Technische Dokumentation für Hochrisiko-KI

Was Art. 11 und Anhang IV verlangen

Die technische Dokumentation ist der Nachweis, dass ein Hochrisiko-KI-System die Anforderungen der KI-Verordnung erfüllt. Art. 11 verpflichtet Anbieter, diese Dokumentation vor dem Inverkehrbringen zu erstellen und über den gesamten Lebenszyklus aktuell zu halten. Anhang IV definiert, was sie enthalten muss, von der Systembeschreibung über das Risikomanagement bis zum Post-Market-Monitoring-Plan. Dieser Beitrag analysiert die Anforderungen im Detail, ordnet die Dokumentation in das Gesamtsystem der Verordnung ein und zeigt, welche praktischen Herausforderungen Unternehmen bei der Umsetzung erwarten.

Der Artikel definiert die Technische Dokumentation Hochrisiko-KI als verpflichtenden Nachweis nach Art. 11 EU AI Act, der vor dem Inverkehrbringen erstellt und während des gesamten Lebenszyklus aktualisiert werden muss. Er erläutert die neun Dokumentationsbereiche aus Anhang IV, darunter Risikomanagement, Testing, Daten-Governance und Post-Market-Monitoring.

Art. 11: Struktur und Kernpflichten

Art. 11 umfasst drei Absätze, die den Rahmen für die technische Dokumentation setzen.

Absatz 1 begründet die zentrale Pflicht: Die technischen Unterlagen für ein Hochrisiko‑KI‑System müssen vor dem Inverkehrbringen oder der Inbetriebnahme erstellt und auf dem neuesten Stand gehalten werden; sie müssen den Nachweis ermöglichen, dass das System die Anforderungen des Kapitels III Abschnitt 2 erfüllt, und die in Anhang IV genannten Elemente mindestens enthalten. Gleichzeitig enthält Absatz 1 eine Erleichterung für kleine und mittlere Unternehmen: KMU einschließlich Start‑ups dürfen die in Anhang IV geforderten Elemente in vereinfachter Form bereitstellen; zu diesem Zweck stellt die Kommission ein vereinfachtes Formular für die technische Dokumentation bereit, das auf die Bedürfnisse kleiner und Kleinstunternehmen zugeschnitten ist und von den notifizierten Stellen für die Konformitätsbewertung akzeptiert wird.

Absatz 2 adressiert Hochrisiko-KI-Systeme, die Bestandteil eines Produkts sind, das unter eine der in Anhang I aufgeführten Harmonisierungsrechtsvorschriften fällt. In diesen Fällen wird eine einzige technische Dokumentation erstellt, die sowohl die Anforderungen der KI-Verordnung als auch die des jeweiligen sektoralen Rechtsrahmens abdeckt. Damit vermeidet die Verordnung parallele Dokumentationspflichten für KI-Systeme in regulierten Produkten wie Medizinprodukten, Maschinen oder Aufzügen.

Absatz 3 ermächtigt die Kommission, mittels delegierter Rechtsakte Anhang IV zu ändern – eine Flexibilitätsklausel, die eine Anpassung der Dokumentationsanforderungen an den technologischen Fortschritt ohne vollständiges Gesetzgebungsverfahren ermöglicht. Für Unternehmen bedeutet das: Die Dokumentationsanforderungen können sich im Laufe der Zeit weiterentwickeln, auch ohne legislative Änderung der Verordnung selbst.

Anhang IV: Die neun Dokumentationsbereiche

Anhang IV definiert den konkreten Inhalt der technischen Dokumentation in neun Bereichen. Zusammen bilden sie ein vollständiges Bild des Systems – von der Konzeption über die Entwicklung bis zum geplanten Betriebsmonitoring.

Der erste Bereich – allgemeine Beschreibung – verlangt die Angabe des Anbieters, der Systemversion, der Zweckbestimmung, der Interaktionen mit Hardware und Software sowie der vorgesehenen Einsatzumgebung. Diese Beschreibung definiert den Rahmen, innerhalb dessen alle weiteren Anforderungen bewertet werden. Eine unpräzise Zweckbestimmung an dieser Stelle führt unweigerlich zu Unschärfen in Risikoanalyse und Testing.

Der zweite Bereich – Entwicklung und Design – umfasst die Beschreibung der Entwicklungsmethoden, der Designentscheidungen, der verwendeten vortrainierten Systeme und Drittanbieter-Werkzeuge. Für Systeme, die auf Foundation Models aufbauen, ist hier die Abgrenzung zwischen eigenem Beitrag und zugekaufter Komponente relevant: Welche Teile des Systems hat der Anbieter selbst entwickelt, welche übernommen, und wie wurde deren Eignung für die spezifische Zweckbestimmung validiert?

Der dritte Bereich – Überwachung, Funktionsweise und Kontrolle – beschreibt die Leistungsfähigkeit des Systems, den Grad seiner Genauigkeit, bekannte Einschränkungen und vorhersehbare Risiken. Hier wird sichtbar, was das System kann und was nicht – eine Information, die für Betreiber nach Art. 26 ebenso relevant ist wie für Aufsichtsbehörden.

Der vierte Bereich betrifft die Leistungsmetriken und deren Angemessenheit. Es genügt nicht, Metriken zu nennen – die Dokumentation muss begründen, warum die gewählten Metriken für die spezifische Zweckbestimmung geeignet sind. Ein biometrisches Identifikationssystem erfordert andere Metriken als ein System zur Kreditwürdigkeitsprüfung.

Der fünfte Bereich verlangt die detaillierte Beschreibung des Risikomanagementsystems nach Art. 9. Die Risikoanalyse, die identifizierten Risiken, die ergriffenen Maßnahmen und die Restrisikobewertung müssen dokumentiert sein. Die technische Dokumentation ist damit der Ort, an dem die Ergebnisse des Risikomanagements in prüfbarer Form vorliegen.

Der sechste Bereich – Validierung und Testing – umfasst die Testverfahren, die verwendeten Datensätze, die Testergebnisse und die Genauigkeits- und Robustheitsmetriken. Testprotokolle müssen nachvollziehbar sein: Welche Tests wurden durchgeführt, unter welchen Bedingungen, mit welchen Ergebnissen? Dieser Bereich bildet die Brücke zu Art. 9 Abs. 6 bis 8, der das Testing als integralen Bestandteil des Risikomanagements verankert.

Der siebte Bereich dokumentiert die angewendeten Normen – harmonisierte Normen, soweit vorhanden, oder die Lösungen, die der Anbieter stattdessen gewählt hat, um die Anforderungen zu erfüllen. In der aktuellen Normenlücke (vgl. den Beitrag zu harmonisierten Normen, KW19-B) ist hier besonders sorgfältig darzulegen, auf welcher Grundlage Konformität beansprucht wird.

Der achte Bereich betrifft die EU-Konformitätserklärung nach Art. 47. Sie ist das formale Dokument, mit dem der Anbieter erklärt, dass das System alle anwendbaren Anforderungen erfüllt. Sie verweist auf die technische Dokumentation als Nachweisgrundlage.

Der neunte Bereich verlangt die Beschreibung des Post-Market-Monitoring-Systems nach Art. 72 – wie der Anbieter plant, das System nach der Inverkehrbringung zu überwachen, welche Daten systematisch erhoben werden, welche Schwellenwerte eine Neubewertung auslösen und welche Maßnahmen bei erkannten Abweichungen vorgesehen sind. Dieser Bereich schließt den Kreis zum Risikomanagement: Das Monitoring-Konzept muss kohärent mit der Risikoanalyse aus Bereich 5 sein.

Dokumentation als lebender Prozess

Die Formulierung „auf dem neuesten Stand zu halten“ in Art. 11 Abs. 1 transformiert die technische Dokumentation von einem statischen Compliance-Artefakt zu einem lebenden Prozess. Jede wesentliche Änderung am System – sei es ein Modellupdate, eine Änderung der Trainingsdaten, eine Anpassung der Schwellenwerte oder eine Erweiterung der Zweckbestimmung – muss sich in der Dokumentation widerspiegeln.

In der Praxis erfordert das einen dokumentationsintegrierten Entwicklungsprozess: Änderungen am System und Änderungen an der Dokumentation müssen synchron laufen. Unternehmen, die Dokumentation als nachgelagerte Aufgabe behandeln – „erst entwickeln, dann dokumentieren“ – werden zwangsläufig Dokumentationslücken produzieren, die bei einer Konformitätsbewertung oder Marktüberwachung auffallen. Erfahrungen aus der Medizinprodukte-Regulierung zeigen, dass nachgelagerte Dokumentation typischerweise drei- bis fünfmal teurer ist als entwicklungsbegleitende: Entscheidungsgründe sind nicht mehr rekonstruierbar, Testbedingungen müssen erneut hergestellt werden, und die beteiligten Personen sind möglicherweise nicht mehr verfügbar.

Die Aufbewahrungsfrist beträgt nach Art. 18 zehn Jahre nach dem Inverkehrbringen oder der Inbetriebnahme. Für Systeme mit langer Betriebsdauer bedeutet das: Die Dokumentation muss über einen Zeitraum archiviert und abrufbar gehalten werden, der die übliche Lebenszeit vieler IT-Systeme übersteigt. Versionierung, Zugänglichkeit und Lesbarkeit über diesen Zeitraum hinweg sind keine trivialen Anforderungen.

Einordnung im Gesamtsystem der Verordnung

Die technische Dokumentation steht nicht isoliert. Sie ist der Knotenpunkt, an dem die verschiedenen Anforderungen der Verordnung materiell zusammenlaufen.

Art. 9 (Risikomanagement) liefert die Inhalte für Anhang IV Bereich 5 – die Risikoanalyse, die Bewertung und die Maßnahmen. Ohne funktionierendes Risikomanagementsystem fehlt der Dokumentation ihr analytischer Kern.

Art. 10 (Daten-Governance) spiegelt sich in der Beschreibung der Trainings-, Validierungs- und Testdaten. Anhang IV verlangt die Angabe der Datencharakteristiken, der Herkunft, des Umfangs und der Eignung der verwendeten Datensätze. Datenlücken oder Qualitätsmängel, die hier nicht dokumentiert sind, werden bei einer Prüfung als Versäumnis gewertet.

Art. 12 (Aufzeichnungspflichten) ergänzt die technische Dokumentation um automatische Protokollierung: Hochrisiko-KI-Systeme müssen Logdateien erzeugen, die den Betrieb nachvollziehbar machen. Diese Logs sind Teil des Gesamtdokumentationssystems, auch wenn sie operativ und nicht einmalig erstellt werden.

Art. 17 (Qualitätsmanagementsystem) bildet den organisatorischen Rahmen: Das QMS definiert die Prozesse, nach denen Dokumentation erstellt, geprüft, freigegeben und aktualisiert wird. Ein QMS ohne Dokumentationsprozess ist unvollständig; eine Dokumentation ohne QMS-Einbettung ist nicht nachhaltig pflegbar.

Art. 43 (Konformitätsbewertung) definiert den Prüfkontext: Benannte Stellen erhalten vollständigen Zugang zur technischen Dokumentation und zu den Trainings-, Validierungs- und Testdatensätzen. Sie können zusätzliche Tests anfordern und Zugang zu den Entwicklungsräumlichkeiten verlangen. Die Dokumentation muss also nicht nur vollständig, sondern auch verständlich und prüfbar aufbereitet sein – eine Anforderung, die über reine Existenz hinausgeht und die Qualität der Darstellung betrifft.

Art. 26 (Pflichten der Betreiber) schafft eine zusätzliche Perspektive: Betreiber müssen die vom Anbieter bereitgestellten Gebrauchsanweisungen einhalten und das System entsprechend überwachen. Die technische Dokumentation ist damit auch die Grundlage für die Betreiberanweisungen – was dort nicht beschrieben ist, kann vom Betreiber nicht umgesetzt werden.

Praktische Herausforderungen

Vier Herausforderungen begegnen Unternehmen regelmäßig bei der Umsetzung der Dokumentationspflichten.

Die erste ist die Traceability: die durchgängige Nachvollziehbarkeit von der Anforderung über die Designentscheidung bis zur Implementierung und zum Test. Klassische Softwareentwicklung dokumentiert oft nur den Endzustand, nicht den Entscheidungspfad. Die Verordnung verlangt aber beides – was gewählt wurde und warum.

Die zweite ist die Versionskonsistenz: Wenn ein Modell in Version 3.2 dokumentiert ist, aber in Version 3.4 betrieben wird, besteht eine Compliance-Lücke. Automatisierte Versionskontrolle der Dokumentation – idealerweise gekoppelt an die Modell- und Code-Versionierung – ist kein Nice-to-have, sondern operative Notwendigkeit.

Die dritte ist die Abgrenzung bei zusammengesetzten Systemen: Wenn ein Hochrisiko-System ein vortrainiertes Foundation Model nutzt, welche Teile der Dokumentation liegen in der Verantwortung des Anbieters und welche beim Upstream-Provider des Basismodells? Art. 53 verpflichtet GPAI-Anbieter, hinreichende technische Dokumentation und Information bereitzustellen, damit nachgelagerte Anbieter ihre eigenen Pflichten erfüllen können. In der Praxis bleibt die Informationsasymmetrie dennoch eine Herausforderung.

Die vierte ist die Ressourcenintensität. Die Erstellung einer vollständigen technischen Dokumentation nach Anhang IV erfordert Expertise aus Entwicklung, Datenwissenschaft, Risikomanagement und Regulatorik. Für KMU kann der Aufwand erheblich sein, auch wenn die vereinfachte Form nach Art. 11 Abs. 1 eine Erleichterung bietet. Entscheidend ist, dass „vereinfacht“ nicht „unvollständig“ bedeutet: Alle Anhang-IV-Bereiche müssen adressiert werden, die Darstellungstiefe darf aber angemessen reduziert werden. Bis die Kommission das vereinfachte Formular veröffentlicht, fehlt KMU allerdings eine konkrete Orientierung, welches Maß an Vereinfachung als ausreichend gilt, ein weiterer Aspekt der regulatorischen Übergangsunsicherheit bis zum Stichtag.

Fazit: Dokumentation als Compliance-Infrastruktur

Die technische Dokumentation nach Art. 11 und Anhang IV ist kein bürokratischer Anhang, sondern die zentrale Compliance-Infrastruktur für Hochrisiko-KI. Sie macht die Einhaltung der Anforderungen prüfbar, archivierbar und nachvollziehbar. Drei Punkte verdienen besondere Beachtung.

Erstens: Die Dokumentation muss vor dem Inverkehrbringen stehen – nicht als Nachdokumentation, sondern als integraler Bestandteil des Entwicklungsprozesses. Zweitens: Sie ist ein lebender Prozess mit zehnjähriger Aufbewahrungspflicht – Versionierung und Aktualität sind keine optionalen Qualitätsmerkmale, sondern regulatorische Anforderungen. Drittens: Die Konformitätsbewertung prüft die Dokumentation als Erstes – sie ist das Fenster, durch das Benannte Stellen und Aufsichtsbehörden auf das System blicken. Was dort nicht steht, existiert für die Aufsicht nicht.