Prove per impostazione predefinita | Developer Docs

Le revisioni di conformità non dovrebbero richiedere di rincorrere screenshot e fogli di calcolo a posteriori. Il KLA Control Plane, il livello di sicurezza, audit e governance che agisce direttamente sul posto e che avvolgi attorno ai tuoi agenti AI esistenti, implementa le prove per impostazione predefinita: ogni controllo di sicurezza, approvazione umana, chiamata di strumento e input al modello viene catturato automaticamente, privato dei dati personali e sigillato in un record a prova di manomissione nel momento stesso in cui avviene. Quando un auditor pone una domanda, la prova esiste già.

Come funziona la pipeline

Le prove attraversano quattro fasi, dalla telemetria grezza fino a un artefatto portabile e verificabile. Ogni fase rafforza un po' di più il record.

flowchart LR
  A["Span di telemetria"] --> B["KLA Collector<br/>Anonimizzazione PII"]
  B --> C["Ledger ImmuDB<br/>Merkle proof"]
  C --> D["Sealed Evidence Bundle"]

Span di telemetria. I tuoi agenti strumentati emettono l'attività come span OpenTelemetry standard, lo standard aperto per le tracce distribuite. KLA arricchisce ciascuno span con attributi semantici GenAI, in modo che il cosa, il perché e il costo di ogni passaggio siano dati di prima classe.
KLA Collector. Il Collector anonimizza le informazioni personali identificabili (PII) prima che qualsiasi cosa venga archiviata o trasmessa, così che i contenuti sensibili non raggiungano mai il ledger.
Ledger ImmuDB. Ogni record viene sottoposto a hashing e scritto in un ledger crittografico ad accodamento esclusivo che produce Merkle proof: impronte matematiche che rendono rilevabile qualsiasi manomissione.
Sealed Evidence Bundle. All'esportazione dall'Evidence Room, KLA raccoglie i record rilevanti con le relative prove in un file autonomo e verificabile in modo indipendente.

ℹ️ Note

Un **Lineage Record** è il nome che KLA dà a una singola traccia end-to-end di un'esecuzione di un agente. La pipeline delle prove per impostazione predefinita trasforma ogni Lineage Record in una prova durevole e dimostrabile, senza alcun passaggio aggiuntivo da parte del tuo team.

Attributi semantici per GenAI

KLA estende OpenTelemetry con attributi pensati appositamente per la governance degli agenti AI. Questi rendono una traccia leggibile per un responsabile della conformità, non solo per uno sviluppatore.

Attributo	Cosa cattura
`genai.agent.name`	L'istanza dell'agente che ha eseguito l'azione
`genai.system.instructions`	Il system prompt che ha plasmato il comportamento dell'agente
`genai.tool.name`	Lo strumento, il database o l'API invocato dall'agente
`genai.tool.parameters`	I parametri esatti passati a quello strumento
`genai.cost.usd`	Il costo in dollari attribuito al passaggio
`genai.token.usage`	I token consumati, per i controlli di budget e soglia

Poiché si tratta di attributi OpenTelemetry standard, non resti mai vincolato a un formato proprietario. Gli stessi span possono alimentare il tuo stack di osservabilità.

Anonimizzazione delle PII ai margini

I dati sensibili vengono mascherati prima che lascino il tuo ambiente, non dopo che sono finiti da qualche parte. Quando l'anonimizzazione è abilitata, l'SDK e il Collector collaborano per tenere i contenuti regolamentati fuori dalla traccia delle prove:

Input e output vengono analizzati alla ricerca di pattern PII comuni (email, numeri di carte di pagamento, identificativi nazionali) e le corrispondenze vengono sostituite con segnaposto come [REDACTED_EMAIL].
I parametri di strumento che contengono segreti (password, token, JWT) vengono mascherati direttamente all'interno di genai.tool.parameters.
L'anonimizzazione avviene prima della trasmissione di rete, perciò i valori non mascherati non vengono mai archiviati nel ledger.

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

🛡️ Important

L'anonimizzazione preserva la *struttura*, non i *segreti*. Un revisore può confermare che un agente ha interrogato il record di un cliente senza mai vedere i dati reali del cliente, soddisfacendo i requisiti di minimizzazione e mantenendo al contempo la traccia utile.

Ancoraggio crittografico con ImmuDB

Per garantire che le prove non possano essere alterate silenziosamente dopo la scrittura, KLA conferma ogni record su ImmuDB, un database ledger crittografico ad alte prestazioni.

Ledger ad accodamento esclusivo. I record vengono scritti in una struttura ad albero di Merkle. Le voci esistenti non possono essere eliminate, modificate o riordinate senza invalidare la catena di prove.
Merkle proof. Ogni record viene sottoposto a hash nel registro ad accodamento esclusivo, e quell'hash insieme all'ancoraggio al registro viaggiano con il record. Il verificatore del bundle ricalcola la Merkle root propria del bundle e conferma che l'ancoraggio sia vincolato a questo record; la proof del registro conservata supporta verifiche di inclusione più approfondite rispetto allo stato firmato del registro.
Sealed Evidence Bundle. Quando esporti dall'Evidence Room, KLA allega la Merkle proof per ogni traccia inclusa, producendo un artefatto portabile e verificabile da terze parti.

Gran parte della verifica viene eseguita offline, senza riporre fiducia nei sistemi attivi di KLA. Un auditor verifica le firme SEK e TEK, conferma ogni hash degli artefatti e ricalcola la Merkle root propria del bundle — interamente in autonomia. Il bundle contiene anche l'ancoraggio al registro immudb e una ricevuta OpenTimestamps su Bitcoin per questo manifest; offline il verificatore conferma che entrambi siano vincolati al manifest (la verifica completa dell'inclusione nel registro e la conferma on-chain richiedono lo stato firmato del registro e la blockchain Bitcoin). La verifica indipendente e offline è proprio il punto.

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

Raccogli un Lineage Record insieme alla decisione di policy che lo ha governato (`allow`, `warn`, `require_approval` o `block`) e a qualsiasi approvazione del Decision Desk, per produrre in un unico file una storia completa e difendibile di una singola esecuzione di un agente.