AI BOM: die KI-Stückliste nach den G7-Mindestelementen

Eine AI BOM (deutsch: KI-Stückliste) ist die strukturierte, maschinenlesbare Aufzeichnung dessen, woraus ein KI-System besteht: Modelle, Datensätze, Softwareabhängigkeiten, Infrastruktur und die Beziehungen zwischen ihnen. Bis 2026 bestimmte der jeweilige Werkzeughersteller, was hineingehört. Seit dem 12. Mai 2026 gibt es eine offizielle Grundlinie der Cybersicherheitsbehörden der G7: 7 Cluster und, nach unserer Zählung, 50 Elemente, sämtlich freiwillig. Dieser Leitfaden liest die Liste so, wie ein Prüfer sie lesen würde: was sie festhält, was sie auslässt, welche Rechtsakte ihren Inhalt dennoch einforderbar machen und wie sich das Dokument in sieben Schritten erstellen lässt.

Auf einen Blick

• Die AI BOM erweitert die Software-Stückliste (SBOM) um Modelle, Datensätze, Infrastruktur und deren Herkunft; sie ergänzt die SBOM und ersetzt sie nicht.
• Die G7-Leitlinie vom 12. Mai 2026 nennt 7 Cluster und nach unserer Zählung 50 Mindestelemente; sie ist freiwillig und nennt kein Gesetz.
• Kein EU-Rechtsakt verlangt eine „AI BOM“ dem Namen nach, doch Anhang IV, Artikel 25 Absatz 4 sowie die Anhänge XI und XII der KI-Verordnung und Anhang I der Cyberresilienz-Verordnung (CRA) verlangen den Großteil ihres Inhalts.
• Zweckrisiko, menschliche Aufsicht, Testergebnisse und Risikoakte fehlen: Sie ist eine Zutatenliste, keine technische Dokumentation.
• Fristen: GPAI-Dokumentationspflichten seit 2. August 2025, CRA-Meldepflichten seit 11. September 2026, Hochrisikopflichten der KI-Verordnung und SBOM-Pflicht der CRA ab Dezember 2027.

Was ist eine AI BOM?

Die G7-Behörden definieren den Gegenstand als strukturierte Aufzeichnung, also als Inventar, der Details und Lieferkettenbeziehungen jener Komponenten, die beim Bau eines KI-Systems verwendet wurden. Das Bild, das sie selbst wählen, ist die Zutatenliste. Wer eine solche Liste vorliegen hat, kann binnen einer Stunde beantworten, ob ein bestimmtes Basismodell, ein bestimmter Datensatz oder eine verwundbare Bibliothek in einem System steckt. Die klassische SBOM reicht dafür aus drei Gründen nicht aus:

• Ein Modell ist keine Bibliothek. Sein Verhalten ergibt sich aus Gewichten und Trainingsdaten, die kein Paketmanifest beschreibt.
• Ein Datensatz hat eine Herkunft, eine Lizenz und eine Schutzbedürftigkeit. Ob personenbezogene oder urheberrechtlich geschützte Daten enthalten sind, entscheidet über Pflichten, die mit Softwarelizenzen nichts zu tun haben.
• Ein KI-System ruft externe Dienste auf. Modell-APIs, Vektordatenbanken und Suchdienste liegen außerhalb des eigenen Builds und tauchen in keiner Abhängigkeitsliste auf.

Die G7-Leitlinie zieht daraus keinen Bruch, sondern eine Ergänzung: KI-Systeme sind auch Softwaresysteme, die SBOM bleibt für sie gültig, und die KI-spezifischen Mindestelemente kommen zu den allgemeinen SBOM-Mindestelementen hinzu.

AI BOM, AIBOM, ML-BOM, SBOM for AI: ein Artefakt, mehrere Namen

Die Bezeichnungen folgen den Urhebern, nicht dem Inhalt. AIBOM oder AI bill of materials ist der Sprachgebrauch der Industrie und von OWASP. ML-BOM heißt das Objekt im Format CycloneDX. SBOM for AI ist der Name, den die G7 und die beteiligten Behörden verwenden, AI SBOM der Name der einschlägigen OWASP-Initiative. Gemeint ist jeweils dasselbe Artefakt; im Folgenden heißt es durchgehend AI BOM. Zwei Nachbarn werden regelmäßig damit verwechselt. Die Model Card ist die Prosadokumentation eines einzelnen Modells für menschliche Leser; die G7-Liste verweist per Link auf sie, statt sie zu ersetzen. Das KI-Register ist die organisationsweite Liste aller KI-Systeme. Die Hierarchie ist einfach: ein Registereintrag je System, darunter eine AI BOM je Systemversion.

Was eine AI BOM enthält: die 50 Mindestelemente der G7

Die Leitlinie „Software Bill of Materials for AI, Minimum Elements“ wurde am 12. Mai 2026 veröffentlicht, gemeinsam vom Bundesamt für Sicherheit in der Informationstechnik (BSI), der italienischen ACN, der französischen ANSSI, dem kanadischen CSE, der US-amerikanischen CISA, dem britischen NCSC und dem japanischen NCO, in Zusammenarbeit mit der Europäischen Kommission. Den Arbeitsstrang leiteten ACN und BSI gemeinsam, unter der kanadischen (2025) und der französischen (2026) G7-Präsidentschaft. Das Papier setzt die gemeinsame G7-Vision vom Juni 2025 fort, entstand zwischen August 2025 und Februar 2026 und umfasst 26 Seiten. Abrufbar ist es bei der CISA und auf der Downloadseite des BSI. Wir haben den Volltext gelesen und gezählt. Die Zahlen in der folgenden Tabelle sind unsere Zählung, keine Angabe der Behörden. <table header-row=“true“> <tr> <td>Cluster</td> <td>Elemente</td> <td>Was festgehalten wird</td> </tr> <tr> <td>Metadaten</td> <td>10</td> <td>Das Dokument selbst: Autor, Version, Name und Version des Datenformats, digitale Signatur des Autors, Name und Version des Werkzeugs, Erzeugungskontext (vor dem Build, im Build, nach dem Build), Zeitstempel, Abhängigkeitsbeziehung</td> </tr> <tr> <td>Eigenschaften auf Systemebene</td> <td>9</td> <td>Das KI-System als Ganzes: Name, Komponenten (Modelle, Datenbanken, sonstige Software), Hersteller, Version, Zeitstempel, Datenfluss zwischen den Komponenten und zu externen Diensten, Datennutzung, Eigenschaften der Ein- und Ausgaben, vorgesehener Anwendungsbereich</td> </tr> <tr> <td>Modelle</td> <td>13</td> <td>Jedes Modell: Name, Kennung, Version, Zeitstempel, Hersteller, Beschreibung (Fähigkeiten, bekannte Grenzen, Abstammung, etwa das für das Fine-Tuning verwendete Basismodell), Hashwert und Hashalgorithmus, Eigenschaften (Architektur, Parameterzahl), Ein- und Ausgabeeigenschaften (Kontextlänge, Modalität), Trainingseigenschaften, Lizenz, externe Verweise (Model Card, Fachaufsatz)</td> </tr> <tr> <td>Datensätze</td> <td>10</td> <td>Jeder Datensatz: Name, Beschreibung (Verwendung für Vortraining, Fine-Tuning oder Evaluierung), Inhalt, Kennung, Hash, Herkunft (Ursprung, Erhebungsmethode wie Web-Crawling oder Lizenzverträge, Verarbeitungs- und Annotationsschritte, Verfahren für synthetische Daten), statistische Eigenschaften, Schutzbedürftigkeit (personenbezogene Daten, urheberrechtlich geschützte Daten, Finanz- oder Gesundheitsdaten), Abhängigkeitsbeziehung, Lizenz</td> </tr> <tr> <td>Infrastruktur</td> <td>2</td> <td>Die zum Betrieb nötige Software (Firmware, Bibliotheken, Frameworks, Laufzeitumgebungen, vom System genutzte Werkzeuge) und die Hardware, per Verweis auf eine Hardware-Stückliste (HBOM)</td> </tr> <tr> <td>Sicherheitseigenschaften</td> <td>4</td> <td>Sicherheitskontrollen (allgemeine und KI-spezifische, etwa Schutz gegen Prompt Injection sowie Ein- und Ausgabefilter), Sicherheitskonformität (Zertifizierungen und Normen), Angaben zur Cybersicherheitspolitik (Link auf die security.txt des Herstellers), Schwachstellenreferenzen</td> </tr> <tr> <td>Leistungskennzahlen</td> <td>2</td> <td>Sicherheitsmetriken (etwa Widerstandsfähigkeit gegen Manipulation durch Dritte) und Betriebsleistung (Verfügbarkeit, Dauer der Vorfallbehebung, Latenz, Durchsatz)</td> </tr> </table> Aus unserer Lektüre ergeben sich drei Beobachtungen, die in den gängigen Erklärtexten fehlen. Von den 14 bestplatzierten Seiten zu diesem Suchbegriff, die wir ausgewertet haben, führt keine einzige diese Liste auf.

• Das Gewicht liegt auf Modellen und Daten. 23 der 50 Elemente beschreiben Modelle und Datensätze, nur 2 die Infrastruktur, und die Hardware wird lediglich über den Verweis auf eine HBOM abgedeckt. Das Element zur Schutzbedürftigkeit der Daten ist zugleich die Stelle, an der die Stückliste auf den Datenschutz trifft.
• Integrität ist eingebaut. Vorgesehen sind Hashwert und Hashalgorithmus für jedes Modell, ein Hash für jeden Datensatz und die digitale Signatur des Autors auf dem Dokument selbst. Fehlt dem Autor eine Angabe, etwa der Hash eines Modells, auf das er keinen Zugriff hat, so soll er ausdrücklich „unbekannt“ eintragen, statt das Feld leer zu lassen.
• Die Model Card bleibt bestehen. Die Elemente zu den Trainingseigenschaften und den externen Verweisen des Modells zeigen per Link auf sie. Die AI BOM strukturiert, die Model Card erläutert.

AI-BOM-Formate: CycloneDX und SPDX

Zwei offene Formate tragen das Artefakt heute. CycloneDX, ein OWASP-Projekt und als ECMA-424 standardisiert, kennt seit Version 1.5 eine Machine-Learning-Stückliste (ML-BOM). SPDX 3.0 der Linux Foundation hat ein KI-Profil und ein Datensatzprofil eingeführt; der Bericht der Linux Foundation zur Umsetzung mit SPDX 3.0 beschreibt die Felder im Einzelnen. Den nüchternsten Vergleich liefert ein Vortrag von Cassie Crossley und Allan Friedman, den das NIST am 19. Mai 2026 veröffentlicht hat. Die folgende Gegenüberstellung gibt deren Einschätzung wieder. <table header-row=“true“> <tr> <td>Format</td> <td>Stärke</td> <td>Grenze</td> </tr> <tr> <td>CycloneDX ML-BOM (Versionen 1.5 bis 1.7)</td> <td>Native ML-Typen und breite Werkzeugunterstützung</td> <td>Weniger KI-Metadatenfelder; kein natives Feld für sensible personenbezogene Daten, Erklärbarkeit, Autonomie oder Sicherheitsrisiko</td> </tr> <tr> <td>SPDX 3.0.1, KI-Profil</td> <td>Die tiefsten KI-Metadaten (Erklärbarkeit, Energie, sensible personenbezogene Daten, Sicherheitsrisiko) und formale Beziehungen „trainiert auf“ und „getestet auf“</td> <td>Werkzeuge noch in der Reifung; das JSON-LD-Format ist in Build-Pipelines weniger handlich</td> </tr> </table> Beim Werkzeug gilt derselbe Befund. Der quelloffene AIBOM Generator der OWASP-Initiative, auf der RSAC 2025 vorgestellt, erzeugt nach demselben Vortrag CycloneDX-1.6-Dokumente für Modelle, die auf Hugging Face liegen; die Abbildung auf das SPDX-KI-Profil war im Mai 2026 noch in Arbeit. Die G7-Leitlinie schreibt kein Format vor. Ihr Metadaten-Cluster verlangt nur, Name und Version des verwendeten Formats anzugeben. Daraus folgt eine praktische Regel: Man wählt das Format, das die vorhandene SBOM-Werkzeugkette bereits ausgibt. Die CRA wird die SBOM aus derselben Pipeline verlangen. Wer sein KI-Managementsystem nach ISO 42001 aufbaut, legt die Formatwahl am besten dort als dokumentierte Entscheidung ab.

Was eine AI BOM nicht belegt

Der G7-Text sagt über sich selbst, dass er keine Anforderungen, Normen oder Rechtsvorschriften schafft. Die Mindestelemente sind nicht verbindlich und sollen weiterentwickelt werden; in einzelnen Rechtsordnungen könnten manche Elemente bereits durch Pflichten oder Normen abgedeckt sein. Welche das wären, lässt das Papier offen: Unsere Volltextprüfung der 26 Seiten hat keine einzige namentlich genannte Verordnung ergeben. Es handelt sich um ein Cybersicherheitsdokument, nicht um eine Auslegungshilfe zur KI-Verordnung. Für Anbieter von Hochrisiko-KI-Systemen stellt sich deshalb die Frage, wie weit die Liste in die technische Dokumentation nach Anhang IV trägt. Die folgende Zuordnung ist unsere eigene Lesart, keine Zuordnung der G7 oder der Kommission. <table header-row=“true“> <tr> <td>Was Anhang IV der KI-Verordnung verlangt</td> <td>In der AI BOM enthalten?</td> <td>Wo der Nachweis liegt</td> </tr> <tr> <td>Zweckbestimmung, Anbieter, Versionen (Nummer 1)</td> <td>Teilweise: Systemname, Hersteller, Version, vorgesehener Anwendungsbereich</td> <td>Betriebsanleitung, Einstufungsvermerk</td> </tr> <tr> <td>Verwendete vortrainierte Systeme und Werkzeuge Dritter sowie die Art ihrer Integration (Nummer 2 Buchstabe a)</td> <td>Ja: Cluster Modelle, Abstammung, Systemkomponenten</td> <td>Stückliste und Lieferantenvereinbarungen</td> </tr> <tr> <td>Systemarchitektur und Zusammenspiel der Komponenten (Nummer 2 Buchstabe c)</td> <td>Ja: Systemkomponenten, Datenfluss</td> <td>Stückliste und Architekturbeschreibung</td> </tr> <tr> <td>Trainingsdaten: Herkunft, Umfang, Beschaffung, Kennzeichnung, Bereinigung (Nummer 2 Buchstabe d)</td> <td>Weitgehend: Cluster Datensätze</td> <td>Datenblätter, Daten-Governance-Nachweis (Artikel 10)</td> </tr> <tr> <td>Maßnahmen der menschlichen Aufsicht (Nummer 2 Buchstabe e)</td> <td>Nein</td> <td>Aufsichtskonzept und Zuweisung (Artikel 14)</td> </tr> <tr> <td>Validierung und Tests: Metriken, Testprotokolle, unterzeichnete Berichte (Nummer 2 Buchstabe g)</td> <td>Am Rande: zwei Kennzahlenelemente</td> <td>Testberichte, Genauigkeitsmetriken (Artikel 15)</td> </tr> <tr> <td>Risikomanagementsystem (Nummer 5)</td> <td>Nein</td> <td>Risikomanagementakte (Artikel 9)</td> </tr> <tr> <td>Angewandte Normen, EU-Konformitätserklärung, Plan zur Beobachtung nach dem Inverkehrbringen (Nummern 7, 8, 9)</td> <td>Nein (nur Sicherheitszertifizierungen)</td> <td>Konformitätsakte</td> </tr> </table> Die Tabelle zeigt das Muster: Die Liste beantwortet die Frage, woraus ein System besteht. Sie beantwortet nicht, wofür es eingesetzt wird, wie riskant es ist, wer es beaufsichtigt und wie es geprüft wurde. Genau diese vier Fragen entscheiden aber über die Konformitätsbewertung. Eine Auslassung ist ausdrücklich gewollt. Die G7-Gruppe hat erörtert, ob der Grad der Entscheidungsbefugnis oder Autonomie des Systems ein eigenes Element werden soll, die Bedeutung des Themas mit Blick auf agentische KI anerkannt und sich dennoch dagegen entschieden. Die Begründung: Rechtsordnungen könnten die Frage unterschiedlich behandeln, auch über Anforderungen an die Sicherheit. Für europäische Leser ist das präzise der Gegenstand von Artikel 14 (menschliche Aufsicht) und der Hochrisiko-Einstufung. Der Nachweis muss also an anderer Stelle existieren, und die AI BOM sollte auf ihn verweisen. Auch das Schlusswort der Leitlinie ist bescheidener als manche Produktbroschüre. Eine SBOM für KI genügt für sich allein nicht; sie muss mit Werkzeugen der Cybersicherheit verbunden werden, also mit Schwachstellenscans und Schwachstellenmanagement, mit Sicherheitshinweisen und Bulletins.

Welche Gesetze die Inhalte einer AI BOM einforderbar machen

Die Liste ist freiwillig, ihr Inhalt ist es über weite Strecken nicht. Sechs Rechtsgrundlagen sind maßgeblich, alle aus der KI-Verordnung (EU) 2024/1689, der Cyberresilienz-Verordnung (EU) 2024/2847 und der NIS-2-Richtlinie.

• KI-Verordnung, Artikel 11 und Anhang IV. Die technische Dokumentation eines Hochrisiko-KI-Systems ist vor dem Inverkehrbringen oder der Inbetriebnahme zu erstellen und auf dem neuesten Stand zu halten; KMU dürfen eine vereinfachte Form nutzen. Anhang IV Nummer 2 verlangt unter anderem Angaben zu den verwendeten vortrainierten Systemen und Werkzeugen Dritter und zu deren Integration, zur Systemarchitektur sowie Datenblätter zu den Trainingsdaten und ihrer Herkunft. Nach Artikel 18 ist die Dokumentation 10 Jahre für die Behörden bereitzuhalten. Nach dem Digital-Omnibus, Verordnung (EU) 2026/1744, gelten die Pflichten für Systeme nach Anhang III ab dem 2. Dezember 2027 und für in Produkte nach Anhang I eingebettete Systeme ab dem 2. August 2028.
• KI-Verordnung, Artikel 25 Absatz 4. Der Anbieter eines Hochrisiko-KI-Systems und der Dritte, der ein darin verwendetes KI-System, Werkzeug, einen Dienst, eine Komponente oder ein Verfahren liefert, legen in einer schriftlichen Vereinbarung die erforderlichen Informationen, Fähigkeiten, den technischen Zugang und die sonstige Unterstützung fest. Ausgenommen sind Dritte, die Werkzeuge und Komponenten, die keine KI-Modelle mit allgemeinem Verwendungszweck sind, unter freier und quelloffener Lizenz öffentlich bereitstellen. Das ist die Rechtsgrundlage, um von einem Lieferanten eine AI BOM zu verlangen.
• KI-Verordnung, Artikel 53 sowie Anhänge XI und XII. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck führen eine technische Dokumentation für das KI-Büro und die nationalen Behörden und geben nachgelagerten Anbietern Informationen weiter, darunter Architektur und Parameterzahl, Modalität und Format der Ein- und Ausgaben, Lizenz sowie Art und Herkunft der Trainingsdaten. Diese Pflichten gelten seit dem 2. August 2025; der Praxisleitfaden vom Juli 2025 enthält dafür ein Formular zur Modelldokumentation.
• KI-Verordnung, Artikel 15. Genauigkeit, Widerstandsfähigkeit und Cybersicherheit von Hochrisiko-KI-Systemen, einschließlich Maßnahmen gegen die Vergiftung von Trainingsdaten und Modellen. Mehr dazu im Beitrag zur KI-Sicherheit.
• Cyberresilienz-Verordnung (CRA), Anhang I Teil II. Hersteller von Produkten mit digitalen Elementen erstellen eine Software-Stückliste in einem gängigen, maschinenlesbaren Format, die mindestens die obersten Abhängigkeiten des Produkts erfasst. Sie gehört zur technischen Dokumentation, wird den Marktüberwachungsbehörden auf Verlangen vorgelegt und muss nicht veröffentlicht werden. Die Meldung aktiv ausgenutzter Schwachstellen gilt seit dem 11. September 2026, die Verordnung insgesamt ab dem 11. Dezember 2027. Artikel 12 schlägt die Brücke: Ein Hochrisiko-KI-System, das ein Produkt mit digitalen Elementen ist und die grundlegenden Anforderungen der CRA erfüllt, gilt als konform mit der Cybersicherheitsanforderung aus Artikel 15 der KI-Verordnung, soweit die Konformitätserklärung dies abdeckt.
• NIS-2-Richtlinie. Die Sicherheit der Lieferkette gehört zu den Risikomanagementmaßnahmen nach Artikel 21.

Die Anwaltschaft zieht dieselbe Linie. Die Kanzlei Morgan Lewis stellt in ihrer Analyse vom 16. Juni 2026 fest, dass sich die G7-Liste mit den Artikeln 11 und 13 sowie Anhang IV überschneidet, und erwartet, dass künftige EU-Leitlinien einzelne Elemente aufgreifen. Das ist eine Einschätzung der Kanzlei, keine amtliche Aussage. Dieselbe Analyse ordnet den US-Hintergrund ein: SBOMs kamen mit der Executive Order 14028 (2021) und den NTIA-Mindestelementen vom Juli 2021 in die Bundesbeschaffung, und die G7-Liste versteht sich als Ergänzung dazu. Für Deutschland kommt ein eigener Anker hinzu. Das BSI hat den G7-Arbeitsstrang gemeinsam mit der italienischen ACN geleitet und veröffentlicht mit der Technischen Richtlinie TR-03183 bereits Anforderungen an SBOMs für die Cyberresilienz-Verordnung. Marktüberwachungsbehörde für die KI-Verordnung ist die Bundesnetzagentur.

Wie man eine AI BOM erstellt: eine Methode in sieben Schritten

1. Geltungsbereich festlegen. Eine AI BOM je KI-System und je Version, angehängt an den Eintrag des Systems im KI-Register oder in einem zentralen AI Registry.
2. Erzeugen, nicht abtippen. Die Angaben stammen aus der Modellregistrierung, der Trainingspipeline und dem Build, im Format der vorhandenen SBOM-Werkzeuge. Ein von Hand geschriebenes Dokument ist beim nächsten Nachtraining veraltet.
3. Die sieben Cluster füllen und „unbekannt“ schreiben, wo man es nicht weiß. Das betrifft vor allem Drittmodelle.
4. Hashen und signieren. Modelldateien, Datensatzdateien und das Dokument selbst.
5. Verknüpfen, was die AI BOM nicht enthält. Model Card, Risikomanagementakte, Aufsichtsmaßnahmen und Testberichte, etwa aus dem KI-Red-Teaming, gehören per Verweis dazu.
6. In Verträge aufnehmen. Lieferanten liefern das Dokument beim Onboarding und bei jeder neuen Modellversion, bei Hochrisiko-Systemen gestützt auf Artikel 25 Absatz 4. Die Klausel gehört in die Lieferanten-Due-Diligence.
7. Lebendig halten. Neu erzeugen bei jedem Nachtraining, jedem Fine-Tuning, jeder Änderung an Abhängigkeiten oder Werkzeugen; in das Schwachstellenmanagement einspeisen; Versionen 10 Jahre aufbewahren, wo KI-Verordnung oder CRA gelten. Auslöser sind häufig Befunde aus der Überwachung von Modelldrift oder eine KI-Vorfallmeldung.

Jeder dieser Schritte hinterlässt einen datierten Nachweis.

AI BOM für Drittmodelle und KI-Agenten

Zwei Fälle bereiten in der Praxis Schwierigkeiten. Modelle, die über eine API bezogen werden. Es gibt keine Gewichte, also auch keinen Hash. Der ehrliche Eintrag lautet „unbekannt“, ergänzt um die Dokumentation des Anbieters. Bei KI-Modellen mit allgemeinem Verwendungszweck schuldet der Modellanbieter den nachgelagerten Anbietern die Informationen nach Anhang XII, und diese füllen den größten Teil des Clusters Modelle: Architektur, Parameterzahl, Modalitäten, Lizenz, Art und Herkunft der Trainingsdaten. Agenten. Das G7-Element zum Datenfluss des Systems nennt bereits APIs externer Dienste, Kommunikationsprotokolle zwischen mehreren Agenten und die Anbindung an Websuche. Der NIST-Vortrag vom Mai 2026 skizziert darüber hinaus eine Stückliste für agentische Systeme, die Werkzeuge, MCP-Server, Prompts, Richtlinien, Speicher und Identitätsbindungen aufnimmt, dazu Laufzeitnachweise wie Werkzeugaufrufe, Freigaben und abgelehnte Aktionen. Kein Format standardisiert diese Ebene bisher. Bis dahin trägt man Werkzeuge und ihre Berechtigungsumfänge in die Cluster Systemkomponenten und Infrastruktur ein und führt die Laufzeitprotokolle getrennt. Die Einzelheiten behandelt der Beitrag zur Sicherheit von KI-Agenten; als allgemeine Referenz für die sichere Entwicklung eignen sich die Leitlinien des NCSC. Für Betreiber gilt eine einfachere Regel. Ein Betreiber schreibt selten selbst eine AI BOM. Er fordert sie an, liest drei Dinge heraus (welches Modell in welcher Version, welche Schutzbedürftigkeit der Daten, welche externen Dienste) und legt sie beim Systemeintrag ab.

Häufige Fragen

Was ist eine AI BOM in einfachen Worten? Eine Zutatenliste für ein KI-System. Sie hält in maschinenlesbarer Form fest, welche Modelle, Datensätze, Softwarebibliotheken, externen Dienste und Infrastrukturbestandteile in einer bestimmten Systemversion stecken und wie sie zusammenhängen. Die G7-Cybersicherheitsbehörden haben am 12. Mai 2026 dafür Mindestelemente veröffentlicht, nach unserer Zählung 50 Elemente in 7 Clustern. Der Nutzen ist praktisch: Fragen von Lieferanten, Kunden oder Behörden nach einem bestimmten Bestandteil lassen sich in einer Stunde beantworten statt in einer Woche. Worin unterscheidet sich eine AI BOM von einer SBOM? Die SBOM beschreibt Softwarekomponenten und ihre Abhängigkeiten. Die AI BOM ergänzt, was ein Paketmanifest nicht kennt: Modelle mit Gewichten, Architektur und Abstammung, Datensätze mit Herkunft, Lizenz und Schutzbedürftigkeit, Datenflüsse zu externen Diensten, KI-spezifische Sicherheitskontrollen. Die G7-Leitlinie stellt klar, dass KI-Systeme auch Softwaresysteme sind und die SBOM für sie gültig bleibt. Die neuen Elemente treten hinzu. In der Praxis entstehen beide Dokumente in derselben Pipeline und im selben Format. Ist eine AI BOM nach der KI-Verordnung Pflicht? Dem Namen nach nicht. Kein EU-Rechtsakt verwendet den Begriff. Verlangt wird jedoch ein großer Teil des Inhalts: für Hochrisiko-KI-Systeme über Artikel 11 und Anhang IV (verwendete Drittkomponenten, Architektur, Trainingsdaten), für KI-Modelle mit allgemeinem Verwendungszweck über Artikel 53 und die Anhänge XI und XII. Hinzu kommt die SBOM-Pflicht der Cyberresilienz-Verordnung für Produkte mit digitalen Elementen. Wer die AI BOM führt, erfüllt diese Pflichten nicht automatisch, hat aber das Material dafür strukturiert vorliegen. Welches Format sollte man verwenden? Dasjenige, das die vorhandene SBOM-Werkzeugkette bereits erzeugt. CycloneDX bietet seit Version 1.5 eine ML-BOM mit breiter Werkzeugunterstützung, aber weniger KI-Metadaten. Das KI-Profil von SPDX 3.0 reicht tiefer, etwa bei Erklärbarkeit und sensiblen personenbezogenen Daten, während die Werkzeuge noch reifen. Die G7-Leitlinie schreibt kein Format vor und verlangt nur, Name und Version des Formats anzugeben. Entscheidend ist die automatische Erzeugung, nicht die Formatfrage. Wer muss das Dokument erstellen, der Anbieter oder der Betreiber? Der Anbieter, also wer das System entwickelt oder unter eigenem Namen in Verkehr bringt, denn nur er hat Zugriff auf Trainingspipeline, Modellregistrierung und Build. Zulieferer von Modellen und Komponenten steuern ihre Teile bei, bei Hochrisiko-Systemen auf Grundlage der schriftlichen Vereinbarung nach Artikel 25 Absatz 4. Der Betreiber fordert das Dokument an, prüft Modellversion, Schutzbedürftigkeit der Daten und externe Dienste und legt es beim Systemeintrag ab. Ersetzt eine AI BOM die Model Card oder die technische Dokumentation? Nein. Die Model Card erläutert ein einzelnes Modell in Prosa, und die G7-Liste verweist per Link auf sie. Die technische Dokumentation nach Anhang IV verlangt zusätzlich die Zweckbestimmung, das Risikomanagementsystem, die Maßnahmen der menschlichen Aufsicht, Testberichte und die Konformitätserklärung. Davon enthält die AI BOM nichts oder nur Randangaben. Sie ist ein Baustein der Akte, der die Fragen zu Bestandteilen und Lieferkette abdeckt, und sollte auf die übrigen Bausteine verweisen.

Fazit

Der Inhalt einer AI BOM ist nicht länger die Meinung eines Herstellers: sieben Cluster, fünfzig Elemente, getragen von sieben Behörden. Was die Liste nicht sagt, ist ebenso wichtig: welches Gesetz gilt und was eine Behörde darüber hinaus verlangen wird. Zweckbestimmung, Risikoakte, Aufsicht und Testnachweise bleiben eigene Dokumente. Der sinnvolle Einstieg ist klein: mit einem System beginnen, die Stückliste aus Pipeline und Build erzeugen, „unbekannt“ ehrlich eintragen, signieren und den Rest der Akte verknüpfen. Danach folgen die Lieferantenverträge und die Anbindung an das Schwachstellenmanagement. AI Sigil führt jedes KI-System als Eintrag mit seinen Modellen, Datensätzen, Komponenten, Risiken, Kontrollen und Nachweisen, sodass die AI BOM einen festen Platz hat und der Rest der Akte einen Klick entfernt liegt.