Um nachzuweisen, was ein KI-Agent gelesen hat, bevor er gehandelt hat, erfassen Sie jeden Lesezugriff als eigenes Ereignis und verknüpfen jede Tatsache in der Entscheidung mit einem dieser Ereignisse. Ein Lese-Ereignis nennt das Quellsystem, das Tool oder den Abruf, der es erzeugt hat, einen Digest der Anfrage und des Ergebnisses, die Version des Quelldatensatzes, den Zeitpunkt und die Datengrenze. Eine Feld-Provenienz-Zuordnung gibt dann für jeden Wert, den der Agent verwendet hat, an, ob er aus einem Tool-Ergebnis, einem Dokument oder dem Modell stammt. Mit beidem kann eine Prüferin eine Entscheidung nehmen und jede Eingabe auf einen Quelldatensatz zurückführen, der zu diesem Zeitpunkt existierte.
Dieser Beitrag behandelt die vier Arten, wie ein Agent liest, eine Datensatzform für jede, ein synthetisches KYC-Beispiel, die Wahl zwischen Aufbewahrung des Inhalts und Aufbewahrung eines Digests sowie das, was KLA heute aufzeichnet. Der Leitfaden zu Audit-Trails für KI-Agenten behandelt den umfassenderen Ausführungsdatensatz. Deterministisches Replay baut auf denselben Lese-Datensätzen auf.
Warum Prüfer fragen, woher die Informationen stammen
Ein Agent, der eine Kundenakte prüft, ein Kreditmemo entwirft oder einen Alert schließt, handelt auf Grundlage dessen, was er gelesen hat. Wird das Ergebnis angefochten, betreffen die ersten Fragen die Eingaben: welche Datensätze der Agent gesehen hat, ob sie aktuell waren, ob er sie lesen durfte und welche Tatsachen in seiner Ausgabe er erfunden hat.
Das Datenschutzrecht stellt eine Variante derselben Frage. Nach Artikel 15 Absatz 1 Buchstabe g der DSGVO hat eine betroffene Person, die Auskunft verlangt, wenn die personenbezogenen Daten nicht bei ihr erhoben wurden, Anspruch auf „alle verfügbaren Informationen über die Herkunft der Daten“. Artikel 14 Absatz 2 Buchstabe f verpflichtet den Verantwortlichen, der betroffenen Person mitzuteilen, „aus welcher Quelle die personenbezogenen Daten stammen“. Ein Agent, der Kundendaten aus mehreren Systemen abruft, erschwert diese Antworten, solange nicht jeder Lesezugriff aufgezeichnet wird.
Die KI-Verordnung nennt Eingaben in Protokollen für eine Kategorie. Für Systeme zur biometrischen Fernidentifizierung nach Anhang III Nummer 1 Buchstabe a verlangt Artikel 12 Absatz 3, dass die Protokollierung „die Referenzdatenbank, mit der das System die Eingabedaten abgleicht“, und „die Eingabedaten, mit denen die Abfrage zu einer Übereinstimmung geführt hat“, umfasst. Für andere Hochrisiko-KI-Systeme verlangen Artikel 12 Absätze 1 und 2 eine automatische Protokollierung, die Rückverfolgbarkeit, Risikoermittlung und Beobachtung nach dem Inverkehrbringen unterstützt, und überlassen die Felder dem Anbieter. Lese-Datensätze sind ein Weg, diese Rückverfolgbarkeit für einen Agenten herzustellen.
Was ein Standard-Trace über Lesezugriffe zeigt
Viele Teams beginnen mit ihren Tracing-Daten. Die OpenTelemetry Semantic Conventions für generative KI mit dem Status Development definieren einen Retrieval-Span mit gen_ai.data_source.id und gen_ai.retrieval.top_k sowie einen Span für die Tool-Ausführung mit gen_ai.tool.name und gen_ai.tool.call.id.
Die Inhaltsattribute sind Opt-In: gen_ai.retrieval.query.text, gen_ai.retrieval.documents, gen_ai.tool.call.arguments, gen_ai.tool.call.result und die Modelleingabe in gen_ai.input.messages. Ein Trace mit Standardeinstellungen kann zeigen, dass ein Abruf oder Tool-Aufruf stattgefunden hat und wie lange er dauerte, ohne festzuhalten, was angefragt wurde oder was zurückkam. Ist die Inhaltserfassung aktiv, liegen die Rohwerte im Trace in einem Speicher, der meist für das Debugging dimensioniert und aufbewahrt wird, ohne Quellversion und ohne Integritätsschutz.
Für den Lese-Datensatz bleibt Tracing nützlich. trace_id und span_id verbinden ein Lese-Ereignis mit dem Span, der es zeitlich erfasst hat.
Vier Arten von Lesezugriffen und was jede braucht
Agenten lesen auf vier Arten. Jede braucht einen etwas anderen Datensatz, und jede hat eine typische Lücke, die den Audit-Trail unterbricht.
| Leseart | Beispiel | Minimaler Datensatz | Übliche Lücke |
|---|---|---|---|
| Strukturierter Systemzugriff | Kundenabfrage im CRM, Saldo im Kernbankensystem, SQL-Abfrage über einen Connector | Tool-ID und -Version, Digest der Argumente, Datensatzreferenzen, Digest des Ergebnisses, Version des Quelldatensatzes oder Stichzeitpunkt | Nur der Tool-Name wird protokolliert; das Ergebnis wird nach dem Schritt verworfen |
| Dokumentzugriff | Passscan, Kontoauszug, unterzeichnetes Mandat | Dokument-ID, SHA-256-Prüfsumme, Version des Speicherobjekts, Eingangszeitpunkt, Seite und Bereich jedes zitierten Werts | Die Datei wird unter demselben Namen ersetzt, sodass die Prüfsumme nicht mehr aufgelöst werden kann |
| Retrieval | Passagen aus dem Richtlinienhandbuch aus einem Vektorindex | Index-ID und Build-Version, Digest der Abfrage, zurückgegebene Chunk-IDs, Scores und Digests der Chunk-Inhalte, top_k | Der Index wird neu aufgebaut, und alte Chunk-IDs existieren nicht mehr |
| Modell oder Gedächtnis | Ein Wert, den das Modell ohne zitierte Quelle geschrieben hat; eine aus dem Agentengedächtnis abgerufene Tatsache | Ein ausdrückliches Quell-Label model oder memory; beim Gedächtnis die ID des Gedächtniseintrags und sein Schreibzeitpunkt | Werte ohne Quelle werden neben Werten mit Quelle gespeichert, ohne dass sie sich unterscheiden lassen |
Ein Lese-Datensatz und eine Feld-Provenienz-Zuordnung
Der folgende Lese-Datensatz ist synthetisch und herstellerneutral. Er beschreibt eine CRM-Abfrage während einer periodischen KYC-Überprüfung. Die Digests sind gekürzt.
{
"read_id": "read_syn_0193_02",
"execution_id": "run_syn_0193",
"tool_call_id": "call_syn_0193_02",
"occurred_at": "2026-10-09T08:12:03.418Z",
"source": {
"system": "crm-eu",
"kind": "api",
"tool_id": "crm.customer.get",
"tool_version": "2026-09-30"
},
"request": {
"arguments_digest": "sha256:3b9e…41d0",
"record_refs": ["cust_syn_55120"]
},
"response": {
"result_digest": "sha256:c07a…9e12",
"source_record_version": "v41",
"as_of": "2026-10-09T08:12:03.390Z"
},
"boundary": {
"data_boundary_ref": "boundary_eu_kyc",
"purpose": "kyc-periodic-review"
},
"retention": {
"content_stored": "digest_only",
"content_location": "crm-eu record history"
}
}Jede Tatsache an ihre Quelle binden
Lese-Datensätze zeigen, was der Agent hätte verwenden können. Die Feld-Provenienz-Zuordnung zeigt, was er tatsächlich verwendet hat. Hängen Sie sie an den Entscheidungsdatensatz an, sodass jedes Ausgabefeld auf genau eine Quelle verweist.
"field_provenance": {
"residence_country": {
"source": "tool",
"tool_call_id": "call_syn_0193_02",
"path": "$.address.country"
},
"id_document_expiry": {
"source": "document",
"document_id": "doc_syn_771",
"checksum_sha256": "8f14…a3c2",
"page": 1
},
"source_of_funds_summary": {
"source": "model"
}
}- Tool-Quelle: Der Wert wird aus einem Pfad in einem aufgezeichneten Tool-Ergebnis gelesen. Die prüfende Person berechnet den Digest des Ergebnisses neu und prüft den Wert an diesem Pfad.
- Dokumentquelle: Der Wert zitiert ein Dokument, das der Agent in diesem Schritt erhalten hat, mit ID und Prüfsumme, mit Seite und, soweit verfügbar, einem Bereich auf der Seite.
- Modellquelle: Der Wert hat keine externe Quelle. Kennzeichnen Sie ihn, damit die prüfende Person ihn als eigene Aussage des Agenten behandelt und entsprechend prüft.
Durchgerechnetes Beispiel: eine synthetische periodische KYC-Überprüfung
Eine fiktive EU-Bank betreibt einen Agenten für die KYC-Aktualisierung. Der Agent liest das Kundenprofil, das aktuelle Ausweisdokument und die Transaktionsübersicht und schlägt dann eine Risikoeinstufung vor, die eine KYC-Analystin genehmigt. Alle Kennungen und Werte unten sind erfunden.
| Entscheidungseingabe | Verwendeter Wert | Quelle | Provenienznachweis | Prüfung und Ergebnis |
|---|---|---|---|---|
| Wohnsitzland | FR | Tool: crm.customer.get | call_syn_0193_02, Digest des Ergebnisses, Datensatzversion v41 | Die CRM-Historie zeigt v41 als aktuell um 08:12:03Z; der Wert stimmt überein. Bestanden |
| Ablauf des Ausweisdokuments | 2031-04-30 | Dokument: doc_syn_771 | Prüfsumme, Seite 1, Bereich über die Textebene lokalisiert | Die gespeicherte Objektversion entspricht der Prüfsumme; das gedruckte Datum stimmt überein. Bestanden |
| Bareinzahlungen, letzte 90 Tage | EUR 18.400 | Tool: txn.summary.get | call_syn_0193_03, Digest des Ergebnisses | Eine erneute Abfrage des Kernbanken-Hauptbuchs für denselben Zeitraum ergibt EUR 18.400. Bestanden |
| Beruf | Selbstständig | Tool: crm.customer.get | call_syn_0193_02, Datensatzversion v41 | Das CRM wurde zwei Tage später in v43 auf „Angestellt“ geändert. Der Agent hat den zum Zeitpunkt aktuellen Wert verwendet. Bestanden, mit einem Hinweis für die Analystin |
| Zusammenfassung zur Herkunft der Mittel | Erzählender Absatz | Modell | source: model | Keine Quelle. Der Genehmigungsdatensatz der Analystin muss zeigen, dass dieser Absatz als vom Agenten geschriebener Text geprüft wurde. Ausnahme: Die Genehmigungsansicht hat ihn nicht gekennzeichnet |
Den Inhalt aufbewahren oder einen Digest aufbewahren
Ein Digest ist klein, kann gefahrlos in einem versiegelten Datensatz gespeichert werden und reicht aus, um eine Übereinstimmung zu beweisen. Für sich allein beweist er nichts: Die Prüfung braucht die Originalbytes, um ihn neu zu berechnen. Legen Sie für jede Quelle fest, wo diese Bytes während der Aufbewahrungsfrist liegen.
- Digest plus Quellversion: geeignet, wenn das Quellsystem die Datensatzhistorie mindestens so lange aufbewahrt, wie der Nachweis prüfbar sein muss. Erfassen Sie die Version oder den Stichzeitpunkt, damit der Lesezugriff später aufgelöst werden kann.
- Digest plus Kopie im Nachweisspeicher: geeignet, wenn die Quelle veränderlich ist, kürzer aufbewahrt wird als der Nachweis oder bei einem Dritten liegt.
- Erfassung auf Feldebene: Speichern Sie nur die Werte, die die Entscheidung verwendet hat, mit ihren Pfaden. So bleiben personenbezogene Daten im Nachweisdatensatz auf das beschränkt, was die Entscheidung braucht.
- Schwärzung und Zugriff: Wenden Sie auf gespeicherte Leseinhalte dieselbe Klassifizierung und Zugriffsrichtlinie an wie auf die Quelle. Erfassen Sie das Schwärzungsprofil mit dem Lesezugriff.
Was KLA heute über Lesezugriffe aufzeichnet
KLA zeichnet Lesezugriffe auf, wo sie über einen gesteuerten Pfad laufen. Die folgenden Punkte beschreiben das aktuelle Verhalten und seine Grenzen.
Gesteuerte Tool-Aufrufe. Ruft ein Agent ein Tool über die KLA-Laufzeit auf, enthalten die signierten Belege für den Aufruf einen SHA-256-Digest der Tool-Argumente und des freigegebenen Ergebnisses. Die Belege werden in das mandantenspezifische Append-only-Nachweisbuch geschrieben und in das Sealed Evidence Bundle übernommen. Das Nachweisbuch enthält den Digest; der gelesene Inhalt bleibt im Quellsystem und im Laufzeitspeicher.
Feld-Provenienz im Process. Ein Process kann für jedes erzeugte Feld eine Quelle festlegen. Bei einer Tool-Quelle erfasst KLA den Wert an einem Pfad des freigegebenen Tool-Ergebnisses und schreibt diesen Wert. Bei einer Dokumentquelle zitiert der Agent ein Stage-Dokument, und das Transition-Gate prüft das Zitat gegen die Dokumente, die die Stage tatsächlich mit Inhalt erhalten hat. Eine festgelegte Quelle ohne Nachweis blockiert den Übergang mit missing_field_provenance. Die Gate-Entscheidung hält die Zuordnung nur als Referenzen fest: {source: "tool", toolKey, callId}, {source: "document", documentId, documentType, checksumSha256, page, region} oder {source: "model"}.
Document Intake. Jedes Quelldokument trägt checksum_sha256, object_version_id und received_at. Die Extraktion erfasst pro Feld einen Hash des Quelltexts, das Extraktionsmodell und die Version des Feldvertrags, und Intake-Ereignisse sind append-only. Lokalisiert der Worker einen zitierten Wert, hält der Datensatz Seite, Box-Koordinaten und Methode (text_layer oder vision) fest, niemals den Text.
Grenzen. KLA erfasst heute weder Chunks aus Vektor-Retrieval noch das vollständige Kontextfenster des Modells. Ein Abruf, den ein Agent in seinem eigenen Code außerhalb eines gesteuerten Tool-Aufrufs ausführt, hinterlässt keinen KLA-Lese-Datensatz; leiten Sie ihn über ein gesteuertes Tool, um ihn aufzuzeichnen. Data Boundaries werden für den Lauf als Ganzes erfasst, ohne Grenzversion pro Lesezugriff.
Was wir beim Aufbau dokumentbasierter Felder gelernt haben
Wir haben dokumentbasierte Felder im September 2026 für einen Proof of Concept zum Merchant-Onboarding gebaut. Ein Feld wie die Handelsregisternummer musste das Onboarding-Dokument zitieren, aus dem es stammte, und das Process-Gate verweigerte den Übergang, wenn das Zitat fehlte.
Unsere Prüfung der ersten Implementierung ergab, dass Zitate gegen alle Dokumente des Laufs geprüft wurden. Ein Agent konnte ein Dokument zitieren, das ihm in diesem Schritt nicht gezeigt worden war, und die Prüfung bestand trotzdem. Wir haben die Prüfung auf die Dokumente umgestellt, die die Stage tatsächlich mit Inhalt erhalten hat. Dieselbe Prüfung ergab, dass aus Tool-Ergebnissen erfasste Werte verloren gingen, wenn ein Lauf pausierte, um auf eine E-Mail-Antwort zu warten; wir haben das behoben, sodass die Erfassungen das Warten überstehen.
Eine Grenze haben wir dokumentiert und beibehalten. Ein Zitat beweist, dass dem Schritt das zitierte Dokument gezeigt wurde. Ob der Wert in diesem Dokument steht, ist eine eigene Frage. Um diese zweite Prüfung zu beschleunigen, haben wir Ende September Zitatbereiche ergänzt: Der Worker lokalisiert den zitierten Wert auf der Seite, und die Fallseite umrandet ihn für die prüfende Person.
Das Lokalisieren von Text mit einem Modell brachte ein eigenes Problem. Ein Modell, das gefragt wird, ob seine eigene Box stimmt, neigt zur Zustimmung. Wir verwenden eine Blindprüfung: Ein zweiter Aufruf transkribiert die ausgeschnittene Box, ohne den erwarteten Text zu sehen, und die Box bleibt nur erhalten, wenn die Transkription übereinstimmt. Bereiche sind eine Lesehilfe auf Grundlage nicht vertrauenswürdiger Seiteninhalte und entscheiden deshalb nie über einen Übergang.
Prüfverfahren für die Lese-Provenienz
Führen Sie diese Schritte an einer risikobasierten Stichprobe von Entscheidungen durch. Das Arbeitspapier für die Prüfung von KI-Agenten zeigt dieselbe Methode für Befugnis, Genehmigung und Ergebnis.
- Eingaben auflisten: Listen Sie für jede Entscheidung der Stichprobe jede Tatsache auf, die der Agent aus seiner Ausgabe und dem Entscheidungsdatensatz verwendet hat.
- Quelle auflösen: Ordnen Sie jede Tatsache einem Lese-Ereignis, einem Dokument oder einem
model-Label zu. Eine Tatsache ohne Eintrag ist eine Ausnahme. - Digests neu berechnen: Rufen Sie den Quellinhalt in der erfassten Version ab und berechnen Sie den Digest des Ergebnisses oder die Prüfsumme neu.
- Zeitpunkte prüfen: Bestätigen Sie, dass jeder Lesezugriff vor der Entscheidung lag und die Quellversion zum Lesezeitpunkt aktuell war.
- Befugnis prüfen: Gleichen Sie jede Quelle und jeden Datensatz mit der Datengrenze und dem Zweck ab, die für den Lauf galten.
- Kennzeichnung prüfen: Bestätigen Sie, dass Tatsachen aus dem Modell der menschlichen prüfenden Person als vom Agenten geschrieben angezeigt wurden.
Häufig gestellte Fragen
Wie kann ich prüfen, woher ein KI-Agent seine Informationen über einen Kunden hatte?
Nehmen Sie eine Entscheidung, listen Sie jede verwendete Kundentatsache auf und führen Sie jede auf einen aufgezeichneten Lesezugriff zurück: den Tool-Aufruf oder das Dokument, die Version des Quelldatensatzes und einen Digest des Ergebnisses. Berechnen Sie den Digest aus der Quelle in dieser Version neu. Jede Tatsache ohne Lese-Datensatz oder mit der Kennzeichnung als vom Modell geschrieben ist entweder eine Ausnahme oder ein Wert, den die prüfende Person als eigene Aussage des Agenten prüfen muss.
Wie prüfe ich, welche Inhalte ein KI-Agent für eine Entscheidung verwendet hat?
Trennen Sie, was der Agent gelesen hat, von dem, was er verwendet hat. Lese-Ereignisse zeigen jeden Abruf und jedes Tool-Ergebnis; eine Feld-Provenienz-Zuordnung im Entscheidungsdatensatz verknüpft jeden Ausgabewert mit einem davon. Ziehen Sie Stichproben von Entscheidungen, berechnen Sie die Digests neu und bestätigen Sie, dass der Inhalt innerhalb der genehmigten Datengrenze lag.
Zeigt ein LLM-Trace, was ein KI-Agent gelesen hat?
Nur wenn die Inhaltserfassung eingeschaltet ist. In den OpenTelemetry-GenAI-Konventionen sind abgerufene Dokumente, Tool-Argumente, Tool-Ergebnisse und Modelleingaben Opt-In-Attribute. Ein Standard-Trace zeigt, dass ein Lesezugriff stattgefunden hat, ohne Aufzeichnung des Inhalts, seiner Quellversion oder seiner Integrität.
Sollte ein Audit-Datensatz den gelesenen Inhalt speichern oder nur einen Hash?
Speichern Sie einen Digest im versiegelten Datensatz und bewahren Sie den Inhalt dort auf, wo er für die gesamte Aufbewahrungsfrist vorgelegt werden kann: im Quellsystem mit einer Versionsreferenz oder im Nachweisspeicher, wenn die Quelle veränderlich ist. Ein Digest ohne abrufbaren Inhalt lässt sich nicht prüfen.
Die wichtigsten Erkenntnisse
Provenienz für eine Agentenentscheidung beruht auf zwei Datensätzen: einem Ereignis pro Lesezugriff und einer Zuordnung jeder Tatsache in der Entscheidung zu einem Lesezugriff, einem Dokument oder dem Modell. Halten Sie den Inhalt so lange auflösbar, wie der Datensatz prüfbar sein muss, und leiten Sie Abrufe über gesteuerte Aufrufe, damit sie aufgezeichnet werden. Für das Datensatzformat beginnen Sie mit dem Audit-Log-Schema für KI-Agenten und dem Ausführungsdatensatz für KI-Agenten. Wie KLA Lesezugriffe mit Entscheidungen und Wirkungen verbindet, zeigt Execution Lineage.