Das LLM-Audit-Log-Schema für Artikel 12 EU AI Act

Was Artikel 12 verlangt — und was nicht

Artikel 12 Abs. 1 KI-VO: „Die Technik der Hochrisiko-KI-Systeme muss die automatische Aufzeichnung von Ereignissen (im Folgenden ‚Protokollierung‘) während des Lebenszyklus des Systems ermöglichen.“ Tragend ist das Wort automatisch. Ein Verfahren, bei dem ein Entwickler auf Anfrage ein Transkript exportieren kann, ist keine Protokollierungsfunktion, sondern ein Mensch. Ein Datensatz, der nur entsteht, weil sich jemand dafür entschieden hat, genügt Abs. 1 nicht.

Artikel 12 Abs. 2 liefert anschließend einen Zwecktest statt einer Feldliste: „Zur Gewährleistung, dass das Funktionieren des Hochrisiko-KI-Systems in einem der Zweckbestimmung des Systems angemessenen Maße rückverfolgbar ist, ermöglichen die Protokollierungsfunktionen die Aufzeichnung von Ereignissen, die für Folgendes relevant sind: a) die Ermittlung von Situationen, die dazu führen können, dass das Hochrisiko-KI-System ein Risiko im Sinne des Artikels 79 Absatz 1 birgt oder dass es zu einer wesentlichen Änderung kommt, b) die Erleichterung der Beobachtung nach dem Inverkehrbringen gemäß Artikel 72 und c) die Überwachung des Betriebs der Hochrisiko-KI-Systeme gemäß Artikel 26 Absatz 5.“ Beachten Sie die Reichweite von Buchstabe a — Situationen, die dazu führen können, nicht nur Situationen, die es bereits sind.

Mehr steht dort nicht. Es gibt eine konkrete Feldliste in Artikel 12 — Absatz 3: Aufzeichnungszeitraum jeder Verwendung, abgeglichene Referenzdatenbank, Eingabedaten mit Treffer und die an der Überprüfung beteiligten natürlichen Personen. Sie gilt ausschließlich für Systeme nach Anhang III Nummer 1 Buchstabe a, also biometrische Fernidentifizierung. Wenn Sie einen Assistenten zur Schadenvorprüfung oder ein RAG-System zur Dokumentenprüfung betreiben, bindet Sie kein Wort davon — und wer die Liste trotzdem abschreibt, erhält ein Schema, das zu einem Gesichtserkennungssystem passt und nicht zum eigenen.

Bei der Aufbewahrung wird es konkret. Anbieter bewahren die Protokolle nach Artikel 19 auf, Betreiber nach Artikel 26 Abs. 6, und beide sagen dasselbe: einen dem Zweck angemessenen Zeitraum, mindestens sechs Monate, sofern Unions- oder nationales Recht nichts anderes bestimmt — wobei das Datenschutzrecht ausdrücklich als mögliche Ausnahme genannt ist. Beide schränken die Pflicht zudem darauf ein, „soweit diese Protokolle ihrer Kontrolle unterliegen“ — das ist der gesetzliche Anknüpfungspunkt für die Eigentumsfrage, auf die ich in „Wo Sie den Datensatz schreiben“ zurückkomme: Die Verordnung knüpft an Kontrolle an, nicht an Nähe. Die Pflichten laufen parallel: Wer ein System baut und selbst betreibt, ist beides zugleich. Ob Ihr System überhaupt hochriskant ist, ist die vorgelagerte Frage — dazu der Überblick über den AI Act.

Normen werden genau dafür erarbeitet, und keine davon ist fertig. Die CEN-CENELEC-Arbeit, die Artikel 12 unterstützen soll — der Weg zur harmonisierten Norm und damit zur Konformitätsvermutung —, befindet sich noch in der Entwicklung und ist unveröffentlicht. Eine Nummer des Arbeitsauftrags nenne ich dafür bewusst nicht: Zuschnitt und Nummerierung haben sich mehrfach geändert, und eine veraltete Kennung ist schlechter als gar keine. ISO/IEC 24970 („AI system logging“) ist stabil genug, um sie zu benennen: Sie hat den FDIS-Status erreicht und wurde im Mai 2026 zur förmlichen Abstimmung registriert; auch sie ist unveröffentlicht. Solange im Amtsblatt keine harmonisierte Norm veröffentlicht ist, gibt es nichts, worauf Sie sich stützen könnten: Sie definieren das Schema selbst und dokumentieren, warum es Abs. 2 genügt. Bis Dezember 2027 ist das die Aufgabe.

Warum Prompt und Antwort nichts erklären

Hier liegt der Fehler in den kursierenden Feldlisten. Bei einer schlichten deterministischen Funktion genügen Eingabe und Ausgabe, um die Arbeit nachzuvollziehen. Ein LLM in einem RAG-System ist diese Funktion nicht. Seine Antwort ist eine Funktion des Korpus zu genau diesem Zeitpunkt — und der Korpus steht nicht im Prompt.

Indexieren Sie Dienstagnacht neu, mit demselben Code, demselben Modell, demselben Seed. Am Mittwoch ruft derselbe Prompt andere Chunks ab und erzeugt eine andere Antwort, und nichts in einem Prompt-und-Antwort-Protokoll hält fest, dass sich etwas geändert hat. Wenn eine Behörde, ein Kunde oder Ihre eigene Vorfallanalyse fragt, warum das System im März dies gesagt hat, überreichen Sie einen Prompt und eine Antwort und können den Zusammenhang zwischen beiden nicht belegen.

Dieselbe Logik befördert drei weitere Felder von „nett“ zu „tragend“. embedder_version, weil ein neues Modell beim erneuten Einbetten derselben Texte sämtliche Nachbarschaften umsortiert. system_prompt_version, weil der System-Prompt Code ist, der ohne Deployment ausgerollt wird und Verhalten unbemerkt ändert. Und die Dekodierparameter samt seed, weil eine Temperatur über null die Ausgabe zu einer Stichprobe macht und nicht zu einem Wert. Darunter liegt als Fehlerbild die Korpus-Drift, über die ich im Monitoring-Kontext geschrieben habe.

Verifikation ist keine Wiederholung

Zwei Dinge, die man von einem Prüfdatensatz will, schließen einander aus, ohne dass es auffällt: ein Datensatz, der keinen Klartext aufbewahrt, und einer, der die Ausgabe erneut herleiten kann. Beides zusammen geht nicht, also hier die saubere Trennung.

Verifikation und Rückverfolgbarkeit ist das, was ein gehashter Datensatz wirklich leistet. Mit den Feldern unten belegen Sie, welcher Korpus, welche Modellgewichte, welche Prompt-Version und welche Chunks eine bestimmte Antwort hervorgebracht haben; Sie weisen nach, dass ein später vorgelegter Prompt tatsächlich derjenige war, der lief, indem Sie seinen HMAC neu berechnen und vergleichen; und Sie zeigen den Entscheidungsweg, einschließlich der Frage, ob ein Mensch die Ausgabe übernommen oder übersteuert hat. Genau das verlangt der Zwecktest aus Abs. 2, und ein Datensatz dieser Form beantwortet ihn.

Wiederholung — die Ausgabe tatsächlich erneut herleiten — ist eine erheblich stärkere Behauptung, und dieses Schema leistet sie nicht. Es kann sie konstruktionsbedingt nicht leisten. Ein prompt_hmac, dessen Klartext in einem Vault mit kurzer TTL liegt, erlaubt Ihnen, einen vorgelegten Kandidaten zu prüfen; sobald der Vault abgelaufen ist, gibt er den Prompt nicht zurück. Ein Hash ist eine Einwegfunktion, und genau deswegen benutzt man ihn. Für den Korpus gilt dasselbe: chunk_id plus index_snapshot_id sagt Ihnen, welche Chunks abgerufen wurden — aber zu zeigen, was das Modell tatsächlich gelesen hat, setzt voraus, dass Snapshot, Quelldokumente, Vorverarbeitung und der Inhalt der Chunks noch existieren.

Entscheiden Sie also bewusst und schreiben Sie die Entscheidung auf. Wiederholbarkeit heißt, die Eingaben im Klartext und den Korpus dahinter über die gesamte Aufbewahrungsfrist zu halten — was direkt in die Minimierungspflicht aus „Der Konflikt mit der DSGVO“ läuft. Für manche Systeme ist das vertretbar, für die meisten eine schlechte Wahl. Dieses Design erkauft Verifikation damit, dass es die Inhalte nicht aufbewahrt.

Der Seed ist Beleg, keine Garantie

Und selbst wenn Sie jede Eingabe aufbewahren, ist Wiederholbarkeit kein gelöstes Problem. Die PyTorch-Dokumentation ist deutlich: „Completely reproducible results are not guaranteed across PyTorch releases, individual commits, or different platforms“, und Ergebnisse „may not be reproducible between CPU and GPU executions, even when using identical seeds“. vLLM hält fest, dass es „does not guarantee the reproducibility of the results by default, for the sake of performance“, und benennt die Bedingungen: Scheduling unter Multiprocessing und Batching verändern Ergebnisse, weshalb Offline-Läufe deterministisches Scheduling oder Batch-Invarianz brauchen und der Online-Betrieb ohne Batch-Invarianz vom Seed wenig hat. Nehmen Sie Hardware, Treiber, CUDA-Versionen, Tokenizer und Quantisierung dazu, und die tokengenaue Neuerzeugung einer Antwort vom vergangenen März liegt zwischen sehr teuer und fiktiv.

Das kostet Sie weniger, als es klingt, denn Artikel 12 Abs. 2 hat das nie verlangt: Verlangt ist Rückverfolgbarkeit in einem der Zweckbestimmung angemessenen Maße, keine deterministische Neuerzeugung. Die Jagd nach bitgenauer Wiederholbarkeit ist Engineering-Eitelkeit — ein wirklich schweres Problem, das Ihnen keine Behörde gestellt hat, gelöst auf Kosten desjenigen, das sie Ihnen gestellt hat. Der Seed gehört weiterhin in den Datensatz, aber als Beleg für Absicht und Konfiguration: Er dokumentiert, worauf das System eingestellt war, als es lief — kein Versprechen, dass Sie es noch einmal herbeiführen können.

Das Schema, Feld für Feld

Das ist ein Datensatz für einen Aufruf. Alles darin ist entweder zur Laufzeit ableitbar oder liegt bereits in Ihren Deployment-Metadaten. Die Markierungen legen ihre eigene Verbindlichkeit offen: Pflicht heißt, dass ich das Feld für den Zwecktest aus Abs. 2 bei einem RAG-System für notwendig halte, nicht, dass der AI Act es benennt. Benannt sind Felder nur in Abs. 3, und nur für Biometrie. ratsam heißt: kostet ein paar Bytes und spart Ihnen im Ernstfall eine Woche. Er schließt mit zwei Signaturen statt einer — warum, steht in „Wo Sie den Datensatz schreiben“.

{
  "record_id": "01J8FQ7M2K9XW3PBN4TRVC6H8D",        // Pflicht · ULID, write-once
  "ts_start": "2026-07-15T09:41:22.118Z",           // Pflicht · Verwendungszeitraum
  "ts_end": "2026-07-15T09:41:26.902Z",             // Pflicht

  "system": {
    "ai_system_id": "schaden-vorpruefung",         // Pflicht
    "risk_class": "hochrisiko",                    // Pflicht · Recht & Compliance verantworten das
    "role": "betreiber",                            // Pflicht · Art. 19 vs. Art. 26 Abs. 6
    "instructions_version": "2.4.0"                  // Pflicht · Betriebsanleitung, Art. 26
  },

  "actor": {
    "subject_pseudonym": "hmac:4f9c1a...e7",         // Pflicht · schlüsselbasiert, nie der Name
    "operator_id": "u-4471",                        // Pflicht · wer hat ausgelöst
    "session_id": "s-9d20d1"                        // ratsam · gruppiert einen Dialog
  },

  "input": {
    "prompt_hmac": "hmac:9f2c8b...31",               // Pflicht · prüft einen vorgelegten Prompt, gibt keinen zurück
    "prompt_ref": "vault://p/2026-07-15/01J8FQ7M",     // ratsam · Klartext, kurze TTL
    "prompt_chars": 812,                            // ratsam
    "pii_classes": ["name", "vertragsnummer"]        // ratsam · speist Ihr Art.-30-Verzeichnis
  },

  "provenance": {                                   // app-attestiert · was die Antwort erzeugt hat — kein Replay-Paket
    "model_id": "llama-3.3-70b-instruct",           // Pflicht
    "weights_sha256": "b71e0c...aa",                 // Pflicht · Namen sind keine Gewichte
    "serving_stack": "vllm-0.8.2",                   // ratsam · Kernels ändern Numerik
    "decoding": {
      "temperature": 0.2,                          // Pflicht
      "top_p": 0.9,                                 // Pflicht
      "seed": 42,                                   // Pflicht · Konfigurationsbeleg, keine Replay-Garantie
      "max_tokens": 800                             // ratsam
    },
    "system_prompt_version": "sp-2026-06-30-r3",     // Pflicht · Code, der still ausrollt
    "system_prompt_sha256": "3ac910...5f",           // Pflicht · Versionsstrings lügen
    "index_snapshot_id": "idx-2026-07-14T02:00Z-a91f", // Pflicht · DAS fehlende Feld
    "embedder_version": "bge-m3@2024-06",           // Pflicht
    "retrieval": {
      "top_k": 8,                                   // Pflicht
      "reranker": "bge-reranker-v2@2025-01",         // Pflicht, sofern vorhanden
      "filter": "mandant=ACME AND lang=de"           // Pflicht · der Filter ändert Ergebnisse
    },
    "retrieved": [                                    // Pflicht · das reale Kontextfenster
      {"chunk_id": "doc-8842#c17", "score": 0.8123, "rank": 1},
      {"chunk_id": "doc-1190#c03", "score": 0.7440, "rank": 2}
    ]
  },

  "output": {
    "response_hmac": "hmac:7d10ff...92",             // Pflicht
    "response_ref": "vault://r/2026-07-15/01J8FQ7M",   // ratsam
    "finish_reason": "stop",                        // ratsam · Abbruch erklärt vieles
    "refusal": false                                // ratsam
  },

  "oversight": {                                    // app-attestiert · eine Entscheidung nach ts_end kommt als verknüpfter Folgedatensatz
    "human_review": "erforderlich",                 // Pflicht · Art. 14
    "reviewer_id": "u-2210",                        // Pflicht, wenn geprüft wurde
    "decision": "uebersteuert",                     // Pflicht · bestaetigt | uebersteuert | keine
    "override_reason_code": "OR-07"                  // ratsam · Codes schlagen Freitext
  },

  "attestations": [                                 // Pflicht · zwei Signierende, weil keine Seite all das bezeugen kann
    {
      "signer": "gateway",                          // signiert nur, was es selbst entgegennimmt
      "key_id": "gw-signing-2026-q3",
      "covers": ["record_id", "ts_start", "ts_end", "system", "actor", "input", "output"],
      "payload_sha256": "9c41d7...a8",               // JCS-Digest über genau die in "covers" genannten Felder
      "signature": "ed25519:9a01...bb"
    },
    {
      "signer": "app:schaden-vorpruefung",          // das Gateway sieht diese Felder nicht — die Anwendung behauptet sie
      "key_id": "app-vorpruefung-2026-q3",          // eigener Schlüssel, eigene Vertrauensdomäne
      "covers": ["record_id", "provenance", "oversight"],
      "payload_sha256": "3fb0ac...5d",               // record_id steht in beiden — keine Hälfte lässt sich umhängen
      "signature": "ed25519:4c88...02"
    }
  ],

  "integrity": {                                    // schreibt der Collector; er signiert keine der beiden Behauptungen
    "canon": "JCS/RFC8785",                        // Pflicht · fixiert Schlüsselreihenfolge und Float-Form, sonst rechnet jeder anders
    "seq": 88213,                                  // Pflicht · vom Collector vergeben; Lücken sind Beweis
    "prev_sha256": "5c2ab8...0d",                    // Pflicht · der vorige entry_sha256 — die Kette
    "entry_sha256": "e1907a...c4"                   // Pflicht · JCS-Digest über jedes Feld oberhalb dieses Blocks
  }
}

Was ich streichen würde und was nicht

Wenn Sie kürzen wollen: prompt_chars, session_id und finish_reason sind Diagnostik, kein Nachweis. Streichen Sie nicht die Scores aus retrieved: Der Unterschied zwischen „aus einem 0,81-Treffer beantwortet“ und „aus einem 0,31-Treffer beantwortet“ ist der Unterschied zwischen einem System, das funktioniert, und einem, das rät — und genau diese Unterscheidung verlangt Artikel 12 Abs. 2 Buchst. a, wenn er das Erkennen risikobehafteter Situationen fordert. Und nehmen Sie keine natürlichsprachliche „Begründung“ aus einem zweiten LLM-Aufruf auf: Sie belegt nichts außer, dass ein zweites Modell plausiblen Text produziert hat, sie ist nicht validierbar, und in einem Prüfdatensatz verleitet sie den Leser dazu, sie für einen Befund zu halten.

Wo Sie den Datensatz schreiben

Zwei mögliche Orte, und keiner davon ist sauber. Für das Gateway spricht Unabhängigkeit: Die Anwendung ist der Prüfgegenstand, und wenn derselbe Codepfad, der die Entscheidung erzeugt, auch deren Protokoll schreibt, ändert ein Deployment beides, und das System benotet sich selbst. Ein Gateway verschafft Ihnen eine eigene Vertrauensdomäne — die aufgelöste Anfrage, die Antwort, einen eigenen Signaturschlüssel — und ist zudem der Punkt, an dem Sie Authentifizierung und Eingabekontrollen ohnehin durchsetzen, derselbe Kontrollpunkt, für den ich beim Absichern von LLM-Anwendungen plädiere.

Sehen Sie sich nun an, was ein Gateway nicht sieht — es ist der größte Teil dieses Artikels: welche Dokumente Ihre Anwendung abgerufen hat, welcher Index-Snapshot tatsächlich abgefragt wurde, wie der Prompt vor dem Eintreffen zusammengesetzt wurde, was ein menschlicher Prüfer zehn Minuten später entschieden hat. Das sind die zentralen Felder — index_snapshot_id vor allen anderen —, und die Anwendung muss sie behaupten. Ausgerechnet für die Felder, die das Argument tragen, ist das Gateway kein unabhängiger Zeuge. Es ist ein Bote.

Das realistische Design ist deshalb geteilt — und genau das ist die attestations-Liste im Schema oben statt der Signatur eines einzelnen Writers: Das Gateway signiert, was es unmittelbar beobachtet, die Anwendung signiert ihre eigene Attestierung der Provenance- und Oversight-Felder mit einem eigenen Schlüssel, und beides geht in einen Append-only-Collector, der keines von beidem signiert und keines nachträglich umschreiben kann. Jede covers-Liste benennt genau, wofür der jeweilige Schlüssel einsteht; record_id steht in beiden, sodass sich keine Hälfte an einen anderen Aufruf hängen lässt. Statt Unabhängigkeit bekommen Sie Zurechenbarkeit: einen Nachweis darüber, wer was behauptet hat, an dem sich nachträgliche Änderungen erkennen lassen. „Immer im Gateway protokollieren“ ist Architekturmeinung, meine eingeschlossen, und keine Vorgabe des AI Act. Artikel 12 sagt nichts darüber, wo der Writer sitzt.

Der Konflikt mit der DSGVO — und wie er sich auflöst

Jetzt der Teil, der Juristen nervös macht, und das zu Recht. Artikel 19 und Artikel 26 Abs. 6 verlangen mindestens sechs Monate Aufbewahrung, und sechs Monate Prompts aufzubewahren ist selbst eine Verarbeitungstätigkeit — Prompts an ein Schadensystem stecken voller Namen, Gesundheitsangaben und Beschwerden. Artikel 5 Abs. 1 Buchst. c DSGVO verlangt Datenminimierung. Klartext-Prompts vorzuhalten, „weil der AI Act Protokollierung fordert“, ist der Weg, eine Verordnung durch den Bruch einer anderen zu erfüllen.

Die Auflösung steckt im Schema oben — und sie muss präzise formuliert werden, sonst ist sie keine: Der Prüfdatensatz muss die Entscheidung verifizierbar machen, ohne die personenbezogenen Daten aufzubewahren. Speichern Sie Identität, nicht Inhalt. Der Datensatz hält prompt_hmac, nicht den Prompt; subject_pseudonym, nicht den Namen; chunk_id, nicht den Chunk-Text. Das ist genau der Kompromiss aus „Verifikation ist keine Wiederholung“ — und dies ist die Verordnung, die ihn zum richtigen macht.

Verwenden Sie einen HMAC mit geheimem Schlüssel, kein nacktes SHA-256. Der Hash eines kurzen Prompts ist per Brute Force angreifbar: Wer die Vorlage kennt, kann Kandidaten durchprobieren und den Digest treffen — der Hash ist dann schlicht der Prompt in Verkleidung. Anonymisierung ist beides nicht: Mit oder ohne Schlüssel bleiben es pseudonymisierte personenbezogene Daten nach Artikel 4 Nr. 5 DSGVO. Der Grund für den Schlüssel ist der Hebel: Vernichten Sie ihn, lassen sich die Digests deutlich schwerer einer Person zuordnen.

Behaupten Sie dafür aber nicht zu viel. Die Vernichtung des Schlüssels ist weder automatisch eine Löschung noch automatisch eine Anonymisierung. Die Leitlinien 01/2025 des EDSA zur Pseudonymisierung sagen ausdrücklich, dass das Löschen der zusätzlichen Informationen pseudonymisierte Daten nicht von selbst anonym macht; anonym werden sie nur, wenn der Anonymisierungstest insgesamt erfüllt ist. Und Ihr Datensatz trägt weiterhin operator_id, session_id, Zeitstempel, Chunk-Referenzen und ein charakteristisches Interaktionsmuster; alle diese Merkmale können einzeln oder in Kombination ausreichen, um eine Person herauszugreifen. Die Schlüsselvernichtung ist eine starke Schutzmaßnahme, kein Trick, der personenbezogene Daten in nicht-personenbezogene verwandelt — und ob sie trägt, ist eine Frage für Ihre DSFA.

Das Verarbeitungsverzeichnis — und die Löschfrage

Das Protokoll ist eine Verarbeitungstätigkeit und muss sich daher in Ihrem Verzeichnis von Verarbeitungstätigkeiten nach Artikel 30 DSGVO wiederfinden — nicht jedoch zwingend als eigene Zeile. Die DSGVO verlangt keinen gesonderten Eintrag je technischem Log-Strom, und viele Verantwortliche dokumentieren die Protokollierung innerhalb der Verarbeitungstätigkeit, der sie dient. Entscheidend ist, dass die Substanz da ist: Zweck — Rückverfolgbarkeit eines Hochrisiko-KI-Systems nach Art. 19 / Art. 26 Abs. 6 AI Act; Kategorien — pseudonymisierte Kennungen, technische Metadaten; Aufbewahrung — die festgelegte Frist, wobei für den Klartext-Vault eine kürzere Frist gilt; Empfänger — Ihr Prüfer und die Marktüberwachungsbehörde.

Bei der Rechtsgrundlage rächt sich die Abkürzung. Artikel 6 Abs. 1 Buchst. c DSGVO — Erfüllung einer rechtlichen Verpflichtung — passt, sobald die Pflicht aus dem AI Act für Sie gilt, ist aber nicht die ganze Prüfung. Ein Assistent zur Schadenvorprüfung verarbeitet Gesundheitsdaten, und besondere Kategorien personenbezogener Daten brauchen zusätzlich zur Rechtsgrundlage aus Artikel 6 einen Erlaubnistatbestand nach Artikel 9. Wenn niemand benannt hat, auf welchen Tatbestand aus Artikel 9 Sie sich stützen, ist Ihre Rechtsgrundlagenprüfung nicht fertig — so ordentlich der Eintrag nach Artikel 30 auch aussieht.

Und die Frage, die immer zuletzt kommt: Was passiert bei einem Löschersuchen nach Artikel 17 DSGVO? Der Klartext-Vault wird gelöscht; das ist der einfache Teil. Der Prüfdatensatz ist schwieriger. Artikel 17 Abs. 3 Buchst. b nimmt die Löschung nur insoweit aus, wie die Verarbeitung zur Erfüllung einer rechtlichen Verpflichtung nach Unionsrecht erforderlich ist. Das ist keine Pauschalausnahme für alles, was „Audit“ heißt, es rechtfertigt keine unbefristete Aufbewahrung, und es deckt nicht automatisch jedes Feld. Der Maßstab ist die Erforderlichkeit Feld für Feld, und er greift: Art. 19 / Art. 26 Abs. 6 trägt plausibel die Rückverfolgbarkeitsfelder für die Aufbewahrungsfrist — und ersichtlich nicht prompt_chars oder eine Session-Kennung, die Sie aus Bequemlichkeit behalten haben. Die Zwei-Speicher-Architektur macht diese Prüfung gewinnbar — sie ersetzt sie nicht.

Wo Tippel ansetzt

Dezember 2027 klingt weit weg. Es ist einen Beschaffungszyklus und einen Ingestion-Umbau entfernt, und genau darin liegt die Falle. Die meisten Teams entdecken das Problem spät: Ein System läuft, jemand verlangt den Prüfpfad, und die Protokolle können nichts erklären. Eine Snapshot-ID nachträglich in eine laufende RAG-Pipeline einzuziehen bedeutet, einen Index zu versionieren, der nie für Versionierung ausgelegt war — ein Umbau der Ingestion-Strecke, kein Logging-Ticket. Zur Bauzeit entschieden, kostet dasselbe ein paar Bytes pro Datensatz.

Wenn Sie ein System entwerfen, das unter Artikel 12 fallen wird, ist der KI-Readiness-Check der Ort, an dem das geklärt wird: ein Use Case, Ihre echten Daten, ein festes Fenster — und am Ende eine Architektur, die Sie verteidigen können, statt einer Präsentation. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.