Suchergebnisse für: „Google“

Am 15. September 2026 hat Google mehrere Drittanbieter-Connectors für Gemini in Google Workspace freigeschaltet. Wer Gemini for Google Workspace nutzt, kann aus dem Gemini-Panel heraus direkt mit Asana, Atlassian Rovo, HubSpot, Intuit Mailchimp, Intuit QuickBooks, Monday und Salesforce arbeiten, ohne das jeweilige System in einem weiteren Tab zu öffnen oder Dateien hin und her zu schieben. Klingt nach einem weiteren Punkt auf der Feature-Liste. Entscheidend ist etwas anderes: Die meisten Gemini-Projekte scheitern nicht am Modell, sondern daran, dass die Daten in einem anderen System liegen als das Werkzeug, mit dem man sie abfragt.

Warum MCP wie ein einheitlicher Schlüssel funktioniert

Wer schon einmal Daten zwischen zwei Fachanwendungen übertragen hat, kennt das Muster: Jedes System hat sein eigenes Schloss, seinen eigenen Schlüssel und seine eigene Vorstellung davon, was ein Datensatz ist. Der Ausweg war lange der Export. Man lud eine CSV-Datei herunter, klebte sie in ein Sheet und arbeitete mit einer Kopie, die beim nächsten Öffnen schon veraltet war. Nicht der Export kostet, sondern die Kopie. Ab diesem Moment gibt es zwei Wahrheiten im Unternehmen.

Das Model Context Protocol, kurz MCP, setzt woanders an. Es beschreibt standardisiert, wie ein Sprachmodell Werkzeuge und Datenquellen anspricht: welche Abfragen möglich sind, welche Parameter erwartet werden, welche Antwortstruktur zurückkommt. Statt für jede Anwendung eine eigene Anbindung zu bauen, gibt es einen gemeinsamen Schlüsselbart, der in viele Schlösser passt. Gemini öffnet damit die Tür zum jeweiligen System, ohne dass die Daten es verlassen müssen. Für Anwender heißt das: Die Antwort kommt aus der Quelle, nicht aus einem Zwischenspeicher.

Wichtig sind die Berechtigungen. Ein Connector ist kein Generalschlüssel für alle Räume. Er ist eine Verbindung, die man ein- und ausschalten kann und die nur zeigt, wozu der Nutzer ohnehin Zugang hätte. Hier kommt die Admin-Konsole ins Spiel.

Was die sieben Connectors zusammenführen

Die Auswahl ist kein Zufall. Sie deckt die vier Bereiche ab, in denen Arbeitsalltag stattfindet: Projektarbeit, Vertrieb und Marketing, Finanzen, Wissensmanagement. Asana und Monday liefern Aufgaben, Projektstände und Zuständigkeiten. Atlassian Rovo bringt Jira und Confluence mit, wo technische Teams Tickets und Dokumentation pflegen. Salesforce und HubSpot steuern die Kundensicht bei, von Kontakten über Opportunities bis zu laufenden Deals.

Intuit QuickBooks trägt die Finanzperspektive bei: Rechnungen, Ausgaben, Buchhaltungsstände. Intuit Mailchimp ergänzt Kampagnendaten und Zielgruppen aus dem Marketing. Zusammen ergibt das eine Landkarte, wo vorher sieben einzelne Karten lagen.

Ein Beispiel zeigt den Unterschied deutlicher als jede Feature-Beschreibung. Eine Umsatzübersicht soll in einem Sheet entstehen. Bisher: Salesforce öffnen, Report bauen, exportieren, einfügen, Formatierung reparieren — und im Meeting feststellen, dass die Zahlen sich längst geändert haben. Mit einem aktiven Connector lässt sich die Frage direkt dort stellen, wo die Tabelle entsteht. Die Antwort kommt aus Salesforce, der Kontext bleibt in Docs, Sheets oder Chat. Der Nutzen liegt weniger in gesparten Klicks als darin, dass niemand mehr eine veraltete Kopie weiterreicht.

Wie Admins die Connectors steuern

Für Administratoren ist ein anderer Satz in Googles Ankündigung entscheidend: Die Funktion ist standardmäßig aktiv. Wer nichts tut, hat sie an. Das ist bequem, verschiebt aber die Verantwortung in die Konfiguration.

Gesteuert wird das in der Admin-Konsole unter Apps, Google Workspace, Gemini for Workspace, Third-Party Connectors. Dort lässt sich festlegen, welche Connectors für die Organisation verfügbar sind, und es lassen sich Zugriffsrichtlinien pflegen. Die Ebenen sind Domain, organisatorische Einheit (OU) oder Gruppe. Das bildet unterschiedliche Realitäten ab: Die Buchhaltung braucht QuickBooks, vertriebsnahe Rollen brauchen Salesforce und HubSpot, das Produktteam Asana und Rovo. Eine pauschale Freigabe für die ganze Domain wäre technisch einfach und organisatorisch falsch.

Wer konfiguriert, sollte außerdem klären, welche Systeme als Datenquelle gelten und wer für deren Inhalte verantwortlich ist. Ein Connector macht eine schlecht gepflegte Datenquelle nicht besser, nur schneller sichtbar. Die Dokumentation in Google Workspace Admin Help beschreibt die Verwaltung im Detail. Lesenswert vor der Freigabe, nicht danach. Die Standardeinstellung ist ein Angebot, keine Empfehlung.

Was Endnutzer im Gemini Side Panel sehen

Für Anwender ist von der Konfiguration nichts zu sehen. Sie sehen das Gemini-Panel, das sie kennen, erweitert um die Systeme, die ihr Admin freigegeben hat. Der Zugriff läuft über das Side Panel in Docs, Sheets und Slides sowie über Google Chat. In Sheets lässt sich Gemini nach Werten fragen, die aus einem angebundenen System stammen, während die Tabelle geöffnet bleibt.

In Chat entsteht eine Variante, die für viele Teams praxisnäher ist als jedes Dokument. Eine Frage im Kanal, eine Antwort aus dem verbundenen System — alle sehen denselben Stand. Die Information wandert nicht mehr zum Werkzeug; das Werkzeug holt sie dort, wo sie liegt.

Die Erwartungen sollten trotzdem realistisch bleiben. Ein Connector ist eine Schnittstelle, kein vollständiges Datenmodell. Nicht jede Frage, die sich in Salesforce stellen lässt, lässt sich aus dem Gemini-Panel beantworten. Die Anbindung deckt definierte Abfragen ab, nicht die komplette Oberfläche des Fremdsystems. Wer Reports mit komplexer Logik, Berechtigungskaskaden oder Custom-Objekten braucht, arbeitet weiter im Fachsystem. Der Gewinn liegt bei den häufigen, einfachen Fragen, die bisher jedes Mal einen Kontextwechsel erforderten.

Rollout, Editions und der 15. September 2026

Die Funktion ist ab sofort verfügbar, für Rapid-Release- und Scheduled-Release-Domains. Der Unterschied ist bekannt: Rapid-Release-Domains bekommen Neuerungen zuerst und können sie meist nicht aufschieben, Scheduled-Release-Domains nach einer Vorlaufzeit. Diesmal entfällt die Wartezeit, die Standardaktivierung greift in beiden Umgebungen zum selben Zeitpunkt.

Verfügbar ist die Funktion in mehreren Editionsgruppen. Im Business-Bereich: Business, Standard und Plus. Im Enterprise-Bereich: Enterprise, Standard und Plus. Dazu Enterprise Essentials Plus sowie die Education-Editionen Google AI Pro for Education, Teaching and Learning und Endpoint Education. Auf der Consumer-Seite sind Google AI Pro und Ultra dabei. Die Funktion bleibt also nicht auf große Vertriebsorganisationen beschränkt, sondern erreicht auch Bildungseinrichtungen und kleinere Unternehmen — sofern die jeweilige Edition Gemini for Google Workspace enthält.

Für Teams, die Gemini bisher nur für Textarbeit in Docs genutzt haben, wächst die Einsatzbreite. Für Teams, die Gemini gar nicht nutzen, ändert sich vor allem eine Einstellung in der Admin-Konsole, von der sie womöglich nichts wussten.

Was das im Alltag bedeutet

Die technische Anbindung ist der einfache Teil. Der schwierige Teil beginnt danach, und er ist organisatorisch. Sobald Gemini auf sieben externe Systeme zugreifen kann, ist die Frage nach Datenqualität und Berechtigungspflege nicht mehr nur Sache der Fachabteilungen. Sie berührt auch, welche Auskunft ein Sprachassistent im Zweifel gibt und wie nachvollziehbar das bleibt.

Sinnvoll ist ein Vorgehen in drei Schritten. Erstens: eine bewusste Entscheidung pro Connector statt stiller Übernahme der Standardeinstellung. Zweitens: eine Zuordnung, welche Rollen welchen Zugang brauchen, abgebildet über Gruppen oder organisatorische Einheiten. Drittens: eine kurze Prüfung der Datenquellen, die angebunden werden. Ein Connector verstärkt bestehende Unordnung, statt sie zu beheben.

Der Fortschritt liegt nicht darin, dass Gemini mehr Systeme kennt. Er liegt darin, dass der Wechsel zwischen Werkzeugen seine Selbstverständlichkeit verliert. Wer zehnmal am Tag zwischen Tabellen und CRM springt, hält das für Arbeit. Es ist Kontextwechsel, und der verschwindet gerade leise, ohne dass jemand eine neue Oberfläche lernen muss.

Quelle: workspaceupdates.googleblog.com

Was bringt Googles neues Migrationstool für den Wechsel von Microsoft 365? Einen kürzeren Weg vom Abo-Abschluss bis zum ersten gefüllten Postfach. Das IT-Portal Petri berichtete im September 2026, dass Google einen Migrationsassistenten direkt in den Einrichtungsprozess von Google Workspace integriert hat. Administratoren können dort Benutzer und Geschäftsdaten aus einer Microsoft-Umgebung importieren, ohne zuvor ein separates Migrationsprojekt aufzusetzen.

Ein Umzug ist ein passendes Bild. Bisher mussten Unternehmen die Kisten selbst packen: Postfächer exportieren, Dateien umkopieren, Kalender neu aufbauen, Termine koordinieren, und für all das meist ein spezialisiertes Werkzeug oder einen Dienstleister buchen. Google stellt den Umzugswagen jetzt schon beim Einzug bereit, also in dem Moment, in dem ein neues Workspace-Konto ohnehin eingerichtet wird.

Für kleine Betriebe und Bildungseinrichtungen ist das eine Erleichterung. Für größere Organisationen bleibt es ein Werkzeug mit Grenzen. Zwei Dinge sind dabei zu trennen: die gesenkte Einstiegshürde und die technische Reichweite des Assistenten.

Was Google direkt in die Workspace-Einrichtung eingebaut hat

Neu ist vor allem der Einstiegspunkt. Statt eines Migrationstools, das Administratoren irgendwo in den Tiefen der Admin-Konsole suchen müssen, sitzt der Import dort, wo ein neues Konto ohnehin konfiguriert wird. Der Administrator verbindet den Microsoft-Tenant mit globalen Administrator-Zugangsdaten, danach erkennt das Werkzeug die vorhandenen Benutzer und übernimmt deren Daten in die Google-Umgebung.

Übertragen werden E-Mail, OneDrive-Dateien, Kalendertermine, Kontakte und Aufgaben – also das, was den Arbeitsalltag einer einzelnen Person ausmacht. Google will damit die Zeit zwischen dem Kauf eines Workspace-Abos und dem ersten Arbeitstag der Belegschaft in Workspace verkürzen.

Je kürzer diese Lücke, desto geringer die Hürde, den Anbieter zu wechseln. Migration war lange eine der größten Reibungsflächen im Plattformgeschäft. Der neue Assistent ist deshalb weniger eine technische Neuerung als eine Ansage an alle, die einen Wechsel bisher gescheut haben.

Wie die Datenübertragung konkret abläuft

Der Ablauf folgt einer festen Reihenfolge. Zuerst muss die eigene Domain verifiziert sein, danach müssen die E-Mail-Einstellungen stehen. Erst dann lässt sich der Import starten, weil sonst die Zuordnung von Adressen zu Postfächern nicht stimmt. Der Bericht nennt beide Schritte als Voraussetzung, bevor Daten importiert werden können.

Wer sein Microsoft-Konto mit globalen Administratorrechten verbindet, sollte wissen, was er da tut. Diese Zugangsdaten öffnen praktisch jede Tür im Tenant. Sie gehören in die Hände der Personen, die die Migration verantworten, und nicht in einen Sammelordner für Betriebszugänge. Nach Abschluss der Übertragung ist es sinnvoll, die Verbindung zu prüfen und die verwendeten Zugangsdaten zu erneuern.

Auffällig sind die Datenquellen, die nicht genannt werden. Postfächer, OneDrive, Kalender, Kontakte und Aufgaben stehen auf der Liste. Teams-Konversationen, gewachsene SharePoint-Strukturen mit ihren Berechtigungsketten oder Automatisierungen, die an einzelne Konten gebunden sind, stehen nicht darauf. Wer in einer über Jahre gewachsenen Microsoft-Umgebung arbeitet, weiß, dass genau dort die schwierigen Fälle liegen.

Zehn Nutzer als Grenze: Wo der Assistent endet

Der entscheidende Vorbehalt steht in den Einschränkungen. Der automatisierte Prozess ist derzeit auf zehn Microsoft-Benutzer begrenzt. Für einen Handwerksbetrieb mit acht Mitarbeitern ist das keine Einschränkung, sondern schlicht passend. Für ein Unternehmen mit mehreren hundert Konten ist es ein Ausschlusskriterium.

Bei größeren Vorhaben bleibt es also beim klassischen Vorgehen: Pilotgruppe definieren, Migration in Wellen, eine Phase der Koexistenz, Nachzügler separat nachziehen. Größere Organisationen brauchen weiterhin zusätzliche Werkzeuge und eine belastbare Planung. Der Assistent verkürzt den Start, er ersetzt kein Migrationsprojekt.

Das ist keine Schwäche der Ankündigung, sondern eine Frage der Zielgruppe. Google bedient mit diesem Schritt zuerst diejenigen, die den Wechsel bisher gar nicht erst versucht haben. Wer schon einmal eine Migration mit mehreren tausend Postfächern begleitet hat, wird von einem Zehn-Nutzer-Import ohnehin nicht angesprochen.

Voraussetzungen: Domain, Lizenzen und der Unterschied zwischen den Tarifen

Ein zweiter Punkt ist das Lizenzmodell. Der Bericht nennt eine Bedingung, die leicht überlesen wird: Das Werkzeug steht zunächst Organisationen mit einem Flexible Plan zur Verfügung. Wer einen Annual- oder Fixed-Term-Plan gebucht hat, muss zusätzliche Lizenzen manuell hinzufügen, um den Migrationsassistenten überhaupt nutzen zu können.

Das ist ein Detail mit praktischen Folgen. Migrationen werden selten spontan entschieden, aber häufig kurzfristig angestoßen, wenn ein Vertrag ausläuft oder ein Standort dazukommt. Wer den Assistenten einplanen will, sollte den eigenen Tarif also vorher prüfen und nicht erst am Tag des Umzugs feststellen, dass die Voraussetzung fehlt. Solche Angaben ändern sich mit der Zeit, deshalb lohnt ein Blick in die aktuelle Dokumentation.

Hinzu kommt der unspektakuläre Teil: Domain-Verifizierung und E-Mail-Konfiguration stehen vor dem Import. Das klingt nach Formalie, ist aber der Punkt, an dem Projekte erfahrungsgemäß hängen bleiben. Solange die DNS-Einträge nicht sauber stehen, bewegt sich kein Postfach.

Wann sich zusätzliche Migrationstools weiterhin lohnen

Wer nach einem Migrationstool von Microsoft 365 zu Google Workspace sucht, findet mit dem eingebauten Assistenten eine Option, die für den Einstieg reicht. Wenn du allerdings vierzig Postfächer, zwei Standorte und eine Handvoll gemeinsam genutzter Postfächer bewegen musst, brauchst du mehr als das. Spezialisierte Migrationsdienste arbeiten mit Wiederholungsläufen, die Änderungen während der Umzugsphase nachziehen.

Diese Wiederholungsläufe entscheiden darüber, ob am Ende eine Lücke bleibt. In einem laufenden Betrieb kommen täglich neue Mails, neue Termine, neue Dateien hinzu. Eine Migration ohne Delta-Abgleich erzeugt einen sauberen Schnitt, aber auch eine Lücke. Wer Microsoft-365-Benutzer und -Daten importieren will, ohne den Betrieb anzuhalten, plant diese Phase bewusst ein.

Dazu kommen Themen, die sich nicht wegklicken lassen: Berechtigungen auf Freigaben, Archivpostfächer, Verteilergruppen, Protokolle für Nachweispflichten. Für Unternehmen zählt deshalb der Werkzeugkasten, nicht das einzelne Produkt. Der eingebaute Assistent deckt den kleinen Teil ab, spezialisierte Werkzeuge den großen.

Bevor irgendetwas übertragen wird, gehört eine Bestandsaufnahme auf den Tisch: Wie viele Konten gibt es wirklich? Welche Datenquellen werden genutzt, welche nur vermutet? Welche Fristen gelten, und wer kommuniziert den Wechsel an die Belegschaft? Diese Fragen kosten weniger Zeit als eine misslungene Migration.

Was das für den Alltag und den Wettbewerb bedeutet

Google senkt mit diesem Schritt die Kosten des Wechsels. Ein Anbieter, dessen Produkt schwer zu verlassen ist, bindet Kunden auch dann, wenn die Zufriedenheit sinkt. Ein Anbieter, dessen Produkt leicht zu verlassen ist, muss dagegen im Alltag überzeugen. Microsoft verliert dadurch keine Kunden, aber der Wechsel kostet weniger Überwindung.

Für kleine und mittlere Organisationen bedeutet das konkret: Eine Google-Workspace-Migration beginnt heute im Einrichtungsprozess statt in einem eigenen Projekt. Wer zehn oder weniger Konten bewegt und mit Postfach, OneDrive, Kalender, Kontakten und Aufgaben auskommt, kann den Assistenten im Einrichtungsprozess mitnehmen. Wer darüber liegt, plant weiterhin in Projektform.

Das eingebaute Tool reicht für den Einstieg, ersetzt aber keine Migrationsstrategie. Prüfe zuerst die Anzahl der Konten, dann den eigenen Lizenzplan, dann die tatsächlich genutzten Datenquellen. Erst danach entscheidet sich, ob der Assistent die Arbeit erledigt oder nur ein Teil davon ist.

Quelle: petri.com

Ein Manifest, eine feste Verzeichnisstruktur, ein Installationsbefehl: Google hat ein Plugin namens google-cloud-developer veröffentlicht, das Agent Skills und die Konfiguration eines MCP-Servers in einem installierbaren Paket bündelt. Es liegt im öffentlichen Google-Agent-Skills-Repository. Wer regelmäßig mit KI-Coding-Agenten arbeitet, kennt den Zustand davor: Jede Fähigkeit wird einzeln nachinstalliert, jede Konfiguration einzeln gepflegt, und in jeder neuen Umgebung beginnt die Sortierarbeit von vorn. Ein Plugin ändert das, weil es nicht ein einzelnes Werkzeug liefert, sondern eine Werkzeugkiste, in der die Fächer schon beschriftet sind.

Was im Plugin google-cloud-developer steckt

Das Fundament sind laut Ankündigung die Grundlagen der Arbeit mit Google Cloud: Authentifizierung, Autorisierung, das Verwalten von Projekten und Guardrails für Operationen der gcloud CLI. Das klingt trocken, ist aber der Teil, an dem Agenten am häufigsten scheitern. Ohne dieses Wissen raten sie entweder oder hantieren mit zu weitreichenden Berechtigungen. Dazu kommt die Konfiguration für den Developer Knowledge MCP Server, der dem Agenten aktuelle offizielle Entwicklerdokumentation liefert. So liegt in einem Paket beisammen, was sonst auf drei oder vier getrennte Einrichtungen verteilt wäre.

Ein Agent, der nur Dokumentation lesen kann, bleibt bei der Analyse stehen. Einer, der nur Befehle ausführt, handelt ohne Kontext. Erst Projektwissen, aktuelles Referenzmaterial und der Zugriff auf eine echte Umgebung zusammen ergeben eine arbeitsfähige Grundlage.

Plugins lösen das Problem gekoppelter Fähigkeiten

Google beschreibt in der Ankündigung ein Muster, das viele Teams kennen: Einzelne Skills lassen sich gut installieren und sparen Kontext, weil sie nur geladen werden, wenn sie gebraucht werden. Sobald aber mehrere Skills zusammenspielen sollen, wird die Verwaltung mühsam. Ein Beispiel aus dem Beitrag: Ein Agent, der Infrastruktur analysiert, arbeitet besser, wenn Domänenwissen, Empfehlungen zum Vorgehen und der Zugriff auf eine laufende Umgebung zusammen verfügbar sind.

Plugins machen das anders: Statt Abhängigkeiten manuell zu verdrahten, werden verwandte Fähigkeiten zu einer Einheit gebündelt. So lassen sich breite Grundlagenfähigkeiten und tiefe produktspezifische Werkzeuge nebeneinander nutzen, ohne bei jeder Änderung die eigene Konfiguration nachzuziehen.

Ein offener Standard statt Bastellösung pro Werkzeug

Google hat das Plugin nicht als proprietäres Format gebaut, sondern nach der Agent-Plugins-Spezifikation. Das ist ein offener, herstellerneutraler Standard, der Agent Skills und MCP-Server in portable, interoperable Einheiten verpackt. Statt für jeden KI-Assistenten eine eigene Konfiguration und einen eigenen Wrapper zu pflegen, gibt es ein einheitliches Manifest und eine einheitliche Verzeichnisstruktur.

Für Entwickler heißt das: Dasselbe Plugin läuft in unterschiedlichen KI-Coding-Umgebungen, und die Anbindung bleibt vergleichbar. Das gilt nicht nur für die heute vorgestellten Pakete, sondern für alles, was im Google-Agent-Skills-Repository veröffentlicht wird. Wer mehrere Agenten parallel betreibt, spart Pflegearbeit.

Beispiel: Projekt anlegen und Identität authentifizieren

Der Beitrag führt ein Szenario durch: Ein Nutzer bittet den Agenten, ein Konto und ein erstes Projekt mit Abrechnung aufzusetzen und anschließend die lokale Maschine so zu authentifizieren, dass ein Skript die APIs als Dienstidentität ansprechen kann – nicht mit den persönlichen Zugangsdaten des Nutzers. Interessant ist weniger das Ergebnis als der Ablauf.

Zuerst prüft er die eigene Umgebung: Ist die CLI vorhanden, gibt es schon Projekte oder Organisationen, in die sich das Neue einfügen müsste. Dann folgt eine Prüfung gegen IAM-Best Practices, um Risiken zu vermeiden, die im Auftrag gar nicht bedacht waren – etwa versehentlich preisgegebene Schlüssel oder Commits mit sensiblen Dateien. Erst im dritten Schritt skizziert der Agent einen Fahrplan und fragt, ob er die Schritte ausführen soll, bevor er an Ressourcen etwas verändert.

Die Reihenfolge adressiert eine der häufigsten Sorgen im Umgang mit Agenten: Er handelt nicht sofort, sondern erklärt zuerst, was er vorhat. Wer schon einmal erlebt hat, wie ein Automatismus eine Produktionsressource angefasst hat, weiß, dass das nicht selbstverständlich ist.

Installation in Antigravity, Claude Code und Codex CLI

Die Installation ist einfach, weil sie auf dem offenen Standard aufsetzt. Bei der Antigravity CLI wird das Plugin direkt über seinen Pfad im Google-Agent-Skills-Repository eingebunden. Bei Claude Code und der Codex CLI sind es zwei Schritte: erst den Google-Plugins-Marketplace hinzufügen, dann das gewünschte Plugin daraus installieren.

Wer diesen Weg geht, sollte zwei Dinge beachten. Erstens greift ein solches Plugin auf eine echte Cloud-Umgebung zu, weshalb die Frage nach minimal nötigen Berechtigungen nicht delegierbar ist. Zweitens lohnt es, die vorgeschlagenen Schritte zu lesen, bevor sie ausgeführt werden – darum geht es bei den eingebauten Guardrails. Der Beitrag verweist zusätzlich auf ein Codelab, das Installation und erste Erkundung in Antigravity begleitet, sowie auf die Einstiegsdokumentation für lokale Entwicklung.

Was das für den Alltag bedeutet

Ein Plugin ist keine neue Fähigkeit des Modells, sondern eine Frage der Ordnung. Es bündelt Wissen, Werkzeuge und Zugriffswege, damit ein Agent sie zuverlässig findet und nicht jedes Team dieselbe Verdrahtung neu erfindet.

Wer Google Cloud bereits nutzt, für den ist das Developer Plugin ein sinnvoller erster Baustein, weil es die Themen abdeckt, an denen Agenten sonst hängen bleiben. Wer neu ist, findet in der Dokumentation den Weg zur lokalen Entwicklungsumgebung. Und wer wissen will, was unter der Haube steckt, kann sich das Repository ansehen und nachvollziehen, wie Agent Skills und MCP-Server dort zusammengesetzt sind.

Quelle: cloud.google.com

Man könnte meinen, die wirklich wichtigen KI-Modelle trügen einen Namen mit „Pro“ im Titel. Schließlich klingt das nach dem großen, schweren Schiff, das durch die KI-Welt pflügt. Was Google gerade zeigt, sieht allerdings anders aus: Statt eines neuen Flaggschiffs in der Pro-Reihe veröffentlicht das Unternehmen mit Gemini 3.8 Flash bereits das dritte Flash-Modell innerhalb von nur sechs Wochen. Die Pro-Reihe hingegen scheint seit Anfang 2026 auf der Stelle zu treten. Das verschiebt die Machtverhältnisse innerhalb der Gemini-Familie leise, aber spürbar.

Zwei Varianten, ein gemeinsamer Kern

Das neue Modell kommt nicht allein. Google stellt Gemini 3.8 Flash in zwei Spielarten vor. Die Standardvariante beschreibt das Unternehmen selbst als Arbeitstier, also als Modell für den täglichen Einsatz – von agentenbasierten Aufgaben bis zur Softwareentwicklung. Daneben existiert Gemini 3.8 Flash Cyber. Diese Variante teilt sich die technische Basis, wurde aber gezielt für das Aufspüren und Eindämmen von Sicherheitslücken optimiert. Wer mit klassischer Software arbeitet, bekommt also das eine Modell; wer in der Cybersicherheit zu Hause ist, das andere.

Für Entwicklerinnen und Entwickler hält Google zudem ein vertrautes Argument bereit. Wie schon beim Vorgänger 3.7 Flash gilt ein Einführungspreis bis Jahresende: 0,75 US-Dollar pro Million Eingabe-Tokens und 3,75 US-Dollar pro Million Ausgabe-Tokens. Danach steigen die Preise auf 1,50 bzw. 7,50 Dollar. Allerdings wirkt dieser Preissprung derzeit eher theoretisch, weil bis dahin vermutlich schon das nächste Flash-Modell bereitstehen wird.

Warum Google die Preise senkt

Dass Google überhaupt so günstig anbietet, hat einen einfachen Grund. Andere KI-Labore haben in jüngster Zeit ihre Token-Preise deutlich gesenkt, um Unternehmen bei der Stange zu halten, die angesichts schwankender Qualität und unklarer ROI-Rechnungen vorsichtig geworden sind. Google kann es sich schlicht nicht leisten, in dieser Preisschlacht zurückzufallen. Ein günstiges Modell allein reicht allerdings nicht, wenn die Leistung nicht stimmt.

Hier kommt der spannende Teil: Google liefert zu Gemini 3.8 Flash die üblichen Benchmark-Zahlen mit, und die sehen überraschend stark aus. In den meisten Tests liegt das neue Modell nur knapp über dem 3.7 Flash, aber bei Coding-Evaluierungen ist der Sprung deutlich größer. Auf dem DeepSWE-Leaderboard, das misst, wie gut ein Modell komplexe Softwareprobleme lösen kann, thront Gemini 3.8 Flash ganz oben – und das zu einem niedrigeren Preis als die Konkurrenz.

Die Pro-Lücke und ihre Folgen

Wer darauf gewartet hat, dass Google das seit Langem angekündigte Gemini 3.5 Pro veröffentlicht, wartet bis heute. Berichten zufolge hat Google den Release des Pro-Modells verschoben, weil dessen Coding-Leistung nicht mit anderen Anbietern mithalten konnte. Wenn die veröffentlichten Zahlen für 3.8 Flash die Realität abbilden, wäre das eine bemerkenswerte Wendung: Dann müsste Google zugeben, dass die kleineren Flash-Modelle inzwischen mit den Spitzenreitern konkurrieren – nur eben unter einem anderen Namen.

Stellen wir uns das einmal bildlich vor. Wir bauen ein Haus. Eigentlich sollte das große Pro-Modell das Fundament gießen, doch der Bau stockt. Also stellt das Team stattdessen modulare Fertigteile her – die Flash-Reihe. Jedes Teil ist einzeln nützlich, lässt sich schnell austauschen und kostet weniger. Irgendwann fragt man sich, ob das Fundament überhaupt noch gebraucht wird, wenn die Module das Haus allein tragen.

Computersteuerung bleibt eine Baustelle

Eine Disziplin, in der Google traditionell hinterherhinkt, ist die agentenbasierte Computersteuerung. Darunter fällt die Fähigkeit eines Modells, eigenständig mit einer grafischen Benutzeroberfläche zu interagieren – also Programme zu öffnen, Formulare auszufüllen oder durch Menüs zu navigieren. Im OSWorld-2.0-Test, der genau das prüft, schlägt sich Gemini 3.8 Flash zwar besser als sein Vorgänger, liegt aber deutlich hinter dem Marktführer Claude Opus. GPT schneidet in diesem Bereich ebenfalls nicht überragend ab, was zeigt, dass es sich um eine branchenweite Herausforderung handelt und nicht um ein Google-spezifisches Problem.

Trotz dieser Schwäche bleibt der Gesamteindruck solide. Wer ein vielseitiges Modell sucht, das in den meisten Benchmarks mithält, ohne das Budget zu sprengen, landet bei Flash. Wer hingegen komplexe, lang laufende Agenten mit Computersteuerung bauen will, schaut weiterhin zur Konkurrenz.

Die Cyber-Variante als Nischenmodell

Gemini 3.8 Flash Cyber ersetzt die ältere 3.5-Version und richtet sich an einen sehr speziellen Kreis. Die meisten Anwenderinnen und Anwender werden dieses Modell nie direkt nutzen, doch für Cybersicherheitsteams spielt es eine wachsende Rolle. Google berichtet von erheblichen Verbesserungen gegenüber früheren Generationen: Das Modell habe in internen Tests mehr Schwachstellen identifiziert und häufiger funktionierende Patches vorgeschlagen.

Konkret nennt das Unternehmen Zahlen, die sich sehen lassen können. Das Chrome-Sicherheitsteam will mit dem neuen Modell eine 2,6-fach höhere Patch-Genauigkeit erreicht haben. Das Cloud-Team gibt an, dass 3.8 Flash Cyber eine kritische Sicherheitslücke in nur zwei Stunden aufgespürt habe. Zusätzlich gibt es Stimmen von Partnern wie Wiz und Palo Alto Networks, die die Leistungsfähigkeit des Modells bestätigen. Solche Erfahrungsberichte sind wertvoll, weil sie zeigen, dass die Verbesserungen nicht nur auf Papier existieren.

Die Verfügbarkeit ist allerdings eingeschränkt. Während das Standardmodell ab sofort im gesamten Google-Ökosystem ausgerollt wird, bleibt Cyber vorerst vertrauenswürdigen Testern und staatlichen Stellen vorbehalten. Das ist nachvollziehbar: Ein KI-Modell, das aktiv nach Sicherheitslücken sucht, darf nicht in falsche Hände geraten.

Was die Flash-Strategie über Googles KI-Kurs verrät

Die Beobachtung, dass Google innerhalb weniger Wochen drei Flash-Modelle veröffentlicht, während die Pro-Reihe schweigt, wirft eine strategische Frage auf. Offenbar hat das Unternehmen erkannt, dass der Markt für schnelle, günstige und vielseitige Modelle gerade das ist, was Unternehmen aktuell kaufen wollen. Riesige Flaggschiff-Modelle sind teuer, langsam in der Iteration und für die meisten Anwendungsfälle überdimensioniert.

Google passt sein Tempo also an die Nachfrage an. Statt einmal im Jahr ein Mega-Update zu liefern, gibt es nun alle paar Wochen ein kleineres, gezielteres Modell. Das ist keine Revolution, sondern eine kluge Anpassung an die Dynamik des Marktes. Allerdings hat das auch einen Haken: Wenn die Pro-Reihe dauerhaft pausiert, verlieren Entwicklerinnen und Entwickler eine wichtige Referenz für Spitzenleistung.

Gleichzeitig zeigt die Benchmark-Tabelle, dass die Flash-Modelle in einigen Bereichen ohnehin schon an der Spitze mitschwimmen. Vielleicht ist das die eigentliche Nachricht hinter dem schnellen Release-Rhythmus: Google testet, ob die Grenze zwischen Pro und Flash überhaupt noch jemanden interessiert.

Was das für Anwenderinnen und Anwender bedeutet

Wer Gemini 3.8 Flash ausprobieren möchte, hat mehrere Wege. In der Gemini-App selbst steht das Modell nur mit einem Pro- oder Ultra-Abo zur Verfügung. Wer ohne Abo testen will, kann das AI Studio nutzen, das kostenlosen Zugang zu den Modellen bietet. Für den professionellen Einsatz bleibt die API der Standardweg, mit den genannten Einführungspreisen.

In der Praxis heißt das: Wer ein preiswertes Modell für Prototyping, kleinere Automatisierungen oder Coding-Aufgaben sucht, bekommt mit 3.8 Flash derzeit eines der stärksten Angebote auf dem Markt. Wer hingegen spezialisierte Anforderungen hat – etwa Computersteuerung oder besonders tiefes Reasoning – sollte die eigenen Tests machen und nicht nur den Marketing-Zahlen vertrauen.

Die wichtigste Erkenntnis aus diesem Release ist weniger die einzelne Modellversion. Es ist die Einsicht, dass sich die Rangordnung der KI-Modelle gerade neu sortiert. Was vor zwei Jahren noch als „kleiner Bruder“ galt, ist heute oft der eigentliche Star. Google scheint das verstanden zu haben und liefert entsprechend – leise, schnell und ohne großes Tamtam.

Quelle: arstechnica.com