Entwickler bringen KI-Modelle, MCP-Tools und autonome Agenten in den Betrieb, oft ohne Wissen der Security-Teams. Ein AI Bill of Materials erfasst den Bestand über alle Clouds, ordnet jeder Komponente Verantwortlichen zu und weist ihn für Audits nach.
Ein AI Bill of Materials wendet das Prinzip der Software-Stückliste auf KI-Systeme an und schafft so eine Sichtbarkeit für Modelle, Trainingsdaten, Agenten, Werkzeuge und Abhängigkeiten.
Der Druck auf ein belastbares KI-Inventar wächst von zwei Seiten. Die US-Cybersicherheitsbehörde CISA und ihre G7-Partnerbehörden veröffentlichten am 12.05 2026 die Leitlinie „Software Bill of Materials for AI – Minimum Elements“, die erste behördliche Vorgabe für die Mindestangaben eines AI-BOM.
Auf Seiten der Standardisierung bietet „Owasp CycloneDX“ ein maschinenlesbares Format für Machine-Learning-Komponenten. Parallel dazu verlangt der EU AI Act in Anhang IV eine technische Dokumentation für Hochrisiko-Systeme, deren Inhalte sich mit einem AI-BOM in weiten Teilen abdecken lassen. Ein AI Bill of Materials, kurz AI-BOM, wendet das Prinzip der Software-Stückliste (SBOM) auf KI-Systeme an und verzeichnet Modelle, Trainingsdaten, Agenten, Werkzeuge und Abhängigkeiten als strukturiertes Inventar.
Schatten-KI wächst im Entwicklungsprozess
Der Bestand, den ein solches Inventar verzeichnen soll, verändert sich derzeit schneller als jede manuelle Dokumentation. Entwickler laden Modelle von Plattformen, zum Beispiel von „Hugging Face“, binden Server nach dem Model Context Protocol (MCP) als Werkzeugschnittstellen an und statten Coding-Agenten mit Skills aus, also mit Textdateien, die dem Agenten Arbeitsanweisungen geben.
KI-gestützte Programmierung erhöht die Menge des ausgelieferten Codes, und auch Mitarbeiter ohne Entwicklerrolle schreiben inzwischen Anwendungen. Oron Noah, Vice President of Product Extensibility und Partnerships bei Wiz, sieht nach eigenen Angaben in über 70 Prozent der Kundenumgebungen einen Fußabdruck aus Agenten, MCP-Servern und zugehörigen Tools. Im Gespräch benennt Noah das Kernproblem: „Kunden tun sich schwer, überhaupt zu verstehen, wie viele KI-Komponenten in ihrer Umgebung laufen. Es wird enorm viel neuer Code in Produktion ausgeliefert, doch die Security-Teams wachsen nicht in diesem Tempo mit.“
Die Kosten dieser Sichtbarkeitslücke lassen sich beziffern. Der IBM-Report „Cost of a Data Breach 2025“ weist für Organisationen mit hoher Schatten-KI-Nutzung im Schnitt 670.000 Dollar zusätzliche Kosten pro Datenpanne aus, und 63 Prozent der untersuchten Unternehmen arbeiten ohne fertige Governance-Richtlinie für KI.
Die Zahlen belegen, dass unkontrollierte KI-Nutzung die Schadenshöhe von Sicherheitsvorfällen unmittelbar erhöht und damit weit über ein Compliance-Randthema hinausreicht. Riskant sind dabei weniger die offiziell eingekauften KI-Dienste als die Komponenten aus dem Entwicklungsprozess.
Manipulierte Skill-Dateien haben in dokumentierten Fällen Agenten dazu gebracht, Kontakt zu Command-and-Control-Servern aufzunehmen, und in Software eingebettete Modelldateien im Pickle-Format führen beim Deserialisieren beliebigen Code aus. Browserbasierte Agenten und SaaS-KI erscheinen zudem in keiner Verwaltungskonsole der Cloud-Provider. Reine Cloud-Scans greifen deshalb zu kurz.
Offene Standards strukturieren das KI-Inventar
Für das Format des Inventars stehen zwei offene Standards bereit. Owasp CycloneDX führt Machine-Learning-Modelle als eigenen Komponententyp und dokumentiert sie über ein Model-Card-Objekt mit Trainingsansatz, verwendeten Datensätzen, Leistungsmetriken und Lizenzangaben. Die aktuelle Spezifikationsversion 1.7 vom 21.10 2025, als Ecma-424 international normiert, ergänzt strukturierte Citations, mit denen sich die Herkunft jeder Angabe im BOM belegen lässt, ein Baustein für Audit-Trails.
Über den Objekttyp der Services beschreibt CycloneDX zudem extern konsumierte KI, also Modelle, die eine Anwendung per API anspricht, ohne sie selbst zu hosten. Der zweite Standard, Spdx 3.0 der Linux Foundation, definiert ein eigenes AI-Profil sowie ein Datensatz-Profil und zielt stärker auf Lizenz- und Compliance-Angaben. Ergänzend arbeitet das 2025 gestartete Owasp-Projekt „AIBOM“ an Leitfäden, Referenzwerkzeugen und einem Schema, das mit beiden Formaten interoperabel bleibt. Kommerzielle Plattformen von Anbietern, darunter Cisco, Endor Labs, Nudge Security, Palo Alto Networks und Wiz, setzen auf diesen Standards auf, sie ersetzen sie nicht.
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
Die G7-Leitlinie legt den inhaltlichen Rahmen für ein AI-BOM fest. Sie gliedert die Mindestangaben in sieben Cluster, von Metadaten über Systemeigenschaften, Modelle, Datensatzeigenschaften und Infrastruktur bis zu Sicherheitseigenschaften und Leistungskennzahlen.
Die Cluster decken unter anderem Modellversionen und Herkunft, Trainings- und Testdaten, benötigte physische und virtuelle Infrastruktur sowie implementierte Schutzmaßnahmen ab. Die Vorgabe ist freiwillig und versteht sich als Ergänzung zu den allgemeinen SBOM-Mindestelementen. In Beschaffung und Lieferantenbewertung dient sie dennoch als Referenzpunkt, denn Einkäufer leiten daraus konkrete Fragen zu Modellherkunft und Datenbasis ab.
Der regulatorische Rahmen in Europa verstärkt diese Entwicklung. Der ursprüngliche Zeitplan des EU AI Act nennt für eigenständige Hochrisiko-Systeme nach Anhang III den Stichtag 02.08 2026. Mit der vorläufigen Einigung zum Digital Omnibus vom 07.05 2026 verschiebt sich dieser Termin voraussichtlich auf den 02.12 2027, für in Produkte eingebettete KI nach Anhang I auf den 02.08.2028.
An den inhaltlichen Pflichten ändert der Omnibus nichts, die technische Dokumentation nach Anhang IV mit Angaben zu Architektur, Trainingsdaten, Metriken und Risikomanagement bleibt in vollem Umfang bestehen, und die Transparenzpflichten nach Artikel 50 gelten unverändert ab dem 02.08 2026.
Ein AI-BOM liefert genau die Rohdaten, die Auditoren dafür anfordern. In dieselbe Richtung weisen ISO/IEC 42001, die für ein KI-Managementsystem ein gepflegtes Bestandsverzeichnis voraussetzt, und das Nist AI RMF, dessen Map-Funktion die Erfassung aller KI-Systeme samt Kontext an den Anfang jedes Risikomanagements stellt. Beide Rahmenwerke stammen zwar nicht aus der EU, ihre Anforderungen lassen sich aber unmittelbar auf europäische Organisationen anwenden.
Der Praxiskern eines AI-BOM liegt in der automatisierten Erhebung, denn manuell gepflegte Verzeichnisse veralten binnen Wochen. Wirksame Discovery setzt deshalb auf mehreren Ebenen zugleich an.
Im Quellcode und in den Repositories erkennen Scanner Modell-Importe, Gewichtsdateien, Framework-Aufrufe und Skill-Definitionen und finden Schatten-KI so an ihrem Ursprung. Endor Labs verfolgt diesen Ansatz mit einer Modell-Discovery im Entwicklungsprozess. In der Build-Pipeline erzeugen in CI/CD integrierte Generatoren das AI-BOM bei jedem Build neu, das Inventar bleibt dadurch synchron zum ausgelieferten Stand. Cisco stellt dafür einen Open-Source-Scanner bereit, der MCP-Server, Modelle und Agenten aufspürt.
Auf der Kontroll- und Datenebene der Cloud zeigen die APIs der Provider verwaltete KI-Dienste, zusätzliche Disk-Scans finden selbst gehostete Modelle und eingebettete Modelldateien über mehrere Public Clouds hinweg. Wiz verknüpft die Funde in einem Security-Graph mit Berechtigungen, Datenzugriffen und Exponierung. Telemetrie aus Identitätsdiensten und Browser-Erweiterungen erkennt schließlich SaaS-KI und Agenten ohne Cloud-Präsenz. Nudge Security wertet dafür unter anderem OAuth-Freigaben und Browsersitzungen aus.
Auf die Erhebung folgt die Zuordnung. Jede Komponente im AI-BOM benötigt einen benannten Verantwortlichen, sonst bleiben Funde ohne Konsequenz. Noah formuliert die Reihenfolge so: „Alles beginnt mit Sichtbarkeit. Man kann nicht schützen, was man nicht sieht. Der erste Schritt ist ein vollständiges Verständnis des eigenen KI-Inventars, der zweite die Identifikation der Eigentümer, die diese Agenten und Anwendungen erstellt haben.“
Damit die Inventarisierung Entwickler nicht ausbremst, plädiert Noah dafür, die Prüfungen in deren Arbeitsumgebung zu verlagern. Richtlinien, die für die Cloud definiert sind, gelten dann bereits in der IDE und in Vibe-Coding-Plattformen, also in Diensten, die Anwendungen aus Sprachbefehlen erzeugen, bevor unsicherer Code die Produktivumgebung erreicht.
Wirksam wird ein AI-BOM erst in Verbindung mit den übrigen Sicherheitsprozessen. Ausdrücklich halten die G7-Behörden fest, dass die Stückliste allein die Lieferkette nicht absichert und deshalb an Schwachstellenmanagement, Advisories und Erkennungswerkzeuge angebunden gehört. Meldet ein Hersteller eine kompromittierte Modellversion, zeigt das Inventar in Minuten die betroffenen Anwendungen und den zuständigen Eigentümer für die Korrektur.
Für CISOs stärkt das Verzeichnis Assurance und Auditfähigkeit, da jede Angabe im BOM eine belegbare Antwort auf Prüferfragen nach Modellherkunft, Datenbasis und Schutzmaßnahmen darstellt. Aus einem aktuell gehaltenen AI-BOM lässt sich darüber hinaus ein lebendes Bedrohungsmodell ableiten, das sich mit jedem Build aktualisiert. Offen bleibt derzeit die Qualitätssicherung der Stücklisten selbst, denn ein Verfahren zur Signatur und Prüfung fremder AI-BOMs befindet sich in den Standardgremien noch in Arbeit.
Vom Schattenbestand zum steuerbaren Inventar
Ein AI-BOM macht Schatten-KI steuerbar. Die Formate von CycloneDX und Spdx sind produktionsreif, die G7-Leitlinie definiert seit Mai 2026 eine behördliche Baseline, und der EU AI Act verlangt für Hochrisiko-Systeme eine Dokumentation, die ein laufend aktualisiertes Inventar bereits weitgehend enthält. Organisationen, die die Erhebung vom Quellcode über die Pipeline bis in die Cloud automatisieren und jeder Komponente einen Verantwortlichen zuordnen, kennen ihren KI-Bestand, bevor Auditoren oder Angreifer ihn finden.