Welche Dokumentationspflichten gelten für Hochrisiko-KI nach dem AI Act?
Kurz gesagt
Anbieter von Hochrisiko-KI müssen nach Art. 17 AI Act ein Qualitätsmanagementsystem dokumentieren und betreiben, ein kontinuierliches Risikomanagement nach Art. 9 nachweisen und technische Dokumentation, Logs sowie Human-Oversight-Nachweise vorhalten. Betreiber tragen eigene, meist schlankere Pflichten. Der genaue Anwendungszeitpunkt hängt nach dem AI Omnibus von der jeweiligen Hochrisiko-Kategorie ab und muss laufend geprüft werden.
Erst die Rolle bestimmen, dann die Pflicht
Der AI Act unterscheidet Rollen: Anbieter (Provider), Betreiber (Deployer), Einführer und Händler eines KI-Systems tragen unterschiedliche Pflichten. Ein Unternehmen kann durch wesentliche Änderung, Fine-Tuning oder Rebranding eines Systems selbst zum Anbieter werden — dieser Rollenwechsel hängt von der konkreten Handlung ab und ist am Recherchestand teils noch nicht abschließend geklärt. Die erste praktische Frage ist deshalb nicht "sind wir hochrisiko", sondern "welche Rolle haben wir für dieses konkrete System".
Was Anbieter von Hochrisiko-KI dokumentieren müssen
Für Anbieter sind zentral:
- Qualitätsmanagementsystem (Art. 17): ein dokumentiertes System, das Prozesse für Entwicklung, Prüfung, Freigabe und Nachverfolgung von Hochrisiko-KI regelt. Der genaue Anwendungszeitpunkt kann je nach Hochrisiko-Kategorie nach dem AI Omnibus variieren.
- Risikomanagement (Art. 9): kein einmaliger Pre-Launch-Fragebogen, sondern ein kontinuierlicher, iterativer Prozess über den gesamten Lebenszyklus — von Entwicklung über Betrieb bis Stilllegung.
- Technische Dokumentation: Angaben zu Zweck, Architektur, Daten, Leistung, Grenzen und Testverfahren, adressatengerecht für Entwickler, Prüfende und Aufsichtsbehörden.
- Logs: nachvollziehbare Protokollierung, die zweckgebunden, zugriffsgeschützt und mit klaren Aufbewahrungsregeln versehen ist. Mehr Logging ist dabei nicht automatisch besser — unstrukturierte Logs ohne Auswertbarkeit erfüllen den Nachweiszweck nicht.
- Human-Oversight-Nachweis: dokumentierte Entscheidungsgrenzen, Kompetenzanforderungen und Eingriffsmöglichkeiten der prüfenden Person.
Was für Betreiber gilt
Betreiber von Hochrisiko-KI haben eigene, in der Regel schlankere Pflichten — etwa zur bestimmungsgemäßen Nutzung, zur Überwachung im Betrieb, zur Sicherstellung geeigneter Human Oversight und zur Weitergabe relevanter Informationen an den Anbieter. Ein Lieferantenzertifikat oder eine Vertragsklausel des Anbieters ersetzt diese eigene Prüfung nicht: Sie ersetzt weder die Prüfung des konkreten Anwendungsfalls noch die Kontrolle der eigenen Datenflüsse, Vertragsbedingungen und Betreiberpflichten.
Die Systemakte als zentrales Nachweisdokument
In der Praxis bewährt sich eine zusammenhängende Systemakte, die Stammdaten, Rollen, Klassifikation, Datenfluss, Vendor-Nachweise, Risiken, Kontrollen, Tests, Freigaben, Schulungsnachweise, Monitoring, Incidents und Changes verknüpft. Nachweise brauchen dabei immer Scope, Systemversion, Datum, Owner und Status — ein aktueller Testbericht für ein Modell belegt nicht automatisch eine andere Version oder eine neue RAG-Konfiguration desselben Systems.
Was ein Zertifikat nicht beweist
Eine Zertifizierung nach ISO/IEC 42001 oder ein Lieferantenzertifikat kann Reife und Auditierbarkeit belegen, beweist aber nicht automatisch die Einhaltung des EU AI Act, der DSGVO oder anderer Gesetze. Eine Konformitätsvermutung nach Art. 40 AI Act entsteht ausschließlich für Anforderungen, die von einem einschlägigen harmonisierten und im EU-Amtsblatt zitierten Standard abgedeckt sind — eine veröffentlichte europäische Norm allein reicht dafür noch nicht. Diese Referenzierung ist am aktuellen Stand teils noch offen und muss vor jeder Zertifizierungsentscheidung erneut geprüft werden.