Template: Technische Dokumentation nach Anhang IV

Wofür

Die technische Dokumentation ist das Dach-Artefakt der Hochrisiko-KI-Compliance: das zentrale Dossier, in dem ein Provider belegt, dass sein System die Anforderungen des EU AI Act erfüllt. Anders als ein Risk Assessment oder ein Logging-Konzept, die jeweils einen Teilaspekt abdecken, bündelt die technische Dokumentation alle anderen Nachweise zu einem konsistenten Ganzen und verweist auf sie. Sie richtet sich primär an Provider von Hochrisiko-KI-Systemen, die vor dem Inverkehrbringen nachweisen müssen, wie das System konzipiert, entwickelt, getestet und überwacht wird. Das Dokument ist lebend: Es wird über den gesamten Lebenszyklus fortgeschrieben und muss bei jeder wesentlichen Änderung am System aktualisiert werden. Dieses Template strukturiert die Pflichtinhalte so, dass sie sich auf bestehende Engineering-Artefakte abbilden lassen, statt parallele Prosa zu erzeugen.

Wann es Pflicht ist

Die Pflicht zur technischen Dokumentation ergibt sich aus Art. 11 EU AI Act (Verordnung (EU) 2024/1689) in Verbindung mit Anhang IV, der die Mindestinhalte auflistet. Sie gilt für Provider von Hochrisiko-KI-Systemen und muss erstellt sein, bevor das System in Verkehr gebracht oder in Betrieb genommen wird; danach ist sie aktuell zu halten. Die Dokumentation ist Voraussetzung der Konformitätsbewertung nach Art. 43 und Grundlage der EU-Konformitätserklärung. Sie verzahnt sich eng mit dem Risikomanagement (Art. 9), den Daten-Governance-Anforderungen (Art. 10), den Protokollierungsfunktionen (Art. 12), der menschlichen Aufsicht (Art. 14) sowie der Aufbewahrungspflicht für die Dokumentation selbst (Art. 18). Mit Enforcement-Wirksamkeit zum 02.12.2027 muss sie belegbar vorliegen, nicht erst geplant sein. Für KMU sieht die Verordnung eine vereinfachte Form vor; die inhaltlichen Themen bleiben dieselben.

Das Artefakt selbst

# Technische Dokumentation — <System-Name> / <Version>

## 0. Metadaten & Versionierung
- Provider (Organisation, Rolle):
- System-Name / Version / eindeutige Kennung:
- Erstellt am / Letzte Revision / nächste Review:
- Verantwortliche(r) (Name, Funktion):
- Rechtsraum des Inverkehrbringens (DE / EU27-Rest / UK / CH):

## 1. Allgemeine Beschreibung (Anhang IV Nr. 1)
- Zweckbestimmung, vorhersehbare Fehlanwendung:
- Interaktion mit Hard-/Software, Versionen, Varianten:
- Form der Bereitstellung (Software, eingebettet, API):

## 2. Systembeschreibung & Entwicklung (Nr. 2)
- Methoden und Entwicklungsschritte:
- Systemarchitektur, Komponenten, Rechenressourcen:
- Datenanforderungen (Verweis auf Daten-Governance, Art. 10):
- Menschliche Aufsicht (Verweis auf Art.-14-Konzept):
- Vorab festgelegte Änderungen & kontinuierliches Lernen:

## 3. Überwachung, Funktionsweise, Kontrolle (Nr. 3)
- Leistungsfähigkeit, Genauigkeitsmetriken, Grenzen:
- Bekannte/vorhersehbare Risiken für Betroffene:

## 4. Risikomanagement (Nr. 4)
- Verweis auf Risk Assessment nach Art. 9:

## 5. Lebenszyklus-Änderungen (Nr. 5)
- Vorgenommene Änderungen seit Erstversion:

## 6. Normen & Spezifikationen (Nr. 6)
- Angewandte harmonisierte Normen / sonstige Lösungen:

## 7. EU-Konformitätserklärung (Nr. 7)
- Verweis / Kopie:

## 8. Post-Market Monitoring (Nr. 8)
- Verweis auf PMM-Plan nach Art. 72:

Ausfüll-Anleitung

1. Metadaten und Versionierung zuerst: Jede Revision braucht Datum, Verantwortliche und einen Änderungsgrund — die Historie ist Teil des Nachweises, nicht Beiwerk.
2. Zweckbestimmung präzise (Abschnitt 1): Beschreiben Sie den intended purpose so eng wie möglich; eine zu weite Zweckbestimmung zieht zusätzliche Pflichten nach sich.
3. Auf Engineering-Artefakte verweisen (Abschnitt 2): Verlinken Sie Architektur-Diagramme, Datenblätter und Trainingsberichte, statt sie in Prosa zu duplizieren.
4. Metriken mit Grenzen (Abschnitt 3): Genauigkeitswerte ohne Angabe der Testbedingungen und bekannter Grenzen sind für Auditoren wertlos.
5. Nicht duplizieren, referenzieren (Abschnitt 4): Das Risikomanagement lebt im Art.-9-Dokument; hier nur verlinken und den Stand benennen.
6. Änderungen lückenlos (Abschnitt 5): Jede wesentliche Änderung am System gehört nachvollziehbar in die Lebenszyklus-Historie.
7. Normen benennen (Abschnitt 6): Geben Sie an, welche harmonisierten Normen angewendet wurden — oder begründen Sie die alternative Lösung.
8. Aktualität sicherstellen (Abschnitt 8): Verknüpfen Sie das Dossier mit dem Post-Market-Monitoring, damit Felderkenntnisse zurückfließen.

Audit-Erwartung

Auditoren behandeln die technische Dokumentation als Einstiegspunkt: Von hier aus prüfen sie, ob die verlinkten Teil-Artefakte tatsächlich existieren, datiert und konsistent sind. Erwartet werden eine vollständige Abdeckung der Anhang-IV-Punkte, eine erkennbare Versionierung mit Änderungshistorie, ein eindeutiger Bezug zwischen Zweckbestimmung und getroffenen Maßnahmen sowie Genauigkeitsangaben, die mit den Testberichten übereinstimmen. Ein häufiger Mangel ist die „eingefrorene" Dokumentation, die den aktuellen Systemstand nicht mehr abbildet — Prüfer gleichen Versionsstände von Modell, Code und Dossier ab. Lückenhafte Verweise auf nicht auffindbare Anlagen werten den Nachweis ab.

Verwandte Artefakte

• Template: AI Risk Assessment nach Art. 9 — das Risikomanagement, auf das Abschnitt 4 verweist.
• Template: Grundrechte-Folgenabschätzung (AISIA) nach Art. 27 — Deployer-seitiges Pendant für den Einsatzkontext.
• Für die Frage, ob Ihr Use-Case überhaupt hochrisiko ist und unter Anhang III fällt: die Use-Case-Bibliothek auf hochrisiko-ki.com.
• Vertiefender Kontext zu Provider-Pflichten im Gesamtbild des EU AI Act: Leitfaden auf eu-ai-verordnung.de.

AEGIRA AI Guardian operationalisiert diese Artefakte als laufende, evidenzbasierte Trust-Infrastructure — aegira.ai.