Warum wurde Gemini von Googles internen Coding-Tools ausgeschlossen? Sergey Brins Geschichte erklärt
Die Formulierung „Sergey Brin Google Gemini Bann“ lässt die Episode dramatischer erscheinen, als die Beweise es stützen. Google hat Gemini nicht für die Öffentlichkeit gesperrt, Aufsichtsbehörden haben es nicht verboten und Brin hat nicht gesagt, das Modell sei bei einer Sicherheitsüberprüfung durchgefallen. Er beschrieb eine engere und seltsamere Situation: Eine interne Google-Webseite, die Coding-Tools auflistet, setzte Gemini auf die „Nein“-Seite.
Die Geschichte stammt von Brins Auftritt bei All-In Live in Miami am 20. Mai 2025. Sie tauchte in der Technologieberichterstattung und in sozialen Beiträgen im Juli 2026 wieder auf, weshalb viele Leser sie als frische Nachricht aufnehmen. Die zentrale Tatsache ist real, aber die genaue Begründung der Richtlinie wurde nie öffentlich bekannt gegeben.
Quelle: Wikimedia Commons / Asoundd, CC BY-SA 4.0
Wichtige Erkenntnisse
- Brin sagte, Gemini sei auf einer internen Google „No List“ für Tools aufgetaucht, die Mitarbeiter zum Programmieren verwenden durften.
- Er beschrieb die Gründe als nur historisch und „seltsam“; Google hat keine detaillierte Erklärung für die Regel veröffentlicht.
- Brin sagte auch, die Regel sei nicht wirklich durchgesetzt worden, aber die interne Webseite existierte immer noch und schuf ein echtes Genehmigungsproblem.
- Die Beschränkung wurde schließlich nach einem langwierigen internen Streit und einer Eskalation aufgehoben.
- Dies war kein öffentliches Verbot von Gemini und kein Beweis dafür, dass Google Gemini generell als unsicher oder illegal einstufte.
Was Sergey Brin tatsächlich sagte
Während des Interviews sprach Brin über seine Rückkehr zur praktischen technischen Arbeit bei Google. Er erklärte, dass er begonnen habe, verschiedene Teile der Systeme des Unternehmens zu berühren, kleine Codeänderungen einzureichen und Experimente durchzuführen, um die Technologie direkt zu verstehen und nicht nur aus Geschäftsleitungsempfehlungen.
Das Gespräch wandte sich dann der KI-gestützten Programmierung zu. Brin sagte, Google unterhalte eine Liste, die festlegt, welche Tools zum Schreiben von Code verwendet werden durften und welche nicht. Gemini, Googles eigene Flaggschiff-KI-Familie, stand auf der verbotenen Seite dieser internen Seite. Er sagte, die Situation habe seinen Verstand „verwirrt“ und verwies auf eine Sammlung historischer Gründe und nicht auf eine klare aktuelle Begründung.
❝ Ich meine, niemand würde diese Regel durchsetzen, aber es gab diese tatsächliche interne Webseite. ❞
Googles Mitbegründer, sprach auf der All-In Live in Miami am 20. Mai 2025
Brin sagte, er habe gegen die Richtlinie gekämpft und ihre Beilegung habe „schockierende“ Zeit gedauert. Er sagte auch, das Problem sei schließlich behoben worden und Google teste verschiedene interne und externe KI-Coding-Tools, um festzustellen, was die Produktivität der Entwickler wirklich verbessert.
Warum wurde Gemini von Googles internen Coding-Tools gesperrt?
Die genaueste Antwort ist: Google hat keinen spezifischen Grund öffentlich genannt. Brin nannte keinen Sicherheitsvorfall, keine Urheberrechts Streitigkeit, keinen Datenschutzverstoß, keine schlechte Coding-Leistung oder eine behördliche Anordnung. Seine eigene Erklärung war, dass Gemini aus historischen Gründen auf der internen No-Use-Liste gelandet war, die für ihn keinen Sinn mehr ergaben.
Diese Formulierung deutet auf eine veraltete Genehmigungsentscheidung oder eine Richtlinie hin, die die Umstände überlebt hat, die sie hervorgebracht haben. Sie sagt uns nicht, was diese ursprünglichen Umstände waren. Jeder Anspruch, dass die Beschränkung definitiv durch Quellcode-Lecks, Modellhalluzinationen, Lizenzierungsbedenken oder interne Rivalitäten verursacht wurde, geht über die öffentlichen Beweise hinaus.
Quelle: commons.wikimedia.org
Große Unternehmen kontrollieren häufig, welche Coding-Assistenten auf Repositories, Prompts und Entwicklerumgebungen zugreifen dürfen. Brins Bericht zeigt, wie eine Genehmigungsliste mit der aktuellen Produktstrategie des Unternehmens aus dem Takt geraten kann.
Was eine interne „No List“ normalerweise bedeutet
Eine Liste genehmigter Tools ist ein Governance-Mechanismus und nicht unbedingt ein Urteil, dass ein Produkt schlecht ist. In Softwareorganisationen kann ein Coding-Assistent einer Überprüfung bedürfen, da er proprietären Code empfangen, Kontext aus dem Repository abrufen, lizenziertes Material generieren, externe Dienste aufrufen oder Telemetriedaten speichern kann. Sicherheitsteams benötigen möglicherweise auch Identitätskontrollen, Protokollierung, regionale Verarbeitungsregeln und vertragliche Garantien, bevor sie ein Tool genehmigen.
Googles öffentliche Dokumentation für Gemini Code Assist veranschaulicht die Art von Kontrollen, die Unternehmenskunden jetzt erwarten. Sie beschreibt die Authentifizierung über verwaltete Identitäten, IAM-basierten Zugriff und Datenschutzverpflichtungen. Diese öffentlichen Kontrollen helfen zu erklären, warum Coding-Tools sorgfältig verwaltet werden, beweisen aber nicht, warum Gemini auf Googles eigener historischer interner Liste erschien.
Für eine breitere Erklärung dieser Datenfragen trennt Zerlos Leitfaden für Datenschutzbedenken bei Google Gemini Einstellungen zur Verbraucheraktivität von Unternehmensdatenschutzverpflichtungen.
Was die Geschichte nicht bedeutet
| Gemeinsame Interpretation | Was die verfügbaren Beweise stützen |
|---|---|
| Google hat Gemini überall gesperrt | Nein. Brin beschrieb eine interne Seite zur Genehmigung von Coding-Tools, kein öffentliches Produktverbot. |
| Gemini fiel bei einer bestätigten Sicherheitsprüfung durch | In Brins Bericht wurden keine solchen Feststellungen offengelegt. |
| Google-Ingenieure konnten Gemini überhaupt nicht nutzen | Brin sagte, die Regel sei nicht wirklich durchgesetzt worden, obwohl die offizielle interne Seite die Einschränkung immer noch aufführte. |
| Der Vorfall ereignete sich im Juli 2026 | Die ursprüngliche öffentliche Darstellung stammt vom 20. Mai 2025; die Geschichte tauchte später in der Berichterstattung von 2026 wieder auf. |
| Die Beschränkung besteht weiterhin | Brin sagte, es sei behoben worden und Google setze KI-Coding-Tools ein und teste sie. |
Verbraucher-Gemini, Gemini-Modelle und Coding-Produkte sind nicht dasselbe
Ein Teil der Verwirrung entsteht durch die Verwendung von „Gemini“ als ein Label für mehrere Ebenen. Gemini kann sich auf die Modellfamilie von Google DeepMind, die öffentliche Gemini-Chat-Anwendung, APIs für Entwickler oder Coding-Produkte wie Gemini Code Assist beziehen. Eine interne Richtlinie kann eine Bereitstellung genehmigen und eine andere einschränken, da die Datenflüsse, Benutzeridentitäten, der Zugriff auf Repositories und die Protokollierungsvereinbarungen unterschiedlich sind.
Quelle: commons.wikimedia.org
Die öffentliche Gemini-Web-App unterscheidet sich von einem Enterprise-Coding-Assistenten, der mit privaten Repositories verbunden ist. Brins Anekdote betraf die interne Genehmigung von Coding-Tools, nicht den normalen Zugriff auf diese kundenorientierte Schnittstelle.
Google kündigte am 20. Mai 2025 an, dass Gemini Code Assist für Einzelpersonen und sein GitHub-Code-Review-Produkt allgemein verfügbar seien und von Gemini 2.5 angetrieben würden. Diese öffentliche Produkteinführung am selben Tag wie Brins Interview lässt die interne Einschränkung besonders widersprüchlich erscheinen, enthüllt aber immer noch nicht, wann die alte interne Liste erstellt oder genau wann sie entfernt wurde.
Hat Sundar Pichai das Verbot aufgehoben?
Brin beschrieb deutlich die Eskalation des Problems, nachdem er Schwierigkeiten hatte, es über den normalen Prozess zu lösen. Mehrere spätere Berichte identifizieren den Google- und Alphabet-CEO Sundar Pichai als den Manager, der die Entfernung der Beschränkung unterstützt hat. Die weit verbreitete Transkription der relevanten Interviewpassage nennt Pichai an dieser Stelle jedoch nicht klar. Die sicherste Formulierung ist, dass Brin den Streitfall an die Geschäftsleitung eskalierte und sagte, das Problem sei gelöst; Berichte schreiben die endgültige Intervention Pichai zu.
Diese Unterscheidung ist wichtig, da virale Zusammenfassungen oft eine informelle Anekdote in eine präzise Unternehmenszeitachse verwandeln. Google hat die interne Webseite, die ursprüngliche Entscheidungsaufzeichnung, das zuständige Team oder eine formelle Post-Mortem nicht veröffentlicht. Die öffentlichen Beweise stammen hauptsächlich aus Brins eigener Geschichte und der anschließenden Berichterstattung darüber.
Warum die Anekdote über Google hinaus wichtig ist
Die Episode ist ein nützliches Beispiel dafür, wie die Einführung von KI durch Organisationsstruktur und nicht durch Modellfähigkeiten verlangsamt werden kann. Ein Unternehmen kann ein KI-Produkt öffentlich bewerben, während interne Sicherheits-, Rechts-, Beschaffungs- und Ingenieursysteme es immer noch als nicht genehmigt behandeln. Das Ergebnis ist eine Lücke zwischen strategischer Absicht und dem täglichen Zugriff für Entwickler.
Drei Lektionen stechen hervor:
- Genehmigungslisten benötigen Eigentümer und Ablaufprüfungen.Eine Regel ohne aktuellen Eigentümer kann auch nach dem Verschwinden ihrer ursprünglichen Begründung bestehen bleiben.
- „Dogfooding“ benötigt einen genehmigten Bereitstellungspfad.Mitarbeiter können ein Produkt nicht verantwortungsvoll auf vertraulichen Arbeiten testen, nur weil ihr Unternehmen es erstellt hat.
- Eskalation ist kein Ersatz für Governance.Brin konnte das Problem nach oben eskalieren; normale Ingenieure benötigen einen dokumentierten Prozess zur Anfechtung veralteter Beschränkungen.
Der interessanteste Teil der Geschichte ist daher nicht, dass Google Gemini einst misstraute. Die Beweise dafür sind nicht schlüssig. Es ist, dass das interne Kontrollsystem von Google anscheinend nicht mit Googles eigener KI-Strategie Schritt gehalten hat und selbst ein Mitbegründer die Korrektur überraschend schwierig fand.
FAQ
Wurde Google Gemini wirklich innerhalb von Google gesperrt?
Laut Sergey Brin tauchte Gemini auf einer internen „No List“ für Tools auf, die Mitarbeiter zum Programmieren verwenden durften. Er sagte auch, die Regel sei nicht wirklich durchgesetzt worden, sodass „als nicht genehmigt aufgeführt“ genauer ist, als zu sagen, dass die gesamte interne Nutzung von Gemini technisch blockiert war.
Warum hat Google Gemini auf die No-Use-Liste gesetzt?
Google hat den Grund nicht veröffentlicht. Brin verwies nur auf ungewöhnliche historische Gründe. Sicherheits-, Datenschutz-, geistiges Eigentum- und Beschaffungsbedenken sind übliche Gründe für die Genehmigungsverfahren für Coding-Tools, aber keiner davon wurde als Ursache in diesem Fall bestätigt.
Wann erzählte Sergey Brin die Geschichte?
Er erzählte sie während eines All-In Live-Interviews in Miami am 20. Mai 2025. Die Anekdote kursierte im Juli 2026 erneut und ließ sie für Leser, die das ursprüngliche Interview nicht gesehen hatten, neu erscheinen.
Hat Sundar Pichai das Gemini-Verbot aufgehoben?
Spätere Berichte besagen, dass Brin die Angelegenheit an Sundar Pichai eskalierte und dass Pichai die Entfernung der Beschränkung unterstützte. Brins öffentliche Darstellung bestätigt die Eskalation und Lösung, obwohl die allgemein verfügbare Transkription Pichai in der betreffenden Passage nicht klar nennt.
Wurde Gemini als unsicher für das Programmieren angesehen?
Brin sagte das nicht. Es wurde kein öffentlicher Sicherheitsfehler oder eine formelle Sicherheitsbewertung als Grund für die interne Auflistung angeführt. Google erweiterte später Gemini-basierte Coding-Produkte und veröffentlichte unternehmensweite Sicherheits- und Datenschutzrichtlinien.
Ist Gemini immer noch von Googles internen Coding-Tools ausgeschlossen?
Brin sagte, das Problem sei behoben worden und Google teste und starte mehrere KI-Tools zur Verbesserung der Entwicklerproduktivität. Es gibt keine öffentlichen Beweise dafür, dass die gleiche Beschränkung weiterhin in Kraft ist.
Fazit
Die Geschichte von Sergey Brin über den Google Gemini Bann ist am besten als internes Governance-Versagen zu verstehen, nicht als öffentliches Verbot oder als bestätigtes Urteil, dass Gemini unsicher sei. Gemini tauchte auf einer „No List“ für Coding-Tools aus Gründen auf, die Brin als historisch und schwer verständlich bezeichnete. Er focht die Richtlinie an, eskalierte sie und sagte, sie sei schließlich korrigiert worden. Unbekannt bleiben die ursprüngliche Begründung, welches Team die Regel besaß und wie lange sie veraltet war.