Ein Arbeitsgruppen-Anlass statt Hype
Die Linux Foundation beschreibt die geplante SAFE Working Group als offenen Versuch, aus KI-Sicherheitsvorfällen und Beinahevorfällen systematisch zu lernen. Das ist weniger spektakulär als ein neues Modell und genau deshalb wichtig. Der offizielle Beitrag „Proposing the SAFE Working Group“ wurde laut gespeicherter Quelle am 4. August 2026 veröffentlicht und trägt die nüchterne Überschrift „An Open Community Effort to Improve AI Security“. Nüchtern ist hier kein Makel. In Sicherheitsarbeit ist Nüchternheit meist der Moment, bevor jemand endlich die Checkliste findet.
Der Anlass passt zu Deep Tech, obwohl er nach Governance klingt. KI-Systeme hängen an Modellen, Laufzeitumgebungen, Werkzeugen, Schutzmechanismen, Monitoring, menschlichen Abläufen und Lieferketten. Wenn etwas schiefgeht, ist selten nur eine Komponente schuld. SAFE soll laut Linux Foundation eine Community-Diskussion darüber starten, wie Organisationen vertraulich aus Vorfällen lernen und daraus praktische Sicherheitsleitlinien für das breitere KI-Ökosystem ableiten können. Das klingt langsam. Es ist aber die Art Langsamkeit, die spätere Katastrophen beschleunigt verhindert.
Dass der Beitrag von der Linux Foundation kommt, ist für diese Debatte relevant. Open-Source-Ökosysteme haben gelernt, Schwachstellen, Maintainer-Strukturen und Lieferkettenrisiken öffentlich zu bearbeiten, auch wenn es knirscht. KI-Sicherheit bringt dieselben Muster in eine schwierigere Umgebung: mehr proprietäre Bausteine, mehr unklare Modellgrenzen, mehr rechtliche Vorsicht. SAFE versucht, aus dieser Gemengelage kein Heldengedicht zu machen, sondern einen Arbeitsprozess. Das ist angenehm unromantisch.
Was die Linux Foundation beschreibt
Die Quelle nennt einen konkreten Mechanismus: Teilnehmer der Open Secure AI Alliance haben einen Request for Comments für die Shared AI Findings Exchange, kurz SAFE, veröffentlicht. Der Entwurf liegt im RFC-Repository der Open Secure AI Alliance. Die Linux Foundation schreibt, die Diskussion solle offen geführt werden und Organisationen helfen, KI-Sicherheitsvorfälle sowie Near Misses vertraulich zu analysieren. Das Ziel ist nicht die nächste Hochglanznorm, sondern verwertbares Lernen aus realen Betriebsfehlern.
Bemerkenswert ist auch die Liste der Mitwirkenden am ursprünglichen Entwurf. Genannt werden Cisco, CrowdStrike, Hugging Face, NVIDIA, Red Hat und weitere Mitglieder der Open Secure AI Alliance. Damit steht SAFE nicht als Einzelanbieter-Programm im Raum, sondern als Vorschlag aus einem Umfeld, das sehr unterschiedliche Interessen mitbringt: Infrastruktur, Modelle, Security, Enterprise-Betrieb und Open Source. Das garantiert noch keine gute Governance. Es verhindert aber, dass die Debatte schon im ersten Absatz nach Herstellerbroschüre riecht.
Der Name selbst ist fast zu glatt, aber der ausgeschriebene Begriff ist präziser: Shared AI Findings Exchange. Es geht also nicht nur um Incident Reporting, sondern um den Austausch von Befunden. Ein Befund ist stärker als ein Verdacht und schwächer als ein endgültiges Urteil. Für KI-Sicherheit ist diese Zwischenkategorie wichtig, weil viele Vorfälle aus mehreren Ursachen bestehen. Ein schlecht begrenztes Tool, ein überforderter Mensch und ein fehlendes Monitoring ergeben zusammen mehr Risiko als jede Einzelkomponente für sich.
Warum offene KI-Sicherheit schwierig ist
Offene KI-Sicherheit scheitert selten am guten Willen. Sie scheitert an Haftung, Vertraulichkeit, Wettbewerb, regulatorischen Pflichten und der unangenehmen Frage, wer einen Fehler öffentlich genug macht, damit andere daraus lernen können. Die Linux Foundation vergleicht die Idee mit sicherheitskritischen Branchen und verweist auf das Aviation Safety Reporting System der NASA als Beispiel für ein freiwilliges, vertrauliches Meldesystem. Der Vergleich ist hilfreich, solange man ihn nicht überdehnt. Flugunfälle und KI-Vorfälle sind nicht dasselbe, aber beide brauchen Lernen jenseits einzelner Aktenordner.
Der Beitrag beschreibt ein reales Defizit: Organisationen untersuchen KI-Sicherheitsvorfälle heute oft intern, während wertvolles Betriebswissen im Unternehmen bleibt. Genau dort wird offene Sicherheitsarbeit schwierig. Wer zu wenig teilt, schützt vielleicht kurzfristig die eigene Reputation und schwächt langfristig das Ökosystem. Wer zu viel teilt, riskiert Angriffsdetails, Vertragsprobleme oder regulatorische Nebenwirkungen. SAFE versucht, diese Spannung nicht mit Vertrauen wegzulächeln, sondern mit vertraulichen Verfahren, Analyse und wiederverwendbaren Empfehlungen zu bearbeiten.
Der NASA-Verweis ist auch eine Erinnerung an Kultur. Vertrauliche Meldesysteme funktionieren nicht, wenn Teilnehmer befürchten müssen, jede Meldung werde später als Schuldeingeständnis genutzt. Gleichzeitig darf Vertraulichkeit nicht zur Ausrede werden, gar nichts zu lernen. SAFE muss also eine schwierige Balance halten: genug Schutz für Meldende, genug Struktur für belastbare Analysen und genug Transparenz, damit Empfehlungen nicht wie Orakelsprüche aus einem geschlossenen Raum wirken.
Der RFC denkt den ganzen Stack mit
Der Entwurf beschränkt sich laut Quelle nicht auf Modelle. Die vorgeschlagenen strukturierten Reviews sollen den vollständigen KI-Betriebsstack betrachten: Modelle, Safeguards, Tools, Runtime-Umgebungen, Monitoring, menschliche Operationen und Supply-Chain-Abhängigkeiten. Das ist der entscheidende Punkt. Viele KI-Sicherheitsdebatten tun so, als ließe sich Risiko am Modellnamen ablesen. In der Praxis entstehen Vorfälle oft an Schnittstellen: ein Tool darf zu viel, ein Mensch sieht zu wenig, ein Monitoring schweigt zur falschen Zeit.
Für Unternehmen ist diese Stack-Sicht unbequem, aber nützlich. Sie zwingt Teams, ihre Zuständigkeiten zu sortieren. Modellteam, Plattformteam, Security Operations, Legal, Datenschutz, Einkauf und Fachbereich müssen nicht alle dasselbe tun. Sie müssen aber wissen, welche Entscheidung bei ihnen liegt. Ein SAFE-ähnliches Verfahren kann nur funktionieren, wenn Vorfälle so beschrieben werden, dass andere Organisationen die Kontrolllücke wiedererkennen. Ein dramatischer Vorfall ohne reproduzierbare Lehre ist nur teure Folklore.
Die Lieferkette verdient besondere Aufmerksamkeit. KI-Systeme entstehen nicht aus einem Modell und guter Laune, sondern aus Datenpipelines, Frameworks, Plugins, Modellgewichten, Container-Images, Vektorindizes, Berechtigungssystemen und externen APIs. Ein Vorfall kann an jeder dieser Stellen beginnen. Wenn SAFE wiederverwendbare Guidance liefern will, muss sie diese Abhängigkeiten benennen können, ohne vertrauliche Details unnötig offenzulegen. Das ist mühselig. Genau deshalb braucht es ein gemeinsames Format.
Neutralität ist eine harte Anforderung
Die Linux Foundation betont, SAFE solle neutral arbeiten, damit kein einzelner Anbieter und kein einzelnes Industriesegment die Ergebnisse kontrolliert. Außerdem sollen die Prozesse sowohl für offene als auch für proprietäre KI-Systeme gelten. Das ist kein freundlicher Nebensatz, sondern eine Kernbedingung. Wenn nur Open-Source-Systeme auswertbar sind, entsteht ein blinder Fleck bei proprietären Plattformen. Wenn nur große Anbieter den Takt setzen, werden kleinere Betreiber zu Zuschauern einer Sicherheitsdebatte, die sie trotzdem ausbaden müssen.
Der Satz aus der Quelle, Vertrauen sei keine Sicherheitskontrolle, trifft den Kern. Vertrauen kann eine Zusammenarbeit erleichtern, ersetzt aber keine Evidenz, keine Tests und keine überprüfbaren Verbesserungen. Für Leserinnen und Leser mit Sicherheitsverantwortung ist das die wichtigste Pointe. SAFE wird nicht daran zu messen sein, ob der Begriff freundlich klingt. Entscheidend wird sein, ob aus gemeldeten Vorfällen konkrete Tests, Richtlinien, Erkennungsmuster, Referenzkonfigurationen oder Incident-Response-Hinweise entstehen.
Neutralität muss zudem überprüfbar sein. Eine Arbeitsgruppe kann sich neutral nennen und trotzdem unbewusst die Perspektive der größten Teilnehmer übernehmen. Darum sind offene RFC-Prozesse, nachvollziehbare Entscheidungsregeln und sichtbare Beitragswege wichtig. Proprietäre Anbieter, Open-Source-Projekte, Cloud-Betreiber und Forschung haben unterschiedliche Schmerzpunkte. Ein belastbares Verfahren muss diese Unterschiede aushalten. Sonst entstehen Empfehlungen, die formal richtig wirken und im Betrieb trotzdem an den falschen Stellen greifen.
Was Unternehmen daraus lernen können
Für Ihre Organisation ist SAFE zunächst kein Produkt, das Sie einkaufen, und kein Standard, den Sie morgen abhaken. Es ist ein Hinweis, welche Fragen reifer KI-Betrieb beantworten muss. Haben Sie eine Stelle, an der KI-Near-Misses gemeldet werden können? Werden Beinahevorfälle untersucht, obwohl noch kein Schaden sichtbar ist? Können Sie eine Kontrolllücke so dokumentieren, dass ein anderes Team daraus etwas lernt? Wenn die Antwort dreimal „kommt darauf an“ lautet, ist immerhin der Status ehrlich.
Der Abgleich mit bestehender Digital-Magazin-Berichterstattung zu praktischen Schwachstellen und Gegenmaßnahmen zeigt, warum solche Verfahren gebraucht werden. Einzelne Sicherheitsmeldungen erklären oft den akuten Fehler. Ein Framework wie SAFE zielt auf wiederkehrende Muster: Welche Annahme ist gebrochen, welcher Kontrollpunkt fehlte, welche technische und organisatorische Änderung verhindert die Wiederholung? Genau diese Übersetzung entscheidet, ob Security-Wissen im Unternehmen bleibt oder dem Ökosystem hilft.
Für interne Teams ist besonders der Begriff Near Miss nützlich. Viele Organisationen dokumentieren nur Ereignisse, die bereits Schaden verursacht haben. Bei KI-Systemen ist das zu spät. Ein Agent, der beinahe ein falsches Tool ausgeführt hätte, eine Schutzregel, die nur zufällig gegriffen hat, oder ein Monitoring, das den Fehler erst im Nachhinein erklärt, sind Lernmaterial. Wenn solche Fälle nicht erfasst werden, bleibt Sicherheitsarbeit reaktiv. SAFE macht sichtbar, dass Beinahevorfälle keine Peinlichkeit sind, sondern Frühwarnsysteme.
Was Teams jetzt beobachten sollten
Die Linux Foundation lädt Entwickler von KI-Modellen, Betreiber von KI-Systemen, Cloud-Infrastrukturteams, Sicherheitsforschung, Governance- und Standardisierungsakteure zur Mitarbeit ein. Außerdem verweist sie auf NVIDIAs ergänzenden Blogbeitrag sowie auf Issues und Pull Requests im RFC-Prozess. Das ist ein offenes Arbeitsangebot, keine abgeschlossene Wahrheit. Gerade deshalb sollten Unternehmen nicht warten, bis irgendjemand eine hübsche PDF-Version mit Reifegradmodell verkauft.
Der sinnvolle nächste Schritt ist kleiner: Lesen Sie den RFC, ordnen Sie Ihre eigenen KI-Sicherheitsvorfälle und Near Misses der Stack-Sicht zu und prüfen Sie, welche Informationen Sie vertraulich teilen könnten, ohne rechtliche Pflichten zu verletzen. Danach lässt sich entscheiden, ob aktive Mitarbeit, Beobachtung oder interne Anpassung sinnvoll ist. SAFE bleibt Deep-Tech-Arbeit, weil es nicht um Slogans geht, sondern um Beweise, Prozesse und wiederholbare Kontrollen. Also um die Dinge, die selten in Keynotes glänzen und im Ernstfall trotzdem zählen.
Die Beobachtung des RFC-Prozesses lohnt sich auch für Organisationen, die nie selbst in der Open Secure AI Alliance mitarbeiten. Ein offener Entwurf zeigt früh, welche Kategorien und Begriffe sich im Markt durchsetzen könnten. Wer seine internen Vorfallberichte schon jetzt daran spiegelt, merkt schneller, wo Informationen fehlen. Das ist ein günstiger Test. Er kostet keine Plattformmigration und keine neue Tool-Lizenz, nur die Bereitschaft, eigene Sicherheitsprotokolle etwas weniger dekorativ und etwas nützlicher zu machen.
Was halten Sie von dem Thema? Hier können Sie mit anderen Leserinnen und Lesern ins Gespräch gehen.
Mitreden & diskutieren
Ihre Meinung zählt — teilen Sie Gedanken, Fragen oder Erfahrungen zu diesem Artikel.