KI-generierte Illustration einer technischen Dokumentation mit verknüpften Unterlagen zu Daten, Tests und menschlicher Aufsicht neben einem symbolischen KI-Modul.

EU AI Act Artikel 11 einfach erklärt: Technische Dokumentation für Hochrisiko-KI

VonNiklas Entenmann

Beitragsbild: KI-generiertes Symbolbild. Keine Aufnahme eines realen Ereignisses.

Autor: Niklas Entenmann · Rechts- und Recherchestand: 9. Oktober 2026

Eine KI liefert überzeugende Ergebnisse. Aber kann das Projektteam erklären, welche Version getestet wurde, welche Grenzen bekannt sind und wer bei Fehlern eingreift? Artikel 11 des EU AI Act macht diese Nachvollziehbarkeit bei Hochrisiko-KI zur dokumentierten Aufgabe. Er verlangt eine technische Dokumentation, mit der sich die Einhaltung der einschlägigen Anforderungen beurteilen lässt.

Das klingt zunächst nach Papierarbeit. Praktisch geht es um verlässliche Antworten auf Fragen, die auch beim Einkauf, bei der Freigabe und nach einem Update entscheidend sind. Nach Artikel 10 über Datenqualität und Daten-Governance erklärt diese Folge, wie die einzelnen Nachweise zu einem verständlichen Gesamtbild werden. Alle Beispiele sind eigene, vereinfachte Szenarien und keine realen Kundenprojekte.

Was Artikel 11 verlangt

Absatz 1 enthält drei Kernpunkte: Die technische Dokumentation muss vor dem Inverkehrbringen oder der Inbetriebnahme des Hochrisiko-KI-Systems vorliegen, aktuell gehalten werden und mindestens die jeweils einschlägigen Inhalte aus Anhang IV enthalten. Sie soll zuständigen Behörden und gegebenenfalls notifizierten Stellen eine klare, umfassende Prüfung ermöglichen. Notifizierte Stellen sind dafür benannte Prüfstellen, die bei bestimmten Konformitätsbewertungsverfahren beteiligt sind.

Ein Verkaufsprospekt genügt dafür nicht. „Unsere KI ist zuverlässig“ beschreibt eine Behauptung. Eine nachvollziehbare Dokumentation erklärt dagegen, für welchen Zweck und unter welchen Bedingungen diese Aussage geprüft wurde. Dabei geht es um die Anforderungen dieses Abschnitts der Verordnung, etwa Risikomanagement, Datenqualität, menschliche Aufsicht und technische Zuverlässigkeit. Ein vollständig ausgefülltes Dokument ersetzt deren tatsächliche Umsetzung nicht.

Primärquelle: aktueller Artikel 11 im AI Act Service Desk der Europäischen Kommission.

Wen betrifft das: Anbieter oder Betreiber?

Die Verantwortung liegt beim Anbieter des Hochrisiko-KI-Systems; die Anbieterpflichten werden in Artikel 16 konkretisiert. Anbieter kann ein Softwareunternehmen sein, aber auch ein Unternehmen, das ein System entwickeln lässt und unter eigenem Namen in Verkehr bringt oder in Betrieb nimmt. Wer ein fertiges System im eigenen Arbeitsprozess verwendet, handelt regelmäßig als Betreiber. Zuerst sind daher Zweck, Risikoeinstufung und Rolle zu klären.

Ein KMU, das einen gewöhnlichen Schreibassistenten für E-Mail-Entwürfe nutzt, muss nicht allein deshalb eine vollständige technische Dokumentation nach Artikel 11 erstellen. Andere Anforderungen, beispielsweise Datenschutz, bleiben gesondert zu prüfen. Auch ein mächtiges Sprachmodell ist nicht automatisch ein Hochrisiko-System: Entscheidend sind die konkrete Anwendung und die Einstufungsregeln.

Vorsicht bei Eigenentwicklungen und Umbauten: Nach Artikel 25 zur KI-Wertschöpfungskette können unter den dort genannten Bedingungen auch Betreiber oder andere Dritte Anbieterpflichten übernehmen. Das kann etwa bei einer wesentlichen Veränderung eines Hochrisiko-Systems oder einer Zweckänderung geschehen, durch die ein bisher nicht als hochriskant eingestuftes System zu Hochrisiko-KI wird. Ein gewöhnliches Konfigurationsupdate ist damit nicht automatisch gleichzusetzen.

Anhang IV: Was gehört in die technische Dokumentation?

Anhang IV nennt neun Bereiche. Die folgende Übersicht verdichtet sie für die Projektpraxis; welche Einzelangaben einschlägig sind, hängt vom jeweiligen System ab:

  1. Systembeschreibung: Zweck, Anbieter, Version, relevante Software und Hardware, Schnittstellen, Bereitstellungsform sowie Benutzeroberfläche und Gebrauchsanweisung.
  2. Entwicklung und Aufbau: Vorgehen, Architektur, wesentliche Designentscheidungen, eingesetzte Drittkomponenten, gegebenenfalls Trainingsdaten, Tests, vorgesehene Änderungen, Aufsichts- und Cybersicherheitsmaßnahmen.
  3. Funktionsweise und Kontrolle: Fähigkeiten, Leistungsgrenzen, vorhersehbare unerwünschte Ergebnisse, Risiken, menschliche Aufsicht und gegebenenfalls Anforderungen an Eingabedaten.
  4. Leistungsmaßstäbe: Warum die gewählten Kennzahlen für dieses System geeignet sind. Eine durchschnittliche Trefferquote kann für eine sensible Entscheidung zu wenig aussagen.
  5. Risikomanagement: Beschreibung des Systems zum Umgang mit Risiken nach Artikel 9.
  6. Änderungen: Beschreibung relevanter Anpassungen durch den Anbieter über den Lebenszyklus des Systems.
  7. Standards und technische Lösungen: Angewandte harmonisierte Normen oder eine genaue Beschreibung der Lösungen zur Erfüllung der Anforderungen, wenn solche Normen nicht angewandt wurden.
  8. EU-Konformitätserklärung: Eine Kopie der Erklärung nach Artikel 47.
  9. Beobachtung nach Markteinführung: Das Verfahren zur Bewertung der späteren Systemleistung einschließlich des Plans nach Artikel 72.

Primärquelle: vollständiger Anhang IV. Die Dokumentation muss also sowohl das Produkt als auch seine Entwicklung und spätere Betreuung verständlich machen. Sie ist mehr als eine Sammlung technischer Einstellungen. Eine Aussage wie „Menschen prüfen die Ergebnisse“ braucht beispielsweise eine Erklärung, welche Eingriffsmöglichkeiten tatsächlich vorgesehen sind.

Beispiel 1: Ein kleiner Anbieter entwickelt Bewerbungs-KI

Ein fiktives Software-KMU entwickelt ein System, das Bewerbungen bewertet und Kandidaten für eine Auswahl priorisiert. Für das Beispiel nehmen wir an, dass die Prüfung nach Artikel 6 und Anhang III die Hochrisiko-Einstufung bestätigt hat. Das Team hat bereits einen erfolgreichen Prototyp und möchte ihn Kunden anbieten.

Nun reicht eine Demonstration mit zehn passenden Lebensläufen nicht. Für die technische Dokumentation muss nachvollziehbar werden: Welche Aufgabe ist vorgesehen? Welche Entscheidungen trifft die Software, welche die Personalabteilung? Welche Daten wurden verwendet? Welche Bewerbungsformen und Personengruppen wurden getestet? Welche Schwächen traten auf, und wie wurden sie berücksichtigt?

Eine sinnvolle praktische Struktur verbindet jede wichtige Aussage mit einem Beleg. Zur getesteten Version gehört der datierte Testbericht. Zur behaupteten Eingriffsmöglichkeit gehört die Beschreibung der entsprechenden Funktion. Zur Datenqualität gehört der Datensteckbrief. Ein gemeinsames Inhaltsverzeichnis mit eindeutigen Verweisen hilft, diese Unterlagen auffindbar zu halten. Diese Ablagestruktur ist eine Umsetzungsidee, kein vorgeschriebenes Softwareprodukt.

Beispiel 2: Ein Unternehmen kauft Hochrisiko-KI ein

Ein fiktives Unternehmen kauft das System für seine Personalabteilung. Als Betreiber erstellt es normalerweise nicht die gesamte Anbieter-Dokumentation neu. Für einen verantwortlichen Einkauf sollte es aber klären, ob Einsatzbedingungen und Grenzen zur eigenen Nutzung passen. Eine allgemeine Produktbroschüre beantwortet diese Fragen oft nicht.

Hilfreiche Beschaffungsfragen sind: Für welche Aufgabe und Version wurde das System bewertet? Welche Gebrauchsanweisung erhält das Team? Welche Einschränkungen sind bekannt? Wie werden Änderungen kommuniziert? Welche menschliche Kontrolle ist vorgesehen? Dabei sind die Informationen für Betreiber von der vollständigen technischen Dokumentation für Behörden und Prüfstellen zu unterscheiden. Artikel 11 verlangt nicht, dass jeder Kunde sämtliche Geschäftsgeheimnisse erhält oder die ganze Dokumentation öffentlich ins Internet gestellt wird.

Vereinfachungen für KMU: Weniger Aufwand, weiterhin Nachweise

Der aktuelle Absatz 1 erlaubt KMU einschließlich Start-ups sowie sogenannten Small Mid-Cap Enterprises, die Angaben aus Anhang IV vereinfacht bereitzustellen. Small Mid-Caps sind eine rechtlich abgegrenzte Unternehmenskategorie; die eigene Einschätzung „Wir sind mittelständisch“ genügt für diese Zuordnung nicht. Die Erweiterung auf diese Kategorie gehört zu den Änderungen des AI Omnibus.

Die Kommission soll hierfür ein vereinfachtes Dokumentationsformular festlegen. Wer den vorgesehenen vereinfachten Weg wählt, muss dieses Formular verwenden; notifizierte Stellen müssen es für die Konformitätsbewertung akzeptieren. Daraus folgt keine Befreiung von den inhaltlichen Anforderungen an das System. Auch eine kurze Dokumentation muss die erforderlichen Informationen liefern. Eine selbst erstellte Checkliste wird nicht allein durch ihre Überschrift zum offiziellen Formular.

Absätze 2 und 3: Produktrecht und technische Weiterentwicklung

Absatz 2 betrifft Hochrisiko-KI im Zusammenhang mit Produkten, die unter die in Anhang I Abschnitt A aufgeführten EU-Harmonisierungsrechtsvorschriften fallen. Hier wird ein gemeinsamer Dokumentationssatz verlangt: Er enthält sowohl die Angaben für die KI als auch die nach dem jeweiligen Produktrecht erforderlichen Informationen. Das soll zusammengehörende Nachweise verbinden; die Anforderungen des Produktrechts verschwinden dadurch nicht.

Absatz 3 ermächtigt die Kommission, Anhang IV durch delegierte Rechtsakte an technischen Fortschritt anzupassen. Für die Praxis empfiehlt sich deshalb, bei wesentlichen Projektmeilensteinen auch die aktuelle Fassung der Dokumentationsanforderungen zu prüfen. Ein Formular aus einem älteren Projekt sollte nicht ungeprüft für jede neue Anwendung übernommen werden.

Aktuell halten: Dokumentation gehört zum Änderungsprozess

Eine Dokumentation zur Version 1.0 erklärt nicht automatisch die Version 2.0. Werden Modell, Datenaufbereitung, Schnittstellen oder Einsatzbedingungen verändert, ist zu prüfen, welche Nachweise betroffen sind. Praktisch hilft eine Verantwortlichkeit pro Dokumentationsbereich und ein Freigabeprozess, der technische Änderung, Teststand und Unterlagen zusammenführt.

Ein möglicher Projektablauf: Das Team beschreibt die Änderung, bewertet ihre Auswirkungen, aktualisiert betroffene Tests und verknüpft deren Ergebnisse mit der neuen Version. Bekannte Grenzen werden ausdrücklich festgehalten. Welche Schritte im Einzelfall notwendig sind, ergibt sich aus System, Änderung und einschlägigen Pflichten. Artikel 11 schreibt keine bestimmte Projektmanagementmethode vor.

Welche Fristen gelten nach dem AI Omnibus?

Die ursprünglichen Hochrisiko-Termine dürfen nicht als aktueller Stand verwendet werden. Nach dem geänderten Artikel 113 gelten die einschlägigen Anforderungen einschließlich Artikel 11 für Hochrisiko-KI nach Artikel 6 Absatz 2 und Anhang III ab 2. Dezember 2027. Für Hochrisiko-KI nach Artikel 6 Absatz 1 und Anhang I gilt der 2. August 2028. Bestehende Systeme und besondere Übergangsfälle sind zusätzlich nach Artikel 111 zu prüfen.

Diese Termine verschieben nicht pauschal jede KI-Regel oder bestehendes Datenschutz- und Produktrecht. Der praktische Nutzen frühzeitiger Dokumentation bleibt: Fehlende Lieferanteninformationen und unklare Testgrundlagen lassen sich vor einem Einsatz besser klären als nach einer problematischen Entscheidung. Quelle: aktueller Artikel 113 und offizieller Umsetzungszeitplan.

Kurze Checkliste für den nächsten Projekttermin

  • Sind Zweck, Hochrisiko-Einstufung und eigene Rolle begründet geklärt?
  • Ist die Dokumentation eindeutig einer Systemversion zugeordnet?
  • Sind die einschlägigen Inhalte aus Anhang IV vollständig abgedeckt?
  • Sind Testberichte, Risiken, Grenzen und Aufsichtsmaßnahmen nachvollziehbar verknüpft?
  • Sind benötigte Informationen von Drittanbietern verfügbar?
  • Ist geklärt, wer Unterlagen bei Änderungen aktualisiert?
  • Wurden aktuelle Fristen, mögliche Übergangsregeln und die Voraussetzungen einer Vereinfachung geprüft?

KI-Governance in den Arbeitsalltag übersetzen

Für Unternehmen in Aachen, NRW und darüber hinaus verbindet Artikel 11 technische Entwicklung mit klaren Verantwortlichkeiten. Consulting Entenmann unterstützt bei KI-Einführung, Governance und Schulungen: Anwendungen einordnen, Fragen an Anbieter formulieren und Teams auf ihre Aufgaben vorbereiten. Informationen zur EU-AI-Act-Schulung für Unternehmen helfen bei der Planung. Dokumentation, fachliche Prüfung und Schulung sollten im Projekt zusammenpassen.

Rechtsstand und Primärquellen

Stand: 9. Oktober 2026. Grundlage ist die aktuell ausgewiesene konsolidierte Verordnung (EU) 2024/1689 vom 27. Juli 2026, einschließlich der AI-Omnibus-Änderungen. Die konsolidierte Fassung dient als Lesehilfe; rechtsverbindlich sind die im Amtsblatt veröffentlichten Rechtsakte. Der Beitrag erklärt allgemeine Zusammenhänge und ersetzt keine Prüfung des konkreten Systems.

Ähnliche Beiträge