G7 will Zutatenliste für KI-Systeme

Am 12. Mai hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) zusammen mit den Cybersicherheitsbehörden aller G7-Staaten ein Dokument veröffentlicht: "Software Bill of Materials for AI - Minimum Elements". Die Idee: Wer ein KI-System baut oder einsetzt, soll offenlegen, was drinsteckt. Welche Modelle, welche Trainingsdaten, welche Software-Abhängigkeiten, welche Sicherheitsmaßnahmen.

Das Konzept der SBOM (Software Bill of Materials) kennt die Softwarebranche seit Jahren. Nach dem SolarWinds-Hack 2020 hat die US-Regierung SBOMs für Bundesaufträge zur Pflicht gemacht. Die Log4Shell-Lücke hat gezeigt, wie wichtig es ist zu wissen, welche Bibliotheken in der eigenen Software stecken. Jetzt soll das gleiche Prinzip auf KI-Systeme übertragen werden.

Was das Dokument verlangt

Das G7-Papier definiert sieben Informations-Cluster, die eine SBOM for AI enthalten sollte:

Metadata beschreibt die SBOM selbst: Wer hat sie erstellt, wann, in welchem Format, mit welchem Tool.

System Level Properties erfasst das KI-System als Ganzes: Name, Hersteller, Version, Datenflüsse, Ein-/Ausgabeformate und den vorgesehenen Einsatzbereich.

Models dokumentiert die verwendeten KI-Modelle: Architektur, Trainingsmethoden, bekannte Limitierungen, Modell-Hashes zur Integritätsprüfung und Lizenzen.

Datasets Properties soll die Trainingsdaten beschreiben: Herkunft, Sammelmethoden, statistische Eigenschaften, ob personenbezogene oder sensible Daten enthalten sind.

Infrastructure listet Software- und Hardware-Abhängigkeiten: Frameworks, Bibliotheken, Runtime-Umgebungen, und bei Bedarf einen Verweis auf eine Hardware Bill of Materials (HBOM).

Security Properties umfasst Sicherheitsmaßnahmen: Verschlüsselung, Zugriffskontrollen, Prompt-Injection-Filter, Adversarial-Robustness-Training und Compliance-Zertifizierungen.

Key Performance Indicators enthält Sicherheitsmetriken und Betriebskennzahlen wie Uptime, Latenz und Robustheit gegen Manipulation.

Wichtig: Nichts davon ist verpflichtend

Das Dokument sagt es auf Seite 1 selbst: Die aufgeführten Elemente sind nicht verbindlich, schaffen keine neuen Anforderungen und keine Gesetzgebung. Es ist eine Empfehlung, erarbeitet von Experten der G7-Cybersicherheitsbehörden zwischen August 2025 und Februar 2026.

Die Reaktionen aus der Security-Community fallen gemischt aus. Dmitry Raidman, CTO von Cybeats, nannte die Richtlinie "amazing", weil sie eine klare Baseline schaffe. Daniel Bardenstein, CEO von Manifest Cyber, lobte sie im selben Bericht als "strong, applaudable step", betonte aber, dass man dem Inhalt der SBOMs auch vertrauen können müsse.

Allan Friedman sieht das kritischer. Friedman hat als ehemaliger SBOM-Verantwortlicher bei CISA die Software-SBOM-Bewegung in den USA vorangetrieben und kennt das Thema so gut wie kaum jemand. Sein Urteil: Das Dokument liste "potential elements", keine Mindestanforderungen. Viele der Cluster seien schwer zu messen oder überhaupt schwer organisationsübergreifend zu definieren.

Wo der Ansatz funktioniert

Für den klassischen Software-Teil ist die SBOM for AI sinnvoll und praktisch umsetzbar.

Software-Abhängigkeiten nachzuhalten ist ein gelöstes Problem. Welche PyTorch-Version läuft? Welche Python-Bibliotheken sind installiert? Dafür gibt es Tools wie Syft, Trivy oder CycloneDX. Das funktioniert bei KI-Systemen genauso wie bei jeder anderen Software.

Auch Modell-Hashes sind technisch machbar. Wenn ein Unternehmen nachweisen kann, dass das deployed Modell identisch mit dem auditierten Modell ist, verhindert das Manipulationen in der Lieferkette. SHA-256 über eine Gewichtsdatei zu berechnen ist kein Hexenwerk.

Und Lizenzfragen werden drängender: Wurde ein Modell auf urheberrechtlich geschützten Daten trainiert? Unter welcher Lizenz steht das Modell selbst? Die SBOM schafft zumindest die Pflicht, das zu dokumentieren.

Wo es unrealistisch wird

Bei den AI-spezifischen Teilen wird es dünn. Hier wünscht sich das Dokument Dinge, die heute niemand liefern kann.

Der größte Schwachpunkt ist die Trainingsdaten-Provenienz. Das Dokument verlangt unter "Dataset provenance" Angaben zu Ursprung, Sammelmethoden und Verarbeitungsschritten. Bei einem großen Sprachmodell reden wir über Billionen Token aus Millionen Quellen. Common Crawl allein umfasst Petabytes an Daten. Wer genau welchen Text beigesteuert hat, lässt sich bei vielen Modellen schlicht nicht mehr rekonstruieren. Automatische Extraktion von Modell-Lineage und standardisierte Metadaten-Schemata sind aktive Forschungsfelder, aber weit von produktionsreifen Lösungen entfernt.

Dann die ehrliche Dokumentation von Limitierungen. "Model description" soll laut Dokument auch "known weaknesses and limitations" enthalten. Aber welches Unternehmen wird freiwillig hinschreiben, dass sein Modell bei bestimmten Aufgaben systematisch versagt oder bei bestimmten Bevölkerungsgruppen schlechtere Ergebnisse liefert? Die SBOM ist Selbstauskunft, keine unabhängige Prüfung. Eine Zutatenliste sagt dir, dass Mehl im Brot ist, aber nicht, ob der Bäcker absichtlich Sand reingemischt hat.

Auch bei den Sicherheitsmetriken fehlt die Grundlage. Was genau misst "Robustness against third-party manipulation"? Gegen welche Angriffe? Unter welchen Bedingungen? Es gibt keine branchenweiten Benchmarks und Testverfahren dafür.

Dazu kommt: Das Tooling existiert kaum. Für klassische Software-SBOMs gibt es ausgereifte Tools. Für die AI-spezifischen Elemente müsste man Datenpipelines instrumentieren, Trainingsumgebungen dokumentieren und Multi-Gigabyte-Gewichtsdateien hashen. Ein Industriestandard dafür? Fehlanzeige.

Das Dokument weiß das selbst

In Abschnitt 3 (Discussion) räumen die Autoren im Dokument selbst ein, dass eine SBOM for AI allein nicht ausreicht und mit Cybersecurity-Tools verbunden werden muss. Auch interessant: Die Arbeitsgruppe hat diskutiert, ob der Autonomiegrad eines KI-Systems dokumentiert werden sollte, was gerade bei agentischen Systemen relevant wäre. Man hat sich dagegen entschieden, weil das Thema in verschiedenen Ländern unterschiedlich geregelt wird.

Einordnung

Die SBOM for AI ist ein politisches Signal, kein technisches Werkzeug. Die G7-Staaten zeigen damit, dass sie das Thema KI-Lieferkettensicherheit auf dem Schirm haben. Für IT-Verantwortliche heißt das konkret: Dokumentationspflichten werden kommen, auch wenn der Weg dahin noch lang ist.

Was man heute schon tun kann: Software-Abhängigkeiten der eigenen KI-Systeme sauber dokumentieren, Modell-Versionen und -Hashes festhalten, Lizenzen prüfen. Das ist machbar, nützlich und vermutlich der Teil, der als erstes verbindlich wird.

Die AI-spezifischen Teile bleiben vorerst ein Wunschzettel. Nicht weil die Idee schlecht wäre. Sondern weil die technischen Voraussetzungen fehlen, weil das Tooling nicht existiert, und weil freiwillige Selbstauskunft genau da versagt, wo es wirklich interessant wird: bei den Schwächen. Dazu kommen Probleme, wie der Herkunftsnachweis der Trainingsdaten, der bei Petabyte an Trainingsdaten lückenhaft oder zu groß sein wird.