Google Vertex AI Agent Engine GA: Was die Policy-Governance für ERP-Integration wirklich leistet

Am 3. Juni 2026 macht Google Cloud die Vertex AI Agent Engine allgemein verfügbar – und positioniert sie als Orchestrierungsschicht für Enterprise-KI-Agenten, die in ERP- und CRM-Systeme eingreifen. Context Caching, Tool-Governance über Apigee und MCP, Grounding mit Vertex AI Search: klingt mächtig. Aber halten wir kurz inne und schauen uns an, was das wirklich bedeutet, wo echte Governance greift und wo noch Lücken klaffen.

Klartext: Was Google jetzt wirklich ankündigt

Google spricht intern nicht konsequent von „Agent Orchestrator“. Der offizielle Produktname lautet Vertex AI Agent Engine, eingebettet in die Gemini Enterprise Agent Platform. Wer in Pressemitteilungen oder Fachblogs den Begriff „Orchestrator“ liest, begegnet einer umgangssprachlichen Beschreibung der Orchestrierungsrolle – kein eigenständiges SKU, kein neues Produkt. Das klingt nach Kleinkrämerei. Ist es aber nicht. Denn wer Enterprise-Budgets in Millionenhöhe auf ein Produkt plant, sollte wissen, wie es offiziell heißt – und was es tatsächlich kann.

Was Google jetzt liefert, ist ein Managed Service, der mehrere spezialisierte KI-Agenten koordiniert, mit Laufzeitumgebung, Session-Management, Tool-Anbindung und Evaluation. Die Agenten laufen auf Gemini-Modellen, das Agent Development Kit (ADK) ist Open Source und setzt auf Grounding über Vertex AI Search. Ein Multi-Agenten-System mit A2A-Protokoll (Agent-to-Agent), das unterschiedliche Rollen – Vertrieb, Finance, Compliance – orchestriert betreiben kann.

Seien wir ehrlich: Das ist ein echter Schritt vorwärts. Aber kein Selbstläufer.

Was Context Caching in der Praxis bedeutet – und was nicht

Das am häufigsten missverstandene Feature. Context Caching in Vertex AI bedeutet: Vorkompilierte Input-Token-Blöcke – lange System-Kontexte, Produktkataloge, Policy-Texte – werden einmalig berechnet und danach wiederverwendet. Laut offiziellem Google Cloud Blog zu Vertex AI Context Caching werden diese gecachten Tokens mit rund 90 Prozent Rabatt gegenüber normalen Input-Tokens abgerechnet. Das ist erheblich.

Zwei Cache-Typen stehen bereit. Implizites Caching erkennt automatisch wiederholte Inhalte und cachet sie – die Lebensdauer beträgt maximal 24 Stunden. Explizites Caching erlaubt eigene CachedContent-Objekte mit individueller TTL (Time-to-Live). Wer eine längere TTL setzt, zahlt höhere Storage-Kosten, spart dafür Rechenaufwand. Wer kurze TTL wählt, riskiert häufige Cache-Misses.

Die harte Wahrheit: Reine System-Prompts lassen sich nicht direkt cachen. Das offizielle API erfordert mindestens ein Content-Objekt in contents. Wer nur seinen System-Prompt cachen will, braucht einen Workaround – den System-Prompt-Text in einen User-Content-Block überführen. Das ist Community-Praxis, keine offizielle Empfehlung. Für Compliance-kritische Produktivumgebungen sollte man diesen Umweg sauber dokumentieren und testen.

Für ERP/CRM-Szenarien ist Context Caching trotzdem hochrelevant: Produktkataloge, Vertragstemplate-Texte oder interne Policy-Dokumente sind ideale Cache-Kandidaten – groß, statisch, teuer in der Wiederberechnung. Kleine, häufig wechselnde Fragmente gehören dagegen nicht in den Cache.

Governance: Was die „Policy-Engine“ wirklich ist

Hier wird am meisten übertrieben. Manche Berichte legen nahe, Vertex AI Agent Engine bringe eine eingebaute Policy-Engine im Stil von OPA oder XACML mit. Das ist falsch. Wie Hyperframe Research in ihrer Analyse zu Vertex AI Guardrails zeigt, verteilt Google die Governance-Mechanismen auf mehrere Schichten: Cloud API Registry, Apigee, IAM, Secure Code Sandbox und Tool-Konfigurationen im ADK.

Was das konkret bedeutet: APIs und Tools für Agenten werden über die Cloud API Registry zentral katalogisiert und kuratiert. Apigee fungiert als Gateway, das Rate Limits, Auth-Flows und Datenmaskierung durchsetzt. IAM regelt, welcher Agent-Service-Account welche GCP-Ressource ansprechen darf. Die Secure Code Sandbox isoliert Tool-Ausführungen. Zusammen ergibt das eine Policy-ähnliche Schicht – aber eben kein einheitliches deklaratives Policy-System mit No-Code-Regeln.

Für Enterprise-Architekten bedeutet das: Wer heute erwartet, Zugriffsregeln wie „Agent Vertrieb darf keine Zahlungsfreigaben auslösen“ in einer einzigen Policy-Konsole zu definieren, wird enttäuscht. Diese Regeln entstehen im Zusammenspiel aus Apigee-Policies, IAM-Rollen, Tool-Definitionen im ADK und Custom-Code-Guardrails. Mehr Flexibilität, mehr Verantwortung. Schluss damit, sich auf fertige Policy-Suites zu verlassen – das Engineering liegt beim Team.

ERP- und CRM-Integration: Wie das Architekturmodell aussieht

Die eigentliche Frage lautet: Wie bindet man SAP, Oracle oder Salesforce sauber ein? Die Antwort ist klarer als erwartet. Agent Engine sieht ERP- und CRM-Systeme ausschließlich als Tools – als REST- oder GraphQL-Endpunkte, idealerweise vermittelt über Apigee oder einen MCP-Server. Das Model Context Protocol (MCP) standardisiert dabei, wie diese APIs als Tool-Definitionen für LLM-Agenten erscheinen.

Bestehende Apigee-APIs lassen sich so als agentengerechte Tools veröffentlichen, mit zentralen Policies direkt am Gateway: Rate Limits, OAuth-Flows, Datenmaskierung sensibler Felder wie Kontodaten oder Sozialversicherungsnummern. Der Agent sieht nur die Policy-gefilterte Sicht. Separation of Duty – ein klassisches ERP-Governance-Konzept – wird dabei nicht durch die Agent Engine selbst erzwungen, sondern durch sorgfältig konfigurierte API-Layer und IAM-Policies.

Agentic-AI-Workflows bedeuten in diesem Modell: Ein Orchestrierungs-Agent verteilt Aufgaben an spezialisierte Sub-Agenten. Ein Finance-Agent greift nur auf freigegebene Finance-APIs zu, ein CRM-Agent auf Kundendaten-Endpunkte. Die Übergabe erfolgt per A2A-Protokoll, protokolliert über Cloud Trace und Cloud Logging. Was automatische Entscheidungen in Unternehmensprozessen bedeuten, wenn die Governance-Schicht nicht sauber sitzt, ist eine Frage, die sich jedes Enterprise-Team ernsthaft stellen muss.

Praxisszenarien: Wo Agent Engine heute schon sinnvoll einsetzbar ist

Trotz aller Einschränkungen gibt es konkrete Einsatzfelder, bei denen Vertex AI Agent Engine heute bereits einen messbaren Mehrwert liefert – wenn die Architektur stimmt. Drei Szenarien verdeutlichen das.

Szenario 1: Automatisierte Bestellprüfung in SAP. Ein Procurement-Agent empfängt eingehende Bestellanforderungen, prüft via Apigee-gesicherter SAP-API, ob Budgets verfügbar sind, vergleicht Lieferantenbedingungen aus einem Vertex AI Search-Datastore und gibt eine Empfehlung zurück – oder eskaliert an einen menschlichen Genehmiger. Der Agent entscheidet nicht autonom über Zahlungen, sondern bereitet Entscheidungen vor. Das ist ein realistisches Produktivszenario, bei dem die Governance-Grenzen klar ziehbar sind: Der Agent hat Read-Zugriff auf Budgetdaten, aber keinen Write-Zugriff auf Zahlungsfreigaben.

Szenario 2: CRM-Kontext-Anreicherung im Vertrieb. Ein Vertriebsagent verknüpft Informationen aus Salesforce-Kundendatensätzen mit internen Angebotsdokumenten, die über Vertex AI Search abrufbar sind. Vor jedem Kundengespräch generiert der Agent eine strukturierte Zusammenfassung: offene Angebote, letzte Kontaktpunkte, relevante Produktempfehlungen basierend auf Kaufhistorie. Kein autonomes Handeln, aber erhebliche Zeitersparnis für Vertriebsteams – und ein Szenario, das datenschutzrechtlich sauber abgrenzbar ist, wenn Kundendaten ausschließlich über maskierte Apigee-Endpunkte fließen.

Szenario 3: Compliance-Monitoring in Finance. Ein Compliance-Agent überwacht kontinuierlich Transaktionsdaten auf Anomalien – nicht in Echtzeit auf Einzeltransaktionsebene, sondern als periodische Batch-Analyse über exportierte ERP-Daten in einem Vertex AI Search-Datastore. Abweichungen werden geloggt, klassifiziert und an Compliance-Teams eskaliert. Das Modell bleibt in seiner Governance-Rolle: Es beobachtet, kategorisiert und alarmiert – aber greift nicht in Transaktionen ein. Der Audit-Trail entsteht automatisch durch Cloud Logging.

Diese drei Szenarien haben gemeinsam, dass die Agent-Autonomie bewusst begrenzt ist. Das ist kein Versagen der Plattform – es ist die richtige Strategie für den Einstieg in produktive Agentic-AI-Deployments.

Grounding: Wie Agenten auf aktuelle Unternehmensdaten zugreifen

Context Caching ist für statische Kontextblöcke ideal. Für dynamische, aktuelle Unternehmensdaten braucht es Grounding. Das Agent Development Kit integriert VertexAiSearchTool, das Agenten auf konfigurierte Datastores in Vertex AI Search zugreifen lässt – private Dokumente, Policy-PDFs, ERP-Exportdaten, CRM-Historiendaten.

Der Ablauf ist dabei klar strukturiert: Der Agent erhält eine Nutzeranfrage, das ADK orchestriert den Prompt zum LLM, das LLM entscheidet, ob ein Search-Tool-Call nötig ist, Vertex AI Search durchsucht den Datastore und rankt relevante Chunks, und das LLM generiert eine Antwort mit Quellen-Metadaten aus dem groundingMetadata-Objekt. Zitierfähige Antworten, rückverfolgbar auf konkrete Dokumente. Das ist für Compliance-Umgebungen mit Audit-Pflicht ein echter Vorteil gegenüber reinen In-Context-Ansätzen.

Die Kombination aus Context Caching für stabile Kontextblöcke, Memory Bank und Sessions in Agent Engine für Nutzer-/Session-Historie sowie Grounding über Vertex AI Search für aktuelle Daten ergibt eine dreischichtige Kontext-Architektur. Wer in ERP/CRM-Szenarien alle drei sauber aufsetzt, reduziert Latenz, spart Token-Kosten und liefert trotzdem präzise Antworten auf Basis aktueller Daten.

Observability und Audit: Was Agent Engine liefert – und was noch fehlt

Agent Engine bringt integrierte Evaluation, Cloud Trace, Cloud Monitoring und Logging. Tool-Call-Fehler, Policy-Verletzungen, Latenzen – das alles ist observierbar. Für ERP-/CRM-Integrationen mit SOX-, DSGVO- oder BaFin-Relevanz ist ein vollständiger Audit-Trail keine Kür, sondern Pflicht.

Die harte Wahrheit dabei: Observability ist vorhanden, aber kein Compliance-Framework ist vorinstalliert. Wer einen vollständigen Audit-Trail für regulierte Finanzprozesse braucht, muss selbst definieren, welche Tool-Calls geloggt werden, wie lange Logs aufbewahrt werden und wie Anomalien eskaliert werden. Agent Engine liefert die Infrastruktur, nicht die Compliance-Strategie. Das ist kein Mangel – aber eine Erwartungshaltung, die korrigiert werden muss.

Ich halte das für den zentralen Blindspot in der aktuellen Debatte um Agentic AI im Enterprise: Plattformen wie Agent Engine machen es einfacher, Agenten zu deployen. Die eigentliche Governance-Arbeit – wer darf was, wann, unter welchen Bedingungen, mit welchem Logging – ist nach wie vor Architektur- und Organisationsarbeit. Kein Managed Service nimmt das ab.

Gegenargument: Ist die verteilte Governance ein struktureller Nachteil?

Ein berechtigter Einwand gegen das Google-Modell: Wenn Governance auf so viele Schichten verteilt ist – Apigee, IAM, ADK-Tool-Definitionen, Secure Code Sandbox –, steigt die Komplexität der Gesamtkonfiguration erheblich. Wer Regeln an fünf verschiedenen Stellen pflegt, riskiert Inkonsistenzen. Eine Apigee-Policy, die Datenmaskierung erzwingt, nützt wenig, wenn dieselben Rohdaten über einen unsauber konfigurierten IAM-Service-Account direkt erreichbar sind.

Das ist kein hypothetisches Problem. In Enterprise-Umgebungen, in denen verschiedene Teams für Apigee-Management, IAM-Administration und ADK-Entwicklung zuständig sind, entstehen Governance-Lücken oft genau an den Übergabepunkten zwischen Teams. Wer Vertex AI Agent Engine einführt, sollte deshalb früh klären, wer die Gesamtverantwortung für die End-to-End-Governance trägt – und wie Änderungen an einer Schicht mit den anderen abgestimmt werden.

Das Gegenargument zu diesem Gegenargument: Monolithische Policy-Systeme haben eigene Schwächen. Sie sind oft weniger flexibel, entwickeln sich langsamer weiter und zwingen alle Anwendungsfälle in dasselbe Regelmodell. Die verteilte Governance von Agent Engine ist letztlich die klassische Microservices-Logik auf die Policy-Ebene übertragen – mit allen Vor- und Nachteilen dieses Architekturprinzips.

GA-Status: Was „allgemein verfügbar“ wirklich bedeutet

Google Cloud gibt am 3. Juni 2026 die allgemeine Verfügbarkeit bekannt. Das ist ein wichtiges Signal. Aber: GA der Plattform bedeutet nicht, dass jedes einzelne Feature GA-Status hat. Einzelne Komponenten können sich weiterhin in Preview oder Private Preview befinden. Für Enterprise-Teams, die kritische ERP-Workflows durch Agenten orchestrieren wollen, gilt: vor dem Rollout im offiziellen Cloud Release Channel prüfen, ob das konkret benötigte Feature GA, Preview oder Experimental ist. SLAs gelten in der Regel nur für GA-Features.

Das klingt bürokratisch. Ist aber bei Plattformen wie Vertex AI Agent Engine essenziell. Wer einen Finance-Agenten in Produktion bringt, der auf Zahlungsfreigaben zugreift, und dabei auf ein Preview-Feature setzt, das morgen die API bricht, hat ein Problem – unabhängig davon, wie gut der Rest der Architektur ist. Einen guten Überblick über die Erwartungslücken bei KI-Agenten im Enterprise-Einsatz liefert IBMs Analyse zu AI Agents: Expectations vs. Reality.

Was das für Enterprise-Teams bedeutet – konkret

Drei Handlungsschritte für Teams, die jetzt evaluieren:

1. Tool-Inventar anlegen. Bevor ein einziger Agent deployed wird: welche ERP/CRM-APIs existieren, welche sind über Apigee oder MCP zugänglich, welche brauchen Datenmaskierung? Cloud API Registry strukturieren, bevor Agent Engine zum Einsatz kommt. Der Werkzeug-Katalog ist das Fundament der Governance.
2. Context-Strategie definieren. Welche Kontextblöcke sind stabil genug für Context Caching – Produktkataloge, Policy-Texte, Vertragsstrukturen? Was ist dynamisch genug, um über Vertex AI Search gegrounded zu werden? Diese Entscheidung wirkt direkt über Token-Kosten und Latenz.
3. Compliance-Anforderungen vor dem Deployment kodieren. SoD-Regeln, Datenmaskierung, Logging-Pflichten: nicht nach dem Deployment nachrüsten. IAM-Rollen, Apigee-Policies, ADK-Tool-Definitionen sind die Orte, an denen diese Regeln entstehen. Dokumentation gehört dazu – und eine klare Zuständigkeitsmatrix zwischen den beteiligten Teams.

Was bleibt, wenn man die GA-Ankündigung nüchtern bewertet: Vertex AI Agent Engine ist kein fertiges ERP-KI-Paket, das man einschaltet. Es ist eine ernsthafte Infrastruktur-Plattform für Teams, die bereit sind, die Governance-Arbeit selbst zu leisten. Die Frage ist nicht, ob die Plattform mächtig genug ist. Die Frage ist: Ist Ihr Team organisatorisch bereit, mit dieser Mächtigkeit verantwortungsvoll umzugehen?