EU-AI-Act-Audit-Logs — was Sie ab 2027 wirklich protokollieren müssen

„Wir loggen doch schon alles in Elastic." Diese Antwort hören wir im Mittelstand oft, wenn es um Compliance-Pflichten nach dem EU AI Act geht. Sie ist selten korrekt. Die Verordnung (EU) 2024/1689 verlangt keine beliebigen Logs — sie verlangt revisionssichere, automatisch erzeugte Protokolle mit definiertem Mindestinhalt, die eine nachträgliche Nachvollziehbarkeit von Einzelentscheidungen sicherstellen. Dieser Artikel zeigt, wo der Unterschied liegt, welche Artikel relevant sind und wie eine produktionstaugliche Toolchain für den Mittelstand aussieht.

Artikel 12 und 19: Was der Gesetzgeber verlangt

Artikel 12 („Aufzeichnungspflichten") adressiert den Anbieter eines Hochrisiko-KI-Systems. Das System muss automatische Protokolle über Ereignisse („logs") während der gesamten Lebensdauer führen. Ziel: Rückverfolgbarkeit von Entscheidungen, Identifikation von Situationen, die zu einer Risikostufe führen könnten, sowie Unterstützung bei der Nachmarktbeobachtung.

Artikel 19 („Aufbewahrung der Protokolle") verpflichtet den Betreiber (Deployer), diese Logs so lange aufzubewahren, wie es dem Zweck angemessen ist — mindestens sechs Monate, sofern keine anderen Rechtsvorschriften längere Fristen vorsehen. Banken mit BAIT-Bezug landen schnell bei zehn Jahren GoBD-Aufbewahrung, KRITIS-Betreiber bei branchenspezifischen Vorgaben.

Die Pflichten gelten nicht nur für Anbieter, sondern auch für Unternehmen, die ein Hochrisiko-System im eigenen Namen einsetzen — beispielsweise einen KI-gestützten Personalauswahl-Assistenten (Anhang III, Punkt 4). Wer Llama 3.3 on-prem für HR-Screening nutzt, ist Deployer eines Hochrisiko-Systems und fällt unter Artikel 26.

Mindestinhalt eines regelkonformen Log-Eintrags

Die Verordnung selbst bleibt teilweise abstrakt. Der Entwurf der harmonisierten Normen (JTC 21 und die Leitlinien des AI Office vom Dezember 2025) konkretisieren jedoch, was „automatische Aufzeichnung" in der Praxis bedeutet.

Feld	Inhalt	Begründung
timestamp	ISO-8601 mit Zeitzone und Millisekunden	Art. 12 — zeitliche Rückverfolgbarkeit
request_id	UUID v7 (zeitsortierbar)	Eindeutige Korrelation über Dienste
user_id	Pseudonymisierte Nutzerreferenz	Nachvollziehbarkeit + DSGVO-Minimierung
input	Prompt, Systemrolle, Parameter	Art. 12 Abs. 2 a — Eingangslage
output	Vollständige Modellausgabe	Nachträgliche Bewertung der Entscheidung
model_version	Name, Checksum, Quantisierung	Art. 12 Abs. 2 b — Referenz der Version
context_sources	RAG-Dokument-IDs + Hashes	Nachvollzug von Grounding
confidence	Log-Probs oder Score	Bewertung der Entscheidungsgüte
tool_calls	Name, Parameter, Ergebnis	Art. 12 Abs. 2 c — Agenten-Aktionen
deployer_feedback	Korrekturen, Freigaben	Nachmarktbeobachtung (Art. 72)

Ein minimalistischer JSON-Datensatz umfasst damit rund 1–4 KB, realistisch wird durch eingebettete Dokumentauszüge schnell das Zehnfache. Bei 100.000 Anfragen pro Monat sind 5–40 GB pro Monat zu erwarten — bei drei Jahren Aufbewahrung überschaubare 200–1500 GB, deutlich unter den Kapazitäten üblicher Log-Infrastrukturen.

Revisionssichere Speicherung: Hash-Chains und WORM

„Revisionssicher" ist ein GoBD-Begriff, der im EU AI Act nicht wörtlich auftaucht, aber über Artikel 12 Abs. 1 faktisch gefordert wird: Die Logs müssen so beschaffen sein, dass spätere Manipulation erkennbar ist. Zwei Muster haben sich durchgesetzt.

Hash-Chains (Merkle-Style)

Jeder Log-Eintrag enthält den SHA-256-Hash des Vorgängers. Änderungen an einem Eintrag invalidieren die gesamte Kette. Die wöchentliche Veröffentlichung des aktuellen Kopf-Hashes in einer internen Stempelung (zum Beispiel als signierter Eintrag in einer separaten, nur lesbaren Tabelle) genügt in der Regel als Manipulationsnachweis — ohne externe Blockchain-Komplexität.

WORM-Storage

„Write Once, Read Many" — objektbasiert über S3 Object Lock, dateibasiert über chattr +i oder über spezialisierte Appliances. Kombiniert mit Retention-Policies erfüllt eine MinIO-Instanz im Compliance-Modus die Anforderungen auch für GoBD und BAIT. Wichtig: Die Retention-Policy muss systemseitig durchgesetzt werden, nicht nur organisatorisch dokumentiert.

Der Konflikt DSGVO vs. AI Act — und wie er aufgelöst wird

DSGVO Art. 17 verlangt die Löschung personenbezogener Daten auf Antrag. AI Act Art. 19 verlangt die Aufbewahrung von Logs. Auf den ersten Blick ein Widerspruch — in der Praxis lösen wir ihn über drei Techniken.

Pseudonymisierung am Edge

Vor dem Schreiben in den Audit-Log werden Personenbezüge durch Token ersetzt. Statt „Max Mustermann, max@acme.de" steht im Log „P-a7f3e2b1" — der Log-Inhalt bleibt vollständig, der Personenbezug liegt in einer getrennten, löschbaren Mapping-Tabelle.

Redaction mit Präsidio

Microsoft Presidio (open-source, lokal betreibbar) erkennt Namen, IBANs, Telefonnummern und Kontextdaten. Im Output-Pfad ersetzen wir Fundstellen durch typisierte Platzhalter (<PERSON>, <IBAN>). Das Urmaterial wandert verschlüsselt in einen separaten, schneller löschbaren Bereich.

Rechtfertigung

Art. 17 Abs. 3 DSGVO sieht ausdrücklich Ausnahmen für Aufbewahrungspflichten aus Unionsrecht vor. Der AI Act ist Unionsrecht. Ein Lösch-Antrag greift also nicht vollständig — wohl aber auf die pseudonymisierende Mapping-Tabelle. Der Audit-Log bleibt, der Personenbezug ist aufgehoben. Diese Argumentation gehört in jedes Verarbeitungsverzeichnis und in die DSFA.

Eine Toolchain, die 2026 funktioniert

Unsere Referenzarchitektur im Mittelstand basiert auf vier Bausteinen, die alle on-prem betrieben werden und durchgehend open source oder hybrid sind.

OpenTelemetry als Transportschicht

OTel-Instrumentierung auf vLLM-Seite (über den openllmetry-Fork) und in der Applikation. Traces gehen an einen zentralen Collector — Vorteil: Ein Tracing-Standard für Apps und KI, keine separaten Pipelines.

Langfuse on-prem als LLM-Observability

Langfuse läuft als Docker-Stack im eigenen Rechenzentrum, speichert Traces strukturiert in PostgreSQL und ClickHouse, bietet Evaluationen, Cost-Tracking und Prompt-Versionierung. Die Oberfläche ist bei Audits gold wert, weil Einzelanfragen mit einem Klick nachvollziehbar sind.

Helicone on-prem als Gateway-Log

Für Teams, die eine OpenAI-kompatible API bereitstellen, ist Helicone (self-hosted) ein sauberer Proxy, der jede Anfrage vollständig protokolliert. Ideal in Kombination mit vLLM als Backend.

Loki + Grafana für Operations

Die betriebliche Schicht bleibt bei bewährten Tools. Strukturierte JSON-Logs fließen in Loki, Dashboards visualisieren Latenz, Fehlerquoten, Scanner-Treffer und Compliance-Kennzahlen. Die Retention-Policy auf Loki-Seite bleibt kurz (30 Tage); archiviert wird in MinIO.

Komponente	Rolle	Retention
OpenTelemetry	Tracing-Transport	nicht persistent
Langfuse	LLM-Observability, Audit-Recherche	12 Monate hot
Helicone	Gateway-Log, API-Proxy	6 Monate hot
Loki	Operations-Logs	30 Tage
MinIO (Object Lock)	WORM-Archiv	36 Monate
PostgreSQL	Hash-Chain / Integritätsnachweis	36 Monate

Umsetzungsplan für bestehende Systeme

1. Inventar: Welche KI-Systeme fallen unter Anhang III? HR-Screening, Kreditentscheidung, biometrische Identifikation sind typische Kandidaten.
2. Gap-Analyse: Vorhandene Logs gegen den Mindestinhalt abgleichen. Oft fehlen Modellversion, Kontextquellen und Tool-Aufrufe.
3. Architektur-Entscheid: OpenTelemetry + Langfuse einführen, Loki-Pipeline erweitern, MinIO-Compliance-Bucket bereitstellen.
4. Pseudonymisierung: Presidio als Redaction-Stufe integrieren, Mapping-Tabelle in getrennter Datenbank.
5. Hash-Chain: PostgreSQL-Tabelle mit Trigger-Logik, täglicher Kopf-Hash in signiertem Read-Only-Record.
6. DSFA aktualisieren: Konflikt DSGVO/AI Act dokumentieren, Rechtsgrundlagen und Löschkonzept festhalten.
7. Audit-Probelauf: Simulierte Behördenanfrage, Wiederherstellung eines einzelnen Requests mit vollständigem Kontext.

Erfahrungsgemäß ist Schritt 6 der zeitkritische Punkt. Ohne saubere juristische Einordnung lassen sich technische Maßnahmen nicht freigeben. Planen Sie 4–6 Wochen für die DSFA-Überarbeitung ein, parallel zur Architektur-Umsetzung.

Häufige Fragen