EU AI Act: Technische Dokumentation

EU AI Act: Technische Dokumentation bezeichnet das strukturierte Nachweis-Paket, mit dem Anbieter (Provider) und in Teilen auch Betreiber (Deployer) eines KI-Systems belegen, dass ihr System die Anforderungen des EU AI Act erfüllt. Es bündelt Informationen zu Modell und Zweck, Daten, Risikomanagement, Tests, Betrieb, Monitoring und Governance – damit Behörden, Auditoren und interne Stakeholder die Konformität nachvollziehen können.

Was gehört typischerweise in die technische Dokumentation?

Der Umfang hängt stark davon ab, ob es sich um ein Hochrisiko-System oder z. B. ein General-Purpose-Modell handelt. In der Praxis umfasst die Dokumentation häufig:

• Systembeschreibung & Zweck: Was macht das System, für welche Use Cases ist es gedacht, welche Grenzen sind bekannt (z. B. keine Rechtsberatung)? Bei Generative KI (Generative AI) zusätzlich: Art der Ausgaben, Sicherheitsziele, Moderationslogik.
• Modell- und Architekturdetails: Versionen, Abhängigkeiten, Trainings-/Inference-Setup, ggf. verwendetes Large Language Model (LLM), Fine-Tuning-Ansatz (z. B. Fine-Tuning oder LoRA), Schnittstellen wie Function Calling / Tool Use.
• Daten-Dokumentation: Herkunft, Auswahlkriterien, Datenqualität, Labeling-Prozesse, Bias-Risiken, Datenaufbewahrung und Datenflüsse. Relevante Datenschutz-Aspekte werden mit Datenschutz (DSGVO/GDPR) & KI verzahnt (z. B. Rechtsgrundlage, PII-Handling, Löschkonzepte).
• Risikomanagement: Identifizierte Risiken (z. B. Halluzinationen, Diskriminierung, Prompt Injection), Maßnahmen und Restrisiken. Hier ist die Verbindung zu AI Risk Assessment (KI-Risikobewertung) und AI Governance zentral.
• Tests, Evaluierung & Nachweise: Testpläne, Metriken, Ergebnisse, Robustheit, Sicherheits- und Qualitätsprüfungen. Für LLM-Workflows oft mit Evaluation (Eval) & Benchmarking, Red-Team-Ansätzen wie Red Teaming (KI-Red-Teaming), sowie Regressionen (z. B. Regression Testing für Prompts/Agents).
• Betrieb & Monitoring: Deployment-Architektur, Logging, Incident-Prozesse, Drift-Erkennung (z. B. Model Drift (Modell-Drift)), Observability (z. B. Model Monitoring & Observability (LLMOps)), Rollback-Strategien und Change-Management.
• Human Oversight & Gebrauchsanweisung: Rollen, Freigaben, Eskalationspfade, Grenzen der Automatisierung (z. B. Human-in-the-Loop (HITL)), Nutzerhinweise und Schulungsunterlagen.

Wie funktioniert das in der Praxis (Beispiel)?

Ein Unternehmen integriert ChatGPT in einen Support-Workflow, ergänzt durch RAG (Retrieval-Augmented Generation) mit internen Wissensartikeln. Die technische Dokumentation beschreibt dann u. a.:

• welche Daten in die Vektordatenbank (Vector Database) fließen, wie sie bereinigt werden (z. B. PII Redaction (PII-Schwärzung)) und wie Aktualisierungen versioniert sind,
• welche Prompt- und Guardrail-Regeln gelten (z. B. Guardrails (KI-Leitplanken), Abwehr von Prompt Injection),
• welche Evals sicherstellen, dass Antworten korrekt, nicht beleidigend und nicht datenschutzwidrig sind,
• wie Monitoring und Incident-Handling laufen, falls es zu Fehlantworten oder Datenabfluss kommt (z. B. Prompt Leakage (Prompt-Datenabfluss)).

Warum ist die technische Dokumentation so wichtig?

Sie ist der zentrale Beleg für „Compliance by Design“: Ohne nachvollziehbare Dokumentation sind Konformitätsbewertung, Audits, interne Freigaben und sichere Skalierung kaum möglich. Gleichzeitig hilft sie operativ – als „Single Source of Truth“ für MLOps/LLMOps, Security, Legal und Produktteams.

Hinweis: Der EU AI Act ist der rechtliche Rahmen; die technische Dokumentation ist das praktische Artefakt, das diesen Rahmen in überprüfbare Nachweise übersetzt (siehe auch EU AI Act).