EU-KI-Verordnung Artikel 12: Was 'Logs und Aufzeichnungen' in der Praxis bedeutet

Was Art. 12 tatsächlich verlangt

Art. 12 der Verordnung (EU) 2024/1689 — der EU-KI-Verordnung — steht im strukturellen Zentrum der Pflichten für Hochrisiko-KI-Systeme. Sein Titel „Aufzeichnungspflichten" lässt die Vorschrift verwaltungstechnisch klingen. Liest man den Text, zerfällt dieser Eindruck.

Art. 12 Abs. 1 ist die operative Verpflichtung: Hochrisiko-KI-Systeme müssen „technisch die automatische Aufzeichnung von Vorgängen ('Protokollen') während der Lebensdauer des Systems ermöglichen." Zwei Formulierungen tragen das Gewicht. „Technisch ermöglichen" schließt eine Logging-Richtlinie aus, die davon abhängt, dass Betreiber sie aktivieren. „Während der Lebensdauer" erstreckt die Pflicht über das initiale Deployment hinaus — durch jedes Update, jede Retraining-Runde und jede Konfigurationsänderung.

Art. 12 Abs. 2 verlangt, dass die Protokollierungsfunktionen „ein dem Zweckbestimmungs-Niveau entsprechendes Maß an Rückverfolgbarkeit der Funktionsweise des KI-Systems gewährleisten." Beachten Sie den Maßstab: nicht ein Maß an Detailtiefe, nicht ein Maß an Ausführlichkeit — ein Maß an Rückverfolgbarkeit. Das Kriterium ist, ob ein Dritter rekonstruieren kann, was passiert ist.

Art. 12 Abs. 3 zählt vier verpflichtende Log-Ziele für Hochrisiko-Systeme nach Anhang III Nr. 1 Buchst. a (biometrische Fernidentifizierung) auf: den Zeitraum jeder Verwendung, die abgeglichene Referenzdatenbank, die Eingabedaten, die zu einem Treffer führten, und die natürlichen Personen, die an der Ergebnisüberprüfung beteiligt waren. Andere Anhang-III-Kategorien erben die allgemeine Rückverfolgbarkeitspflicht aus Art. 12 Abs. 1–2 ohne diese spezifische Aufzählung, aber das Prinzip skaliert: Was eine zuständige Behörde benötigt, um eine Fehlfunktion oder ein diskriminierendes Muster zu untersuchen, muss aus dem Protokoll wiederherstellbar sein.

Die festgelegte Kategorienpaarung der KI-Verordnung stellt Art. 12 neben Art. 14 (menschliche Aufsicht). Sie sind so konzipiert, dass sie zusammenwirken: Art. 12 erzeugt die Belege; Art. 14 ist der menschliche Prüfer, der sie liest. In unserem Kategorierahmen bilden diese beiden Verpflichtungen Cat 2 — Artikel 12 (Protokollierung) und Artikel 14 (menschliche Aufsicht) sind die Nachweis-Kategorie, in der die vom System erzeugten Artefakte für eine Person prüfbar sind, die nicht im Anfragepfad war. Eine Logging-Implementierung, die keine prüfbaren Artefakte hervorbringt, scheitert an beiden Artikeln gleichzeitig.

Was „automatisch" in der Implementierung bedeutet

Die meisten Teams, die Art. 12 lesen, greifen zunächst auf ihre bestehende Anwendungsprotokollierung zurück. Die Anwendung emittiert strukturiertes JSON an einen Log-Aggregator. Der Aggregator persistiert in Object Storage. Es gibt eine Aufbewahrungsrichtlinie. Fertig.

Mit dieser Vorstellung deckt sich Art. 12 Abs. 1 nicht. Tragend ist hier das Wort „automatisch": es zieht eine Trennlinie zwischen einer Protokollierung, die als Nebenprodukt des Systembetriebs entsteht, und einer, die nur deshalb entsteht, weil eine Entwicklerin im richtigen Moment an eine log.info-Zeile gedacht hat. Aus Sicht der Verordnung ist nur das erste „automatisch".

Ein nützlicher Test: Fragen Sie sich, ob Ihre Logs noch existieren würden, wenn jedes Mitglied Ihres Engineering-Teams morgen durch Personen ersetzt wäre, die den Anwendungscode noch nie gesehen haben. Lautet die Antwort „nein, sie müssten erst verstehen, welche Funktionen instrumentiert sind", ist Ihre Protokollierung richtlinienbasiert. Der Maßstab nach Art. 12 liegt näher bei „das System erzeugt Aufzeichnungen kraft seines Betriebs" als bei „das System erzeugt Aufzeichnungen, weil wir es so konfiguriert haben."

Anwendungs-Layer-Logging trägt diese Last schlecht, weil jede Lücke im Logging-Pfad zugleich eine Lücke in der Compliance-Position ist: ein nicht instrumentierter Endpunkt, eine Retry-Schleife, die einen Fehler vor dem Schreiben verschluckt, ein neuer Pfad, an den niemand gedacht hat. Solche Fehlermodi tauchen in einem Code-Review nur dann auf, wenn die Prüferinnen ausdrücklich nach Logging-Abdeckung suchen. Und selbst dann ist die Prüfung selbst nur eine Richtlinie über einer Richtlinie — der Maßstab nach Art. 12 Abs. 1 wird damit gerade nicht erreicht.

Architekturelle Protokollierung verlagert das Aufzeichnungsverhalten stattdessen aus der Anwendung heraus: an das Gateway, den Proxy, den Audit-Dienst, die Datenbank. Die Anwendung wird zum Teilnehmer eines Logging-Systems statt zum Erzeuger der Logs. Das ist im Aufbau teurer. Es ist auch die einzige Konstellation, die Fail-Closed funktioniert.

Die Rückverfolgbarkeitslücke, die die meisten Teams übersehen

An Art. 12 Abs. 2 scheitern die meisten produktiven LLM-Anwendungen leise. Eingabe und Ausgabe zu erfassen genügt nämlich gerade nicht — eine Behörde, die einen Vorfall aufarbeitet, sucht keine Logzeile pro API-Aufruf, sondern eine durchgehende Kausalkette von der Anfrage bis zur Wirkung.

Stellen Sie sich eine Hochrisiko-LLM-Anwendung vor, die Bewerbungen vorprüft. Eine Bewerberin wird abgelehnt. Ihr Anwalt verlangt die Begründung der Entscheidung. Was muss das System offenlegen?

Eine naive Logzeile lautet vielleicht: request_id=abc123 input="<prompt>" output="reject" latency_ms=412. Das erfasst Eingabe und Ausgabe, rekonstruiert aber nicht die Entscheidung. Der Anwalt kann aus dieser Zeile nicht entnehmen, welche Modellversion verwendet wurde, ob ein Content-Filter eingegriffen hat, was der System-Prompt sagte, wie die Temperature eingestellt war, ob Retrieval-Augmented Generation externen Kontext einspeiste, was dieser Kontext war, oder ob eine nachgelagerte Regel den Modelltext in das binäre „Ablehnung" überführte.

Der Maßstab für Rückverfolgbarkeit aus Art. 12 Abs. 2 verlangt die Antwort auf all diese Fragen. Die Kausalkette läuft: Eingabe trifft ein → Vorverarbeitung (Sanitisierung, Prompt-Zusammenstellung, Retrieval) → Modellaufruf (mit benannter Version + Parametern) → Nachverarbeitung (Content-Filterung, Output-Parsing, Regelanwendung) → Endgültige Entscheidung gegen die ursprüngliche Eingabe protokolliert.

Ein funktionierendes Kausalketten-Log erfasst alle fünf Stufen mit stabilen Identifikatoren, die zur Anfrage zurückverweisen. Die meisten LLM-Anwendungen protokollieren nur Stufe eins und Stufe fünf, wobei alles dazwischen entweder implizit ist oder im Datensatz fehlt. Diese Lücke ist die Art. 12-Verletzung, nach der Behörden suchen werden, sobald die Anhang-III-Durchsetzung am 2. August 2026 beginnt.

Was „angemessene" Aufbewahrung bedeutet

Art. 12 nennt keine konkrete Aufbewahrungsdauer. Art. 19 verpflichtet Anbieter von Hochrisiko-KI-Systemen, die vom System erzeugten Protokolle „für einen dem Zweck des Hochrisiko-KI-Systems angemessenen Zeitraum" aufzubewahren — mindestens sechs Monate, „sofern in geltendem Unionsrecht oder nationalem Recht, insbesondere im Unionsrecht zum Schutz personenbezogener Daten, nichts anderes vorgesehen ist."

Diese Sechs-Monats-Untergrenze steht in Spannung zu Art. 5 Abs. 1 Buchst. e DSGVO, der vorschreibt, dass personenbezogene Daten „in einer Form gespeichert werden, die die Identifizierung der betroffenen Personen nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist." Wenn Ihre Protokolle personenbezogene Daten enthalten — und Hochrisiko-KI-Logs tun das oft konstruktionsbedingt, weil der Gesetzgeber Entscheidungen über bestimmte Personen untersuchbar machen will — dann ist die Aufbewahrungsdauer nach oben durch die Speicherbegrenzung der DSGVO und nach unten durch die Sechs-Monats-Schwelle der KI-Verordnung beschränkt.

Die ehrliche Antwort lautet: Die richtige Aufbewahrungsdauer hängt von der Risikoklassifizierung des KI-Anwendungsfalls, dem absehbaren Untersuchungshorizont und der Rechtsgrundlage der Aufbewahrung ab. Für ein LLM zur Kreditentscheidung kann der relevante Horizont das Recht der Antragstellerin auf Rechtsbehelf nach nationalem Verbraucherkreditrecht sein. Für ein LLM in der medizinischen Triage kann es sich über die volle Aufbewahrungspflicht für medizinische Akten erstrecken. Für ein LLM im Recruiting orientiert es sich an den Verjährungsfristen des Antidiskriminierungsrechts.

Was Art. 12 verlangt, ist, dass die gewählte Dauer bewusst gewählt ist. Eine Aufbewahrungsrichtlinie nach dem Motto „wir behalten Logs, bis unser Object Storage zu teuer wird", ist nicht angemessen. Eine Richtlinie nach dem Motto „wir behalten Logs für N] Monate, weil das das maximale Fenster ist, in dem eine Behörde nach [konkretem Gesetz] eine Untersuchung eröffnen könnte", ist angemessen. Die Begründung muss schriftlich existieren und eine Konformitätsbewertung nach [Art. 43 überstehen.

Spezifisch für deutsche Aufsichtsstrukturen ist dabei zu erwarten, dass BfDI und die Landesdatenschutzbehörden den Maßstab „angemessen" nicht isoliert nach KI-Verordnung lesen, sondern an die bestehende DSGVO-Auditpraxis nach §§ 27 ff. BDSG anschließen. Wer bereits ein Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO mit definierten Aufbewahrungsfristen pflegt, kann Art. 12-Logs in dieselbe Systematik einhängen — separate Datenkategorie, separate Frist, separate Rechtsgrundlage. Behörden lesen einen solchen Anhang erfahrungsgemäß als Beleg für „bewusst gewählt"; eine pauschale Übernahme der allgemeinen Aufbewahrungsfrist des Unternehmens dagegen lädt zur Nachfrage ein. Praktisch heißt das: die Art. 12-Aufbewahrung gehört in das VVT, nicht in die Compliance-Wiki-Seite daneben.

Ein konkreter Logging-Vertrag für eine LLM-Anwendung

Im Folgenden steht ein Logging-Vertrag, den ein Hochrisiko-LLM-System erfüllen sollte. Er ist nicht erschöpfend — Ihr konkreter Anhang-III-Anwendungsfall mag mehr verlangen — aber er ist das Minimum, das wir in der Implementierungspraxis als ausreichend für den Rückverfolgbarkeitsstandard nach Art. 12 Abs. 2 ermittelt haben.

Für jede Anfrage muss das Protokoll enthalten:

• Eine stabile, global eindeutige Anfrage-ID. Im Gateway erzeugt, durch jeden nachgelagerten Dienst weitergereicht, in den endgültigen gespeicherten Datensatz geschrieben. Ohne diese kann die Kausalkette über Dienstgrenzen hinweg nicht rekonstruiert werden.
• Einen Eingabe-Hash. Nicht in jedem Fall die Eingabe selbst (was einen DSGVO-Konflikt erzwingen würde), sondern einen Hash, der einer Behörde erlaubt zu bestätigen, dass der gespeicherte Datensatz einem konkret eingereichten Prompt entspricht, wenn der Nutzer das Original vorlegt.
• Ein Sanitisierungs-Manifest. Welche Felder als personenbezogen erkannt wurden. Welche Erkennungsregeln gegriffen haben. Was die Redaktionsersetzungen waren. Das ist die Brücke zwischen der Rückverfolgbarkeitspflicht der KI-Verordnung und der Datenminimierungspflicht aus Art. 25 DSGVO.
• Modellidentität und -version. Nicht nur „GPT-4" — der konkrete Upstream-Modellbezeichner, das Datum, an dem das Modell ins Deployment geladen wurde, und jeder angewendete fein-getunte Adapter. Modelle ändern sich. Datensätze müssen die Version festhalten.
• Die Modellparameter. Temperature, Top-p, Max Tokens, System-Prompt, alle Tool-Definitionen. Ein anderer System-Prompt ist ein anderes System. Der Datensatz muss sagen, welcher verwendet wurde.
• Die Entscheidungsausgabe in der Form, in der das Modell sie erzeugt hat. Getrennt von jeder nachgelagerten Verarbeitung. Nachverarbeitungsregeln dürfen greifen, aber die rohe Modellausgabe ist das Artefakt, das eine Behörde unabhängig prüfen will.
• Die nachgelagerten Aktionen. Hat ein Content-Filter eingegriffen? Hat eine Routing-Regel die Antwort verändert? Hat ein integrierter Workflow eine Aktion ausgeführt (E-Mail versendet, Datensatz aktualisiert, Kredit verweigert)? Jede nachgelagerte Aktion ist Teil der Kausalkette.
• Aufbewahrungsklasse und Löschzeitpunkt. Nicht die Richtlinie in einem anderen System — der konkrete Ablaufzeitpunkt, der diesem konkreten Datensatz zugeordnet ist. Aufbewahrung ist eine Eigenschaft des Logs, nicht eine Eigenschaft der Speicherstufe.

Ein Protokoll, das diese acht Anforderungen erfüllt, übersteht die Art von Untersuchung, die Art. 12 Abs. 2 erwartet. Ein Protokoll, dem eine fehlt, lässt eine Lücke, die eine Behörde benennen kann.

Wo Lucairn ansetzt

Das Lucairn-Gateway sitzt zwischen Ihrer Anwendung und dem Upstream-LLM-Anbieter. Jede Anfrage, die das Gateway passiert, erzeugt einen Datensatz, der den oben skizzierten Acht-Punkte-Vertrag erfüllt. Der Datensatz wird von einem in-Process-Witness-Dienst mit einem Schlüssel signiert, den das Upstream-Modell nie sieht, gegen einen öffentlichen RFC-3161-Zeitstempel-Dienst (FreeTSA) zeitgestempelt und in ein öffentliches Sigstore-Rekor-Transparenzlog eingetragen, sodass der Inklusionsbeweis selbst zum Nachweis dafür wird, dass der Datensatz zum gestempelten Zeitpunkt existierte.

Das ist für die Art. 12-Compliance in zwei konkreten Punkten relevant. Erstens erfasst das Gateway die Kausalkette an dem Punkt, an dem sie tatsächlich existiert — an der Grenze zwischen Ihrem Code und dem Modell — statt sich darauf zu verlassen, dass die Anwendung jeden Schritt selbst protokolliert. Zweitens liefern die Witness-Signatur und der Rekor-Inklusionsbeweis manipulationssichere Logs, die eine Kompromittierung des Betreibers überstehen. Eine Behörde, die fragt „Woher wissen wir, dass Ihre Entwickler einen Datensatz nicht im Nachhinein still überschrieben haben?", erhält eine kryptografische statt einer prozeduralen Antwort. Die Implementierung im Detail unter audit-trail-for-ai.

Die Split-Knowledge-Architektur bedeutet zusätzlich, dass das Modell die rohen Identitätsdaten der Nutzer nie sieht — die Pseudonymisierung erfolgt vorgelagert zum Modellaufruf. Art. 12 verlangt, dass Sie rekonstruieren können, was die KI getan hat. Er verlangt nicht, der KI mehr Informationen zu geben, mit denen sie es tun kann. Im Gegenteil: Die Präferenz des Gesetzgebers ist umgekehrt — je weniger personenbezogene Daten das Modell berührt, desto kleiner ist die Angriffsfläche für einen späteren Anspruch auf Rechtsbehelf.

Für Teams, die auf den 2. August 2026 hinarbeiten, zählt operativ, ob ihre Logging-Architektur die erste Untersuchung nach Art. 12 übersteht. Die Durchsetzung selbst steht fest — das Datum ist gesetzt, und die Anhang-III-Kategorien werden ab dem ersten Tag in den Fokus rücken. Der Acht-Punkte-Vertrag ist ein nützlicher Selbsttest. Fehlt einer der acht Punkte in Ihren aktuellen Logs, haben Sie noch Zeit, das zu beheben, bevor Behörden anfangen zu fragen.