SAFE RFC: OSAA's luftfahrtorientierter KI-Vorfallaustausch ist ein offener Entwurf, noch kein System

Am 4. August 2026 veröffentlichte die Linux Foundation, als die Black Hat USA in Las Vegas ihre Pforten öffnete, einen Request for Comments für die Arbeitsgruppe Shared AI Findings Exchange (SAFE) — ein Vorschlag, dass Organisationen KI-Sicherheitsvorfälle und Beinahevorfälle in einen vertraulichen gemeinsamen Kanal melden, gemeinsam daraus lernen und defensive Kontrollen veröffentlichen, die aus dem abgeleitet werden, was fehlgeschlagen ist. Der erste Entwurf wurde von Mitwirkenden von Cisco, CrowdStrike, Hugging Face, NVIDIA und Red Hat sowie weiteren Mitgliedern der Allianz entwickelt, erklärte die Linux Foundation in ihrer Ankündigung. Am selben Tag wurde er über das GitHub-Repository der Open Secure AI Alliance zur Begutachtung durch die Community freigegeben. Der Eintrag beschreibt keinen Schaden: Es handelt sich um einen Richtlinieneintrag, der im Archiv mit einer Info-Schweregradstufe und einer Konfidenznote A abgelegt ist, und sein Gegenstand ist ein Prozess und kein Ereignis. Die Schweregradstufe, die Konfidenzbewertung und die Quellenliste des Eintrags stehen in dem KI-Vorfallarchiv, zusammen mit den Einträgen, die um ihn herum abgelegt wurden.

Der Entwurf fordert die Mitglieder auf, vier Dinge zu berichten und das Warum zu ignorieren.

Der August-Text hält sich mit Rhetorik zurück und ist konkret bei den Auslösekriterien. Unter der Überschrift „Reporting Compact“ fordert er die Mitglieder auf, sich – als Bedingung der Mitgliedschaft – zu verpflichten, einen Vorfall zu melden, wenn sie Kenntnis davon erlangen oder begründet vermuten, dass ein von ihnen betriebenes KI-System eine der folgenden vier Handlungen begangen hat: ohne Autorisierung auf ein Drittsystem zugegriffen, es ausgenutzt, gestört, missbraucht oder verändert zu haben; durch Entkommen aus einer Sandbox-, Netzwerk-, Identitäts-, Richtlinien- oder Werkzeuggrenze bzw. durch deren Umgehung Auswirkungen auf Dritte verursacht zu haben; ohne Einwilligung des Eigentümers auf vertrauliche Informationen Dritter zugegriffen zu haben; oder ein Produktionsziel weiterhin sondiert, darauf zugegriffen oder es verändert zu haben, nachdem der Betreiber wusste oder begründet vermutete, dass die Aktivität unbefugt war oder außerhalb des genehmigten Umfangs lag.

Dann kommt der Satz, der den Großteil der Arbeit leistet: „Die Absicht entscheidet nicht darüber, ob ein Ereignis meldepflichtig ist. Der Glaube, dass eine Umgebung simuliert war, mag einen Vorfall erklären, hebt aber nicht die Meldepflicht auf.“ Dieser Satz scheint sich auf den Fall zu beziehen, in dem ein System in einer Umgebung läuft, die sein Betreiber für eine abgeschottete Testumgebung hält, und die Produktivinfrastruktur als Teil der Übung behandelt: Der Glaube des Betreibers über die Umgebung mag das Ereignis erklären, hebt aber nicht die Meldepflicht auf. Der Entwurf fordert die Mitglieder außerdem auf, Beinahevorfälle zu melden, nicht nur Ereignisse, die einen bestätigten Schaden verursacht haben, und innerhalb von 30 Tagen eine vorläufige Analyse von Kontrollversagen vorzulegen.

Der Zeitrahmen: sofort, 72 Stunden, vier Werktage, neunzig Tage

Die Benachrichtigungstabelle des Entwurfs ist das Konkreteste darin, und die erste Zeile ist überhaupt keine Frist: Die unmittelbar betroffene Organisation ist sofort zu informieren. Jede Frist läuft ab dem Moment, in dem das Mitglied Kenntnis von Tatsachen erlangt, die hinreichenden Anlass zu der Vermutung geben, dass ein meldepflichtiges Ereignis vorliegt – nicht erst ab dem Moment, in dem eine Untersuchung abgeschlossen ist. Die folgende Tabelle ist aus dem Entwurf vom 4. August übernommen; die überarbeitete Fassung vom Oktober behält dieselben Intervalle bei.

Drei dieser Zeilen betreffen die Information anderer Personen, und vier betreffen die Information von SAFE selbst. Die Unterscheidung ist wichtig, weil das Framework ausdrücklich kein Offenlegungsregime ist: Der Entwurf besagt: „Diese Fristen ersetzen keine Verpflichtung von Zulieferern, betroffene Parteien zu benachrichtigen, Kunden nach den bestehenden Best Practices für Coordinated Vulnerability Disclosure zu informieren oder geltende vertragliche und sonstige rechtliche Verpflichtungen zur Benachrichtigung von Aufsichtsbehörden oder Strafverfolgungsbehörden zu erfüllen.“ Was SAFE hinzufügt, ist eine parallele Verpflichtung gegenüber einer Stelle, die keine Regulierungsbehörde ist – und ein dreistufiges Offenlegungsmodell, bei dem nur die letzte Stufe, der Bericht zur öffentlichen Sicherheit, breit weitergegeben werden soll.

Acht Kontrollebenen im August, elf im Oktober

Die Reviews sind um den Betriebs-Stack herum strukturiert, nicht allein um das Modell. Der Augustentwurf listete acht Ebenen auf und stellte an jede eine Frage – erkannte das Modell Unsicherheit und Abbruchbedingungen; waren Autorisierung und Umgebungsannahmen explizit; funktionierten Klassifikatoren, Genehmigungen und Aktionsgrenzen; waren Anmeldedaten, Berechtigungen und Ausführung eingeschränkt; waren Isolation und Datengrenzen unabhängig verifiziert; konnten Operatoren in Echtzeit erkennen und unterbrechen; waren Eskalationswege und Kill-Verfahren klar; hatte ein Cloud-, Evaluierungs-, Daten- oder Tooling-Partner angenommene Kontrollen ungültig gemacht.

Die Oktober-Revision mit Datum vom 21. Oktober 2026, die am nächsten Tag in das Repository committet wurde, ergänzt drei Ebenen: den Serving-Pfad, die Autorisierung im Moment der Festschreibung und die Workflow-Komposition über eine Abfolge von Aktionen hinweg. Außerdem verwandelt sie die Überprüfung in eine abgestufte Bewertung mit vier zulässigen Antworten – bestanden, nicht bestanden, unzureichende Nachweise, nicht anwendbar – und stellt in ihrem Änderungsprotokoll fest, dass diese Befunde weder eine allgemeine Systemsicherheit noch eine rechtliche Konformität belegen. Diese Entwicklung lohnt sich als Beschreibung der Sorgen zu lesen, die die Autoren entwickelt haben: nicht, ob das Modell sich richtig verhielt, sondern ob das Modell, das antwortete, auch das Modell war, das konfiguriert worden war, ob die Berechtigung noch bestand, als die Aktion ausgeführt wurde, und ob die Abfolge als Ganzes innerhalb des Umfangs blieb, mit dem sie begonnen hatte.

Luftfahrt, aber welcher Bereich der Luftfahrt?

Die eigene Rahmung des Berichts – ein System nach dem Vorbild des Aviation Safety Reporting System der NASA – folgt der Ankündigung der Linux Foundation statt dem Entwurf. Die Ankündigung beschreibt ASRS als „ein freiwilliges, vertrauliches Meldesystem, das darauf ausgelegt ist, Flugunfälle so zu analysieren und auf sie zu reagieren, dass die Branche lernen und sich verbessern kann“. Weder der Augustentwurf noch die Oktoberüberarbeitung nennt ASRS an keiner Stelle; der Entwurf sagt nur, dass SAFE „die stärksten Merkmale vertraulicher Sicherheitsmeldesysteme übernehmen sollte“. Das ist ein kleiner Unterschied mit einer praktischen Folge: Die Ankündigung weckt eine Erwartung, zu der sich der Text noch nicht verpflichtet.

Die Analogie sorgte innerhalb des RFC-Prozesses selbst für Kommentare. Ein früher Pull Request, am 5. August von einem Beitragenden in persönlicher Eigenschaft eröffnet, argumentiert, dass „der ASRS-Analogie ein institutionelles Element fehlt“ – dass ASRS in erheblichem Maße funktioniert, weil Berichte von NASA entgegengenommen, verarbeitet und de-identifiziert werden, „einem öffentlichen, nicht regulierenden und nicht kommerziellen Dritten – nicht von der FAA als Regulierungsbehörde und nicht von den Fluggesellschaften, deren Betriebe gemeldet werden.“ Der Pull Request, der auch den Internet-Governance-Prozess von 1998 heranzieht, war am 30. Oktober weiterhin offen. Ob der Betreiber von SAFE die NASA-Rolle übernehmen kann, ist eine ungeklärte Designfrage und keine feststehende Funktion: Der Oktober-Text stellt die Arbeitsgruppe unter die eigene Governance der Alliance, mit Offenlegung von Interessenkonflikten, Selbstausschluss bei Befangenheit und einem Einspruchsweg zum Alliance Steering Committee.

Unabhängige Berichterstattung traf eine zweite, engere Unterscheidung. Infosecurity Magazine merkte in seinem Bericht vom 6. August an, dass der Beitrag der Linux Foundation KI-Agenten nicht ausdrücklich erwähnt — die agentische Rahmung gehört zu NVIDIAs begleitendem Beitrag, der argumentiert, dass „ein KI-Agent nicht nur ein Modell ist. Er ist ein System“, und Harnesses, Sandboxes, Guardrails und Evaluierungswerkzeuge aufführt, die von Mitgliedern der Allianz beigesteuert wurden. Die Auslöser des Entwurfs betreffen, wörtlich gelesen, Systeme, die außerhalb der Autorisierung handeln; die Botschaft der Ankündigung dreht sich, wörtlich gelesen, um Agenten.

Was Kommentatoren darüber sagten, wer die Kosten trägt

Einer der konkretesten veröffentlichten Einwände gegen den Entwurf in seiner vorliegenden Fassung kam von einem Gründungsmitglied der Allianz und nicht von einem externen Kritiker. Stephen Sargent, Gründer und Chief Technology Officer von Avondale.AI, reichte am 7. August per E-Mail eine Positionserklärung ein – an einem Tag, an dem das Dokument zufolge das Rechtsteam der Linux Foundation den Eingang bestätigte – und veröffentlichte sie am 9. August. Er beginnt mit seiner Unterstützung der Mission und argumentiert dann, dass der Pakt nicht mit der Organisationsgröße skaliere: „Das RFC unterscheidet nicht zwischen einer Organisation mit 50.000 Beschäftigten und einem kleinen Team.“ Ein Bericht binnen vier Geschäftstagen plus ein aufbewahrtes forensisches Paket könnten seiner Einschätzung nach mehr Personalzeit binden, als ein kleiner Betreiber erübrigen kann; seine Empfehlung lautet ein gestuftes Rahmenwerk, bei dem vertrauliche Berichte und eine verzögerte oder anonymisierte Veröffentlichung unterhalb einer Größenschwelle Standard sind.

Ein zweiter Einwand betrifft die Offenlegung und nicht die Fristen: Er argumentiert, dass „öffentliche Offenlegung IST eine Form der Durchsetzung“ für kleine Betreiber sei, weil der Bericht eines großen Unternehmens eine Fußnote sei und der eines kleinen Unternehmens zur Schlagzeile werde, und fordert, dass de-identifizierte Berichterstattung unterhalb einer Größenschwelle der Standard sein sollte. Ein dritter Einwand betrifft den Prüfrahmen und nicht den Zeitplan: Das Acht-Ebenen-Modell setzt getrennte Unternehmens­teams voraus, sodass bei einem Deployment durch eine einzige Person „der Betreiber alles erledigt“ und eine fehlende Ebene als Kontrollversagen gelesen wird, obwohl es sich schlicht um ein anderes Betriebsmodell handelt. Sein vierter Einwand betrifft den Ausdruck „Mindestpraktiken für Interoperabilität und Assurance“, den er als Weg von freiwilliger Berichterstattung zu de facto verpflichtenden Instrumenten liest. Das Positionspapier ist die Sicht eines Mitglieds, veröffentlicht von diesem Mitglied. Die Ankündigung der Linux Foundation vom 4. August geht ihm voraus und befasst sich nicht mit der Frage. Ein späterer Pull-Request, am 5. Oktober eröffnet und am 30. Oktober noch offen, schlägt eine Evidenzvorlage für Betreiber ohne Security Operations Centre vor – eine Anerkennung dafür, dass die Besorgnis angekommen ist, und ein Kandidat statt einer übernommenen Lösung, wobei sein Autor erklärt, er „begründe weder eine SAFE-Einführung noch rechtliche Hinlänglichkeit“.

Was hat sich zwischen dem 4. August und dem 30. Oktober geändert?

Die Geschichte des Repositorys ist die beste verfügbare Aufzeichnung dessen, was der RFC tatsächlich hervorgebracht hat, und sie ist lesbarer, als die Berichterstattung vermuten lässt. Die ersten Commits wurden am {{1}}3. August{{/1}} eingereicht; der Entwurf und ein erweitertes Readme wurden am {{2}}4. August um 00:14 und 00:19 UTC{{/2}} committet. Dann wurde es zehn Wochen lang still um das Repository. Am {{3}}14. Oktober{{/3}} fügte die Alliance eine Charta und eine Mitgliederdatei hinzu und schrieb das Readme um, um das Repository zur Heimat der SAFE-Arbeitsgruppe zu machen; an diesem Tag wurden {{4}}Paul DiOrio von NVIDIA und Josh Boyer von Red Hat{{/4}} als Interimsvorsitzende verzeichnet. Am {{5}}21. Oktober{{/5}} veröffentlichte die Arbeitsgruppe SAFE v1 mit einem Änderungsprotokoll, dessen erster Eintrag besagt, dass der Text „proposed“ aus der Beschreibung von SAFE entfernt und es als etablierte Arbeitsgruppe der Alliance ausweist.

Zwei Dinge an diesem Zustand sollten getrennt betrachtet werden. Die README des Repositories enthält jetzt die Zeile „Status: Genehmigt — Genehmigt vom Lenkungsausschuss“, was in den öffentlichen Unterlagen einer Ratifizierungserklärung am nächsten kommt; die Charta aus demselben Repository lautet weiterhin „In Entwicklung. Die SAFE-Charta wird hier veröffentlicht, sobald sie vom Lenkungsausschuss genehmigt wurde.“ Das Änderungsprotokoll bezeichnet den Oktober-Text als „SAFE v1“ und beschreibt, was er ändert, sagt aber nicht, wer ihn ratifiziert hat, mit welcher Abstimmung oder an welchem Datum. Wer wissen möchte, ob SAFE inzwischen eine genehmigte Spezifikation ist oder eine Arbeitsgruppe, deren maßgebliche Charta noch ungeschrieben ist, wird aus den Dokumenten keine eindeutige Antwort erhalten.

Was gilt als gesichert und was nicht

• Gegründet: Ein Request for Comments für den Shared AI Findings Exchange wurde am 4. August 2026 veröffentlicht – die Linux Foundation datierte ihre Ankündigung auf diesen Tag – und die darin als Mitwirkende genannten Organisationen sind Cisco, CrowdStrike, Hugging Face, NVIDIA und Red Hat, die neben „weiteren Mitgliedern der Open Secure AI Alliance“ genannt werden.

• Festgelegt: Der Entwurf enthält einen Berichts-Kompakt mit vier Auslösern, eine Benachrichtigungstabelle von sofort bis 90 Tage, eine Liste zur Beweissicherung, einen mehrschichtigen Prüfrahmen und ein dreistufiges Offenlegungsmodell. Der Volltext ist im Repository öffentlich zugänglich, und seine Historie ist ebenfalls öffentlich.

• Belegt, jedoch nur mit Quellenangabe: die Größe der Allianz – „mehr als 120 Organisationen“ – ist NVIDIAs eigene Angabe, wiederholt im Bericht von Infosecurity Magazine vom 6. August. Keine der geprüften Berichterstattungen zeigt ein unabhängiges Mitgliedschaftsaudit, und die Mitgliederdatei des Repositorys führt zwei Mitwirkende und zwei interimistische Vorsitzende auf, nicht 120 Organisationen.

• Nicht belegt: dass irgendjemand im Rahmen des Compact einen Bericht eingereicht hat. Die öffentlichen Aufzeichnungen vom 30. Oktober zeigen Commits, Pull Requests und Issues; sie zeigen keinen Vorfallbericht, kein Pilotprojekt, keinen ersten Fall, keine Stellungnahmefrist, keine Abstimmungsregel und kein Ratifizierungsdatum. Das Rahmenwerk beschreibt eine Verpflichtung, der Mitglieder als Bedingung der Mitgliedschaft „zustimmen“, was nicht dasselbe ist wie eine Verpflichtung, die irgendjemand bereits erfüllt hat.

• Umstritten: ob der ASRS-Vergleich ohne einen neutralen öffentlichen Betreiber Bestand hat – dagegen wird in einem offenen Pull Request argumentiert; ob die Berichtslast für kleine Betreiber verhältnismäßig ist – dagegen wird in einem Positionspapier eines Gründungsmitglieds argumentiert; und wie viel des Frameworks agentenspezifisch gegenüber allgemeiner KI-Sicherheit ist, eine Unterscheidung, die der Text der Linux Foundation und der Text von NVIDIA unterschiedlich ziehen.

Nichts davon macht die Aufzeichnung falsch, und die Note A des Archivs ist aus sich heraus vertretbar: Die Primärdokumente stimmen darin überein, was wann und von wem veröffentlicht wurde, und der Entwurf ist vollständig lesbar. Was die Note nicht tragen kann, ist das, was ein Leser am meisten will – ob der Mechanismus funktioniert. Dafür gibt es keinerlei Belege in die eine oder andere Richtung, weil der Mechanismus noch keinen Fall hatte.