Produktive KI auf Google Cloud: von Vertex AI zur Gemini Enterprise Agent Platform

Wer zuletzt nach Vertex AI gesucht hat und bei der Gemini Enterprise Agent Platform gelandet ist, hat sich nicht verirrt: Google hat sie am 22. April 2026 umbenannt. Die Bausteine für einen produktiven Agenten sind weiterhin da, viele mit neuen Namen. Das hier ist das Setup, das ich heute bauen würde: getrennte Projekte und Agenten-Identitäten, ein VPC-Service-Controls-Perimeter, RAG Engine auf den eigenen Daten, Model Armor vor jedem Modellaufruf, Evaluationen auf echten Traces und Provisioned-Kapazität erst, wenn die Zahlen es rechtfertigen. Jede Aussage verweist auf Googles Dokumentation.

Dominik Heinrich

7. November 202611 Min. Lesezeit

1. Wann Google Cloud passt, und wie sich die Namen geändert haben

Google Cloud ist ein starkes Zuhause für KI, wenn Ihre Analysen schon in BigQuery liegen, Ihr Unternehmen mit Google Workspace arbeitet oder Sie Gemini-Modelle nahe an Ihren Daten mit Googles Suchtechnologie für den Abruf wollen. Model Garden bietet auch Modelle von Drittanbietern und offene Modelle, etwa Claude von Anthropic und Googles offene Gemma-Familie, Sie sind also nicht an eine Modellfamilie gebunden.

Die Umbenennung ist das Erste, was man verstehen muss, denn die Hälfte der Tutorials im Netz nutzt die alten Namen. In den Release Notes vom 22. April 2026 listet Google jede Änderung von Vertex AI zur Gemini Enterprise Agent Platform: Vertex AI Studio wurde zu Agent Studio, die Vertex AI API zur Agent Platform API, Vertex AI Agent Engine zu Agent Runtime, deren Memory Bank und Sessions zu Agent Platform Memory Bank und Sessions, und Vertex AI Search zu Agent Search. RAG Engine, Vector Search und Model Garden behalten ihre Namen. Google weist zudem darauf hin, dass gespeicherte Links über Weiterleitungen funktionieren.

Technisch bricht wenig: Die Dokumentation zu VPC Service Controls schützt den Dienst weiterhin als aiplatform.googleapis.com, bestehende Projekte laufen weiter. Neue Funktionen erscheinen aber unter den Agent-Platform-Namen, nutzen Sie diese ab jetzt in Dokumentation und Runbooks.

What is Gemini Enterprise Agent Platform?, Google Cloud Tech (YouTube). Wird erst nach Ihrem Klick von YouTube geladen.

2. Projekte, IAM und Agent Identity

Nutzen Sie getrennte Google-Cloud-Projekte für Nicht-Produktion und Produktion, idealerweise in einem Ordner mit Organisationsrichtlinien, die erlaubte Regionen und Dienste einschränken. Quoten, Modellzugriff, Logs und Sicherheitseinstellungen unterscheiden sich dann pro Projekt, und ein Test erreicht keine Produktionsdaten.

Agenten brauchen eine eigene Identität, nicht ein geteiltes Dienstkonto, das alles darf. Googles Agent-Platform-Übersicht beschreibt Agent Identity als Weg, Agenten granulare Rechte zu geben, und die Dokumentation behandelt die Authentifizierung bei Google Cloud mit der eigenen Identität des Agenten sowie bei externen Diensten über einen Auth Manager mit OAuth-Flows. Geben Sie jedem Agenten nur die Rollen, die er braucht: einen Cloud-Storage-Bucket lesen, ein Dataset abfragen, die genutzten Modelle aufrufen.

Für Menschen nutzen Sie Gruppen und vordefinierte Rollen statt Einzelfreigaben, und das Recht, Agenten in Produktion zu bringen, bleibt bei einer kleinen Gruppe oder Ihrer CI/CD-Pipeline. Prüfen Sie IAM-Bindungen vor dem Go-live; zu breite Rollen auf einem Agenten sind der häufigste Fund in einem Security-Review.

3. Ein privater Perimeter: VPC Service Controls und Private Service Connect

Auf Google Cloud ist ein VPC-Service-Controls-Perimeter die stärkste Kontrolle gegen Datenabfluss. Sie legen die Projekte mit Agent, Daten und Modellen hinein und führen die APIs als eingeschränkte Dienste auf, etwa aiplatform.googleapis.com und storage.googleapis.com. Aufrufe dieser APIs von ausserhalb des Perimeters werden dann blockiert, sofern sie kein von Ihnen definiertes Access Level erfüllen. Googles Dokumentation zur Agent Runtime nennt die Unterstützung von VPC Service Controls und dass ein bereitgestellter Agent im Perimeter sicheren Zugriff auf Google-APIs wie BigQuery behält.

Für private Verbindungen aus Ihren eigenen Netzen ist der Leitfaden des Google Cloud Architecture Center zu privater Konnektivität für RAG-fähige generative KI-Anwendungen der Bauplan: ein Routing-Projekt mit einem Private-Service-Connect-Endpoint, angebunden an Ihre On-Prem- oder andere Cloud-Netze über Cloud Interconnect oder Cloud VPN, mit DNS, das auf diesen Endpoint zeigt, und Data Engineers, die RAG-Daten privat nach Cloud Storage hochladen.

Führen Sie den Perimeter zuerst im Dry-Run-Modus ein. Er protokolliert, was blockiert würde, ohne zu blockieren, so finden Sie das vergessene Dienstkonto in einer CI-Pipeline, bevor es ein Release bricht.

bash

# Dry-run perimeter around the AI project (POLICY_ID = your access policy)
gcloud access-context-manager perimeters dry-run create ai_perimeter \
  --policy=POLICY_ID \
  --perimeter-title="AI production perimeter" \
  --perimeter-type=regular \
  --perimeter-resources=projects/PROJECT_NUMBER \
  --perimeter-restricted-services=aiplatform.googleapis.com,storage.googleapis.com,bigquery.googleapis.com

# After the dry-run logs are clean, enforce it
gcloud access-context-manager perimeters dry-run enforce ai_perimeter --policy=POLICY_ID

Tipp aus der Praxis

Prüfen Sie, ob jeder Dienst, den Ihr Agent braucht, von VPC Service Controls unterstützt wird, bevor Sie einen dichten Perimeter versprechen. Google führt eine Liste unterstützter Produkte mit Einschränkungen pro Dienst.

Referenz-Setup auf der Gemini Enterprise Agent Platform (früher Vertex AI): alles in einem VPC-Service-Controls-Perimeter, Model Armor im Anfragepfad, Evaluationen auf Cloud-Trace-Daten.

4. Modelle und Kapazität: zuerst Pay-as-you-go, später Provisioned Throughput

Model Garden bietet Zugriff auf Googles Gemini-Modelle, Drittanbieter- und offene Modelle; die Agent-Platform-Übersicht spricht von über 200 Foundation Models. Wie in jeder Cloud gilt: pro Schritt wählen, ein schnelles, günstiges Modell für Routing und Extraktion, ein stärkeres für komplexe Antworten und ein Embedding-Modell für den Abruf.

Bei der Kapazität ist Pay-as-you-go der Standard. Provisioned Throughput ist ein Abonnement mit festen Kosten, das Durchsatz für unterstützte generative KI-Modelle an den gewählten Standorten reserviert. Gemessen wird in Generative AI Scale Units (GSUs), und Google positioniert es für Echtzeit-Anwendungen in Produktion wie Chatbots und Agenten, bei denen planbares Erlebnis und feste Kosten zählen. Übersteigt eine Anfrage das reservierte Kontingent, wird sie als Pay-as-you-go verarbeitet; wer nur Provisioned Throughput konfiguriert, bekommt für solche Anfragen stattdessen einen HTTP-429-Fehler.

Diese Wahl zwischen Überlauf und harter Grenze ist eine Architekturentscheidung, kein Abrechnungsdetail. Überlauf schützt das Nutzererlebnis, macht die Kosten aber weniger planbar; eine harte Grenze schützt das Budget, braucht aber Retries und einen Fallback in der Anwendung.

5. Ihre Daten: RAG Engine, Vector Search und Agent Search

Google bietet mehrere Wege, einen Agenten auf eigenen Daten aufzubauen. RAG Engine verbindet private Unternehmensdaten sicher mit Modellen, um Antworten genauer zu machen und Halluzinationen zu reduzieren, und kann verschiedene Vektorspeicher nutzen. Vector Search ist die KI-native Suchmaschine für das Speichern und Durchsuchen von Embeddings im grossen Massstab. Agent Search, früher Vertex AI Search, bietet Suche in Google-Qualität über Ihre Dokumente und Websites als verwalteten Dienst.

Das Architecture Center listet Referenzdesigns für mehrere Kombinationen, etwa RAG-Infrastruktur mit Agent Platform und Vector Search, mit AlloyDB oder mit Spanner Graph für graphbasierten Abruf. Für ein erstes Release nehme ich standardmässig die am stärksten verwaltete Option, die Datenresidenz und Zugriffsregeln erfüllt, denn der schwierige Teil von RAG ist selten der Index. Schwierig ist, Dokumente aktuell zu halten, zu respektieren, wer welches Dokument sehen darf, und mit Fragen zu testen, bei denen Sie die richtige Quelle kennen.

Legen Sie die Rohdokumente in Cloud Storage innerhalb des Perimeters ab, verschlüsseln Sie mit eigenen Schlüsseln, wo es die Richtlinie verlangt (RAG Engine dokumentiert CMEK-Unterstützung), und geben Sie dem Ingestion-Job eine eigene Identität, die nur die Quell-Buckets lesen darf.

6. Den Agenten bauen und betreiben: ADK, Agent Studio und Agent Runtime

Zum Bauen bietet Google zwei Wege. Agent Studio ist eine Low-Code-Oberfläche, um Agenten und ihre Workflows zu entwerfen. Das Agent Development Kit (ADK) ist ein modulares, modellunabhängiges Framework für Code-first-Agenten mit Denkschritten und Tool-Nutzung. Die Dokumentation behandelt auch andere Frameworks auf der Runtime, etwa LangChain, LangGraph, AG2 und LlamaIndex, sowie das Agent2Agent-Protokoll für Agenten, die miteinander sprechen.

Zum Betreiben ist Agent Runtime (früher Agent Engine) die verwaltete, skalierbare Umgebung, um Agenten bereitzustellen und zu betreiben, auch lang laufende. Dazu gehören Agent Platform Sessions für den Zustand innerhalb einer Interaktion, Memory Bank für Gedächtnis über Sessions hinweg und Code Execution, das generierten Python-Code in einer Sandbox ausführt. Für Governance beschreibt Google Agent Gateway zusammen mit Model Armor als die Schicht, die Agenten-Interaktionen absichert und Laufzeitrichtlinien durchsetzt.

Meine Empfehlung: Schreiben Sie den Agenten mit ADK, wenn Sie Entwickler haben, denn Code ist testbar und reviewbar, und nutzen Sie Agent Studio für Prototypen mit Fachteams. Bringen Sie ihn über Ihre Pipeline auf die Agent Runtime, mit Revisionen und Traffic-Splitting für einen vorsichtigen Rollout, nicht vom Laptop aus.

Tipp aus der Praxis

Nutzen Sie Revisionen und Traffic-Splitting auf der Agent Runtime wie einen Canary: einen kleinen Teil des Verkehrs auf die neue Revision, ihre Online-Evaluationswerte mit der alten vergleichen, dann den Rest umschalten.

7. Model Armor vor jedem Modellaufruf

Model Armor prüft Prompts und Antworten, bevor sie das Modell oder den Nutzer erreichen. Google nennt die wichtigsten Anwendungsfälle: sensible Daten wie personenbezogene Daten oder geistiges Eigentum mit Sensitive Data Protection schwärzen, Prompt Injection und Jailbreak-Versuche blockieren, schädliche URLs filtern und Responsible-AI-Filter für Kategorien wie Hassrede, Belästigung oder sexuell explizite Inhalte anwenden. Es funktioniert für Anwendungen auf Google Cloud und anderen Clouds, was hilft, wenn Ihre Agenten über Anbieter verteilt sind.

Model Armor wird über Templates konfiguriert: ein Template pro Risikoprofil, etwa ein strenges für einen kundennahen Agenten und ein leichteres für einen internen Recherche-Assistenten. Jedes Template legt Filter, ihre Konfidenzstufen sowie Fehlercode und Meldung fest, die Ihre Anwendung bei einer Blockierung erhält, damit die App höflich antworten kann statt abzustürzen.

Behandeln Sie Templates als Code. Legen Sie sie aus der Pipeline an, prüfen Sie Änderungen wie jede andere Sicherheitsregel und führen Sie pro Template ein Testset mit Angriffs-Prompts, inklusive Anweisungen, die in Dokumenten versteckt sind, die Ihr Agent abruft.

bash

# Strict template for a customer-facing agent (values from Google's example)
gcloud model-armor templates create support-agent-strict \
  --project=PROJECT_ID --location=LOCATION \
  --rai-settings-filters='[
    {"filterType": "HATE_SPEECH", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "HARASSMENT", "confidenceLevel": "MEDIUM_AND_ABOVE"},
    {"filterType": "SEXUALLY_EXPLICIT", "confidenceLevel": "MEDIUM_AND_ABOVE"}
  ]' \
  --basic-config-filter-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=HIGH \
  --malicious-uri-filter-settings-enforcement=enabled

8. Auf echten Traces evaluieren, beobachten, Kosten steuern, dann die Clouds vergleichen

Agenten- und Modell-Evaluationen in der Gemini Enterprise Agent Platform sind laut Googles Ankündigung seit dem 31. Juli 2026 allgemein verfügbar. Der Dienst bringt über 20 vorgefertigte Metriken für Qualität, Sicherheit, Grounding, Tool-Nutzung und Trajektorie mit, dazu adaptive Rubrics und eigene Metriken als Code oder LLM-as-a-Judge. Offline-Evaluation misst Agenten an historischen Daten und setzt voraus, dass der Agent OpenTelemetry-Signale exportiert; mit Agent Runtime muss Cloud Trace aktiviert sein. Online-Monitore ziehen Stichproben aus Live-Traces und Logs, führen die Metriken aus, schreiben Ergebnisse in Cloud Logging und numerische Werte in Cloud Monitoring, wo Sie darauf alarmieren können.

Das ist ein grosser praktischer Vorteil: Dieselben Traces, die Sie zur Fehlersuche nutzen, werden zu Ihren Qualitätsdaten. Richten Sie Tracing ab Tag eins ein, lassen Sie die Offline-Evaluation als Gate in CI laufen und halten Sie Online-Monitore in Produktion mit einem Alert, wenn ein Wert fällt.

Für die Kosten: Ressourcen pro Agent und Team labeln, Token-Verbrauch pro Modell beobachten, Provisioned Throughput nur für eine nachgewiesen gleichmässige Last und das Setup jedes Quartal prüfen. Die häufigsten Fehler, die ich sehe: ein Agent mit einem breiten Dienstkonto, kein Perimeter, Model Armor nur auf dem Nutzer-Prompt statt auch auf abgerufenen Inhalten, und Tracing, das erst nach dem ersten Vorfall eingeschaltet wird. Dasselbe Setup auf Microsoft Azure steht in /blog/azure-ai-foundry, auf AWS in /blog/aws-bedrock.

Fazit
Auf Google Cloud lautet das Rezept für Produktion: ein VPC-Service-Controls-Perimeter, Agenten mit eigenen Identitäten, RAG auf eigenen Daten, Model Armor als Sicherheitsschicht und der Evaluation Service, der dieselben Traces liest, mit denen Sie debuggen.

Echte Projekte dazu

Selbst ausprobieren

Bereit für Produktion

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden