Audit-Trail: wer wann was in System und Automatisierung getan hat

Ein Audit-Trail ist ein fortlaufendes, nachträglich nicht veränderbares Protokoll darüber, wer in einem System oder einer Automatisierung wann welche Aktion ausgeführt hat und mit welchem Ergebnis. Er hält Menschen und Maschinen gleichermaßen fest: den Sachbearbeiter, der einen Datensatz ändert, ebenso wie den nächtlichen Abgleich oder den KI-Aufruf, der einen Entwurf erzeugt.

Was ein Audit-Trail festhält

Jeder Eintrag beantwortet dieselben Fragen, und zwar so, dass ein Außenstehender sie später ohne Rückfrage versteht:

• Wer. Eine eindeutige Kennung der Person oder des technischen Benutzers – bei Automatisierungen der Name des Ablaufs, nicht ein Sammelkonto „admin“.
• Was. Die Aktion und ihr Gegenstand: Datensatz angelegt, Feld geändert, Rechnung versendet, Freigabe erteilt.
• Wann. Ein Zeitstempel mit Zeitzone aus einer verlässlichen Uhr.
• Vorher und nachher. Bei Änderungen der alte und der neue Wert – sonst ist der Eintrag nur eine Behauptung.
• Womit und warum. Der Auslöser (Klick, Zeitplan, eingehende Nachricht), die Version der Regel oder der Anweisung an das Modell, bei Fehlern die Meldung.

Zwei Eigenschaften machen aus einer Liste einen Nachweis: Einträge werden nur angehängt, nie überschrieben, und wer im System fachlich arbeitet, kann das Protokoll nicht selbst bereinigen.

Protokoll, Logdatei, Versionsgeschichte: die Unterschiede

Technische Logdateien schreiben Entwickler zur Fehlersuche. Sie sind ausführlich, werden oft nach kurzer Zeit überschrieben und enthalten Details, die im Fachbereich niemand lesen kann. Eine Versionsgeschichte im Code-Repository zeigt, wer die Software geändert hat, aber nicht, was mit den Daten im Betrieb geschah. Das Änderungsprotokoll im engeren Sinn liegt dazwischen: fachlich lesbar, auf Geschäftsvorfälle bezogen und so lange aufbewahrt, wie Nachweispflichten es verlangen.

Bei Buchhaltungsdaten verlangen die GoBD Nachvollziehbarkeit und Unveränderbarkeit; ein Änderungsprotokoll ist dort keine Kür. Für Hochrisiko-KI-Systeme sieht die EU-KI-Verordnung eine automatische Protokollierung vor. Die meisten Automatisierungen im Mittelstand fallen nicht darunter, der Gedanke dahinter lässt sich trotzdem übernehmen.

Der Audit-Trail bei der Abnahme

Bei der Abnahme einer Automatisierung prüft der Auftraggeber, ob das Ergebnis den vereinbarten Kriterien entspricht. Ohne Protokoll bleibt ihm dafür eine Vorführung mit Beispieldaten. Mit Protokoll kann er echte Durchläufe nachvollziehen: Welche Vorgänge liefen durch, welche wurden als Ausnahme aussortiert und warum, wie oft musste ein Mensch eingreifen?

Deshalb gehört das Protokoll selbst in die Abnahmekriterien: welche Ereignisse erfasst werden, wo sie einsehbar sind und wie lange sie aufbewahrt werden. Wer das erst nach der Übergabe fordert, bestellt es als Nachtrag. Wie aussortierte Fälle geordnet weiterlaufen, beschreibt der Artikel Ausnahmebehandlung.

Auskunft, Löschung, Rechenschaft: Nachweise nach DSGVO

Die DSGVO verlangt vom Verantwortlichen, die Einhaltung ihrer Grundsätze nachweisen zu können. Im Alltag zeigt sich das an konkreten Anfragen:

• Auskunftsersuchen. Eine Person will wissen, welche Daten über sie verarbeitet wurden und an wen sie gingen. Ein Protokoll, das auch automatische Weitergaben an andere Systeme und KI-Dienste festhält, macht die Antwort vollständig.
• Löschung und Berichtigung. Der Eintrag belegt, dass und wann gelöscht oder korrigiert wurde, ohne die gelöschten Inhalte selbst weiter aufzubewahren.
• Datenpanne. Nach einem Vorfall muss eingegrenzt werden, welche Datensätze betroffen waren. Ohne Protokoll bleibt nur die ungünstigste Annahme.

Das Protokoll ist dabei selbst eine Verarbeitung personenbezogener Daten. Es braucht eine Aufbewahrungsfrist, einen begrenzten Leserkreis und nur so viel Inhalt, wie der Nachweis erfordert. Ein Protokoll, das ganze Kundendatensätze kopiert, schafft das nächste Problem.

Typische Lücken

• Sammelkonten. Alle Automatisierungen laufen unter einem technischen Benutzer; wer was ausgelöst hat, lässt sich nicht mehr trennen.
• Nur Fehler protokolliert. Erfolgreiche Durchläufe fehlen und damit der Beleg, dass ein Vorgang überhaupt stattfand.
• Überschreibbare Tabellen. Das Protokoll liegt in derselben Datenbank und mit denselben Schreibrechten wie die Daten, die es belegen soll.
• Wiederholte Läufe ohne Kennung. Ein abgebrochener Lauf startet neu und schreibt seine Einträge ein zweites Mal; ohne eindeutige Kennung je Vorgang lässt sich nicht mehr unterscheiden, was doppelt ist – eine Schwäche, die der Artikel Idempotenz behandelt.
• Niemand liest mit. Ein Protokoll, das erst im Streitfall geöffnet wird, taugt nicht als Frühwarnung; dafür ist Prozessmonitoring zuständig.

Wie wir Protokolle festlegen

Welche Ereignisse eine Automatisierung protokolliert, wo die Einträge einsehbar sind und wie lange sie liegen, schreiben wir als Abnahmekriterium ins Angebot, bevor die Arbeit beginnt. Wie wir KI-Aufrufe protokollieren, beschreibt der Beitrag KI-Aufrufe mit Kostengrenze. Wie wir Abläufe bauen, deren Läufe sich im Journal belegen lassen, beschreibt die Seite Geschäftsprozesse nachweisbar automatisieren.