Gemini wird zum Agenten für Unternehmen: Hyperscaler-Plattform oder eigener Agent-Stack?

/01Was Google am 8. Oktober angekündigt hat

Am 8. Oktober 2026 hat Google Cloud auf der Veranstaltung „Gemini at Work 2026" den „Gemini agent" vorgestellt. Thomas Kurian, CEO von Google Cloud, beschreibt ihn im Blogbeitrag als „a single, universal agent for work": ein Agent, der Fragen beantwortet, Wissensarbeit erledigt, Bilder und Medien erzeugt, Code schreibt und ausführt – und dabei den Geschäftskontext der Organisation hält, Arbeit plant, Werkzeuge nutzt, sich mit Geschäftssystemen verbindet und das Ergebnis dort abliefert, wo die Leute ohnehin arbeiten. Gegenüber TechCrunch fasste Kurian das Prinzip so zusammen: Der Agent bekommt „Ziele, nicht nur Anweisungen". Zum Start ist das Angebot laut TechCrunch auf Unternehmen beschränkt; frühe Tester sind On, Shopify und PayPal.

Die Reichweite ist der Kern der Ankündigung. Der Agent ist laut Blog erreichbar über Web, iOS, Android, Windows, Mac, Kommandozeile, Google Workspace, Microsoft 365 und Slack, und er läuft auch ohne Oberfläche („headless"). Als Konnektoren nennt Google unter anderem Gmail, Drive, Docs, Confluence, Microsoft Office und Teams, Git, Jira, Salesforce, ServiceNow, SAP, Workday, BigQuery, Databricks, Postgres, Snowflake, Amazon S3, Azure Data Lake – und MCP-Server. Unter dem Agenten sitzt ein Modellrouting: Argon für anspruchsvolles Schließen, Flash für Volumen, Omni für Medien, Gemma für Edge und offene Gewichte; als Drittmodell ist Claude von Anthropic eingebunden, „andere führende private und offene Modelle" sollen folgen. Ein „Smart Routing" verteilt Aufgaben nach Kosten und Leistung.

Das Modell dahinter ist Gemini 4 Argon, angekündigt am 30. September 2026 als Frontier-Modell für „real-world coding, enterprise knowledge work, and cyber defense". Zwei Zahlen aus der Ankündigung sind für Agentenarbeit entscheidend: Die Ausgabegrenze steigt auf 1 Million Tokens (von 64.000 bei den Gemini-3-Modellen), und der Einführungspreis liegt bei 2 $ je Million Eingabe- und 10 $ je Million Ausgabe-Token, nach der Einführungsphase 4 $ und 20 $, mit 95 Prozent Nachlass auf gecachte Eingaben. Zunächst erhalten „vertrauenswürdige Cyber-Verteidiger" im Fairwind-Programm Zugang; API-Kunden und AI-Ultra-Abonnenten sollen folgen, ein Datum nennt Google nicht.

Zur Governance nennt der Blog, was ein IT-Leiter hören will: eine kryptografisch bestätigte Identität je Agent mit minimalen Rechten, Abbildung auf OAuth für Fremdsysteme, ein Audit-Trail, in dem Handlungen dem Agenten zugeordnet sind, eine „Agent Sandbox" mit Netzwerkgrenze, ein „Agent Gateway" als Richtlinienfilter für alle Agenten, Ausgabenobergrenzen je Projekt. Und zwei Sätze zur Datenhaltung: „Your data do not need to move" und „Your proprietary inputs and outputs remain entirely your own". Zahlen zur Verbreitung liefert Google gleich mit: Rund 90 Prozent der Fortune-100-Unternehmen nutzten Gemini Enterprise, fast 500 Google-Cloud-Kunden hätten im vergangenen Jahr je mehr als eine Billion Token verarbeitet. Das sind Herstellerangaben; sie stehen hier, weil sie die Größenordnung zeigen, in der diese Plattform gedacht ist.

/02Was die Hyperscaler-Plattformen gemeinsam haben

Google ist nicht allein, und das ist wichtig für die Einordnung: Es geht nicht um ein Produkt, sondern um eine Architektur, die vier Anbieter gleichzeitig bauen.

Microsoft positioniert Copilot Studio (Dokumentationsstand 25. September 2026) als „graphical, low-code studio for building and managing AI-powered agents and workflows". Agenten laufen auf wählbaren „Harnesses" – unter anderem einem „GitHub Copilot harness" für mehrstufige Aufgaben –, verbinden sich über Konnektoren mit Daten und Systemen und können laut Dokumentation ein eigenes Konto bekommen, um „proaktiv" an Aufgaben zu arbeiten. OpenAI bietet eine von OpenAI betriebene Agents API mit Codex-Harness und ein Agents SDK, das in der eigenen Anwendung läuft, beides mit MCP-Unterstützung. Anthropic stellt das Claude Agent SDK für Python und TypeScript bereit – mit MCP, Hooks und Berechtigungssteuerung – und „Managed Agents", deren Sitzungen in einer von Anthropic verwalteten Sandbox oder in einer selbst gehosteten Sandbox auf eigener Infrastruktur laufen.

Das gemeinsame Muster: Der Hersteller stellt die Orchestrierung, die Identitäten, die Konnektoren und das Modell; der Kunde bringt Ziele, Daten und Freigaben. Das ist schnell, weil nichts gebaut werden muss, und integriert, weil der Hersteller die Systeme kennt, die der Kunde ohnehin nutzt. Es ist zugleich die engste Kopplung, die Unternehmens-IT in den letzten zehn Jahren eingegangen ist – enger als Cloud-Speicher, weil der Agent nicht Daten hält, sondern handelt.

/03Was ein eigener Agent-Stack ist – und was er nicht ist

Ein eigener Agent-Stack besteht aus denselben vier Schichten, nur in Ihrer Hand: ein Sprachmodell mit Function Calling, das auf eigener Hardware läuft – etwa ein Qwen-Modell der 27B-Klasse unter vLLM; eine Agentenschleife, die plant, Werkzeuge aufruft und Ergebnisse bewertet (ein Framework wie LangGraph oder eigener Code – der Framework-Vergleich ordnet die Optionen); MCP-Server als Werkzeugschicht, die ERP, CRM, Dateiablage und Datenbanken nach einem offenen Protokoll anbinden; und ein Audit-Protokoll, das jeden Werkzeugaufruf mit Agentenidentität, Parametern und Ergebnis festhält.

MCP ist dabei nicht nur eine Google-Zutat, sondern der Punkt, an dem beide Welten sich berühren. Die aktuelle Spezifikation (Stand 28. Juli 2026) definiert über JSON-RPC 2.0 drei Serverangebote – Tools, Resources, Prompts –, dazu Elicitation (Rückfragen des Servers an den Nutzer) und Erweiterungen wie Tasks für langlaufende Vorgänge. Ihre Sicherheitsprinzipien sind unmissverständlich: Hosts „must obtain explicit user consent before invoking any tool", Werkzeugbeschreibungen sind „untrusted, unless obtained from a trusted server" – und: „MCP itself cannot enforce these security principles at the protocol level." Das heißt: Wer den Host betreibt, trägt die Durchsetzung. Bei der Hyperscaler-Plattform ist das der Hersteller, beim eigenen Stack sind Sie es.

Der Server selbst ist überschaubar. Wie ein MCP-Server für ein internes System gebaut und abgesichert wird, steht im MCP-Tutorial; die Modellseite ist mit vLLM eine Zeile:

# Modell mit Werkzeugaufrufen über die OpenAI-kompatible API bereitstellen
vllm serve /models/qwen3-27b@2026-10 \
  --served-model-name agent-modell \
  --enable-auto-tool-choice --tool-call-parser hermes \
  --max-model-len 65536 --port 8000

# Agentenschleife: Modell + MCP-Server + Protokoll (Ausschnitt aus der Konfiguration)
{"model": "http://vllm01:8000/v1/agent-modell",
 "mcp_servers": {"erp": {"url": "http://mcp-erp:8080/mcp", "allow": ["lese_auftrag", "lese_bestand"]},
                 "crm": {"url": "http://mcp-crm:8080/mcp", "allow": ["lese_kunde"]}},
 "approval_required": ["schreibe_*", "sende_*"],
 "audit": {"sink": "https://audit.intern/agent", "fields": ["agent_id", "tool", "args_hash", "result_hash"]}}

Was der eigene Stack nicht ist: fertig. Es gibt keinen Konnektor zu Workday, der am ersten Tag funktioniert, keine Postfachintegration, die Threads versteht, keinen Medien-Generator. Jede Anbindung ist ein MCP-Server, den jemand schreibt oder aus der Community bezieht und prüft. Die Agentic AI-Fähigkeiten offener 27B-Modelle bei mehrstufigen Aufgaben liegen unter denen der Frontier-Modelle; wo die Grenze verläuft, muss ein Golden-Set mit Ihren Aufgaben zeigen, nicht ein Benchmark. Und der Betrieb – Modellwechsel, Protokollauswertung, Sandbox, Patches – ist Ihr Betrieb.

/04Sechs Kriterien im Vergleich

Die Tabelle stellt beide Architekturen nebeneinander. Sie bewertet nicht Google, sondern die Eigenschaften, die sich aus der Architektur ergeben – bei Microsoft, OpenAI und Anthropic in derselben Form.

/05Datenhoheit und Identitäten: wo der Lock-in wirklich sitzt

Die Datenhoheit ist das Kriterium, das in jeder Diskussion zuerst fällt – und das am wenigsten trennscharf ist. Google sagt in der Dokumentation zu Gemini für Google Cloud: „Gemini doesn't use your prompts or its responses as data to train its models", die Verarbeitung erfolgt nach Nutzungsbedingungen und Cloud Data Processing Addendum, Prompts sind in Transit verschlüsselt. Das ist eine belastbare vertragliche Zusage, und für viele Datenklassen reicht sie. Ob sie reicht, ist keine technische, sondern eine Frage des Datenschutzrechts und der Vertraulichkeitsstufe – inklusive der Frage, welchem Recht der Anbieter unterliegt; der Artikel zum CLOUD Act führt das aus.

Der härtere Lock-in sitzt woanders: bei Identitäten und Konnektoren. Googles Konzept – jeder Agent hat eine eigene, kryptografisch bestätigte Identität, Handlungen werden ihm zugerechnet, „coworker agents" bekommen laut Blog E-Mail-Adressen unter @agents.company.com – ist aus Sicherheitssicht richtig. Es bedeutet aber, dass ein Teil Ihrer Belegschaft in einem Verzeichnis existiert, das dem Hersteller gehört, mit Rechten in Ihren Systemen, die über dessen OAuth-Abbildung vergeben werden. Wer die Plattform verlässt, verliert nicht Daten – die liegen, wie Google richtig sagt, weiterhin bei Ihnen –, sondern die Rechtebeziehungen, die Erinnerungen der Agenten, die Konnektorkonfiguration und das Audit-Protokoll in dessen Format. Welche Konzepte für nicht-menschliche Identitäten es jenseits einzelner Hersteller gibt, steht im Artikel zur Agenten-Identität.

Im eigenen Stack sind Identitäten Einträge im eigenen Verzeichnis, Rechte sind Allowlists je MCP-Server, das Protokoll ist eine Tabelle in Ihrer Datenbank. Das ist weniger komfortabel und mehr Arbeit – und es ist der einzige Zustand, in dem ein Prüfer in drei Jahren fragen kann, warum Agent 17 am 3. März eine Bestellung ausgelöst hat, und Sie die Antwort aus eigenen Systemen geben. Die Sicherheitsrisiken sind in beiden Welten dieselben: Prompt Injection über Werkzeugergebnisse, überweite Rechte, fehlende Human-in-the-Loop-Stufen vor irreversiblen Schritten. Die OWASP Agentic Top 10 gelten für den Gemini agent wie für Ihren eigenen; der Unterschied ist, wer die Guardrails konfiguriert und wer sieht, ob sie gegriffen haben.

/06Kosten je Lauf: eine Rechnung mit offenen Annahmen

Agenten verbrauchen mehr Token als Chats, weil jede Werkzeugantwort in das Kontextfenster zurückfließt und das Modell mehrfach plant. Googles 1-Million-Token-Ausgabegrenze für Argon ist dafür gebaut – „so a single trajectory can generate hundreds of thousands of tokens of reasoning and code", wie Google schreibt. Das ist eine Fähigkeit und eine Kostenstelle zugleich.

Ein Beispielszenario mit eigenen Annahmen: Ein Agent prüft Eingangsrechnungen gegen Bestellungen. Je Lauf liest er 150.000 Eingabe-Token (Rechnung, Bestellung, Lieferschein, Richtlinie, Zwischenergebnisse) und erzeugt 15.000 Ausgabe-Token (Planung, Werkzeugaufrufe, Begründung). Mit Argons Einführungspreis sind das 0,30 $ + 0,15 $ = 0,45 $ je Lauf, nach der Einführungsphase 0,90 $. Bei 20.000 Rechnungen im Monat: 9.000 $ beziehungsweise 18.000 $ monatlich für das Modell – vor Plattformlizenz, vor Konnektoren, vor dem Nachlass für gecachte Eingaben, der die Zahl deutlich senken kann, wenn Richtlinie und Bestelldaten stabil bleiben. Die Annahmen sind frei gewählt; setzen Sie Ihre ein.

Auf der anderen Seite steht Hardware mit festen Kosten. Unsere Referenzrechnung für ein A100-System kommt auf rund 55.000 € über 36 Monate (Hardware, Setup, Strom und Hosting, Support) gegenüber rund 108.000 € Cloud-API bei 100.000 Anfragen im Monat, Break-even nach rund 18 Monaten – gerechnet für Chat-Anfragen, nicht für Agentenläufe. Für Agenten verschiebt sich die Rechnung in beide Richtungen: Mehr Token je Lauf sprechen für feste Kosten; die Frage, ob ein 27B-Modell die Aufgabe überhaupt in der geforderten Qualität löst, spricht dafür, das vorher zu messen. Ein ki·spezial System mit 192 GB VRAM im Vollausbau schafft mit Qwen3 27B gemessen 3.900 Token/s – ob das Ihre 20.000 Läufe trägt, hängt davon ab, wie viele davon gleichzeitig kommen. Belastbar ist nur eine Messung mit Ihrem Aufgaben-Mix.

/07Hybride ehrlich benennen: Postfach dort, ERP hier

In der Praxis entscheidet kaum ein Haus für eine Seite. Die Postfächer liegen bei Microsoft oder Google, die Produktionsdaten im ERP auf eigenen Servern, die Konstruktionsdaten in einem PLM, das niemand ins Internet stellt. Der sinnvolle Schnitt verläuft entlang der Daten, nicht entlang der Technik.

Hyperscaler-Agent für das, was ohnehin dort liegt. Mails sortieren, Termine koordinieren, Besprechungen zusammenfassen, Dokumente aus Drive oder SharePoint aufbereiten: Diese Daten sind bereits in der Plattform des Herstellers, und der Agent dort ist für sie gebaut. Ein eigener Agent, der sich über IMAP in ein Microsoft-365-Postfach einklinkt, ist technisch möglich und organisatorisch unsinnig.

Eigener Agent für Kernsysteme und schützenswerte Daten. Bestellungen auslösen, Lagerbestände umbuchen, Konstruktionsdaten lesen, Personaldaten verarbeiten, Angebote aus Kalkulationsdaten erstellen: Hier handelt der Agent mit Schreibrechten in Systemen, deren Ausfall oder Fehlbuchung Geld kostet, und mit Daten, deren Abfluss nicht zu heilen ist. Diese Agenten gehören On-Premise, mit eigenen Identitäten und eigenem Protokoll.

Die Naht ist MCP. Googles Agent kann MCP-Server aufrufen; Ihr eigener Agent-Stack besteht aus MCP-Servern. Ein MCP-Server vor dem ERP, der nur Leseoperationen für den Hyperscaler-Agenten freigibt und Schreiboperationen dem eigenen Agenten vorbehält, ist eine saubere Grenze: Der Postfach-Agent darf fragen, ob ein Auftrag existiert; buchen darf nur der Agent, dessen Protokoll bei Ihnen liegt. Dass die Werkzeugschicht in beiden Welten dasselbe Protokoll spricht, ist der eigentliche Fortschritt dieses Jahres – er macht den Hybrid zur Architektur statt zum Kompromiss. Welche Rolle MCP als Unternehmensstandard spielt, haben wir im Artikel zum MCP-Standard beschrieben.

/08Wann der eigene Stack die falsche Wahl ist

Ehrlich: Für die meisten Aufgaben, die 2026 mit Agenten erledigt werden, ist der eigene Stack die falsche Wahl – nicht weil er schlechter wäre, sondern weil der Aufwand zur Aufgabe nicht passt.

Wenn die Daten ohnehin beim Hyperscaler liegen und keine zusätzlichen Systeme angebunden werden, bringt ein eigener Stack keine Datenhoheit zurück, die Sie nicht schon abgegeben haben. Er kostet nur Zeit.

Wenn niemand ihn betreibt. Ein Agent-Stack braucht jemanden, der Modellstände pinnt, MCP-Server patcht, Protokolle liest und Freigaberegeln pflegt. In einem Haus ohne eigene IT-Betriebsmannschaft – oder ohne einen Dienstleister, der das übernimmt – verwaist er nach dem ersten Projekt. Dann ist der Hyperscaler-Agent mit seinen Standardkontrollen die sicherere Wahl, nicht die unsicherere.

Wenn die Aufgabe Frontier-Fähigkeiten verlangt. Mehrstufige Aufgaben über Dutzende Werkzeugaufrufe mit langen Zwischenergebnissen sind der Grund, warum Google die Ausgabegrenze auf eine Million Token hebt. Offene 27B-Modelle lösen viele Agentenaufgaben, aber nicht alle; wo Ihr Golden-Set zeigt, dass die Erfolgsquote nicht reicht, hilft kein Architekturargument. Der Hybrid – Frontier-Modell über ein Gateway für die schwierigen Schritte, lokales Modell für die Masse – ist dann die ehrliche Antwort.

Wenn der Zeithorizont kurz ist. Ein Pilot, der in drei Wochen zeigen soll, ob Agenten im Vertriebsinnendienst etwas bringen, gehört auf die Plattform, auf der er in drei Wochen läuft. Der eigene Stack ist eine Entscheidung für Jahre; wer noch nicht weiß, ob er Agenten will, sollte sie nicht treffen.

Und eine Grenze auf der anderen Seite: Die Sandbox- und Gateway-Konzepte, die Google beschreibt, lösen Probleme, die Sie im eigenen Stack selbst lösen müssen – Netzwerkgrenzen für Agenten, Richtlinienfilter vor jedem Werkzeugaufruf. Wie das On-Premise mit Firecracker, gVisor oder Containern aussieht, steht im Sandboxing-Artikel. Wer das nicht bauen will, sollte den eigenen Stack nicht bauen.

/09Entscheidung nach Datenklasse und Integrationsgrad

Zwei Fragen genügen für die Zuordnung: Welche Datenklasse berührt der Agent, und wie tief greift er in Systeme ein?

Lesend, Daten beim Hyperscaler (Mails, Kalender, Office-Dokumente, öffentliche Quellen): Hyperscaler-Agent. Prüfen Sie die Verarbeitungsbedingungen, setzen Sie Ausgabenobergrenzen, lassen Sie Konnektoren zu eigenen Systemen zunächst aus.

Lesend, Daten in eigenen Systemen (ERP-Auskunft, Lagerstand, Dokumentenrecherche per RAG): beides möglich. Ein MCP-Server mit Leserechten vor dem System kann beide Agenten bedienen; entscheiden Sie nach Vertraulichkeit. Kundendaten und Kalkulationen sprechen für den eigenen Agenten, Produktdokumentation nicht.

Schreibend in eigene Kernsysteme (Buchen, Bestellen, Freigeben, Personal): eigener Agent-Stack mit Freigabestufe vor jedem irreversiblen Schritt, eigener Identität, eigenem Protokoll. Das ist die Klasse, für die ein Multi-Agenten-System mit getrennten Rollen – Planer ohne Schreibrechte, Ausführer mit engem Werkzeugsatz – mehr bringt als ein universeller Agent. Hier zahlt sich der Aufwand aus, weil ein Fehler teurer ist als der Betrieb.

Schützenswerte Daten ohne Netzberührung (Konstruktion unter Geheimhaltung, Patientendaten, Verschlusssachen): eigener Stack, isoliert, ohne Cloud-Rückfallebene – auch wenn das Fähigkeiten kostet.

Für ein Haus ab 20 Mitarbeitern mit eigenem ERP ist die realistische Zielarchitektur ein Hybrid: Hyperscaler-Agent für die Büroarbeit, eigener Agent für zwei bis drei Kernprozesse, MCP als Grenze dazwischen, ein Gateway, das Frontier- und lokales Modell unter einem Alias führt. Die Reihenfolge: zuerst die MCP-Server mit Leserechten, weil sie beiden Seiten dienen; dann der erste eigene Agent für einen Prozess mit klarer Freigabestufe; erst danach die Frage, ob der Hyperscaler-Agent diese Server auch sehen darf. Ein Proof of Concept mit eigenen Daten auf unserer Hardware – 2 bis 4 Wochen, kostenlos – beantwortet vorab, ob ein offenes Modell den gewählten Prozess trägt, bevor jemand GPU-Hardware beschafft.

Das ist keine Formsache: Googles Ankündigung ist technisch überzeugend und organisatorisch verführerisch, weil sie das Schwierigste – Identitäten, Rechte, Protokoll – mitliefert. Genau deshalb sollte die Entscheidung, welche Agenten dort leben, bewusst fallen und nicht per Standardeinstellung. Ein Agent mit Schreibrechten im ERP ist kein Software-Abonnement. Er ist ein Mitarbeiter, und für Mitarbeiter führen Sie das Verzeichnis selbst.