Das Protokoll soll beweisen. Es darf nicht alles behalten. Das Protokoll soll beweisen. Es darf nicht alles behalten.

Die erste Logzeile ist bereits eine Entscheidung

Gedankliches Beispiel: Ein KI-System ordnet eine Bewerbung weit unten ein. Die Recruiterin hält die Empfehlung für falsch und verschiebt den Vorgang in die engere Auswahl. Monate später fragt die Bewerberin, welchen Einfluss das System hatte.

Nun soll das Protokoll beweisen, welche Ausgabe vorlag, welche Regeln galten und wer eingegriffen hat. Der scheinbar sichere Reflex lautet: alles speichern. Den Lebenslauf, sämtliche Eingaben und Ausgaben, Klicks, Bearbeitungszeiten und freien Notizen.

Damit ließe sich viel rekonstruieren. Es entstünde aber auch ein zweites Bewerberarchiv und ein detailliertes Arbeitsprotokoll der Personalabteilung. Die Beweissicherung hätte ihren Gegenstand verändert: Sie würde nicht mehr nur den Einsatz des Systems beschreiben, sondern zugleich die beteiligten Menschen vermessen.

Die DSGVO löst diesen Konflikt nicht zugunsten maximaler Aufzeichnung. Artikel 5 verbindet Zweckbindung, Datenminimierung, Speicherbegrenzung und Rechenschaft ↗. Ein Arbeitgeber muss die Rechtmäßigkeit einer Verarbeitung belegen können. Er darf daraus jedoch keine Erlaubnis ableiten, personenbezogene Daten für unbestimmte spätere Fragen auf Vorrat zu sammeln.

Die entscheidende Frage lautet deshalb nicht: Was kann das System protokollieren? Sie lautet: Was muss später über einen bestimmten Vorgang bewiesen werden können?

Der AI Act verlangt Logs, keine Totalaufnahme

Die AI Act Protokollierung wird leicht als allgemeine Pflicht verstanden, jede Interaktion mit einem KI-System sechs Monate lang aufzubewahren. Das steht so nicht in der Verordnung.

Artikel 26 Absatz 6 verpflichtet Betreiber von Hochrisiko-KI-Systemen, die automatisch erzeugten Logs unter ihrer Kontrolle für eine dem Zweck angemessene Dauer von mindestens sechs Monaten aufzubewahren, sofern anderes Unions- oder nationales Recht – insbesondere das Datenschutzrecht – nichts anderes bestimmt. Für Hochrisiko-Systeme nach Anhang III gelten die betreffenden Kapitel nach dem konsolidierten Rechtsstand vom 27. Juli 2026 ab dem 2. Dezember 2027. Zu Anhang III gehören unter anderem Systeme, die bestimmungsgemäß Bewerbungen analysieren oder filtern und Kandidatinnen und Kandidaten bewerten. Die konsolidierte Fassung trennt Anwendungszeitpunkt, Hochrisikoklassifizierung und Aufbewahrungspflicht ausdrücklich ↗.

Daraus folgen drei Grenzen. Erstens ist nicht jedes KI-System am Arbeitsplatz ein Hochrisiko-System. Maßgeblich sind Zweckbestimmung und konkreter Einsatz. Zweitens betrifft die Vorschrift automatisch erzeugte Logs, nicht automatisch jede zusätzlich angelegte Personal- oder Entscheidungsakte. Drittens bleibt das Datenschutzrecht anwendbar. Die Mindestdauer ist keine Aufforderung, den Inhalt eines Logs beliebig auszuweiten.

Vor dem Speicherkonzept steht daher die Systemklassifizierung: Entwirft die Anwendung nur einen internen Text? Priorisiert sie Vorgänge? Bewertet sie Personen? Beeinflusst ihre Ausgabe Einstellung, Aufgabenverteilung, Beförderung oder Beendigung eines Beschäftigungsverhältnisses? Eine Anbieterbeschreibung kann diese Fragen für den konkreten Betrieb nicht abschließend beantworten. Der Beitrag Die Anbieterakte kennt Ihren Einsatz nicht vertieft diese Verantwortung des Arbeitgebers.

Auch das deutsche Beschäftigtendatenschutzrecht setzt keine pauschale Speichererlaubnis. Nach § 26 BDSG ist die Verarbeitung von Beschäftigtendaten an ihre Erforderlichkeit für das Beschäftigungsverhältnis gebunden ↗; die Vorschrift erfasst ausdrücklich auch Bewerbende. Bei technischen Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung zu überwachen, nennt § 87 Absatz 1 Nummer 6 BetrVG das Mitbestimmungsrecht des Betriebsrats ↗. Ob eine konkrete Protokollierung darunter fällt, hängt von ihrer Ausgestaltung und Verwendung ab. Genau deshalb gehört das Logdesign vor die Einführung.

Drei Spuren, drei verschiedene Zwecke

Ein einziges umfassendes Protokoll wirkt übersichtlich. Tatsächlich vermischt es Aufgaben, Zugriffsrechte und Löschgründe. Belastbarer ist die Trennung in drei Spuren.

Die Systemspur beschreibt das technische Ereignis

Sie hält fest, welcher Dienst wann aufgerufen wurde, welche System- und Konfigurationsversion lief, ob ein Fehler auftrat und welcher Prozess den Aufruf ausgelöst hat. Häufig genügt eine pseudonyme Vorgangskennung. Namen, vollständige Eingaben und fachliche Dokumente müssen nicht automatisch in denselben Datensatz gelangen.

Diese Spur dient vor allem Betrieb, Sicherheit und Fehleranalyse. Auch administrative Zugriffe sollten nachvollziehbar sein. Sonst wird zwar die Nutzung des Systems protokolliert, nicht aber der besonders weitreichende Zugriff auf seine Aufzeichnungen.

Die Entscheidungsspur zeigt den tatsächlichen Einfluss

Sie verbindet den Vorgang mit der Systemausgabe, die einer Person tatsächlich angezeigt wurde. Hinzu kommen die geltende Regelversion, die zuständige menschliche Rolle, die Übernahme oder Korrektur der Empfehlung und das verantwortete Ergebnis.

Die Entscheidungsspur soll nicht jede Bedienhandlung festhalten. Mausbewegungen, Tippgeschwindigkeit oder die Dauer einzelner Bildschirmansichten beweisen meist keine sorgfältige Prüfung. Sie schaffen jedoch leicht Daten, die später zur Leistungs- oder Verhaltensbewertung verwendet werden können.

Die Streitakte entsteht erst aus einem Anlass

Eine Beschwerde, ein Sicherheitsvorfall oder ein arbeitsrechtliches Verfahren kann verlangen, bestimmte Unterlagen länger zu sichern. Dafür braucht es eine gesonderte Fallakte mit dokumentiertem Anlass, engerem Zugriff und einem eigenen Löschereignis.

Ein möglicher künftiger Streit rechtfertigt dagegen nicht, sämtliche Eingaben und Ausgaben aller Beschäftigten dauerhaft vorzuhalten. Das allgemeine Log darf kein vorsorgliches Beweislager für jeden denkbaren Konflikt werden.

Ein Feld ohne Zweck gehört nicht ins Protokoll

Die Speicherbegrenzung beginnt nicht mit einer pauschalen Frist, sondern mit einem Feldregister. Für jedes vorgesehene Datum sollte vor der technischen Umsetzung feststehen, welche Frage es beantwortet.

1. Benennen Sie den Entscheidungspunkt. Dokumentiert wird nicht abstrakt der gesamte KI-Workflow, sondern der Moment, in dem eine Ausgabe Folgen für eine Person oder einen Arbeitsprozess haben kann.

2. Formulieren Sie Fehler- und Streitszenarien. Welche Information wäre nötig, um eine falsche Datengrundlage, eine ungeeignete Konfiguration, eine missverstandene Ausgabe oder eine nur formale menschliche Prüfung zu erkennen?

3. Begründen Sie jedes Feld. Das Register nennt Zweck, betroffene Personengruppe, Rechtsgrundlage der Verarbeitung, Herkunft, Zugriffsrollen, Löschereignis und eine datenärmere Alternative. Ein Feld bleibt nicht erhalten, nur weil es technisch verfügbar ist.

4. Verweisen Sie, statt zu duplizieren. Liegen Bewerbungsunterlagen oder Personalstammdaten bereits kontrolliert in einem Fachsystem, kann die Entscheidungsspur auf den dortigen Datensatz und seinen damaligen Stand verweisen. Voraussetzung ist, dass der Verweis über die benötigte Nachweisdauer stabil bleibt.

5. Trennen Sie Leserechte und Exporte. IT-Sicherheit, Personalabteilung, Datenschutz, Revision und Führungskräfte brauchen nicht dieselbe Sicht. Ein Exportrecht kann getrennte Spuren wieder zu einem umfassenden Verhaltensprofil verbinden.

6. Testen Sie das Ende. Eine Frist im Löschkonzept genügt nicht. Der Test muss auch Indizes, Ausleitungen, lokale Exporte und Sicherungskopien erfassen. Wo Daten nicht sofort physisch verschwinden, muss wenigstens klar sein, wann sie überschrieben werden und wie der operative Zugriff bis dahin ausgeschlossen bleibt.

Manipulationsschutz beantwortet eine andere Frage. Eine signierte oder verkettete Ereignisfolge kann nachträgliche Änderungen erkennbar machen. Sie beweist nicht, dass die ursprüngliche Aufzeichnung vollständig oder fachlich richtig war. Integrität schützt den Nachweis vor stiller Veränderung; sie ersetzt keine Prüfung seines Inhalts.

Der Bewerbungsfall bleibt im Fachsystem

Zurück zum gedanklichen Beispiel. Das Unternehmen nutzt ein KI-System, das Bewerbungen für die menschliche Sichtung priorisiert. Es spricht selbst keine Absage aus. Seine Reihenfolge beeinflusst aber, welche Profile zuerst geprüft werden.

Die Bewerbungsunterlagen bleiben im führenden Fachsystem. Dort gelten die festgelegten Berechtigungen und Löschregeln. Die technische Systemspur erhält lediglich eine Vorgangskennung sowie System-, Konfigurations- und Fehlerdaten.

Die Entscheidungsspur speichert die Stellen- und Vorgangskennung, den Zeitpunkt, die verwendete Regel- und Systemversion, die tatsächlich angezeigte Empfehlung sowie die verantwortliche Rolle. Außerdem hält sie fest, ob die Empfehlung übernommen oder korrigiert wurde. Für wiederkehrende Abweichungen können begrenzte Kategorien sinnvoll sein, etwa „Qualifikation falsch erkannt“ oder „Dokument unvollständig verarbeitet“. Freitext bleibt auf Fälle beschränkt, in denen eine nachvollziehbare Erklärung anders nicht möglich ist.

Der vollständige Lebenslauf wird nicht ein zweites Mal in das Log kopiert. Auch Verweildauer, Tastatureingaben und sämtliche Zwischenstände bleiben draußen. Falls der Datenstand im Fachsystem früher gelöscht oder überschrieben würde als der Entscheidungsnachweis, muss das Unternehmen bewusst abwägen: Genügt eine versionierte Referenz? Braucht es einen begrenzten Snapshot der tatsächlich verwendeten Merkmale? Oder ist die Nachweisdauer der Entscheidungsspur zu lang angesetzt?

Ein Snapshot kann in besonders folgenreichen Fällen nötig sein. Er ist dann jedoch kein beiläufiges Technikdatum, sondern ein eigener personenbezogener Nachweisbereich mit Zweck, Berechtigung und Löschereignis.

Ein Modellname allein erklärt den Vorgang nicht. Er sagt weder, welche konkrete Version und Konfiguration verwendet wurden, noch welche Ausgabe die Recruiterin sah. Warum eine allgemeine Modellerklärung den Einzelfall nicht ersetzt, zeigt Das Modell kann erklären. Der Einzelfall ist verschwunden.

Menschliche Aufsicht ist kein Benutzername

Ein Feld mit dem Wert „menschlich geprüft“ ist schnell angelegt. Es belegt noch keine wirksame menschliche Aufsicht.

Für Hochrisiko-KI verlangt der AI Act, dass die zuständigen Personen die Fähigkeiten und Grenzen des Systems verstehen, seine Ausgabe angemessen interpretieren und sie im Einzelfall verwerfen, überschreiben oder rückgängig machen können. Ein brauchbarer Nachweis hält deshalb nicht nur fest, wer angemeldet war. Er zeigt, welche Ausgabe vorlag und welche verantwortete Handlung daraus folgte.

Auch das bleibt begrenzt. Das Protokoll kann eine Korrektur oder Freigabe dokumentieren. Es kann aus sich heraus nicht beweisen, dass die Person genügend Zeit, Kompetenz und organisatorische Autorität für eine echte Prüfung hatte. Diese Voraussetzungen liegen außerhalb der Logdatei: in Rollen, Schulung, Arbeitsgestaltung und Eskalationswegen.

Die menschliche Aufsicht darf zudem nicht selbst zur dauerhaften Leistungskontrolle werden. Wer jede Pause, jeden Klick und jede Abweichung misst, dokumentiert nicht mehr nur die Kontrollfähigkeit des Systems. Er baut ein Messsystem über die Kontrollierenden.

Wenn weniger Speicherung den Nachweis zerstört

Datensparsamkeit kann zur Ausrede werden. Eine Vorgangsnummer, ein Zeitstempel und ein Prüfvermerk reichen nicht, wenn die sichtbare Ausgabe unbekannt, die Regelversion überschrieben und der referenzierte Datenstand nicht mehr erreichbar ist. Dann bleibt nur die Behauptung eines ordentlichen Ablaufs.

Deshalb müssen Verweise und Löschfristen zusammenpassen. Die Systemspur, das Fachsystem und die Entscheidungsspur dürfen nicht unabhängig voneinander veralten. Wo ein notwendiger Nachweis sonst ins Leere liefe, braucht es entweder eine kürzere Aufbewahrung der Entscheidungsspur oder einen eng begrenzten, ausdrücklich geregelten Datenstand.

Die französische Datenschutzbehörde CNIL empfiehlt für Anwendungsprotokolle unter anderem Autor, Zeitpunkt und Art einer Operation sowie eine Referenz auf die betroffenen Daten, um unnötige Duplikate zu vermeiden. Für die von ihr behandelten Ereignisprotokolle nennt sie eine rollierende Aufbewahrung zwischen sechs Monaten und einem Jahr. Gleichzeitig warnt sie vor übermäßigen Kopien, zweckfremder Verwendung und unbegrenzter Speicherung. Die CNIL beschreibt damit beide Seiten eines belastbaren Logdesigns ↗. Ihre Empfehlung ist keine allgemeine gesetzliche Speicherfrist für deutsche Arbeitgeber.

Auch Tarifverträge, Betriebsvereinbarungen, laufende Verfahren und besondere gesetzliche Aufbewahrungspflichten können im Einzelfall andere Ergebnisse verlangen. Ein Feldregister ersetzt daher weder die Systemklassifizierung noch die arbeits- und datenschutzrechtliche Prüfung.

Die Grenze verläuft durch den Zweck

Ein gutes Protokoll ist absichtlich unvollständig. Es bewahrt, was eine konkrete Entscheidung anfechtbar und einen Fehler untersuchbar macht: den verwendeten Datenstand, den relevanten Systemzustand, die sichtbare Ausgabe, den menschlichen Eingriff und das verantwortete Ergebnis.

Zu wenig Speicherung entwertet den Nachweis. Zu viel verändert seinen Gegenstand. Aus dem Protokoll über ein System wird eine Nebenakte über die Menschen, die mit ihm arbeiten oder von ihm beurteilt werden.

Die tragende Entscheidung fällt deshalb vor der ersten Logzeile. Nicht bei der Frage, wie lange sich alles speichern lässt, sondern bei der Frage, was später bewiesen werden muss – und was gerade deshalb nicht behalten werden darf.