Was der Gemini Agent im Unternehmen tun soll und wo Googles Angaben enden

Der Gemini Agent soll Ziele bekommen statt Einzelanweisungen. Google Cloud formuliert das so: „You give it objectives, not instructions.“ Gemeint ist, dass Sie ein Ergebnis delegieren und später fertige Arbeit abholen, statt jeden Schritt per Prompt anzustoßen. Am 8. Oktober 2026 hat Google Cloud den Agenten als einen einzelnen, universellen Agenten für die Arbeit vorgestellt. Laut Google plant er die Aufgabe, nutzt Skills und Tools, verbindet sich mit Unternehmenssystemen und liefert das Ergebnis dort ab, wo Sie ohnehin arbeiten: in Dokumenten, im Postfach, in Entwicklungsumgebungen.

Das klingt nach dem Ende des Chatfensters. Ob es das ist, entscheidet sich nicht in der Keynote. Die Beschreibung der Funktionen stammt überwiegend vom Hersteller, und das gilt auch für die Kundenzahlen in der Ankündigung; unabhängig geprüft sind sie nicht. Als Gegenlicht dienen die Berichterstattung von TechCrunch und die Empfehlungen von IBM, wobei IBM selbst Produkte für Agenten anbietet und entsprechend einzuordnen ist. Remy, ein in unserem Archiv beschriebenes, intern getestetes und von Google nicht bestätigtes Projekt für den persönlichen Alltag, ist davon zu trennen. Hier geht es um den angekündigten Unternehmensagenten.

Für Ihren Betrieb zählen zwei Fragen. Welche Aufgabe wird durch einen Agenten tatsächlich besser, der über Stunden eigenständig arbeitet, statt nur eine Antwort zu liefern? Und was bleibt zwangsläufig bei Ihnen: Verantwortung, Freigaben, Zuordnung von Handlungen zu Personen? Die zweite Frage beantwortet kein Anbieter für Sie. Im abgerufenen Teil der Ankündigung fehlen Angaben zu Verfügbarkeit, Preisen und Lizenzen, dazu lässt sich hier nichts sagen.

Was sich gegenüber dem Chatfenster ändert

Der Unterschied zum Chatfenster beginnt bei der Laufzeit. Laut Google läuft der Agent in der Cloud. Arbeit, die Stunden oder Tage dauert, läuft demnach weiter, auch wenn Sie den Laptop schließen. Das ist eine Herstellerangabe, und sie beschreibt eine Architektur, keine Ergebnisqualität. Betrieblich heißt das: Ein Auftrag endet nicht mehr mit dem Arbeitstag der Person, die ihn erteilt hat. Wer ihn beaufsichtigt, muss deshalb geregelt sein, bevor der erste lange Auftrag startet.

Dazu kommt die Struktur im Hintergrund. Google beschreibt, dass der Agent bei mehrstufigen Aufgaben dynamisch Sub-Agenten anlegen kann, temporäre, auf einen Job zugeschnittene Helfer, jeder mit eigener Identität. Davon unterscheidet Google den Coworker-Agenten, der eher ein Teammitglied sein soll: mit dauerhafter, definierter Rolle, eigener E-Mail-Adresse und eigenem Speicher. Dieser Coworker-Agent sieht nach Googles Darstellung nur den Kontext, den Sie oder Ihr Team ihm geben. Für Ihre Inventur bedeutet das, dass womöglich nicht nur ein Agent zu erfassen ist, sondern mehrere Identitäten pro Auftrag.

Einordnen lässt sich das Ganze gegenüber der Gemini Enterprise Agent Platform, die Google im April auf der Cloud Next vorgestellt hat, als Infrastruktur, mit der Unternehmen eigene Agenten bauen, verwalten und überwachen. Zum Gemini Agent sagt Google, dass er Ziele entgegennimmt und in Unternehmenssystemen und Arbeitsumgebungen handelt. Ob und wie beide technisch ineinandergreifen, geben die vorliegenden Angaben nicht her; dazu sollten Sie den Anbieter befragen.

Auffällig ist die Reihenfolge. TechCrunch berichtet, Google bringe den Agenten zunächst zu Unternehmen und erst später zu Verbrauchern. Sundar Pichai begründet das laut TechCrunch damit, dass sich so die „harder problems around security, scale, and performance“ lösen ließen. Er nennt Sicherheit, Skalierung und Leistung also als die schwierigeren Probleme.

Welche Systeme der Agent erreicht

Google nennt für den Gemini Agent eine lange Liste von Anbindungen: Confluence, Microsoft Office, Teams, Slack, Git, Jira, Salesforce, ServiceNow, BigQuery, Databricks, Postgres und Snowflake. Dazu kommen beliebige MCP-Server, also Anbindungen nach dem Model Context Protocol, innerhalb oder außerhalb des Firmennetzes. Das ist die Herstellerangabe. Wie tief die einzelnen Verbindungen reichen, ob lesend oder schreibend, steht im abgerufenen Text nicht.

Die Liste liest sich wie eine Kompetenzbeschreibung, ist für Sie aber zunächst eine Inventurfrage. Jede genannte Plattform hält Daten, die ein Agent erreichen könnte: Tickets in Jira und ServiceNow, Kundendaten in Salesforce, Code in Git, Auswertungen in Snowflake oder BigQuery. Wer den Agenten einführt, sollte vorab für jedes System festhalten, welche Daten dort liegen und welche davon überhaupt in die Reichweite eines Agenten gehören. Das ist eine Empfehlung, keine Vorgabe aus Googles Text.

Am wenigsten greifbar sind die MCP-Server. Sie erlauben Google zufolge Verbindungen auch außerhalb des eigenen Netzes. Ein MCP-Server ist schnell aufgesetzt, und oft wissen nur einzelne Teams davon. Bevor Sie einen Agenten darauf loslassen, brauchen Sie eine Übersicht: Welche Server existieren, wer betreibt sie, welche Daten laufen darüber? Was nicht inventarisiert ist, kann niemand freigeben oder sperren.

Hinzu kommt die Modellwahl. Laut Google orchestriert der Agent Gemini-Modelle und Claude-Modelle von Anthropic, weitere private und offene Modelle sollen später folgen. Standardmäßig wählt der Agent je Aufgabe das passende Modell; laut TechCrunch können Nutzer die Wahl auch selbst übernehmen. Was das für den Weg Ihrer Daten bedeutet, sagen die Quellen nicht. Fragen Sie den Anbieter deshalb konkret: Welche Inhalte gehen an welches Modell, und lassen sich die verfügbaren Modelle administrativ begrenzen? Davon hängt ab, ob Ihre Datenschutz- und Compliance-Bewertung für ein Modell auch für alle anderen gilt.

Identität und Audit-Trail: Der Agent ist nicht der Nutzer

Wenn ein Agent eine E-Mail schreibt, ein Dokument ändert oder einen Termin setzt, stellt sich im Nachhinein eine banale Frage: Wer war das? Bei einem Coworker-Agenten lautet die Antwort ausdrücklich nicht „der Nutzer“. Google beschreibt, dass dieser ein eigenes Workspace-Konto erhält, samt E-Mail-Adresse, Kalender, Drive und Eintrag im Firmenverzeichnis. Er handelt laut Google unter eigener Identität statt unter der des Auftraggebers und sieht nur, was ihm freigegeben wird. Wird er etwa in einem Dokumentkommentar angesprochen und schlägt eine Änderung vor, erscheint er in der Versionshistorie unter eigenem Namen.

Ob dieser Zugriffsschutz in Ihrem Setup greift, sollten Sie selbst prüfen, etwa mit einem Test, bei dem Sie dem Agenten bewusst nichts freigeben.

Die Kehrseite steht bei TechCrunch: Handelt der Agent, schreibt er einen Audit-Trail, der ihm und nicht einer Person zugeordnet wird. Ob der Auftraggeber zusätzlich erfasst wird, nennt die Quelle nicht und ist beim Anbieter zu klären. Wer ihn beauftragt hat und wer für das Ergebnis geradesteht, sollten Sie deshalb organisatorisch festhalten. Naheliegend wäre, jedem Agenten einen benannten Verantwortlichen zuzuweisen und das Verzeichnis entsprechend zu pflegen. Das ist eine Empfehlung, keine Funktion, die Google in den vorliegenden Angaben beschreibt.

Und selbst ein lückenloser Trail ersetzt keine Prüfregel. Ein Protokoll beantwortet, was geschah, nicht, ob es in Ordnung war. Das zeigt sich schon bei Gemini Notebook: Dort bleibt trotz Audit-Logs für Gemini Notebook die Frage, welche Ereignisse Folgen haben und wer sie auswertet, bei den Organisationen. Dieselbe Frage stellt sich beim Agenten. Legen Sie vorab fest, wer die Einträge liest, nach welchen Kriterien und mit welcher Befugnis, bei Auffälligkeiten einzugreifen.

Branchenpakete, Berichte und Kosten

Bei den Branchenpaketen ist Googles Beschreibung konkret, bezieht sich aber auf Gemini insgesamt, nicht ausdrücklich auf den Agenten: Laut Google Cloud ist die Branchenspezialisierung in der Preview für Financial Services und Legal, Government, Healthcare und Retail sollen bald folgen. Wer in einer der drei nachgereichten Branchen arbeitet, plant also vorerst mit einer Ankündigung, nicht mit einem Produkt. Einen Termin nennt die Quelle nicht.

Am konkretesten wird Google im Rechtsbereich. Gemini übernehme dort matter-level Berechtigungen und ethische Wände direkt aus Dokumentenmanagementsystemen wie NetDocuments und iManage. Das ist für Kanzleien und Rechtsabteilungen die entscheidende Frage, denn eine KI, die Mandatsgrenzen nicht kennt, wäre unbrauchbar. Beachten Sie die Formulierung: Das ist eine Herstellerangabe. Ob die Übernahme in Ihrer Konstellation lückenlos greift, etwa bei Mandaten mit besonderen Sperren, lässt sich nur im eigenen Setup prüfen, am besten mit einem Testmandat und einem Konto ohne Berechtigung.

Auch bei den Berichten beschreibt Google einen praktischen Mechanismus. Der Agent nutzt Operational-Reporting-Skills mit BigQuery und Knowledge Catalog, baut die Abfrage und speichert sie. Gespeicherte Berichte lassen sich laut Google danach auf Abruf ausführen, ohne dass Token-Kosten anfallen. Das ist ein betrieblicher Hebel: Wiederkehrende Auswertungen wie Wochenzahlen müssen nicht jedes Mal neu durch ein Modell laufen. Offen bleibt, wer die gespeicherte Abfrage fachlich abnimmt, bevor sie als verlässlich gilt.

Zur Kostenkontrolle nennt Google Multi-Model-Orchestrierung, Smart Routing und Ausgabenlimits in Echtzeit. Preise, Lizenzen oder Limits finden sich im abgerufenen Teil der Quelle nicht. Eine Budgetplanung lässt sich darauf nicht stützen; sie beginnt mit der Frage an den Anbieter, welche Limits Sie selbst setzen können und was bei Erreichen passiert.

Auch die Kundenzahlen sollten Sie mit Vorsicht lesen. Google berichtet, Bradesco habe mit Gemini Enterprise die Prüfzeit für Dokumente von 1 Stunde auf 5 Minuten gesenkt. Das ist eine Angabe aus Googles eigener Kommunikation, unabhängig geprüft ist sie nicht, und sie bezieht sich auf Gemini Enterprise, nicht auf den Gemini Agent. Für Ihr Vorhaben sagt sie deshalb nichts über den Agenten aus.

Was Sie vor dem Einsatz selbst klären müssen

Eine Quelle brauchen Sie vor dem Einsatz mit richtiger Einordnung. Der IBM-Beitrag vom 12. Oktober 2026 stammt von Autoren aus dem Produktmarketing von watsonx Orchestrate. IBM verkauft also ein eigenes Produkt für genau dieses Problem. Die Empfehlungen taugen trotzdem als Checkliste für die Vorbereitung, weil sie sich auf jeden Agenten übertragen lassen. Über Googles Produkt sagen sie nichts aus.

Erstens: Verantwortung benennen. IBM empfiehlt je einen Geschäftsverantwortlichen für das Ergebnis und einen Betriebsverantwortlichen für den einzelnen Agenten. Die Fachabteilung definiert, was ein akzeptables Resultat ist; die IT legt Integrations- und Betriebsstandards fest. Bei Aktionen mit größerer Wirkung können laut IBM menschliche Freigaben nötig sein. Welche Aktionen bei Ihnen dazugehören, entscheiden Sie vorab, nicht erst nach dem ersten Vorfall.

Zweitens: den Notfall regeln. Legen Sie fest, wer einen auffälligen Agenten einschränken, pausieren oder auf eine frühere Version zurücksetzen darf. IBM betont, dass diese Zuständigkeiten stehen sollten, bevor der Agent in einem kritischen Workflow steckt. Danach ist es zu spät für Grundsatzdiskussionen.

Drittens: klein anfangen. Wählen Sie einen einzigen Workflow mit klarem Verantwortlichen, messbarem Ergebnis und überschaubarem Umfang. Das ist unspektakulär, aber es zwingt zu einer Frage, die Pilotprojekte gern umgehen: Woran erkennen Sie, dass der Agent die Aufgabe tatsächlich besser erledigt?

Eine Lücke bleibt, und die kann keine Checkliste schließen. Die Quellen beschreiben nicht, welche Aktionen der Gemini Agent ohne menschliche Freigabe ausführt und ob sich Freigaben konfigurieren lassen. Das ist keine Entwarnung und kein Alarm, sondern eine offene Frage. Klären Sie sie vor dem Einsatz mit Google, und lassen Sie sich die Antwort schriftlich geben. Erst dann wissen Sie, ob Ihre Freigaberegeln im Produkt abbildbar sind oder ob Sie sie organisatorisch um das Produkt herum bauen müssen.