Evidence-by-Default | Developer Docs

Compliance-Prüfungen sollten nicht erfordern, dass man im Nachhinein Screenshots und Tabellenkalkulationen zusammensucht. Die KLA Control Plane, die Schicht für Sicherheit, Audit und Governance, die Sie um Ihre bestehenden KI-Agenten legen und die diese direkt an Ort und Stelle absichert, setzt Evidence-by-Default um: Jede Sicherheitsprüfung, jede menschliche Freigabe, jeder Tool-Aufruf und jede Modelleingabe wird automatisch erfasst, von personenbezogenen Daten bereinigt und im selben Moment, in dem sie geschieht, in einem manipulationssicheren Datensatz versiegelt. Bis ein Prüfer danach fragt, existiert der Nachweis bereits.

So funktioniert die Pipeline

Beweise durchlaufen vier Phasen, von der reinen Telemetrie bis zum portablen, verifizierbaren Artefakt. Jede Phase härtet den Datensatz ein Stück weiter ab.

flowchart LR
  A["Telemetrie-Spans"] --> B["KLA Collector<br/>PII-Bereinigung"]
  B --> C["ImmuDB-Ledger<br/>Merkle-Proofs"]
  C --> D["Sealed Evidence Bundle"]

Telemetrie-Spans. Ihre instrumentierten Agenten geben Aktivitäten als standardmäßige OpenTelemetry-Spans aus, dem offenen Standard für verteilte Traces. KLA reichert jeden Span mit semantischen GenAI-Attributen an, sodass das Was, Warum und die Kosten jedes Schritts erstklassige Daten werden.
KLA Collector. Der Collector bereinigt personenbezogene Daten (PII), bevor etwas gespeichert oder übertragen wird, sodass sensible Inhalte niemals den Ledger erreichen.
ImmuDB-Ledger. Jeder Datensatz wird gehasht und in einen kryptografischen Append-only-Ledger geschrieben, der Merkle-Proofs erzeugt: mathematische Fingerabdrücke, die Manipulationen erkennbar machen.
Sealed Evidence Bundle. Beim Export aus dem Evidence Room verpackt KLA die relevanten Datensätze samt ihren Proofs in eine in sich geschlossene, unabhängig verifizierbare Datei.

ℹ️ Note

Ein **Lineage Record** ist KLAs Bezeichnung für einen einzelnen End-to-End-Trace eines Agentenlaufs. Die Evidence-by-Default-Pipeline verwandelt jeden Lineage Record in dauerhafte, beweisbare Evidenz, ohne dass Ihr Team zusätzliche Schritte unternehmen muss.

Semantische Attribute für GenAI

KLA erweitert OpenTelemetry um Attribute, die speziell für die Governance von KI-Agenten entwickelt wurden. Sie machen einen Trace nicht nur für Entwickler, sondern auch für einen Compliance-Verantwortlichen lesbar.

Attribut	Erfasst
`genai.agent.name`	Die Agenteninstanz, die die Aktion ausgeführt hat
`genai.system.instructions`	Der System-Prompt, der das Verhalten des Agenten geprägt hat
`genai.tool.name`	Das Tool, die Datenbank oder die API, die der Agent aufgerufen hat
`genai.tool.parameters`	Die genauen Parameter, die an dieses Tool übergeben wurden
`genai.cost.usd`	Die dem Schritt zugeordneten Kosten in Dollar
`genai.token.usage`	Verbrauchte Tokens, für Budget- und Schwellenwertprüfungen

Da es sich um standardmäßige OpenTelemetry-Attribute handelt, sind Sie niemals an ein proprietäres Format gebunden. Dieselben Spans können auch Ihren eigenen Observability-Stack speisen.

PII-Bereinigung am Rand

Sensible Daten werden maskiert, bevor sie Ihre Umgebung verlassen, nicht erst nachdem sie irgendwo gelandet sind. Wenn die Bereinigung aktiviert ist, arbeiten SDK und Collector zusammen, um regulierte Inhalte aus dem Beweisverlauf herauszuhalten:

Ein- und Ausgaben werden auf gängige PII-Muster geprüft (E-Mail-Adressen, Zahlungskartennummern, nationale Kennungen), und Treffer werden durch Platzhalter wie [REDACTED_EMAIL] ersetzt.
Tool-Parameter, die Geheimnisse enthalten (Passwörter, Tokens, JWTs), werden direkt innerhalb von genai.tool.parameters maskiert.
Die Bereinigung erfolgt vor der Netzwerkübertragung, sodass unmaskierte Werte niemals im Ledger gespeichert werden.

collector:
  redaction:
    enabled: true
    patterns: [email, credit_card, national_id]
    secret_fields: [password, token, authorization]

🛡️ Important

Die Bereinigung bewahrt die *Struktur*, nicht die *Geheimnisse*. Ein Prüfer kann bestätigen, dass ein Agent einen Kundendatensatz abgefragt hat, ohne jemals die tatsächlichen Daten des Kunden zu sehen. So werden Minimierungsanforderungen erfüllt und der Trace bleibt dennoch aussagekräftig.

Kryptografische Verankerung mit ImmuDB

Um zu garantieren, dass Beweise nach dem Schreiben nicht unbemerkt verändert werden können, schreibt KLA jeden Datensatz in ImmuDB, eine hochperformante kryptografische Ledger-Datenbank.

Append-only-Ledger. Datensätze werden in eine Merkle-Tree-Struktur geschrieben. Bestehende Einträge können nicht gelöscht, bearbeitet oder umsortiert werden, ohne die Proof-Kette ungültig zu machen.
Merkle-Proofs. Jeder Datensatz trägt einen Hash, der zu einem veröffentlichten Root-Hash zusammengeführt wird. Jeder kann die Kette neu berechnen, um die genaue Position und den Inhalt eines Datensatzes zu bestätigen.
Sealed Evidence Bundles. Wenn Sie aus dem Evidence Room exportieren, hängt KLA an jeden enthaltenen Trace den Merkle-Proof an und erzeugt so ein portables, durch Dritte verifizierbares Artefakt.

Die Verifizierung ist nicht darauf angewiesen, KLA zu vertrauen. Ein Prüfer berechnet die Merkle-Proofs in einem Sealed Evidence Bundle gegen den veröffentlichten Root-Hash neu und bestätigt vollständig eigenständig, dass die Beweise authentisch und unverändert sind. Genau darum geht es: um die unabhängige Verifizierbarkeit.

curl https://api.kla.digital/v1/evidence.bundle?lineageId=ln_9f2c \
  -H "Authorization: Bearer $KLA_ACCESS_TOKEN" \
  -H "x-tenant-id: acme-prod" \
  -o evidence-bundle.zip

💡 Tip

Bündeln Sie einen Lineage Record zusammen mit der Richtlinienentscheidung, die ihn geregelt hat (`allow`, `warn`, `require_approval` oder `block`), sowie jeder Decision Desk-Freigabe, um in einer einzigen Datei eine vollständige, belastbare Darstellung für einen einzelnen Agentenlauf zu erzeugen.