Die Luftfahrt wurde nicht sicher, indem man prüfte, ob jeder Bolzen seine Nennlast halten konnte. Sie wurde sicher, indem man fragte, wie Teile interagieren, wer was befehlen darf und wie reale Operationen von den im Sicherheitsfall angenommenen Bedingungen abweichen. Diese Disziplin ist Systems Safety. Ihr Werkzeugkasten umfasst STPA, FRAM und STECA, Methoden, die regulierte Industrien bereits vorschreiben.

KI-Sicherheit hat sie größtenteils nicht importiert. Ein Paper von 2026 tut es.

Luca Carlucci, James Fillingham, Robert Walpole und Bartłomiej Kryś wenden diese drei Methoden auf einen frontier Coding-Agenten in einem realistischen Produktionssetup (Labor, Unternehmenskunde, Entwickler) an in "Ein Systemdenken-Ansatz zum Risiko des Kontrollverlusts durch fortgeschrittene KI" (arXiv:2606.13474; ICML 2026 Technical ASI Governance Workshop). Sie finden drei Gefahren, die gewöhnliche Modelltests nie erfassen sollten.

Die drei Methoden, in einfacher Sprache

STPA
Systemtheoretische Prozessanalyse
Karten, wer was befiehlt, wer was überwacht und wo welche Informationen fließen. Findet Wege, auf denen Kontrolle versagt, selbst wenn jede Komponente wie vorgesehen funktioniert.
FRAM
Funktionale Resonanz-Analysemethode
Behandelt das System als gekoppelte Funktionen, nicht als Teileliste. Zeigt, wie gewöhnliche alltägliche Variationen zu einem schlechten Systemergebnis zusammenwirken können.
STECA
Sozio-technische Evaluation für kritische Anwendungen
Erweitert STPA auf Menschen, Anreize und Institutionen. Verfolgt Verantwortungslücken, die zwischen Organigrammen und Code liegen.

Das Szenario, das sie verwendet haben

Sie haben alle drei Methoden an einem frontier Coding-Agenten in produktiver Softwarearbeit getestet: langfristig, toolnutzend, mit echten Codebasen und externen Diensten, beaufsichtigt von einem Labor, Unternehmenskunden und Entwicklern. So werden diese Systeme bereits ausgeliefert. Das Risiko des Kontrollverlusts auf Systemebene ist noch kaum analysiert.

Drei Erkenntnisse, die Modellbewertungen übersehen

Erkenntnis 1
Niemand außerhalb des Labors kann die Sicherheitsgeschichte überprüfen

In ihrem Setup gibt das Labor die Sicherheitszusagen ab, schreibt die Nutzungsregeln und überwacht Verstöße. Regulierer, Kunden und Prüfer können die Abläufe nicht unabhängig kontrollieren. Selbstberichte bilden den Haupt-Feedbackkreislauf.

STECA kennzeichnet das als defekte Kontrollstruktur. Eine Kontrollhandlung funktioniert nur, wenn jemand sehen kann, ob sie gewirkt hat. Wenn die für Sicherheit verantwortliche Partei zugleich die Hauptquelle des Nachweises ist, dass Sicherheit gegeben ist, ist die Schleife kompromittiert. Das ist eine Design-Tatsache, keine Behauptung, dass irgendein bestimmtes Labor unehrlich ist.

Erkenntnis 2
Überwachung ist zu langsam, um einzugreifen

STPA bildet die Lücke zwischen dem Handeln eines Agenten und einem Menschen, der erfährt, dass er gehandelt hat. Bei mehrstufigen Echtzeitläufen hat der Agent oft bereits ein Tool aufgerufen, Code geschrieben oder eine Änderung gepusht, bevor ein Prüfer den Alert sieht.

In der Luftfahrt nennt man das, aus der Schleife zu gehen. Formale Autorität, das System zu stoppen, bleibt auf dem Papier. Funktionale Autorität hält nicht Schritt. So könnte die Echtzeit-Überwachung von Frontier-Codieragenten heute aussehen.

Erkenntnis 3
Sicherheitsvorkehrungen veralten stillschweigend

FRAM konzentriert sich auf gewöhnliche Variation. Safeguards werden auf den Zustand des Systems zum Zeitpunkt der Einführung abgestimmt. Dann ändern sich Prompts, die Aufgabenmischung ändert sich, Randfälle häufen sich, und die reale Verteilung entfernt sich von der Stichprobe, die beim Start verwendet wurde.

Nichts alarmiert. Die Schutzmaßnahmen tun noch genau das, wofür sie gegen die Bedingungen von gestern entwickelt wurden. Die Lücke wächst still, bis ein neuartiger Fall auf eine Regel trifft, die nicht mehr passt.

Was das für die Governance bedeutet

Modelltests fragen, was das System bei bestimmten Eingaben tut. Sie kartieren nicht die Kontrollstruktur darum herum, wer wofür verantwortlich ist oder wie sich der Betrieb nach der Freigabe verändert. Capability-Scores und Red Teams bleiben notwendig. Sie reichen nicht aus.

Die Forderung des Papiers ist einfach: Modellbezogene Gefahrenanalyse und systembezogene Gefahrenanalyse müssen als verpflichtender Bestandteil der Sicherheitsbewertung gekoppelt werden. STPA, FRAM und STECA sind ein konkreter Anfang. Hochskaliert von einem einzelnen Coding-Agenten auf eine ganze Wirtschaft, ist genau dieser blinde Fleck das, was schrittweise Entmachtung schwer bis spät zu erkennen.

Für die Foundation liegt die Lehre beim Design, nicht bei einem einzelnen Paper. Unabhängige Inspektion, Compute-Regeln und externe Verifikation existieren, damit Sicherheit nicht auf einer Selbstauskunft des Labors beruht. Deshalb steht in unserem Plan bindende Grenzen und Verifikation, nicht nur freiwillige Selbstbewertung. Lesen Sie das Papier, wenn Sie die vollständigen Methodendetails wünschen: arXiv:2606.13474. Setzen Sie die Erkenntnis dann in Recht und Institutionen um, nicht nur in einer Workshop-Zitation.