AI Bill of Materials (AIBOM): Vollständiger Leitfaden

Ein AI Bill of Materials (AIBOM) ist ein strukturiertes Inventar der Datensätze, Modelle und Abhängigkeiten in einem KI-System und schafft Transparenz in der KI-Lieferkette.

Was ist eine AI Bill of Materials (AIBOM)?

Im Mai 2026 erreichte ein bösartiges Hugging Face-Repository, das sich als offizielle OpenAI-Veröffentlichung ausgab, die Spitzenposition der Trendliste der Plattform, bevor es gekennzeichnet und entfernt wurde. Da die echte Modellkarte nahezu Zeile für Zeile kopiert worden war, wirkte der Eintrag legitim, und jeder, der ihn bereits heruntergeladen hatte, konnte dies nicht erkennen, weil ein Scan von Softwareabhängigkeiten Bibliotheken und Pakete prüft, während die Kompromittierung im Modell selbst lag.

Eine AI bill of materials (AIBOM) liefert Ihnen, was dieser Scan nicht leisten konnte: eine Möglichkeit festzustellen, ob sich ein kompromittiertes Modell oder ein vergifteter Datensatz bereits in Ihrer Umgebung befindet.

Eine AIBOM ist ein strukturiertes Inventar der Datensätze, Modelle, Frameworks und Abhängigkeiten, aus denen ein KI-System besteht, wobei die Herkunft jeder Komponente dokumentiert wird. Sie umfasst die Assets, deren Herkunft andernfalls nicht dokumentiert wäre: Daten von Drittanbietern, vortrainierte Modelle und Open-Source-Bibliotheken.

Wie sich eine AIBOM zu einer Software Bill of Materials verhält

Eine Software Bill of Materials listet die Softwarekomponenten und Abhängigkeiten in einer Anwendung auf: Bibliotheken, Pakete, Versionskennungen und Lizenzen. Eine AIBOM erweitert diese Inventarpraxis auf KI-spezifische Assets, einschließlich Trainingsdaten, Modellgewichten, Modellherkunft und Performance-Baselines. CycloneDX, der OWASP BOM-Standard, setzt dies um, indem SBOM und AI/ML-BOM als interoperable BOM-Typen definiert werden.

Kernkomponenten einer AIBOM

Eine AIBOM erfasst die vollständige Menge an Komponenten, die die Zusammensetzung, Herkunft und das Betriebsprofil eines KI-Systems definieren. Die Leitlinien der G7 Cybersecurity Working Group vom Mai 2026, veröffentlicht als CISA's AI SBOM minimum elements, gliedern diese Komponenten in sieben Cluster.

Komponentencluster	Was erfasst wird	Warum es dazugehört
Metadaten	Autor der AIBOM, Erstellungsdatum, Schemaversion, Dokumentkennung	Stellt die Nachvollziehbarkeit der Verwahrung für das Inventarartefakt her
Eigenschaften auf Systemebene	Softwareabhängigkeiten, Frameworks, Laufzeitumgebungen, Datenverarbeitungslogik	Entspricht traditionellem SBOM-Inhalt; ermöglicht CVE-Nachverfolgung
Modelle	Modellidentität, Architektur, wie Gewichte erzeugt wurden (trainiert, feinabgestimmt oder destilliert), dokumentierte Einschränkungen	Für Modellgewichte gibt es kein Äquivalent zu einem Paketmanager; die Herkunft ermöglicht die Identifizierung von Manipulationen
Datensatzeigenschaften	Identität, Herkunft, Lizenzierung, Erhebungsmethodik und angewandte Vorverarbeitung von Trainings-, Validierungs- und Testdatensätzen	Data Poisoning ist durch Softwareanalyse nicht identifizierbar; Herkunftsaufzeichnungen verfolgen nach, ob Trainingsdaten manipuliert wurden
Key Performance Indicators	Bei der Bereitstellung erfasste Benchmarks für Genauigkeit, Fairness und Widerstandsfähigkeit gegen adversariale Angriffe	Legt Verhaltens-Baselines fest; Verschlechterungen können auf adversariale Manipulation hinweisen
Infrastruktur	Physische und virtuelle Infrastruktur, Verknüpfungen zu Hardware BOM für spezialisierte KI-Hardware (GPUs, TPUs)	Dokumentiert die Compute-Umgebung, die das Modell erzeugt hat und ausführt
Dokumentstruktur und Aktualisierungsrhythmus	Versionsverwaltung des AIBOM-Formats, Auslöser für Aktualisierungen, Aufzeichnungen zu Lifecycle-Übergängen	Definiert, wann und wie das Inventar aktualisiert wird; verknüpft jeden Übergang im Lifecycle mit erforderlichen Änderungen in den betroffenen Clustern

Diese sieben Cluster beschreiben, was eine AIBOM enthält. Wann Sie jeden davon befüllen, hängt vom Modell-Lifecycle ab: Der Datensatz wird stufenweise aufgebaut, nicht in einem einzigen Durchlauf.

Wie eine AIBOM über den gesamten Modell-Lifecycle hinweg erstellt und gepflegt wird

Ein AIBOM-Datensatz nimmt über vier Lifecycle-Phasen Gestalt an, wobei jede Phase bestimmte Cluster aus der oben genannten Komponententaxonomie befüllt.

1. Datenbeschaffung und -vorbereitung. Hier beginnt die AIBOM mit den Datensatzeigenschaften: Sie erfassen Identität, Herkunft, Lizenzierung und Integrität jedes Trainings-, Validierungs- und Testdatensatzes, bevor das Modelltraining beginnt. Aktualisieren Sie diesen Cluster bei der ersten Erhebung und bei jedem Retraining- oder Fine-Tuning-Ereignis.
2. Modelltraining und Fine-Tuning. Während des Trainings erfassen Sie die Verknüpfung zwischen Eingabedatensätzen, Trainingscode, Hyperparameter-Konfigurationen und den resultierenden Modellgewichten. Fine-Tuning-Ereignisse erfordern Aktualisierungen sowohl im Modell-Cluster als auch im Datensatz-Cluster.
3. Build und Bereitstellung. Bei der Bereitstellung befüllen Sie den Cluster Eigenschaften auf Systemebene vollständig mit Details zu Softwareabhängigkeiten, Frameworks und Laufzeitumgebung. KPI-Basiswerte werden erfasst. Infrastrukturkomponenten werden dokumentiert oder über ein HBOM verknüpft.
4. Laufende Überwachung und Wartung. Die Pflege einer AIBOM ist ereignisgesteuert. Änderungen an beliebigen Komponenten in den sieben Clustern lösen Aktualisierungen aus, einschließlich neu trainierter Modelle, gepatchter Abhängigkeiten, Datensatzversionen und Infrastrukturänderungen. Tools zur autonomen Erkennung und maschinenlesbare Formate halten den Datensatz korrekt, indem sie ihn aktualisieren, wenn Änderungen auftreten.

Über diese vier Phasen hinweg bleibt eine AIBOM nur dann zuverlässig, wenn ihr Format und ihre Aktualisierungsregeln im Voraus festgelegt sind, was die aktuellen Standards vorgeben.

AIBOM-Standards und Frameworks

Vier ineinandergreifende Standards bilden derzeit die maßgebliche Grundlage für die Implementierung einer AIBOM. Jeder adressiert eine andere Ebene des Governance-Stacks.

1. NIST AI Risk Management Framework. Das NIST AI Risk Management Framework etabliert Nachverfolgbarkeit und Rechenschaftspflicht als grundlegende Eigenschaften für vertrauenswürdige KI. Seine erste Veröffentlichung, AI RMF 1.0, setzte diese Baseline im Januar 2023, und das Generative AI Profile erweiterte sie im Juli 2024 auf generative Systeme. Der Bericht von NIST vom April 2025 AI 100-5e2025 verknüpft KI-Lieferketten ausdrücklich mit SBOM-Mechanismen und verweist auf Modell- und Datenkarten neben Software Bills of Materials als Transparenzinstrumente.
2. OWASP CycloneDX ML-BOM. Die ML-BOM-Funktionalität, eingeführt in CycloneDX v1.5 und in späteren Versionen erweitert, bildet Datensätze, Modelle und Konfigurationen für AI/ML-Systeme ab, einschließlich Herkunftsdokumentation und ethischer Erwägungen für Datensätze.
3. SPDX 3.0 AI- und Datensatz-Profile. SPDX, ein ISO/IEC-Standard, ergänzte in Version 3.0 AI- und Datensatz-Profile. Diese Profile dokumentieren KI-Modelle, Trainingsdaten, Prompt-Vorlagen, KI-Agenten und Lizenzierung.
4. CISA- und G7-Mindestelemente. CISA veröffentlichte SBOM Minimum Elements für KI-Software im August 2025. Im Mai 2026 veröffentlichten Cybersicherheitsbehörden aus allen G7-Mitgliedstaaten sowie der EU gemeinsame Leitlinien, die sieben Cluster potenzieller Elemente für AI SBOMs definieren, dargelegt in the joint G7 guidance.

Die Einführung von AIBOMs befindet sich noch in einem frühen Stadium, und aktuelle Implementierungen sind oft unvollständig oder ungenau. Aber die Standards geben Ihnen eine Grundlage, auf der Sie aufbauen können.

Warum eine AIBOM für Sicherheit, Compliance und Auditierbarkeit wichtig ist

Für die Sicherheit erfasst eine AIBOM die Herkunft von Datensätzen und Prüfsummen von Modellgewichten, damit Teams untersuchen können, ob Modelle mit manipulierten Daten trainiert wurden. Wenn Schwachstellen oder kompromittierte Komponenten die KI-Infrastruktur betreffen, zeigt Ihnen die AIBOM, welche Systeme betroffen sind.

Für die Compliance umfasst der EU AI Act Transparenz- und Dokumentationspflichten für bestimmte KI-Systeme und Modelle, einschließlich technischer Dokumentation und Zusammenfassungen von Trainingsinhalten. Eine AIBOM unterstützt diese Pflichten, indem sie einen strukturierten Datensatz zur Zusammensetzung erstellt.

Für die Auditierbarkeit gibt die AIBOM Auditoren und Incident Response Teams eine nachvollziehbare, versionierte Antwort, wenn sie fragen, woraus ein bestimmtes KI-System aufgebaut wurde. Der Datensatz zeigt, welche Datensätze es trainiert haben, welche Modellgewichte bereitgestellt sind und welche Frameworks und Abhängigkeiten es unterstützen. Ohne diesen Datensatz ist Ihre Antwort auf jede Auditfrage zur KI-Zusammensetzung bestenfalls ein Rekonstruktionsversuch.

Jedes dieser Ergebnisse setzt voraus, dass der Datensatz korrekt und aktuell ist. Diesen Zustand im Unternehmensmaßstab zu erreichen, stößt auf strukturelle Einschränkungen, die sich nicht allein durch Aufwand beseitigen lassen.

Herausforderungen bei der Implementierung einer AIBOM

Strukturelle Einschränkungen erschweren die Implementierung einer AIBOM unabhängig vom Reifegrad oder der Ressourcenausstattung einer Organisation.

• Unreife Standards und Tools. CycloneDX ML-BOM, SPDX 3.0 AI-Profile und die G7-Leitlinien sind alle erst vor Kurzem erschienen, daher befinden sich Praktiken und Tools noch in der Konsolidierung.
• Intransparente Modelle von Drittanbietern. Proprietäre Foundation-Modelle, die über Inference-APIs genutzt werden, legen nur wenig über ihre internen Details offen. Sie können Name, Version, Endpoint, Zugriffskontrollen und Herstellerbestätigungen erfassen, aber die vollständige Zusammensetzung geschlossener Modelle bleibt außer Reichweite.
• Herkunft von Trainingsdaten. Bei extern trainierten Modellen wird die Herkunft möglicherweise nie offengelegt. Bei internen Modellen müssen Sie sie während des Trainings erfassen, weil eine nachträgliche Rekonstruktion unzuverlässig ist.
• Schnelle Modellversionierung. Jedes Retraining oder jede Parameteränderung erzeugt eine neue effektive Version mit eigenem Risikoprofil und führt zu einer Versionsflut, die kein manueller Prozess im großen Maßstab nachverfolgen kann.
• Heterogene Umgebungen. Unternehmens-KI erstreckt sich über Cloud-Anbieter, On-Premises-Infrastruktur, SaaS-KI-Tools, eingebettete KI in Drittanbieteranwendungen, agentische Systeme und Vektordatenbanken.

Diese Einschränkungen sind extern, daher können Sie höchstens Ihr Design daran ausrichten. Die Fehler im nächsten Abschnitt sind das Gegenteil, und es liegt an Ihnen, sie zu verhindern.

Häufige Fehler bei der AIBOM-Implementierung

Fehler	Folge
Die AIBOM als einmaliges Dokument behandeln, das für ein Audit erstellt wird	Incident Response trifft Entscheidungen auf Basis eines Datensatzes, der die Produktion nicht mehr widerspiegelt
Das Inventar manuell pflegen	Die Geschwindigkeit von Änderungen an Modellen, Datensätzen und APIs übersteigt jeden von Menschen betriebenen Prozess, sodass der Datensatz veraltet
Modellnamen und Versionen ohne Herkunft erfassen	Data- und Model-Poisoning bleiben nicht identifizierbar, weil die Identifizierung von Trainingsherkunft, Prüfsummen der Gewichte und Laufmetadaten abhängt, die sich nachträglich nicht rekonstruieren lassen
Die AIBOM als eigenständige Compliance-Datei betreiben, die von Engineering-Tools getrennt ist	Es entstehen zwei Inventare, die auseinanderlaufen; CISA's SBOM guidance definiert die Bill of Materials als verschachteltes Inventar für Lieferkettenrisiken, und der Betrieb der AIBOM außerhalb der SBOM-Toolchain kappt diese Verbindung
Den Umfang des Inventars auf von der IT genehmigte KI beschränken und Shadow AI auslassen	Im Datensatz bleibt ein systematischer blinder Fleck bestehen

Jeder der oben genannten Fehler ist eine Prozessentscheidung, daher hat jeder eine prozessuale Lösung. Die folgenden Praktiken machen aus dem Inventar eine operative Kontrolle statt einer statischen Datei.

AIBOM-Best Practices

Die folgenden Maßnahmen entwickeln Ihr AIBOM-Programm von statischer Dokumentation zu einem operativen Governance-Instrument weiter.

• Autonome Erkennung und Generierung bereitstellen. Integrieren Sie sie in Modellregister, API-Gateways und Inventare von Cloud-KI-Services.
• Auf ein maschinenlesbares Format standardisieren. Geben Sie CycloneDX ML-BOM oder SPDX 3.0 AI-Profile aus. Für Menschen lesbare Tabellen können die Workflows nicht speisen, die den Sicherheitswert des Inventars operationalisieren.
• Herkunft an der Quelle erfassen. Erfassen Sie Kennungen von Trainings- und Fine-Tuning-Datensätzen, Prüfsummen von Modellgewichten, Metadaten von Trainingsläufen und Versions-Pins von Inference-APIs. Bei internen Modellen sollten Sie die Herkunftsverfolgung zur Trainingszeit in die ML-Pipeline instrumentieren.
• CI/CD anhand der AIBOM steuern. Erzeugen Sie die AIBOM bei der Erstellung von Trainingsartefakten, bei Registry-Push-Ereignissen und bei Änderungen an Bereitstellungskonfigurationen, und behandeln Sie eine fehlende oder veraltete AIBOM als Pipeline-Fehler, der die Promotion in die nächste Umgebung stoppt.
• Kontinuierlich auf Drift überwachen. Vergleichen Sie bei jedem Bereitstellungsereignis die Hashes bereitgestellter Modellartefakte mit den in der AIBOM erfassten Hashes. Ein ereignisgesteuerter Rhythmus ist das, was einen Governance-Datensatz von einem veralteten Dokument unterscheidet.
• Shadow AI durch aktive Erkennung finden. Identifizieren Sie Verbindungen zu bekannten KI-Inference-Endpoints und fügen Sie erkannte Assets mit einer expliziten Klassifizierung als ungesteuertes Risiko zur AIBOM hinzu.

Diese Praktiken machen aus Ihrer AIBOM ein lebendiges Verzeichnis statt eines Audit-Artefakts. Ihre Umsetzung im Cloud-Maßstab erfordert Tooling, und hier kommt SentinelOne's AI Security Posture Management ins Spiel.

AIBOM-Governance mit SentinelOne verbessern

Eine AIBOM ist nur so gut wie die Erkennung, die sie speist. Singularity Cloud Security, SentinelOne's Cloud-Native Application Protection Platform, erstellt und pflegt über seine Funktion AI Security Posture Management (AI-SPM) eine AIBOM über Cloud-Umgebungen hinweg, mit integriertem Data Security Posture Management (DSPM) für die Datenschicht.

• Erkennung, die das Inventar befüllt. AI-SPM findet die KI-Pipelines, ML-Modelle und Abhängigkeiten, die in Ihrer Umgebung laufen, einschließlich Jobs auf Services wie Amazon SageMaker. Da sowohl genehmigte als auch Shadow AI abgedeckt werden, wird jede aufgelistete Komponente zu einem potenziellen AIBOM-Eintrag ohne stillen blinden Fleck.
• Risikokontext auf Basis des Datensatzes. Konfigurationsprüfungen und Verified Exploit Paths zeigen, welche katalogisierten Komponenten fehlkonfiguriert oder ausnutzbar sind, und DSPM hält Hochrisikodaten durch ein Safe-to-Train-Gate aus KI-Pipelines heraus. Prompt Security prüft Prompts und Antworten und steuert agentische KI, wodurch sich Ihre AIBOM-Governance auf die Runtime-Ebene erweitert.
• Validierung über die gesamte Plattform hinweg. Die Singularity Platform vereinheitlicht Endpoint-, Cloud- und Identity-Telemetrie in einem Data Lake, sodass Sie bestätigen können, dass die bereitgestellte Umgebung weiterhin Ihrer AIBOM entspricht. Wenn sie abweicht, greift Purple AI ein, ein Natural-Language-Analyst, der autonom über dieselben Daten hinweg untersucht. According to IDC verzeichneten Purple AI-Kunden eine um 63 % schnellere Bedrohungsidentifizierung und eine um 55 % reduzierte Mean Time to Respond (MTTR). 

Buchen Sie eine SentinelOne-Demo, um Ihr Risiko in der KI-Lieferkette zu bewerten und ein belastbares KI-Governance-Programm über Ihre Cloud-Umgebungen hinweg aufzubauen.

Wichtigste Erkenntnisse

Eine AIBOM inventarisiert die Datensätze, Modelle, Frameworks und Abhängigkeiten hinter einem KI-System und dokumentiert, woher jede Komponente stammt. Sie erweitert die etablierte SBOM-Praxis auf KI-spezifische Assets wie Trainingsdaten, Modellgewichte und Modellherkunft. 

Standards von NIST, OWASP CycloneDX, SPDX und den G7 definieren, was eine AIBOM erfasst. Das Inventar ist wichtig für Sicherheit, Compliance und Auditierbarkeit, erfordert jedoch autonome Erkennung, maschinenlesbare Formate, Herkunftserfassung und CI/CD-Integration, um bei Modelländerungen korrekt zu bleiben. Richtig umgesetzt ist die AIBOM keine Formalität mehr, sondern eine Kontrolle, auf deren Basis Sie handeln können.

FAQs

Was ist ein AI Bill of Materials?

Eine KI-Stückliste oder AIBOM ist ein maschinenlesbares Verzeichnis der Komponenten eines KI-Systems: seiner Datensätze, Modelle, Frameworks, Softwareabhängigkeiten und Metadaten wie Herkunft und Lizenzen. Ihr Zweck ist operativ.

Wenn festgestellt wird, dass ein Modell kompromittiert ist, oder nachgewiesen wird, dass ein Datensatz vergiftet wurde, ermöglicht Ihnen das AIBOM, anhand von Belegen zu beantworten, welche Ihrer Systeme diese Komponente enthalten und wann sie in diese gelangt ist. Ohne sie wird diese Antwort zu einem Rekonstruktionsaufwand unter Zeitdruck.

Kann man ein AIBOM für ein geschlossenes oder ein Drittanbieter-Modell erstellen?

Teilweise. Bei einem geschlossenen Foundation-Modell, das über eine Inference-API erreicht wird, können Sie die vollständige interne Zusammensetzung nicht erfassen, da der Anbieter seine Trainingsdaten oder Gewichte nicht offenlegt. Sie können dennoch erfassen und festhalten, was bekannt sein kann: Modellname, Version, API-Endpunkt, Zugriffskontrollen und etwaige Bestätigungen des Anbieters. 

Erfassen Sie diese als erstklassigen AIBOM-Eintrag und kennzeichnen Sie die nicht offengelegten Felder ausdrücklich, damit das Inventar zeigt, wo die Transparenz endet, und keine stillen Lücken offenlässt.

Was sollte ein AIBOM enthalten?

Die Leitlinien vom Mai 2026 der G7 gliedern den AIBOM-Inhalt in sieben Cluster: Metadaten, Softwareeigenschaften auf Systemebene, Modellidentität und Herkunft der Gewichte, Datensatzeigenschaften, zentrale Leistungsindikatoren, Infrastrukturdokumentation und Dokumentstruktur mit Aufzeichnungen zur Aktualisierungsfrequenz. 

Zusammen dokumentieren diese Cluster, wie ein KI-System erstellt wurde, worauf es ausgeführt wird und wie sich das Inventar über den gesamten Lebenszyklus hinweg verändert.

Welche Standards gelten für AIBOMs?

Vier Standards und Frameworks bilden die Grundlage der aktuellen AIBOM-Praxis. Das NIST AI Risk Management Framework legt Erwartungen an Governance und Rückverfolgbarkeit fest. OWASP CycloneDX ML-BOM und SPDX 3.0 AI profiles, ein ISO/IEC-Standard, stellen maschinenlesbare Formatspezifikationen für Modelle und Datensätze bereit. 

Die SBOM-Mindestelemente von CISA und die Sieben-Cluster-Leitlinien der G7 definieren, was die Transparenz von KI-Systemen erfassen sollte. Zusammen erweitern sie etablierte SBOM-Ansätze auf KI-Inventarmodelle.

Wie hält man ein AIBOM aktuell, wenn sich Modelle ändern?

Behandeln Sie die AIBOM als ein ereignisgesteuertes Verzeichnis, das an Ihre ML-Pipeline gebunden ist. Lösen Sie Aktualisierungen bei der Erstellung von Modelltrainingsartefakten, Registry-Push-Ereignissen, Retraining, Fine-Tuning und Änderungen der Bereitstellungskonfiguration aus. Vergleichen Sie Hashes bereitgestellter Modelle mit den erfassten Hashes und warnen Sie bei neuen Inferenzendpunkten oder Registry-Einträgen ohne entsprechenden AIBOM-Eintrag.

AI security posture management-Tools können diese Prüfungen kontinuierlich ausführen und Abweichungen kennzeichnen, sobald sie auftreten. Wenn die Generierung ein erforderlicher CI/CD-Schritt ist, verhindern veraltete Verzeichnisse die Promotion, bevor ein nicht verwaltetes Modell die Produktion erreicht.