Google Cloud Next '26: Googles neue Kontrollschicht für die Enterprise-KI
Vom 22. bis 24. April 2026 hat Google auf dem Cloud Next '26 in Las Vegas die Gemini Enterprise Agent Platform und die 8. Generation der eigenen TPU-Chips vorgestellt. 75 Prozent aller Google-Cloud-Kunden nutzen bereits KI-Produkte, 330 von ihnen haben in zwölf Monaten mehr als eine Billion Tokens verarbeitet. Was sich technisch verändert hat, ist erheblich - was das für deutsche Entscheider bedeutet, ist komplexer.
Google hat auf dem Cloud Next '26 in Las Vegas (22.-24. April 2026) die Gemini Enterprise Agent Platform in vier Säulen strukturiert: BUILD, SCALE & ORCHESTRATE, GOVERN und OPTIMIZE. Parallel dazu stellte Google die 8. TPU-Generation vor - erstmals als zwei spezialisierte Chips: TPU 8t für Training (dreimal leistungsfähiger als der Vorgänger, 9.600 TPUs mit 2 PB Speicher pro Superpod) und TPU 8i für Inferenz (80 Prozent bessere Leistung pro Dollar). Die Adoption-Zahlen sind beeindruckend: 75 Prozent der Kunden nutzen KI-Produkte, 40 Prozent Quartalswachstum bei bezahlten Gemini-Enterprise-Nutzern. Vodafone erwartet 100 Millionen Euro Einsparung durch selbstheilende Netzwerkdiagnostik. Für Europa bleibt die Souveränitätsfrage offen: Das Thales-Google-Joint-Venture S3NS erreichte im EU-Ausschreibungsverfahren nur SEAL-2 statt SEAL-3, CISPE spricht von "Sovereignty Washing". Das US CLOUD Act bleibt ein strukturelles Risiko. Die eigentliche strategische Frage lautet: Wer die Agenten-Kontrollschicht kontrolliert, bindet sich tief - auf Modell-, Framework-, Runtime- und Prozessebene gleichzeitig. Empfehlung: Pilot mit GOVERN starten, EU-Only-Verarbeitungsoptionen explizit vertraglich fixieren und abstrahierte Agenten-Interfaces von Anfang an einplanen.
Einordnung: Konferenz, Kontext, Bedeutung
Google Cloud Next ist die wichtigste Bühne, auf der Google jedes Jahr seinen Cloud- und KI-Fahrplan für Enterprise-Kunden vorstellt. Die Ausgabe 2026 fand vom 22. bis 24. April in Las Vegas statt und stand unter dem Zeichen des Übergangs: Weg von einzelnen Gemini-Modellzugängen, hin zu einer vollständigen Betriebsinfrastruktur für autonome KI-Agenten.
Die Dimensionen, mit denen Google seine Marktposition beschreibt, sind messbar: 75 Prozent aller Google-Cloud-Kunden setzen bereits KI-Produkte ein. 330 Kunden haben in den letzten zwölf Monaten mehr als eine Billion Tokens verarbeitet. Die API-Kapazität liegt inzwischen bei 16 Milliarden Tokens pro Minute - im Vergleich zu 10 Milliarden im Vorquartal. Die Zahl zahlender Gemini-Enterprise-Nutzer wuchs im ersten Quartal 2026 um 40 Prozent gegenüber dem Vorquartal.
Was diese Zahlen zeigen: Die Experimentierphase ist für viele Unternehmen vorbei. Die Ankündigungen auf dem Cloud Next '26 richten sich an Organisationen, die KI-Agenten jetzt in den Produktionsbetrieb überführen wollen - und dabei Fragen nach Sicherheit, Steuerbarkeit und Portabilität stellen müssen.
Die Gemini Enterprise Agent Platform: Vier Säulen
Google hat die Agenten-Plattform in vier funktionale Bereiche gegliedert. Jeder Bereich adressiert eine andere Phase im Agenten-Lebenszyklus.
Das Agent Development Kit (ADK) arbeitet mit einem Graph-basierten Ansatz für komplexe Agenten-Logik. Agent Studio ermöglicht Low-Code-Entwicklung für Fachbereiche ohne tiefes Engineering-Know-how. Der Agent Registry dient als zentrales Verzeichnis aller Agenten einer Organisation. Das Model Context Protocol (MCP) wird nativ unterstützt. Fertige Integrationen existieren für Atlassian, Box, Oracle, ServiceNow und Workday.
Sub-Sekunden-Kaltstarts ermöglichen reaktionsfähige Agenten ohne Wartezeiten beim ersten Aufruf. Long-Running Agents können Prozesse über Stunden oder Tage hinweg verfolgen, ohne den Kontext zu verlieren. Der Memory Bank speichert Wissen sitzungsübergreifend dauerhaft. Sichere Sandboxes isolieren Agenten-Ausführungen voneinander. Die Orchestrierung mehrerer Agenten ist nativ integriert.
Jeder Agent erhält eine kryptografische Identität (Agent Identity), die alle Aktionen eindeutig zuordenbar macht. Das Agent Gateway kontrolliert den Datenverkehr zwischen Agenten und schützt vor Prompt-Injection-Angriffen. Agent Anomaly Detection erkennt ungewöhnliches Verhalten automatisch. Das Security Command Center integriert Agenten-Sicherheit in die bestehende Cloud-Sicherheitsstruktur.
Agent Observability ist OpenTelemetry-konform und integriert sich in bestehende Monitoring-Infrastrukturen. Agent Simulation ermöglicht Stresstests unter kontrollierten Bedingungen, bevor ein Agent in Produktion geht. Agent Evaluation berechnet in Echtzeit, wie gut ein Agent seine Ziele erreicht, und gibt verwertbares Feedback zurück.
Besonders relevant für Enterprise-Entscheider ist die GOVERN-Säule. Kryptografische Agenten-Identitäten und der Agent Gateway adressieren direkt die häufigsten Sicherheitsbedenken bei der Einführung autonomer Systeme: Wer hat was getan, und war die Anfrage legitim? Diese Fragen lassen sich mit der neuen Plattform erstmals systematisch beantworten.
8. TPU-Generation: Erstmals getrennte Chips
Google trennt mit der 8. TPU-Generation erstmals Training und Inferenz auf Chip-Ebene. Das ist eine direkte Reaktion auf die unterschiedlichen Anforderungen beider Workloads: Training braucht maximale Parallelverarbeitung und Speicherbandbreite, Inferenz braucht Effizienz und niedrige Kosten pro Token.
TPU 8t vs. TPU 8i - Vergleich
| Merkmal | TPU 8t (Training) | TPU 8i (Inferenz) |
|---|---|---|
| Primärer Zweck | Modell-Training | Produktions-Inferenz |
| Leistungsgewinn | 3x mehr als Ironwood | 80 % besser pro Dollar |
| Energieeffizienz | 2x besser pro Watt | Deutlich verbessert |
| Maximale Skalierung | 9.600 TPUs, 2 PB Speicher | 1.152 TPUs pro Pod |
| Netzwerk-Technologie | Virgo (bis 1 Mio. TPUs) | Boardfly-Topologie |
| Besonderheit | ca. 97 % Goodput | 3x mehr On-Chip-SRAM, Collectives Acceleration Engine |
Für deutsche Unternehmen bedeuten diese Zahlen konkret: Wer Modelle fine-tunet oder eigene Trainingsdurchläufe plant, bekommt mit TPU 8t erheblich mehr Kapazität pro Dollar als mit der Vorgängergeneration. Wer in Produktion Token-Kosten senken will, profitiert von TPU 8i. Die Trennung schafft aber auch eine neue Planungsaufgabe: Training und Inferenz müssen als unterschiedliche Infrastruktur-Workloads gedacht und budgetiert werden.
Enterprise-Adoption in Zahlen
Die Adoption-Daten zeigen, dass Google-Cloud-KI bereits breiten Einsatz findet - nicht nur bei Tech-Konzernen, sondern auch in traditionellen Branchen.
100 Millionen Euro projizierte Einsparung durch selbstheilende Netzwerkdiagnostik auf Basis von Gemini. Agenten erkennen Netzwerkprobleme und lösen sie ohne manuellen Eingriff.
90 Prozent Mitarbeiter-Adoption mit mehr als 100 Agenten im ersten Einsatzmonat. Eines der schnellsten Enterprise-Rollouts, die öffentlich dokumentiert sind.
Gemini wurde für eine interne KI-Plattform eingesetzt, die verschiedene Fachbereiche des Konzerns mit KI-Kapazitäten versorgt.
Der Werbekonzern produziert mithilfe von KI alle vier Tage eine vollständige Kampagne - doppelt so schnell wie zuvor. Der Fokus liegt auf KI-gestützter Kreativproduktion in großem Maßstab.
Multi-Agenten-Adoption auf Databricks
Auf der Databricks-Plattform, die eng mit Google Cloud zusammenarbeitet, wuchs die Nutzung von Multi-Agenten-Systemen in nur vier Monaten um 327 Prozent. Das zeigt, dass der Übergang von Einzel-Agenten zu koordinierten Agenten-Schwärmen in der Praxis schneller stattfindet als viele Planungsszenarien bisher annahmen.
EU- und Deutschland-Perspektive
Während Google in Las Vegas Wachstumszahlen präsentierte, lief in Europa ein paralleler Prozess: die EU vergab souveräne Cloud-Verträge im Wert von 180 Millionen Euro über sechs Jahre an vier Anbieter. Das Ergebnis ist für Google gemischt.
Die S3NS-Kontroverse
- S3NS ist das Joint Venture von Thales und Google für souveräne Cloud-Dienste in Europa.
- Im EU-Ausschreibungsverfahren erreichte S3NS die Zertifizierungsstufe SEAL-2. Die anderen drei ausgewählten Anbieter schafften SEAL-3.
- Der europäische Cloud-Verband CISPE bezeichnete die SEAL-2-Zertifizierung als "Sovereignty Washing" - also die Vermarktung eines Produkts als souverän, das die tatsächlichen Anforderungen nicht vollständig erfüllt.
- Der US CLOUD Act bleibt ein strukturelles Risiko: Er erlaubt US-Behörden unter bestimmten Umständen Zugriff auf Daten, die von US-Unternehmen verwaltet werden, auch wenn diese Daten physisch in Europa gespeichert sind.
Google Cloud bietet EU-Only-Datenverarbeitungsoptionen an, bei denen Daten ausschließlich innerhalb der EU verbleiben und verarbeitet werden. Diese Option verringert das CLOUD-Act-Risiko, schließt es aber nicht vollständig aus, solange Google als US-amerikanisches Unternehmen der US-Jurisdiktion unterliegt.
Für deutsche Unternehmen, insbesondere in regulierten Branchen wie Finanzdienstleistungen, Gesundheitswesen oder kritischer Infrastruktur, bleibt die Einschätzung klar: Die Souveränitätsfrage muss vor der Plattformauswahl beantwortet werden, nicht danach. Interne Links zu verwandten Analysen findest du im Abschnitt unten.
Mehr zur digitalen Souveränitätsdebatte in Europa: Digitale Souveränität: Frankreich handelt, Deutschland zögert . Zur Transparenz-Debatte bei US-Cloud-Anbietern: Microsoft EU-Rechenzentren und Transparenz .
Kritische Perspektive: Vendor Lock-in und die Agenten-Kontrollschicht
Die Gemini Enterprise Agent Platform ist ein durchdachtes, technisch ausgereiftes Angebot. Und genau das macht sie strategisch heikel. Wer die Agenten-Kontrollschicht eines Anbieters übernimmt, bindet sich nicht nur an das Modell, sondern an das Orchestrierungs-Framework, die Runtime, die interne Governance-Sprache und die Arbeitsweisen des gesamten Teams.
Kai Waehner, Analyst für Enterprise-Architekturen, beschreibt in seiner Analyse zur Agentic-AI-Landschaft 2026, dass sich Lock-in bei Agenten-Systemen kumulativ aufbaut: jede Schicht verstärkt die Abhängigkeit von der darunter liegenden. Model, Framework, Runtime und Teamprozesse bilden zusammen eine Abhängigkeitskette, die schwerer aufzulösen ist als klassischer SaaS-Lock-in.
Lock-in-Dimensionen bei Agenten-Plattformen
- Modell-Lock-in: Fine-tuning-Investitionen, spezifische Prompt-Architekturen und Evaluierungsdaten sind schwer auf andere Modelle übertragbar.
- Framework-Lock-in: ADK-basierte Agenten-Definitionen und der Agent Registry schaffen proprietäre Abhängigkeiten, die Migrationen aufwändig machen.
- Runtime-Lock-in: Memory Bank, Long-Running Agents und Sub-Sekunden-Kaltstarts sind plattformspezifisch; alternative Runtimes müssen komplett neu konfiguriert werden.
- Prozess-Lock-in: Teams entwickeln Intuition und Muster für eine spezifische Plattform. Diese implizites Wissen ist der am schwersten portierbare Lock-in.
Google bietet ein wichtiges Gegengewicht: Der Apache-Iceberg-basierte Cross-Cloud-Lakehouse-Ansatz hält die Datenschicht portabel. Das bedeutet: Deine Daten bleiben in einem offenen Standard, auch wenn du Agenten-Logik migrieren musst. Das ist eine bewusste Designentscheidung, die langfristige Flexibilität ermöglicht - vorausgesetzt, du nutzt sie aktiv.
Die ehrliche Einordnung: Die Agenten-Plattform-Frage ist eine strategische Entscheidung auf dem Niveau einer ERP-Auswahl, nicht eine technische Pilotentscheidung. Sie verdient denselben Entscheidungsrahmen. Mehr zur Governance von KI-Agenten: KI-Agenten-Governance im Enterprise . Zur Vendor-Lock-in-Analyse: KI-Agenten-Plattformen und Vendor Lock-in .
Was Unternehmen jetzt tun sollten
Der Einstieg in die Gemini Enterprise Agent Platform gelingt am besten mit einer strukturierten Reihenfolge, die Risiken kontrollierbar hält und gleichzeitig schnell Ergebnisse liefert.
Schritt 1: Souveränitätsanforderungen zuerst klären
Bevor du eine Plattform wählst, beantworte schriftlich: Welche Daten dürfen die EU nicht verlassen? Welche Regulierungsanforderungen gelten für deine Branche? Mit diesen Antworten kannst du die Google-Cloud-EU-Only-Verarbeitungsoptionen gezielt bewerten und mit deiner Rechts- und Compliance-Abteilung abstimmen. Prüfe auch, ob SEAL-2 oder SEAL-3 für deine Anwendungsfälle erforderlich ist.
Schritt 2: Pilot mit der GOVERN-Säule beginnen
Die GOVERN-Säule liefert sofortigen Nutzen für bestehende Agenten: kryptografische Identitäten machen Agenten-Aktionen nachvollziehbar, der Agent Gateway schützt vor Prompt-Injection-Angriffen. Beides sind Sicherheitsfunktionen, die du auch dann brauchst, wenn du die Plattform nicht vollständig übernahmen möchtest. Ein Pilot mit GOVERN erzeugt internen Wert, ohne tiefe Framework-Abhängigkeiten zu schaffen.
Schritt 3: Abstrahierte Agenten-Interfaces definieren
Lege von Anfang an fest, welche Agenten-Definitionen plattformunabhängig gehalten werden sollen. Nutze MCP-basierte Interfaces, wo immer möglich. Dokumentiere, welche Funktionen proprietär zu ADK oder Agent Studio sind und welche portabel bleiben. Eine klare Exit-Strategie vor dem ersten Produktionsagent ist kein Zeichen von Misstrauen, sondern von guter Architektur.
Schritt 4: Adoption mit OPTIMIZE messen
Nutze Agent Observability und Agent Evaluation von Anfang an. Messbare KPIs - wie Aufgaben-Erledigungsrate, Eskalationsquote und Token-Kosten pro Prozessdurchlauf - machen den Wert von Agenten quantifizierbar und helfen dir, intern für weitere Investitionen zu argumentieren. Die OpenTelemetry-Konformität erleichtert die Integration in bestehende Monitoring-Systeme wie Datadog, Grafana oder Azure Monitor.
Schritt 5: Daten auf Apache Iceberg halten
Nutze den Cross-Cloud-Lakehouse-Ansatz auf Apache-Iceberg-Basis für alle Datenquellen, auf die Agenten zugreifen. Das hält die Datenschicht offen und portabel, unabhängig davon, welche Agenten-Plattform du langfristig einsetzt. Diese Entscheidung kostet kaum Mehraufwand, wenn sie früh getroffen wird, und verhindert teuren technischen Schuldenabbau später.
Zum Thema Vertrauensaufbau bei der KI-Einführung im Enterprise: Stanford AI Index 2026 und die Vertrauenslücke .