Ein AIBOM ist ein strukturiertes Inventar dessen, woraus ein KI-System besteht: die Modelle und wie ihre Gewichte erzeugt wurden, die über den gesamten Modell-Lebenszyklus verwendeten Datensätze, die Infrastruktur, auf der es läuft, die Sicherheitskontrollen darum herum und die Leistungskennzahlen, gegen die es abgenommen wurde. Eine KI-Stückliste leistet für eine Modell-Pipeline das, was eine Teileliste für eine Maschine leistet, und im Lauf des vergangenen Jahres ist sie von Forschungsarbeiten in die Beschaffung gewandert. Dieser Wandel zeigt sich unmittelbar in unserer eigenen Arbeit im Bereich Entwicklung großer Sprachmodelle, wo das Inventar zunehmend gemeinsam mit dem Modell aufgebaut wird, statt erst zusammengestellt zu werden, nachdem ein Kunde danach gefragt hat.
Im Mai 2026 veröffentlichten die Cybersicherheitsbehörden der G7 eine gemeinsame Leitlinie zu Mindestelementen genau für dieses Artefakt, die sich über 50 benannte Elemente in sieben Clustern erstreckt. Diese Liste ist inzwischen das Vokabular, auf das das Sicherheitsteam eines Unternehmenskäufers zurückgreift, wenn es fragt, was in dem Produkt steckt, das Sie verkaufen. Im Folgenden zeigen wir, woher diese Anfragen kommen, welche Felder in den Datensatz gehören, welche Felder eine Pipeline von sich aus liefert und wo die Analogie zum Software-Inventar an ihre Grenzen stößt.
Woher AIBOM-Anfragen kommen
Das Dokument hinter der aktuellen Welle ist Software Bill of Materials for AI: Minimum Elements, veröffentlicht am 12. Mai 2026 von sieben nationalen Cybersicherheitsbehörden gemeinsam mit der Europäischen Kommission: dem deutschen BSI, der italienischen ACN, der französischen ANSSI, dem kanadischen CSE, der US-amerikanischen CISA, dem britischen NCSC und dem japanischen NCO. Es entstand aus einem Arbeitsstrang der G7-Cybersicherheitsarbeitsgruppe, der von August 2025 bis Februar 2026 lief.
Die eigene Einordnung des Dokuments ist ungewöhnlich direkt hinsichtlich seiner Grenzen und stellt fest, dass die Mindestelemente „nicht verpflichtend sind; sie schaffen keine Anforderungen, Standards oder Gesetze.“ Dieser Hinweis erklärt die Geschwindigkeit, mit der es sich verbreitet hat: Eine freiwillige Feldliste mit sieben Regierungsunterschriften ist für ein Beschaffungsteam nahezu kostenlos in einen Fragebogen zu übernehmen. Sie erreicht einen Anbieter auf einem von vier Wegen:
- Ein Sicherheitsfragebogen beim Onboarding von Anbietern, bei dem ein KI-Abschnitt an eine bestehende Frage zum Software-Inventar angehängt wird.
- Ein vertragliches Deliverable in einem unternehmensweiten Rahmenvertrag für Dienstleistungen, formuliert als Verpflichtung, ein Inventar der KI-Komponenten zu führen.
- Ein internes Governance-Programm beim Kunden, bei dem jemand die KI-Nutzung an ein Gremium, einen Prüfer oder eine Aufsichtsbehörde meldet.
- Due-Diligence-Prüfungen bei einer Übernahme oder Finanzierungsrunde, bei denen der Käufer fragt, ob die Herkunft Ihres Modells einer genauen Prüfung standhält.
Zwei dieser Wege enden in einer technischen Überprüfung Ihrer Codebasis und Modell-Pipeline statt in einem Dokumentenaustausch, was einem Audit der KI-Implementierung im Unternehmen deutlich näherkommt als dem Ausfüllen eines Formulars. Die Leitlinie merkt zudem an, dass ihre Elemente in manchen Rechtsordnungen „bereits durch gesetzliche Anforderungen und Verpflichtungen abgedeckt sein oder voraussichtlich abgedeckt werden können“, ein Satz, der für jeden, der in die EU verkauft, sehr viel Gewicht hat. Für einen genaueren Blick darauf, was diese technische Überprüfung tatsächlich prüft und warum gerade Regulierungsbehörden darauf drängen, lesen Sie unsere Aufschlüsselung dazu, was ein KI-Audit abdeckt und warum es Regulierungsbehörden wichtig ist.
Was in einem AIBOM steckt, Feld für Feld
Hier ist die vollständige Liste, Cluster für Cluster, mit den ursprünglichen Elementnamen aus der Leitlinie. Behandeln Sie dies als Ihre AIBOM-Vorlage und streichen Sie nichts ohne einen Grund, den Sie vor dem Sicherheitsverantwortlichen eines Kunden vertreten könnten.
Metadaten (10 Elemente) beschreiben den Datensatz selbst, nicht das System: SBOM-Autor, SBOM-Version, Name des SBOM-Datenformats, Version des SBOM-Datenformats, Signatur des SBOM-Autors, Name des SBOM-Tools, Version des SBOM-Tools, Generierungskontext des SBOM, Zeitstempel des SBOM und Abhängigkeitsbeziehung des SBOM. Das Element, das gerne übersprungen wird, ist der Generierungskontext, der festhält, ob das Inventar aus dem Quellcode, aus dem Build oder aus einer ausgelieferten Binärdatei stammt. Diese drei weichen auf vorhersehbare Weise voneinander ab, und der Leser muss wissen, welche davon vorliegt.
Systemebene-Eigenschaften (9 Elemente) decken das System als Ganzes ab: Systemname, Systemkomponenten, Systemhersteller, Systemversion, Zeitstempel des Systems, Datenfluss des Systems, Datennutzung des Systems, Ein-/Ausgabe-Eigenschaften des Systems und vorgesehener Anwendungsbereich. Im Datenfluss des Systems werden Multi-Agenten-Protokolle, externe Service-APIs und bidirektionaler Web-Grounding-Verkehr deklariert, sodass dieser Cluster offenlegt, ob Ihr Produkt zur Inferenzzeit stillschweigend das Modell eines anderen Anbieters aufruft. Genau diese Ebene müssen unsere Projekte zur Transformation der Arbeitskraft durch agentische KI zuerst kartieren, denn wenn ein Agent in Ihrem Auftrag drei weitere Modelle aufruft, bedeutet das drei zusätzliche Einträge, die dieser Cluster tragen muss.
Modelle (13 Elemente) ist der größte Cluster: Modellname, Modellkennung, Modellversion, Zeitstempel des Modells, Modellhersteller, Modellbeschreibung, Hashwert des Modells, Hash-Algorithmus des Modells, Modelleigenschaften, Eingabe-Ausgabe-Eigenschaften des Modells, Trainingseigenschaften des Modells, Modelllizenz und externe Referenzen des Modells. Das Hash-Paar hat hier das größte Gewicht, denn ohne einen Hashwert und den Algorithmus, der ihn erzeugt hat, ist jede andere Aussage in diesem Cluster eine Behauptung, die der Empfänger nicht überprüfen kann.
Eigenschaften der Datensätze (10 Elemente) deckt Datensatzname, Datensatzbeschreibung, Datensatzinhalt, Datensatzkennung, Hash des Datensatzes, Herkunft des Datensatzes, statistische Eigenschaften des Datensatzes, Sensibilität des Datensatzes, Abhängigkeitsbeziehung des Datensatzes und Datensatzlizenz ab. Dies ist der Cluster, der interne Diskussionen auslöst, da er für jeden Datensatz über den gesamten Modell-Lebenszyklus hinweg gilt, einschließlich Evaluierungs- und Fine-Tuning-Datensätzen. Diese Abstammung zu entwirren, ist meist eher ein Problem der Datentechnik (Data Engineering) als der Dokumentation, denn Sie können keine Herkunft aufzeichnen, die Sie nie erfasst haben.
Infrastruktur (2 Elemente) deckt Infrastruktur-Software und Infrastruktur-Hardware ab, zuzüglich eines Links zu einer Hardware-Stückliste, sofern vorhanden.
Sicherheitseigenschaften (4 Elemente) decken Sicherheitskontrollen, Sicherheits-Compliance, Informationen zur Cybersicherheitsrichtlinie und Verweise auf Schwachstellen ab.
Wichtige Leistungsindikatoren (2 Elemente) decken Sicherheitskennzahlen und operative Leistungs-KPIs ab. Diese drei kurzen Cluster werden am häufigsten leer ausgeliefert, was wie ein Inventar wirkt, das frühzeitig aufgegeben hat.
Automatisch generierte Felder im Vergleich zu manuell erstellten Feldern
Leitlinien zur Erstellung von AIBOM-Datensätzen neigen dazu, die Datei als ein einziges Deliverable mit einem einzigen Verantwortlichen darzustellen. Fünfzig Elemente, die Code, Daten, Infrastruktur, Sicherheit und Rechtliches umfassen, sind konstruktionsbedingt funktionsübergreifend, und sie danach aufzuteilen, wer sie erzeugen kann, macht aus einem ins Stocken geratenen Projekt zwei handhabbare. Nach unserer Zählung stammen 27 Elemente direkt aus Werkzeugen, die die meisten Teams bereits einsetzen, während die verbleibenden 23 ein menschliches Urteilsvermögen erfordern, das kein Scanner leisten kann.
Felder, die die Pipeline erzeugt
Alles, was identitätsförmig ist, und alles, was hashförmig ist, gehört zur Pipeline. Der Metadaten-Cluster ist fast vollständig ein Nebenprodukt des Generierungsschritts, da das Tool seinen eigenen Namen und seine Version, den Zeitstempel, das Datenformat und die Lebenszyklusphase kennt, in der es ausgeführt wurde. Modell- und Datensatzkennungen, -versionen, -zeitstempel und -hashes stammen aus Ihrer Modellregistry und Ihrem Objektspeicher, und der Infrastruktur-Cluster stammt aus den Infrastructure-as-Code-Definitionen, die Ihre Beschleuniger bereits bereitstellen.
Die beiden Leistungsindikator-Elemente gehören unter einer Bedingung hierher: Ihr Evaluierungs-Framework schreibt Ergebnisse an einem dauerhaften Ort. Erzeugen Sie sie bei jeder Modellveröffentlichung aus der CI, sind sie konstruktionsbedingt korrekt, während das vierteljährliche erneute Eintippen in eine Tabelle sie innerhalb einer Woche nach dem nächsten Deployment falsch werden lässt.
Felder, die ein Mensch schreibt
Die verbleibenden Elemente sind Werturteile, und ein Scanner hat keine Grundlage, um sie zu treffen. Jedes braucht einen benannten Verantwortlichen:
- Vorgesehener Anwendungsbereich. Zu erklären, dass ein Klassifikator in einem medizinischen, finanziellen oder cybersicherheitsrelevanten Kontext läuft, ist eine Abgrenzungsentscheidung mit regulatorischen Konsequenzen, die keine statische Analyse ableiten kann.
- Herkunft und Sensibilität des Datensatzes. Die Herkunft gibt an, woher die Daten stammen und zu welchen Bedingungen, die Sensibilität gibt an, was ein Datenleck kosten würde. Beides gehört zur Data Governance und zum Rechtsbereich, und beides prüft ein ernsthafter Prüfer zuerst.
- Trainingseigenschaften und Einschränkungen des Modells. Die nützliche Version nennt die Bedingungen, unter denen das Modell an Leistung verliert, genau das Material, das Anbieter instinktiv abschwächen.
- Sicherheitskontrollen, Compliance und Richtlinieninformationen. Diese beziehen sich auf ein bestehendes Kontrollrahmenwerk und werden daher aus Ihrem Sicherheitsprogramm übernommen statt aus dem Code generiert.
- Die Autorensignatur. Eine Signatur ist eine Schlüsselverwaltungsentscheidung darüber, welche Instanz für den Inhalt einsteht, und macht aus einer Beschreibung eine Verpflichtung.
Felder in dieser Gruppe veralten leise, weil in der Produktion nichts kaputtgeht, wenn sie falsch werden. Geben Sie jedem einen Verantwortlichen und einen Überprüfungsauslöser, der an das Neutrainieren des Modells gekoppelt ist, statt an ein Kalenderdatum.
Die SBOM-Analogie und wo sie endet
Der Vergleich zwischen AIBOM und SBOM hält auf der Ebene des Zwecks gut stand und bricht auf der Ebene der Überprüfbarkeit auseinander. Beide sind Zutatenlisten, die es einem Abnehmer erlauben, über das Risiko von etwas nachzudenken, das er nicht selbst gebaut hat, und das G7-Dokument stellt ausdrücklich klar, dass KI-Systeme auch Softwaresysteme sind, sodass die KI-Cluster auf einem konventionellen Software-Inventar aufsetzen.
Inventareinheit
Softwarekomponenten und -pakete
Modelle, Datensätze und das System, das sie zusammensetzt
Identitätsnachweis
Komponentenname, Version, Hash
Hashwert des Modells plus Hash-Algorithmus, Hash und Kennung des Datensatzes
Herkunft
Lieferant und Abhängigkeitsbeziehung
Herkunft des Datensatzes über den gesamten Modell-Lebenszyklus
Laufzeitverhalten
Außerhalb des Umfangs
Datenfluss des Systems, Ein-/Ausgabe-Eigenschaften, vorgesehener Anwendungsbereich
Rechtliche Angriffsfläche
Komponentenlizenz
Modelllizenz und Datensatzlizenz, einschließlich des Open-Weight-Status
Leistung
Außerhalb des Umfangs
Sicherheitskennzahlen und operative Leistungs-KPIs
Empfänger kann es allein verifizieren
In der Regel durch erneutes Hashen des Pakets
Teilweise: Gewichte lassen sich sauber hashen, Trainingsdaten nicht
Bei der Überprüfbarkeit endet die Analogie. Eine Abhängigkeitsaussage lässt sich günstig testen: Paket herunterladen, hashen, vergleichen. Eine Aussage zur Herkunft von Trainingsdaten bleibt für einen Empfänger, der weder die Daten noch die Rechenleistung besitzt, um die Gewichte neu zu erzeugen, unüberprüfbar. Sanchit Vir Gogia hat die Grenze in CSO Online präzise auf den Punkt gebracht: „Mindestelemente schaffen Transparenz. Sie schaffen keine Gewissheit. Sie sagen dem Käufer, was der Anbieter behauptet, dass es existiert.“
Die Autoren des G7-Dokuments kommen aus der entgegengesetzten Richtung zum selben Schluss und stellen fest, dass ein solches Inventar „für sich allein nicht ausreicht, um die Cybersicherheit entlang der Lieferkette zu erhöhen“, und nur funktioniert, wenn es mit Tools für Schwachstellen-Scanning und -Management verknüpft wird. Für einen Käufer macht das dieses Dokument zu einem Ausgangspunkt für Fragen, und die naheliegende Folgemaßnahme ist eine unabhängige Überprüfung der Codebasis und der Modell-Pipeline, die hinter den Behauptungen steht. Für einen Anbieter sind Felder, die Sie mit einem Hash oder einem signierten Artefakt belegen können, in einer Verhandlung weitaus mehr wert als Felder, die Sie nur behaupten können.
Vom Papierkram zum Produktartefakt
Teams, die aufhören, diese Anfrage zu fürchten, sind die, die das Artefakt in den Build integrieren. Die Mechanik ist unspektakulär: ein maschinenlesbares Format wählen, die automatischen Felder bei jeder Modellveröffentlichung in der CI generieren, die von Menschen erstellten Felder zusammen mit dem Code in der Versionskontrolle halten, damit sie den Review durchlaufen, und das Ergebnis als signiertes Artefakt zur Veröffentlichung publizieren.
Die Formatwahl ist inzwischen so weit geklärt, dass sie langweilig ist. OWASPs CycloneDX bietet einen eigens dafür gebauten Komponententyp für Machine-Learning-Modelle und eine externe Model-Card-Referenz, und Version 1.7 der Spezifikation erschien im Oktober 2025, sodass die Werkzeuge bereits heute existieren und nicht nur auf einer Roadmap stehen. SPDX ist die glaubwürdige Alternative, und die G7-Leitlinie verweist auf SPDX- und CycloneDX-Felder als akzeptable Orte für Informationen zur Modelllizenzierung.
Zwei Designentscheidungen leisten den Großteil der Arbeit. Generieren Sie pro Release statt pro Quartal, denn ein Inventar, dessen Zeitstempel Ihrem bereitgestellten Modell hinterherhinkt, signalisiert einem Prüfer, dass Ihr Prozess nur Dekoration ist. Behandeln Sie von Menschen erstellte Felder wie geprüften Code, sodass das Herabstufen einer Sensibilitätsklassifizierung die Freigabe von jemandem erfordert, der dafür verantwortlich ist.
Das ist gewöhnliche Automatisierung von Release-Artefakten, weshalb Engineering-Teams, die einem bestehenden Produkt KI-Funktionen hinzufügen, am besten daran tun, den Generierungsschritt gleich zusammen mit dem Inferenzpfad zu entwerfen. Die Teams, die damit zu kämpfen haben, sind jene, bei denen niemand die Modellregistry verantwortet, und das ist eine organisatorische Lücke im Kostüm eines Dokumentationsproblems.
Die Nachfrage nach diesem Artefakt steigt weiter, und die Feldliste ist inzwischen stabil genug, um mit Zuversicht darauf aufzubauen. Erzeugen Sie das Inventar einmal als Nebenprodukt Ihres Release-Prozesses, und eine unangenehme Frage wird zu einem Link, den Sie in einen Fragebogen einfügen. Wenn Sie Hilfe dabei möchten, diesen Generierungsschritt in eine Pipeline einzubauen, die Sie bereits betreiben, kontaktieren Sie uns, und wir starten von dem, was Sie bereits haben, statt von einem leeren Blatt.
Häufig gestellte Fragen
Was ist ein AIBOM?
Es handelt sich um ein strukturiertes Inventar der Komponenten eines KI-Systems: die Modelle und wie ihre Gewichte erzeugt wurden, die über den gesamten Modell-Lebenszyklus verwendeten Datensätze, die Infrastruktur, auf der es läuft, die darauf angewendeten Sicherheitskontrollen und seine Leistungsindikatoren. Die G7-Leitlinie zu Mindestelementen gliedert es in sieben Cluster mit 50 benannten Elementen, von denen eines das Dokument selbst und sechs das System beschreiben.
Was ist der Unterschied zwischen SBOM und AIBOM?
Ein Software-Inventar listet Komponenten, Versionen und Abhängigkeitsbeziehungen auf. Die KI-Version fügt Cluster für Modelle, Datensätze, Infrastruktur, Sicherheitseigenschaften und wichtige Leistungsindikatoren hinzu, die die G7-Leitlinie als Ergänzungen und nicht als Ersatz behandelt. Der praktische Unterschied liegt in der Überprüfbarkeit: Ein Paket-Hash kann von jedem, der ihn erhält, erneut geprüft werden, während eine Aussage zur Herkunft von Trainingsdaten das in der Regel nicht kann.
Was sollte ein AIBOM enthalten?
Mindestens die sieben Cluster aus der G7-Leitlinie: Metadaten, Systemebene-Eigenschaften, Modelle, Eigenschaften der Datensätze, Infrastruktur, Sicherheitseigenschaften und Wichtige Leistungsindikatoren. Die Felder, die bei der Prüfung durch einen Käufer am meisten Gewicht haben, sind der Hashwert und der Hash-Algorithmus des Modells, die Herkunft und Sensibilität des Datensatzes, der Datenfluss des Systems, der vorgesehene Anwendungsbereich und die Autorensignatur.
Ist ein AIBOM verpflichtend?
Die G7-Mindestelemente sind freiwillig und stellen direkt fest, dass sie keine Anforderungen, Standards oder Gesetze schaffen. Die Verpflichtung entsteht stattdessen vertraglich, über Sicherheitsfragebögen, Beschaffungsbedingungen und Anbieter-Risikoprogramme, und die Leitlinie merkt an, dass dieselben Elemente in manchen Rechtsordnungen bereits in bestehenden gesetzlichen Anforderungen enthalten sein können.
Erfahren Sie, wie Redwerk die Kernentwicklung einer KI-Optimierungsplattform übernahm und sie zu einem erfolgreichen Produkt-Launch führte
