Was ein Agent getan hat, muss rekonstruierbar bleiben

Ein Agent ist nicht deshalb kontrollierbar, weil er am Ende einen überzeugenden Bericht schreibt. Kontrollierbar wird er, wenn sein tatsächlicher Weg durch Quellen, Entscheidungen, Werkzeuge und Zustandsänderungen überprüfbar bleibt.

Am Ende einer langen agentischen Sitzung steht oft eine beruhigende Zusammenfassung: Recherche abgeschlossen, Dateien aktualisiert, Tests bestanden, nächste Schritte vorbereitet. Solche Statusberichte sind hilfreich. Sie sind aber Selbstauskünfte des Systems. Wenn eine Datei fehlt, eine Quelle falsch interpretiert oder ein Tool mit unerwarteter Nebenwirkung ausgeführt wurde, kann derselbe Agent dennoch eine glatte Erfolgsgeschichte formulieren.

Verantwortbare Agentenarbeit braucht deshalb mehr als Erinnerung und Abschlussprosa. Sie braucht eine rekonstruierbare Spur: Was war der Ausgangszustand? Welcher Auftrag galt? Welche Quellen wurden tatsächlich gelesen? Welches Tool erhielt welche Parameter? Was änderte sich? Welche Prüfung lief? Wer bestätigte den nächsten Schritt? Nur wenn diese Fragen später beantwortet werden können, wird aus einem Chatverlauf ein steuerbarer Prozess.

Status ist eine Momentaufnahme, kein Beweis

Eine Projekttabelle mit offenen, erledigten und blockierten Aufgaben kann lange Sitzungen stabilisieren. Sie verdichtet den gültigen Zustand und erleichtert Übergaben. Doch sie zeigt meist nur, was das System über den Zustand behauptet. Sie erklärt nicht automatisch, wie dieser Zustand entstanden ist.

Ein Task kann als erledigt markiert sein, obwohl nur ein Entwurf existiert. Eine Quelle kann als geprüft gelten, obwohl lediglich eine Zusammenfassung gelesen wurde. Ein Test kann „bestanden" heißen, obwohl er mit alten Daten lief. Der Status bleibt wertvoll, muss aber mit Ereignissen und Artefakten verbunden werden.

Die stärkere Formulierung lautet daher nicht „Aufgabe 17 ist fertig", sondern: „Artefakt Version 4 wurde aus den Quellen A und B erzeugt, Testset C lief gegen Commit D, zwei Prüfkriterien bestanden, eines wurde mit dokumentierter Ausnahme akzeptiert, Freigabe erteilte Rolle E." Damit wird der Status verifizierbar.

Observability, Audit Trail und Provenienz lösen verschiedene Fragen

Observability macht sichtbar, was während der Laufzeit geschieht. Traces zeigen zusammenhängende Vorgänge, Logs einzelne Ereignisse, Metriken aggregierte Größen wie Latenz, Fehlerquote oder Verbrauch. Audit Trails konzentrieren sich auf kontrollrelevante Handlungen: Freigaben, Zugriffe, Änderungen, Veröffentlichungen und Ausnahmen. Provenienz erklärt Entstehung und Ableitung: Aus welchen Eingaben, Aktivitäten und verantwortlichen Instanzen ging ein Ergebnis hervor?

Diese Ebenen ergänzen sich. Ein Trace kann zeigen, dass ein Agent eine Suchabfrage, drei Toolaufrufe und eine Dateischreibung ausführte. Der Audit Trail hält fest, dass die Schreibung autorisiert war. Die Provenienz verbindet die neue Datei mit den gelesenen Quellen und der Transformation.

Nicht jedes Debug-Detail gehört dauerhaft in den Audit Trail. Nicht jedes Audit-Ereignis braucht vollständigen Promptinhalt. Eine saubere Architektur trennt die Signale, definiert gemeinsame Identifikatoren und erlaubt dennoch Korrelation.

Ein agentischer Trace braucht mehr als einen Modellnamen

Ein nützlicher Trace beginnt mit einer stabilen Run-ID und zerlegt die Arbeit in Spans. Ein Span kann Planung, Retrieval, Toolausführung, Evaluation oder menschliche Freigabe repräsentieren. Parent-Child-Beziehungen zeigen, welcher Schritt welchen Unterprozess ausgelöst hat.

Zu einem Ereignis gehören mindestens Zeitpunkt, Akteur, Aufgabe, Operation, Inputreferenzen, Outputreferenzen, Status, Dauer und Fehler. Bei Toolaufrufen kommen Toolversion, validierte Parameter, Berechtigungsentscheidung und Nebenwirkung hinzu. Bei Retrieval sind Query, Datenquellen-ID, ausgewählte Dokumente und relevante Versionen wichtig. Bei Evaluation werden Metrik, Testversion, Ergebnis und Begründung festgehalten.

OpenTelemetry entwickelt für generative KI gemeinsame semantische Attribute. Solche Konventionen lösen nicht jedes Governance-Problem, schaffen aber eine gemeinsame Sprache über Bibliotheken und Plattformen hinweg. Eigene Felder sollten dieselbe Disziplin besitzen: klare Bedeutung, stabiler Datentyp, dokumentierter Geltungsbereich und Versionierung.

Behauptung, Ereignis und Artefakt müssen getrennt werden

Agenten formulieren häufig Sätze wie „Ich habe die Datei validiert". Dieser Satz ist eine Behauptung. Das Validierungsereignis ist die tatsächlich ausgeführte Operation. Das Prüfprotokoll ist das resultierende Artefakt. Erst die Verbindung aller drei Elemente erzeugt belastbare Nachvollziehbarkeit.

Die Trennung verhindert, dass Sprache technische Realität ersetzt. Ein Modell kann „gespeichert" schreiben, obwohl der Schreibvorgang fehlschlug. Das System darf den Status erst aktualisieren, wenn der Host den neuen Zustand beobachtet und ein Artefakt oder Event bestätigt.

Für wichtige Aussagen gilt dasselbe. Eine Empfehlung verweist auf Evidenzkarten. Jede Evidenzkarte enthält Quelle, Ausschnitt oder Datensatzreferenz, Zeitpunkt, Geltungsbereich und Prüfergebnis. Der Artikel oder Bericht referenziert die Karten, nicht bloß eine unsichtbare Erinnerung des Modells.

Zustandsänderungen brauchen Vorher und Nachher

Ein lesender Agent hinterlässt andere Risiken als ein schreibender. Sobald Dateien, Datenbankeinträge, Berechtigungen oder externe Systeme verändert werden, muss der Audit Trail die Mutation erfassen. Dazu gehören Zielobjekt, alter Zustand oder Version, beabsichtigte Änderung, tatsächliches Ergebnis und Rücknahmeweg.

Bei großen oder sensiblen Objekten muss nicht der gesamte Inhalt dupliziert werden. Version, Hash, Diff, Speicherort und geschützte Metadaten können genügen. Entscheidend ist, dass später festgestellt werden kann, welche Änderung mit welcher Autorität geschah.

Reversible Schritte werden anders behandelt als irreversible. Ein Entwurf kann in einem isolierten Ordner erzeugt werden. Eine Veröffentlichung, Löschung oder Transaktion benötigt einen Checkpoint. Das Freigabeereignis wird mit Scope und Ablaufzeit verknüpft; eine Bestätigung für Objekt A darf nicht stillschweigend Objekt B autorisieren.

Kosten und Zeit sind Teil des Verhaltens

Agentenqualität wird häufig nur am Endergebnis gemessen. Ein System kann jedoch dasselbe Ergebnis mit zehn oder zehntausend Aufrufen erzeugen. Unbegrenzte Schleifen, wiederholtes Retrieval und erfolglose Tool-Retries sind operative Fehler, selbst wenn am Ende ein brauchbarer Text entsteht.

Deshalb erfasst Observability auch Latenz, Modell- und Toolaufrufe, Input- und Outputmengen, Cache-Nutzung, Retry-Zahl und geschätzte Kosten. Diese Werte werden pro Schritt, Aufgabe und Gesamt-Run betrachtet. Budgets sind nicht nur Berichtsfelder, sondern Steuergrenzen. Überschreitet ein Run ein Zeit-, Kosten- oder Schrittlimit, pausiert oder eskaliert er.

Aggregierte Metriken zeigen Muster: Welche Rolle verursacht Wiederholungen? Wo entstehen lange Wartezeiten? Welches Tool liefert die meisten Fehler? Einzelne Traces erklären anschließend konkrete Ausreißer.

Fehler müssen ihre Ursache behalten

Ein Agent, der nach einem Fehler erfolgreich neu plant, ist wertvoll. Doch die erfolgreiche Wiederholung darf den ersten Fehler nicht aus der Historie löschen. Sonst verschwindet genau das Lernmaterial, das für Verbesserung und Risikobewertung benötigt wird.

Ein Fehlerereignis hält Kategorie, betroffenen Schritt, Eingabe, Toolantwort, sichtbare Nebenwirkung und gewählte Reaktion fest. Es unterscheidet Timeout, Berechtigungsverweigerung, Schemafehler, leeres Retrieval, widersprüchliche Evidenz und fachliche Unsicherheit. „Es gab ein Problem" ist nicht diagnostizierbar.

Retries werden mit dem ursprünglichen Fehler verknüpft. Wenn ein Agent seine Strategie ändert, wird die Entscheidung begründet. Wiederholt sich derselbe Fehler, kann eine Circuit-Breaker-Regel den Run stoppen. So verhindert das System, dass autonome Beharrlichkeit zum Schaden wird.

Vollständiges Logging kann selbst zum Risiko werden

Prompts, Toolparameter und Antworten können personenbezogene Daten, Geschäftsgeheimnisse, Zugangsdaten oder vertrauliche Dokumentinhalte enthalten. Blindes Mitschreiben schafft eine zweite sensible Datenbank und vergrößert die Angriffsfläche.

Logging folgt deshalb Datenminimierung. Standardmäßig werden Referenzen, Kategorien, Hashes und notwendige Metadaten gespeichert. Vollinhalte werden nur erfasst, wenn der Zweck sie verlangt, die Rechtsgrundlage geklärt und der Zugriff streng begrenzt ist. Geheimnisse werden gefiltert, sensible Felder maskiert und Mandanten getrennt.

Aufbewahrung ist abgestuft. Kurzlebige Debugdaten können nach Tagen verschwinden, während kontrollrelevante Freigaben länger benötigt werden. Löschregeln, Zugriffsauskunft und Zweckbindung müssen auch für Observability-Daten gelten. Ein Audit Trail ist keine Lizenz zur unbegrenzten Sammlung.

Manipulationsschutz und Zurechenbarkeit

Ein Audit Trail verliert seinen Wert, wenn der handelnde Agent ihn nachträglich umschreiben kann. Kritische Ereignisse werden deshalb append-only gespeichert oder über Hashketten, signierte Einträge und versionierte, schreibgeschützte Speicher abgesichert. Der Agent darf Ereignisse vorschlagen, aber die Laufzeit erzeugt die autoritative Aufzeichnung.

Zurechenbarkeit erfordert stabile Identitäten für Agent, Modellkonfiguration, Skill, Tool und menschliche Rolle. „Das Modell" ist zu ungenau. Relevant sind Version, Konfiguration, Berechtigungskontext und ausgeführter Code. Bei Multi-Agent-Systemen trägt jede Nachricht Sender, Empfänger, Task-ID und Vertrauensstatus.

Manipulationsschutz bedeutet nicht, dass jeder Logeintrag Wahrheit enthält. Er beweist zunächst nur, dass eine bestimmte Aufzeichnung seit ihrem Eintrag nicht verändert wurde. Plausibilitätsprüfung und unabhängige Evidenz bleiben notwendig.

Dashboards sind Einstieg, nicht Kontrolle

Ein Dashboard kann Status, Fehler, Kosten und offene Freigaben übersichtlich darstellen. Es darf aber nicht nur grüne Ampeln zeigen. Nutzer müssen von einer Kennzahl zum Trace, vom Trace zum Ereignis und vom Ereignis zum Artefakt oder zur Quelle navigieren können.

Gute Übersichten zeigen auch Unsicherheit und fehlende Telemetrie. Ein nicht instrumentierter Toolaufruf ist kein erfolgreicher Toolaufruf. Eine Lücke im Trace wird sichtbar markiert. Bei kritischen Prozessen kann unvollständige Beobachtbarkeit selbst ein Blocker sein.

Der Mensch braucht entscheidungsfähige Sichten: Was änderte sich? Welche Evidenz fehlt? Welche Ausnahme wurde genutzt? Was kostet die Fortsetzung? Wie kann zurückgerollt werden? Rohlogs bleiben für Diagnose verfügbar, werden aber nicht als Benutzeroberfläche missverstanden.

Evaluation verbindet Spuren mit Qualität

Observability sagt, was geschah; Evaluation beurteilt, ob es gut genug war. Beide müssen verbunden sein. Ein Testresultat verweist auf Run, Artefaktversion, Datensatz und Kriterien. Fehler aus dem Betrieb werden zu neuen Evaluationsfällen. Eine neue Agentenversion wird gegen gespeicherte Traces oder reproduzierbare Szenarien geprüft.

NIST betont risikobasierte Messung und Behandlung über den Lebenszyklus. Für Agenten bedeutet das: Nicht nur Modellantworten, sondern komplette Trajektorien werden evaluiert. Hat der Agent die richtige Quelle gewählt? Berechtigungen eingehalten? Unnötige Schritte vermieden? Unsicherheit erkannt? Sicher gestoppt?

Damit wird Beobachtbarkeit zur Lerninfrastruktur. Sie liefert keine automatische Wahrheit, aber die Belege, aus denen Teams Fehler erkennen, Kontrollen verbessern und Regressionen verhindern können.

Übungsblatt: Baue einen rekonstruierbaren Agenten-Run

Wähle einen Workflow mit mindestens einem Retrieval-, Tool- und Prüfschritt.

1. Definiere Run-ID, Task-ID, Agentenidentität und Artefaktversionen.

2. Zeichne Trace und Spans von Auftrag bis Übergabe.

3. Lege Events für Retrieval, Toolaufruf, Mutation, Fehler, Retry, Evaluation und Freigabe fest.

4. Verbinde jede wichtige Behauptung mit einer Evidenzreferenz.

5. Erfasse Vorher/Nachher, Diff oder Hash für jede Zustandsänderung.

6. Definiere Metriken und Budgets für Schritte, Zeit, Kosten und Fehler.

7. Markiere sensible Felder, Maskierung, Zugriff und Aufbewahrungsfrist.

8. Simuliere Toolfehler und Logmanipulation; prüfe Stop, Eskalation und Rekonstruktion.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Observability, Audit Trail und Provenienz überschneiden sich, sind aber nicht identisch. Telemetrie macht Laufzeitverhalten sichtbar; ein Audit Trail hält kontrollrelevante Ereignisse unveränderbar und zurechenbar fest; Provenienz beschreibt, wie Artefakte und Aussagen entstanden sind. Vollständiges Logging ist weder automatisch sinnvoll noch datenschutzkonform. Inhalt, Detailgrad, Zugriff und Aufbewahrung müssen aus Zweck und Risiko abgeleitet werden.