Technische Dokumentation nach EU AI Act —
was Entwickler vorbereiten sollten.

Viele Teams hören "technische Dokumentation" und denken an Confluence-Seiten, die niemand liest. Annex IV des EU AI Acts meint etwas anderes. Es geht um ein strukturiertes Dossier, das Marktaufsichtsbehörden und Konformitätsbewertungsstellen — also Behörden, die prüfen ob dein System den Anforderungen entspricht — nachvollziehen lässt, wie das System entwickelt wurde, was es kann, wo es scheitert und wie es überwacht wird. Wer das erst baut wenn der Prüfer klingelt, hat verloren.

Gute Nachricht: Viel davon dokumentierst du sowieso schon. Es geht darum, das vorhandene Wissen in eine Struktur zu bringen, die dem Annex entspricht — und dabei die Lücken zu erkennen, bevor sie zur Compliance-Lücke werden.

Wer ist betroffen und wann?

Annex IV gilt für Anbieter von Hoch-Risiko-KI-Systemen nach Art. 6 in Verbindung mit Annex III EU AI Act. Das sind vereinfacht gesagt Systeme, die in sensiblen Bereichen Entscheidungen unterstützen oder treffen — Bewerber-Screening, Kreditvergabe-Unterstützung, biometrische Identifikation in der Strafverfolgung, KI in sicherheitskritischer Infrastruktur und weitere Kategorien.

Wer ein solches System entwickelt und in der EU auf den Markt bringt oder in Betrieb nimmt, ist Anbieter im Sinne der Verordnung — unabhängig davon ob es ein Produkt für externe Kunden oder ein intern genutztes Tool ist. Die Pflichten für High-Risk-Systeme nach Annex III greifen ab dem 2. August 2026.

Die 9 Kapitel von Annex IV — was konkret gefragt ist

Annex IV gibt neun Pflicht-Abschnitte vor. Ich gehe jeden mit praxisrelevanten Hinweisen durch, was dort tatsächlich hineingehört — und was oft vergessen wird.

Datenherkunft dokumentieren: der unterschätzte Aufwand

Kapitel 2 von Annex IV — Entwicklungsmethoden und Training — greift tief in die Datenherkunft. Was verwendest du zum Training? Woher kommen die Daten? Wie wurde sichergestellt, dass sie repräsentativ sind?

Das ist in der Praxis oft der schwerste Teil. Insbesondere wenn:

• Trainingsdaten aus verschiedenen Quellen zusammengeführt wurden und keine saubere Provenienz existiert.
• Öffentliche Datensätze verwendet wurden, deren Lizenz und Herkunft nicht vollständig dokumentiert ist.
• Das Modell auf einem vortrainierten Basismodell eines Drittanbieters aufbaut (fine-tuning).

Für den letzten Fall musst du dokumentieren, was du über das Basismodell weißt — einschließlich der Information, die der Modell-Anbieter bereitstellt (Model Cards, System Cards, technische Berichte). Was der Anbieter nicht bereitstellt, ist eine bekannte Lücke; das Vorgehen damit muss beschrieben werden.

Tests dokumentieren: Evidenz schlägt Aussage

Annex IV verlangt nicht nur, dass du testest — er verlangt, dass du nachweist, dass du getestet hast, was du wie getestet hast und was das Ergebnis war. Ein Testbericht ohne Datum, ohne definierte Testumgebung und ohne klare Pass/Fail-Kriterien ist wertlos.

Ein minimaler Test-Dokumentations-Standard für Annex-IV-Kompatibilität:

# Beispiel: Testreport-Struktur (YAML-Format für maschinelle Verarbeitbarkeit)
test_report:
  version: "1.3.2"
  date: "2026-06-15"
  environment:
    hardware: "NVIDIA A100 80GB"
    framework_version: "torch 2.3.1"
    dataset: "eval-set-v4.2-anonymized"
    dataset_size: 12400
    dataset_split: "held-out / never seen during training"

  metrics:
    accuracy:
      value: 0.887
      threshold: 0.85        # definierter Mindest-Schwellenwert
      passed: true
    false_positive_rate:
      value: 0.043
      threshold: 0.05
      passed: true
    bias_assessment:
      method: "demographic parity across gender groups"
      disparity_delta: 0.031
      threshold: 0.05
      passed: true

  known_limitations:
    - "Performance sinkt auf < 0.78 bei Anfragen in Dialekten"
    - "Robustheit bei Adversarial Inputs nicht getestet (TODO: v1.4)"

  sign_off:
    author: "Max Müller"
    reviewer: "Sara Schmidt"
    date: "2026-06-16"

Das klingt aufwändig. Ist es auch. Aber Testergebnisse, die nur in der CI/CD-Pipeline existieren ohne menschliche Auswertung und Freigabe, sind für den Annex-IV-Nachweis nicht ausreichend.

Monitoring nach Go-Live: der vergessene Teil der Doku

Annex IV Kapitel 9 — Post-Market Monitoring — ist oft das schwächste Kapitel in der Praxis. Weil es über den Launch hinausgeht und im Entwicklungsprojekt niemand zuständig ist.

Das Monitoring-System muss laut Art. 72 EU AI Act aktiv Daten über die Systemleistung im Produktivbetrieb sammeln und auswerten. Für Entwickler bedeutet das: Monitoring-Infrastruktur ist kein nettes Extra, sondern Bestandteil der Compliance-Architektur.

Was monitoren	Warum	Tool-Optionen (Beispiele)
Prediction Distribution	Data/Concept Drift erkennen — wenn sich die reale Welt vom Trainingsverteilung entfernt	Evidently AI, Arize Phoenix, eigene Statistical Process Control
Fehlerrate & Ausreißer	Anomalien im Output erkennen bevor sie eskalieren	Custom Dashboards, Grafana mit Alerting
Human Feedback	Qualitative Rückmeldungen von Nutzern zu Fehlentscheidungen	Internes Feedback-Loop, Ticketsystem
Fairness-Metriken	Sicherstellen, dass im Produktivbetrieb keine Diskriminierungseffekte entstehen	Fairlearn, eigene Gruppen-Analysen

Das Monitoring-Konzept muss in der Doku stehen, bevor das System in Betrieb geht — nicht danach geschrieben werden.

SME-Vereinfachung: was Startups und KMUs entlastet

Art. 11 Abs. 2 EU AI Act sieht ausdrücklich vor, dass kleine und mittlere Unternehmen sowie Startups die Annex-IV-Dokumentation in vereinfachter Form erbringen dürfen. Die EU-Kommission soll hierfür eine vereinfachte Vorlage bereitstellen. Stand Juni 2026 liegt diese noch nicht vor — der grundsätzliche Anspruch ist aber rechtlich verankert.

Was das konkret bedeutet: Inhaltlich müssen alle neun Annex-IV-Kapitel abgedeckt sein — Vereinfachung bezieht sich auf Format und Tiefe, nicht auf das Weglassen von Pflicht-Inhalten. Konformitätsbewertungsstellen sind per Verordnung verpflichtet, vereinfachte Formen zu akzeptieren.

Dokumentationsprozess: so baust du ihn in die Entwicklung ein

Dokumentation als Nacharbeit nach dem Sprint ist zum Scheitern verurteilt. Was funktioniert:

Definition of Done erweitern

Kein Feature ist "done", ohne dass die relevanten Annex-IV-Felder aktualisiert sind. Das klingt bürokratisch, aber eine konsequente DoD-Erweiterung ist weniger Aufwand als nachträgliches Rekonstruieren.

Dokumentations-Checkliste per Milestone

Zu jedem Modell-Release oder größeren Update eine Checkliste abarbeiten:

• Systemversion und Änderungen dokumentiert (Kapitel 1, 6)?
• Trainings- und Evaluierungsdaten beschrieben (Kapitel 2)?
• Testresultate mit Datum und Signatur (Kapitel 3, 4)?
• Risikoassessment aktualisiert (Kapitel 5)?
• Monitoring-Pläne aktuell (Kapitel 9)?

Versionskontrolle für Dokumentation

Die technische Dokumentation muss "aktuell gehalten" werden — so steht es in Art. 11. Das bedeutet: Sie ist ein lebendes Dokument. Wer Dokumentation in Word-Dateien per E-Mail verwaltet, hat ein Versions- und Aktualitäts-Problem. Besser:

# Dokumentations-Struktur als Git-Repo (Beispiel)
/ai-system-docs/
├── annex-iv/
│   ├── 01-general-description.md
│   ├── 02-development-methods.md
│   ├── 03-capabilities-limitations.md
│   ├── 04-performance-metrics.md
│   ├── 05-risk-management.md
│   ├── 06-lifecycle-changes.md
│   ├── 07-standards-applied.md
│   ├── 08-declaration-of-conformity.md
│   └── 09-post-market-monitoring.md
├── test-reports/
│   ├── 2026-03-01-v1.0-eval.yaml
│   └── 2026-06-15-v1.3-eval.yaml
├── risk-register.md
└── CHANGELOG.md

Git-Versionierung erlaubt es, zu jedem Zeitpunkt zu sagen: "So sah unsere Dokumentation zum Release-Datum aus." Das ist genau das, was eine Behörde bei einer Nachprüfung sehen will.

Quellen

• EUR-Lex: EU AI Act (Verordnung EU 2024/1689) — Volltext inkl. Annex IV und Art. 11
• artificialintelligenceact.eu: Annex IV — strukturierte Aufbereitung
• artificialintelligenceact.eu: Art. 11 — Technische Dokumentation
• EU-Kommission AI Act Service Desk: Annex IV

Häufige Fragen

Muss ich die technische Dokumentation öffentlich machen?

Nein. Die Dokumentation muss vorgehalten und auf Anfrage an nationale Marktaufsichtsbehörden und Konformitätsbewertungsstellen herausgegeben werden. Öffentlich zugänglich ist die EU-Konformitätserklärung (Annex-IV-Kapitel 8), nicht die vollständige technische Doku. Vertrauliche Geschäftsinformationen können geschützt werden.

Wie lange muss die Dokumentation aufbewahrt werden?

Nach Art. 18 EU AI Act muss die technische Dokumentation mindestens 10 Jahre nach dem Inverkehrbringen oder der Inbetriebnahme des High-Risk-KI-Systems aufbewahrt werden. Das gilt auch für abgelöste Versionen.

Wir nutzen ein vortrainiertes Basismodell eines Drittanbieters. Müssen wir dessen interne Architektur dokumentieren?

Du musst dokumentieren, was du weißt und was dir der Anbieter bereitstellt (Model Cards, technische Reports). Was der Anbieter nicht offenlegt, kann von dir nicht vollständig dokumentiert werden — das ist eine bekannte Spannung im EU AI Act. Als Anbieter des High-Risk-Systems bist du für das Gesamtsystem verantwortlich und musst diesen Umstand in der Dokumentation transparent machen. Für Anbieter von GPAI-Modellen (General Purpose AI) gibt es separate Pflichten nach Art. 53 EU AI Act.

Gibt es bereits fertige Templates für Annex-IV-konforme Dokumentation?

Es gibt Vorschläge aus der Forschung und Praxis (z. B. vom Arxiv-Papier "Technical Documentation Templates for the AI Act", Stand 2025). Eine offiziell von der EU-Kommission herausgegebene vereinfachte Vorlage nach Art. 11 Abs. 2 für KMUs lag Stand Juni 2026 noch nicht vor. Harmonisierte Standards (CEN-CENELEC JTC 21) sind in Entwicklung, erwartet Q4 2026.

Was passiert bei fehlender oder unvollständiger Dokumentation?

Fehlende technische Dokumentation ist eine der explizit genannten Verstöße in Art. 101 EU AI Act. Bußgelder für Verstöße gegen die Hochrisiko-Anforderungen (Art. 10–15) können bis zu 15 Millionen Euro oder 3 % des weltweiten Jahresumsatzes betragen, je nachdem, was höher ist. Hinzu kommen Marktzugangskonsequenzen — Systeme ohne konforme Dokumentation dürfen nicht in den EU-Markt gebracht werden.