Google hat seine Datenarchitektur neu gestaltet, damit KI in Unternehmen aufhört zu scheitern
Jahrelang arbeiteten Datenteams und KI-Teams in großen Konzernen wie Abteilungen aus verschiedenen Ländern. Die einen bauten Data Warehouses, Kataloge und Pipelines. Die anderen stellten Modelle, APIs und Agenten bereit. Beide Welten kommunizierten über manuelle Exporte, unterbrochene Prozesse und einen blinden Glauben daran, dass „das andere Team das schon löst". Das Ergebnis war vorhersehbar: KI-Agenten gelangten in die Produktionsumgebung und brachen zusammen, sobald sie auf Daten stießen, die niemand so aufbereitet hatte, dass eine autonome Maschine sie lesen, interpretieren und darauf handeln konnte.
Auf der Google Cloud Next 2026 benannte Google diesen Zusammenbruch präzise: Die Trennung zwischen Datenplattform und KI-Plattform ist das größte Hindernis für den unternehmensweiten Einsatz autonomer Agenten. Die Antwort darauf war die Agentische Datenwolke, eine tiefgreifende Neukonfiguration der Datenarchitektur, die keine KI-Schicht über das Bestehende legt, sondern das Fundament neu gestaltet, damit Agenten erstklassige Nutzer der Unternehmensdaten werden.
Der Unterschied im Anspruch ist nicht gering. Es geht nicht um neue Konnektoren oder um Dashboards, die mit natürlicher Sprache angereichert wurden. Es geht um einen strukturellen Neuentwurf, der zwingt, zu überdenken, wie jedes Fortune-500-Unternehmen – mit Daten, die auf AWS, Azure und Google Cloud verteilt sind – die Informationen, die es bereits besitzt, verwalten, bereitstellen und monetarisieren wird.
Die Diagnose, die Führungskräfte lieber ignorieren
Es gibt eine Zahl, die unangenehm ist: Laut der Forschung, die mit der Markteinführung einhergeht, entdecken rund 70 % der Unternehmen die Schwachstellen ihrer Dateninfrastruktur erst nach dem Einsatz von Agenten, nicht davor. Das ist kein technisches Problem. Es ist ein Führungsproblem im technischen Gewand.
Fragmentierte Daten, ohne Governance, in Silos verschiedener Clouds eingeschlossen, sind nicht über Nacht entstanden. Sie haben sich über Jahre hinweg angesammelt – durch übereilte Entscheidungen, schlecht integrierte Unternehmensakquisitionen und eine zutiefst menschliche organisatorische Tendenz: das schwierige Gespräch über die tatsächliche Datenarchitektur aufzuschieben, weil „das Geschäft ja weiterläuft". Bis es das nicht mehr tut.
Die von Google vorgestellte Architektur besteht aus sechs Komponenten, die nicht unabhängig voneinander sind, sondern ein System mit sequenzieller Logik bilden. An der Basis ermöglicht das Multicloud Data Lakehouse, das auf dem offenen Apache-Iceberg-Format aufbaut, dass BigQuery Daten abfragt, die in AWS S3 und Azure ADLS gehostet werden, ohne diese verschieben oder replizieren zu müssen. Dies eliminiert Egress-Kosten und das Risiko von Inkonsistenzen zwischen Kopien. Darauf aufbauend arbeitet die Lightning-Engine für Apache Spark, eine in C++ vektorisierte Ausführungsschicht, die bis zu 4,9-mal die Leistung des herkömmlichen Spark liefert. Die Daten sind nicht nur zugänglich; sie lassen sich mit einer Geschwindigkeit verarbeiten, die es einem Agenten ermöglicht, Spark-Code in kontinuierlichen Zyklen zu generieren, auszuführen und zu korrigieren, ohne dass die Kosten explodieren.
Über dieser Ausführungsinfrastruktur kommt die Schicht der kontextuellen Intelligenz: der Knowledge Catalog, die Weiterentwicklung des am 10. April 2026 vorgestellten Dataplex Universal Catalog. Dieses Element sollte die Aufmerksamkeit von Unternehmensarchitekten am stärksten in Anspruch nehmen. Der Katalog erfordert nicht, dass Datenteams Ressourcen manuell katalogisieren. Er untersucht Abfrageprotokolle, erstellt Tabellenprofile, analysiert semantische Modelle aus Tools wie Looker und extrahiert Beziehungen zwischen Entitäten aus unstrukturierten Dateien. Das Ergebnis ist ein dynamischer Wissensgraph, der automatisch gepflegt wird und auf die Frage antwortet, die jeder Agent vor dem Handeln lösen muss: Welche Daten existieren, was bedeuten sie genau und sind sie vertrauenswürdig?
Wenn die Datenspeicherung aufhört, passiv zu sein
Das Element, das die operative Geometrie der Daten am radikalsten verändert, ist der Intelligente Speicher, der sich derzeit in der Vorschauphase befindet. Bisher war eine Datei, die in einen Google Cloud Storage-Bucket gelangte, inert, bis jemand entschied, sie zu verarbeiten. Mit dieser Funktionalität beschriftet das System eine Datei in dem Moment, in dem sie im Bucket ankommt, automatisch, generiert Embeddings, extrahiert relevante Entitäten und verknüpft sie mit dem Knowledge Catalog. PDFs, Verträge, Support-Tickets, Audioaufnahmen: Alles wird zu einem durchsuchbaren Asset, ohne dass ein Ingenieur eingreifen muss.
Für Führungskräfte, die Projekte zur Aufbereitung unstrukturierter Daten aufgeschoben haben – jene, die „sechs Monate" an Extraktion, OCR, Indexierung und Katalogisierung in Anspruch nehmen würden – rekonfiguriert dies die Zeit- und Kostengleichung auf eine Weise, die kein bequemes Aufschieben mehr erlaubt. Was zuvor ein Projekt mit einem Executive Sponsor, eigenem Budget und ungewissem Lieferdatum war, wird zu einer automatischen Folge der Speicherrichtlinie.
Der Deep Research Agent, basierend auf Gemini 3.1 Pro, veranschaulicht den terminalen Anwendungsfall dieser gesamten Infrastruktur. Er arbeitet, indem er interne Quellen aus dem Knowledge Catalog und dem Lakehouse mit offenen Quellen im Internet kombiniert, strukturierte Recherchepläne erstellt und Berichte mit verifizierbaren Zitaten in Minuten liefert. Aufgaben, die in Bereichen wie Wettbewerbsintelligenz, Biowissenschaften oder Finanzdienstleistungen zwischen einer und drei Wochen Analysearbeit in Anspruch nahmen, werden zum Ausgangspunkt – nicht zum Endpunkt.
Das Data Agents Kit vervollständigt das Bild auf der Entwicklerseite. Es bietet vorkonfigurierte MCP-Tools und drei spezialisierte Agenten: einen, der Anweisungen in natürlicher Sprache in verwaltete Pipelines umwandelt und dabei zwischen BigQuery, dbt, Spark oder Airflow wählt; einen weiteren, der den vollständigen Zyklus von Data-Science-Modellen automatisiert; und einen dritten, der sich auf die Beobachtbarkeit der Infrastruktur spezialisiert. Das Model Context Protocol fungiert als Interoperabilitätsschicht, die es Agenten jedes Anbieters – Gemini, Claude, eigene Modelle – ermöglicht, auf Daten-Assets zuzugreifen, ohne maßgeschneiderte Konnektoren zu benötigen.
Multicloud hört auf, eine Klage zu sein, und wird zu einer Architekturentscheidung
Kein Unternehmen unter den Fortune 500 operiert ausschließlich in Google Cloud. SAP-, Salesforce-, Workday- und Oracle-Systeme sind aus historischen, vertraglichen und operativen Gründen auf AWS und Azure verteilt – Gründe, die kein CTO-Mandat mit einem Memorandum lösen kann. Jahrelang war die Multicloud das wiederkehrende Argument, um keine KI-Initiative in größerem Maßstab voranzutreiben: „Zuerst müssen wir die Daten konsolidieren."
Das Multicloud Data Lakehouse demontiert dieses Argument mit technischer Spezifität. Mithilfe des Iceberg REST Catalog, der Multicloud-Interconnect-Funktion und einer intelligenten Cache-Schicht kann BigQuery Daten in AWS S3 und Azure ADLS mit Latenz und Kosten abfragen, die mit denen nativer Daten in Google Cloud vergleichbar sind. Ein Beschaffungsagent kann in einer einzigen Abfrage Vertragsdaten, die in S3 gespeichert sind, Bestände in Azure und Transaktionsdaten in BigQuery kombinieren – alles unter einem einheitlichen Iceberg-Katalog, ohne dass ein Engineering-Team einen ETL-Prozess zwischen den Clouds verwalten muss.
Die Implikation für Integrationsarchitekten ist strategischer Natur. Das Gespräch hört auf, „wie wir alles in eine einzige Cloud migrieren" zu sein, und wird zu „wie wir einen einzigen Katalog über die bereits vorhandene Datenverteilung verwalten". Das ist nicht dasselbe Gespräch. Das erste hat in den meisten reifen Organisationen prohibitive politische und finanzielle Kosten. Das zweite ist ausführbar, ohne bestehende Verträge mit anderen Anbietern zu stören.
Was Google insgesamt vorschlägt, ist ein Paradigmenwechsel mit organisatorischen Konsequenzen, die über die technische Architektur hinausgehen. Das MCP als Governance-Schicht für Agenten muss mit derselben Disziplin verwaltet werden, die heute auf ein API-Gateway angewendet wird: Versionierung, Authentifizierung, Überwachung, Nutzungslimits. Der Knowledge Catalog hört auf, ein Dokumentationsprojekt zu sein, und wird zu einer operativen Echtzeit-Abhängigkeit – was Service-Level-Agreements, kontinuierliche Wartung und ein Betriebsmodell impliziert, das Datenteams noch nicht entworfen haben.
Die Kultur einer Organisation ist nicht das gerahmte Poster im Konferenzraum und nicht die Rede des CEOs auf der Jahrestagung. Sie ist die kumulierte Summe aller Entscheidungen, die Führungskräfte getroffen haben, als es bequemer war aufzuschieben als zu entscheiden, sicherer zu delegieren als zu übernehmen, leichter die technischen Schulden zu beschuldigen als anzuerkennen, dass die Datenarchitektur mit chirurgischer Präzision die Architektur der Macht, der Angst und der Gespräche widerspiegelt, die die Unternehmensführung nie den Mut hatte zu führen.
