Ihr Audit-Log rettet Sie nicht! Non-deterministische KI‑Agenten brauchen eine erweiterte Vertragsebene

User Flows, Wireframes und Klick-Dummies, ergänzt durch Prozessmodelle, Zustandsautomaten, API-Spezifikationen und Regressionstests per Screenshot-Diff: Das Methodenarsenal, mit dem Finanzinstitute IT-Systeme spezifizieren und abnehmen, ist ausgereift und prüfungserprobt. Es beruht auf einem Prinzip, das selbstverständlich scheint: Ein System verhält sich reproduzierbar. Sind Zustand und Eingabe bekannt, steht das Ergebnis fest. Abnahme heißt dann, Soll und Ist zu vergleichen.

von Christoph Bieselt, Dayy

Bei heute typischen, über externe Modell-APIs betriebenen LLM-Agenten ist diese Reproduzierbarkeit nicht mehr garantiert. Selbst bei einer Temperatur von null können Batching, Gleitkomma-Effekte auf der Inferenz-Hardware und stille Modell-Updates dazu führen, dass dieselbe Anfrage unterschiedliche Antworten erzeugt. Hinzu kommt, dass das Verhalten eines Agenten, neben dem genutzten Modell, von einem komplexen Gerüst aus System-Prompt, verfügbarem Kontext, Tool-Ergebnissen und Gesprächsverlauf abhängt.

In der Praxis wird diese Lücke häufig mit zwei Mitteln gefüllt: mit immer ausgefeilteren Prompts und mit vollständiger Protokollierung.“

Prompt-Engineering übernimmt dabei faktisch die Rolle der Governance. Die Regeln, was ein Agent darf und was nicht, stehen als natürlichsprachlicher Text im System-Prompt, und das Log soll im Nachhinein belegen, dass alles korrekt lief.
Kritisch wird es in dem Moment, in dem eine Aufsicht, eine interne Revision oder ein Gericht wissen will, warum der Agent in einem konkreten Szenario so und nicht anders reagiert hat. Die ehrliche Antwort lautet dann oft: weil das Modell den Prompt in diesem Moment so interpretiert hat. Solche Begründungen allein dürften einer tieferen Prüfung durch BaFin oder FINMA kaum genügen.

Warum das Log die falsche Frage beantwortet

Ein Audit-Log beantwortet die Frage „Was ist passiert?“. Bei einer Prüfung stellt sich jedoch auch die Frage: „Welche Handlungen wären möglich gewesen, welche waren ausgeschlossen – und wodurch?“ Erst die zweite Frage zielt auf den Nachweis wirksamer Kontrolle. Eine Grenze, die erst im Log sichtbar wird, hat nicht zwangsläufig im Vorfeld gewirkt.

Was es braucht, ist eine erweiterte technische Vertragsebene innerhalb des Agenten: verbindliche Vorgaben, die vor oder während einer Handlung greifen.“

Nachgelagerte Prüfungen, etwa von Modellausgaben, können diese ergänzen. Drei Architektur­ent­schei­dungen stehen dabei im Mittelpunkt: typisierte Tool-Definitionen begrenzen die ausführbaren Aktionen, strukturierte Session-Artefakte halten den maßgeblichen Zustand fest, und revisionsgepinntes Publishing ordnet jeder Sitzung eine eindeutige Version des Verhaltensvertrags zu.

1. Tools als Vollzugsgrenze statt Prompt-Disziplin

Der wichtigste Schritt ist eine klare Trennung zwischen Denken und Handeln. Das Modell darf eine Überweisung vorschlagen. Ob sie ausgeführt werden kann, muss die Anwendung entscheiden. Dafür erhält der Agent einen festen Bestand an Tools, deren Funktionen und Parameter im Code definiert sind. Auch für die Benutzeroberfläche braucht es einen freigegebenen Bestand an Komponenten.
Damit bekommt eine Regel wie „Keine Überweisung über 10.000 Euro ohne Freigabe“ eine andere Verbindlichkeit. Sie steht nicht mehr nur als Anweisung im Prompt.

Die Validierung der Parameter sowie weitere Prüfungen erfolgen deterministisch im Code, bevor eine Aktion ausgelöst wird.“

Solange sämtliche relevanten Aktionen über diese kontrollierten Schnittstellen laufen, kann das Modell eine unzulässige Überweisung zwar vorschlagen, technisch aber nicht selbstständig ausführen.
Aus einer Guardrail als Text wird so eine Guardrail als Vertrag. Die Menge der möglichen Aktionen ergibt sich aus den Tool-Definitionen und ihrer Parametervalidierung. Diese lassen sich überprüfen, versionieren und testen wie jeder andere Code.

2. Session-Artefakte statt Kontext im Chatverlauf

Viele Agenten-Implementierungen behandeln den Gesprächsverlauf als Wahrheit und Gedächtnis. Was der Nutzer vor zehn Nachrichten gesagt hat, „weiß“ das Modell, weil es im Kontextfenster steht. Für kontinuitätskritische Fakten ist das unzureichend.
Welcher Vorgang aktiv ist, welche Dringlichkeitsstufe gilt, ob eine Einwilligung vorliegt und in welchem Schritt eines Workflows sich die Session befindet, gehört in strukturierte, vom Chatverlauf entkoppelte Session-Artefakte. Dort hält die Anwendung fest, welcher Vorgang bearbeitet wird und wie weit er fortgeschritten ist. Der Gesprächsverlauf kann erklären, wie es dazu kam.

Die Anwendung muss den gültigen Zustand jedoch abfragen können, ohne ihn vom Modell erneut aus dem Gespräch ableiten zu lassen.“

Der naheliegende Einwand lautet: Der Verlauf ist doch vorhanden. Das stimmt. In regulierten Umgebungen wird er häufig umfassend protokolliert. Allerdings ist das sichtbare Gespräch nur ein Teil dessen, was dem Modell bei einer Antwort vorlag. Der System-Prompt wirkt ebenfalls auf die Antwort ein. Hinzu kommen beispielsweise Dokumente, die erst während der Sitzung geladen wurden.
Ob eine Einwilligung vorlag, muss als Fakt im System stehen. Es darf nicht davon abhängen, wie ein Modell einen Satz wie „Ja, passt schon“ im Kontext gelesen hat.

Das Kontextmodell muss deshalb bereits bei der Systemarchitektur berücksichtigt werden.“

Davon hängen die Kontinuität der Nutzersitzungen und die verlässliche Prüfung von Aktionen ab. Nur wenn der maßgebliche Zustand eindeutig vorliegt, kann die Anwendung feststellen, ob die Voraussetzungen für einen Tool-Aufruf erfüllt sind.

3. Revisionsgepinntes Publishing

Für einzelne Prompts existieren bereits etablierte Versionierungslösungen. Damit ist aber noch nicht geklärt, welcher Verhaltensvertrag für eine Sitzung galt. Ein unveränderter Prompt hilft wenig, wenn zwischenzeitlich ein Tool andere Parameter verlangt oder ein Eskalationsziel geändert wurde. In der Praxis werden diese Bestandteile jedoch häufig getrennt verwaltet. Ein validiertes und revisionsgepinntes Artefakt fehlt dann.

Der Gegenentwurf behandelt den gesamten Verhaltensvertrag wie Software. Vor der Veröffentlichung wird maschinell geprüft, ob seine Bestandteile zu den verfügbaren Funktionen passen.“

Ein im Vertrag genanntes Tool muss vorhanden sein. Ein Eskalationsziel muss sich gegen das zuständige Verzeichnis prüfen lassen. Fehlerhafte Verweise fallen so vor dem Einsatz auf.
Der geprüfte Vertrag wird anschließend als unveränderliche Version veröffentlicht. Ein Hash des Inhalts dient als eindeutige Kennung. Jede Sitzung erhält beim Start diese Kennung und bleibt bis zum Ende an die betreffende Version gebunden. Wird währenddessen eine neue Version veröffentlicht, gilt diese für neu gestartete Sitzungen.
Fragt die Revision später nach den Regeln vom 14. März, lässt sich die Sitzung einer konkreten Version zuordnen. Prüfen lassen sich die Regeln nur, wenn das Institut den vollständigen Vertrag archiviert hat. Der Hash belegt dann zusätzlich, dass diese Version tatsächlich auch unverändert ist.

Die drei Bausteine müssen im Zusammenspiel überprüft werden: Blockiert die Anwendung einen unzulässigen Tool-Aufruf? Bleibt eine dokumentierte Freigabe auch bei gekürztem Gesprächskontext eindeutig zugeordnet? Lässt sich für eine abgeschlossene Session die gültige Revision wiederherstellen?“

Im Audit-Trail wird festgehalten, welche Aktion auf dieser Grundlage ausgeführt oder abgewiesen wurde.
Für die Beschreibung solcher Tests und die Bewertung ihrer Ergebnisse besteht weiterhin Entwicklungsbedarf. Ein bestandener Test allein sagt noch wenig darüber aus, ob die wesentlichen Risiken abgedeckt sind. Auch das muss gegenüber Aufsicht und Revision begründet werden können.
Dayy arbeitet deshalb in einem eigenen Forschungs- und Entwicklungsvorhaben an einer Testmethodik, mit der sich das Verhalten probabilistischer KI-Agenten anhand definierter Anforderungen überprüfen und dokumentieren lässt.

Fazit: Architektur vor Protokoll

Keiner der Bausteine macht ein Audit-Log überflüssig. Es wird weiterhin gebraucht, um nachzuvollziehen, was geschehen ist. Eine unzulässige Aktion verhindern kann es jedoch nicht. Die Anwendung muss die Grenzen des Agenten bereits bei der Ausführung durchsetzen. Für eine spätere Prüfung muss außerdem feststehen, welcher Zustand und welche Vertragsversion dabei galten.

Wer KI-Agenten in regulierten Umgebungen einführt, muss die Frage, was ein Agent darf, früh im Projekt als Architekturaufgabe behandeln.“

Dazu gehört auch, die Verantwortung für diese Grenzen festzulegen. Wer gibt eine Aktion frei? Wer entscheidet, ob eine Regel geändert werden darf? Die Antworten darauf sollten mehrere Abteilungen gemeinsam erarbeiten, bevor die Grenzen im Code festgeschrieben werden.
Wenn die Revision Jahre später nach einem Vorgang vom 14. März fragt, muss die Antwort über den Gesprächsverlauf hinausgehen. Das Institut muss zeigen können, welche Regeln damals galten und wie die Anwendung sie durchgesetzt hat. Erst dann wird aus einem protokollierten Vorgang ein belastbarer Nachweis wirksamer Kontrolle. Christoph Bieselt, Dayy