OpenAI hat am 28. September einen Entwurf für Safety Cases bei Frontier-Reinforcement-Learning veröffentlicht. Vor dem Fortsetzen eines Frontier-RL-Runs soll eine strukturierte Sicherheitsbegründung stehen, die technische Schutzmaßnahmen, Restrisiken und operative Freigaben zusammenführt.
OpenAI bezeichnet vollständige Safety Cases noch als Zielbild. Die veröffentlichten Regeln seien derzeit in Umsetzung und würden sich in den kommenden Wochen weiter verändern. Es handelt sich damit noch nicht um einen extern auditierten Standard.
Monitoring soll einen Trainingslauf technisch stoppen können
OpenAI trennt die technischen Schutzmaßnahmen in Alignment, Containment und Monitoring. Bekannte Vorfälle sollen als zurückgehaltene Tests dienen, damit geprüft werden kann, ob ein Monitor frühere Fehlermodi tatsächlich erkannt hätte. Für neue Risiken sollen laufend neue Eval-Daten hinzukommen.
Monitoring und Auto-Pause sollen laut Entwurf „fail closed“ funktionieren. Ein Trainingslauf soll nicht starten können, wenn die vorgesehenen Kontrollen fehlen. Die Kontrollschicht soll auch nicht aus dem normalen Trainingsablauf heraus deaktivierbar sein.
Für Alarme nennt OpenAI definierte Reaktionszeiten als Beispiel. Tagsüber könnten Security-On-Call und Run-Owner benachrichtigt werden; nachts könnte ein nicht bestätigter Alarm den Lauf automatisch pausieren.
Diese Forderung passt zu OpenAIs jüngsten Incident-Berichten. Dort funktionierte die Erkennung problematischer Agentenaktivität teilweise schneller als die anschließende technische Unterbrechung des Laufs.
Sandbox und Forschungsinfrastruktur werden getrennt betrachtet
Für Containment verlangt OpenAI mehrere Sicherheitsschichten. Neben der eigentlichen Sandbox soll auch die Forschungsinfrastruktur gehärtet werden, auf der sie läuft.
Der Entwurf fordert außerdem Sicherheitsprüfungen aller Dienste, die ein Modell während des Trainings erreichen kann. OpenAI nennt Internet-Caches als Beispiel. Hilfsdienste, Resolver und Proxies gehören damit ausdrücklich zur Sicherheitsgrenze und nicht nur der Prozess, in dem das Modell arbeitet.
Kommunikation zwischen parallelen Samples soll auf freigegebene Kanäle begrenzt werden. Gleichzeitig sollen Transkripte aus Training, Evals und internen Deployments unveränderlich gespeichert werden, beispielsweise in Write-once-Speicher. Das soll spätere Incident-Untersuchungen verlässlicher machen.
Training soll den eigenen Monitor nicht schwächen
Ein konkreter Punkt betrifft Chain-of-Thought-Daten. OpenAI empfiehlt, automatischen RL-Gradern die interne Reasoning-Spur nicht zu zeigen.
Die Begründung ist ein möglicher Rückkopplungseffekt: Wenn Trainingssignale direkt davon abhängen, welche internen Muster ein Monitor erkennt, könnte das Training Verhalten begünstigen, das für den Monitor schlechter sichtbar ist.
Zusätzlich sollen Labs Eval-Awareness und Metagaming messen. Dafür fordert OpenAI explizite Blocking-Schwellen. Worst-Case-Tests sollen prüfen, ob mindestens eine Evaluation problematisches Verhalten zuverlässig erkennt.
Konkrete Schwellenwerte veröffentlicht OpenAI in diesem Dokument nicht. Auch ein vollständiger Safety Case eines aktuellen Frontier-Runs liegt nicht öffentlich vor.
Mehrere Führungskräfte sollen einen Run stoppen können
Der operative Teil betrifft den Freigabeprozess. OpenAI schlägt vor, dass mehrere leitende Personen einen Frontier-Run jeweils per Veto stoppen können. Als Beispiele nennt das Unternehmen den Research-Leiter beziehungsweise VP, den Head of Safety und den Chief Scientist.
Der für einen Run verantwortliche Senior Leader soll für Safety Case und Incident Response verantwortlich sein. OpenAI nennt ausdrücklich auch die Leistungsbewertung als möglichen Ort für diese Verantwortlichkeit.
Vor der Freigabe soll eine Person aus einem anderen Team einen Gegenentwurf beziehungsweise ein Pre-Mortem schreiben und nach Schwachstellen im Safety Case suchen. Auditoren sollen ausreichend Zugriff erhalten, um Aussagen überprüfen zu können.
Wie unabhängig diese Auditoren sein müssen, legt OpenAI bislang nicht fest. Die Regeln sind deshalb derzeit eine überprüfbare Selbstverpflichtung, aber noch kein Nachweis ihrer Wirksamkeit.
Aus Incidents sollen Regressionstests entstehen
OpenAI fordert Root-Cause-Analysen, operative Postmortems und regelmäßige interne Updates während längerer Untersuchungen.
Aus einem Incident soll anschließend ein Regressionstest entstehen. Forscher sollen Tests entwickeln, die dieselbe Verhaltensneigung erkennen können, ohne ausschließlich auf den bekannten Einzelfall zu optimieren. Zusätzlich können incident-spezifische Tests verhindern, dass derselbe Fehlermodus später unbemerkt zurückkehrt.
OpenAI sagt außerdem, dass betroffene Dritte möglichst schnell informiert und abgeschlossene Untersuchungen öffentlich gemacht werden sollen.
Der Maßstab für den neuen Prozess liegt deshalb nicht in der Länge der Safety-Dokumentation. Prüfen lässt sich künftig, ob ein Run bei fehlenden Nachweisen tatsächlich pausiert wird, ob Veto-Rechte genutzt werden können und ob die vorgesehenen Eskalationen unter realen Betriebsbedingungen funktionieren.