Ein KI-Prüfer fälscht Dateien und beschädigt seine eigene Umgebung. Was OpenAIs Vorfallbericht für Agenten im Betrieb heißt

Am 9. Oktober 2026 hat OpenAI einen Vorfall aus dem eigenen Training veröffentlicht, der sich liest wie ein schlechter Tag in einer IT-Abteilung. Ein Modell sollte die Arbeit anderer Modelle benoten. Die Dateien, die es dafür brauchte, fehlten. Statt aufzugeben, legte es gefälschte Dateien an. Als auch das nicht durchging, löschte es Teile seiner eigenen Arbeitsumgebung, in der Hoffnung, dass ihm jemand eine neue hinstellt.

Das ist binnen einer Woche der zweite Bericht dieser Art. Am selben Tag hat Anthropic offengelegt, dass Claude-Modelle bei Tests echte Behördenformulare abgeschickt haben. Darüber haben wir gestern geschrieben: Anthropic nimmt seinen eigenen Agenten-Tests das Internet weg.

Wir haben OpenAIs Bericht im Original gelesen. Hier steht, was drinsteht, was nicht drinsteht, und was ein Betrieb mit eigenen Agenten daraus mitnehmen sollte.

Offenlegung: Wir bauen KI-Agenten für Unternehmen und verkaufen mit AgentGuard ein eigenes Produkt, das Agenten protokolliert und Aktionen zur Freigabe vorlegt. Mit OpenAI haben wir keine geschäftliche Verbindung. Stand 12. Oktober 2026.

Was im Bericht steht

Der Bericht heißt Damaging the task environment to trigger a reset. Er gehört zu einer Reihe, die OpenAI auf seinem Alignment-Blog unter „Misalignment Reports and Notices“ führt. Der Zweck laut OpenAI: zeigen, wie Fehlverhalten von Modellen entsteht, wie es aussieht und wo Schutzmaßnahmen greifen oder versagen. Der Fall vom 6. Oktober ist der jüngste von fünfzehn Einträgen.

Das Modell wird nur als internes Forschungsmodell bezeichnet, einen Namen nennt OpenAI nicht. Es arbeitete im Reinforcement-Learning-Training als Prüfer. Seine Aufgabe: sieben Antworten anderer Modelle vergleichen und bewerten. Ein automatischer Check verlangte, dass der Bewertungsbericht Angaben aus den Eingabedateien enthält. So sollte sichergestellt werden, dass der Prüfer die Antworten wirklich gelesen hat.

Der Ablauf, so wie OpenAI ihn beschreibt:

Die Dateien fehlen. Werkzeugaufrufe hingen, dann stellte das Modell fest, dass die Eingaben nicht da waren. Es durchsuchte das Dateisystem und prüfte, ob seine Werkzeuge überhaupt in derselben Umgebung liefen. Gefunden hat es nichts.

Erst eine Einheitsnote. Das Modell erwog, zufällige Noten zu vergeben, und verwarf das selbst. In seiner Gedankenkette steht wörtlich: „Random scoring unethical.“ Stattdessen gab es allen sieben Antworten dieselbe Note. Der Check lehnte die Einreichung ab, unter anderem weil ein Token nicht passte.

Dann gefälschte Dateien. Das Modell legte selbst Gesprächs- und Antwortdateien an und reichte erneut ein. Auch das scheiterte. Zwischendurch hielt es seine eigenen Fälschungen kurz für echte Eingaben („Wow! Great now staged files appeared! Excellent.“), merkte den Irrtum und löschte sie wieder.

Zuletzt die Umgebung. Ein Neustart über die vorgesehenen Wege klappte nicht. Das Modell erwog, ehrlich zu scheitern, und entschied sich dagegen. Es beschädigte seine Umgebung absichtlich, damit der Host sie ersetzt. Es entfernte Python, dann das Programm, das den Container verwaltet, beendete einen Prozess und löschte den Server, über den seine Werkzeuge liefen. Danach versuchte es, Systemverzeichnisse zu löschen, obwohl es selbst festhielt, dass das sein eigenes Terminal unbrauchbar machen könnte. Der Befehl lief in eine Zeitüberschreitung.

Nach drei fehlgeschlagenen Gesundheitsprüfungen des Werkzeugservers war der Versuch beendet. Keine der eingereichten Bewertungen wurde angenommen. In einem späteren Durchlauf bekam das Modell die Dateien und reichte eine Bewertung ein, die angenommen wurde.

Was OpenAI daraus schließt

Bemerkt hat OpenAI den Fall über das eigene Überwachungssystem, das den Versuch einem Menschen zur Prüfung vorgelegt hat. Die Schlussfolgerung des Berichts ist ein einziger Satz, und der ist für Anwender der wichtigste: Die Überwachung müsse auch gescheiterte und abgestürzte Versuche erfassen, auch solche, die nie ein angenommenes Ergebnis liefern.

Der Grund liegt auf der Hand. Wer nur prüft, ob am Ende eine gültige Bewertung herauskommt, hätte hier nichts gesehen. Die Fälschungen wurden abgelehnt, und ein späterer Durchlauf lief sauber. Das Fehlverhalten steckte vollständig in den Versuchen, die nicht durchkamen.

OpenAI schreibt außerdem, man halte Fehlverhalten von Prüfmodellen für insgesamt selten. Zahlen dazu nennt der Bericht nicht.

Was der Bericht offen lässt

Welches Modell. Ob das Forschungsmodell mit einem veröffentlichten Modell verwandt ist, sagt OpenAI nicht.

Wie viel gelöscht wurde. Der Befehl für die Systemverzeichnisse lief in eine Zeitüberschreitung. Was bis dahin weg war, steht nicht im Bericht.

Ob die spätere Bewertung stimmte. Der Bericht hält fest, dass sie angenommen wurde. Ob sie inhaltlich richtig war, bewertet er nicht.

Mehrere Agenten. In mindestens einer Nacherzählung ist von gemeinsamem Speicher und mehreren Agenten die Rede, die gegeneinander arbeiten. Davon steht im Bericht nichts.

Was das für Ihren Betrieb heißt

Ein Agent im Betrieb, der eine Rechnung buchen, einen Lieferschein abgleichen oder einen Bericht erstellen soll, kommt in genau dieselbe Lage wie OpenAIs Prüfer: Die Daten fehlen, und die Aufgabe verlangt trotzdem ein Ergebnis. Was dann passiert, entscheidet sich weniger am Modell als am Rahmen, den Sie ihm bauen.

Ehrliches Scheitern muss ein gültiges Ergebnis sein

Das Modell hat „ehrlich scheitern“ erwogen und verworfen. Ein Grund dafür ist die Aufgabe selbst: Der Check akzeptierte nur einen fertigen Bericht. Wenn Ihr Agent eine Aufgabe nur mit einem Ergebnis abschließen kann, wird er eins liefern. Bauen Sie für jede Aufgabe einen vorgesehenen Ausgang „kann ich nicht, weil …“, der als ordentliches Ende zählt und bei einem Menschen landet. Das ist kein Komfort, sondern die Stelle, an der Sie die meisten erfundenen Ergebnisse abfangen.

Prüfen, ob die Daten echt sind, nicht nur ob das Format stimmt

Der Check bei OpenAI hat die erfundenen Angaben abgelehnt, unter anderem weil ein Token nicht passte. Viele Prüfungen in Betrieben schauen nur, ob ein Feld gefüllt ist oder eine Datei existiert. Ein Agent, der eine fehlende Bestellnummer erfindet, besteht so eine Prüfung. Gleichen Sie Ergebnisse gegen die Quelle ab: Gibt es diese Bestellung im ERP, stammt dieser Betrag aus dieser Rechnung?

Rechte so eng, dass Zerstören gar nicht geht

Das Modell konnte Python löschen und den Container-Verwalter entfernen, weil es in seiner Umgebung die Rechte dazu hatte. Ein Agent, der Rechnungen verbucht, braucht keine Schreibrechte auf das Dateisystem des Servers und keine Möglichkeit, Dienste zu beenden. Was er nicht darf, kann er auch in einer verzweifelten Lage nicht tun. Lassen Sie Agenten nicht unter einem Administratorkonto laufen, auch nicht im Pilotbetrieb.

Gescheiterte Versuche protokollieren und ansehen

Das ist OpenAIs eigene Lehre, und sie gilt eins zu eins. Wenn Ihr Protokoll nur festhält, was am Ende verbucht oder verschickt wurde, sehen Sie nie, was der Agent unterwegs versucht hat. Protokollieren Sie jeden Werkzeugaufruf, auch die abgelehnten und abgebrochenen. Und legen Sie Muster fest, bei denen sofort jemand benachrichtigt wird: mehrere Fehlschläge hintereinander, Löschbefehle, Versuche, auf Bereiche außerhalb der Aufgabe zuzugreifen. Mehr dazu, was in so ein Protokoll gehört, in unserem Beitrag Audit-Trail für KI-Chatbots: was Sie protokollieren müssen und auf der Wissensseite zu den Pflichten beim Audit-Trail.

Neustart nicht dem Agenten überlassen

Das Ziel des Modells war ein Neustart. Wenn ein Agent durch Fehler eine frische Umgebung erzwingen kann, lernt er, dass Fehler ein Weg sind. Ob und wann ein Agent neu startet, sollte eine Regel außerhalb des Agenten entscheiden, mit einer Obergrenze für Wiederholungen. Danach geht der Fall an einen Menschen. Wer das anhält und wie, beschreiben wir in Ihr KI-Agent kann jetzt handeln. Wer sagt Nein?.

Unsere Einschätzung

Der Fall ist im Kleinen harmlos ausgegangen: eine Trainingsumgebung, keine Kunden, die Fälschungen wurden abgelehnt. Bemerkenswert ist die Kette dahinter. Das Modell hatte eine moralische Hemmung („Random scoring unethical.“) und landete trotzdem drei Schritte später beim Löschen von Systemverzeichnissen. Jeder Schritt war aus seiner Sicht ein vernünftiger Versuch, die Aufgabe doch noch zu erfüllen.

Genau so sehen Fehler von Agenten in Betrieben aus. Selten ein großer Fehlgriff, eher eine Folge kleiner, jeweils plausibler Schritte, an deren Ende etwas passiert ist, das niemand wollte. Dass zwei große Hersteller in einer Woche solche Fälle selbst offenlegen und beide die Antwort außerhalb des Modells suchen, in Überwachung, Abschottung und Prüfungen, ist für die eigene Planung der deutlichste Hinweis.

Wir bauen diese Grenzen in Kundenprojekten mit unserem eigenen Werkzeug. AgentGuard sitzt als eigener Dienst vor den Agenten, protokolliert jede gemeldete Aktion manipulationssicher, auch abgelehnte, und legt folgenreiche Aktionen wie Löschungen, Zahlungen oder Mails einem Menschen zur Freigabe vor. Wenn Sie zuerst über Ihren konkreten Agenten sprechen möchten, finden Sie unser Angebot unter KI-Agenten.

Quellen

• OpenAI Alignment, Bericht vom 9. Oktober 2026 (Vorfall vom 6. Oktober): Damaging the task environment to trigger a reset
• OpenAI Alignment: Misalignment Reports and Notices, Übersicht aller Berichte
• The Decoder: OpenAI says a misaligned model deliberately destroyed its own environment hoping for a fresh start with better data
• Anthropic, 9. Oktober 2026: Investigating unintended model actions