Wann technische Dokumentation gilt und was als Nächstes zu tun ist

Die technische Dokumentation ist eine konkrete Pflicht des EU AI Act, wenn ein Unternehmen Anbieter eines Hochrisiko-KI-Systems ist. Artikel 11 verlangt, dass sie vor dem Inverkehrbringen oder der Inbetriebnahme erstellt, aktuell gehalten und so klar verfasst wird, dass Behörden und notifizierte Stellen die Konformität prüfen können. Anhang IV legt die Mindestinhalte fest.

Nicht jedes SaaS-Unternehmen, das eine KI-API nutzt, benötigt deshalb eine vollständige Anhang-IV-Akte. Entscheidend sind Systemgrenze, Rolle des Unternehmens und Hochrisiko-Einstufung. Auch ohne direkte Pflicht kann eine angemessene Systemakte Produktsteuerung, Anbieterprüfung, Kundenanfragen und spätere Neubewertungen unterstützen.

Zuerst System, Rolle und Einstufung klären

Beschreiben Sie das gesamte System: Zweck, Nutzer, betroffene Personen, Ein- und Ausgaben, Schnittstellen, Nutzungskontext und Einfluss der Ausgabe auf Entscheidungen. Ein fremdes Modell kann nur ein Bestandteil des SaaS-Systems sein.

Bestimmen Sie danach die Rolle. Wer ein Hochrisiko-System entwickelt und unter eigenem Namen vermarktet, ist regelmäßig Anbieter; ein Kunde kann lediglich Betreiber sein. Umbenennung, wesentliche Änderung oder ein geänderter Zweck können Pflichten verschieben. Prüfen Sie schließlich die beiden Hauptrouten des Artikels 6: Systeme in regulierten Produkten nach Anhang I und Anwendungsfälle nach Anhang III. Der Überblick für SaaS-Anbieter erläutert diese Grundlagen.

Wann Artikel 11 gilt

Artikel 11 und Anhang IV gelten für die technische Dokumentation von Hochrisiko-KI-Systemen; die Kernpflicht liegt beim Anbieter. Nach der Verordnung (EU) 2026/1744 gelten die Hochrisiko-Regeln für Anhang-III-Systeme ab 2. Dezember 2027 und für in Anhang-I-Produkte eingebettete Systeme ab 2. August 2028.

Teams sollten nicht bis dahin warten. Produktrecht, Datenschutz, Verträge, Sicherheitskontrollen oder Kundenprüfungen können bereits ähnliche Nachweise verlangen. Frühzeitiges Arbeiten verhindert, dass Versionen, Datensätze, Tests und Entscheidungen später rekonstruiert werden müssen.

Ist das System nicht hochriskant oder das Unternehmen nur Betreiber, kann eine vollständige Akte rechtlich entbehrlich sein. Halten Sie trotzdem Entscheidung, Fakten, Prüfer und Neubewertungsauslöser fest. Neue Zwecke, sensible Nutzung, wesentliche Modell- oder Datenänderungen, neue Märkte oder ein veränderter Einfluss auf Personen lösen eine neue Prüfung aus.

Was die Akte abdecken muss

Anhang IV verlangt mindestens:

1. Identität, Zweck, Versionen, Nutzer und Betriebsbedingungen des Systems.
2. Entwicklungsmethoden, Architektur, Komponenten und wichtige Designentscheidungen.
3. Datenherkunft, Validierung, Tests und relevante Leistungsgrenzen.
4. Risiken, Kontrollen, menschliche Aufsicht, Protokollierung und Eskalation.
5. Robustheit, Cybersicherheit und vorhersehbare unerwünschte Ergebnisse.
6. Änderungsmanagement, Vorfälle und Marktbeobachtung.
7. Standards, Konformitätsweg und erforderliche Freigaben.
8. Rückverfolgbarkeit jeder Aussage zu einem kontrollierten Nachweis.

Die Akte darf als Index auf kontrollierte Quellen verweisen. Sie muss nicht jedes Diagramm, Testergebnis und Ticket duplizieren. Stabile Links, Berechtigungen, Versionen und Aufbewahrung sind wichtiger als Seitenzahl.

Praktischer Ablauf

1. Umfang freigeben: stabile Systemkennung, Zweck, Grenze, Rolle, Einstufung und Annahmen dokumentieren.
2. Abdeckungsindex erstellen: für jedes Element Quelle, Eigentümer, Version, Status, Prüfer und Aktualisierungsauslöser festhalten.
3. Nachweise bei den Fachverantwortlichen belassen: Produkt verantwortet Zweck, Engineering Architektur, Daten- oder ML-Teams Bewertungen, Security Schutzmaßnahmen und Compliance die Zuordnung.
4. Wesentliche Lücken zuerst schließen: Einstufung, Leistungsangaben, Risiken, Aufsicht und Release-Freigabe priorisieren.
5. Änderungen koppeln: Änderungen an Zweck, Modell, Daten, Schwellenwerten, Nutzern, Integrationen oder Kontrollen müssen gezielte Aktualisierung und gegebenenfalls neue Tests auslösen.
6. Abruf testen: Ein unabhängiger Prüfer sollte eine Leistungsangabe, eine Risikokontrolle, einen Aufsichtspfad und ein Release anhand der Quellen nachvollziehen können.

Die Checkliste zur technischen Dokumentation bietet eine ausführliche Prüfstruktur. Kundenantworten sollten außerdem zu den zunehmend verlangten KI-Kontrollen passen.

Häufige Fehler

• Mit einer allgemeinen Vorlage beginnen, bevor Umfang und Nachweise feststehen.
• Nur das Modell statt des gesamten Systems dokumentieren.
• Lieferantenunterlagen als Beleg für die eigene Konfiguration übernehmen.
• Eine Nicht-Hochrisiko-Einstufung niemals erneut prüfen.
• Eine Audit-Akte führen, die nicht mit Release- und Änderungsmanagement verbunden ist.

Beispiel: KI-gestützte Bewerberauswahl

Bei einer Funktion, die Bewerbungen für Recruiter ordnet, muss das Team Zweck, Anbieter, Systemgrenze und Anhang-III-Einstufung bestimmen. Ist das Unternehmen Anbieter eines Hochrisiko-Systems, umfasst die Akte Produktionsversionen, Eingabedaten, Workflow, Gruppenbewertungen, Kennzahlen, Grenzen, menschliche Prüfung, Protokollierung, Sicherheit und Monitoring. Ein Modell- oder Schwellenwertwechsel muss die verbundenen Leistungs-, Risiko-, Aufsichts- und Anleitungseinträge erneut öffnen.

FAQ

Wann gilt die Pflicht für SaaS-Teams?

Artikel 11 gilt für Anbieter von Hochrisiko-KI-Systemen. Klären Sie Systemgrenze, Rolle und Einstufung, bevor Sie eine vollständige Anhang-IV-Akte als gesetzlich erforderlich behandeln.

Was sollte zuerst dokumentiert werden?

Zweck, Systemgrenze, Rolle, Einstufung, Produktionsversion, Architektur, wesentliche Risiken, Bewertungen, Kontrollen, Anweisungen und Verantwortliche.

Dürfen vorhandene Engineering-Unterlagen wiederverwendet werden?

Ja. Verweisen Sie auf kontrollierte, aktuelle Quellen und zeigen Sie im Index, welche Anforderung und Version sie abdecken.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 6 und 11 sowie Anhänge I, III und IV.
• Verordnung (EU) 2026/1744 zu Dokumentation und Anwendungszeitplan.
• Europäische Kommission, „AI Act“, aktueller Umsetzungszeitplan.