Was ist eine AI-BOM? Das KI-Inventar, das der EU AI Act bei Ihnen voraussetzt

Was ist eine AI-BOM?

Eine AI-BOM, oder AI Bill of Materials, ist ein maschinenlesbares Inventar aller Komponenten künstlicher Intelligenz, die ein Softwaresystem enthält, samt der Herkunfts- und Governance-Fakten zu jeder einzelnen. Wo eine SBOM Pakete, Versionen und Lizenzen auflistet, listet eine AI-BOM Modelle, Datensätze, Prompts, Agenten, Tools und Guardrails auf und hält fest, woher jedes stammt, was es tun darf und in welche regulatorische Risikoklasse es fällt.

Die Idee stammt direkt von der Software-Stückliste ab. Die US-Executive-Order 14028 machte SBOMs 2021 zur Bedingung für die Softwarebeschaffung des Bundes, und die Praxis überlebte die politischen Wechselfälle dieser Verordnung, weil sie sich als einzig praktikable Antwort auf „was läuft hier eigentlich“ erwies. KI-Systeme stellen dieselbe Frage auf einer breiteren Fläche. Eine Abhängigkeit hat eine Version und eine Lizenz. Ein Modell hat eine Version, eine Lizenz, einen Anbieter, Gewichte, die lokal oder entfernt liegen können, einen Trainingskorpus, den Sie womöglich nicht kontrollieren, eine Fine-Tuning-Historie, eine Inferenzkonfiguration, ein Evaluationsprotokoll und einen Fähigkeitsrahmen. Nichts davon passt in eine package.json.

AI-BOM und SBOM: worin liegt der Unterschied?

Sie beantworten unterschiedliche Fragen zum selben Repository, und der Unterschied ist nicht kosmetisch. Eine SBOM ist eine Liste von Dingen, die Sie installiert haben. Eine AI-BOM ist eine Liste von Dingen, die Entscheidungen treffen.

Die letzte Zeile ist der Punkt, an dem die meisten Werkzeuge aufhören. Eine Abhängigkeit deklariert sich in einem Lockfile. Ein Modell nicht. openai/gpt-4o-mini steht als String-Literal in einer Servicedatei. Ein lokales Modell steht als .gguf-Pfad in einer Konfiguration. Ein MCP-Server steht als URL in .mcp.json. Ein Prompt steht als Markdown-Datei da, die niemand irgendwo registriert hat. Es gibt kein Manifest zum Parsen, also muss ein KI-Inventar durch Lesen des Codes selbst abgeleitet werden.

Was verlangt der EU AI Act tatsächlich?

Artikel 11 verpflichtet Anbieter von Hochrisiko-KI-Systemen, die technische Dokumentation vor dem Inverkehrbringen oder der Inbetriebnahme zu erstellen und aktuell zu halten. Anhang IV legt den Mindestinhalt fest. Artikel 18 verpflichtet den Anbieter, diese Dokumentation zusammen mit den Aufzeichnungen des Qualitätsmanagementsystems und der EU-Konformitätserklärung zehn Jahre nach dem Inverkehrbringen aufzubewahren.

Lesen Sie Anhang IV als Fragebogen, und seine Form wird offensichtlich. Es sind neun Abschnitte, und die meisten davon fragen danach, woraus das System besteht und woher diese Teile stammen.

Punkt für Punkt ist die Entsprechung eng genug, dass die Dokumentationsaufgabe für den größten Teil des Pakets zu einem Exportproblem wird, und für den Rest zu echter Analysearbeit.

Zwei Abschnitte in dieser Tabelle sind als nicht nativ von einem Stücklistenformat abgedeckt markiert, und es sind genau die beiden, die in der Praxis die meiste Auditzeit verschlingen: Genauigkeit nach Subgruppe (§3) und das Design der menschlichen Aufsicht (§2(e)). Kein BOM-Standard hat ein Feld für „wer kann diese Entscheidung überstimmen, über welche Schnittstelle, mit welcher Schulung“. Eine AI-BOM liefert Ihnen die Zusammensetzung. Sie liefert Ihnen nicht die Bewertung. Wer Ihnen das Gegenteil verkauft, verkauft Ihnen eine Tabelle unter neuem Namen.

Was sich 2026 geändert hat und was nicht

Der AI Omnibus trat am 27. Juli 2026 in Kraft, nachdem das Europäische Parlament ihn am 16. Juni und der Rat ihn am 29. Juni angenommen hatte. Er ist eine gezielte Vereinfachung des AI Act und keine Neufassung, und die Schlagzeile ist ein Aufschub.

Der Omnibus schuf zudem eine Kategorie „kleines Unternehmen mittlerer Kapitalisierung“, definiert über weniger als 750 Beschäftigte und einen Umsatz von höchstens 150 Millionen Euro, und weitete auf sie die vereinfachten Vorlagen für technische Dokumentation sowie die verhältnismäßigen Qualitätsmanagementanforderungen aus, die zuvor nur KMU nutzen konnten. Am Inhalt von Anhang IV hat er nichts geändert. Die Liste dessen, was Sie über Ihr System sagen können müssen, ist dieselbe wie 2024.

Zwei weitere Omnibus-Änderungen betreffen speziell die Dokumentationsarbeit. Artikel 10(5) bietet nun eine klarere Rechtsgrundlage für die Verarbeitung besonderer Kategorien personenbezogener Daten, soweit dies zur Erkennung und Minderung von Verzerrungen unbedingt erforderlich ist und Schutzmaßnahmen greifen. Das löst einen echten Teufelskreis: Teams konnten die Genauigkeit nach Subgruppen nicht messen, weil sie das Merkmal nicht erheben durften, das die Messung erst ermöglicht. Und Artikel 40(2) verpflichtet die Kommission, einheitliche Normen anzufordern, die den AI Act und die bestehende Harmonisierungsgesetzgebung gemeinsam abdecken, damit ein Produkt nicht zwei parallele Dokumentationsregime bedienen muss.

Warum scheitert es ausgerechnet am Inventar?

Weil KI-Komponenten über Kanäle in ein Repository gelangen, die nie für Inventarisierung ausgelegt waren, und weil sie das inzwischen schneller tun als jede Review-Taktung.

Die gemessene Fassung ist ernüchternd. Der Cost of a Data Breach Report 2026 von IBM, durchgeführt vom Ponemon Institute bei 602 kompromittierten Organisationen zwischen März 2025 und Februar 2026, stellte fest, dass sich der Anteil der Sicherheitsvorfälle mit Shadow AI im Jahresvergleich mehr als verdoppelt hat.

Shadow AI wird meist als Mitarbeiterproblem verhandelt: jemand fügt Kundendaten in einen Consumer-Chatbot ein. Diese Rahmung unterschätzt das Phänomen erheblich. Die größere und leisere Variante ist Shadow AI im Repository. Ein Modell-String, der einem Service hinzugefügt wird. Ein HuggingFace-Datensatz, der in ein Notebook gezogen wird. Ein MCP-Server, der für eine Debugging-Sitzung auf eine Produktionsdatenbank zeigt und nie entfernt wird. Eine Prompt-Datei, die bearbeitet wird, um eine Einschränkung zu lockern. Jedes ist eine einzeilige Änderung. Jedes verändert, was das System ist, und damit, was seine Dokumentation nach Anhang IV sagen müsste. Keines meldet sich an.

Dieser dritte Schritt hat sich verändert, seit der AI Act entworfen wurde. Wenn ein menschlicher Entwickler ein Modell wählte, gab es eine Entscheidung, meist ein Gespräch, manchmal ein Designdokument. Wenn ein KI-Coding-Agent die Integration schreibt, wählt er Modell, Client-Bibliothek und Standardkonfiguration in einer einzigen Bearbeitung, und die Spur dieser Entscheidung ist ein Diff, den niemand Zeile für Zeile liest. Die allgemeine Form dieses Problems haben wir in warum die meisten SAST-Findings Rauschen sind und in Geschäftslogikfehler in KI-generiertem Code beschrieben; der AI-BOM-Fall ist die Governance-Variante desselben Taktungsproblems.

“

Ein als Dokument gepflegtes Inventar beschreibt den Tag, an dem es geschrieben wurde. Ein aus dem Code abgeleitetes Inventar beschreibt heute. Nur eines von beiden übersteht ein Audit, das achtzehn Monate nach der letzten Review-Sitzung eintrifft.

Was muss ein KI-Inventar erfassen?

Sechs Kategorien, und jede davon ist ein Ort, an dem die Zusammensetzung des Systems entschieden wird. Fehlt eine, hat das Anhang-IV-Paket eine Lücke, die eine prüfende Stelle beim Lesen des Codes findet, den Sie selbst als Nachweis übergeben haben.

Welches AI-BOM-Format sollte man verwenden?

CycloneDX ist die pragmatische Standardwahl. Es unterstützt Machine-Learning-Modelle seit Version 1.5 im Jahr 2023, die aktuelle Spezifikation ist 1.7 (veröffentlicht am 21. Oktober 2025) und sie ist als ECMA-424 normiert, es handelt sich also um einen echten Standard und kein Herstellerschema. SPDX 3.0 bietet über sein AI Profile eine ISO-orientierte Alternative. Beide sind als JSON serialisierbar, beide fügen sich in bestehende SBOM-Pipelines ein, und beide werden von offener Tooling-Landschaft unterstützt.

Eine minimale CycloneDX-ML-BOM-Komponente sieht so aus.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "components": [
    {
      "type": "machine-learning-model",
      "bom-ref": "pkg:huggingface/mistralai/Mistral-7B-Instruct-v0.3",
      "name": "support-triage-v4",
      "version": "2026-06-11",
      "modelCard": {
        "modelParameters": {
          "approach": { "type": "supervised" },
          "architectureFamily": "Transformer (Mistral-7B, fine-tuned)",
          "datasets": [
            { "ref": "urn:cdx:dataset-support-tickets-2025h2", "type": "training" }
          ]
        },
        "quantitativeAnalysis": {
          "performanceMetrics": [
            { "type": "accuracy", "value": "0.881", "slice": "all locales" }
          ]
        },
        "considerations": {
          "useCases": ["tier-1 support triage"],
          "technicalLimitations": ["degrades below 0.72 on locales unseen in training"]
        }
      }
    }
  ]
}

Das deckt Anhang IV §1, §2(b), §2(c), §2(d) und einen Teil von §2(g) in einem einzigen Objekt ab. Was es nicht abdeckt und was Sie daher als benutzerdefinierte Eigenschaften oder als separate Dokumente führen, fällt in drei Kategorien.

Neben dem Format steht die Reporting-Ebene. Das NIST AI Risk Management Framework (AI 100-1) gliedert die KI-Risikoarbeit in Govern, Map, Measure und Manage, und seine Map-Funktion kommt einer Definition der Inventaraufgabe nahe: Kontext, Komponenten, Fähigkeiten und Grenzen des Systems dokumentieren. ISO/IEC 42001 verlangt ein KI-Managementsystem, in dessen Kern ein KI-Inventar und eine Risikobewertung stehen. Keines von beiden ist ein Format. Beide verbrauchen dieselben zugrunde liegenden Fakten, was das praktische Argument dafür ist, diese Fakten einmal maschinell zu erzeugen und anschließend in das Rahmenwerk zu projizieren, das die jeweilige prüfende Stelle oder der Sicherheitsfragebogen eines Kunden spricht.

Wie baut man eine AI-BOM, die wahr bleibt?

Der Fehlermodus jedes Governance-Inventars ist identisch, und er hat nichts mit dem Anfangsaufwand zu tun. Jemand startet eine Erhebung, befragt die Teams, füllt eine Tabelle, und das Artefakt ist etwa eine Woche lang korrekt. Was folgt, ist keine Faulheit; es ist Arithmetik. Komponenten ändern sich schneller als Review-Zyklen.

Die Designbedingung kommt also zuerst, und die Schritte folgen daraus.

1. Leiten Sie das Inventar aus dem Code ab, nie aus einem Fragebogen. Ein Fragebogen erfasst, woran sich Menschen erinnern. Ein Scan erfasst, was ausgeliefert wurde. Die beiden divergieren sofort, und nur eines davon ist das, was eine prüfende Stelle liest.

2. Verankern Sie jede Komponente an einer Datei und einer Zeile. Ein Inventareintrag ohne Quellort ist eine Behauptung. Ein Eintrag mit src/lib/triage.ts:23 daneben ist ein Nachweis, und er macht die Behebung einem Team zuweisbar statt einem Gremium.

3. Klassifizieren Sie auf Komponentenebene, nicht auf Systemebene. Artikel 5, 6 und 50 knüpfen daran an, was eine Komponente tut. Ein Repository enthält routinemäßig einen Chat-Helfer mit minimalem Risiko, einen kundenzugewandten Assistenten mit begrenztem Risiko und ein wirklich hochriskantes Scoring-Modell. Ein einziges Label auf Systemebene verdeckt genau die Komponente, auf die es ankommt.

4. Kennzeichnen Sie Status, nicht nur Vorhandensein. Governed, Shadow, Drift, fehlend. Eine Komponente mit Model Card und Lizenz ist ein anderes Objekt als dieselbe Komponente ohne beides, und der gesamte Wert eines ersten Scans liegt im Verhältnis zwischen diesen beiden Stapeln.

5. Erzeugen Sie es bei jedem Push neu und bilden Sie den Diff. Anhang IV §6 verlangt die über den Lebenszyklus vorgenommenen Änderungen. Wird das Inventar pro Commit neu erzeugt, schreibt sich dieser Abschnitt von selbst; der Diff ist das Änderungsprotokoll. Wird es pro Quartal erzeugt, muss jemand es aus dem Gedächtnis rekonstruieren.

6. Blockieren Sie die Pipeline bei jeder neuen ungoverneten Komponente. Ein Build, der fehlschlägt, sobald eine verbotene oder hochriskante Komponente ohne Dokumentation landet, ist die einzige Kontrolle, die das Verhältnis aus Schritt 4 stabil hält. Alles Weichere als ein Gate verkommt zu einem Dashboard, das niemand öffnet.

7. Regeln Sie vertraglich, was Sie nicht scannen können. Ihr Scan sieht, was Ihr Repository enthält. Er sieht nicht den Trainingskorpus eines Anbieters. Artikel 25(2) und 25(4) legen die Kooperationspflicht auf den vorgelagerten Anbieter, also schreiben Sie sie auch in den Vertrag: Model Cards, Zusammenfassungen der Trainingsdaten und Benachrichtigung, wenn sich eine Modellversion unter Ihnen ändert.

8. Bewahren Sie es zehn Jahre auf. Artikel 18 ist eindeutig, und zehn Jahre sind länger als die meisten Artefakt-Aufbewahrungsrichtlinien, länger als die Standardaufbewahrung der meisten CI-Anbieter und deutlich länger als die durchschnittliche Verweildauer der Person, die das System gebaut hat. Exportieren Sie das Paket an einen dauerhaften Ort.

Wie CybeDefend die AI-BOM erzeugt

Alles Vorherige ist der allgemeine Fall. So setzen wir es um, denn die Designbedingung aus dem vorigen Abschnitt ist genau die, für die wir gebaut haben.

Der AI-BOM-Scanner von CybeDefend durchläuft ein Repository und katalogisiert die sechs Kategorien direkt aus dem Code: Modelle (gehostete Strings, HuggingFace-Kennungen, lokale .gguf- und .onnx-Gewichte), in Code oder Konfiguration referenzierte Datensätze, versionierte Prompts, Agenten- und Orchestrierungs-Frameworks, die von Ihren Agenten genutzten MCP-Server und die eingesetzten Guardrail-Bibliotheken. Jeder Eintrag landet mit Quelldatei und Zeile, fester Version und einem Status: governed, shadow, drift oder fehlend. Kein Fragebogen, keine Interviewrunde.

Ein Scan gibt anschließend drei Artefakte in ./.ai-bom/ aus, und das ist der Teil, auf den es für die oben beschriebene Arbeit ankommt.

Das erste ist ein AI-Act-Compliance-Bericht, abgebildet auf die Verordnung (EU) 2024/1689, mit jeder Komponente einsortiert in verbotenes, hohes, begrenztes oder minimales Risiko nach Artikel 5, 6 und 50, GPAI-Komponenten getrennt gezählt und Komponenten mit systemischem Risiko markiert. Das zweite ist eine NIST-AI-RMF-Abdeckungszuordnung über Govern, Map, Measure und Manage, mit benannten Lücken statt einer geglätteten Durchschnittszahl. Das dritte ist die maschinenlesbare CycloneDX-AI-BOM, damit sich das Inventar in die SBOM-Werkzeuge einfügt, die Sie ohnehin betreiben.

Es läuft dort, wo Sie ausliefern. Fügen Sie die cybedefend-action in einen GitHub-Workflow ein oder rufen Sie die CybeDefend-CLI aus GitLab CI, einem Jenkinsfile oder Tekton auf, und der Scan läuft bei jedem Push, der Bericht wird als Build-Artefakt veröffentlicht.

- name: CybeDefend Security Scan
  uses: CybeDefend/cybedefend-action@v2
  with:
    pat: ${{ secrets.CYBEDEFEND_PAT }}
    project_id: ${{ secrets.CYBEDEFEND_PROJECT_ID }}
    branch: ${{ github.ref_name }}
    break_on_severity: high

Das sind Schritt 5 und 6 der obigen Liste, umgesetzt: das Inventar wird pro Commit neu erzeugt, Anhang IV §6 wird damit zu einem Diff, und der Build bricht ab, sobald eine neue verbotene oder hochriskante Komponente ohne Governance-Dokumentation landet. Der Scan liest Ihr Repository und erzeugt ein strukturiertes Inventar; Quellcode verlässt Ihre Umgebung nicht, und das Dashboard erhält ausschließlich Komponenten-Metadaten, niemals Rohcode oder Prompt-Inhalte.

Die AI-BOM steht neben der übrigen Plattform und nicht innerhalb der Agentenschleife. Sie ist ein Repository- und Pipeline-Scanner, was für ein Inventar der richtige Ort ist: es braucht den ganzen Baum, nicht die laufende Bearbeitung. Was innerhalb der Agentenschleife läuft, ist VibeDefend, das Ihre Geschäfts- und Sicherheitsregeln in den Agenten lädt, bevor er schreibt, unsichere Aktionen abfängt und SAST-, SCA-, Secrets-, IaC- und CI/CD-Findings im Kontext des Agenten lebendig hält. Beide ergänzen einander. VibeDefend regiert, was der Agent beim Schreiben tut; die AI-BOM hält fest, wozu das Repository geworden ist.

Häufig gestellte Fragen

Was ist eine AI-BOM?

Eine AI-BOM, oder AI Bill of Materials, ist ein maschinenlesbares Inventar aller KI-Komponenten eines Systems: Modelle, Datensätze, Prompts, Agenten und Orchestrierungs-Frameworks, die Tools und MCP-Server, die diese Agenten aufrufen, sowie die darauf angewandten Guardrails. Jeder Eintrag trägt Herkunfts- und Governance-Fakten: Anbieter, Version, Lizenz, Datenherkunft, Fähigkeitsumfang und Risikoklassifizierung. Sie überträgt das SBOM-Konzept von Softwarepaketen auf KI-Assets und ist die zugrunde liegende Nachweisbasis für die technische Dokumentation nach Artikel 11 und Anhang IV des EU AI Act, für NIST-AI-RMF-Reporting und für KI-Inventare nach ISO/IEC 42001.

Was ist der Unterschied zwischen einer AI-BOM und einer SBOM?

Eine SBOM listet Softwarekomponenten (Pakete, Versionen, Lizenzen) und dient vor allem dazu, bekannte Schwachstellen zu finden. Eine AI-BOM listet KI-Komponenten und ihre KI-spezifischen Governance-Aspekte: Herkunft der Trainingsdaten, Fine-Tuning-Abstammung, Prompt-Versionen, Fähigkeitsumfang der Agenten, Guardrail-Abdeckung und Restrisiko. Sie ergänzen einander, statt zu konkurrieren, und CycloneDX kann beide ausdrücken, sodass eine AI-BOM im selben Format und derselben Pipeline wie Ihre bestehende SBOM erzeugt werden kann.

Verlangt der EU AI Act eine AI-BOM?

Nicht unter diesem Namen. Der AI Act verwendet den Begriff nie. Artikel 11 verpflichtet Anbieter von Hochrisiko-KI-Systemen, vor dem Inverkehrbringen technische Dokumentation zu erstellen und aktuell zu halten, und Anhang IV legt den Mindestinhalt fest: allgemeine Beschreibung, Designspezifikationen, Architektur, Datenanforderungen und Datenherkunft, menschliche Aufsicht, Validierung und Test, Cybersicherheit, Fähigkeiten und Grenzen, Risikomanagement, Änderungen im Lebenszyklus und Beobachtung nach dem Inverkehrbringen. Eine AI-BOM ist der praktische Weg, den größten Teil dieses Pakets maschinell zu erzeugen. Artikel 18 verlangt anschließend die Aufbewahrung der Dokumentation über zehn Jahre nach dem Inverkehrbringen.

Hat der AI Omnibus die Pflicht zur technischen Dokumentation abgeschafft?

Nein. Der AI Omnibus trat am 27. Juli 2026 in Kraft und verschob die Hochrisikopflichten für eigenständige Systeme nach Anhang III vom 2. August 2026 auf den 2. Dezember 2027 sowie für Hochrisiko-KI in regulierten Produkten vom 2. August 2027 auf den 2. August 2028. Er schuf außerdem die Kategorie „kleines Unternehmen mittlerer Kapitalisierung“ (weniger als 750 Beschäftigte, Umsatz höchstens 150 Millionen Euro), die vereinfachte Vorlagen für technische Dokumentation nutzen darf. Der Inhalt von Anhang IV blieb unverändert, die Transparenzpflichten nach Artikel 50 blieben bei ihrem ursprünglichen Datum, und die GPAI-Pflichten gelten seit dem 2. August 2025, mit Durchsetzungsbefugnissen der Kommission seit dem 2. August 2026.

Welches Format sollte eine AI-BOM verwenden, CycloneDX oder SPDX?

CycloneDX ist die pragmatische Standardwahl. Es unterstützt Machine-Learning-Modelle seit Version 1.5 (2023), die aktuelle Spezifikation ist 1.7 (Oktober 2025) und sie ist als ECMA-424 normiert, mit modelCard, modelParameters, Datensatzreferenzen und quantitativeAnalysis, die den Großteil der Zusammensetzungsfakten abdecken. Das AI Profile von SPDX 3.0 ist die ISO-orientierte Alternative und eine sinnvolle Wahl, wenn Ihre Organisation ohnehin auf SPDX standardisiert. Keines von beiden hat native Felder für die Methodik der Bias-Bewertung oder das Design menschlicher Aufsicht, das wird also in beiden Fällen als benutzerdefinierte Eigenschaft oder verlinktes Dokument geführt.

Bin ich Anbieter, wenn ich das Modell eines anderen nur feinabgestimmt habe?

In der Regel ja. Artikel 25(1) behandelt eine Partei als Anbieter eines Hochrisiko-KI-Systems, wenn sie es unter eigenem Namen oder eigener Marke in Verkehr bringt, wenn sie es wesentlich verändert, oder wenn sie seine Zweckbestimmung so ändert, dass es zum Hochrisikosystem wird. Ein vorhandenes Modell auf eigenen Daten feinabzustimmen und unter dem eigenen Produktnamen auszuliefern, löst typischerweise alle drei Fälle aus. Die Model Card des ursprünglichen Labors dokumentiert nur das Basismodell; die Dokumentationspflicht nach Artikel 11 für Ihr System liegt bei Ihnen, und Artikel 25(2) und 25(4) verpflichten den vorgelagerten Anbieter zur Zusammenarbeit und Informationsbereitstellung, nicht dazu, Ihr Paket zu schreiben.

Wie findet man Shadow AI in einer Codebasis?

Indem man den Code scannt statt die Teams zu befragen. KI-Komponenten deklarieren sich selten in einem Manifest: ein gehostetes Modell erscheint als String-Literal, ein lokales Modell als Gewichtspfad in einer Konfiguration, ein Datensatz als URI in einem Notebook, ein MCP-Server als URL in einer Agentenkonfiguration, ein Prompt als nicht nachverfolgte Markdown-Datei. Ein Repository-Scan löst jedes davon in eine Komponente mit Datei und Zeile auf und markiert anschließend jene ohne Model Card, ohne Lizenz, ohne feste Version und ohne erfassten Verantwortlichen. IBMs Cost of a Data Breach Report 2026 fand Shadow AI in 43 % der Sicherheitsvorfälle und mehr als zwei Drittel der Organisationen ohne Governance-Prozess zu ihrer Begrenzung, die realistische Erwartung an einen ersten Scan ist also, dass der Shadow-Stapel größer ausfällt als der governte.

Wie oft sollte eine AI-BOM neu erzeugt werden?

Bei jedem Push. Anhang IV §6 verlangt die über den Lebenszyklus vorgenommenen Änderungen, und ein Inventar pro Commit macht aus diesem Abschnitt einen Diff statt einer Rekonstruktionsübung. Ein Quartalsinventar ist binnen Tagen veraltet, sobald KI-Coding-Agenten die Integrationen schreiben, denn ein Modellwechsel, eine neue Tool-Berechtigung oder eine Prompt-Änderung ist ein einzeiliger Commit. In der CI neu zu erzeugen und den Build scheitern zu lassen, sobald eine neue hochriskante oder verbotene Komponente ohne Dokumentation landet, ist das, was Artefakt und Codebasis in Übereinstimmung hält.