Wir nutzen bereits ein Tracing-Backend. Ist das Problem damit nicht gelöst?

Ein Backend bietet Ihnen Erfassung und Speicherung. Bei diesem Pattern geht es um drei Dinge, die ein Backend Ihnen nicht abnimmt: ob ein einziger Identifikator den gesamten Run durchzieht, ob die Detailgenauigkeit ausreicht, um ihn ohne die Quellsysteme zu rekonstruieren, und ob die aufgezeichneten Daten sicher aufbewahrt werden können. Teams mit hervorragenden Tools scheitern regelmäßig am Rekonstruktionstest.

Steht eine vollständige Erfassung nicht im Widerspruch zur Datenminimierung?

Das würde es, wenn Erfassung bedeuten würde, alles im Rohzustand aufzubewahren. Die Kontrollmaßnahme formuliert bewusst beide Seiten – genug zur Rekonstruktion, aber nichts, was das Protokoll zur Sicherheitslücke macht. Der Weg, beides zu vereinbaren, ist die Schwärzung auf Feldebene bei der Erfassung in Kombination mit einer Aufbewahrungsfrist, die an die rechtfertigende Verpflichtung gekoppelt ist. Was Sie nicht tun können, ist, diesen Konflikt zu ignorieren, indem Sie einfach alles aufbewahren und es Compliance nennen.

Wie viel Detailgenauigkeit ist ausreichend?

Genau so viel, wie nötig ist, um den Rekonstruktionstest bei einem zufällig ausgewählten Run zu bestehen – nicht mehr. Dieser Schwellenwert lässt sich durch Ausprobieren ermitteln, weshalb der Test in die Routine und nicht erst in ein Audit gehört. Alles, was darüber hinaus erfasst wird, verursacht Kosten und Risiken, ohne eine konkrete Frage zu beantworten.

ZuverlässigkeitAktualisiert 2026-08-25 · Version 1.0

Correlated Run Trace

Ein einziger Identifikator verknüpft einen gesamten Agenten-Run – Inputs, Modell und Version, jeden Tool-Aufruf mit seinen Argumenten und Ergebnissen, die finale Aktion – zu einem Datensatz, den Sie Monate später erneut abspielen können. Der schwierige Teil ist nicht die Erfassung. Es geht darum, vollständig genug zu sein, um den Run zu rekonstruieren, und gleichzeitig so zurückhaltend, dass der Trace-Speicher nicht zu einer zweiten Kopie der beschriebenen Daten wird.

Evidenz: BranchenbeobachtungKonfidenz: MittelQuelle: BranchenbeobachtungQuelle: Paper

Maschinenlesbar: JSON

Definition

Ein Correlated Run Trace ist eine unveränderliche Aufzeichnung mit einem einzigen Identifikator, die alles erfasst, was ein Agenten-Run entschieden und getan hat. Sie wird mit einer Detailgenauigkeit aufgezeichnet, die es ermöglicht, den Run im Nachhinein lückenlos zu rekonstruieren, ohne Zugriff auf die erzeugenden Systeme zu haben, und ist so redigiert, dass der Trace kein leichteres Angriffsziel darstellt als die Quelle. Es handelt sich um eine Aufzeichnung der Entscheidungen des Agenten, nicht um ein Request-Log.

Problem

Agenten sind nicht-deterministisch und arbeiten mehrschrittig, sodass sich das Geschehene nicht einfach aus dem Output ableiten lässt. Die meisten Teams protokollieren zwar, können aber dennoch nicht beantworten, warum ein bestimmter Run so agiert hat: Die Schritte befinden sich in verschiedenen Systemen ohne gemeinsamen Identifikator, der Prompt wurde als Template-Referenz aufgezeichnet, die sich inzwischen geändert hat, oder die Modellversion wurde nie erfasst, sodass niemand sagen kann, ob sich das Verhalten oder das Modell verändert hat.

Wann zu verwenden

Jeder Agent, dessen Aktionen Konsequenzen haben, nach denen später gefragt wird: ein regulierter Prozess, bei dem der Trace der Audit-Trail ist und Nachvollziehbarkeit eine Pflicht statt einer Präferenz darstellt, ein Vorfall, der eine Ursachenanalyse erfordert, ein Kunde, der ein Ergebnis anfechtet, oder eine Evaluierungsschleife, die echte Fehler benötigt, um daraus zu lernen.

Lösung

Erzeugen Sie am Einstiegspunkt einen eindeutigen Run-Identifikator und leiten Sie diesen durch jeden Schritt, Service und Wiederholungsversuch (Retry) weiter. Die Korrelation macht den gesamten Wert aus: Unverknüpfte Datensätze desselben Runs sind lediglich drei Protokolleinträge, kein Trace.

Erfassen Sie den gerenderten Prompt, nicht nur einen Verweis darauf. Eine Template-ID verweist auf den aktuellen Stand des Templates, der sich von dem unterscheiden kann, was das Modell tatsächlich gesehen hat.

Erfassen Sie bei jedem Aufruf das Modell und seine Version. Ohne diese Angaben lassen sich eine Verhaltensänderung und eine Modelländerung im Nachhinein nicht voneinander unterscheiden.

Protokollieren Sie Tool-Aufrufe als Argumente plus Ergebnis, einschließlich Fehlern und Wiederholungsversuchen. Ein Trace, der nur erfolgreiche Aufrufe zeigt, beschreibt einen Run, der so nie stattgefunden hat.

Schwärzen Sie Daten bei der Erfassung, nicht erst beim Lesen. Nutzen Sie Regeln auf Feldebene, die Geheimnisse und personenbezogene Daten verwerfen oder hashen, bevor der Datensatz geschrieben wird. Eine Schwärzung bei der Abfrage belässt den Rohwert weiterhin im Speicher.

Führen Sie das Sampling am Ende (Tail-based Sampling) und nicht am Anfang (Head-based Sampling) durch. Entscheide erst nach Abschluss des Runs, was aufbewahrt wird, damit Fehler, Eskalationen und Anomalien erhalten bleiben und nur routinemäßige Erfolge ausgedünnt werden.

Gestalten Sie den Speicher als Append-only und versehen Sie ihn mit den Zugriffskontrollen des sensibelsten Systems, das er beschreibt – nicht mit den Standardeinstellungen eines Logging-Backends.

Komponenten

Ein am Einstiegspunkt erzeugter Run-Identifikator, der durch jeden Schritt, Service, Wiederholungsversuch und jede asynchrone Fortsetzung weitergeleitet wird.Ein Span pro Schritt mit einem stabilen Schema: Inputs, Modell und Version, Tool-Name, Argumente, Ergebnis, Latenz, Token-Nutzung.Schwärzung auf Feldebene bei der Erfassung mit einer expliziten Liste darüber, was verworfen, was gehasht und was unverändert beibehalten wird.Tail-based Sampling, das im Nachhinein entscheidet, sodass anomale Runs erhalten bleiben und routinemäßige ausgedünnt werden.Append-only-Speicher mit einer Aufbewahrungsfrist, die auf die Verpflichtung zur Protokollierung abgestimmt ist, und Zugriffskontrollen, die denen der Quellsysteme entsprechen.Ein Replay-Pfad, der einen Run allein aus dem Trace rekonstruiert und oft genug genutzt wird, damit etwaige Lücken bekannt sind.

Vorteile

Macht nicht-deterministische Fehler diagnostizierbar: Sie können beantworten, warum dieser spezifische Run so reagiert hat, anstatt den Fehler so lange zu reproduzieren, bis er wieder auftritt.
Macht Nachweispflichten zu einem greifbaren Artefakt statt zu einem bloßen Versprechen. Die Rekonstruktion eines zufällig ausgewählten vergangenen Runs funktioniert entweder oder sie funktioniert nicht.
Speist die Evaluierung mit echten statt mit erfundenen Fehlern – das ist der Unterschied zwischen einem Benchmark und einer Regressions-Testsuite.
Trennt Drift von Deployments. Wenn die Modellversion im Datensatz enthalten ist, wird aus der vagen Aussage „Es ist schlechter geworden“ eine präzise beantwortbare Frage.

Risiken

Der Trace-Speicher als leichtestes Angriffsziel: Er enthält dieselben Daten wie die Systeme, die er beschreibt, meist jedoch mit schwächeren Zugriffskontrollen und längeren Aufbewahrungsfristen.
Erfassungskosten, die mit dem Traffic steigen, bis jemand aus Kostengründen auf Head-based Sampling umstellt und damit unbemerkt genau die Runs verwirft, die erhaltenswert gewesen wären.
Eine Schwärzung, die Daten entfernt, die für die Rekonstruktion benötigt worden wären. Eine Überschwärzung bleibt so lange unbemerkt, bis jemand versucht, einen Run zu replizieren, und scheitert.
Datenvolumen wird mit Abdeckung verwechselt. Terabytes an Spans ohne gemeinsamen Identifikator können dennoch keine einzige Frage zu einem bestimmten Run beantworten.

Wann nicht zu verwenden

Einstufige, deterministische Aufrufe, bei denen Input und Output bereits die gesamte Geschichte erzählen. Diese lassen sich bereits über ein einfaches Request-Log rekonstruieren.
Prototypen ohne Nutzer und ohne Verpflichtungen, bei denen die Kosten für die Trace-Pipeline den Erkenntnisgewinn übersteigen würden.
Fälle, in denen geltende Regeln die Aufbewahrung von Inhalten gänzlich untersagen. In diesem Fall protokolliert der Trace lediglich, dass eine Entscheidung getroffen wurde, sowie deren Metadaten, während der Inhalt außen vor bleibt. Dies ist ein anderes Artefakt, und etwas anderes vorzugeben, schafft genau die Haftungsrisiken, die die Regel eigentlich verhindern sollte.

Technologien

OpenTelemetry GenAI semantic conventionsDistributed tracing backendsTail-based samplingField-level redaction at captureAppend-only / WORM storageStructured logging with a propagated run id

Beispiele

Ein Vorfall, bei dem ein Agent eine E-Mail an den falschen Kunden gesendet hat. Der Run-Identifikator verknüpft den Retrieval-Vorgang, der den falschen Datensatz zurückgegeben hat, den Tool-Aufruf, der ihn verwendet hat, und die gesendete Nachricht. So lässt sich die Ursache auf eine einzige Abfrage zurückführen, statt eine Woche lang Reproduktionsversuche zu starten.
Eine Regulierungsbehörde fragt nach, wie eine Entscheidung vor sechs Monaten zustande kam. Der Replay-Pfad rekonstruiert den Run allein aus dem Trace, einschließlich der an diesem Tag aktiven Modellversion.
Ein Qualitätsabfall nach einem Modell-Upgrade. Da jeder Span die Modellversion enthält, basiert der Vergleich auf zwei Gruppen realer Runs und nicht auf subjektiven Eindrücken.

KPIs

Erfolgsquote der Rekonstruktion: Anteil zufällig ausgewählter vergangener Runs, die sich allein aus dem Trace durchgängig rekonstruieren lassen. Dies ist der eigentliche Test für diese Kontrollmaßnahme und die einzige Kennzahl hier, die sich nicht einfach durch das Erfassen von mehr Daten verbessern lässt.
Vollständigkeit der Korrelation: Anteil der Spans in einem Run, die den Run-Identifikator tragen. Jeder Wert unter 100 % bedeutet, dass ein Schritt unsichtbar ist – und der fehlende Schritt ist selten der uninteressante.
Abflussrate sensibler Felder: Anteil der stichprobenartig geprüften Datensätze, die einen Wert enthalten, den die Schwärzungsregeln hätten entfernen müssen. Der Zielwert ist null; jeder andere Wert bedeutet, dass der Trace-Speicher Haftungsrisiken anhäuft.
Aufbewahrungsquote anomaler Runs: Anteil fehlerhafter oder eskalierter Runs, die nach dem Sampling aufbewahrt werden. Head-based Sampling drückt diesen Wert in Richtung der allgemeinen Sampling-Rate – genau das ist der Fehler, den diese Metrik aufdecken soll.

Beobachtete Fehlermuster

Der Trace, der nichts beweist: Jeder Schritt wird protokolliert, kein Schritt teilt sich einen Identifikator, und die Rekonstruktion eines Runs erfordert das manuelle Korrelieren von Zeitstempeln.
Der per Verweis aufgezeichnete Prompt. Das Template wurde geändert, sodass das Protokoll nun einen Prompt beschreibt, den das Modell nie gesehen hat – was niemand bemerkt, bis eine Rekonstruktion im Widerspruch zum Output steht.
Head-based Sampling, das das Gewöhnliche bewahrt. Der benötigte Run wurde bereits am Einstiegspunkt verworfen, noch bevor absehbar war, dass er von Interesse sein würde.
Das Protokoll als Sicherheitslücke: Unbearbeitete Tool-Argumente übertragen personenbezogene Daten in einen Speicher mit breiterem Zugriff und längerer Aufbewahrungsfrist als die Datenbank, aus der sie stammen.
Fehlende Modellversion. Eine Verhaltensänderung und ein stilles Modell-Update sehen im Datensatz identisch aus, und die Untersuchung scheitert an einer Frage, die der Trace hätte beantworten müssen.

Lessons Learned

Die Korrelation ist das Produkt, die Erfassung nur das Rohmaterial. Teams, die ein Tracing-Backend kaufen, aber auf den Identifikator verzichten, erhalten lediglich Speicherplatz statt Antworten.
Testen Sie die Rekonstruktion, nicht die Pipeline. Wählen Sie einen zufälligen vergangenen Run aus und bauen Sie ihn nach – Lücken befinden sich immer dort, wo niemand eine Instrumentierung vorgenommen hat, und nur der Versuch deckt sie auf.
Schwärzen Sie beim Schreiben. Jede Schwärzung, die auf den Lesezeitpunkt verschoben wird, ist eine Entscheidung, den Rohwert aufzubewahren – und Speicher überdauert die ursprüngliche Absicht.
Führen Sie das Sampling am Ende (Tail-based) durch. Head-based Sampling ist die Entscheidung, interessante Runs zu verwerfen, noch bevor man wissen kann, welche das sein werden.
Erfassen Sie überall die Modellversion. Das kostet nur ein Feld und macht den Unterschied aus, ob man Drift diagnostizieren oder nur darüber spekulieren kann.

FAQs

Wir nutzen bereits ein Tracing-Backend. Ist das Problem damit nicht gelöst?: Ein Backend bietet Ihnen Erfassung und Speicherung. Bei diesem Pattern geht es um drei Dinge, die ein Backend Ihnen nicht abnimmt: ob ein einziger Identifikator den gesamten Run durchzieht, ob die Detailgenauigkeit ausreicht, um ihn ohne die Quellsysteme zu rekonstruieren, und ob die aufgezeichneten Daten sicher aufbewahrt werden können. Teams mit hervorragenden Tools scheitern regelmäßig am Rekonstruktionstest.
Steht eine vollständige Erfassung nicht im Widerspruch zur Datenminimierung?: Das würde es, wenn Erfassung bedeuten würde, alles im Rohzustand aufzubewahren. Die Kontrollmaßnahme formuliert bewusst beide Seiten – genug zur Rekonstruktion, aber nichts, was das Protokoll zur Sicherheitslücke macht. Der Weg, beides zu vereinbaren, ist die Schwärzung auf Feldebene bei der Erfassung in Kombination mit einer Aufbewahrungsfrist, die an die rechtfertigende Verpflichtung gekoppelt ist. Was Sie nicht tun können, ist, diesen Konflikt zu ignorieren, indem Sie einfach alles aufbewahren und es Compliance nennen.
Wie viel Detailgenauigkeit ist ausreichend?: Genau so viel, wie nötig ist, um den Rekonstruktionstest bei einem zufällig ausgewählten Run zu bestehen – nicht mehr. Dieser Schwellenwert lässt sich durch Ausprobieren ermitteln, weshalb der Test in die Routine und nicht erst in ein Audit gehört. Alles, was darüber hinaus erfasst wird, verursacht Kosten und Risiken, ohne eine konkrete Frage zu beantworten.