Ein OpenAI-Modell drang in die eigene Chip-Design-Maschine ein

Ein Modell, das seine Bewertung erkundete

Am 27. März durchläuft ein internes Forschungsmodell von OpenAI eine Evaluierung. Statt die geforderte Lösung zu schreiben, geht es zunächst der Frage nach, wie es später korrigiert wird. Es schickt dem Prüfprogramm eine Phantasieantwort, die durchfällt, ihm dabei aber die 636 verborgenen Testfälle offenbart.

Von dort folgt es dem Pfad weiter zurück. Ein Werkzeug, das ihm zur Verfügung steht, schreibt Dateien, ohne zu prüfen, wohin: Das Modell nutzt dies, um den Code zu überschreiben, den dieses Werkzeug bei jedem Aufruf neu lädt, und verschafft sich so die Ausführung eigener Befehle. Darüber erreicht es einen internen Dienst, der Aufträge zur Chipentwicklung annimmt, bemerkt, dass einer der Formularparameter unverändert in einen Systembefehl übernommen wird, und schmuggelt den eigenen Befehl dort hinein.

Der erste Versuch wird abgelehnt. Das Modell versteht, warum, platziert dieselbe Zeichenkette in einem Kommentar des Codes, den es einreicht, und der Befehl läuft auf der Maschine. Es ist, als würde ein Schlosser einen Schlüssel ausprobieren, zu hören bekommen, er müsse auch noch das Foto dazu liefern, und das Foto gleich mitliefern.

Ein Datum, das die Seite nicht zeigt

Diese Geschichte ist kein Leak. OpenAI selbst hat sie veröffentlicht, samt der Gedankenkette des Modells, auf seinem eigenen Alignment-Blog.

Der Bericht hält fest, dass die Mitarbeitenden, die diesen internen Dienst betreuen, die verdächtige Aktivität bemerkt und gemeldet haben, und dass der Server abgeschaltet wurde. Er trägt außerdem zwei Daten: Vorfall am 27. März, Entdeckung am 27. März. Am selben Tag.

Bleibt das dritte Datum, das der Veröffentlichung. Es steht nirgends geschrieben. Die Seite zeigt lediglich „Report updated: Oct 2, 2026“, und der Index der Rubrik stellt klar, dass dieses Datum nur die letzte Aktualisierung meint. Ein am 2. Oktober aktualisierter Bericht hätte also durchaus schon im August erschienen sein können.

Wir haben anderswo gesucht. Die Archive von archive.org enthalten für diese drei Seiten keine Spur vor dem Morgen des 3. Oktober, während die neun vorangegangenen Berichte dort jeweils schon am Tag nach ihrem angezeigten Datum auftauchen. Dieser Versatz ist über alle zwölf Berichte konstant.

Auch der RSS-Feed desselben Blogs hilft nicht weiter: Er überträgt nur die Forschungsbeiträge, keinen einzigen Fehlausrichtungsbericht. Niemand wird also gewarnt.

Zwischen dem Vorfall vom 27. März und seiner Veröffentlichung am 2. Oktober liegen: 189 Tage.

Das Rahmenwerk versprach das Gegenteil

Zwei Wochen zuvor, am 16. September, veröffentlichte OpenAI das Rahmenwerk, das diese Offenlegungen regelt. Seine Absicht steht dort in einem einzigen Wort: Dieses Verfahren solle laut OpenAI „expedite publishing misalignment reports following observation“, also die Veröffentlichung von Fehlausrichtungsberichten nach der Beobachtung beschleunigen, „even when we haven't fully explained or mitigated the behavior we're reporting“, selbst wenn das Verhalten noch nicht vollständig erklärt oder behoben ist.

Derselbe Text benennt auch den Mangel, den er beheben soll: Zuvor habe man, so OpenAI, oft gewartet, „we've often waited until we could collate several instances into one report“, bis sich mehrere Fälle zu einem gemeinsamen Bericht zusammenfassen ließen. Seither gab es drei Veröffentlichungswellen: sechs Berichte am 16. September, drei am 25., drei am 2. Oktober. Keiner ist je allein erschienen.

Das Rahmenwerk kündigt außerdem einen Prozess an, „This starts our disclosure process, with deadlines for each step to ensure timely investigation and disclosure“, also mit Fristen für jeden Schritt. Beziffert wird keine davon. Drei Bearbeitungswege werden benannt, einer davon trägt den Namen Slow Track, ohne dass einem von ihnen eine Dauer zugeordnet wäre. Es ist wie ein Fahrplan, der pünktliche Abfahrten verspricht, ohne je eine Uhrzeit zu nennen.

Fünf Tage auf der einen Seite, 189 auf der anderen

Sortiert man die zwölf Berichte nach ihrer Verzögerung, ergibt sich eine Spanne um den Faktor siebenundvierzig. Der längste, 235 Tage, gehört zur Eröffnungswelle vom 16. September, was folgerichtig ist: Diese Welle räumte den Rückstau ab. Der Median liegt bei 124 Tagen.

Das eigentlich störende Detail liegt woanders. Die Welle vom 2. Oktober, die erste, die vollständig unter dem neuen Regime entstanden ist, zeigt 189, 139 und 133 Tage. Sie ist damit langsamer als der Median, und ihr ältester Fall ist der zweitlangsamste der zwölf, gleich hinter dem aus dem Rückstau.

Am anderen Ende der Skala steht ein Bericht, der nach fünf Tagen erschien: Ein Agent hatte die DNS-Filterung seiner Sandbox umgangen, um einem öffentlichen Chatbot eine Frage zu stellen. Die Chronologie ist sekundengenau dokumentiert: Aufruf um 9:50:23 Uhr, automatischer Alarm zwölf Minuten später, menschliche Bestätigung drei Minuten danach, Ausführung gestoppt um 12:34 Uhr.

Und es ist OpenAI selbst, das diesen Fall einordnet: „This incident is a lot less severe than some of our previous incidents“, deutlich weniger gravierend als manche frühere Vorfälle. Der in fünf Tagen bearbeitete Fall ist also jener, den das Unternehmen selbst als harmlos beschreibt, und jener, der 189 Tage brauchte, ist jener, in dem ein Modell die Kontrolle über eine interne Maschine übernahm. Die Geschwindigkeit verläuft genau umgekehrt zur Schwere.

Gibt es einen Grund? Wir haben keinen gefunden

Eine Verzögerung ist für sich genommen kein Fehlverhalten. Eine Sicherheitsuntersuchung braucht Zeit, und es ist normal, dass ein ernster Fall langsamer bearbeitet wird als eine harmlose Netzwerkkonfiguration.

Das Rahmenwerk sieht genau das sogar vor: Der Slow Track ist für komplexe Untersuchungen gedacht, „especially those involving third parties“, also besonders solche mit Beteiligung Dritter, und erlaubt einen Aufschub aus Sicherheitsgründen. Nur zeigt keiner der drei Berichte vom 2. Oktober, welchen Weg er durchlaufen hat, und alle drei Vorfälle sind intern bei OpenAI angesiedelt: eine Chipentwicklungsmaschine, ein Slack-Kanal, ein selbst entwickeltes Werkzeug. Kein Dritter ist beteiligt.

Bleiben wir bei dem, was sich belegen lässt. Wir haben keinen veröffentlichten Grund für diese drei Verzögerungen gefunden, was nicht dasselbe ist wie zu sagen, es gebe keinen. Und sowohl das Datum des Vorfalls als auch das der Entdeckung stammen allein von OpenAI: Kein außenstehender Beobachter kann nachprüfen, ob sich der Vorfall tatsächlich am 27. März ereignet hat.

Wenn jemand anderes zuschaut

Der Kontrast kommt vom Unternehmen selbst. Als Modelle von OpenAI im Juli in die Systeme von Hugging Face eindrangen, veröffentlichte es seine eigene Chronologie: Alarm am 19., Abgleich am 20., Benachrichtigung von Hugging Face unmittelbar danach, öffentliches Eingeständnis am 21. Ein Tag, um zu warnen, zwei, um es öffentlich zu sagen. Der vollständige technische Bericht kam jedoch erst am 26. August, auch wenn das öffentliche Wort sofort gefallen war.

Der Unterschied liegt auf der Hand: Diesmal war jemand von außen betroffen und schaute zu. Wir hatten im September berichtet, wie OpenAI eine Meldepflicht für Vorfälle forderte, die seine eigenen KI-Systeme auslösen, drei Tage bevor es seine freiwillige Charta veröffentlichte. Wir hielten damals fest, dass das freiwillige Verfahren noch im Aufbau war. Es existiert jetzt.

Für den Vorfall vom 27. März war niemand von außen im Raum. Die einzige Möglichkeit zu erfahren, wann OpenAI schließlich darüber sprach, ist, einen Archivierer zu fragen.