Audit-Trail für KI-Systeme: Warum jeder Schritt einen Beleg braucht

Was ein Audit-Trail ist — und was eine Logdatei nicht ist

Fast jedes System schreibt Logdateien. Sie sind für die Fehlersuche gemacht: technisch, kurzlebig, oft rotierend überschrieben, und sie protokollieren, was das Programm getan hat, nicht was fachlich geschehen ist. Ein Audit-Trail beantwortet eine andere Frage — nicht „warum ist es abgestürzt“, sondern „wer hat was wann veranlasst, und was kam dabei heraus“.

Der letzte Punkt ist der, an dem sich Nachweise entscheiden. Ein Protokoll, aus dem sich Einträge entfernen lassen, belegt nichts — es zeigt nur den Stand, den jemand zeigen wollte. Deshalb wird bei einem Audit-Trail angehängt: Eine Korrektur ist ein neuer Eintrag, der den alten erklärt, nicht ein überschriebener alter.

Was ein brauchbarer Nachweis enthält

Sechs Angaben je Eintrag reichen für die meisten Fälle. Sie sind der Maßstab, an dem sich auch ein fremdes System prüfen lässt: Fehlt eine davon, bleibt am Ende eine Lücke, die niemand mehr schließen kann.

1. Zeitpunkt — wann der Vorgang stattfand, nicht wann protokolliert wurde.
2. Auslöser — welcher Mensch, welches System oder welcher Agent gehandelt hat.
3. Vorgang — was getan wurde, in fachlichen Worten und nicht als technischer Aufruf.
4. Gegenstand — worauf sich der Vorgang bezog, eindeutig identifiziert.
5. Ergebnis — was dabei herauskam, einschließlich Ablehnung und Fehlschlag.
6. Prüfung — wer oder was das Ergebnis kontrolliert hat und mit welchem Urteil.

Bei KI-Systemen kommt eine siebte Angabe dazu, die im klassischen Audit-Trail fehlt: welches Modell beteiligt war. Ohne sie lässt sich später nicht unterscheiden, ob ein Fehler an der Vorgabe, am Modell oder an der Prüfung lag — und genau diese Unterscheidung braucht man, wenn ein Ergebnis beanstandet wird.

Warum KI-Systeme den Nachweis dringender brauchen

Ein Agent führt mehrere Schritte selbständig aus: Er liest Daten, ruft Werkzeuge auf, entscheidet, welcher Schritt als Nächstes kommt. Zwischen Auftrag und Ergebnis liegen deshalb viele Zwischenschritte, die niemand beobachtet hat. Die naheliegende Antwort — das Modell anschließend nach einer Zusammenfassung zu fragen — hilft nicht: Eine Zusammenfassung ist eine Aussage des Modells über sich selbst.

Dazu kommt die gemessene Fehleranfälligkeit. Veracode fand 2025 in 45 % der von über 100 Modellen erzeugten Code-Beispiele Schwachstellen aus den OWASP Top 10, bei Java in 72 %. In der Untersuchung von Perry und Kollegen (ACM CCS 2023) schrieben Entwickler mit KI-Assistent unsichereren Code und hielten ihn zugleich häufiger für sicher. Ein System, das solche Ergebnisse erzeugt, muss nicht nur geprüft werden — die Prüfung muss auch nachlesbar sein.

Der Standard, über den Agenten heute Werkzeuge anbinden, hat diese Sorge aufgenommen: Die Spezifikation des Model Context Protocol in der Fassung 2025-06-18 verlangt, dass Hosts vor jedem Werkzeugaufruf die ausdrückliche Zustimmung des Nutzers einholen. Zustimmung und Nachweis gehören zusammen — die eine legt fest, was passieren darf, der andere hält fest, was passiert ist.

Was ein Prüfsiegel leistet — und was nicht

Ein Prüfsiegel bindet einen geprüften Stand an eine konkrete Version. Bei MCP Baldux entsteht es, wenn alle vier Prüfrollen zugestimmt haben, und es ist kryptografisch überprüfbar: Wer wissen will, ob der laufende Stand noch der geprüfte ist, kann das nachrechnen.

Ein Prüfsiegel ist kryptografisch überprüfbar, nicht fälschungssicher. Es verhindert keine Änderung — es macht sie erkennbar. Und es beweist nicht, dass der Code fehlerfrei ist; es belegt, dass eine bestimmte Prüfung an einem bestimmten Stand stattgefunden hat.

Diese Unterscheidung ist der Grund, warum wir sie überall gleich formulieren. Ein Siegel, das als Sicherheitsgarantie verkauft wird, verspricht etwas, das keine Technik halten kann. Was es tatsächlich leistet, ist die Grundlage für eine ganz praktische Frage im Streitfall: Ist das, was heute läuft, dasselbe, was damals geprüft wurde?

Wie ein Audit-Trail in die eigene Anwendung kommt

Zwei Ebenen sind zu unterscheiden, und sie werden regelmäßig verwechselt. Die eine ist der Nachweis über den Bauvorgang — wie die Anwendung entstanden ist. Die andere ist der fachliche Audit-Trail im laufenden Betrieb — wer in Ihrer Anwendung welchen Auftrag freigegeben hat.

Die zweite Ebene ist eine Entscheidung, die in die Beratung gehört: Welche Vorgänge sind protokollpflichtig, wie lange werden Einträge aufbewahrt, wer darf sie lesen. Rechte und Aufbewahrung gehören dabei zusammen — ein Protokoll, das jeder einsehen darf, ist selbst ein Datenschutzthema.

Ob Ihr Haus zu einem Audit-Trail verpflichtet ist, hängt an Branche, Verarbeitung und Rolle; für die Bewertung Ihres Falls ist Ihre Rechtsabteilung oder eine Kanzlei zuständig. Die Einordnung der europäischen KI-Verordnung samt Fristen steht im Lexikon — sie ist eine Einordnung, keine Rechtsberatung.