AI-BOM und Model-Cards für EU-AI-Act-Transparenz 2026

Pexon Consulting | 11 Min. Lesezeit | 15.07.2026

TL;DR

Eine AI-BOM ist die maschinenlesbare Stückliste eures KI-Systems, eine Model-Card der lesbare Steckbrief pro Modell. Beide operationalisieren die Transparenz- und Dokumentationspflichten des EU AI Act. Pexon Consulting, 80 Mitarbeiter und Microsoft Partner, baut euch die Struktur in einem 6-Wochen-Pilot auf, statt eines 80-seitigen PDFs, das nie gepflegt wird.

Warum ein PDF-Dossier die falsche Antwort ist

Die meisten Firmen reagieren auf den AI Act mit einem Word-Dokument: einmal geschrieben, im Compliance-Ordner abgelegt, nie wieder angefasst. Das ist der teuerste Fehler, den wir gerade in Projekten sehen. Der AI Act verlangt keine Momentaufnahme, sondern eine gepflegte, aktuelle Dokumentation, die dem Modell und den Daten folgt, wenn sie sich ändern.

Ein Sprachmodell, das ihr im Januar dokumentiert habt, hat im Juli ein neues Fine-Tuning, eine andere RAG-Datenquelle und einen aktualisierten Prompt-Filter. Das PDF weiß davon nichts. Genau diese Lücke füllen zwei Artefakte, die aus der Software-Welt kommen und jetzt für KI adaptiert werden: die AI-BOM als maschinenlesbare Stückliste und die Model-Card als menschenlesbarer Steckbrief.

Unsere klare Position: Wer Transparenzpflichten mit einem statischen Dokument erschlagen will, produziert Compliance-Theater. Die Prüfstelle will nicht euer schönstes PDF sehen, sie will nachvollziehen, was live im System steckt.

Was eine AI-BOM ist und woher sie kommt

Eine AI-BOM (AI Bill of Materials) ist ein maschinenlesbares Inventar jedes Datensatzes, Modells und Software-Bausteins, aus dem ein KI-System gebaut ist. Sie ist die direkte Erweiterung der SBOM (Software Bill of Materials), die in der Cybersecurity seit Jahren Standard ist, um KI-spezifische Angaben: Modellgewichte, Trainingsdaten-Referenzen, Preprocessing-Schritte, Lernraten und Umgebungs-Konfiguration.

Der Punkt: Ihr erfindet kein neues Format. Die etablierte Spezifikation CycloneDX hat mit ihrer ML-BOM-Erweiterung genau dafür eine eigene, versionierte Struktur veröffentlicht, aufsetzend auf demselben Standard, den eure Security-Teams schon für Container-Images nutzen. SPDX geht denselben Weg. Das heißt konkret: Ihr könnt die AI-BOM in dieselbe CI/CD-Pipeline hängen, die heute schon SBOMs generiert.

Warum das für den AI Act zählt: Annex XI verlangt von Anbietern universeller KI-Modelle (GPAI) unter anderem die Modellarchitektur und Parameterzahl, die Art und Herkunft der Trainingsdaten samt Kurationsmethodik, die eingesetzten Rechenressourcen und Trainingszeit sowie den bekannten oder geschätzten Energieverbrauch. Eine gepflegte AI-BOM ist der Ort, an dem diese Felder leben, statt in einem Textblock zu verstauben.

Was eine Model-Card ist und wie sie sich von der AI-BOM unterscheidet

Die Model-Card ist der lesbare Steckbrief eines einzelnen Modells: Wofür ist es gedacht, wo sind die Grenzen, welche Fehlermodi sind bekannt, wie wurde es evaluiert. Während die AI-BOM eine Maschine füttert (Scanner, Audit-Tool, Lieferketten-Prüfung), spricht die Model-Card einen Menschen an, der eine Verantwortungsentscheidung trifft: den Compliance-Verantwortlichen, den Downstream-Integrator, den Auditor.

Beide gehören zusammen, sind aber nicht dasselbe. Die AI-BOM sagt „dieses System enthält Modell X in Version 2.3 mit Datenquelle Y“. Die Model-Card sagt „Modell X ist für deutschsprachige Dokumentenklassifikation trainiert, halluziniert bei Tabellen und sollte nicht für medizinische Entscheidungen genutzt werden“. Das eine ist Inventar, das andere ist Beipackzettel.

Für die AI-Act-Logik ist die Model-Card besonders bei Art. 53(1)(b) relevant: GPAI-Anbieter müssen Downstream-Anbietern, die das Modell in ihr System integrieren, die Informationen aus Annex XII bereitstellen. Genau das ist eine Model-Card: die Übergabe-Doku an den, der das Modell weiterbaut. In der Praxis nutzen wir das Format, das die Community um Hugging Face etabliert hat, und ergänzen die AI-Act-spezifischen Felder.

Welche Transparenzpflichten der AI Act wirklich verlangt und wann

Der AI Act staffelt seine Pflichten nach Datum, und die Reihenfolge wird oft verwechselt. Drei Ebenen sind für Transparenz und Dokumentation entscheidend, und eine davon hat sich 2026 verschoben.

GPAI-Pflichten gelten bereits. Seit dem 2. August 2025 müssen Anbieter universeller KI-Modelle die technische Dokumentation nach Annex XI führen, Downstream-Anbietern Informationen nach Annex XII geben, eine Urheberrechts-Policy umsetzen und eine Zusammenfassung der Trainingsdaten nach dem Template des AI Office veröffentlichen. Für Modelle, die vor diesem Datum auf dem Markt waren, läuft eine Übergangsfrist bis zum 2. August 2026.

Die Art.-50-Transparenzpflichten kommen am 2. August 2026. Das betrifft nicht nur Hochrisiko-Systeme, sondern breit: Wer KI-Systeme betreibt, die direkt mit Menschen interagieren, oder synthetische Inhalte (Text, Bild, Audio, Video) erzeugt, muss offenlegen, dass der Nutzer mit einer KI spricht beziehungsweise dass Inhalt KI-generiert ist. Deepfakes und Emotions- oder Biometrik-Erkennung fallen ebenfalls darunter.

Die Hochrisiko-Fristen wurden verschoben. Über die sogenannte Omnibus-Vereinbarung im Mai 2026 hat die EU die Pflichten für eigenständige Hochrisiko-Systeme nach Annex III (etwa Recruiting, Kreditscoring, Bildung) vom 2. August 2026 auf den 2. Dezember 2027 verschoben. In regulierte Produkte eingebettete KI nach Annex I (Medizinprodukte, Maschinen) folgt bis 2. August 2028. Der Grund ist ehrlich: Die Normungsgremien CEN-CENELEC sind mit den harmonisierten Standards nicht fertig geworden.

Die praktische Konsequenz: Wer 2026 auf die verschobene Hochrisiko-Frist wartet und deshalb nichts tut, übersieht, dass GPAI-Doku schon läuft und Art. 50 in wenigen Wochen greift. Die Verschiebung ist kein Freibrief, sie ist nur eine Umschichtung.

So operationalisiert ihr das: ein Model-Card-Template

Statt Prosa hier die konkrete Struktur. Diese YAML-Model-Card hängt ihr neben die Modell-Artefakte ins Repository, generiert die AI-BOM daraus und lasst beide bei jedem Modell-Release durch die Pipeline aktualisieren. Die Kommentare markieren, welches Feld auf welchen AI-Act-Anker zahlt.

# model-card.yaml - Steckbrief pro Modell, versioniert im Repo
# Feldkommentare verweisen auf die AI-Act-Grundlage

modell:
  name: "dok-klassifikator-de"
  version: "2.3.0"                      # muss zur AI-BOM-Referenz passen
  basis_modell: "claude-sonnet-4-6"    # namentliche Modell-ID, nicht "ein LLM"
  architektur: "Transformer, Fine-Tuning per LoRA"  # Annex XI: Architektur
  parameter_klasse: "GPAI, kein systemisches Risiko"

verwendungszweck:
  vorgesehen: "Klassifikation deutschsprachiger Eingangsdokumente"
  ausgeschlossen:                      # Grenzen explizit nennen (Haftung)
    - "medizinische oder rechtliche Entscheidungen"
    - "Verarbeitung ohne menschliche Freigabe"

daten:                                 # Annex XI: Art und Herkunft der Daten
  trainingsdaten_herkunft: "interne, freigegebene Belege 2023 bis 2025"
  kuration: "PII-Entfernung, Duplikat-Filter, manuelle Stichprobe"
  trainingsdaten_zusammenfassung: "veröffentlicht nach AI-Office-Template"

evaluation:                            # bekannte Fehlermodi offenlegen
  metrik: "F1 = 0.91 auf Halte-Set (n=4.200)"
  bekannte_grenzen:
    - "unsichere Klassifikation bei gescannten Tabellen"
    - "Bias-Prüfung für seltene Dokumenttypen ausstehend"

transparenz:                           # Art. 50, ab 2. August 2026
  ki_kennzeichnung: true               # Nutzer sieht: Ergebnis KI-generiert
  menschliche_aufsicht: "Vier-Augen-Freigabe vor Buchung"

ressourcen:                            # Annex XI: Rechenaufwand und Energie
  trainingszeit_std: 18
  energieverbrauch_kwh: 42             # geschätzt, wenn nicht gemessen

Die AI-BOM entsteht daraus maschinell. Wenn ihr CycloneDX schon für SBOMs nutzt, ergänzt ihr die ML-BOM-Komponenten und lasst sie im Build generieren:

# AI-BOM im Build erzeugen und gegen Modell-Referenz prüfen
# CycloneDX ML-BOM-Erweiterung, gleiche Pipeline wie SBOM
cyclonedx-py environment --output-format json > ai-bom.json

# Model-Card-Version muss zur AI-BOM-Komponente passen (Konsistenz-Gate)
jq -e '.components[] | select(.name=="dok-klassifikator-de" and .version=="2.3.0")' ai-bom.json 
  || echo "FEHLER: Model-Card und AI-BOM driften auseinander"

Wir raten davon ab, das händisch zu pflegen. Sobald der Mensch die Version im PDF nachtragen muss, driftet die Doku, und beim Audit steht ihr mit einem Stand von vor vier Monaten da. Der ganze Sinn ist, dass AI-BOM und Model-Card aus derselben Quelle wie euer Code kommen.

Wer welche Pflicht hat: Anbieter, Betreiber, Open Source

Ein häufiges Missverständnis: Nicht jeder muss alles dokumentieren. Der AI Act unterscheidet Rollen. Als Anbieter eines GPAI-Modells trefft ihr die volle Annex-XI-Doku-Pflicht. Als Betreiber, der ein fremdes Modell nur einsetzt, braucht ihr vor allem die Art.-50-Transparenz und eine saubere Model-Card für euren eigenen Anwendungsfall, aber nicht die Trainingsdaten-Zusammenfassung des Modellanbieters.

Für Open-Source-Modelle gibt es eine Ausnahme: Die Pflichten aus Art. 53(1)(a) und (b), also die volle technische Doku und die Downstream-Info, entfallen für Modelle unter einer freien Open-Source-Lizenz, deren Gewichte, Architektur und Nutzungsinformationen öffentlich sind. Wer Modelle mit systemischem Risiko betreibt, verliert diese Ausnahme aber wieder.

In der Praxis heißt das: Ein Mittelständler, der Llama oder ein deutsches Open-Weight-Modell selbst hostet, hat einen leichteren Doku-Pfad als vermutet, muss aber Art. 50 trotzdem erfüllen und braucht eine Model-Card für sein konkretes System. Wir sortieren im ersten Workshop, in welche Rolle ihr fallt, bevor ihr Aufwand in die falsche Pflicht steckt.

Häufig gestellte Fragen

Was kostet der Aufbau von AI-BOM und Model-Cards?

Als 6-Wochen-Pilot mit Anbindung an eure bestehende CI/CD bewegt sich das im Bereich eines mittleren fünfstelligen Betrags, abhängig von der Zahl der Modelle und der Reife eurer Pipeline. Der Kostentreiber ist selten das Template, sondern die saubere Verdrahtung mit euren Datenquellen und dem Deployment. Ein statisches PDF ist billiger, kostet euch aber beim Audit die Zeit, die ihr vorher gespart habt.

AI-BOM oder Model-Card, was brauche ich zuerst?

Beginnt mit der Model-Card, weil sie den Menschen adressiert und ihr sie sofort schreiben könnt. Die AI-BOM folgt, sobald ihr die Felder maschinell aus Repo und Pipeline zieht. Umgekehrt scheitert es oft: Wer mit der maschinellen Stückliste startet, hat die inhaltlichen Grenzen des Modells noch nicht durchdacht.

Gilt der EU AI Act auch für Modelle, die ich nur einkaufe und nutze?

Ja, aber in geringerem Umfang. Als reiner Betreiber trefft ihr vor allem die Art.-50-Transparenzpflicht ab 2. August 2026 und braucht eine Model-Card für euren Anwendungsfall. Die tiefe technische Doku nach Annex XI liegt beim Modellanbieter, nicht bei euch.

Reicht ein Model Card im Hugging-Face-Format für die AI-Act-Compliance?

Als Basis ja, als Ganzes nein. Das Community-Format deckt Verwendungszweck, Metriken und Fehlermodi gut ab, aber es fehlen die AI-Act-spezifischen Felder wie die Trainingsdaten-Zusammenfassung nach AI-Office-Template und der explizite Art.-50-Kennzeichnungsstatus. Wir erweitern das bewährte Format um genau diese Anker.

Müssen wir schon jetzt handeln oder reicht 2027 wegen der Fristverschiebung?

Handeln, jetzt. Verschoben wurden nur die eigenständigen Hochrisiko-Fristen auf Dezember 2027. Die GPAI-Doku läuft seit August 2025, und die Art.-50-Transparenz greift am 2. August 2026. Wer auf 2027 wartet, verpasst die zwei Pflichten, die schon aktiv beziehungsweise unmittelbar sind.

Nächster Schritt

Wenn ihr wisst, dass Transparenz kommt, aber nicht wisst, welche eurer Systeme welche Pflicht trifft, ist der Ausgangspunkt eine ehrliche Standortbestimmung, keine Tool-Auswahl.

Verwandte Themen

Externe Grundlage: Annex XI des EU AI Act zur technischen Dokumentation