KI-Systeme protokollieren Outputs. Gerichte werden nach Entscheidungen fragen.

Jede Organisation, die KI in einem folgenreichen Bereich einsetzt — Kreditvergabe, Recht, Versicherung, Personalauswahl — baut ein Prüfprotokoll auf. Die meisten dieser Protokolle werden nutzlos sein, wenn eine Entscheidung angefochten wird. Nicht weil die Protokolle unvollständig sind. Sondern weil sie das Falsche protokollieren.

Herkömmliche Audit-Infrastruktur ist um Ereignisse herum konzipiert: Eine Handlung wurde vorgenommen, durch einen bestimmten Akteur, zu einem bestimmten Zeitpunkt, mit einer bestimmten Veränderung des Systemzustands als Folge. Die Invariante ist die Rekonstruierbarkeit. Wenn Sie das Ereignisprotokoll erneut abspielen, können Sie wiederherstellen, was geschehen ist. Genau das verleiht einem Prüfpfad seine rechtliche Bedeutung. Nicht die Tatsache, dass er existiert, sondern dass er etwas beweisen kann.

KI-Inferenz ist in diesem Sinne kein Ereignis. Eine KI-Entscheidung ist eine Funktion. Sie nimmt Eingaben entgegen und erzeugt eine Ausgabe. Die Ausgabe ist nicht die Entscheidung — sie ist das Ergebnis der Entscheidungsfunktion, angewandt auf einen bestimmten Satz von Eingaben unter bestimmten Bedingungen. Protokollieren Sie nur die Ausgabe, so haben Sie die Antwort festgehalten, ohne die Frage festzuhalten, ohne das Modell, das sie beantwortet hat, ohne den Kontext, der ihm gegeben wurde, oder die Parameter, unter denen es operiert hat. Sie haben einen Beleg, keinen Prüfpfad.

Die vier Eingaben, die die Entscheidung bestimmen

Eine von einem Sprachmodell erzeugte Entscheidung wird durch mindestens vier unabhängige Variablen bestimmt.

Die Nutzereingabe: das Dokument, die Abfrage oder der Prompt, der zum Zeitpunkt der Inferenz übermittelt wurde. Die meisten Organisationen protokollieren dies. Es ist das Einfachste.

Der System-Prompt: die Anweisungen, die das Verhalten des Modells rahmen, seine Ausgaben einschränken und seine Rolle in der Pipeline definieren. System-Prompts ändern sich. Sie werden stillschweigend aktualisiert, ohne Versionierung, während Teams das Modellverhalten iterativ weiterentwickeln. Wenn Sie den exakten System-Prompt, der zum Zeitpunkt einer bestimmten Inferenz im Einsatz war, nicht vorlegen können, können Sie nicht rekonstruieren, was dem Modell aufgetragen wurde.

Die Modellversion: nicht der Modellname. Die Version. „GPT-4“ ist keine Modellversion. Wenn ein Anbieter ein Modell hinter einem stabilen API-Endpunkt aktualisiert, was vorkommt, ist Ihr Protokolleintrag „GPT-4“ vereinbar mit zwei verschiedenen Modellen, die für dieselbe Eingabe zwei verschiedene Ausgaben erzeugen. Die Entscheidung ist nicht rekonstruierbar.

Der Abrufkontext: Wenn das System auf Retrieval-Augmented Generation (RAG) setzt, sind die abgerufenen Dokumente Teil der Entscheidungsfunktion. Ein Retrieval-Index verändert sich im Laufe der Zeit. Dokumente werden hinzugefügt, ausgemustert, neu zerlegt (re-chunked), neu eingebettet (re-embedded). Das Abrufergebnis für dieselbe Abfrage ist heute nicht dasselbe wie das Abrufergebnis vor sechs Monaten. Sofern der abgerufene Kontext nicht zum Zeitpunkt der Inferenz protokolliert wird, kann die Entscheidung nicht reproduziert werden.

Schon eine einzige dieser Variablen — nicht protokolliert oder nicht versioniert — macht die Entscheidung unwiederbringlich.

Warum Output-Protokolle genau in dem Moment versagen, in dem sie auf die Probe gestellt werden

Der Fehlermodus ist im Normalbetrieb unsichtbar. Ein Output-Protokoll funktioniert einwandfrei für Monitoring, Analytik und Fehlersuche. Es versagt genau dann, wenn Sie es am dringendsten brauchen: wenn eine Entscheidung bestritten wird.

Betrachten Sie das Szenario. Eine folgenreiche automatisierte Entscheidung wird zwölf Monate nach ihrem Zustandekommen angefochten. Das Modell wurde inzwischen aktualisiert. Der Retrieval-Index wurde neu aufgesetzt. Der System-Prompt wurde zweimal überarbeitet. Der Anfechtende fragt, berechtigterweise: Was wusste Ihr System, als es diese Entscheidung traf, und warum hat es so entschieden?

Das Output-Protokoll antwortet: Es hat dies entschieden. Es beantwortet nicht: auf welcher Grundlage.

Das ist der Unterschied zwischen Protokollierung und Rechenschaft. Ein Protokoll sagt Ihnen, was geschehen ist. Ein Rechenschaftsnachweis sagt Ihnen, warum — in einer Form, die verifiziert, reproduziert und verteidigt werden kann. Die maßgeblichen Regulierungsrahmen beginnen, diese Unterscheidung durchzusetzen, ob die Organisationen darauf vorbereitet sind oder nicht.

Was die Regulierungsrahmen tatsächlich verlangen

Artikel 12 der EU-KI-Verordnung verlangt, dass Hochrisiko-KI-Systeme „technisch die automatische Aufzeichnung von Ereignissen (Protokollierung, ‚logs‘) während des Lebenszyklus des Systems ermöglichen“, wobei die Protokollierungsfunktionen so ausgelegt sein müssen, dass ein Maß an Nachvollziehbarkeit gewährleistet ist, das „dem Zweck des Systems angemessen“ ist (Verordnung (EU) 2024/1689, Artikel 12 Absatz 1–2). Nach Artikel 22 DSGVO haben Personen das Recht, nicht einer ausschließlich auf automatisierter Verarbeitung — einschließlich Profiling — beruhenden Entscheidung unterworfen zu werden, die ihnen gegenüber rechtliche Wirkung entfaltet oder sie in ähnlicher Weise erheblich beeinträchtigt; und soweit eine solche Verarbeitung zulässig ist, gewährt ihnen Artikel 22 Absatz 3 Schutzmaßnahmen, darunter das Eingreifen einer Person, das Recht auf Darlegung des eigenen Standpunkts und das Recht auf Anfechtung der Entscheidung; ein „Recht auf Erläuterung“ als solches findet sich nicht im Wortlaut von Artikel 22, sondern leitet sich aus dem rechtlich nicht bindenden Erwägungsgrund 71 sowie aus den Transparenzpflichten der Artikel 13–15 ab, die „aussagekräftige Informationen über die involvierte Logik“ verlangen. Der Rahmen der PRA zum Modellrisikomanagement — Supervisory Statement SS1/23, „Model risk management principles for banks“ — erwartet von Unternehmen, eine Dokumentation zu führen, die so detailliert ist, dass eine unabhängige Partei die Ergebnisse eines Modells nachvollziehen und reproduzieren kann, was die Prüfbarkeit und eine wirksame Modell-Governance stützt.Quellen: EU-Verordnung über Künstliche Intelligenz, Artikel 12 (Aufbewahrung von Aufzeichnungen) — Verordnung (EU) 2024/1689 · DSGVO Artikel 22 (Volltext), gdpr-info.eu · Bank of England (PRA) — SS1/23, „Model risk management principles for banks“

Keine dieser Regelungen legt fest, was Protokollierung technisch bedeutet. Ein Gericht oder eine Aufsichtsbehörde, die sie auslegt, wird einen zweckorientierten Maßstab anlegen: Erlaubt das Protokoll, die Entscheidung zu rekonstruieren und zu erläutern? Ein Output-Protokoll erfüllt diesen Maßstab nicht. Ein Protokoll aus Output plus Kontext plus Modellversion erfüllt ihn.

Die praktische Folge ist, dass Organisationen, die KI auf Allzweck-APIs ohne Versionszusage und ohne Retrieval-Protokollierung aufbauen, eine Haftung anhäufen, die unsichtbar bleibt, bis eine Entscheidung angefochten wird — zu welchem Zeitpunkt die für die Rekonstruktion erforderlichen Eingaben nicht mehr existieren.

Wie ein entscheidungsrekonstruierbares Protokoll tatsächlich aussieht

Der minimal tragfähige Rechenschaftsnachweis für eine KI-Entscheidung enthält: Einen Hash der Nutzereingabe zum Zeitpunkt der Inferenz. Den exakten, im Einsatz befindlichen System-Prompt, versioniert und gehasht. Eine Modellkennung, die sich auf bestimmte Gewichte festlegt — eine eingefrorene Deployment-ID oder eine Snapshot-Referenz auf Anbieterebene, nicht einen Namen. Den abgerufenen Kontext, sofern zutreffend: Dokumentkennungen, Inhalts-Hashes und Abruf-Zeitstempel. Die Inferenzparameter: Temperatur, Sampling-Konfiguration, alles, was die Stochastik der Ausgabe beeinflusst. Die Ausgabe, gehasht und mit Zeitstempel versehen. Die nachgelagerte Entscheidung, falls die Ausgabe in einen regelbasierten oder von Menschen geprüften Schritt einfließt.

Dies ist keine große Datenmenge. Der Abrufkontext ist die größte Komponente bei RAG-Systemen, aber er ist durch das Kontextfenster begrenzt. Der Rest sind Metadaten. Die Kosten ihrer Speicherung sind vernachlässigbar im Verhältnis zu den Kosten, sie nicht vorlegen zu können.

Der Test

Wenn Sie eine KI-Entscheidung anhand eines Protokolleintrags nicht reproduzieren können — dieselben Eingaben durch dieselbe Modellversion mit demselben System-Prompt und Abrufkontext laufen lassen und zu derselben Ausgabe gelangen —, dann ist Ihr Protokoll kein Prüfpfad. Es ist eine Output-Historie.

Output-Historien sind nützlich. Verteidigungsfähig sind sie nicht.

Die Organisationen, die in der stärksten Position sein werden, wenn automatisierte Entscheidungen angefochten werden, sind nicht zwangsläufig diejenigen mit den besten Modellen. Es sind diejenigen, die die Protokollierung von Anfang an als ein Problem der Entscheidungsarchitektur behandelt haben, bevor irgendeine Entscheidung bestritten wurde.

Der richtige Zeitpunkt, diese Architektur zu bauen, ist vor dem Streit, nicht danach.