Sobald ein KI-Agent nicht mehr nur Entwürfe schreibt, sondern Datensätze anlegt, Felder ändert oder Tickets schließt, kommt im Betrieb früher oder später eine Rückfrage: Warum steht hier dieser Wert, und wer hat ihn gesetzt? Spätestens dann zeigt sich, ob jemand nachvollziehbar prüfen kann, was ein KI-Agent geändert hat und warum. In vielen Projekten lautet die ehrliche Antwort: Man sieht, dass ein technisches Konto etwas geändert hat, aber nicht, auf welcher Grundlage.
Das liegt selten an fehlender Technik, sondern daran, dass die Frage erst gestellt wird, wenn der Agent schon läuft. Dieser Beitrag beschreibt, welche Angaben ein Agentenprotokoll braucht, wo es entsteht und wie sich prüfen lässt, ob es reicht.
Warum ein gewöhnliches Änderungsprotokoll nicht genügt
Die meisten Geschäftsanwendungen protokollieren Änderungen bereits mit Zeitpunkt, Benutzer und altem und neuem Wert. Bei Menschen reicht das oft, weil man nachfragen kann. Bei einem Agenten fehlt dieser Weg. Er erinnert sich beim nächsten Aufruf nicht an seine Gründe, und eine nachträgliche Frage an das Modell liefert eine neu formulierte Erklärung, keine Aufzeichnung dessen, was tatsächlich geschah.
Dazu kommt, dass ein Agent über mehrere Systeme arbeitet. Er liest eine E-Mail, schlägt in der Warenwirtschaft nach und ändert dann einen Eintrag im CRM. Das Änderungsprotokoll des CRM kennt nur den letzten Schritt. Die E-Mail, die den Ausschlag gab, steht darin nicht. Das „Warum“ entsteht aber genau in den Schritten davor.
Wie prüfe ich nachvollziehbar, was ein KI-Agent geändert hat und warum?
Nachvollziehbar ist eine Änderung dann, wenn sich aus dem Protokoll allein die Kette rekonstruieren lässt: Auftrag, gelesene Eingaben, angewandte Regel, ausgeführte Aktion, Ergebnis und gegebenenfalls Freigabe. Die folgenden Angaben gehören deshalb zu jedem schreibenden Schritt:
| Angabe | Welche Frage sie beantwortet |
|---|---|
| Lauf-Kennung | Welche Schritte gehören zu demselben Auftrag? |
| Agent und Auftraggeber | Welcher Agent hat gehandelt, in wessen Auftrag? |
| Eingaben mit Verweis | Welche E-Mail, welches Dokument, welcher Datensatz lag vor? |
| Aufgerufenes Werkzeug mit Parametern | Was genau wurde in welchem System ausgelöst? |
| Wert vorher und nachher | Was hat sich geändert, und wie lässt es sich zurücksetzen? |
| Begründung zum Zeitpunkt der Aktion | Auf welche Regel oder Angabe stützt sich der Schritt? |
| Versionen von Modell, Anweisungen und Werkzeugen | Mit welchem Stand des Agenten ist es passiert? |
| Freigabe | Hat ein Mensch zugestimmt, und wer? |
Zwei Punkte werden oft übersehen. Erstens die Begründung: Sie muss im selben Schritt entstehen wie die Aktion, etwa als Pflichtfeld, das der Agent beim Aufruf des Werkzeugs ausfüllen muss, mit Verweis auf die Regel oder Eingabe, auf die er sich stützt. Eine Begründung, die erst Tage später erfragt wird, ist eine Rekonstruktion. Zweitens die Versionen: Wenn sich ein Verhalten nach einem Modellwechsel ändert, lässt sich das nur erkennen, wenn jeder Schritt den Stand des Agenten trägt.
Wo das Protokoll entstehen muss
Das Protokoll gehört nicht in die Verantwortung des Modells. Eine Anweisung, Schritte zu notieren, befolgt es meistens, aber nicht verlässlich, und nach einer manipulierten Eingabe womöglich falsch.
Die Aufzeichnung entsteht deshalb in der Software um den Agenten herum: dort, wo seine Werkzeugaufrufe ausgeführt werden. Jeder Aufruf läuft durch diese Schicht, wird mit den genannten Angaben festgehalten und erst dann an das Zielsystem weitergereicht. Der Agent kann diese Einträge weder ändern noch löschen. Wie eine solche Schicht aufgebaut ist, beschreiben wir auf der Seite zur Harness-Architektur für KI-Agenten.
Voraussetzung ist ein eigenes Konto pro Agent und Zweck, damit Einträge überhaupt zuordenbar sind. Den Zuschnitt dieser Rechte behandeln wir in Zugriffsrechte für KI-Agenten: In wessen Namen handelt der Agent?.
Was nicht ins Protokoll gehört
Vollständig heißt nicht, alles zu speichern. Zugangsdaten und Schlüssel haben im Protokoll nichts zu suchen, auch wenn der Agent sie in einer Eingabe gesehen hat. Personenbezogene Daten werden nur so weit erfasst, wie die Rückverfolgung es verlangt; oft genügt ein Verweis auf die E-Mail statt ihres Texts. Aufbewahrung und zulässige Inhalte klären Sie mit Ihrer Datenschutzberatung.
So prüfen wir, ob das Protokoll reicht
Ob ein Protokoll taugt, zeigt erst eine echte Rückfrage. Wir prüfen es deshalb vor dem Start und danach regelmäßig mit einer Stichprobe:
- Änderung zufällig auswählen. Aus den Änderungen des Agenten wird eine beliebige gezogen, nicht eine, die man gut kennt.
- Jemand Unbeteiligtes verfolgt sie zurück. Eine Person, die den Agenten nicht gebaut hat, beantwortet allein aus dem Protokoll: Welcher Auftrag, welche Eingaben, welche Regel, welches Ergebnis, welche Freigabe?
- Begründung gegen die Eingaben halten. Stimmt die notierte Begründung mit dem überein, was in den Eingaben tatsächlich steht? Weicht beides ab, ist das ein Befund über den Agenten, nicht über das Protokoll.
- Zurücksetzen durchspielen. Lässt sich die Änderung mit dem gespeicherten Vorher-Wert rückgängig machen, ohne in einem anderen System nachzuforschen?
- Lücken schließen. Jede Frage, die nur mit Rückfrage beim Entwicklerteam beantwortet werden konnte, wird zu einer neuen Pflichtangabe im Protokoll.
Die Stichprobe zeigt nebenbei, ob ein Agent seinen Anweisungen folgt. Passen die Begründungen wiederholt nicht zu den Eingaben, gehören diese Fälle in die Testsammlung, an der jede neue Version gemessen wird.
- Stichprobe zieheneine beliebige Änderung des Agenten auswählen
- Kette lesenAuftrag, Eingaben, Regel, Aktion und Freigabe aus dem Protokoll
- Begründung prüfenpasst sie zu den tatsächlichen Eingaben?
- Zurücksetzen testenVorher-Wert genügt ohne weitere Nachforschung
- Lücken schließenfehlende Angaben werden zur Pflicht
Grafik verwenden? Gern, mit Quelle Wundrig und Link auf diesen Beitrag. Hinweise
Ein Prüfagent als Beispiel
Besonders deutlich wird der Nutzen bei Agenten, deren eigentliches Ergebnis eine Entscheidung ist. Wir haben einen Agenten gebaut, der Produkte auf Marktplätzen gegen den Kriterienkatalog eines Gütesiegels prüft. Dort genügt ein „passt“ oder „passt nicht“ nicht: Zu jedem Ergebnis gehört die Angabe, welches Kriterium mit welcher Stelle der Produktseite erfüllt oder verfehlt ist. Diese Begründung entsteht im selben Schritt wie das Ergebnis und wird mit ihm gespeichert. So kann ein Mensch ein Ergebnis in kurzer Zeit nachvollziehen, ohne die Produktseite selbst neu zu lesen. Mehr zu solchen Prüfagenten und anderen Einsatzformen finden Sie auf unserer Seite zu KI-Agenten.
Für Informationen, die ein Agent sich merkt, gilt dieselbe Kette aus Quelle, Zeitpunkt und Freigabe; dazu mehr in Das Gedächtnis von KI-Agenten: Wer darf hineinschreiben?.
Fazit
Nachvollziehbarkeit bei KI-Agenten entsteht nicht durch nachträgliches Fragen, sondern durch Aufzeichnung im Moment der Aktion. Jeder schreibende Schritt braucht Auftrag, Eingaben, Werkzeugaufruf, Vorher- und Nachher-Wert, eine gleichzeitig entstandene Begründung, die Versionen des Agenten und gegebenenfalls die Freigabe. Diese Angaben schreibt die Software um den Agenten, nicht das Modell selbst, und der Agent kann sie nicht verändern. Ob das Protokoll reicht, zeigt eine regelmäßige Stichprobe, bei der jemand Unbeteiligtes eine zufällige Änderung zurückverfolgt und zurücksetzt.
Häufige Fragen
Kann man einen KI-Agenten nachträglich fragen, warum er etwas geändert hat?
Fragen kann man, aber die Antwort ist eine neu formulierte Erklärung und keine Aufzeichnung dessen, was tatsächlich geschah. Verlässlich ist nur eine Begründung, die im selben Schritt wie die Aktion entstanden und gespeichert ist. Sie lässt sich dann gegen die protokollierten Eingaben prüfen.
Was sollte ein Protokoll für KI-Agenten enthalten?
Zu jedem schreibenden Schritt gehören eine Lauf-Kennung, Agent und Auftraggeber, Verweise auf die Eingaben, der Werkzeugaufruf mit Parametern, der Wert vorher und nachher, die Begründung, die Versionen von Modell und Anweisungen sowie eine allfällige Freigabe. Zugangsdaten gehören nicht hinein, personenbezogene Daten nur so weit wie nötig.
Woran erkennt man, ob ein KI-Agent seinen Anweisungen folgt?
Ein Weg ist die regelmäßige Stichprobe: Eine zufällige Änderung wird zurückverfolgt und die notierte Begründung mit den tatsächlichen Eingaben verglichen. Passen beide wiederholt nicht zusammen, folgt der Agent seinen Regeln nicht verlässlich. Solche Fälle gehören in die Testsammlung, an der jede neue Version gemessen wird.