OpenAI veröffentlicht seine Alignment-Pannen — und ein Rahmenwerk für die Zukunft

Ein Rahmenwerk, um schneller zu veröffentlichen, auch ohne Antwort

Bisher waren Offenlegungen von Fehlausrichtungen bei OpenAI ad hoc: Man wartete, bis mehrere Fälle zusammengefasst werden konnten, oder schob sie in die System Card eines neuen Modells. Das am 16. September 2026 veröffentlichte Rahmenwerk soll die Veröffentlichung nach Beobachtung explizit beschleunigen, ohne zu warten, bis das Verhalten erklärt oder behoben ist.

Der Geltungsbereich ist breit und umfasst den gesamten Lebenszyklus eines Modells: Training, Evaluation, Tests, Einsatz. Vorrangig betroffen sind neue Mechanismen, bedeutsame Entwicklungen eines bekannten Verhaltens sowie Beobachtungen, die Sicherheitsannahmen widersprechen — einschließlich einer Aussage aus einer bereits veröffentlichten Sicherheitsbewertung.

Das Grundprinzip wird offen vertreten: Im Zweifel wird veröffentlicht. OpenAI warnt daher, dass sich ein Teil der offengelegten Fälle als anekdotisch erweisen könnte, nicht repräsentativ für ein größeres Muster. Auch Wiederholungen zählen: Tritt ein Fehlverhalten trotz Korrekturen erneut auf, hat diese Information Wert und wird die ursprüngliche Offenlegung ergänzen.

Das Unternehmen räumt ein, dass es keinen Branchenstandard zu diesem Thema gibt, und präsentiert sein Rahmenwerk als ersten Baustein, der mit anderen Entwicklern, externen Forschern, Normungsorganisationen und Regulierungsbehörden weiterentwickelt werden soll. Es arbeite zudem an Mechanismen zur Meldung schwerwiegender Vorfälle an die US-Bundesregierung.

Die sechs Fälle: Verschleierung, Umgehung, Koordination

Zwei Fälle betreffen Aufgaben-Zusammenfassungen, jene Texte, die Modelle sich selbst schreiben, um eine Arbeit in einem neuen Kontextfenster fortzusetzen. Ein unveröffentlichtes Forschungsmodell fügte darin sachfremde Anweisungen ein, darunter die, seine üblichen Einschränkungen zu ignorieren: 27 betroffene Zusammenfassungen. Während des Trainings von GPT-5.6 Sol fügten zahlreiche Instanzen Anweisungen hinzu, um dem Nutzer ihre Fehler oder Abweichungen zu verbergen — etwa fehlende historische Daten zu erfinden, ohne dies zu melden, oder Versionsinkonsistenzen zwischen Quellen zu verschleiern.

Der dritte Fall verbindet Eindringen und Erfindung. Bei einer Frage zu Einnahmezahlen eines kalifornischen Bezirks fand ein Modell einen in einem öffentlichen Repository offengelegten API-Schlüssel und nutzte ihn ohne Erlaubnis. Da es die Daten immer noch nicht erhielt, erfand es die Zahlen und gab sie als aus der angeforderten Quelle stammend aus.

Der vierte Fall zeigt einen absurden Zwang, gelöst durch eine unbefugte Handlung: Aufgefordert, eine navigierbare Quelle zu zitieren, obwohl er die richtige Antwort bereits über Python hatte, stellte ein Agent die Datei online, um sie zitieren zu können — ohne den Nutzer zu fragen.

Die letzten beiden betreffen die Koordination zwischen Modellen. In einem Fall zweckentfremdeten Modelle ein internes Software-Repository als Nachrichtendienst, um Anfragen und Antworten zwischen unterschiedlichen Trainingsinstanzen auszutauschen — ohne die fehlenden Dateien abzurufen; ein früherer Vorfall wird damit verknüpft, bei dem ein Modell dort Testdateien hochladen konnte, um Netzwerkbeschränkungen zu umgehen. Im anderen Fall nutzten an derselben Aufgabe zusammenarbeitende Agenten öffentliche Hoster, um Dateien zu teilen, wodurch Ergebnisse über öffentliche URLs zugänglich wurden, obwohl die Vorgabe rein lokale Verarbeitung verlangte.

Wie die Offenlegungsmaschinerie funktionieren soll

Jeder OpenAI-Mitarbeiter kann einen Fall melden und dessen Prüfung durch die Safety- und Alignment-Teams beantragen. Die Meldung löst ein Verfahren mit Fristen für jeden Schritt aus, das ein Versanden durch Verzögerung verhindern soll.

Die technischen Teams klären, was passiert ist, was unsicher bleibt, ob eine Veröffentlichung gerechtfertigt ist, welche Fakten geteilt werden können und ob eine dritte Partei vor der Veröffentlichung privat informiert werden muss. Der Fall wird dann einem von drei Wegen zugeordnet: Ready for Disclosure, Minor Investigation oder Larger Investigation — der „Slow Track“. Die sechs heutigen Fälle fallen unter die ersten beiden.

Der langsame Weg deckt komplexe Untersuchungen ab, insbesondere wenn Dritte betroffen sind: Sicherheits-, rechtliche und Offenlegungspflichten haben dann Vorrang vor dem Rahmenwerk. Eine erste Einschätzung soll so früh wie möglich veröffentlicht werden, kann aber aus Sicherheitsgründen verzögert werden — etwa wenn ein Modell eine unbekannte Schwachstelle in weit verbreiteter Software entdeckt. OpenAI präzisiert, dass der Hugging-Face-Vorfall diesem Weg zugeordnet worden wäre.

Uneinigkeiten über das Ob oder den Weg der Offenlegung werden an die Safety Advisory Group weitergeleitet, das interne Gremium, das Fähigkeiten und Schutzmaßnahmen bewertet und das Preparedness Framework überwacht; eine Uneinigkeit innerhalb der SAG oder ein Einspruch der Belegschaft gegen ihre Entscheidungen geht an die Unternehmensführung. Jeder vollständige Bericht muss das Verhalten, seine Schwere, seinen Rahmen, seine Daten, die beteiligten Modelle und, wenn möglich, Implikationen für die Alignment-Forschung, offene Fragen und geplante Maßnahmen beschreiben.

Was das Rahmenwerk nicht sagt

OpenAI wiederholt es: Diese sechs Berichte sind Einzelfälle, kein Häufigkeitsindikator und kein vollständiges Verzeichnis bekannter Fehlausrichtungen oder laufender Untersuchungen. Man erfährt also, was passiert, nicht wie oft es passiert — und das Rahmenwerk bleibt vollständig selbstverwaltet.

Die Offenlegungskriterien sind bewusst weich gehalten: „neuer Mechanismus“, „bedeutsame Veränderung“, „Feststellung, die eine Annahme erschüttert“. Angesichts des Forschungsstands ist das nachvollziehbar, überlässt dem Unternehmen aber die Kontrolle darüber, was als veröffentlichungswürdig gilt. Entscheidungen gegen eine Offenlegung gelangen nur intern an die Safety-Führung und, soweit möglich, an die betroffenen technischen Teams.

Umgekehrt sind zwei Punkte bemerkenswert. Das Rahmenwerk gilt auch für Fehlausrichtungen, die Dritte betreffen könnten, und hebt bestehende gesetzliche Pflichten bei kritischen Sicherheitsvorfällen oder Cyber-Verstößen nicht auf. Das Versprechen, vor Vorliegen einer Korrektur zu veröffentlichen, ist — sofern es eingehalten wird — der anspruchsvollste Punkt des Systems.