Checkliste zur technischen Dokumentation

Eine wirksame technische Dokumentation deckt die Anforderungen des EU AI Act ab und macht jede Aussage bis zur Systemversion und zum stützenden Nachweis rückverfolgbar. Anbieter eines Hochrisiko-KI-Systems müssen die Dokumentation vor dem Inverkehrbringen oder der Inbetriebnahme erstellen, aktuell halten und so verständlich gestalten, dass Behörden und notifizierte Stellen die Konformität beurteilen können.

Artikel 11 und Anhang IV bilden die Grundstruktur. Die Verordnung (EU) 2026/1744 behält Anhang IV als Mindestmaßstab bei, erlaubt KMU einschließlich Start-ups sowie kleinen Midcap-Unternehmen aber ein vereinfachtes Kommissionsformular, sobald es verfügbar ist. Die Darstellung wird vereinfacht, nicht die Pflicht, die Konformität zu belegen. Die Checkliste richtet sich an Anbieter; Käufer oder Betreiber können andere Pflichten haben. Klären Sie daher zuerst Systemgrenze, Rolle und Einstufung.

Umfang und Kontrolle

• [ ] Stabile Systemkennung, Anbieter und abgedeckte Produktionsversion festhalten.
• [ ] Zweck, Nutzer, betroffene Personen, Einsatzkontext und ausgeschlossene Nutzungen beschreiben.
• [ ] Rolle und Hochrisiko-Einstufung mit Bezug auf Anhang I oder III begründen.
• [ ] Einen Gesamtverantwortlichen und für jeden Nachweis einen fachlichen Eigentümer benennen.
• [ ] Einen Abdeckungsindex mit Anforderung, Quelle, Version, Status, Prüfer und Aktualisierungsauslöser anlegen.

Beginnen Sie mit dem Index statt mit einer allgemeinen Vorlage. Er zeigt fehlende Nachweise und verhindert, dass Text und Produkt auseinanderlaufen.

System, Entwicklung und Architektur

• [ ] Zweck, Anbieter, Versionen, Bereitstellungsformen und Betriebsbedingungen dokumentieren.
• [ ] Hardware, Software, Firmware, Schnittstellen, Abhängigkeiten und externe KI-Komponenten erfassen.
• [ ] Architektur, Entwicklungsmethoden, Designentscheidungen und Drittleistungen versioniert sichern.
• [ ] Datenbeschaffung, Aufbereitung, Kennzeichnung, Qualität und Governance beschreiben, soweit relevant.
• [ ] Ausgaben, Grenzen, erwartete Qualität und Wirkung auf Entscheidungen erläutern.
• [ ] Entwicklungsänderungen und das Verfahren für spätere Änderungen nachweisen.

Diagramme benötigen Datum und Version. Lieferantenunterlagen ersetzen keinen Nachweis darüber, wie die eigene Konfiguration funktioniert.

Leistung, Risiken und Kontrollen

• [ ] Fähigkeiten, Einschränkungen, Genauigkeit, Robustheit und Cybersicherheit angeben.
• [ ] Metriken, Schwellenwerte, Testdaten, Testbedingungen, Ergebnisse und bekannte Ausschlüsse sichern.
• [ ] Vorhersehbare Risiken für Gesundheit, Sicherheit und Grundrechte bewerten.
• [ ] Kontrollen, Restrisiko, Verantwortliche und befugte Risikoakzeptanz dokumentieren.
• [ ] Menschliche Aufsicht, Warnungen, Eingriffsmöglichkeiten und Eskalationen beschreiben.
• [ ] Protokollierung, Aufbewahrung, Zugriff und Rückverfolgbarkeit erklären.
• [ ] Die Anforderungen der Artikel 8 bis 15 mit Kontrollen und Nachweisen verknüpfen.

Eine Prozentangabe zur Genauigkeit ist ohne Aufgabe, Population, Datensatzversion, Metrik und Testdatum unvollständig. Der Risikoeintrag erklärt die Entscheidung; Tests, Freigaben, Anweisungen und Logs belegen ihre Umsetzung.

Konformität und Lebenszyklus

• [ ] Angewandte harmonisierte Normen oder technische Spezifikationen mit Ausgabe und Umfang nennen.
• [ ] Abweichungen und alternative Nachweise begründen.
• [ ] Konformitätsbewertung, EU-Konformitätserklärung und gegebenenfalls notifizierte Stelle erfassen.
• [ ] Änderungen chronologisch führen und je Release die Übereinstimmung mit der Produktion bestätigen.
• [ ] Nachmarktbeobachtung, Beschwerden, Vorfälle, Drift und Korrekturmaßnahmen nachweisen.
• [ ] Lieferantenänderungen, Rücknahme, Rollback und Aufbewahrung als Prüfauslöser definieren.

Bei jeder wesentlichen Änderung sollte geprüft werden, ob Zweck, Einstufung, Daten, Architektur, Leistung, Risiken, Kontrollen, Anweisungen, Aufsicht oder Monitoring betroffen sind. Ist das der Fall, müssen gezielte Aktualisierungen vor dem Release abgeschlossen werden.

Abschließende Qualitätskontrolle

• [ ] Jede Aussage hat eine kontrollierte Quelle oder ist ausdrücklich als Analyse gekennzeichnet.
• [ ] Versionskennungen stimmen in Architektur, Tests, Risiken, Anweisungen und Release-Nachweisen überein.
• [ ] Offene Lücken haben Eigentümer, Zwischenkontrolle, Risikodecision und Frist.
• [ ] Links funktionieren und Prüfer besitzen angemessenen Zugriff.
• [ ] Eine unabhängige Person kann die wesentlichen Schlussfolgerungen anhand des Index nachvollziehen.

Technische Dokumentation betrifft das gesamte System im vorgesehenen Kontext, nicht nur das Modell. Richtlinien allein sind kein Umsetzungsnachweis, und die Akte ist mit dem Launch nicht fertig. Testen Sie den Prozess an einem echten Release und verfolgen Sie Änderungen sowie Nachmarkt-Signale laufend.

Häufige Fragen

Wann gilt die Pflicht für SaaS-Teams?

Artikel 11 gilt für Anbieter von Hochrisiko-KI-Systemen. Ein SaaS-Unternehmen kann stattdessen Betreiber sein oder keine Hochrisiko-KI einsetzen. Freiwillige Dokumentation bleibt für Governance und Kundenprüfungen sinnvoll, sollte aber nicht als gesetzliche Pflicht ausgegeben werden.

Wann gelten die Hochrisiko-Regeln?

Nach der Verordnung (EU) 2026/1744 gelten die betreffenden Regeln für eigenständige Systeme nach Anhang III ab 2. Dezember 2027 und für in Produkte nach Anhang I integrierte Systeme ab 2. August 2028. Prüfen Sie stets die für das konkrete System geltenden Übergangsregeln.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 9, 11, 16–18 und 72 sowie Anhang IV.
• Verordnung (EU) 2026/1744, insbesondere die Änderung von Artikel 11 und die Anwendungstermine.
• Europäische Kommission, „Navigating the AI Act“.