Dokumentationspflichten für Hochrisiko-KI: Was Sie konkret brauchen

Die Dokumentationslandschaft: Was verlangt wird und warum

Dokumentation ist das Rückgrat der Hochrisiko-Regulierung. Der EU AI Act verfolgt einen klaren Grundgedanken: Wenn ein KI-System in sensiblen Bereichen eingesetzt wird - Personalauswahl, Kreditvergabe, Strafverfolgung, kritische Infrastruktur - dann muss jede Entscheidung nachvollziehbar sein. Nicht im Nachhinein rekonstruiert, sondern von Anfang an dokumentiert.

Die Pflichten verteilen sich auf mehrere Artikel, die zusammen ein geschlossenes System bilden:

• Technische Dokumentation nach Art. 11 i.V.m. Annex IV
• Risikomanagementsystem nach Art. 9
• Daten-Governance nach Art. 10
• Aufzeichnungspflichten nach Art. 12
• Transparenzpflichten nach Art. 13
• Qualitätsmanagementsystem nach Art. 17
• Konformitätsbewertung nach Art. 43
• EU-Konformitätserklärung nach Art. 47
• Registrierung in der EU-Datenbank nach Art. 49

Das klingt nach viel. Ist es auch. Aber die meisten dieser Anforderungen überlappen sich inhaltlich. Wer die technische Dokumentation sauber aufbaut, hat 60-70% der anderen Pflichten bereits abgedeckt. Der Schlüssel liegt in der Struktur.

Technische Dokumentation (Art. 11 + Annex IV)

Annex IV ist das Herzstück. Hier steht schwarz auf weiß, was die technische Dokumentation enthalten muss. Die Dokumentation muss vor dem Inverkehrbringen erstellt und laufend aktualisiert werden.

Allgemeine Beschreibung und Zweckbestimmung

Jedes Hochrisiko-KI-System braucht eine klare Beschreibung seiner Zweckbestimmung (intended purpose). Das ist kein Marketing-Text. Gefordert sind:

• Die genaue Funktion des Systems und der Zweck, für den es bestimmt ist
• Name und Kontaktdaten des Anbieters
• Die Version des Systems
• Wie das System mit Hardware oder Software interagiert, die nicht Teil des Systems selbst ist
• Die Versionen relevanter Software oder Firmware

Konkret: Wenn Sie ein KI-System zur Bewerbervorauswahl betreiben, reicht nicht "KI für HR". Sie beschreiben: "System zur automatisierten Vorauswahl von Bewerbungen auf Basis von Lebensläufen und Anschreiben. Bewertet Eignung anhand von X Kriterien. Output: Ranking-Score 0-100 und Empfehlung ja/nein/vielleicht. Nicht vorgesehen für: finale Einstellungsentscheidungen ohne menschliche Prüfung."

Entwicklungsprozess und Designentscheidungen

Annex IV verlangt eine detaillierte Beschreibung der Elemente des KI-Systems und des Entwicklungsprozesses:

• Methoden und Schritte der Entwicklung, einschließlich des Einsatzes vortrainierter Systeme oder Tools Dritter
• Designspezifikationen: Gesamtarchitektur, algorithmische Entscheidungen, zentrale Annahmen
• Beschreibung der Recheninfrastruktur (Hardware-Anforderungen, Rechenkapazität, erwartete Latenzen)

In der Praxis: Dokumentieren Sie, warum Sie sich für ein bestimmtes Modell entschieden haben. Warum Gradient Boosting statt neuronales Netz? Warum GPT-4 als Basis statt Llama? Diese Entscheidungen müssen nachvollziehbar sein - nicht als wissenschaftliche Abhandlung, sondern als nachvollziehbare Begründung.

Trainings-, Validierungs- und Testdaten

Art. 10 regelt die Daten-Governance, Annex IV fordert die Dokumentation. Konkret verlangt sind:

• Beschreibung der verwendeten Trainings-, Validierungs- und Testdatensätze
• Herkunft der Daten, Umfang und wesentliche Merkmale
• Wie die Daten beschafft und ausgewählt wurden
• Kennzeichnungsverfahren (Labeling), Datenbereinigung, Anreicherung
• Bewertung der Verfügbarkeit, Menge und Eignung der Datensätze
• Prüfung auf mögliche Verzerrungen (Bias) und Maßnahmen zu deren Behebung

Das bedeutet: Sie brauchen ein Datenblatt pro Datensatz. Nicht 200 Seiten, aber genug, damit ein Auditor nachvollziehen kann, woher die Daten kommen und warum sie geeignet sind.

Leistungskennzahlen und bekannte Einschränkungen

Die Dokumentation muss enthalten:

• Metriken zur Bewertung der Genauigkeit, Robustheit und Cybersicherheit (Art. 15)
• Bekannte und vorhersehbare Einschränkungen des Systems
• Erwartbare Ergebnisse und Vorhersehbarkeitsgrad
• Spezifikationen zu Eingabedaten (welche Daten werden benötigt, in welchem Format)

Praktisch heißt das: Accuracy, Precision, Recall, F1-Score - plus Angabe, bei welchen Subgruppen die Performance abweicht. Ein System zur Kreditwürdigkeitsprüfung, das bei Selbstständigen 15% schlechter performt als bei Angestellten, muss das dokumentieren. Nicht verstecken.

Maßnahmen zur menschlichen Aufsicht

Art. 14 regelt die menschliche Aufsicht, Annex IV fordert deren Dokumentation:

• Welche Maßnahmen zur menschlichen Aufsicht vorgesehen sind
• Wie die Aufsichtsperson das System übersteuern, stoppen oder korrigieren kann
• Welche technischen Mittel die Aufsicht unterstützen

Ein Beispiel: Bei einem System zur automatisierten Dokumentenprüfung in der Versicherungsbranche dokumentieren Sie, dass jede Ablehnungsentscheidung von einem Sachbearbeiter bestätigt werden muss, dass der Sachbearbeiter die Bewertungsgründe einsehen kann und dass er mit einem Klick die Systementscheidung überstimmen kann.

Genauigkeit, Robustheit, Cybersicherheit

Art. 15 verlangt, dass Hochrisiko-KI-Systeme ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit erreichen. Die Dokumentation muss umfassen:

• Getestete und erwartete Genauigkeitsniveaus
• Maßnahmen gegen Fehler, Ausfälle und Inkonsistenzen
• Resilienz gegen Manipulationsversuche (adversarial attacks)
• Technische Redundanz und Failover-Konzepte
• Cybersicherheitsmaßnahmen gegen unbefugten Zugriff und Datenmanipulation

Risikomanagement-Dokumentation (Art. 9)

Der iterative Risikomanagementprozess

Art. 9 verlangt ein Risikomanagementsystem, das den gesamten Lebenszyklus des KI-Systems begleitet. Das ist kein einmaliges Assessment vor dem Launch. Es ist ein fortlaufender Prozess mit vier Phasen:

1. Identifikation und Analyse bekannter und vernünftigerweise vorhersehbarer Risiken
2. Bewertung der Risiken, die bei bestimmungsgemäßer Verwendung und bei vernünftigerweise vorhersehbarer Fehlanwendung auftreten können
3. Bewertung weiterer Risiken auf Grundlage der Post-Market-Überwachung (Art. 72)
4. Geeignete und zielgerichtete Risikominderungsmaßnahmen

Was eine Risikobewertung in der Praxis aussieht

Eine Risikobewertung für ein Hochrisiko-KI-System ist kein abstraktes Dokument. Sie enthält konkret:

• Risikokatalog: Jedes identifizierte Risiko mit Beschreibung, betroffener Personengruppe und Schadenspotenzial
• Eintrittswahrscheinlichkeit und Schweregrad: Quantifiziert oder kategorisiert (hoch/mittel/niedrig)
• Mitigationsmaßnahmen: Was wurde gegen jedes Risiko unternommen?
• Testprotokolle: Wie wurde verifiziert, dass die Maßnahme wirkt?

Für ein KI-System im Bereich Personalauswahl könnte ein Risikoeintrag lauten: "Risiko: Geschlechtsbezogene Diskriminierung durch historisch verzerrte Trainingsdaten. Schweregrad: Hoch. Wahrscheinlichkeit: Mittel. Maßnahme: Bias-Audit auf geschützten Merkmalen, regelmäßige Fairness-Tests, Ausschluss von Proxy-Variablen. Verifikation: Quartalsweiser Adverse-Impact-Test nach 4/5-Regel."

Residualrisiken

Art. 9 Abs. 4 ist klar: Verbleibende Risiken müssen dokumentiert werden. Kein System ist risikofrei. Wer behauptet, alle Risiken eliminiert zu haben, hat entweder nicht richtig gesucht oder dokumentiert unvollständig.

Residualrisiken werden mit Begründung akzeptiert und den Betreibern (Deployern) in den Gebrauchsanweisungen mitgeteilt.

Qualitätsmanagementsystem (Art. 17)

Was QMS für KI konkret bedeutet

Art. 17 verlangt von Anbietern ein Qualitätsmanagementsystem. Das ist kein ISO-9001-Zertifikat an der Wand. Es ist ein dokumentiertes System von Strategien, Verfahren und Anweisungen, das folgende Bereiche abdeckt.

Mindestanforderungen

Das QMS muss mindestens enthalten:

• Eine Strategie zur Einhaltung regulatorischer Anforderungen
• Verfahren für die Designentwicklung und -kontrolle
• Verfahren für Entwicklung, Qualitätskontrolle und Qualitätssicherung
• Prüf- und Validierungsverfahren (vor, während und nach der Entwicklung)
• Technische Spezifikationen und Normen
• Systeme und Verfahren für das Datenmanagement (einschließlich Art. 10)
• Das Risikomanagementsystem nach Art. 9
• Post-Market-Monitoring nach Art. 72
• Verfahren für die Meldung schwerwiegender Vorfälle (Art. 73)
• Kommunikation mit Behörden und notifizierten Stellen
• System zur Dokumentenverwaltung und -aufbewahrung
• Ressourcenmanagement und Verantwortlichkeiten
• Accountability-Framework mit klaren Zuständigkeiten

In der Praxis reicht ein gut strukturiertes Dokument von 15-25 Seiten, das diese Punkte adressiert. Kein Beraterroman.

Gebrauchsanweisungen (Art. 13)

Die Gebrauchsanweisung (Instructions for Use) richtet sich an die Betreiber (Deployer) Ihres Systems. Art. 13 verlangt, dass sie klar und verständlich folgende Informationen enthält:

• Name und Kontaktdaten des Anbieters
• Leistungsmerkmale, Fähigkeiten und Grenzen des Systems
• Zweckbestimmung und Kontraindikationen (wofür das System nicht gedacht ist)
• Änderungen, die der Anbieter während des Lebenszyklus vorgenommen hat
• Maßnahmen zur menschlichen Aufsicht, einschließlich technischer Maßnahmen
• Erwartete Lebensdauer und notwendige Wartungsmaßnahmen
• Spezifikationen zu Eingabedaten
• Informationen zu Trainings- und Validierungsdaten (soweit relevant)

Die Gebrauchsanweisung ist das Bindeglied zwischen Anbieter und Betreiber. Wenn Sie hier unvollständig dokumentieren, verlagern Sie Compliance-Risiken auf Ihre Kunden - und auf sich selbst. Denn der Anbieter haftet für unvollständige Informationen.

Aufzeichnungs- und Überwachungspflichten (Art. 12 + Art. 72)

Art. 12 verlangt, dass Hochrisiko-KI-Systeme eine automatische Aufzeichnung von Ereignissen (Logging) ermöglichen. Die Logs müssen mindestens umfassen:

• Zeitpunkt jeder Nutzung (Start und Ende)
• Referenzdatenbank, gegen die Eingabedaten geprüft werden
• Eingabedaten, die zu einer Suche geführt haben
• Identifikation der an der menschlichen Aufsicht beteiligten Personen

Art. 72 ergänzt dies um Post-Market-Monitoring: Der Anbieter muss ein System einrichten, das systematisch Daten über die Leistung des KI-Systems während seines gesamten Lebenszyklus sammelt und analysiert. Die Ergebnisse fließen zurück in das Risikomanagementsystem.

Pflichten der Betreiber (Art. 26 + Art. 27 FRIA)

Betreiber (Deployer) sind nicht nur passive Nutzer. Art. 26 verlangt eigene Dokumentationspflichten:

• Sicherstellung, dass die Eingabedaten relevant und hinreichend repräsentativ sind
• Überwachung des Betriebs gemäß Gebrauchsanweisung
• Aufbewahrung der automatisch erzeugten Logs (mindestens 6 Monate, sofern nicht anders geregelt)
• Durchführung einer Grundrechte-Folgenabschätzung (Fundamental Rights Impact Assessment, FRIA) nach Art. 27 vor Inbetriebnahme

Die FRIA nach Art. 27 ist verpflichtend für Betreiber, die Einrichtungen des öffentlichen Rechts sind oder private Betreiber, die öffentliche Dienstleistungen erbringen. Sie umfasst:

• Beschreibung der Prozesse, in denen das System eingesetzt wird
• Zeitraum und Häufigkeit der beabsichtigten Nutzung
• Kategorien betroffener Personen
• Spezifische Risiken für die in Art. 27 genannten Grundrechte
• Beschreibung der Maßnahmen zur menschlichen Aufsicht
• Maßnahmen bei Materialisierung der identifizierten Risiken

Praktisches Template: So sieht ein Dokumentationsordner aus

Eine pragmatische Ordnerstruktur für ein Hochrisiko-KI-System:

\\\` 📁 [Systemname]_Dokumentation/ ├── 01_Allgemein/ │ ├── Systembeschreibung_und_Zweckbestimmung.pdf │ ├── Versionshistorie.xlsx │ └── Anbieter_Kontaktdaten.pdf ├── 02_Technische_Dokumentation/ │ ├── Architektur_und_Design.pdf │ ├── Algorithmus_Entscheidungen.pdf │ ├── Infrastruktur_Spezifikationen.pdf │ └── Drittanbieter_Komponenten.pdf ├── 03_Daten/ │ ├── Datensatz_Trainingsdaten.pdf │ ├── Datensatz_Validierungsdaten.pdf │ ├── Datensatz_Testdaten.pdf │ ├── Bias_Analyse.pdf │ └── Daten_Governance_Verfahren.pdf ├── 04_Risikomanagement/ │ ├── Risikobewertung_v[X].pdf │ ├── Risikokatalog.xlsx │ ├── Residualrisiken.pdf │ └── Mitigationsmaßnahmen.pdf ├── 05_Leistung_und_Tests/ │ ├── Performance_Metriken.pdf │ ├── Testprotokolle.pdf │ ├── Bekannte_Einschraenkungen.pdf │ └── Fairness_Audit.pdf ├── 06_Menschliche_Aufsicht/ │ ├── Aufsichtskonzept.pdf │ └── Ueberstimmungsverfahren.pdf ├── 07_QMS/ │ ├── Qualitaetsmanagement_Handbuch.pdf │ └── Prozessbeschreibungen.pdf ├── 08_Gebrauchsanweisung/ │ └── Instructions_for_Use_v[X].pdf ├── 09_Logging_und_Monitoring/ │ ├── Logging_Konzept.pdf │ └── Post_Market_Monitoring_Plan.pdf ├── 10_Konformitaet/ │ ├── Konformitaetsbewertung.pdf │ ├── EU_Konformitaetserklaerung.pdf │ └── EU_Datenbank_Registrierung.pdf └── 11_FRIA/ (falls zutreffend) └── Grundrechte_Folgenabschaetzung.pdf \\\`

Diese Struktur ist kein Standard. Sie ist ein Vorschlag, der alle Anforderungen abdeckt und für Auditoren navigierbar ist.

Tools vs. manuelle Dokumentation

Lassen Sie mich direkt sein: Sie können die Dokumentationspflichten mit Word, Excel und einem strukturierten Dateiordner erfüllen. Der EU AI Act schreibt keine bestimmte Software vor.

Aber die Frage ist, ob das skaliert.

Wann manuelle Dokumentation funktioniert:

• Sie haben ein oder zwei Hochrisiko-KI-Systeme
• Das Team ist klein und die Verantwortlichkeiten klar
• Die Systeme ändern sich selten

Wann Sie über Tools nachdenken sollten:

• Mehrere KI-Systeme gleichzeitig im Einsatz
• Regelmäßige Modell-Updates, die neue Dokumentationszyklen auslösen
• Verschiedene Teams (Data Science, Legal, Compliance) müssen an derselben Dokumentation arbeiten
• Sie brauchen Versionierung und Audit-Trails, die über "Dateiname_v3_final_FINAL.docx" hinausgehen

Es gibt mittlerweile spezialisierte Plattformen für KI-Governance und AI Act Compliance. Manche sind ausgereift, viele noch nicht. Prüfen Sie kritisch, ob eine Plattform tatsächlich den Dokumentationsumfang nach Annex IV abbildet oder nur ein hübsches Dashboard liefert.

Mein pragmatischer Rat: Starten Sie jetzt mit der Struktur, nicht mit dem Tool. Die Ordnerstruktur oben funktioniert mit jedem System. Wenn Sie in sechs Monaten merken, dass die manuelle Pflege zu aufwändig wird, migrieren Sie. Aber die Struktur und die Inhalte - die brauchen Sie in jedem Fall.

Fazit

Der 2. August 2026 ist kein abstraktes Datum mehr. Die Dokumentationspflichten für Hochrisiko-KI-Systeme sind umfangreich, aber sie sind kein Hexenwerk. Sie folgen einer klaren Logik: Beschreiben Sie, was Ihr System tut. Dokumentieren Sie, wie und womit es entwickelt wurde. Belegen Sie, dass Sie die Risiken kennen und adressieren. Geben Sie Betreibern alles an die Hand, was sie für einen sicheren Einsatz brauchen.

Wer das als lästige Pflicht betrachtet, hat die falsche Perspektive. Gute Dokumentation ist kein Compliance-Overhead - sie ist die Grundlage dafür, dass Ihr KI-System überhaupt vertrauenswürdig einsetzbar ist. Und sie ist die Eintrittskarte für den europäischen Markt.