Art. 11 EU AI Act: Technische Dokumentation Hochrisiko-KI

Wenn eine Hochrisiko-KI vor einer Behörde oder einer benannten Stelle bestehen soll, entscheidet selten das Modell selbst — sondern das, was über das Modell schriftlich vorliegt. Genau das regelt Artikel 11 der Verordnung (EU) 2024/1689. Er macht die technische Dokumentation zur Pflicht und definiert über den Verweis auf Anhang IV präzise, was sie enthalten muss. Aus einer internen Entwicklungsnotiz wird damit das zentrale Beweisstück, an dem sich die Konformität eines Hochrisiko-Systems überhaupt erst zeigen lässt.

Dokumentation als Nachweispflicht, nicht als Beiwerk

Art. 11 Abs. 1 verlangt, dass die technische Dokumentation eines Hochrisiko-KI-Systems erstellt wird, bevor das System in Verkehr gebracht oder in Betrieb genommen wird — und dass sie laufend aktuell gehalten wird. Beide Bedingungen sind bemerkenswert: Die Dokumentation darf nicht nachträglich kurz vor dem Audit zusammengeschrieben werden, und sie ist kein eingefrorener Snapshot, sondern ein lebendes Artefakt, das mit dem System mitwächst.

Entscheidend ist der Zweck, den die Verordnung der Dokumentation zuschreibt. Sie soll nachweisen, dass das System die Anforderungen des Abschnitts 2 — also die materiellen Pflichten für Hochrisiko-KI von Risikomanagement bis Cybersicherheit — erfüllt. Und sie soll den zuständigen nationalen Behörden sowie den benannten Stellen die nötigen Informationen in klarer und umfassender Form liefern, um die Konformität zu beurteilen. Damit ist klar: Die Dokumentation ist kein internes Hilfsmittel, sondern die Schnittstelle zwischen dem Provider und allen, die seine Behauptung der Regelkonformität überprüfen.

Anhang IV: Was konkret hineingehört

Art. 11 bleibt nicht abstrakt. Er verweist auf Anhang IV, der den Mindestinhalt in einer strukturierten Liste festlegt. Wer diese Struktur einmal durchgeht, erkennt, dass sie den gesamten Lebenszyklus eines Hochrisiko-Systems abbildet — von der Idee bis zum Betrieb nach dem Inverkehrbringen.

Am Anfang steht eine allgemeine Beschreibung des Systems: Zweckbestimmung, Name des Providers, Versionen, das Zusammenspiel mit Hard- und Software, die Formen, in denen das System bereitgestellt wird, sowie eine Beschreibung der Benutzeroberfläche und der Betriebsanleitung. Darauf folgt eine detaillierte Beschreibung der Elemente und des Entwicklungsprozesses: die angewandten Methoden und Entwicklungsschritte, die Designspezifikationen und zentralen Entwurfsentscheidungen, die Systemarchitektur, die Datenanforderungen samt Beschreibung der Trainings-, Validierungs- und Testdaten, die Maßnahmen zur menschlichen Aufsicht, vorab festgelegte Änderungen sowie die Validierungs- und Testverfahren mit den verwendeten Metriken.

Hinzu kommen Angaben zu Überwachung, Funktionsweise und Kontrolle des Systems mit seinen Fähigkeiten und Grenzen, eine Bewertung der Eignung der Leistungsmetriken, eine detaillierte Darstellung des Risikomanagementsystems nach Art. 9 sowie eine Beschreibung der über den Lebenszyklus vorgenommenen relevanten Änderungen. Den Abschluss bilden die Liste der angewandten harmonisierten Normen, eine Kopie der EU-Konformitätserklärung und eine Beschreibung des Systems zur Bewertung der Leistung in der Phase nach dem Inverkehrbringen — dem Plan zur Marktbeobachtung im Sinne von Art. 72. Welche Systeme überhaupt in diese Pflichtenkategorie fallen, lässt sich vorab über hochrisiko-ki.com einordnen.

Erleichterungen für KMU — ohne inhaltliche Lücken

Der Gesetzgeber hat die Belastung gesehen, die eine vollständige Anhang-IV-Dokumentation für kleinere Organisationen bedeutet. Art. 11 Abs. 2 erlaubt deshalb kleinen und mittleren Unternehmen einschließlich Start-ups, die geforderten Elemente in vereinfachter Form bereitzustellen. Die Europäische Kommission soll dafür ein vereinfachtes Formular festlegen.

Wichtig ist die Reichweite dieser Erleichterung: Sie betrifft die Form, nicht die Substanz. Auch ein KMU muss nachweisen können, dass sein System die Hochrisiko-Anforderungen erfüllt. Die Vereinfachung senkt den Aufwand der Darstellung, nicht den Anspruch an die zugrunde liegende Evidenz. Wer aus der KMU-Regelung schließt, die inhaltlichen Pflichten seien optional, missversteht sie.

Vom Pflichtdokument zur belastbaren Evidenz

Anhang IV liest sich wie eine Inhaltsangabe — die eigentliche Herausforderung liegt darin, dass jeder Punkt mit nachvollziehbaren Belegen unterfüttert sein muss. Eine technische Dokumentation, die behauptet, das Risikomanagement sei etabliert, ohne die Risikoanalysen, Maßnahmen und Restrisikobewertungen aus Art. 9 vorzulegen, erfüllt die Funktion nicht, die Art. 11 ihr zuweist. Die Dokumentation ist nur so stark wie die Evidenz, auf die sie verweist.

Genau hier entscheidet sich, ob ein Provider seine Konformität behaupten oder belegen kann. Die geforderten Inhalte — Datenherkunft, Architekturentscheidungen, Testmetriken, Aufsichtsmaßnahmen, Änderungshistorie — entstehen nicht in einer Dokumentationsphase am Ende. Sie fallen während der Entwicklung und des Betriebs an und müssen dort systematisch erfasst werden. Das erklärt den engen Zusammenhang zwischen Art. 11 und einem gelebten AI Management System (AIMS nach ISO 42001 × CMMI v3): Das Managementsystem liefert die Routinen, in denen die von Anhang IV verlangten Nachweise zuverlässig und wiederholbar entstehen, statt im Nachhinein rekonstruiert werden zu müssen.

Diese Logik gilt unabhängig vom Rechtsraum, in dem ein Provider tätig ist — ob DE, EU27-Rest, UK oder CH —, sobald sein System auf dem EU-Markt bereitgestellt wird. Die Anforderung an die Aktualität nach Art. 11 Abs. 1 macht zudem deutlich, dass die Dokumentation kein einmaliges Projekt ist: Jede relevante Änderung am System zieht eine Aktualisierung nach sich, andernfalls verliert das Dokument seine Beweiskraft genau in dem Moment, in dem es gebraucht wird.

Bis zum 02.12.2027 vom Sammelordner zur Audit-Reife

Bis zum Wirksamwerden der Durchsetzung am 02.12.2027 (Digital Omnibus) bleibt Organisationen Zeit, ihre technische Dokumentation von einem verstreuten Sammelordner zu einer kohärenten, jederzeit vorzeigbaren Nachweisbasis umzubauen. Wer erst kurz vor der Konformitätsbewertung beginnt, die Geschichte seines Systems zu rekonstruieren, wird Lücken finden, die sich rückwirkend nicht mehr schließen lassen — eine Testreihe, die nie protokolliert wurde, eine Designentscheidung, deren Begründung niemand mehr kennt.

Art. 11 ist deshalb mehr als eine Formvorschrift. Er ist der Punkt, an dem ein Hochrisiko-System seine eigene Vertrauenswürdigkeit nach außen sichtbar macht. Genau dort setzt evidenzbasierter AI Trust an: nachweisbar, audit-ready — nicht als Versprechen, sondern als durchgängig dokumentierte Praxis. Mehr zur AEGIRA Trust-Platform: aegira.ai.