Technische Dokumentation nach dem AI Act: ein praktischer Leitfaden zu den Anforderungen von Anhang IV

Bei einem Medizinprodukt fließt das in Ihre bestehende technische Dokumentation nach MDR/IVDR ein, siehe Anhang-IV-Dokumentation für medizinische KI.

Kurzfassung: Was Sie über die Anhang-IV-Dokumentation wissen müssen

• Wer: Jeder Anbieter (Provider) eines Hochrisiko-KI-Systems muss die technische Dokumentation nach Anhang IV erstellen, bevor er das System auf dem EU-Markt in Verkehr bringt oder in Betrieb nimmt.
• Was: Neun Pflichtabschnitte zu Systembeschreibung, Entwicklungsprozess, Überwachung, Leistungskennzahlen, Risikomanagement, Änderungen über den Lebenszyklus, harmonisierten Normen, Konformitätserklärung und Marktbeobachtung.
• Wann: Die Dokumentation muss vor Beginn der Konformitätsbewertung vorliegen, nicht danach. Die Frist für die Hochrisiko-Pflichten ist der 2. August 2026.
• Wie lange: Rechnen Sie mit 40-60 Stunden für einfache Systeme, 60-100 Stunden für mittlere Systeme und 100-200+ Stunden für komplexe Systeme. Nachträgliche Dokumentation dauert 2-3-mal so lange.
• Erleichterung für KMU: Artikel 11(2) erlaubt KMU und Startups eine vereinfachte Form, alle neun Abschnitte müssen aber trotzdem behandelt werden.
• Lebendiges Dokument: Die Anhang-IV-Dokumentation ist keine einmalige Lieferung, sie muss über den gesamten Lebenszyklus des KI-Systems hinweg aktualisiert werden.
• Tor zur Konformität: Ohne vollständige Dokumentation können Sie die Konformitätsbewertung nicht bestehen. Ohne Konformitätsbewertung dürfen Sie das System nicht rechtmäßig betreiben.

Warum technische Dokumentation wichtig ist

Artikel 11 verlangt, dass die technische Dokumentation eines Hochrisiko-KI-Systems erstellt wird, bevor das System in Verkehr gebracht oder in Betrieb genommen wird, und über seinen Lebenszyklus hinweg aktuell gehalten wird.

Die Dokumentation dient zwei Zwecken:

1. Konformität nachweisen mit den Anforderungen der Artikel 8-15: Risikomanagement, Daten-Governance, Transparenz, menschliche Aufsicht, Genauigkeit, Robustheit und Cybersicherheit.
2. Den zuständigen nationalen Behörden alle nötigen Informationen bereitstellen, um die Konformität des Systems zu bewerten.

Das ist keine Formsache. Bei der Konformitätsbewertung, ob selbst bewertet oder durch eine benannte Stelle geprüft, prüft der Bewerter Ihre Dokumentation gegen die gesetzlichen Anforderungen. Lücken in der Dokumentation führen direkt zu nicht bestandenen Bewertungen, Verzögerungen und im schlimmsten Fall dazu, dass Sie Ihr System nicht in Verkehr bringen können.

Der Bezug zur Konformitätsbewertung ist direkt: Bei Systemen, die eine Selbstbewertung nach Anhang VI erfordern, prüft das eigene Qualitätsmanagement-Team des Anbieters die Dokumentation. Bei Systemen, die nach Anhang VII eine benannte Stelle erfordern (vor allem biometrische Identifizierung), nimmt ein externer Bewerter jeden Abschnitt unter die Lupe. In beiden Fällen ist unvollständige oder vage Dokumentation der mit Abstand häufigste Grund für eine nicht bestandene Bewertung.

Die neun Pflichtabschnitte von Anhang IV

Die folgenden Abschnitte entsprechen der Struktur, die in Anhang IV des AI Act festgelegt ist. Für jeden Abschnitt erklären wir, was hineingehört, was nicht hineingehört, und geben ein praktisches Beispiel anhand eines KI-Systems zur Kreditwürdigkeitsprüfung, einer der häufigsten Hochrisiko-Einstufungen nach Anhang III Nummer 5(a).

Abschnitt 1: Allgemeine Beschreibung des KI-Systems

Was hineingehört:

• Der Zweckbestimmung des Systems, präzise formuliert
• Name, Anschrift und Kontaktdaten des Anbieters
• Versionsnummer des Systems und etwaige Vorgängerversionen
• Wie das System mit externer Hardware oder Software interagiert
• Versionen der relevanten Software oder Firmware und Anforderungen an Versions-Updates
• Alle Formen, in denen das System in Verkehr gebracht wird (SaaS, API, eingebettet, on-premise)
• Die Hardware, auf der das System laufen soll
• Bei Produktbestandteilen: Fotos, die äußere Merkmale, Kennzeichnung und internen Aufbau zeigen
• Eine grundlegende Beschreibung der Benutzeroberfläche, die dem Betreiber (Deployer) bereitgestellt wird

Was NICHT hineingehört: Marketingtexte, wunschgetriebene Funktionsbeschreibungen oder vage Behauptungen über die Fähigkeiten des Systems. Schreiben Sie so, als würden Sie das System einer Regulierungsbehörde erklären, die es noch nie gesehen hat.

Beispiel Kreditwürdigkeitsprüfung: "CreditScore Pro v3.2 ist ein KI-System, das die Kreditwürdigkeit natürlicher Personen bewertet, die Konsumkredite zwischen 1.000 EUR und 50.000 EUR beantragen. Es verarbeitet Finanzhistorie, Beschäftigungsdaten und Transaktionsmuster der Antragsteller über eine API-Integration mit dem Kernbankensystem der betreibenden Bank. Es gibt einen numerischen Score (300-850) und eine Risikokategorie (niedrig/mittel/hoch/sehr hoch) aus. Es wird als cloudbasierte SaaS-Anwendung auf AWS eu-west-1 betrieben. Das System trifft keine autonomen Kreditentscheidungen, es liefert eine Empfehlung, die ein menschlicher Kreditsachbearbeiter bewertet."

Abschnitt 2: Detaillierte Beschreibung der Elemente und des Entwicklungsprozesses

Dies ist der technisch anspruchsvollste Abschnitt. Er muss fünf Teilbereiche abdecken:

Konzeption und Entwicklung:

• Allgemeine Logik des Systems und die verwendeten Algorithmen
• Wesentliche Designentscheidungen, einschließlich Begründung und getroffener Annahmen
• Systemarchitektur, die erklärt, wie die Softwarekomponenten aufeinander aufbauen oder ineinandergreifen
• Für Entwicklung, Training, Test und Validierung eingesetzte Rechenressourcen
• Verwendete Werkzeuge, Bibliotheken oder vortrainierte Modelle von Dritten, mit Versionsnummern

Datenpraktiken:

• Trainingsmethoden und -techniken
• Trainingsdaten: Beschreibung der Datensätze, Datenherkunft, Umfang, wesentliche Merkmale
• Wie die Daten beschafft und ausgewählt wurden
• Verfahren zur Kennzeichnung (Labelling) und Methoden zur Datenbereinigung
• Bewertung der Daten in Bezug auf Eignung, Verzerrungen und mögliche Lücken

Menschliche Aufsicht:

• In das System integrierte Maßnahmen, um die menschliche Aufsicht nach Artikel 14 zu ermöglichen

Vorab festgelegte Änderungen:

• Etwaige vorab festgelegte Änderungen am System und seiner Leistung, mit Angaben zu den technischen Lösungen, die die fortlaufende Konformität sicherstellen

Validierung und Test:

• Validierungs- und Testverfahren, einschließlich der verwendeten Daten und ihrer wesentlichen Merkmale
• Kennzahlen zur Messung von Genauigkeit, Robustheit und Konformität
• Testprotokolle und Testberichte mit Datum und Unterschrift

Cybersicherheit:

• Technische Lösungen für die Anforderungen aus Artikel 15
• Maßnahmen gegen KI-spezifische Schwachstellen: Data Poisoning, Model Poisoning, adversarielle Beispiele

Beispiel Kreditwürdigkeitsprüfung, Abschnitt Datenpraktiken: "Die Trainingsdaten umfassen 2,4 Millionen anonymisierte historische Kreditanträge aus dem Zeitraum 2018-2024, bezogen von drei EU-Bankpartnern im Rahmen von Datennutzungsvereinbarungen. Der Datensatz enthält 43 Merkmale pro Antrag. Geschützte Merkmale der Antragsteller (Geschlecht, ethnische Herkunft, Alter) wurden aus den Modell-Eingaben ausgeschlossen, aber in einem separaten Analysedatensatz für Bias-Tests behalten. Kennzeichnung: Jeder Antrag wurde mit dem tatsächlichen Rückzahlungsergebnis (Ausfall/kein Ausfall) nach 12 Monaten gekennzeichnet. Datenbereinigung: 14.200 Datensätze (0,6 %) wurden wegen unvollständiger Rückzahlungsdaten ausgeschlossen. Bias-Bewertung: Der Trainingsdatensatz überrepräsentiert Antragsteller im Alter von 30-50 Jahren und unterrepräsentiert Antragsteller unter 25 Jahren. Dem wurde durch geschichtete Stichprobenziehung während des Trainings und nachträgliche Kalibrierung der Scores über die Altersgruppen begegnet."

Umgang mit Modellen Dritter und vortrainierten Modellen: Wenn Ihr System ein Modell nutzt, das Sie nicht selbst trainiert haben, ein feinabgestimmtes Foundation Model, ein vortrainiertes Embedding-Modell oder eine Klassifizierungs-API eines Dritten, müssen Sie dennoch die Merkmale des Basismodells, Ihren Anpassungsprozess und alle vom Basismodell geerbten Einschränkungen dokumentieren. "Wir haben Modell X verwendet" reicht nicht. Fordern Sie technische Dokumentation, Model Cards oder Datenblätter von Ihren Lieferanten an. Dokumentieren Sie, was Sie wissen, was Sie nicht wissen und welche Schritte Sie unternommen haben, um Lücken zu schließen. Kann der Lieferant keine ausreichende Dokumentation liefern, ist das selbst ein Risiko, das dokumentiert und gemindert werden muss.

Abschnitt 3: Überwachung, Funktionsweise und Kontrolle

• Die Fähigkeiten und Grenzen des Systems in der Leistung, einschließlich der Genauigkeitsgrade für bestimmte Personen oder Gruppen
• Vorhersehbare unbeabsichtigte Ergebnisse und Risikoquellen für Gesundheit, Sicherheit und Grundrechte
• Vorgaben zur menschlichen Aufsicht: technische Maßnahmen, um die Interpretation der Ergebnisse zu erleichtern
• Vorgaben für Eingabedaten, soweit einschlägig

Beispiel Kreditwürdigkeitsprüfung: "Die Genauigkeit des Systems (AUC-ROC) liegt bei 0,87 auf der allgemeinen Testpopulation. Bekannte Grenzen: Die Genauigkeit sinkt auf 0,79 für Antragsteller mit weniger als 12 Monaten Kredithistorie und auf 0,81 für Selbstständige mit unregelmäßigen Einkommensmustern. Das System kann unzuverlässige Scores für Antragsteller aus Ländern mit inkompatiblen Bonitätsauskunftssystemen erzeugen. Menschliche Aufsicht: Das Dashboard des Betreibers zeigt den Score, die fünf wichtigsten beitragenden Faktoren und einen Konfidenzindikator. Liegt die Konfidenz unter 70 %, kennzeichnet das System den Fall für eine verpflichtende manuelle Prüfung."

Abschnitt 4: Angemessenheit der Leistungskennzahlen

• Die zur Leistungsmessung gewählten Kennzahlen
• Warum diese Kennzahlen für das konkrete System und die Zweckbestimmung angemessen sind
• Die Benchmark(s), gegen die die Leistung gemessen wird

Anforderung an aufgeschlüsselte Genauigkeit: Der AI Act erwartet, dass Leistungskennzahlen über relevante Untergruppen aufgeschlüsselt und nicht nur als Gesamtzahlen berichtet werden. Für ein System zur Kreditwürdigkeitsprüfung bedeutet das, Genauigkeit, Falsch-positiv-Raten und Falsch-negativ-Raten aufgeschlüsselt nach Altersgruppe, Geschlecht, geografischer Region und Beschäftigungsart zu berichten. Eine einzelne Gesamtzahl wie "95 % Genauigkeit" reicht nicht und wird bei der Konformitätsbewertung wahrscheinlich beanstandet.

Beispiel Kreditwürdigkeitsprüfung: "Primäre Kennzahl: AUC-ROC, gewählt, weil sie die Trennfähigkeit über alle Klassifizierungsschwellen hinweg misst, was für ein Scoring-System angemessen ist, bei dem Betreiber ihre eigenen Annahmeschwellen setzen. Sekundäre Kennzahlen: Falsch-positiv-Rate (FPR) und Falsch-negativ-Rate (FNR), berichtet aufgeschlüsselt nach Altersgruppe (<25, 25-35, 35-50, 50-65, 65+), Geschlecht und Beschäftigungsart (angestellt, selbstständig, arbeitslos). Benchmark: Die Leistung des Systems wird mit dem bestehenden logistischen Regressionsmodell des wichtigsten Bankpartners verglichen, unter Verwendung desselben Testdatensatzes."

Abschnitt 5: Risikomanagement-System

• Das Risikomanagement-System nach Artikel 9
• Bekannte oder vorhersehbare identifizierte Risiken
• Ergebnisse der Risikobewertung
• Ergriffene Risikomanagement-Maßnahmen und Bewertung des Restrisikos
• Nachweis, dass der Prozess iterativ war und über den gesamten Entwicklungslebenszyklus durchgeführt wurde

Beispiel Kreditwürdigkeitsprüfung: "Das Risikoregister umfasst 23 identifizierte Risiken. Top 5 nach Schweregrad: (1) systematische Verzerrung gegenüber jungen Antragstellern mit dünner Kreditakte, gemindert durch altersgeschichtete Kalibrierung und verpflichtende manuelle Prüfung für Antragsteller unter 25 Jahren; (2) Proxy-Diskriminierung über die Postleitzahl, gemindert durch den Ausschluss geografischer Merkmale und Tests auf ungleiche Auswirkungen; (3) Data Drift durch sich ändernde wirtschaftliche Bedingungen, gemindert durch vierteljährliche Überwachung der Modellleistung und Auslöser für ein Nachtraining; (4) adversarielle Manipulation der Eingabedaten, gemindert durch Eingabevalidierung, Anomalieerkennung und Gegenprüfung von Transaktionsmustern; (5) übermäßiges Vertrauen der Betreiber in automatisierte Scores, gemindert durch die Pflicht zur menschlichen Prüfung aller Grenzfall-Scores (Bereich 550-650)."

Abschnitt 6: Änderungen über den Lebenszyklus

• Alle relevanten Änderungen, die über den Lebenszyklus am System vorgenommen wurden
• Wie Änderungen getestet und validiert wurden
• Verfahren zur Versionskontrolle und zum Änderungsmanagement

Dieser Abschnitt muss als lebendiges Register geführt werden. Jedes Modell-Update, jedes Nachtraining, jede hinzugefügte Funktion oder Leistungs-Neukalibrierung sollte mit Datum, Begründung, Testergebnissen und Bestätigung der fortlaufenden Konformität protokolliert werden.

Abschnitt 7: Angewandte harmonisierte Normen

• Wenn harmonisierte Normen nach Artikel 40 angewandt wurden, listen Sie sie mit Versionsnummern auf
• Wo keine harmonisierten Normen angewandt wurden, beschreiben Sie die Lösungen, die zur Erfüllung von Kapitel III Abschnitt 2 gewählt wurden

Stand April 2026 hat CEN/CENELEC Normentwürfe veröffentlicht, aber noch nicht alle sind formal harmonisiert. Dokumentieren Sie, welchen Normen Sie gefolgt sind, und erklären Sie für Bereiche ohne harmonisierte Normen, wie Sie die gesetzlichen Anforderungen direkt aus dem Text der Artikel 8-15 erfüllt haben.

Abschnitt 8: EU-Konformitätserklärung

• Eine Kopie der EU-Konformitätserklärung nach Artikel 47

Dieser Abschnitt wird am Ende des Konformitätsbewertungsverfahrens ausgefüllt. Die Erklärung verweist auf das System, den Anbieter, die verwendeten harmonisierten Normen oder sonstigen Spezifikationen und das durchlaufene Konformitätsbewertungsverfahren.

Abschnitt 9: System zur Marktbeobachtung

• Das System zur Marktbeobachtung nach Artikel 72
• Wie Leistungsdaten nach dem Einsatz erhoben und ausgewertet werden
• Schwellen und Auslöser für Korrekturmaßnahmen
• Verfahren zur Meldung von Vorfällen nach Artikel 73

Beispiel Kreditwürdigkeitsprüfung: "Leistungsüberwachung: automatisierte wöchentliche Berechnung von AUC-ROC, FPR und FNR auf einem rollierenden 90-Tage-Fenster von Produktionsentscheidungen, aufgeschlüsselt nach Untergruppe. Alarmschwellen: Fällt der AUC-ROC einer Untergruppe unter 0,80, wird innerhalb von 48 Stunden eine Untersuchung ausgelöst. Fällt der Gesamt-AUC-ROC unter 0,83, wird das System für ein Nachtraining gekennzeichnet. Rückkopplungsschleife: Die Einsatzpartner berichten vierteljährlich über die tatsächlichen Ausfallraten für KI-bewertete Anträge, was ein Backtesting der Vorhersagen ermöglicht. Meldung von Vorfällen: Das Team für die Marktbeobachtung meldet schwerwiegende Vorfälle innerhalb von 15 Tagen gemäß Artikel 73 an die zuständige Marktüberwachungsbehörde."

Praxisszenarien für die Dokumentation

Szenario 1: Medizinprodukt-KI (Radiologie)

Ein Anbieter eines KI-Systems, das Radiologen beim Erkennen von Lungenrundherden auf CT-Aufnahmen unterstützt (Hochrisiko nach Anhang III Nummer 1 und möglicherweise nach der Medizinprodukteverordnung), steht vor den anspruchsvollsten Dokumentationsanforderungen. Eine Drittbewertung durch eine benannte Stelle ist wahrscheinlich erforderlich. Abschnitt 2 muss detaillierte Beschreibungen des Trainingsdatensatzes (Zehntausende annotierter Aufnahmen), der Übereinstimmung zwischen den Kennzeichnern (Inter-Rater-Reliabilität) und der Leistung aufgeschlüsselt nach Rundherd-Größe, Patientendemografie und Scanner-Hersteller enthalten. Abschnitt 5 muss das Risiko übersehener Befunde (Falsch-negative) und Fehlalarme (Falsch-positive) mit konkreter Quantifizierung des Restrisikos behandeln.

Szenario 2: HR-Screening-Tool (Recruiting)

Ein HR-Technologieunternehmen, das ein KI-System zum Filtern von Bewerbungen anbietet (Hochrisiko nach Anhang III Nummer 4(a)), muss in Abschnitt 2 dokumentieren, wie die Trainingsdaten kuratiert wurden, um historische Einstellungsverzerrungen nicht einzucodieren. Abschnitt 3 muss die Genauigkeit aufgeschlüsselt nach Geschlecht, Alter, ethnischer Herkunft und Behinderungsstatus angeben. Abschnitt 5 muss Risiken behandeln, darunter indirekte Diskriminierung über Proxy-Merkmale (Name der Universität als Proxy für den sozioökonomischen Status, Lücken im Lebenslauf als Proxy für Betreuungsaufgaben). Abschnitt 9 muss beschreiben, wie der Anbieter überwacht, ob die Empfehlungen des Systems im Betrieb zu ungleichen Ergebnissen über geschützte Gruppen hinweg führen.

Szenario 3: Überwachung kritischer Infrastruktur

Ein Anbieter eines KI-Systems, das die Stabilität des Stromnetzes überwacht und automatisierte Lastabwurf-Entscheidungen auslöst (Hochrisiko nach Anhang III Nummer 2), muss in Abschnitt 1 die Interaktion des Systems mit SCADA-Systemen und Netzhardware dokumentieren. Abschnitt 2 muss die für Tests genutzten Simulationsumgebungen abdecken, da Tests am laufenden Netz nicht praktikabel sind. Abschnitt 5 muss Risiken kaskadierender Ausfälle behandeln, einschließlich Szenarien, in denen die KI fälschlich einen Lastabwurf auslöst und ungeplante Ausfälle verursacht, die Krankenhäuser und Rettungsdienste treffen.

Häufige Fallstricke und wie Sie sie beheben

Fallstrick 1: Dokumentation nachträglich schreiben

Der AI Act verlangt, dass die Dokumentation während der Entwicklung erstellt wird, nicht nachdem das System fertig ist. Wurden Designentscheidungen, die Wahl der Trainingsdaten und Testergebnisse nicht zeitnah dokumentiert, ist die Rekonstruktion schwerer und für einen Bewerter weniger glaubwürdig.

Lösung: Beginnen Sie ab dem ersten Tag mit einem Dokumentations-Log. Halten Sie wichtige Entscheidungen, Datensatzbeschreibungen und Testergebnisse in Echtzeit fest. Bauen Sie Dokumentationsaufgaben in Ihren Sprint oder Entwicklungszyklus ein.

Fallstrick 2: Dokumentation als einmalige Lieferung behandeln

Die Anhang-IV-Dokumentation ist ein lebendiges Dokument. Sie muss über den Lebenszyklus des KI-Systems hinweg aktuell gehalten werden. Jede wesentliche Änderung, ein Modell-Update, ein neuer Trainingsdatensatz, eine geänderte Zweckbestimmung, löst ein Dokumentations-Update aus.

Lösung: Koppeln Sie Dokumentations-Updates an Ihre CI/CD-Pipeline. Jedes Release, das das Modellverhalten ändert, sollte eine Dokumentationsprüfung auslösen. Nutzen Sie Versionskontrolle (Git) für die Dokumentation parallel zum Code.

Fallstrick 3: Geerbte Einschränkungen von Drittkomponenten ignorieren

Wenn Ihr System ein vortrainiertes Modell, einen Datensatz eines Dritten oder eine externe API nutzt, müssen Sie die von diesen Komponenten geerbten Einschränkungen und Risiken dokumentieren. "Wir haben GPT-4 für die Embedding-Schicht verwendet" reicht nicht.

Lösung: Fordern Sie technische Dokumentation oder Model Cards von Ihren Lieferanten an. Dokumentieren Sie, was Sie wissen und was Sie nicht wissen. Kann ein Lieferant keine ausreichende Dokumentation liefern, dokumentieren Sie diese Lücke und erklären Sie Ihre Minderungsstrategie.

Fallstrick 4: Vage oder nur aggregierte Genauigkeitsangaben

"Das System erreicht 95 % Genauigkeit" erfüllt den Anhang-IV-Standard nicht. Sie müssen angeben:

• Die verwendete Kennzahl (Precision, Recall, F1, AUC-ROC usw.)
• Den Datensatz, auf dem sie gemessen wurde
• Die Bevölkerungssegmente, für die sie gemessen wurde (aufgeschlüsselte Leistung)
• Bekannte Fehlermodi und Leistungseinbrüche unter bestimmten Bedingungen

Lösung: Berichten Sie die Leistung aufgeschlüsselt über alle relevanten Untergruppen. Dokumentieren Sie die verwendeten Datensätze, Bedingungen und Schwellen. Sagen Sie klar, wo die Leistung nachlässt.

Fallstrick 5: Fehlende Cybersicherheits-Dokumentation

Viele Teams dokumentieren die funktionale Leistung, vernachlässigen aber die Cybersicherheit. Artikel 15 verlangt eine konkrete Dokumentation der Maßnahmen gegen Data Poisoning, Model Poisoning, adversarielle Eingaben und unbefugten Zugriff.

Lösung: Erstellen Sie ein Bedrohungsmodell, das speziell auf KI-Schwachstellen zugeschnitten ist. Dokumentieren Sie jede Bedrohung, die Minderungsmaßnahmen und das Restrisiko. Das ist etwas anderes als Ihre allgemeine IT-Sicherheitslage.

Fallstrick 6: Keine Versionskontrolle oder Prüfspur

Bewerter suchen nach Belegen, dass sich die Dokumentation zusammen mit dem System entwickelt hat. Ein einzelnes, undatiertes Word-Dokument ohne Änderungshistorie ist ein Warnsignal.

Lösung: Speichern Sie die Dokumentation in versionskontrollierten Repositories. Nutzen Sie mit Zeitstempel versehene Commits. Führen Sie ein Änderungsprotokoll für jede größere Überarbeitung der Dokumentation.

Erleichterungen für KMU nach Artikel 11(2)

Artikel 11(2) erlaubt KMU und Startups ausdrücklich, die Anhang-IV-Elemente in vereinfachter Form bereitzustellen. Die Europäische Kommission ist beauftragt, ein vereinfachtes Formular für die technische Dokumentation zu erstellen, das auf die Bedürfnisse von Klein- und Kleinstunternehmen zugeschnitten ist.

Stand April 2026 hat die Kommission dieses Formular noch nicht veröffentlicht. Der praktische Ansatz für die Zwischenzeit:

1. Alle neun Abschnitte abdecken, die Vereinfachung betrifft die Tiefe, nicht den Umfang.
2. Detailtiefe an die Systemkomplexität anpassen, ein einfaches Klassifizierungs-Tool braucht nicht dieselbe Tiefe wie ein medizinisches KI-Diagnosesystem.
3. Substanz vor Länge stellen, Bewerter prüfen, ob Sie die Anforderungen behandelt haben, nicht die Seitenzahl.
4. Dokumentieren, was Sie wirklich wissen, es ist besser zu schreiben "wir haben auf einem Datensatz von 5.000 Datensätzen getestet und X gefunden", als aufwendige Testerzählungen zu erfinden.

Beispiel: Ein fünfköpfiges Startup, das ein KI-System zur Priorisierung von Support-Tickets anbietet (Hochrisiko, wenn in wesentlichen Diensten eingesetzt), kann seinen Entwicklungsprozess auf 15-20 Seiten dokumentieren statt auf den 80+ Seiten, die ein großer Anbieter medizinischer KI vielleicht braucht, solange jeder Anhang-IV-Abschnitt mit ehrlichen, konkreten Informationen behandelt wird.

Dokumentation als lebendiges Dokument

Die Anhang-IV-Dokumentation ist keine Lieferung, die Sie abschließen und archivieren. Der AI Act verlangt, dass sie über den Lebenszyklus des Systems hinweg gepflegt wird. Auslöser für Updates sind unter anderem:

• Nachtraining oder Fine-Tuning des Modells, aktualisieren Sie die Abschnitte 2, 4 und 5.
• Neue Trainingsdaten, aktualisieren Sie die Abschnitte 2 und 5.
• Geänderte Zweckbestimmung oder geänderter Einsatzkontext, aktualisieren Sie die Abschnitte 1, 3 und 5.
• Neu identifizierte Risiken, aktualisieren Sie Abschnitt 5.
• Erkannte Leistungsverschlechterung, aktualisieren Sie die Abschnitte 4 und 9.
• Veröffentlichte Regulierungshinweise oder harmonisierte Normen, aktualisieren Sie Abschnitt 7.
• Vorfälle nach dem Inverkehrbringen, aktualisieren Sie die Abschnitte 5 und 9.

Legen Sie einen Prüfrhythmus fest: mindestens vierteljährlich oder ausgelöst durch eines der oben genannten Ereignisse.

Praktische Tipps zu Werkzeugen und Versionskontrolle

Dokumentation, die in verstreuten Word-Dokumenten über E-Mail-Threads lebt, übersteht keine Konformitätsbewertung. Praktische Ansätze früher Anwender:

1. Docs-as-Code: Speichern Sie die Dokumentation in Markdown oder reStructuredText neben Ihrer Codebasis, versioniert in Git. Jede Dokumentationsänderung ist ein Commit mit Zeitstempel und Autor.
2. Strukturierte Vorlagen: Nutzen Sie eine einheitliche Vorlage, die die neun Anhang-IV-Abschnitte abbildet. Das sichert Vollständigkeit und macht die Prüfung durch den Bewerter einfach.
3. Automatisierte Datenerfassung: Ziehen Sie Trainings-Metadaten, Testergebnisse und Leistungskennzahlen direkt aus Ihrer ML-Pipeline in Ihre Dokumentationsvorlagen. Werkzeuge wie MLflow, Weights & Biases oder DVC können einen Großteil von Abschnitt 2 und Abschnitt 4 automatisieren.
4. Review-Workflows: Verlangen Sie eine Freigabe für Dokumentationsänderungen, ähnlich wie beim Code Review. Das schafft eine Prüfspur, die zeigt, wer was wann freigegeben hat.
5. Single Source of Truth: Vermeiden Sie es, Informationen über Systeme hinweg zu duplizieren. Liegt Ihr Risikoregister in einem GRC-Tool, verweisen Sie aus der Dokumentation darauf, statt es zu kopieren.

Vorbereitungs-Checkliste

Nutzen Sie diese Liste, um Ihre Bereitschaft vor Beginn der formalen Dokumentation zu prüfen:

• Systembeschreibung und Zweckbestimmung präzise definiert
• Architekturdiagramme und Komponentenverzeichnis vorbereitet
• Alle Drittkomponenten identifiziert und Lieferantendokumentation eingeholt
• Quellen der Trainingsdaten, Auswahlkriterien und Bereinigungsmethoden dokumentiert
• Bias-Bewertung der Trainings- und Testdaten mit aufgeschlüsselten Ergebnissen abgeschlossen
• Maßnahmen zur menschlichen Aufsicht spezifiziert und getestet
• Genauigkeitskennzahlen mit aufgeschlüsselten Leistungsdaten über relevante Untergruppen definiert
• KI-spezifisches Cybersicherheits-Bedrohungsmodell mit dokumentierten Minderungen abgeschlossen
• Risikomanagement-Prozess mit Iterationsnachweis über den Entwicklungslebenszyklus dokumentiert
• Testpläne, Testergebnisse und Testberichte mit Datum und Unterschrift archiviert
• Plan zur Marktbeobachtung mit Schwellen und Auslösern entworfen
• Verfahren zu Änderungsmanagement und Versionskontrolle definiert
• Dokumentation in versionskontrolliertem Repository mit Prüfspur gespeichert
• Anwendbarkeit der KMU-Vereinfachung geprüft (falls relevant)

Zeit- und Ressourcenschätzungen nach Systemkomplexität

Diese Zahlen setzen voraus, dass Designentscheidungen von Anfang an dokumentiert wurden. Nachträgliche Dokumentation, das Rekonstruieren von Entscheidungen, Testergebnissen und Datenherkunft im Nachhinein, ist durchweg der teuerste und fehleranfälligste Weg.

Bezug zur Konformitätsbewertung

Technische Dokumentation ist kein Selbstzweck, sie ist der zentrale Input für die Konformitätsbewertung. Der Zusammenhang ist direkt:

• Selbstbewertung (Anhang VI): Ihr internes Qualitätsmanagement-System prüft die Dokumentation gegen die Artikel 8-15. Ist die Dokumentation unvollständig, kann die Selbstbewertung nicht bestehen.
• Bewertung durch eine benannte Stelle (Anhang VII): Die benannte Stelle prüft Ihre Dokumentation im Detail. Rechnen Sie mit Rückfragen, Bitten um Klarstellung und Folge-Audits. Die Qualität Ihrer Dokumentation bestimmt Tempo und Kosten der Bewertung.
• Konformitätserklärung (Artikel 47): Sie können die Erklärung nicht unterzeichnen ohne abgeschlossene Konformitätsbewertung, und Sie können die Konformitätsbewertung nicht abschließen ohne vollständige Dokumentation.

Nächste Schritte

1. Stufen Sie Ihr KI-System ein, um zu bestätigen, ob eine Anhang-IV-Dokumentation erforderlich ist.
2. Prüfen Sie den vollständigen Text von Anhang IV für die genauen gesetzlichen Anforderungen.
3. Nutzen Sie die obige Checkliste, um Ihre aktuellen Dokumentationslücken zu prüfen.
4. Beginnen Sie mit Abschnitt 1 (allgemeine Beschreibung) und Abschnitt 2 (Entwicklungsprozess), diese sind am zeitintensivsten.
5. Prüfen Sie die vollständige Compliance-Checkliste, um zu sehen, wie die Dokumentation in das breitere Compliance-Programm passt.

Führen Sie die kostenlose AI-Act-Bewertung durch, um die Risikoeinstufung und die Dokumentationspflichten Ihres Systems zu bestätigen.

Den vollständigen Gesetzestext finden Sie im kompletten AI-Act-Leitfaden.

Häufig gestellte Fragen

Wie detailliert muss die Anhang-IV-Dokumentation sein?

Detailliert genug, damit ein Bewerter, ob intern oder eine benannte Stelle, überprüfen kann, dass Ihr System jede Anforderung der Artikel 8-15 erfüllt, ohne Ihnen Zusatzfragen stellen zu müssen. Der Maßstab ist keine Seitenzahl, sondern Vollständigkeit und Konkretheit. Ein 30-seitiges Dokument, das jeden Abschnitt mit konkreten Belegen behandelt, ist besser als ein 100-seitiges Dokument in generischer Sprache. Der entscheidende Test: Könnte ein qualifizierter Bewerter, der Ihr System noch nie gesehen hat, allein aus der Dokumentation verstehen, wie es funktioniert, welche Risiken es birgt und wie Sie diese gemindert haben?

Kann ich Dokumentation aus ISO oder anderen Frameworks wiederverwenden?

Teilweise. Bestehende Dokumentation aus ISO 42001 (KI-Managementsysteme), ISO 27001 (Informationssicherheit) oder IEC 62304 (Software für Medizinprodukte) kann Bausteine liefern, aber keine dieser Normen bildet alle neun Anhang-IV-Abschnitte direkt ab. Nutzen Sie bestehendes Material dort, wo es dieselben Themen behandelt, aber seien Sie bereit, Lücken zu füllen, besonders bei KI-spezifischen Anforderungen wie aufgeschlüsselten Leistungskennzahlen, Bias-Bewertungen und KI-spezifischen Cybersicherheits-Bedrohungen (Data Poisoning, adversarielle Beispiele).

Was, wenn mein System ein vortrainiertes Modell nutzt und der Lieferant keine vollständige Dokumentation teilt?

Dokumentieren Sie, was der Lieferant bereitgestellt hat (Model Card, Datenblatt, Leistungs-Benchmarks), was Sie angefragt, aber nicht erhalten haben, und wie Sie die daraus entstehenden Dokumentationslücken behandelt haben. Führen Sie eine eigene Bewertung der Modellleistung in Ihrem Einsatzkontext durch. Dokumentieren Sie die geerbten Risiken und Ihre Minderungsstrategie. Ein Bewerter prüft, ob Ihr Vorgehen angesichts der verfügbaren Informationen angemessen ist, aber ein vollständiges Fehlen von Lieferantendokumentation ist ein erheblicher Risikofaktor, der ausdrücklich behandelt werden muss.

Muss die Dokumentation in einer bestimmten Sprache verfasst sein?

Die Dokumentation muss in einer Amtssprache des Mitgliedstaats verfasst sein, in dem das System in Verkehr gebracht oder in Betrieb genommen wird. In der Praxis wird Englisch von Marktüberwachungsbehörden in der ganzen EU weithin akzeptiert, klären Sie das aber mit der zuständigen nationalen Behörde. Wenn Sie in mehreren Mitgliedstaaten tätig sind, brauchen Sie möglicherweise Übersetzungen wesentlicher Abschnitte.

Wie oft muss die Anhang-IV-Dokumentation aktualisiert werden?

Der AI Act nennt keinen festen Zeitplan. Die Anforderung ist, dass die Dokumentation über den Lebenszyklus des Systems hinweg "aktuell gehalten" wird. In der Praxis sollten Updates durch jede wesentliche Änderung am System (Nachtraining, neue Daten, neuer Einsatzkontext, festgestellte Vorfälle), durch jede neue Risikoinformation und in regelmäßigen Prüfintervallen (vierteljährlich ist eine sinnvolle Basis) ausgelöst werden. Jedes Update sollte versionskontrolliert mit einem klaren Änderungsprotokoll erfolgen.

Welche Sanktionen drohen bei unzureichender technischer Dokumentation?

Unzureichende Dokumentation von Hochrisiko-KI-Systemen fällt unter die allgemeine Kategorie der Hochrisiko-Verstöße und kann Bußgelder von bis zu 15 Millionen EUR oder 3 % des weltweiten Jahresumsatzes nach sich ziehen, je nachdem, welcher Betrag höher ist. Für KMU gilt der niedrigere Betrag. Über die Bußgelder hinaus ist die praktische Folge, dass Sie die Konformitätsbewertung nicht abschließen können, was bedeutet, dass Sie das System nicht rechtmäßig auf dem EU-Markt in Verkehr bringen dürfen. Die vollständige Aufschlüsselung finden Sie im Leitfaden zu Sanktionen und Bußgeldern.

Legalithm ist ein KI-gestütztes Compliance-Workflow-Tool, keine Rechtsberatung. Endgültige Compliance-Entscheidungen sollten von qualifiziertem Rechtsbeistand geprüft werden.