Artikel 11 AI Act einfach erklärt: Was Technische Dokumentation jetzt erfüllen muss

KI-System entwickelt, ein paar Tests durchgeführt, Bedienungsanleitung geschrieben – fertig?

Nicht ganz.

Sobald ein KI-System nach dem EU AI Act als Hochrisiko-KI-System eingestuft wird, steigen die Anforderungen an seine Dokumentation deutlich. Dann reicht es nicht mehr, nur zu erklären, wie Anwender die Software bedienen.

Die Dokumentation muss zusätzlich nachvollziehbar machen:

• wie das KI-System entwickelt wurde,
• mit welchen Daten und Methoden es arbeitet,
• wie zuverlässig es funktioniert,
• welche Risiken bestehen,
• wie Menschen das System überwachen können,
• wie Änderungen und Vorfälle kontrolliert werden.

Mit anderen Worten: Die Technische Dokumentation wird zum zentralen Compliance-Nachweis.

Artikel 11 des AI Acts bildet dafür eine wichtige Grundlage. Doch was fordert er konkret? Wer ist betroffen? Und welche Unterlagen müssen Unternehmen tatsächlich erstellen?

Was regelt Artikel 11 des AI Acts?

Artikel 11 der Verordnung (EU) 2024/1689 verpflichtet Anbieter von Hochrisiko-KI-Systemen dazu, eine Technische Dokumentation zu erstellen.

Diese Dokumentation muss grundsätzlich vor dem Inverkehrbringen oder der Inbetriebnahme des Systems vorliegen. Außerdem muss sie während des Lebenszyklus aktuell gehalten werden.

Ihr Zweck ist klar: Behörden und andere zuständige Stellen sollen beurteilen können, ob das KI-System die Anforderungen des AI Acts erfüllt.

Die Dokumentation ist damit keine freiwillige Projektakte und auch kein reines Informationsangebot für Kund. Sie ist ein regulatorischer Nachweis. Artikel 11 verweist für die konkreten Inhalte insbesondere auf Anhang IV des AI Acts.

Gilt Artikel 11 für jedes KI-System?

Nein.

Das ist eine der wichtigsten Unterscheidungen.

Die umfangreichen Anforderungen aus Artikel 11 richten sich vor allem an Anbieter von Hochrisiko-KI-Systemen. Ob ein System als hochriskant gilt, richtet sich insbesondere nach Artikel 6 sowie den Anhängen I und III des AI Acts.

Dabei gibt es vereinfacht zwei große Gruppen:

KI als Produkt oder Sicherheitsbauteil

Ein KI-System kann als hochriskant gelten, wenn es selbst ein reguliertes Produkt ist oder als Sicherheitskomponente eines Produkts eingesetzt wird und dieses Produkt einer Konformitätsbewertung durch eine unabhängige Stelle unterliegt.

Das kann beispielsweise Systeme im Umfeld von Maschinen, Medizinprodukten oder anderen regulierten Produkten betreffen.

KI für besonders sensible Einsatzbereiche

Auch bestimmte eigenständige KI-Systeme können als hochriskant eingestuft werden. Dazu gehören je nach konkretem Einsatzzweck unter anderem Anwendungen in den Bereichen:

• Biometrie,
• kritische Infrastruktur,
• Bildung,
• Personalmanagement,
• Zugang zu wichtigen privaten oder öffentlichen Leistungen,
• Strafverfolgung,
• Migration und Grenzkontrolle,
• Justiz und demokratische Prozesse.

Entscheidend ist nicht allein die verwendete Technologie. Entscheidend sind der vorgesehene Verwendungszweck und die möglichen Auswirkungen auf Gesundheit, Sicherheit und Grundrechte.

Die Europäische Kommission hat 2026 zusätzlich Entwürfe für Leitlinien zur Einstufung von Hochrisiko-KI veröffentlicht. Diese Leitlinien sind nicht rechtsverbindlich, sollen aber die Auslegung unterstützen.

Was ist mit „Technischer Dokumentation“ gemeint?

Wer aus der Technischen Kommunikation kommt, denkt bei Technischer Dokumentation möglicherweise zuerst an:

• Bedienungsanleitungen,
• Onlinehilfen,
• Sicherheitsinformationen,
• Installationsanleitungen,
• Wartungsinformationen.

Diese Inhalte bleiben wichtig. Artikel 11 meint jedoch deutlich mehr.

Die Technische Dokumentation eines Hochrisiko-KI-Systems beschreibt nicht nur die Nutzung des Produkts. Sie dokumentiert auch dessen Konzeption, Entwicklung, Prüfung, Leistungsfähigkeit und Risikobeherrschung.

Man könnte sagen:

Die Nutzungsdokumentation erklärt, wie das System verwendet wird.
Die Compliance-Dokumentation belegt, warum das System verantwortbar eingesetzt werden kann.

Beide Informationsbereiche müssen zusammenpassen.

Was muss die Technische Dokumentation konkret enthalten?

Die Grundregel steht in Artikel 11. Die inhaltlichen Einzelheiten finden sich in Anhang IV des AI Acts.

Dabei geht es nicht darum, möglichst viele Dokumente zu produzieren. Die Unterlagen müssen so vollständig und verständlich sein, dass die Konformität des Systems beurteilt werden kann.

Die folgenden Nachweisbereiche sind besonders wichtig.

1. Allgemeine Beschreibung des KI-Systems

Zunächst muss klar sein, was das KI-System überhaupt ist und wofür es gedacht ist.

Dazu gehören beispielsweise:

• Produktname und Versionsstand,
• Name und Kontaktdaten des Anbieters,
• vorgesehener Verwendungszweck,
• Zielgruppen und vorgesehene Betreiber,
• grundlegende Funktionen,
• Einbindung in andere Produkte oder Systeme,
• Hardware- und Softwareumgebung,
• Schnittstellen,
• Formen der Bereitstellung,
• relevante Versionen und Varianten.

Der Verwendungszweck ist dabei kein beiläufiger Einleitungssatz. Er beeinflusst unter anderem die Risikoklassifizierung, die erforderlichen Schutzmaßnahmen und die Grenzen des zulässigen Einsatzes.

Eine Formulierung wie „Das System unterstützt Entscheidungen“ ist meistens zu ungenau.

Welche Entscheidungen?
Für welche Personen?
In welchem fachlichen Kontext?
Auf Basis welcher Daten?
Mit welcher menschlichen Kontrolle?

Je präziser der Verwendungszweck beschrieben ist, desto besser lassen sich Risiken und Anforderungen daraus ableiten.

2. Beschreibung der Entwicklung und Systemarchitektur

Die Dokumentation muss nachvollziehbar darstellen, wie das KI-System entwickelt wurde.

Dazu können gehören:

• Systemarchitektur,
• eingesetzte Algorithmen und Modelle,
• Modelltypen,
• Trainingsverfahren,
• Optimierungsverfahren,
• verwendete Softwarekomponenten,
• Abhängigkeiten von Drittsystemen,
• Rechenressourcen,
• Designentscheidungen,
• Annahmen und technische Einschränkungen.

Die Dokumentation sollte außerdem erklären, wie einzelne Komponenten zusammenwirken.

Bei einem komplexen KI-System genügt deshalb kein Architekturdiagramm, das aus fünf Kästchen und sieben Pfeilen besteht, deren Bedeutung nur das Entwicklungsteam kennt.

Ein guter Nachweis beantwortet Fragen wie:

• Welche Eingaben verarbeitet das System?
• Welche Verarbeitungsschritte finden statt?
• Wie wird die Ausgabe erzeugt?
• Welche Komponenten können das Ergebnis beeinflussen?
• Wo greifen menschliche Kontrollen ein?
• Welche externen Dienste werden verwendet?

3. Daten und Daten-Governance

Viele Risiken eines KI-Systems entstehen nicht erst im Modell. Sie beginnen bei den Daten.

Die Dokumentation sollte deshalb nachvollziehbar beschreiben:

• welche Daten verwendet wurden,
• aus welchen Quellen sie stammen,
• wie sie erhoben wurden,
• wie Daten ausgewählt und aufbereitet wurden,
• welche Datenqualität angestrebt wurde,
• wie Repräsentativität geprüft wurde,
• wie mit Lücken und Fehlern umgegangen wurde,
• welche Verzerrungen erkannt wurden,
• welche Maßnahmen gegen Bias vorgesehen sind.

Auch Trainings-, Validierungs- und Testdaten müssen voneinander unterscheidbar sein.

Die Aussage „Das Modell wurde mit umfangreichen Daten trainiert“ ist kein belastbarer Nachweis.

Umfangreich im Vergleich wozu?
Aus welchen Zeiträumen?
Für welche Personengruppen?
Mit welcher Qualität?
Und wer hat das geprüft?

Technische Redakteur werden hier häufig zu Übersetzer zwischen Data Science, Qualitätsmanagement, Recht und Aufsichtsbehörden.

4. Funktionsweise, Fähigkeiten und Grenzen

Ein KI-System muss nicht nur beschrieben werden. Seine tatsächliche Leistungsfähigkeit muss nachvollziehbar sein.

Dazu gehören unter anderem:

• erwartete Genauigkeit,
• Robustheit,
• Zuverlässigkeit,
• relevante Leistungskennzahlen,
• bekannte Fehlermuster,
• Einschränkungen,
• Bedingungen, unter denen die Leistung sinkt,
• vorhersehbare Fehlanwendungen,
• Abhängigkeiten von Eingabedaten,
• Grenzen der Generalisierbarkeit.

Besonders wichtig ist, dass Leistungswerte nicht ohne Kontext angegeben werden.

Eine Genauigkeit von 94 Prozent klingt beeindruckend. Sie sagt allein aber wenig aus.

Relevant sind beispielsweise auch:

• Welche Fehler machen die übrigen sechs Prozent aus?
• Sind bestimmte Gruppen häufiger betroffen?
• Wie wurden die Testdaten ausgewählt?
• Welcher Schwellenwert wurde verwendet?
• Welche Folgen hat eine falsche Ausgabe?
• Gibt es falsch positive und falsch negative Ergebnisse?

Die Dokumentation sollte also nicht nur zeigen, wie gut das System funktioniert. Sie muss auch erklären, wann und warum es möglicherweise nicht gut funktioniert.

5. Prüfungen, Tests und Validierung

Artikel 11 verlangt eine Dokumentation, die eine Konformitätsbewertung ermöglicht. Dafür sind belastbare Testnachweise unverzichtbar.

Wichtige Nachweise können sein:

• Testkonzepte,
• Validierungspläne,
• Testszenarien,
• Testdatensätze,
• Akzeptanzkriterien,
• festgelegte Metriken,
• Prüfergebnisse,
• Abweichungen,
• Fehleranalysen,
• Freigaben,
• Regressionstests,
• Ergebnisse von Robustheits- und Sicherheitstests.

Auch der Zeitpunkt der Tests ist relevant.

Ein System kann vor der Markteinführung hervorragend funktionieren und sich durch neue Daten, Modellanpassungen oder veränderte Umgebungsbedingungen später anders verhalten.

Deshalb sollte die Testdokumentation nicht als einmaliger Abschlussbericht verstanden werden. Sie ist Teil einer fortlaufenden Nachweiskette.

6. Risikoanalyse und Schutzmaßnahmen

Hochrisiko-KI benötigt ein systematisches Risikomanagement.

Die Technische Dokumentation sollte zeigen:

• welche Risiken identifiziert wurden,
• wer davon betroffen sein könnte,
• wie wahrscheinlich ein Schaden ist,
• wie schwer mögliche Auswirkungen wären,
• welche Schutzmaßnahmen vorgesehen sind,
• welche Restrisiken verbleiben,
• wie diese Restrisiken kommuniziert werden,
• wie die Wirksamkeit der Maßnahmen kontrolliert wird.

Dabei geht es nicht nur um klassische technische Fehler.

Je nach System können auch Risiken für Grundrechte relevant sein, beispielsweise:

• Diskriminierung,
• Benachteiligung bestimmter Personengruppen,
• fehlende Nachvollziehbarkeit,
• unangemessene Überwachung,
• falsche Entscheidungen,
• Einschränkung menschlicher Handlungsmöglichkeiten,
• Verarbeitung sensibler personenbezogener Daten.

Die Risikoanalyse darf deshalb nicht isoliert in der Entwicklungsabteilung verbleiben. Sie muss mit Datenschutz, Informationssicherheit, Qualitätsmanagement, Recht und Technischer Kommunikation abgestimmt werden.

7. Menschliche Aufsicht

Der AI Act stellt hohe Anforderungen an die menschliche Kontrolle von Hochrisiko-KI-Systemen.

Die Dokumentation sollte deshalb deutlich machen:

• welche Aufgaben Menschen übernehmen,
• welche Entscheidungen nicht vollständig automatisiert erfolgen dürfen,
• wie Ausgaben überprüft werden,
• wann ein Eingreifen notwendig ist,
• wie das System gestoppt oder übersteuert werden kann,
• welche Kompetenzen die überwachenden Personen benötigen,
• welche Informationen ihnen zur Verfügung stehen müssen.

Eine Formulierung wie „Die finale Entscheidung liegt beim Menschen“ reicht nicht automatisch aus.

Kann die Person das Ergebnis tatsächlich verstehen?
Hat sie genug Zeit für die Prüfung?
Kennt sie die Grenzen des Systems?
Kann sie einer Empfehlung widersprechen?
Oder bestätigt sie am Ende nur noch automatisch, was die KI vorgeschlagen hat?

Gute Dokumentation beschreibt menschliche Aufsicht als konkreten Prozess – nicht als beruhigenden Satz im letzten Kapitel.

8. Cybersicherheit und technische Robustheit

Auch Schutzmaßnahmen gegen Manipulation, Angriffe und technische Störungen müssen dokumentiert werden.

Abhängig vom System können dazu gehören:

• Zugriffsschutz,
• Rollen- und Berechtigungskonzepte,
• Schutz von Trainings- und Betriebsdaten,
• Absicherung von Schnittstellen,
• Erkennung manipulierter Eingaben,
• Schutz gegen Adversarial Attacks,
• Überwachung von Modell- und Datenveränderungen,
• Update- und Patchprozesse,
• Backup- und Wiederherstellungskonzepte,
• Incident-Response-Prozesse.

Bei KI-Systemen können zudem spezielle Angriffsformen relevant sein, etwa:

• Data Poisoning,
• Model Poisoning,
• Manipulation von Eingaben,
• Umgehung von Schutzmechanismen,
• unbefugte Extraktion von Modellinformationen,
• Missbrauch von Schnittstellen.

Die Technische Dokumentation muss nicht jeden möglichen Angriff bis ins letzte Detail offenlegen. Sie muss aber nachvollziehbar machen, dass relevante Gefährdungen erkannt und angemessen behandelt wurden.

9. Protokollierung und Überwachung

Hochrisiko-KI-Systeme müssen so gestaltet sein, dass relevante Ereignisse nachvollzogen werden können.

Dazu gehört die Dokumentation der Protokollierungsfunktionen:

• Welche Ereignisse werden erfasst?
• Welche Eingaben und Ausgaben werden gespeichert?
• Wie werden Zeitpunkte dokumentiert?
• Wie lange werden Protokolle aufbewahrt?
• Wer darf auf sie zugreifen?
• Wie werden Auffälligkeiten erkannt?
• Wie lassen sich Entscheidungen später rekonstruieren?

Protokolldaten können wichtige Nachweise liefern, wenn Fehler, Beschwerden oder schwerwiegende Vorfälle untersucht werden müssen.

Allerdings gilt nicht das Motto: „Wir speichern einfach alles.“

Protokollierung muss auch mit Datenschutz, Informationssicherheit und Aufbewahrungsfristen abgestimmt werden.

10. Änderungen und Versionsmanagement

KI-Systeme verändern sich.

Modelle werden aktualisiert.
Trainingsdaten werden ergänzt.
Schwellenwerte werden angepasst.
Schnittstellen ändern sich.
Neue Anwendungsfälle kommen hinzu.

Die Technische Dokumentation muss solche Änderungen nachvollziehbar abbilden.

Dazu gehören beispielsweise:

• Versionshistorien,
• Änderungsbeschreibungen,
• Gründe für Änderungen,
• Auswirkungen auf Leistung und Risiken,
• erforderliche neue Prüfungen,
• Freigabeentscheidungen,
• aktualisierte Gebrauchsanweisungen,
• Bewertung wesentlicher Änderungen.

Besonders wichtig ist die Frage, ob eine Änderung so erheblich ist, dass eine erneute Konformitätsbewertung notwendig werden kann.

„Modell aktualisiert“ ist daher kein ausreichender Eintrag im Änderungsprotokoll.

Die Dokumentation sollte zeigen, was geändert wurde, warum es geändert wurde und welche Auswirkungen geprüft wurden.

11. Marktbeobachtung und Betriebserfahrungen

Die Verantwortung endet nicht mit der Markteinführung.

Anbieter müssen beobachten, wie sich das System im realen Einsatz verhält. Die Technische Dokumentation sollte deshalb auch mit der Marktbeobachtung verknüpft sein.

Mögliche Nachweise sind:

• Plan zur Überwachung nach dem Inverkehrbringen,
• Rückmeldungen von Betreiber,
• Beschwerden,
• Leistungsdaten aus dem Betrieb,
• erkannte Fehlanwendungen,
• Sicherheitsvorfälle,
• Korrekturmaßnahmen,
• Aktualisierungen der Risikoanalyse,
• Erkenntnisse aus Supportfällen.

Ein Testsystem kennt kontrollierte Bedingungen. Der reale Betrieb kennt kreative Menschen, schlechte Daten, ungewöhnliche Kombinationen und den berühmten Sonderfall, den angeblich „niemand vorhersehen konnte“.

Genau deshalb ist die Marktbeobachtung so wichtig.

Anhang IV nennt den Plan zur Beobachtung nach dem Inverkehrbringen ausdrücklich als Bestandteil der Technischen Dokumentation.

Welche Typen von Nachweisen sind wichtig?

Artikel 11 verlangt nicht nur beschreibende Fließtexte. Für eine belastbare Compliance-Dokumentation werden unterschiedliche Nachweisarten benötigt.

Beschreibende Nachweise

Sie erläutern das System und seine Funktionsweise, zum Beispiel:

• Systembeschreibung,
• Verwendungszweck,
• Architektur,
• Funktionsbeschreibung,
• Beschreibung der menschlichen Aufsicht.

Prozessnachweise

Sie zeigen, dass Anforderungen systematisch bearbeitet wurden:

• Entwicklungsprozesse,
• Freigabeverfahren,
• Daten-Governance,
• Risikomanagement,
• Änderungsmanagement,
• Marktbeobachtung.

Prüfnachweise

Sie belegen tatsächliche Ergebnisse:

• Testberichte,
• Validierungsberichte,
• Messergebnisse,
• Robustheitstests,
• Bias-Analysen,
• Sicherheitsprüfungen.

Entscheidungsnachweise

Sie machen fachliche Abwägungen nachvollziehbar:

• Auswahl von Modellen,
• Festlegung von Schwellenwerten,
• akzeptierte Restrisiken,
• Auswahl von Datenquellen,
• Freigaben und Genehmigungen.

Betriebsnachweise

Sie zeigen, wie das System nach der Bereitstellung überwacht wird:

• Logs,
• Vorfallsberichte,
• Nutzerfeedback,
• Beschwerden,
• Leistungsüberwachung,
• Korrekturmaßnahmen.

Rückverfolgbarkeitsnachweise

Sie verbinden Anforderungen, Risiken, Maßnahmen und Tests:

• Anforderungsmatrizen,
• Traceability-Matrizen,
• Verknüpfungen zwischen Risiken und Schutzmaßnahmen,
• Zuordnung von Tests zu Anforderungen,
• Versions- und Änderungsstände.

Besonders wertvoll ist eine klare Nachweiskette:

Anforderung → Risiko → Maßnahme → Test → Ergebnis → Freigabe

Fehlt diese Verbindung, entsteht schnell ein Dokumentenberg, in dem zwar alles irgendwo steht, aber niemand zuverlässig nachweisen kann, ob eine konkrete Anforderung tatsächlich erfüllt wurde.

Wie lange muss die Dokumentation aufbewahrt werden?

Artikel 18 des AI Acts verpflichtet Anbieter von Hochrisiko-KI-Systemen grundsätzlich dazu, die Technische Dokumentation für einen Zeitraum von zehn Jahren nach dem Inverkehrbringen oder der Inbetriebnahme des Systems für die zuständigen Behörden bereitzuhalten.

Das gilt auch für weitere relevante Unterlagen, etwa zum Qualitätsmanagement und zur Konformitätsbewertung.

Unternehmen benötigen deshalb ein verlässliches Konzept für:

• Archivierung,
• Versionsstände,
• Zugriffsrechte,
• Lesbarkeit über lange Zeiträume,
• Zuordnung zu Produktversionen,
• Schutz vor nachträglichen Veränderungen.

Ein zehn Jahre altes Dokument, das sich nicht mehr öffnen oder keiner konkreten Produktversion zuordnen lässt, ist zwar vorhanden – als Nachweis aber nur begrenzt hilfreich.

Welche Risiken entstehen bei mangelhafter Dokumentation?

Fehlende oder unzureichende Dokumentation ist nicht bloß ein redaktionelles Problem.

Sie kann dazu führen, dass:

• die Konformität nicht nachgewiesen werden kann,
• sich die Markteinführung verzögert,
• Behörden zusätzliche Informationen verlangen,
• Produkte oder Systeme beanstandet werden,
• Korrekturmaßnahmen notwendig werden,
• Haftungs- und Reputationsrisiken steigen,
• Bußgelder drohen.

Auch intern entstehen Risiken.

Wenn Entwicklungsentscheidungen nicht dokumentiert wurden, müssen Teams später rekonstruieren, warum ein Modell, ein Datensatz oder ein Schwellenwert ausgewählt wurde.

Das wird besonders schwierig, wenn Mitarbeitende das Unternehmen verlassen oder externe Anbieter beteiligt waren.

Die gefährlichste Dokumentationslücke ist deshalb oft nicht das fehlende Hochglanzdokument. Es ist die Entscheidung, die nur noch im Kopf einer Person existiert.

Welche Rolle übernimmt die Technische Redaktion?

Artikel 11 macht aus Technischen Redakteur nicht automatisch Data Scientists oder Jurist.

Ihre Rolle kann sich jedoch deutlich erweitern.

Technische Redaktionen können unter anderem dabei unterstützen:

• Informationsanforderungen zu strukturieren,
• Nachweisarten zu definieren,
• Terminologie zu vereinheitlichen,
• Inhalte aus verschiedenen Fachbereichen zusammenzuführen,
• Verantwortlichkeiten sichtbar zu machen,
• Dokumentvorlagen zu entwickeln,
• Versionen und Varianten zu organisieren,
• widersprüchliche Aussagen zu erkennen,
• nutzungsbezogene Informationen mit Compliance-Nachweisen abzugleichen,
• komplexe Sachverhalte verständlich aufzubereiten.

Die Inhalte selbst müssen aus den verantwortlichen Fachbereichen kommen.

Eine Technische Redaktion kann nicht eigenständig bestätigen, dass ein Modell robust, diskriminierungsfrei oder cybersicher ist. Sie kann aber dafür sorgen, dass die zuständigen Fachpersonen ihre Bewertungen strukturiert, eindeutig und nachprüfbar dokumentieren.

Das ist ein entscheidender Unterschied:

Technische Redakteur erfinden keine Nachweise. Sie machen Nachweise nutzbar.

So kannst Du Deine Dokumentation auf Artikel 11 vorbereiten

Ein sinnvoller Einstieg besteht nicht darin, sofort ein 200-seitiges AI-Act-Handbuch zu schreiben.

Beginne mit einer Bestandsaufnahme.

1. System klassifizieren

Prüfe gemeinsam mit Recht, Compliance und Produktverantwortlichen:

• Handelt es sich um ein KI-System im Sinne des AI Acts?
• Wer ist Anbieter, Betreiber, Importeur oder Händler?
• Welcher Verwendungszweck ist vorgesehen?
• Könnte das System als Hochrisiko-KI gelten?

2. vorhandene Nachweise sammeln

Viele Informationen existieren möglicherweise bereits:

• Architekturunterlagen,
• Datenblätter,
• Testberichte,
• Risikoanalysen,
• Datenschutzdokumente,
• Sicherheitskonzepte,
• Modellkarten,
• Freigabeprotokolle,
• Supportinformationen.

3. Lückenanalyse durchführen

Vergleiche die vorhandenen Unterlagen mit Artikel 11 und Anhang IV.

Welche Nachweise fehlen?
Welche Informationen sind veraltet?
Welche Dokumente widersprechen sich?
Welche Entscheidungen wurden noch nicht festgehalten?

4. Verantwortlichkeiten festlegen

Definiere für jeden Informationsbereich eine verantwortliche Rolle.

Zum Beispiel:

• Entwicklung für Architektur und technische Funktionsweise,
• Data Science für Daten und Modellleistung,
• Qualitätsmanagement für Prozesse und Freigaben,
• Informationssicherheit für Cyberrisiken,
• Recht und Compliance für regulatorische Einordnung,
• Technische Redaktion für Struktur, Konsistenz und Publikation.

5. Dokumentation modular aufbauen

Nicht jede Information muss in einem einzigen Dokument stehen.

Ein modulares Dokumentationssystem kann beispielsweise umfassen:

• Systembeschreibung,
• Risikomanagementakte,
• Daten- und Modellbeschreibung,
• Test- und Validierungsakte,
• Gebrauchsanweisung,
• Cybersecurity-Nachweise,
• Änderungsakte,
• Marktbeobachtungsplan.

Wichtig ist, dass die Bestandteile eindeutig miteinander verknüpft und als vollständiger Nachweis abrufbar sind.

6. Aktualisierung in Prozesse integrieren

Die Dokumentation muss mit dem System wachsen.

Deshalb sollten Änderungen an Modell, Daten, Einsatzbereich oder Risikobewertung automatisch eine Prüfung der Dokumentation auslösen.

Dokumentation darf nicht der letzte Schritt vor der Veröffentlichung sein. Sie muss Bestandteil des Entwicklungs- und Änderungsprozesses werden.

Checkliste: Erfüllt Deine Dokumentation die Grundidee von Artikel 11?

Prüfe, ob Du folgende Fragen beantworten kannst:

• Ist der vorgesehene Verwendungszweck eindeutig beschrieben?
• Sind Systemarchitektur und Funktionsweise nachvollziehbar?
• Sind Datenquellen und Datenaufbereitung dokumentiert?
• Sind Leistung, Genauigkeit und Grenzen belegt?
• Gibt es nachvollziehbare Test- und Validierungsnachweise?
• Sind Risiken, Schutzmaßnahmen und Restrisiken dokumentiert?
• Ist die menschliche Aufsicht konkret beschrieben?
• Sind Cybersecurity-Maßnahmen nachvollziehbar?
• Können relevante Ereignisse protokolliert werden?
• Werden Änderungen und Versionen kontrolliert?
• Gibt es einen Plan für die Marktbeobachtung?
• Lassen sich Anforderungen, Risiken, Maßnahmen und Tests miteinander verknüpfen?
• Ist geregelt, wer welche Informationen aktualisiert?
• Können die Unterlagen langfristig archiviert und Behörden bereitgestellt werden?

Kannst Du mehrere dieser Fragen nur mit „Das müsste eigentlich irgendwo stehen“ beantworten, hast Du bereits einen guten Ausgangspunkt für Deine Lückenanalyse gefunden.

Fazit: Artikel 11 verlangt mehr als eine Bedienungsanleitung

Artikel 11 des AI Acts erweitert den Blick auf Technische Dokumentation.

Bei Hochrisiko-KI geht es nicht mehr nur darum, die Bedienung eines Systems zu erklären. Unternehmen müssen nachvollziehbar belegen, wie das System entwickelt, geprüft, abgesichert und überwacht wird.

Eine gute KI-Dokumentation verbindet daher:

• Produktwissen,
• Entwicklungsnachweise,
• Datenkompetenz,
• Risikomanagement,
• Qualitätsmanagement,
• Informationssicherheit,
• Nutzerinformationen,
• regulatorische Anforderungen.

Wer frühzeitig klare Strukturen, Verantwortlichkeiten und Nachweisketten schafft, muss Compliance später nicht mühsam aus E-Mails, Tickets und verstreuten Projektdateien rekonstruieren.

Denn beim AI Act gilt ein vertrauter Grundsatz aus dem Qualitätsmanagement:

Was nicht nachvollziehbar dokumentiert ist, lässt sich nur schwer verlässlich nachweisen.

Hinweis: Dieser Beitrag bietet eine fachliche Einordnung und ersetzt keine individuelle Rechtsberatung. Ob ein konkretes System als Hochrisiko-KI einzustufen ist und welche Pflichten gelten, sollte im jeweiligen Anwendungsfall rechtlich und technisch geprüft werden.