Das Modell kann erklären. Der Einzelfall ist verschwunden. Das Modell kann erklären. Der Einzelfall ist verschwunden.

Eine Erklärung braucht die Vergangenheit, nicht nur das Modell

Die meisten Konzepte für Erklärbarkeit beginnen beim Modell. Ein Widerspruch beginnt beim Fall: Welche Daten lagen vor? Welche Version lief? Welche Schwelle galt? Und wer machte aus der Ausgabe eine Entscheidung?

Fehlt diese Kette, kann ein Unternehmen sein System ausführlich beschreiben und die einzelne Folge trotzdem nicht erklären. Die aktuelle Modellversion lässt sich prüfen. Eine Modellkarte nennt Zweck und Grenzen. Das Team kennt die Merkmale, die Ergebnisse typischerweise beeinflussen. Nur der damalige Lauf ist verloren.

Das geschieht schneller, als es klingt. Eingangsdaten werden berichtigt, Schwellen angepasst, Modelle ausgetauscht. Ein externer Dienst verändert sein Verhalten, ohne dass der Produktname wechselt. Oder ein Mensch übernimmt eine Empfehlung, hält den eigenen Grund aber nicht fest. Die Erklärung beschreibt dann die Gegenwart des Systems statt die Vergangenheit des Falls.

Die britische Datenschutzaufsicht ICO unterscheidet deshalb zwischen Prozesserklärungen und Erklärungen des konkreten Ergebnisses. Die erste zeigt, wie ein System entwickelt und kontrolliert wird. Die zweite beantwortet, was bei einer bestimmten Entscheidung geschah. Die Leitlinie ist keine Auslegung des EU-Rechts, trifft aber den operativen Unterschied präzise. ICO-Leitlinie zu Prozess- und Einzelfallerklärungen ↗

Die Aufgabe lautet daher nicht, möglichst viele Daten zu sammeln. Unternehmen brauchen einen fallbezogenen Entscheidungsbeleg: kleiner als ein Vollarchiv, aber vollständig genug, um eine konkrete Folge später zu verstehen und anzufechten.

Der AI Act verlangt Logs – aber nicht automatisch den ganzen Fall

Der Begriff AI Act Logging verführt zu einer einfachen Annahme: Wenn ein System gesetzeskonform protokolliert, müsse damit auch jede Einzelentscheidung erklärbar sein. Der Verordnungstext trägt diese Gleichsetzung nicht.

Artikel 12 verlangt für Hochrisiko-Systeme technische Funktionen zur automatischen Aufzeichnung von Ereignissen. Diese sollen insbesondere Risiken erkennbar machen, die Marktbeobachtung unterstützen und den Betrieb überwachen. Das schafft Rückverfolgbarkeit. Es bedeutet aber nicht automatisch, dass ein einzelnes Log auch die damals verwendeten Werte, den gültigen Schwellenwert und den menschlichen Entscheidungsgrund enthält. Konsolidierte Fassung des EU AI Act mit den Artikeln 12, 19 und 26 ↗

Auch die häufig zitierte Sechsmonatsfrist ist kein universeller Maßstab. Die Artikel 19 und 26 sehen für automatisch erzeugte Logs bestimmter Hochrisiko-Systeme eine Aufbewahrung von mindestens sechs Monaten vor, soweit die Logs unter der Kontrolle des Anbieters oder Betreibers stehen und anderes Unions- oder nationales Recht keine abweichende Regel enthält.

Am 19. September 2026 gilt zudem ein veränderter Zeitplan. Der AI Act ist grundsätzlich seit dem 2. August 2026 anwendbar. Die Verordnung 2026/1744 hat die Anwendung der Hochrisiko-Anforderungen und der zugehörigen Anbieter- und Betreiberpflichten jedoch verschoben: für Systeme nach Anhang III auf den 2. Dezember 2027, für produktbezogene Systeme nach Anhang I auf den 2. August 2028. Änderungsverordnung 2026/1744 vom 8. Juli 2026 ↗

Daneben enthält Artikel 86 ein eng begrenztes Recht auf eine klare und aussagekräftige Erklärung. Es betrifft bestimmte nachteilige Entscheidungen, die ein Betreiber auf die Ausgabe eines in Anhang III genannten Hochrisiko-Systems stützt und die rechtliche oder ähnlich erhebliche Wirkungen entfalten. Das ist kein allgemeines Erklärungsrecht für jede KI-Nutzung. Ob die Vorschrift greift, muss für den konkreten Einsatz und im Zusammenspiel mit der DSGVO sowie sektorspezifischem Recht geprüft werden.

Vor dem Logschema steht deshalb die Einordnung der Entscheidung: Welche Wirkung kann sie haben? Ist sie vollständig automatisiert oder unterstützt das System einen Menschen? Welche Rechtsgebiete und Aufbewahrungspflichten gelten zusätzlich? Erst danach lässt sich bestimmen, welcher Nachweis wirklich benötigt wird.

So sieht ein begrenzter Entscheidungsbeleg aus

Weder der AI Act noch das Urteil des Europäischen Gerichtshofs liefern ein universelles technisches Schema. Für die Praxis lässt sich jedoch eine sechsteilige Arbeitsstruktur ableiten:

1. Fallbezug: Eine geschützte Fall-ID, der Zeitpunkt, der Verwendungszweck, der betroffene Prozess und die verantwortliche Organisationseinheit. Die Zuordnung zur Person kann getrennt gespeichert und strenger geschützt werden.
2. Verwendete Eingaben: Nicht alle verfügbaren Daten, sondern die Werte und Kategorien, die tatsächlich in diesen Lauf eingingen. Dazu gehören ihre Herkunft, der Abrufzeitpunkt, relevante Umwandlungen und der Umgang mit fehlenden Werten.
3. Systemzustand: Modell- oder Serviceversion, Feature-Schema, Konfiguration, Prompt- oder Regelstand, Schwellenwerte und gegebenenfalls die Version eines zusätzlichen Erklärverfahrens. Ein Produktname reicht nicht, wenn sich das Verhalten dahinter ändern kann.
4. Ausgabe und betriebliche Folge: Der erzeugte Score, die Kategorie oder Empfehlung sowie die Regel, durch die daraus eine Priorisierung, Absage oder Eskalation wurde. Ein Wert von 0,42 bleibt bedeutungslos, wenn die damals gültige Schwelle fehlt.
5. Menschlicher Anteil: Wer das Ergebnis prüfte, welche Entscheidungsbefugnis bestand, welche weiteren Informationen einflossen und ob die Empfehlung bestätigt, verändert oder verworfen wurde. Eine Freigabe dokumentiert eine Handlung. Sie dokumentiert noch keinen Grund.
6. Integrität und Zugriff: Änderungen, Abrufe und Löschungen müssen nachvollziehbar bleiben. Der Beleg muss nicht breit sichtbar sein, aber für eine befugte Prüfung unverändert auffindbar bleiben.

Nicht jede Ebene verlangt eine Kopie der vollständigen Ursprungsdaten. Ist eine Quelle unveränderlich versioniert, kann ein belastbarer Verweis genügen. Wird sie laufend überschrieben, braucht der Fall einen Snapshot der verwendeten Werte oder eine gleichwertige beweissichere Ableitung.

Der praktische Test ist einfach: Nehmen Sie nach einer Änderung an Modell, Schwelle oder Datenaufbereitung einen abgeschlossenen Fall. Lässt sich erklären, welche Ausgabe damals entstand und warum daraus genau diese Folge wurde? Wenn nicht, fehlen nicht unbedingt mehr Daten. Vielleicht fehlt die Verbindung zwischen den vorhandenen Spuren.

Zehn Euro und ein nicht nachvollziehbares Profil

Wie entscheidend dieser Fallbezug ist, zeigt ein Urteil des Europäischen Gerichtshofs vom 27. Februar 2025. Eine österreichische Mobilfunkkundin hatte keinen Vertrag erhalten, weil eine automatisierte Bonitätsbewertung sie als nicht ausreichend zahlungsfähig eingestuft hatte. Der Vertrag hätte eine monatliche Zahlung von zehn Euro verlangt.

Der Gerichtshof erklärte weder eine komplexe mathematische Formel noch die detaillierte Beschreibung sämtlicher Rechenschritte für ausreichend. Die betroffene Person müsse in verständlicher Form nachvollziehen können, welches Verfahren und welche Grundsätze konkret angewandt wurden und wie ihre personenbezogenen Daten in das Ergebnis eingingen. Bei einem Profiling könne auch die Information hilfreich sein, in welchem Maß eine Abweichung der berücksichtigten Daten zu einem anderen Ergebnis geführt hätte. Urteil des EuGH in der Rechtssache C-203/22 ↗

Das Urteil schreibt kein KI-Entscheidungsprotokoll vor. Operativ zeigt es dennoch, was ein Unternehmen rekonstruieren können müsste: die damals verwendeten Daten, das erzeugte Profil, das übermittelte Ergebnis und die Kriterien, durch die daraus eine Ablehnung wurde. Ebenso wichtig ist die Frage, ob der Mobilfunkanbieter eine eigene Entscheidung traf oder das Ergebnis faktisch übernahm.

Eine verständliche Gegenprobe kann sichtbar machen, ob ein falsches Datum, eine fehlerhafte Zuordnung oder ein bestimmtes Merkmal das Ergebnis getragen hat. Sie ist nicht dasselbe wie die Offenlegung des gesamten Modells. Sie erklärt die Wirkung im Einzelfall.

Auch Geschäftsgeheimnisse rechtfertigen nach dem Urteil keine pauschale Auskunftsverweigerung. Hält ein Verantwortlicher bestimmte Informationen für geschützt, muss er sie der zuständigen Aufsichtsbehörde oder einem Gericht zugänglich machen können. Dort werden die betroffenen Rechte gegeneinander abgewogen. Geschützter Zugang ersetzt öffentliche Offenlegung – nicht die Nachweisfähigkeit.

Datenminimierung entscheidet über die Form des Belegs

Ein umfassendes Entscheidungsarchiv könnte den Fall rekonstruierbar machen und zugleich ein neues Risiko schaffen. Wenn Rohdaten, Freitexte, Zwischenstände und Identitätsmerkmale ohne Auswahl zusammengeführt werden, entsteht neben dem operativen System ein zweites, besonders aussagekräftiges Personenprofil.

Artikel 5 DSGVO verlangt, personenbezogene Daten auf das für den jeweiligen Zweck notwendige Maß zu begrenzen. Die Speicherbegrenzung verlangt außerdem, Personen nicht länger identifizierbar zu halten, als es der Zweck erfordert. Artikel 5 der Datenschutz-Grundverordnung ↗

DSGVO-Datenminimierung bedeutet damit nicht, auf einen Nachweis zu verzichten. Sie verändert dessen Architektur. Fall-ID und Entscheidungsbeleg können in einem zugriffsbeschränkten Nachweisspeicher liegen. Die Identitätszuordnung bleibt separat geschützt. Nicht verwendete Eingaben gehören nicht in den Fallbeleg. Freitext sollte nur übernommen werden, wenn er tatsächlich entscheidungsrelevant war und sich nicht durch eine engere Kategorie ersetzen lässt.

Auch die Löschung muss nicht für jedes Feld am selben Tag erfolgen. Ein technischer Versionsverweis kann noch erforderlich sein, wenn die direkte Identitätszuordnung bereits entfallen darf. Ein laufender Widerspruch kann eine geplante Löschung verändern. Entscheidend ist, dass jede Speicherung einen benannten Zweck, eine Rechtsgrundlage, eine verantwortliche Rolle und einen konkreten Prüfauslöser besitzt.

Die tragfähige Abwägung liegt daher nicht zwischen „alles behalten“ und „alles löschen“. Der Beleg muss klein genug sein, um keine unnötige Paralleldatenbank zu erzeugen, und vollständig genug, damit eine betroffene Person nicht mit einer abstrakten Modellbeschreibung abgespeist wird.

Was der Anbieter nicht bewahrt, können Sie später nicht erklären

Viele Unternehmen kontrollieren nur einen Ausschnitt des Entscheidungspfads. Das Modell läuft bei einem Anbieter, Daten kommen aus einem Drittsystem und die betriebliche Folge wird in einer weiteren Anwendung ausgelöst. Jeder Beteiligte hält einzelne Spuren. Niemand hält den Zusammenhang.

Vor dem Einsatz muss deshalb geklärt sein, welche Versionskennungen verfügbar bleiben, welche Logs exportiert werden können und wie lange der Anbieter sie aufbewahrt. Ebenso relevant sind Änderungen an Modell, Datenaufbereitung, Schwellenwerten und Erklärverfahren. Zeigt ein Dienst nur seinen aktuellen Zustand, kann eine frühere Entscheidung trotz vorhandener Benutzeroberfläche unerklärbar werden.

Bei nichtdeterministischen Systemen ersetzt eine spätere Wiederholung den ursprünglichen Lauf nicht. Sie kann bei der Analyse helfen, erzeugt aber möglicherweise ein anderes Ergebnis. Die tatsächliche Ausgabe und ihre betriebliche Verwendung müssen deshalb im Moment der Entscheidung gesichert werden.

Dasselbe Provenienzproblem kennen Redaktionen von veröffentlichten Aussagen. Ein aktueller Artikel verrät nicht automatisch, welche Quelle und Begründung seine frühere Fassung getragen haben. Der Journalbeitrag „Der Artikel ist live. Seine Begründung darf nicht verschwinden.“ untersucht diese verwandte Frage. Bei einer KI-gestützten Einzelentscheidung ist die Konsequenz schärfer: Ein verlorener Lauf kann verhindern, dass eine konkrete Folge wirksam bestritten wird.

Anfechtbarkeit ist der bessere Maßstab

Eine KI-Entscheidung ist nicht schon deshalb erklärbar, weil das Modell als interpretierbar gilt. Sie ist erklärbar, wenn sich der damalige Fall aus den verwendeten Daten, dem Systemzustand, der Entscheidungsregel und dem menschlichen Anteil verständlich zusammensetzen lässt.

Dafür braucht es weder grundsätzlich den vollständigen Quellcode noch eine unbegrenzte Vorratsspeicherung. Die Offenlegung des Algorithmus kann am Einzelfall vorbeigehen. Ein lückenloses Archiv kann wiederum mehr personenbezogene Daten binden, als die Erklärung rechtfertigt.

Der belastbare Entscheidungsbeleg liegt zwischen diesen Extremen. Er ist begrenzt, geschützt und auf den damaligen Fall bezogen. Er enthält genug, um die Folge zu verstehen, zu prüfen und gegebenenfalls anzufechten. Alles andere darf verschwinden. Nur nicht der Grund, aus dem diese konkrete Entscheidung entstand.