Schatten-KI Entwicklungsprozess Das AI-BOM macht Modelle und Agenten sichtbar

Von Thomas Joos 6 min Lesedauer

Anbieter zum Thema

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.(Bild: ©  SVasco - stock.adobe.com)
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.
(Bild: © SVasco - stock.adobe.com)

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.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu RZ- und Server-Technik

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung

Behörden und Regulierer fordern Mindestangaben

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.

Discovery reicht vom Code bis in die Cloud

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.

Das Inventar liefert den Nachweis für Audits

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.

(ID:50968793)