Eine AI-Stückliste ist nur dann nützlich, wenn sie zwei Fragen beantworten kann: Was wurde vor dem Deployment deklariert, und was lief tatsächlich, als eine Entscheidung, ein Vorfall oder ein Audit stattfand? Eine gültige JSON-Datei, die beides nicht beantworten kann, ist Inventartheater.
Das praktische Design ist ein gekoppeltes Inventar. Erzeuge während des Builds oder der Beschaffung einen standardbasierten Datensatz, beobachte das Live-System zur Laufzeit, bewahre für jedes Feld Belege auf und vergleiche beide Datensätze. Blockiere ein Release, wenn ein kritisches Modell, ein Datensatz, eine Laufzeitumgebung, eine API, ein Agent-Tool oder eine Lizenz ungelöst ist.
Leserlevel: Fortgeschritten. Dieser Leitfaden richtet sich an Engineers, Sicherheitsteams, Plattformverantwortliche und technische Governance-Leads, die modellgestützte Systeme betreiben.
Inhalt
Welche Fragen eine AI-Stückliste beantworten sollte
Eine AI-Stückliste, meist als AIBOM oder AI BOM abgekürzt, ist ein maschinenlesbares Inventar der Komponenten und Belege hinter einem AI-System. Sie erweitert eine herkömmliche Software-Stückliste über Packages und Bibliotheken hinaus.
Das Inventar sollte es einem Prüfer ermöglichen, folgende Fragen zu beantworten:
CycloneDX beschreibt seine AI/ML-BOM-Funktionalität als Möglichkeit, Modelle, Datensätze, Konfigurationen, Provenienz und Abhängigkeiten darzustellen. SPDX 3.0.1 definiert ebenfalls ein AI-Profil für AI-spezifische Metadaten. Dies sind interoperable Datenmodelle, aber kein Ersatz für die fehlenden Belege selbst.
Eine Model Card beantwortet eine engere Frage: Was soll dieses Modell tun, wie wurde es evaluiert und wo kann es versagen? Das ursprüngliche Model-Cards-Paper schlug eine Dokumentation vor, die bestimmungsgemäße Verwendung, Evaluierungsbedingungen und Leistung in relevanten Gruppen abdeckt. Eine Data Card dokumentiert die Herkunft, Erhebung und Annotation eines Datensatzes, seine bestimmungsgemäße Verwendung sowie Entscheidungen, die die nachgelagerte Leistung beeinflussen; das Data-Cards-Paper berichtet über Erkenntnisse aus mehr als 20 Deployments.
Behalte beide. Eine Model Card oder Data Card liefert menschlichen Kontext. Eine AIBOM verknüpft diese Dokumente mit einem versionierten Systeminventar.
Warum gültige AIBOM-Dateien dennoch schwache Belege enthalten können
Eine Studie vom Juli 2026 untersuchte diese Unterscheidung in großem Maßstab. Die Autoren sammelten einen Snapshot von 2.942.466 öffentlichen Hugging-Face-Modelldatensätzen, behielten 97.940 Modelle mit mehr als 100 Downloads und erzeugten mit dem OWASP AIBOM Generator CycloneDX-AIBOMs. Sie prüften eine Stichprobe von 100 Artefakten anhand der Berichte des Generators und maßen anschließend das Vorhandensein von Feldern über den gesamten Datensatz.
Der berichtete durchschnittliche Vollständigkeitswert lag bei 54,31 von 100. Erforderliche Strukturfelder waren in 100 % der erzeugten Artefakte vorhanden. Die Dokumentation in Model Cards erreichte durchschnittlich 19,51 %.
Diese Lücke ist das wichtige Ergebnis. Die Datei kann strukturell gültig sein, während die für eine Entscheidung benötigten Informationen fehlen.
Die Ergebnisse auf Feldebene waren noch deutlicher:
| Feld in der erzeugten AIBOM | Vorhanden |
|---|---|
| --- | ---: |
| Lizenz | 73,14 % |
| Datensatz | 39,35 % |
| Hyperparameter | 25,40 % |
| Technische Einschränkungen | 16,74 % |
| Bewertung von Sicherheitsrisiken | 9,76 % |
| Aussagekräftige Beschreibung | 0,22 % |
| Energieverbrauch | 0,02 % |
Das Beschreibungsfeld war in fast jedem Artefakt vorhanden, aber nur 211 von 97.940 Beschreibungen enthielten Informationen über Platzhaltertext hinaus. Eine Prüfung auf das Vorhandensein des Schemas würde die übrigen Beschreibungen als vollständig zählen.
Was die Autoren gemessen haben: Abdeckung von Feldern und Kategorien in AIBOMs, die aus einem gefilterten öffentlichen Hugging-Face-Snapshot erzeugt wurden.
Was sie abgeleitet haben: Die Dokumentation in Model Cards und externen Referenzen erklärt einen großen Teil des Unterschieds zwischen schwachen und stärkeren Artefakten.
Was sie nicht festgestellt haben: Ob ein Modell sicher, fair, leistungsfähig, rechtlich nutzbar oder für ein bestimmtes Deployment geeignet war.
Die Autoren warnen außerdem, dass ihre Ergebnisse von der Hugging-Face-API, der Extraktionslogik des Generators und einem Snapshot abhängen, der Modelle mit 100 oder weniger Downloads ausschließt. Private Registries, geschützte Modelle, andere Hosting-Plattformen und spätere Änderungen an Repositories können anders aussehen. Das Ergebnis spricht für semantische Validierung. Es legt keinen universellen Schwellenwert fest.
Inventar zur Build-Zeit und Inventar zur Laufzeit lösen unterschiedliche Probleme
Eine AIBOM zur Build-Zeit dokumentiert die Absicht. Ein Inventar zur Laufzeit dokumentiert die Beobachtung.
| Frage | Belege zur Build-Zeit | Belege zur Laufzeit |
|---|---|---|
| --- | --- | --- |
| Welches Modell soll ausgeliefert werden? | Lockfile, Manifest, Beschaffungsdatensatz, Model-Digest | Geladene Model-ID, Endpoint, Image-Digest, Serving-Konfiguration |
| Welche Daten sollen verfügbar sein? | Deklarationen zu Training und Evaluierung, freigegebene Retrieval-Quellen | Verbundene Vector Stores, eingebundene Datensätze, Live-Datendienste |
| Welche Tools darf ein Agent aufrufen? | Tool-Registry, Richtlinie, deklarierte MCP-Server und APIs | Erkannte Endpoints, aktive Integrationen, beobachtete Konfiguration |
| Welche Software unterstützt die Inferenz? | Package- und Container-SBOM | Laufendes Image, Laufzeitumgebung, Treiber, Beschleuniger |
| Welche Einschränkungen gelten? | Lizenz, Model Card, Data Card, Vertragsreferenz | Aktueller Anbieter, Region, Route, Richtlinienversion |
| Ist das freigegebene System abgewichen? | Baseline zum Vergleich | Belege für den Vergleich mit der Baseline |
Belege zur Build-Zeit allein übersehen Notfalländerungen, Shadow Deployments, veränderliche Tags, Provider-Umleitungen und Konfigurationsabweichungen. Beobachtungen zur Laufzeit können allein einen Prozessnamen oder Endpoint erkennen, ohne dessen freigegebenen Zweck, Lizenz, Trainingsprovenienz oder Evaluierungsgrenze zu kennen.
Google hat am 14. Juli 2026 k8s-aibom als Open Source veröffentlicht, um die Laufzeitseite zu untersuchen. Der Controller überwacht den Zustand von Kubernetes-Workloads und Pods, wendet Erkennungsregeln an und erzeugt CycloneDX-1.6-ML-BOM-Dokumente. Die dokumentierte Abdeckung umfasst Inferenz-Laufzeitumgebungen, Agent-Frameworks, Vector Databases, Trainingsjobs und Evaluierungsharnesses. Er läuft ohne privilegiertes DaemonSet oder Kernelzugriff.
Das Projekt verdeutlicht einen wichtigen Architekturpunkt: AIBOMs zur Build-Zeit und zur Laufzeit ergänzen sich. Es handelt sich jedoch um frühe Software. Das Repository kennzeichnet v1.0 als Alpha und als geeignet für nicht kritische Beobachtungsszenarien. Es liefert weder ein gehostetes Image noch ein Helm-Repository, und sein aktueller `NoopVerifier` kann eine Identität nicht als kryptografisch verifiziert markieren.
Ein Maintainer von NVIDIA AICR schlug eine Integration von k8s-aibom und AICR vor, die die Laufzeitbeobachtungen von k8s-aibom mit der Deployment-Absicht und signierten Attestierungen von AICR verbinden würde. Der Autor beschreibt das Ziel als einen Nachweis dafür, dass das, was ein Team deployed hat, auch tatsächlich vom System ausgeführt wird. Das Issue enthält keine verknüpfte Implementierung, keinen Verantwortlichen und keinen Meilenstein. Behandle es als Vorschlag aus der Praxis, nicht als offizielle Roadmap oder abgeschlossene Konzeption.
Mache aus einem neuen Controller keine universelle Produktempfehlung. Verwende das Muster: Deklarierten Zustand mit beobachtetem Zustand koppeln, Belege aufbewahren und Unsicherheit sichtbar machen.
_Eine nützliche AI-Stückliste verbindet die Build-Absicht mit Laufzeitbelegen, semantischen Prüfungen und einer versionierten Entscheidung._
Die sieben erfassenswerten Ebenen
Das genaue Schema hängt von deinem Standard und Deployment ab. Die folgenden Ebenen bilden ein praxisnahes Minimum für ein Produktionsinventar.
1. Modellidentität
Erfasse Anbieter, Modellfamilie, unveränderliche Revision oder Digest, Format, Basismodell, Adapter, Quantisierung, Tokenizer und Serving-Route. Ein benutzerfreundlicher Alias wie `support-model` ist für Menschen nützlich, reicht für die Nachverfolgbarkeit aber nicht aus.
Bei einer externen API solltest du die stabile Modellkennung des Anbieters und die Gateway-Route erfassen, die sie ausgewählt hat. Wenn der Anbieter das Modell hinter einem Alias stillschweigend aktualisieren kann, kennzeichne die Revision als ungelöst, statt eine Genauigkeit zu erfinden.
2. Daten- und Retrieval-Abhängigkeiten
Erfasse deklarierte Trainings-, Fine-Tuning-, Evaluierungs- und Kalibrierungsdatensätze, sofern diese Informationen vorhanden sind. Ergänze bei einem RAG-System die Quellsammlungen, das Embedding-Modell, die Chunking-Version, den Vector-Store-Dienst, die Zugriffsrichtlinie und die Aktualitätsgrenze.
Speichere Datensatzkennungen, Versionen, Hashes, Verträge oder kontrollierte Katalogreferenzen. Kopiere keine Rohdaten von Kunden oder privaten Trainingsbeispiele in die AIBOM.
Wenn ein Team benutzerdefinierte Datensysteme mit Next.js und AI-Agenten entwickelt→, gehören die Schemaversion, die Migrationsgrenze und die verbundenen Dienste in den Systemkontext, selbst wenn sie keine Modellartefakte sind.
3. Laufzeit und Software
Verknüpfe das AI-Inventar mit der gewöhnlichen SBOM. Erfasse den Container-Digest, die Inference Engine, das Framework, relevante Bibliotheken, die Treiber- und Beschleunigerklasse sowie Konfigurationen, die das Modellverhalten verändern können.
Das ist wichtig, weil sich dieselben Gewichte nach einer Änderung an Tokenizer, Attention-Backend, Quantisierungspfad oder Serving Engine unterschiedlich verhalten können. Die Analyse dazu, warum mehr AI-Tokens die Compute-Rechnung verändern→, zeigt, warum ein Deployment-Datensatz das Laufzeitbudget und die Konfiguration benötigt und nicht nur einen Modellnamen.
4. Tools, APIs und Agent-Berechtigungen
Liste die Tools auf, die ein Agent erreichen kann, nicht jedes Tool, das irgendwo im Unternehmen installiert ist. Füge Model Gateways, MCP-Server, Browser- oder Code-Execution-Tools, externe APIs und die Richtlinienreferenz hinzu, die jede Aktion regelt.
Ein Inventar erzwingt keine Autorisierung. Kombiniere es mit deterministischen Kontrollen. Der Artikel über AI-Agent-Berechtigungen→ erklärt, warum die Selbstbeschränkung eines Modells keine Zugriffskontrollgrenze darstellt.
5. Evaluierung und Betriebsgrenzen
Verweise auf den exakten Evaluierungsdatensatz, die Evaluator-Version, Schwellenwerte, das Datum und die Bedingungen, die für die Freigabe verwendet wurden. Erfasse bekannte Fehlermuster, vorgesehene und ausgeschlossene Verwendungen, Fallback-Verhalten, Monitoring-Verantwortliche und das Ablaufdatum der Entscheidung.
Schreibe nicht einfach „Evaluierung bestanden“, ohne die Testidentität anzugeben. Ein geändertes Modell mit einer unveränderten Ergebniszeichenfolge ist ein schwacher Beleg.
6. Rechte, Richtlinien und Provenienz
Erfasse Modell- und Datensatzlizenzen, Nutzungsbeschränkungen, Bedingungen für die Weiterverteilung, Quell-Repositories, Model Cards, Data Cards, Papers, Freigaben und Attestierungen. Speichere Referenzen und Hashes, wenn die Quelle zugriffsbeschränkt ist.
Diese Ebene unterstützt die Prüfung. Sie entscheidet keine Rechtsfrage. Fehlende oder widersprüchliche Informationen zu Rechten sollten an die für diese Entscheidung verantwortliche Person weitergeleitet werden.
7. Verantwortlichkeit und Lebenszyklus
Jeder Datensatz benötigt einen Verantwortlichen, Systemzweck, eine Umgebung, Erstellungszeit, Beobachtungszeit, abgelöste Version und Aufbewahrungsregel. Ohne Verantwortlichkeit wird ein Inventar zu einem Archiv verlassener Fakten.
Füge eine stabile System-ID hinzu, die Redeployments übersteht. Eine versionierte AIBOM sollte die Historie der Änderungen zeigen, wer sie akzeptiert hat und welche Belege diese Entscheidung stützten.
Kennzeichne jede Tatsache als deklariert, abgeleitet, verifiziert oder ungelöst
Eine AIBOM sollte den Belegstatus auf Feldebene führen. Ein einziges Label für das gesamte Dokument verbirgt zu viel.
Die ersten drei Labels beschreiben unterschiedliche Belegstärken. „Deklariert“ ist keine schwächere Schreibweise von „verifiziert“. Eine Anbieterangabe kann die einzige verfügbare Quelle für Trainingsdaten sein, während ein Image-Digest mechanisch verifiziert werden kann.
Das k8s-aibom-Projekt implementiert derzeit `declared`, `inferred` und `unresolved`, einschließlich Beleg-Locators für Attribute. In der README wird der kryptografische Status `verified` als zukünftige Funktion beschrieben, nicht als bereits vorhandene. Bewahre diese Ehrlichkeit auch in deinem eigenen System.
Ein konzeptioneller Datensatz könnte so aussehen:
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
Dies ist ein Designentwurf, kein konformes CycloneDX- oder SPDX-Dokument. Verwende für das echte Artefakt das Schema und den Validator des gewählten Standards.
Ein reproduzierbarer AIBOM-Workflow
Schritt 1: Definiere die Systemgrenze
Benenne die Anwendung, Umgebungen, Verantwortlichen und nutzerseitigen Entscheidungen, die im Umfang liegen. Entscheide, ob das Inventar einen einzelnen Modell-Endpoint, einen Agent-Workflow oder ein vollständiges Produkt abdeckt.
Eine Grenze wie „alles AI“ kann nicht getestet werden. „Der Produktions-Support-Agent und jeder Dienst, der seine Antworten oder Aktionen verändern kann“ dagegen schon.
Schritt 2: Sammle Build- und Beschaffungsbelege
Erzeuge die gewöhnliche SBOM, löse Modell- und Datensatzkennungen auf, erfasse unveränderliche Digests und verknüpfe Model Cards, Data Cards, Lizenzen, Evaluierungen und Freigaben.
Der OWASP AIBOM Generator kann Hugging-Face-Metadaten in CycloneDX 1.6 extrahieren und fehlende Felder melden. Behandle seine Ausgabe als Ausgangsinventar. Die groß angelegte Studie zeigt, warum ein automatisch befülltes Feld weiterhin einer Inhaltsprüfung bedarf.
Schritt 3: Erzeuge ein Standarddokument
Wähle ein Format, das deine Abnehmer verarbeiten können. CycloneDX bietet eine AI/ML-BOM-Funktionalität und einen Implementierungsleitfaden. SPDX 3 bietet AI und Dataset-Profile.
Die Formatwahl sollte sich nach den empfangenden Systemen, der Policy Engine, der Attestierungspipeline und den Kundenanforderungen richten. Vermeide die Pflege zweier Formate, sofern nicht tatsächlich ein Abnehmer beide benötigt.
Schritt 4: Ergänze, was Automation nicht wissen kann
Beauftrage Verantwortliche damit, bestimmungsgemäße Verwendung, Einschränkungen, Datensatzprovenienz, Evaluierungsbedingungen, Rechte und Risikoentscheidungen zu ergänzen. Lehne Platzhalter wie „N/A“, „Standardmodell“ oder kopierten Marketingtext ab, wenn das Feld entscheidungsrelevant ist.
Verlange einen ausdrücklichen Grund für unbekannte Werte. „Der Anbieter legt die Trainingsdaten nicht offen“ ist ein besserer Beleg als ein leeres Array, weil dadurch zwischen fehlender Arbeit und nicht verfügbarer Information unterschieden wird.
Schritt 5: Beobachte das Live-Deployment
Sammle Modell-IDs zur Laufzeit, Image-Digests, Endpoints, verbundene Stores, Agent-Tools und Konfigurationen über den am wenigsten privilegierten verfügbaren Mechanismus. In Kubernetes kann das ein Controller sein, der die API überwacht. In einem verwalteten API-Stack können es Gateway-Konfiguration, Deployment-Manifeste, Provider-Antworten und Audit-Logs sein.
Behaupte keine Laufzeitverifizierung, wenn der Scanner lediglich eine Zeichenfolge abgeglichen hat. Kennzeichne den Wert als abgeleitet und bewahre den Abgleichsbeleg auf.
Schritt 6: Validiere Syntax, Semantik und Abweichungen
Führe drei getrennte Prüfungen durch:
Die erste Prüfung ist automatisiert. Die zweite benötigt Domänenregeln und bei manchen Feldern eine menschliche Prüfung. Die dritte benötigt versionierte Datensätze und eine stabile Vergleichsgrenze.
Schritt 7: Signiere, speichere, vergleiche und lasse ablaufen
Hash das Artefakt, binde es an den Build oder das Deployment, speichere es in einem unveränderlichen oder kontrollierten Belegsystem und erstelle einen für Menschen lesbaren Diff. AIBoMGen ist ein Forschungsprototyp, der die Erfassung von Modell und Umgebung mit Hashes, Signaturen und in-toto-Attestierungen während des Trainings kombiniert.
Signaturen schützen die Integrität nach der Erstellung. Sie machen eine unvollständige oder falsche Deklaration nicht wahr.
Lege ein Ablauf- oder Prüfdatum fest. Ein perfektes Inventar vom letzten Quartal beschreibt heute kein veränderliches Produktionssystem.
Mache das Inventar zu einem Release-Gate
Ein Inventar wird nützlich, wenn es eine Entscheidung verändert. Definiere die Richtlinie vor dem Release-Fenster.
| Bedingung | Standardaktion | Grund |
|---|---|---|
| --- | --- | --- |
| Identität eines kritischen Modells oder einer kritischen Laufzeitumgebung ist ungelöst | Blockieren | Die eingesetzte Komponente kann nicht zurückverfolgt werden |
| Die Laufzeit enthält ein nicht deklariertes Modell, eine API, ein Tool oder einen Datenspeicher | Blockieren und untersuchen | Die freigegebene Grenze ist abgewichen |
| Die Modellrevision hat sich geändert, die Evaluierungsreferenz jedoch nicht | Blockieren | Die Freigabebelege decken den Kandidaten nicht ab |
| Erforderliche Lizenz oder Nutzungsbeschränkung fehlt | An verantwortliche Prüfung weiterleiten; blockieren, wenn die Richtlinie dies verlangt | Rechte können nicht aus der Verfügbarkeit abgeleitet werden |
| Heuristische Ableitung widerspricht einer Deklaration | Beleg blockieren oder unter Quarantäne stellen | Mindestens eine Quelle ist falsch oder veraltet |
| Eine nicht kritische Beschreibung ist nicht detailliert genug | Zeitlich begrenzte Behebung anlegen | Die Lücke rechtfertigt möglicherweise keinen Servicestopp |
| Die AIBOM hat sich nur geändert, weil sich die Beobachtungszeit geändert hat | Zulassen | Es ist keine wesentliche Systemabweichung aufgetreten |
Passe den Schweregrad an das System an. Ein Schreibassistent und ein medizinisches Entscheidungstool sollten nicht denselben universellen Schwellenwert verwenden.
Verfolge vier operative Kennzahlen:
Optimiere nicht auf die Anzahl ausgefüllter Felder. Damit würdest du genau den Fehler wiederholen, den die Vollständigkeitsstudie offengelegt hat.
Dasselbe Systemprinzip zeigt sich in der Analyse von Aktivität von Code-Agenten und Infrastruktur→: Modellfähigkeit ist nur ein Teil des eingesetzten Systems. Laufzeit, Tools, Routing und operative Kontrollen bestimmen, was Nutzer tatsächlich erhalten.
Halte Secrets und personenbezogene Daten heraus
Eine AIBOM wird wahrscheinlich zwischen Engineering, Sicherheit, Auditoren, Kunden und automatisierten Systemen zirkulieren. Behandle sie als Inventar, nicht als Secret Store.
Füge Folgendes nicht ein:
Verweise auf Secrets über den Pfad im Secret Manager oder eine logische Kennung, ohne den Wert einzuschließen. Verweise auf sensible Datensätze über eine verwaltete Katalog-ID, Version, Klassifizierung, Verantwortlichen und Integritäts-Hash. Wende Zugriffskontrollen auf das vollständige Artefakt an, wenn bereits seine Metadaten sensibel sind.
Was eine AIBOM nicht beweisen kann
Eine AI-Stückliste verbessert die Nachverfolgbarkeit. Sie beweist nicht:
Die Vollständigkeitsstudie vom Juli misst die Dokumentationsabdeckung, nicht die Modellqualität. Das k8s-aibom-Repository erklärt ausdrücklich, dass seine Ausgabe keine Compliance zertifiziert. Beide Einschränkungen sind wichtig.
Verwende die AIBOM als Karte von einer Entscheidung zu überprüfbaren Belegen. Kombiniere sie mit Evaluierung, Autorisierung, Monitoring, Incident Response, Datenschutzkontrollen und verantwortlicher Prüfung. Die Karte beschleunigt diese Prozesse, weil sie jedem Prüfer zeigt, welches System er bewertet.
Häufig gestellte Fragen
Was ist eine AI-Stückliste?
Eine AI-Stückliste ist ein maschinenlesbares Inventar der Modelle, Datensätze, Software, Laufzeitumgebungen, Tools, Provenienz, Einschränkungen und Belege hinter einem AI-System. Eine nützliche AIBOM identifiziert unveränderliche Versionen, Verantwortliche, ungelöste Fakten und Änderungen zwischen freigegebenem und Live-Zustand.
Ist eine AI BOM dasselbe wie eine SBOM?
Nein. Eine SBOM inventarisiert Softwarekomponenten und Abhängigkeiten. Eine AI BOM verbindet dieses Softwareinventar mit AI-spezifischen Komponenten wie Modellen, Datensätzen, Adaptern, Evaluierungen, bestimmungsgemäßen Verwendungen, Einschränkungen und Laufzeit-Routen. Ein Produktions-AI-System benötigt normalerweise beides.
Sollte ich CycloneDX oder SPDX für eine AIBOM verwenden?
Verwende das Format, das deine nachgelagerten Tools und Belegkonsumenten unterstützen. CycloneDX verfügt über eine dokumentierte AI/ML-BOM-Funktionalität; SPDX 3 bietet AI- und Dataset-Profile. Validiere zunächst ein kanonisches Format. Füge ein zweites nur hinzu, wenn eine Richtlinie, ein Kunde oder eine Integration dies erfordert.