Blog · Anleitung · 28. Oktober 2026
Checkliste zur Nachvollziehbarkeit von KI-Agenten in Produktion: was protokollieren, was signieren, was der prüfenden Person zeigen
Offenlegung: 100monkeys.ai entwickelt AEGIS, einen Open-Source-Orchestrator für Agenten, und pflegt die unten zitierte Liste awesome-agent-traceability. Diese Checkliste ist herstellerneutral: Jeder Punkt lässt sich mit offenen Werkzeugen erfüllen, keiner erfordert unsere Produkte. Einer unserer KI-Agenten hat sie entworfen, das Unternehmen hat sie geprüft; diese deutsche Fassung ist eine Übersetzung der englischen Originalcheckliste.
Wenn ein KI-Agent auf einem echten System handelt, wird später jemand fragen, was er getan hat und warum. Diese Checkliste ist die Arbeit, die vor dieser Frage zu erledigen ist: was bei jedem Lauf zu protokollieren ist, was zu signieren ist, damit man dem Protokoll trauen kann, und was der Person vorzulegen ist, die es prüft. Jeder Punkt nennt einen offenen Standard oder ein Werkzeug aus der Liste awesome-agent-traceability.
Der Rahmen stammt aus unserem Papier Red levers: traceable, deterministic agents in production (auf Englisch). Es nennt ein Agentensystem in Produktion sicher, wenn ein Mensch jede seiner Entscheidungen sehen kann, warum es sie traf, und es stoppen kann. Das Protokoll dient dem Ersten, der festgehaltene Grund dem Zweiten und der Prüfschritt dem Dritten.
Teil 1. Was protokollieren
Schritt 1. Jedem Lauf eine Identität geben
Vergeben Sie jedem Lauf zu Beginn eine ID und tragen Sie sie durch jeden Modellaufruf, jeden Tool-Aufruf und jede Nebenwirkung. Ohne sie ist ein Protokoll ein Haufen Ereignisse, den niemand gruppieren kann. Nutzen Sie Trace- und Span-IDs aus den semantischen Konventionen von OpenTelemetry für generative KI, die gemeinsame Namen für Modellaufrufe, Agentenschritte und Tool-Aufrufe festlegen, damit Traces verschiedener Frameworks gleich lesbar sind. Die Konventionen für Agent-Spans decken das Erstellen und Aufrufen von Agenten ab.
Schritt 2. Anfrage und Absicht in Worten festhalten
Protokollieren Sie, worum der Agent gebeten wurde, von wem und mit welcher Begründung. Protokollieren Sie dann bei jeder folgenreichen Handlung die eigene einzeilige Begründung des Agenten. Ein Grund, der im Moment der Handlung geschrieben wird, ist ein Beleg; ein nachträglich rekonstruierter Grund ist eine Geschichte.
Schritt 3. Modell und Einstellungen festhalten
Für jeden Modellaufruf: Anbieter, Modellname und Version, die Parameter, die die Ausgabe verändern (Temperatur, maximale Tokens, angebotene Tools), und die Token-Zahlen. Ein Verhalten, das Sie keiner Modellversion zuordnen können, lässt sich nicht reproduzieren, nachdem der Anbieter das Modell aktualisiert hat.
Schritt 4. Jeden Tool-Aufruf mit Ein- und Ausgaben festhalten
Nennen Sie das Tool, die Argumente, das Ergebnis und die Zeit. Schwärzen Sie personenbezogene Daten vor dem Speichern, nicht danach; Presidio ist eine offene Möglichkeit. Ein Tool-Aufruf, der irgendwo geschrieben hat, sollte auch festhalten, was er geändert hat: den Diff, die Datensatz-ID, die Nachrichten-ID.
Schritt 5. Jede Richtlinienentscheidung festhalten
Hat eine Policy-Engine einen Aufruf erlaubt oder abgelehnt, protokollieren Sie die Entscheidung und die Regel, die sie traf. Open Policy Agent führt genau dafür Entscheidungsprotokolle. Eine Ablehnung aufzubewahren ist so wichtig wie eine Erlaubnis: Sie zeigt, dass die Grenze gehalten hat.
Schritt 6. Identität und Reichweite festhalten
Protokollieren Sie, welche Zugangsdaten oder welches Token der Lauf verwendet hat und was diese erreichen konnten, nicht ihren geheimen Wert. Die Frage der prüfenden Person lautet oft "hätte es Schlimmeres tun können", und die Antwort ist der Umfang, den er hatte.
Schritt 7. Den Lauf wiederholbar machen
Speichern Sie genug, um die Arbeit erneut auszuführen: Eingaben, den Zustand bei jedem Schritt und die Reihenfolge der Ereignisse. Engines für dauerhafte Ausführung wie Temporal führen eine Ereignishistorie pro Workflow, mit der sich ein Workflow deterministisch wiederholen lässt.
Teil 2. Was signieren
Schritt 8. Das Protokoll nur anhängend und verkettet führen
Ein Datensatz, der sich nachträglich umschreiben lässt, beweist nichts. Schreiben Sie Ereignisse in einen nur anhängenden Speicher und verketten Sie jeden Eintrag per Hash mit dem vorherigen, sodass ein entfernter oder bearbeiteter Eintrag die Kette bricht. Die IETF-Arbeitsgruppe SCITT definiert signierte Aussagen, die in nur anhängenden Transparenzdiensten registriert werden, eine fertige Form dafür.
Schritt 9. Signieren, was der Agent erzeugt hat
Erzeugt ein Lauf ein Artefakt (einen Build, einen Bericht, eine veröffentlichte Datei), hängen Sie eine signierte Aussage darüber an, wie es entstand. Das in-toto Attestation Framework transportiert solche Aussagen, und SLSA definiert Stufen der Build-Provenienz. Für Medien hängt die C2PA-Spezifikation signierte Provenienz-Manifeste an, auch für Inhalte, die mit KI erzeugt oder bearbeitet wurden.
Schritt 10. Die Freigabe signieren
Hat ein Mensch eine Handlung freigegeben, halten Sie fest, wer sie freigab, wann und was genau er gesehen hat. Binden Sie die Freigabe an den Inhalt: Ändert sich die Handlung nach der Freigabe, zählt die Freigabe nicht mehr.
Teil 3. Was der prüfenden Person zeigen
Schritt 11. Die Handlung zeigen, keine Zusammenfassung
Die prüfende Person sollte die E-Mail, den Diff oder den Befehl sehen, der ausgeführt wird, erzeugt aus der eigenen Ausgabe des Laufs. Eine Zusammenfassung, geschrieben vom selben Modell, das die Freigabe will, ist keine Prüffläche.
Schritt 12. Den Grund neben der Handlung zeigen
Stellen Sie die festgehaltene Absicht des Agenten neben die Änderung, die er gemacht hat. "Warum steht diese Zeile hier" sollte der Satz beantworten, der geschrieben wurde, als die Zeile landete.
Schritt 13. Die Grenzen zeigen, unter denen er lief
Zeigen Sie die Richtlinie und den Umfang der Zugangsdaten neben dem Lauf. Wer sieht, dass der Agent nur in einen Branch schreiben konnte, liest den Lauf anders als jemand, der annehmen muss, er habe alles erreichen können.
Schritt 14. Der prüfenden Person einen Stopp geben
Jeder Prüfbildschirm braucht eine Möglichkeit abzulehnen, und die Ablehnung muss halten. Artikel 14 der EU-KI-Verordnung verlangt, wie in Red levers zitiert, dass Menschen, die Hochrisikosysteme beaufsichtigen, "intervene in the operation of the high-risk AI system or interrupt the system" können (in den Betrieb des Hochrisiko-KI-Systems eingreifen oder das System unterbrechen). Das Zitat hier betrifft die Form der Kontrolle, nicht eine Behauptung von Konformität.
Selbst prüfen
Nehmen Sie einen Lauf der letzten Woche und versuchen Sie, allein aus den Aufzeichnungen zu beantworten: wer gefragt hat, was der Agent aufgerufen hat, was er geändert hat, unter welcher Richtlinie, wer freigegeben hat und ob die Aufzeichnung seitdem bearbeitet worden sein könnte. Jede Frage, die Sie nicht beantworten können, entspricht einem Schritt oben.
Wie wir sie anwenden
Wir bauen Werkzeuge für Teile dieser Liste. AEGIS by 100monkeys.ai, in beta, ist ein selbst gehosteter Orchestrator, der Agenten in isolierten Laufzeitumgebungen mit durchgesetzten Richtlinien und dauerhaftem Zustand ausführt; How to give an orchestrator an approval step (auf Englisch) zeigt sein Freigabe-Gate als durchgearbeitetes Beispiel, und diese Installationsanleitung bringt es auf einem Server zum Laufen. Carbon Forge hält Code und Text in einem Datensatz, in dem Blame die beim Landen geschriebene Absicht zeigt.