LLM-Observability und ein Audit-Trail für KI-Agenten können dieselbe Trace-ID tragen und trotzdem unterschiedliche Fragen beantworten. Ein Observability-Trace zeichnet auf, wie ein Modellaufruf oder ein Agentenschritt ablief: die Operation, das Modell, die Token-Zahlen, die Latenz, Fehler und, wenn die Inhaltserfassung eingeschaltet ist, die Nachrichten. Ein prüffähiger Trail zeichnet auf, warum eine Aktion zugelassen wurde, wer die Befugnis darüber hatte, welche Richtlinienversion entschieden hat, was das Tool verändert hat und wie jeder den Datensatz später verifizieren kann. Bei einem Hochrisiko-System nach dem EU AI Act trägt der Audit-Trail die Rückverfolgbarkeit, die Artikel 12 verlangt, und der Trace hilft den Engineers, das System zu betreiben.
Dieser Leitfaden vergleicht beide Feld für Feld, zeichnet eine synthetische Aktion auf beide Arten auf, legt dar, was der EU AI Act von Protokollen verlangt, und listet auf, was ein Observability-Stack zusätzlich braucht. Das Audit-Framework für KI-Agenten in Unternehmen ordnet den Datensatz in die vollständige Prüfmethode ein, und sein ausgefülltes Audit-Arbeitspapier prüft eine Aktion von der Berechtigung bis zum Ergebnis.
Was LLM-Observability aufzeichnet
Viele LLM-Observability-Tools erzeugen oder übernehmen OpenTelemetry-Daten. Die OpenTelemetry-Semantikkonventionen für generative KI definieren Spans für Inferenz, Embeddings, Retrieval, Speicher und Tool-Ausführung, mit Attributen wie gen_ai.operation.name, gen_ai.provider.name, gen_ai.request.model, gen_ai.usage.input_tokens und gen_ai.tool.name. Die Konventionen haben den Status Development, Namen können sich also noch ändern.
Inhalte sind in diesen Konventionen Opt-In. Modelleingabe und -ausgabe (gen_ai.input.messages, gen_ai.output.messages), Tool-Argumente und -Ergebnisse (gen_ai.tool.call.arguments, gen_ai.tool.call.result) sowie abgerufene Dokumente (gen_ai.retrieval.documents) werden nur aufgezeichnet, wenn jemand sie aktiviert. Ein Trace mit Standardeinstellungen kann zeigen, dass ein Tool lief und wie lange es dauerte, ohne festzuhalten, wozu es aufgefordert wurde oder was es zurückgab.
Für das Engineering sind diese Daten gut geeignet: einen fehlgeschlagenen Schritt, ein langsames Retrieval oder einen teuren Prompt finden und Prompt-Versionen vergleichen. Die Nutzung im Engineering erklärt auch die üblichen Speicherentscheidungen: Sampling zur Begrenzung des Volumens, Aufbewahrung nach Speicherkosten und Speicher, die Betreiber bearbeiten oder leeren können.
Die Lücke zwischen den beiden Datensätzen haben wir in unserem eigenen Produkt erlebt. In einem Proof of Concept zum Händler-Onboarding im September verlinkte die Fallhistorie jeden Schritt mit dem Lineage Explorer, und die Links zeigten „Trace not found“ für einen Run, der an einer Freigabe pausierte. Der Run veröffentlichte seine Trace-Spans erst bei Abschluss, während der Gate-Beleg für die ausstehende Entscheidung bereits existierte. Wir haben den Lineage Explorer so geändert, dass er die bis dahin aufgezeichneten Schritte des Runs aus dem Ausführungsdatensatz liest, wenn noch kein Trace veröffentlicht ist, und anzeigt, dass der Run noch nicht beendet ist.
Was ein prüffähiger Trail ergänzt
Ein Prüfer, eine Aufsichtsbehörde oder eine Rechtsabteilung, die eine einzelne Agentenaktion prüft, stellt Fragen, für die ein Trace nicht gebaut wurde. Die Tabelle ordnet jeder Frage ein typisches Observability-Feld zu und das Feld, das sie im herstellerneutralen Audit-Log-Schema für KI-Agenten beantwortet.
| Frage des Prüfers | Typisches Observability-Feld | Audit-Trail-Feld (audit event v1) | Lücke im Trace |
|---|---|---|---|
| Für wen hat der Agent gehandelt, und wer verantwortet das Ergebnis? | gen_ai.agent.name, gen_ai.conversation.id, Dienstname | actors.requester, actors.delegated_user, actors.service_identity, actors.accountable_owner | Der Trace nennt den Agentenprozess und selten die delegierende Person oder den verantwortlichen Eigentümer |
| Welches Release lief? | gen_ai.request.model, gen_ai.response.model | components.agent.version, components.model.version, components.prompt_template.version, jeweils mit configuration_digest | Ein Modellname allein führt nicht zu einem freigegebenen Release von Agent, Prompt und Orchestrator |
| Welche Richtlinie hat entschieden, und wurde sie vor der Aktion geprüft? | Kein GenAI-Span für Richtlinienentscheidungen | policy.policy_id, policy.policy_version, policy.policy_digest, policy.inputs_digest, policy.decision, policy.matched_rule_ids, policy.evaluated_at | Richtlinienprüfungen erscheinen, wenn überhaupt, als eigene Spans ohne festgelegte Bedeutung |
| Hat eine befugte Person freigegeben? | Kein GenAI-Span für Freigaben | approval.required_role, approval.reviewer, approval.decision, approval.decided_at, approval.presented_evidence_digest | Der Trace kann nicht zeigen, was der Prüfer gesehen hat oder ob er die Rolle innehatte |
| Was hat das Tool verändert? | gen_ai.tool.name, gen_ai.tool.call.id; Argumente und Ergebnis bei Opt-In | tool_calls[].arguments_digest, result_digest, idempotency_key, downstream_effects[].before_state_digest, after_state_digest | Keine Verbindung vom Aufruf zur Zustandsänderung im führenden System |
| Ist jede Aktion in der Grundgesamtheit enthalten? | Gesampelte Traces | sequence, lineage.ordered_event_ids, Abgleich mit dem Ursprungssystem | Sampling verwirft Datensätze planmäßig |
| Hat sich der Datensatz seit dem Schreiben verändert? | Keines | integrity.record_hash, integrity.previous_event_hash, integrity.signature | Trace-Speicher sind meist bearbeitbar und laufen nach einem Speicherplan ab |
Eine synthetische Aktion, auf beide Arten aufgezeichnet
Der Kreditagent einer fiktiven Bank erfasst eine Kreditentscheidung über 24.000 EUR. Der Observability-Trace für den Tool-Schritt sieht so aus. Die Werte sind synthetisch.
{
"name": "execute_tool set_disposition",
"trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
"span_id": "00f067aa0ba902b7",
"start_time": "2026-07-21T09:14:31.944Z",
"end_time": "2026-07-21T09:14:32.433Z",
"attributes": {
"gen_ai.operation.name": "execute_tool",
"gen_ai.tool.name": "set_disposition",
"gen_ai.tool.call.id": "call_01JZ8V4R1E7P3M9C5Q2T6N8D0A",
"gen_ai.agent.name": "Credit review agent"
},
"status": "OK"
}Das Audit-Ereignis für dieselbe Aktion
Das Audit-Ereignis für denselben Aufruf ist der öffentliche synthetische vollständige Ausführungsdatensatz. Er trägt dieselbe trace_id und span_id, sodass sich beide Datensätze verknüpfen lassen. Er ergänzt, was dem Span fehlt: den delegierenden Nutzer und den verantwortlichen Eigentümer, die Richtlinie credit-disposition-policy 4.2.1, die unter der Regel manual-review-above-20000 require_approval zurückgibt, die Freigabe des Senior Underwriters um 09:14:31.902Z vor dem Aufruf um 09:14:31.944Z, die Digests von Argumenten und Ergebnis, die Zustands-Digests vorher und nachher im Kernbankensystem, das Geschäftsergebnis sowie einen Datensatz-Hash mit einer Ed25519-Signatur.
Ein Prüfer kann die Signatur verifizieren, prüfen, dass die Freigabe vor dem Aufruf lag, die Richtlinie über die aufgezeichneten Eingaben erneut ausführen und die Effektreferenz bis ins Kernbankensystem verfolgen. Mit dem Span allein kann der Prüfer bestätigen, dass ein Tool namens set_disposition ohne Fehler zurückkehrte.
Was der EU AI Act von Protokollen verlangt
Artikel 12 Absatz 1 des EU AI Act verlangt, dass Hochrisiko-KI-Systeme technisch die automatische Aufzeichnung von Ereignissen über ihre gesamte Lebensdauer ermöglichen. Artikel 12 Absatz 2 bindet diese Protokollierung an die Ermittlung von Situationen, die ein Risiko oder eine wesentliche Änderung bewirken können, an die Beobachtung nach dem Inverkehrbringen und an die Überwachung des Betriebs durch den Betreiber. Artikel 12 Absatz 3 legt Mindestfelder nur für Systeme zur biometrischen Fernidentifizierung fest.
Artikel 19 Absatz 1 verpflichtet Anbieter, automatisch erzeugte Protokolle, soweit sie ihrer Kontrolle unterliegen, mindestens sechs Monate aufzubewahren, sofern das Unionsrecht oder nationale Recht nichts anderes vorsieht. Artikel 26 Absatz 6 legt dasselbe Minimum für Betreiber fest. Korrekturmaßnahmen regelt Artikel 20, das Qualitätsmanagement einschließlich der Verfahren zur Aufzeichnung Artikel 17.
Für die meisten Hochrisiko-Systeme überlässt die Verordnung die Feldliste dem Anbieter. Bei einem Agenten bedeutet Rückverfolgbarkeit einer Entscheidung meist die Felder zu Akteur, Release, Richtlinie, Freigabe, Tool-Effekt und Ergebnis aus der Tabelle oben. Die am 24. Juli 2026 veröffentlichte Verordnung (EU) 2026/1744 hat den Geltungsbeginn für Hochrisiko-Systeme nach Artikel 6 Absatz 2 und Anhang III auf den 2. Dezember 2027 und für Systeme nach Artikel 6 Absatz 1 und Anhang I auf den 2. August 2028 verschoben. Der Leitfaden zur Protokollierung nach Artikel 12 behandelt die Pflicht im Detail.
Die vier Ebenen eines Evidence Packs
Ein Evidence Pack bündelt den Audit-Trail für eine Entscheidung oder einen Zeitraum, sodass ein Prüfer ihn außerhalb des erzeugenden Systems prüfen kann. Das Beispiel für den Evidence Room zeigt einen Export.
- Entscheidungsdatensatz: Kennung, Zeitpunkt, Entscheidungstyp, Ergebnis und Risikoeinstufung. Jedes andere Artefakt verweist darauf.
- Eingabekontext: was der Agent gelesen hat, mit Quellenverweisen und Versionen; die geltenden Versionen von Modell, Prompt und Richtlinie. Wie Sie nachweisen, was ein KI-Agent gelesen hat beschreibt den Lesedatensatz.
- Governance-Nachweise: Richtlinienentscheidungen mit getroffenen Regeln, Decision Requests mit Prüfer und Begründung, Eskalationen und Übersteuerungen.
- Integrität: ein Manifest der Artefakte mit SHA-256-Digests, Signaturen, Zeitstempelankern und Beweiskette, sodass ein Prüfer das Pack offline verifizieren kann.
Architekturmuster für prüffähige Datensätze
Diese Muster liegen auf dem Aktionspfad. Sie setzen voraus, dass der Agent Tools über einen Kontrollpunkt aufruft, der die Richtlinie auswerten und das Ergebnis aufzeichnen kann.
Ein Feld, das beim Versiegeln eines Datensatzes fehlt, lässt sich später nicht ergänzen. Anfang September 2026 ergab eine Code-Analyse unserer eigenen Plattform, dass einige plattforminterne Entscheidungsdatensätze und versiegelte Belege den handelnden Agenten nicht nannten. Versiegelte Belege lassen sich nicht nachträglich befüllen, sodass jeder Tag ohne das Feld weitere Datensätze erzeugte, die ein Prüfer keinem Agenten zuordnen konnte. Wir haben die Agentenidentität innerhalb von zwei Tagen in Entscheidungsdatensätze und versiegelte Gate-Belege aufgenommen. Legen Sie die Feldliste vor dem ersten Produktionsdatensatz fest.
- Zum Entscheidungszeitpunkt schreiben: die Richtlinienentscheidung aufzeichnen, bevor die Aktion fortgesetzt wird, und die Freigabe vor dem Tool-Aufruf. Ein nachträglich aus Protokollen zusammengesetzter Datensatz kann die Reihenfolge nicht verlässlich zeigen.
- Append-only-Speicher: Ereignisse dort speichern, wo bestehende Einträge weder bearbeitet noch gelöscht werden können, und jeden Datensatz per Hash mit dem vorherigen verketten.
- Signieren und versiegeln: jeden Datensatz signieren und Exporte mit einem Manifest und einer Signatur versiegeln, die ein Prüfer mit veröffentlichten Schlüsseln prüfen kann.
- Inhalte auflösbar halten: ein Digest beweist eine Übereinstimmung nur, wenn der Inhalt später vorgelegt werden kann. Bewahren Sie die Quellversion oder eine geschützte Kopie für die Aufbewahrungsfrist auf.
- Aufzeichnen, was das Replay braucht: Entscheidungseingaben, die fixierte Richtlinienversion und die aufgezeichnete Modellausgabe. Deterministisches Replay für Entscheidungen von KI-Agenten listet den vollständigen Satz und seine Grenzen auf.
- Mit Telemetrie verknüpfen:
trace_idundspan_idim Audit-Ereignis mitführen, damit Engineers und Prüfer zwischen beiden Datensätzen wechseln können.
Die Nachweisebene auf einem Observability-Stack aufbauen
Teams mit bestehendem Tracing können die Nachweisebene in Phasen ergänzen.
- Phase 1, die Fragen festlegen: die Entscheidungstypen mit Audit- oder Rechtsrisiko auflisten und die Fragen, die ein Prüfer zu jedem stellen wird.
- Phase 2, Kontrollpunkte setzen: folgenreiche Tool-Aufrufe über einen Richtlinien-Kontrollpunkt leiten, der die Felder zu Akteur, Release, Richtlinie, Freigabe und Effekt aufzeichnet.
- Phase 3, Integrität schützen: Audit-Ereignisse in Append-only-Speicher mit Hashing, Signaturen und versiegelten Exporten verlagern.
- Phase 4, den Datensatz testen: Aktionen als Stichprobe ziehen, Signaturen verifizieren, die Grundgesamtheit abgleichen und Entscheidungen nachspielen. Die Audit-Checkliste für KI-Agenten und das Audit-Arbeitspapier liefern die Tests.
Häufig gestellte Fragen
Können LLM-Observability-Tools als Audit-Trail nach dem EU AI Act dienen?
Observability-Traces decken einen Teil davon ab. In den OpenTelemetry-GenAI-Konventionen sind Inhalte Opt-In, und es gibt keine Spans für Richtlinienentscheidungen oder Freigaben. Ein Audit-Trail nach dem EU AI Act braucht für einen Agenten außerdem die delegierende Person, Version und Ergebnis der Richtlinie, die Freigabe, den Effekt des Tools auf das führende System, die Vollständigkeit der Grundgesamtheit und Manipulationsnachweise. Verknüpfen Sie den Trace mit einem Audit-Ereignis, das diese Felder trägt.
Wie erstelle ich Audit-Trails für Aktionen von KI-Agenten?
Vergeben Sie eine Ausführungskennung und zeichnen Sie die Identitäten von Agent und Mensch, Release-Versionen, das vom Agenten Gelesene, Tool-Aufrufe und Ergebnisse, Richtlinienentscheidungen, Freigaben, Ausgaben, Nebenwirkungen und Zeitstempel auf. Schreiben Sie die Datensätze zum Entscheidungszeitpunkt in Append-only-Speicher und versiegeln Sie Exporte mit einem Manifest und Signaturen.
Wie prüfe ich Entscheidungen von KI-Agenten und spiele sie nach?
Wählen Sie eine Ausführung aus einer abgeglichenen Grundgesamtheit, verifizieren Sie ihre Integrität, lösen Sie die aufgezeichnete Richtlinienversion auf und führen Sie die Richtlinie ohne Tool-Zugriff erneut über die aufgezeichneten Eingaben aus. Vergleichen Sie Ergebnis und getroffene Regeln mit dem Datensatz. Prüfen Sie den externen Effekt des Tools gesondert im nachgelagerten System, denn eine nachgespielte Entscheidung beweist ihn nicht.
Was ist ein Evidence Pack?
Ein Evidence Pack bündelt Entscheidungsdatensatz, Eingabekontext, Governance-Nachweise und Integritätsmaterial für eine Entscheidung oder einen Zeitraum, sodass ein Prüfer es außerhalb des erzeugenden Systems verifizieren kann.
Welche Artikel des EU AI Act betreffen Protokolle?
Artikel 12 verlangt eine automatische Ereignisprotokollierung für Hochrisiko-Systeme. Artikel 19 Absatz 1 und Artikel 26 Absatz 6 verpflichten Anbieter und Betreiber, die Protokolle, soweit sie ihrer Kontrolle unterliegen, mindestens sechs Monate aufzubewahren, sofern anderes Recht nichts anderes vorsieht. Artikel 17 regelt das Qualitätsmanagement einschließlich der Aufzeichnung.
Was ist Append-only-Speicher und warum ist er wichtig?
Append-only-Speicher nimmt neue Datensätze an und verweigert das Bearbeiten und Löschen bestehender. Zusammen mit Hash-Verkettung und Signaturen kann ein Prüfer jede nachträgliche Änderung am Trail erkennen.
Die wichtigsten Erkenntnisse
Nutzen Sie Observability weiter für den Betrieb des Systems, und ergänzen Sie auf dem Aktionspfad ein Audit-Ereignis, das belegt, wie eine Entscheidung gesteuert wurde. Verknüpfen Sie beide über die Trace-ID. Zeichnen Sie für jede folgenreiche Aktion auf, was der Agent gelesen hat, die Richtlinienversion, die Freigabe, den Effekt und einen Integritätsnachweis. Nutzen Sie die Audit-Checkliste für KI-Agenten, um diese Datensätze zu testen, die Bereitschaftsbewertung, um Lücken zu finden, und Execution Lineage, um zu sehen, wie KLA die Datensätze eines Runs verknüpft.