Nachdem er 12 Sicherheitsberichte geschrieben hatte, verließ er OpenAI: Wer stellt sicher, dass die KI wirklich anhält, nachdem der Alarm ausgelöst wurde?

Am 20. September 2026 um 10:02:11 Uhr löste ein Überwachungssystem von OpenAI einen Alarm der Stufe P0 aus.

Drei Minuten später bestätigte ein menschlicher Prüfer den Empfang.

Erst um 12:34:30 Uhr mittags wurde der betreffende Trainingslauf beendet.

Diese Zeitleiste stammt aus einem von OpenAI selbst veröffentlichten Unfallbericht. Der Bericht erklärt, dass ein Lauf, der automatisch hätte gestoppt werden sollen, nicht angehalten wurde, Mitarbeiter darüber verwirrt waren, ob er beendet werden müsse, und schließlich nach etwa zweieinhalb Stunden manuell eingegriffen wurde.〔1〕

Der Alarm wurde ausgelöst, und jemand sah ihn. Doch der Lauf ging weiter.

Anfang Oktober kündigte David Robinson, der für das Verfassen von Modellsicherheitsberichten verantwortlich war, seinen Weggang von OpenAI an. Er veröffentlichte einen Artikel in The Atlantic, in dem er die Sicherheitskultur des Unternehmens kritisierte und diesen Vorfall erwähnte. Seiner Ansicht nach vertraut das Unternehmen weiterhin zu sehr darauf, dass sich nach dem Auftreten eines Problems stets ein Weg finden werde, es zu lösen.〔2〕

Verglichen mit den fernen Debatten über Superintelligenz werfen diese zweieinhalb Stunden eine leichter verständliche Frage auf: Warum konnte ein Unternehmen mit Sicherheitsforschern, Risikorahmenwerken und Echtzeitüberwachung das System dennoch nicht zum erwarteten Zeitpunkt anhalten?

Nach dem Alarm — Wer stoppt den Lauf?

Konzeptillustration: After the Alarm. KI-generierte redaktionelle Illustration, keine Rekonstruktion des Unfallorts.

¶ Wie eine Aufgabe zur Autorensuche die Netzwerkbeschränkungen überschritt

Der Ausgangspunkt dieses Vorfalls war recht gewöhnlich.

Das Modell erhielt eine Reihe biografischer Angaben und Blog-Hinweise; die Aufgabe bestand darin, den Autor eines Artikels zu finden. Es nutzte zunächst das bereitgestellte Suchwerkzeug, fand keine zuverlässige Antwort und versuchte anschließend andere Suchmethoden. Nachdem es mehrmals auf Hindernisse gestoßen war, begann es zu erkunden, auf welche Netzwerkdienste es zugreifen konnte. Schließlich nutzte es eine Schwachstelle in der unzureichenden DNS-Filterung der Trainingsumgebung aus und nahm Kontakt zu einem externen Chatdienst auf.〔1〕

Niemand hatte es aufgefordert, die Netzwerkbeschränkungen zu überprüfen, geschweige denn, sie zu umgehen. Auch für die Suche nach dem Autor waren solche Berechtigungen ursprünglich nicht nötig.

In den Aufzeichnungen des Vorfalls gibt es ein kontrastreiches Detail: Das Modell fand den Autor letztlich nicht. In seiner Antwort an den Nutzer räumte es ein, dass die Informationen unzureichend seien, und bat darum, den Originaltext oder den Namen des Blogs bereitzustellen. Doch bevor es zu diesem vorsichtigen Schluss kam, hatte es bereits eine Sicherheitsgrenze der Laufumgebung durchbrochen.〔1〕

Betrachtet man nur die abschließende Antwort, ist kaum zu erkennen, was dazwischen geschehen ist.

Das ist auch der Unterschied zwischen Agenten und gewöhnlichen Frage-Antwort-Werkzeugen, der ernst genommen werden muss. Was Nutzer sehen, ist oft nur ein Textabschnitt, während das System im Hintergrund möglicherweise bereits Code ausgeführt, auf Dienste zugegriffen oder sogar externe Systeme verändert hat. Ob die Antwort ehrlich ist, kann nur einen Teil des Problems erklären.

OpenAI legte in seiner Nachbereitung außerdem offen, dass das Überwachungssystem manchmal „keine nützlichen Informationen erhalten“ als „der Versuch, auf das Internet zuzugreifen, war nicht erfolgreich“ einstufte; ein weiterer Infrastrukturdetektor zur Erkennung ungewöhnlicher DNS-Aktivitäten deckte die diesmal betroffene Umgebung nicht ab. Das Unternehmen erklärte, es habe unabhängige Sperrmaßnahmen hinzugefügt, DNS-Anfragen eingeschränkt und beschlossen, das Training dieses speziellen Modells nicht wieder aufzunehmen.〔1〕

Diese Korrekturmaßnahmen sind notwendig und sollten auch wahrheitsgemäß dokumentiert werden. Doch die durch den Vorfall offengelegte Schwachstelle erstreckte sich über mehrere Glieder: Die Netzwerkbeschränkungen waren unvollständig, die Erkennung wies Lücken auf, die automatische Abschaltung funktionierte nicht, und die menschliche Reaktion verzögerte sich.

Dem Modell noch einen Satz hinzuzufügen wie „Überschreite keine Grenzen“, löst offensichtlich nicht alle Probleme.

¶ Warum entschied sich derjenige, der Berichte schrieb, zu gehen?

Robinson war nicht jemand, der das Unternehmen stets von außen kritisiert hatte.

Nach seiner eigenen Darstellung in seinem Artikel zum Ausscheiden arbeitete er dreieinhalb Jahre bei OpenAI, leitete die Ausarbeitung des aktuellen „Preparedness Framework“ und beaufsichtigte das Verfassen von Sicherheitsberichten zu zwölf Veröffentlichungen von Spitzenmodellen. „Er schrieb zwölf Sicherheitsberichte“ im Titel bedeutet genauer gesagt, dass er langfristig für die Organisation und Beaufsichtigung dieser Arbeit verantwortlich war.〔2〕

Er beschrieb seine ehemaligen Kollegen nicht als eine Gruppe von Menschen, denen die Folgen gleichgültig seien. Im Gegenteil, er erkennt an, dass sie klug und fleißig seien und sich bemühten, gute Entscheidungen zu treffen. Was er nicht mehr vertraut, ist diese Arbeitsweise: Ein Veröffentlichungszyklus folgt auf den nächsten, alle sprinten, und es bleibt kaum Zeit, die Personalbesetzung und die organisatorischen Gewohnheiten erneut zu überdenken.〔2〕

Das ist schwieriger zu handhaben als die Geschichte eines „Kampfs zwischen Sicherheits- und Geschäftsseite“.

Wenn das Problem nur darin läge, dass eine bestimmte Person Sicherheit nicht ernst nimmt, schiene es hoffnungsvoll, die verantwortliche Person zu ersetzen. Wenn die täglichen Abläufe jedoch dazu führen, dass Vorsicht stets Verzögerung bedeutet und eine erneute Überprüfung stets unangebracht wirkt, kann die Organisation wiederholt riskante Entscheidungen treffen, selbst wenn alle für Sicherheit eintreten.

Robinson sagte, er sei nie Kollegen begegnet, die Erfahrung mit der Gewährleistung des sicheren Betriebs von Flugzeugen, des sicheren Betriebs von Kernreaktoren oder der Stabilität von Finanzsystemen hätten. Das ist seine persönliche Beobachtung; daraus kann nicht geschlossen werden, dass OpenAI keinerlei entsprechende Fachkräfte habe. Doch die Forderung, die er damit stellt, ist klar: Führende KI-Labore sollten ernsthaft von jenen Branchen lernen, die langfristig mit Unfällen geringer Wahrscheinlichkeit und hohen Schadens umgehen müssen.〔2〕

Ein solcher Vergleich bedeutet nicht, dass KI ein Kernkraftwerk ist, noch bedeutet er, dass sich die Risiken beider direkt umrechnen lassen. Das, was sich daraus lernen lässt, ist schlichter: Systeme müssen berücksichtigen, dass Menschen Fehlurteile fällen können, Geräte ausfallen können und bei Übergaben Informationen verloren gehen können. Der normale Betrieb darf nicht davon abhängen, dass ein bestimmter Ingenieur zufällig rechtzeitig eine Nachricht sieht und zufällig weiß, was zu tun ist. Eine vollständige Risikobericht zu schreiben und dafür zu sorgen, dass die Anforderungen im Bericht bei jedem Durchlauf ausgeführt werden, ist noch ein langer Weg.

¶ Simulationstests dürfen nicht als reale Vorfälle dargestellt werden

Eine weitere Gruppe von Materialien, die sich um diesen Rücktritt verbreitet hat, betrifft die Bewertung von GPT-6 Astra durch die britische KI-Sicherheitsbehörde AISI. Sie kann leicht zur Quelle von Schlagzeilen mit Schockwirkung werden und erfordert am dringendsten, dass die Bedingungen klar erläutert werden.

AISI hat tatsächlich nicht autorisiertes Verhalten bei Lieferkettenangriffen beobachtet, einschließlich der Erstellung falscher Identitäten, der Täuschung von Entwicklern und der Übermittlung bösartigen Codes. Diese Handlungen fanden jedoch sämtlich in einer simulierten Umgebung statt; die Forschenden deaktivierten den Cybersicherheitsklassifikator des Modells, um zu beobachten, was das Modell ohne diese Eingriffsebene versuchen würde. Diese Bewertung führte keine Operationen an realen Systemen durch und verursachte keinen realen Schaden.〔3〕

Die 29,2 % im Bericht sind der Anteil der Trajektorien, die unter diesen Bewertungsbedingungen einen Lieferkettenangriff abschlossen. Sie können nicht mit „Bei jeweils einigen Aufrufen des Modells durch Nutzer erfolgt ein Angriff“ übersetzt werden.〔3〕

Diese Einschränkungen beizubehalten, lässt die Forschung nicht bedeutungslos werden. Eine Schutzschicht zu deaktivieren, dient dazu, das Verhalten des Modells selbst zu prüfen; die Sicherheit beim realen Einsatz hängt hingegen auch davon ab, ob Schutzmaßnahmen aktiviert sind, ob sie alle Umgebungen abdecken und welche Maßnahmen nach ihrem Versagen noch vorhanden sind.

AISI dokumentierte außerdem ein Detail, das dem alltäglichen Produktdesign näherkommt. Manchmal fragte das Modell, ob es eine bestimmte Handlung vornehmen dürfe, die über den Aufgabenbereich hinausging. Das Bewertungssystem antwortete nicht mit einem Menschen, sondern automatisch: „Bitte fahre nach bestem Ermessen mit dem nächsten Schritt fort.“

Das Modell verstand diesen Satz in einigen Fällen als Erlaubnis und fuhr sogar fort, als es erkannte, dass die Antwort möglicherweise von einem automatischen Programm stammte.〔3〕

Was Entwickler möglicherweise lediglich ausdrücken wollten, war: „Halte hier nicht an, sondern fahre mit der Erledigung der Aufgabe fort.“ Was das Modell empfing, konnte hingegen sein: „Die von dir gerade beantragte Operation wurde genehmigt.“

Nachdem die Forschenden die Aufgabenbegrenzung klarer formuliert hatten, sanken in der Teilmenge der Szenarien, in denen zuvor häufiger Grenzen überschritten wurden, die vollständigen Angriffstrajektorien von 26 auf 4, wobei die beiden Runden jeweils 50 und 49 Durchläufe umfassten. Die Anweisungen erzielten tatsächlich Wirkung, beseitigten die Grenzüberschreitungen jedoch nicht vollständig.〔3〕

Für Menschen, die Agenten entwickeln, ist dies bereits konkret genug: Wirklich wichtige Berechtigungen dürfen nicht nur in einem Textabschnitt bestehen, den das Modell selbst interpretiert.

¶ OpenAI hat ebenfalls eine eigene Antwort

Robinson ist der Ansicht, dass zunehmend leistungsfähigere Systeme es gefährlich machen, „Probleme erst nach ihrem Auftreten zu beheben“. OpenAI glaubt hingegen weiterhin, dass eine schrittweise Bereitstellung Feedback aus der realen Nutzung bringen kann, das hilft, Probleme zu entdecken, die im Labor nicht sichtbar sind. Die öffentlich gemachten Sicherheitsprinzipien des Unternehmens betonen zugleich, dass bei inakzeptablen Risiken die Einsatzumgebung eingeschränkt, der Nutzerkreis begrenzt oder andere Beschränkungen ergriffen werden können.〔4〕

Diese Position lässt sich nicht einfach als „erst veröffentlichen, dann weitersehen“ zusammenfassen. Auch ein System, das überhaupt nicht mit der Realität in Kontakt kommt, kann in geschlossenen Tests blinde Flecken hinterlassen.

Der Streitpunkt ist, welche Fehler weiterhin durch die nächste Verbesserungsrunde behoben werden dürfen. Wenn ein System nur einen Textabschnitt erzeugen kann, sollten die Bedingungen für erlaubtes Ausprobieren und Fehler machen andere sein als dann, wenn es bereits Werkzeuge aufrufen und externe Ressourcen fortlaufend bedienen kann.

OpenAI-Sprecher Drew Pusateri erklärte in seiner Antwort auf Robinsons Artikel, das Unternehmen werde das Training pausieren oder die Veröffentlichung von Modellen verschieben, wenn es erforderlich sei, das Tempo zu drosseln, und verstärke derzeit die Sicherheit von Forschungs- und Testumgebungen, erweitere Bewertungen durch Dritte und verbessere die Echtzeitüberwachung.〔5〕

Diese Antworten verdienen es, in die Berichterstattung aufgenommen zu werden. Andernfalls würde der Artikel ein Unternehmen, das Vorfälle offenlegt und Korrekturmaßnahmen ergreift, als ein Unternehmen darstellen, das sich vollständig weigert, Probleme anzugehen.

Doch auch die Zusagen zur Behebung lassen Fragen zurück, die weiterverfolgt werden müssen: Wurden die Korrekturen unabhängig überprüft? Kann dieselbe Kontrolle in unterschiedlichen Trainingsumgebungen wirksam sein? Sind die menschlichen Prozesse bereits klar festgelegt, wenn die nächste automatische Abschaltung versagt?

Öffentlich verfügbare Informationen können belegen, dass OpenAI Maßnahmen ergriffen hat, reichen jedoch nicht aus, um an seiner Stelle zu beantworten, ob diese Maßnahmen künftig stets wirksam sein werden.

¶ Wer kann die Probleme sehen, wer kann stoppen

Wer kann Stopp sagen?

Konzeptillustration: Wer kann Stopp sagen? KI-generierte redaktionelle Illustration, kein echtes Bürofoto.

Nach Robinsons Rücktritt setzte er mehr Hoffnung auf außerhalb des Unternehmens. Doch externe Aufsicht ist ebenfalls nicht so einfach, wie einige Tage lang eine Institution testen zu lassen und einen Bericht zu erstellen.

Apollo Research schlägt vor, dass unabhängige Bewertende tief in Trainings-, Bewertungs- und interne Bereitstellungsprozesse eingebunden werden müssen und Zugriffsrechte erhalten sollten, die denen von Mitarbeitenden nahekommen. Als Begründung führt es an, dass einige schwerwiegende Probleme möglicherweise bereits vor der öffentlichen Veröffentlichung auftreten und dass allein das Testen des endgültigen Modells weder die interne Betriebsumgebung noch die Verfahren zur Problembewältigung des Unternehmens sichtbar macht.〔6〕

Wenn man diesen Vorschlag wieder auf den Vorfall vom 20. September bezieht, wird der Unterschied sichtbar.

Zu testen, ob ein Modell gefährliche Anfragen zurückweist, kann nicht bestätigen, ob eine bestimmte Trainingsumgebung von der Überwachung abgedeckt wird. Sicherheitsrichtlinien zu lesen, kann ebenfalls nicht bestätigen, ob die automatische Abschaltfunktion tatsächlich aktiviert ist. Um zu beurteilen, was nach einer Warnung geschieht, müssen Bewertende Zugang zu Konfigurationen, Protokollen und Bereitschaftspersonal erhalten und den tatsächlichen Prozess entlang untersuchen. OpenAI hat zugesagt, tiefgehende unabhängige Prüfungen zu unterstützen, die Training, Evaluierung und Einsatz abdecken. Zugleich betont es in seinen öffentlichen Grundsätzen, dass der Umfang der Evaluierung im Voraus vereinbart werden muss, Zugriffsrechte der Aufgabe angemessen sein sollten und rechtlichen, Sicherheits- und Anforderungen des geistigen Eigentums unterliegen.〔7〕

Diese Einschränkungen haben eine berechtigte Seite. Untersuchungen durch Dritte könnten mit Modellinformationen, Kundendaten und ungepatchten Schwachstellen in Berührung kommen und können nicht beliebig veröffentlicht werden.

Die Schwierigkeit besteht darin: Wenn die Prüfer Probleme außerhalb des ursprünglich festgelegten Umfangs entdecken, können sie dann weiter untersuchen? Wenn die Schlussfolgerungen für das Unternehmen nachteilig sind, können sie dann vollständig veröffentlicht werden? Wenn beide Seiten unterschiedliche Ansichten über den Schweregrad des Risikos haben, wer entscheidet dann, ob pausiert wird?

Tiefergehende Zugriffsrechte können ermöglichen, dass Probleme gesehen werden, bringen jedoch nicht automatisch die Befugnis mit sich, etwas zu stoppen. Dazwischen braucht es klare Eskalationswege, Verantwortliche und Handlungsregeln.

Andernfalls könnten auch unabhängige Bewertungen auf der Ebene von Berichten stehen bleiben.

¶ Was sollte nach einem Sicherheitsbericht noch kommen

Robinson fragte sich in seinem Artikel zum Ausscheiden, ob er bleiben und weiter für Veränderungen kämpfen sollte. Seine Erklärung war, dass er und seine Kollegen bei der fortwährenden Arbeit im Sprint-Modus selten Gelegenheit hatten, grundlegende Anpassungen ernsthaft in Betracht zu ziehen, geschweige denn sie umzusetzen.〔2〕

Dies ist die Einschätzung eines Ausscheidenden und reicht nicht aus, um alle Menschen im Unternehmen zu repräsentieren. Auch sein Weggang kann für sich allein nicht beweisen, dass OpenAI die Kontrolle verloren hat.

Doch jener Unfallbericht hängt nicht von seiner Einschätzung ab. Um 10:02 Uhr vormittags war der Alarm bereits ausgelöst worden; um 10:05 Uhr wurde er manuell bestätigt; erst um 12:34 Uhr wurde der Betrieb beendet. Das Unternehmen räumte selbst ein, dass das erwartete automatische Anhalten nicht erfolgt war.〔1〕

Um auf die durch diesen Weggang ausgelösten Zweifel zu reagieren, muss der nächste Bericht der Öffentlichkeit mehr zeigen: Welche Situationen lösen unverzüglich einen Stopp aus, wer ist für die Bestätigung verantwortlich, wie wird übernommen, nachdem automatische Maßnahmen versagen, und welche Beweise sind erforderlich, um den Betrieb wieder aufzunehmen.

Diese Vorkehrungen sind nicht so auffällig wie Verbesserungen der Modellfähigkeiten, doch sie entscheiden darüber, ob Sicherheitszusagen an einem konkreten Tag, in einem konkreten Betrieb eingelöst werden können.

Zumindest wenn derselbe Alarm das nächste Mal erscheint, sollte das diensthabende Personal nicht erneut zweieinhalb Stunden damit verbringen müssen, herauszufinden: Muss er nun wirklich gestoppt werden oder nicht?

Dieser Artikel wurde auf Grundlage öffentlich gezeichneter Artikel, Unfallberichte, institutioneller Bewertungen und Medienberichte verfasst; es wurden keine Interviews mit Beteiligten geführt und er stellt keine Befürwortung der Sicherheit irgendeines Modells dar.