EU AI Act: technische Dokumentation umsetzen

Ein KI-System kann fachlich überzeugen und dennoch vor dem Produktivbetrieb scheitern: wenn Herkunft der Trainingsdaten, Grenzen der Modellleistung, menschliche Eingriffe oder Änderungen am System nicht belastbar nachvollzogen werden können. Die EU AI Act technische Dokumentation ist deshalb keine nachgelagerte Compliance-Aufgabe. Für betroffene KI-Systeme bildet sie die Grundlage, um Anforderungen an Entwicklung, Betrieb und Kontrolle praktisch nachzuweisen.

Besonders anspruchsvoll wird dies in Unternehmen, deren KI-Anwendungen mit SAP-Prozessen, Datenplattformen, Fachanwendungen oder externen Modellen verbunden sind. Dokumentationspflichten treffen dort auf gewachsene Systemlandschaften, verteilte Verantwortlichkeiten und laufende Releases. Entscheidend ist nicht, möglichst viele Dokumente zu produzieren. Entscheidend ist eine Dokumentation, die mit dem tatsächlichen Systemstand übereinstimmt, prüfbare Aussagen ermöglicht und im Betrieb fortgeschrieben wird.

Wann technische Dokumentation nach dem EU AI Act relevant wird

Der EU AI Act unterscheidet Pflichten nach Rolle und Risikoklasse. Die umfassenden Anforderungen an die technische Dokumentation nach Anhang IV richten sich vor allem an Anbieter von Hochrisiko-KI-Systemen. Sie müssen die Dokumentation erstellen, bevor das System in Verkehr gebracht oder in Betrieb genommen wird, und sie aktuell halten. Sie ist Teil der Konformitätsbewertung und muss den zuständigen Behörden auf Verlangen zur Verfügung stehen.

Für Betreiber ist die Lage anders, aber nicht folgenlos. Wer ein Hochrisiko-System einsetzt, benötigt ausreichende Unterlagen, um die eigenen Betriebs- und Überwachungspflichten erfüllen zu können. Das betrifft etwa die Nutzung nach Anleitung, die Überwachung durch qualifizierte Personen, die Protokollierung und die Behandlung schwerwiegender Vorfälle. Betreiber sollten daher frühzeitig prüfen, welche Nachweise vom Anbieter erforderlich sind und welche betrieblichen Informationen sie selbst ergänzen müssen.

Auch bei KI-Modellen mit allgemeinem Verwendungszweck gelten spezifische Informations- und Dokumentationspflichten für deren Anbieter. Für Unternehmen, die solche Modelle über Plattformen oder APIs in eigene Prozesse integrieren, ist relevant, ob die verfügbaren Informationen ausreichen, um das konkrete Anwendungssystem zu bewerten und kontrolliert zu betreiben. Ein Modellsteckbrief ersetzt keine technische Dokumentation für eine eigene Hochrisiko-Anwendung.

Die rechtliche Einordnung hängt immer vom konkreten Einsatz ab. Eine Prognose für den Energiebedarf, eine Priorisierung von Servicefällen oder ein Assistenzsystem im Einkauf können technisch ähnlich aufgebaut sein, aber regulatorisch unterschiedlich zu bewerten sein. Risikoklasse, Rolle in der Lieferkette und vorgesehener Verwendungszweck müssen daher vor der Dokumentation geklärt werden. Andernfalls wird womöglich am falschen Nachweis gearbeitet.

Was die EU AI Act technische Dokumentation enthalten muss

Anhang IV verlangt keine reine Systembeschreibung. Gefordert ist ein nachvollziehbares Gesamtbild: Was leistet das System, wie wurde es entwickelt, mit welchen Daten arbeitet es, wie wurde es geprüft und wie wird es kontrolliert? Die Dokumentation muss so konkret sein, dass sie die Konformitätsbewertung und die Prüfung der Anforderungen unterstützt.

Im Kern gehören vier Ebenen zusammen:

• Die System- und Zweckbeschreibung erklärt Funktionen, Einsatzgrenzen, Nutzergruppen, Schnittstellen, vorgesehene Betriebsumgebung und erwartete Outputs.

• Die Entwicklungsdokumentation beschreibt Architektur, Komponenten, Modellversionen, Datenverarbeitung, Trainings- und Validierungsansätze sowie getroffene Designentscheidungen.

• Die Nachweise zur Leistungsfähigkeit und Risikobeherrschung erfassen Testmethoden, Testdaten, Kennzahlen, Fehlerbilder, menschliche Aufsicht, Cybersecurity-Maßnahmen und Restrisiken.

• Die Betriebsdokumentation umfasst Logging, Monitoring, Änderungsmanagement, Incident-Prozesse, Wartung und die Informationen, die Nutzern oder Betreibern bereitgestellt werden.

Wie tief einzelne Punkte auszuführen sind, hängt vom System ab. Bei einem regelbasierten, eng abgegrenzten KI-Modul wird die Architektur anders dokumentiert als bei einer Anwendung mit Sprachmodell, Retrieval-Komponente und mehreren angebundenen Fachsystemen. Die Prüflogik bleibt jedoch vergleichbar: Eine Aussage zur Funktionsweise muss sich mit Konfigurationen, Datenflüssen, Tests und Betriebsprozessen belegen lassen.

Für SAP-nahe Szenarien ist die Abgrenzung besonders relevant. Wenn ein KI-System beispielsweise Lieferantenrisiken bewertet und die Ergebnisse in einen Beschaffungsprozess zurückspielt, reicht es nicht, das Modell isoliert zu beschreiben. Dokumentiert werden müssen auch die Quellsysteme, Datenübergaben, Berechtigungen, fachlichen Freigaben und Folgen der Ausgabe im Prozess. Erst diese Kette zeigt, ob die menschliche Aufsicht praktisch wirksam ist.

Von Einzeldokumenten zu einer steuerbaren Nachweisstruktur

In vielen Projekten liegen benötigte Informationen bereits vor, jedoch verstreut: Architekturdiagramme im Projektwiki, Testprotokolle in Testmanagement-Werkzeugen, Datenflussanalysen in Datenschutzunterlagen, Rollenbeschreibungen im IAM-Konzept und Modellparameter in Entwicklungsumgebungen. Die Aufgabe besteht nicht darin, alles zu kopieren. Es braucht eine verbindliche Nachweisstruktur mit klarer Zuordnung zum jeweiligen KI-System und zu dessen Version.

Ein sinnvoller Start ist ein Dokumentationsregister. Es führt die erforderlichen Nachweise, ihren Speicherort, verantwortliche Rollen, Freigabestatus und den Bezug zu Systemversionen zusammen. Damit wird erkennbar, welche Inhalte fehlen, welche Artefakte veraltet sind und welche Nachweise vor einem Go-live geprüft werden müssen. Für Audits und interne Freigaben ist diese Transparenz oft wertvoller als ein umfangreiches, aber nicht gepflegtes Gesamtdokument.

Wichtig ist die Trennung zwischen fachlicher Verantwortung, technischer Verantwortung und Governance. Fachbereiche beschreiben Zweck, zulässige Nutzung und Prozessfolgen. Data- und KI-Teams verantworten Daten, Modellverhalten, Tests und technische Änderungen. Informationssicherheit, Datenschutz, Compliance und gegebenenfalls Recht prüfen Anforderungen in ihrem Zuständigkeitsbereich. Eine zentrale Rolle - etwa Product Owner oder KI-Systemverantwortlicher - sollte sicherstellen, dass diese Beiträge vollständig zusammengeführt und freigegeben werden.

Änderungen sind der kritische Punkt im Betrieb

Die technische Dokumentation ist kein Projektabschlussdokument. Sie verliert schnell an Aussagekraft, wenn Modell, Prompting, Datenquelle, Schnittstelle oder Entscheidungsschwelle geändert werden. Gerade bei Anwendungen mit externen Foundation Models können Anpassungen beim Anbieter, neue Modellversionen oder veränderte API-Funktionen Einfluss auf Leistung, Sicherheit und Risikoprofil haben.

Deshalb sollte das Change-Management dokumentationsrelevante Änderungen eindeutig kennzeichnen. Nicht jede Konfigurationsänderung erfordert denselben Prüfaufwand. Eine Anpassung der Benutzeroberfläche ist anders zu behandeln als eine neue Datenquelle, ein Modellwechsel oder die Ausweitung auf eine weitere Nutzergruppe. Unternehmen benötigen nachvollziehbare Kriterien dafür, wann Tests wiederholt, Risiken neu bewertet, Betriebsanweisungen angepasst oder Freigaben erneuert werden müssen.

Für produktionsnahe KI-Projekte empfiehlt sich die Verknüpfung mit bestehenden Release- und Cutover-Prozessen. Vor der Produktivsetzung sollten Systemversion, Teststand, offene Risiken, Rollenbesetzung, Monitoring und Rückfalloptionen dokumentiert freigegeben sein. Nach dem Go-live liefern Logs, Nutzerfeedback und Incident-Meldungen die Grundlage, um Annahmen aus der Entwicklungsphase zu überprüfen. So wird technische Dokumentation zum Steuerungsinstrument für einen stabilen Betrieb.

Typische Lücken und ihre Folgen

Ein häufiger Fehler ist die Konzentration auf das Modell bei gleichzeitiger Vernachlässigung des Gesamtsystems. Risiken entstehen jedoch häufig an Schnittstellen: durch unvollständige Stammdaten, unklare Datenübernahmen, fehlende Berechtigungsprüfung oder nicht definierte Übergaben an Fachprozesse. Eine weitere Lücke sind Kennzahlen ohne Kontext. Eine hohe Genauigkeit sagt wenig aus, wenn Testdaten nicht repräsentativ sind oder Fehlentscheidungen in bestimmten Fallgruppen schwerwiegende Folgen haben.

Ebenso problematisch sind pauschale Aussagen zur menschlichen Aufsicht. Es genügt nicht, dass ein Mensch theoretisch eingreifen kann. Dokumentiert werden sollte, wer eine Ausgabe prüft, welche Informationen dafür vorliegen, in welchem Zeitfenster Entscheidungen getroffen werden und wann das System nicht eingesetzt werden darf. In zeitkritischen Prozessen kann eine formale Freigabe ohne realistische Eingriffsmöglichkeit ihre Schutzwirkung verlieren.

Schließlich scheitert Dokumentation oft an fehlender Eigentümerschaft. Wenn nach dem Projekt niemand für Aktualisierung, Aufbewahrung und Nachweisführung zuständig ist, entstehen Lücken zwangsläufig. Eine dokumentierte Betriebsverantwortung mit festen Prüfintervallen ist daher keine Formalie, sondern Voraussetzung für revisionssicheres Reporting.

Dokumentation als Teil der KI-Governance aufsetzen

Unternehmen profitieren von einem gestuften Vorgehen. Zuerst wird das KI-Portfolio erfasst und nach Einsatz, Rolle, Datenbezug, Prozesskritikalität und möglicher Risikoklasse priorisiert. Anschließend lassen sich für die relevanten Systeme Dokumentationslücken gegen die vorhandenen Artefakte prüfen. Daraus entsteht ein umsetzbarer Maßnahmenplan, der nicht nur Anforderungen benennt, sondern Verantwortliche, Nachweise und Termine in die bestehende Projektsteuerung überführt.

Bei komplexen Daten- und Systemlandschaften sollte die technische Dokumentation mit Datenflussanalyse, Rollenmodell, Testmanagement und Informationssicherheitsprozessen verbunden werden. Das reduziert Doppelarbeit und verbessert die Qualität der Nachweise. Gleichzeitig bleibt sichtbar, welche Aussage auf welcher Datenbasis, Konfiguration und Testversion beruht.

Technische Nachweise gezielt strukturieren

Quteco kann in Quick Checks und Workshops Dokumentationslücken in KI- und Datenprojekten strukturiert erfassen und eine technische Nachweisarchitektur für Entwicklung, Test und Betrieb aufsetzen. Bei der Einordnung rechtlicher Anforderungen kann die rechtlich eigenständige Quteco Rechtsanwaltsgesellschaft mbH hinzugezogen werden. Ein klarer Nachweisstand schafft die Voraussetzung, KI-Systeme nicht nur kontrolliert einzuführen, sondern auch bei Änderungen verlässlich zu steuern.