Riproduzione deterministica delle decisioni degli agenti IA

Tre cose che si intendono per riproduzione¶

I team usano la parola per tre operazioni diverse. Indicate nel piano di audit quella che intendete, perché ciascuna dimostra qualcosa di diverso.

Cosa si riproduce in modo deterministico e cosa no¶

Una regola di policy che confronta un importo con una soglia, verifica un ruolo o controlla un campo rispetto a un elenco dà la stessa risposta per gli stessi input. Questo la rende riproducibile, a condizione che gli input e la versione esatta della regola siano registrati.

Un modello linguistico ospitato può restituire testi diversi per lo stesso prompt tra una chiamata e l’altra e tra un aggiornamento del modello e l’altro. Abbassare la temperatura di campionamento riduce la variazione senza eliminarla, e alcuni modelli attuali non accettano un’impostazione di temperatura. Trattate l’output del modello come un input registrato: conservate ciò che il modello ha restituito e riproducete la decisione da lì.

Un AI judge, cioè un modello a cui si chiede di classificare o confrontare testo all’interno di un controllo di policy, ha lo stesso problema. Registrate il suo verdetto con fornitore, modello, versione del prompt e hash di ciò che ha confrontato. Una riproduzione può allora verificare il resto della decisione attorno a quel verdetto registrato.

I sistemi esterni cambiano. Un record cliente, una lista di sanzioni o un saldo letto al momento della decisione saranno diversi una settimana dopo. Riproducete a partire dalla lettura registrata, con la sua versione della fonte, e mai da una nuova query.

• Deterministico: controlli di soglia, di ruolo, di appartenenza a un elenco e di schema; precedenza degli esiti tra allow, warn, require_approval e block; instradamento verso un ruolo di revisore.
• Registrato e riutilizzato: output del modello, verdetti dell’AI judge, risultati del recupero, risultati degli strumenti, decisioni umane, marche temporali usate dalle regole.
• Mai ripetuto: scritture, pagamenti, messaggi, depositi e qualsiasi altra chiamata con un effetto esterno.

Cosa registrare perché la riproduzione funzioni¶

La maggior parte delle riproduzioni fallite si riconduce a un singolo elemento mancante. La tabella elenca cosa serve a una riproduzione della decisione, con nomi di campo di esempio.

Esempio svolto: riprodurre una decisione di credito sintetica¶

L’agente di credito di una banca fittizia ha richiesto una disposizione di EUR 24.000 per un richiedente lavoratore autonomo. La policy credit-disposition-policy 4.2.1 ha restituito require_approval in base alla regola manual-review-above-20000. L’auditor riproduce la decisione due volte: con la versione registrata e con una bozza 4.3.0 che aggiunge un blocco per i lavoratori autonomi sopra EUR 15.000. Tutti gli identificativi e i valori sono inventati e i digest sono abbreviati.

{
  "run_id": "run_syn_0418",
  "replay_scope": "deterministic-only",
  "recorded": {
    "policy_id": "credit-disposition-policy",
    "policy_version": "4.2.1",
    "policy_pack_hash": "sha256:a4fc…278a",
    "decision": "require_approval",
    "matched_rules": ["manual-review-above-20000"],
    "occurred_at": "2026-10-02T10:02:11.204Z"
  },
  "replayed": [
    {
      "policy_version": "4.2.1",
      "decision": "require_approval",
      "matched_rules": ["manual-review-above-20000"],
      "delta": "none"
    },
    {
      "policy_version": "4.3.0-draft",
      "decision": "block",
      "matched_rules": ["block-self-employed-above-15000"],
      "delta": "require_approval -> block"
    }
  ],
  "not_replayed": [
    {
      "gate": "memo-consistency-check",
      "reason": "needs_original_text"
    }
  ]
}

• Versione registrata: la riproduzione con la 4.2.1 restituisce require_approval con la stessa regola. La decisione registrata deriva dagli input registrati.
• Versione bozza: la riproduzione con la 4.3.0 restituisce block. Il delta mostra l’impatto della bozza su questa esecuzione prima del rilascio.
• Non riprodotto: un gate usava un AI judge su un testo di relazione non conservato. La riproduzione lo riporta sotto needs_original_text e lo esclude dal confronto.
• Non dimostrato: se il core banking ha registrato la disposizione. Lo dicono la ricevuta dello strumento e il record del core banking.

Una decisione riprodotta non dimostra un’azione esterna¶

Una riproduzione corrispondente dimostra che la policy, applicata agli input registrati, dà l’esito registrato. Non dimostra che il sistema a valle abbia accettato la chiamata, applicato la modifica, applicata una sola volta o mantenuta. Un pagamento può essere respinto dopo che la chiamata dell’agente è tornata. Un record può essere modificato da un altro processo un minuto dopo.

La prova di un effetto esterno viene dal sistema esterno: una ricevuta a valle, un digest dello stato successivo, un riferimento all’effetto che il sistema di registrazione può risolvere o un estratto di riconciliazione. La registrazione dell’esecuzione degli agenti IA li mostra come tool_calls[].result_digest e downstream_effects[] con i digest dello stato prima e dopo. Un auditor li verifica separatamente dalla riproduzione.

Inoltre la riproduzione non deve mai creare un secondo effetto. Una chiave di idempotenza per azione consente a una chiamata ritentata o ripresa di restituire il risultato conservato. Quando una chiamata è stata inviata e nessun risultato è stato registrato, l’esito è sconosciuto: la risposta corretta è la riconciliazione con il sistema di destinazione, e una riproduzione non può risolverlo.

Cosa abbiamo imparato costruendo la riproduzione delle decisioni¶

All’inizio abbiamo offerto la simulazione delle policy tramite casi di test costruiti a mano. L’uso interno del prodotto a ottobre 2026 ha reso evidente il problema: un responsabile della compliance non scriverà un caso di test con decine di campi per verificare una modifica di policy. La domanda che pone è cosa avrebbe fatto la modifica alle decisioni recenti, per esempio quanti casi in più sarebbero andati in revisione umana. È la domanda a cui risponde la nostra riproduzione d’impatto, eseguendo una bozza sulle esecuzioni registrate recenti ed elencando ogni esecuzione il cui esito cambierebbe.

La riproduzione funziona solo su input registrati fin dall’inizio. Abbiamo iniziato a conservare il contesto della decisione valutato su ogni registrazione di decisione il 23 settembre 2026. Le decisioni registrate prima di quella data non si possono riprodurre; la riproduzione d’impatto le conta sotto no_recorded_context e non le conta mai come corrispondenze.

Confrontate le regole applicate oltre agli esiti. Per una dimostrazione di sblocco di pagamenti trattenuti preparata per un briefing con analisti a ottobre 2026, su dati sintetici, abbiamo eseguito cinque simulazioni di policy. Ogni risultato registrava l’esito atteso ed effettivo, gli ID delle regole applicate, l’ID e la versione della policy e un ID di prova, e tutte e cinque corrispondevano. Il risultato block per una corrispondenza confermata con le sanzioni elencava due regole applicate, il blocco per sanzioni e la regola generale di approvazione dello sblocco, con un solo codice motivo. Un confronto sui soli esiti non avrebbe mostrato che erano scattate entrambe le regole. Una simulazione precedente nello stesso lavoro era fallita in modo sicuro perché l’input dello strumento non aveva una convalida affidabile; abbiamo riscritto la regola perché leggesse i campi del work item del Process, e l’esecuzione fallita resta nello storico di audit.

Contate i codici motivo prima di spiegare un tasso. In un benchmark interno di un controllo con AI judge a settembre 2026, una variante di policy sembrava intervenire a torto nel 98% dei casi. I codici motivo hanno mostrato che quegli interventi erano 565 risultati judge_unavailable causati dal troncamento dell’input, identici tra i modelli. In un primo momento avevamo dato la colpa alla logica di corrispondenza. Una variante successiva, che confrontava solo l’istruzione con l’azione corrente, non presentava troncamento.

Come KLA riproduce oggi le decisioni¶

KLA registra ogni decisione di policy con ID della policy, versione, hash del policy pack, regole applicate, codici motivo, esito e ora, e conserva una copia oscurata degli input della decisione per la riproduzione. Le registrazioni di decisione scritte prima che KLA conservasse quella copia sono segnalate come non riproducibili.

Riproduzione per esecuzione. KLA rivaluta gli input registrati della decisione di un’esecuzione con i controlli AI judge e guardrail disattivati e senza creare approvazioni. La risposta è etichettata deterministic-only ed elenca, per ogni gate, la decisione precedente e quella nuova.

Riproduzione d’impatto. Una Simulation rivaluta una versione di policy scelta, di solito una bozza, sulle ultime 50, 200 o 1.000 esecuzioni registrate nell’ambito della policy (200 per impostazione predefinita) ed elenca ogni esecuzione in cui l’esito registrato e quello della bozza differiscono. Legge solo le registrazioni di decisione e non crea prove, approvazioni né registrazioni di decisione. Ogni esecuzione che non può riprodurre è conteggiata sotto un motivo: no_recorded_context, input_not_stored, tool_schema_changed, decided_by_safeguard o needs_original_text.

Controlli AI judge. KLA registra per ogni controllo del judge il fornitore, il modello, la versione del prompt, gli hash degli operandi confrontati, il verdetto, la confidenza e il metodo. La riproduzione non chiama di nuovo il judge; le esecuzioni che ne dipendono sono riportate sotto needs_original_text.

Configurazione dell’agente. Ogni esecuzione fa riferimento a un hash del manifest dell’agente, e lo storico dei manifest conserva il manifest completo: fornitore e nome del modello, istruzioni e strumenti.

Effetti esterni. Il runtime identifica ogni azione governata di uno strumento per tenant, esecuzione e gate. Un nuovo tentativo restituisce il risultato confermato. Una chiamata con un intento registrato e nessun risultato si ferma con "execution outcome is unknown; operator reconciliation is required".

Visualizzazione. Lineage Explorer e la vista del runtime dell’agente mostrano la sequenza registrata di un’esecuzione. Non la rieseguono.

Limiti. KLA non riesegue chiamate al modello o strumenti nell’ambito della riproduzione. La documentazione dell’evidence verifier afferma che i suoi controlli dimostrano il collegamento della decisione registrata, "not downstream tool execution".

La riproduzione come procedura di audit¶

Usate la riproduzione della decisione come test di riesecuzione su un campione. Registrate ogni risultato nella carta di lavoro; la carta di lavoro compilata per l’audit degli agenti IA include una riga sulla riproduzione con il relativo limite dichiarato.

• Selezionare: estraete il campione dalla popolazione riconciliata, includendo esiti block e require_approval ed esecuzioni a ridosso di modifiche di policy.
• Fissare: risolvete la versione della policy e l’hash del pack registrati rispetto all’archivio delle release.
• Riprodurre: rieseguite la decisione sugli input registrati senza accesso agli strumenti.
• Confrontare: confrontate esito e regole con la registrazione. Classificate ogni differenza: modifica di regola, input non conservato, modifica di schema, dipendenza dal judge o dal modello, oppure divergenza non spiegata.
• Verificare gli effetti separatamente: ricostruite ogni azione eseguita fino al sistema a valle e riconciliatela.
• Dichiarare i limiti: indicate quali gate sono stati esclusi e perché, e non estendete la conclusione della riproduzione agli effetti esterni.