Replay deterministico
Il replay deterministico consiste nel rieseguire una decisione registrata di un agente AI con gli stessi input, la stessa versione della policy e la stessa configurazione, per confermare che produca lo stesso esito.
Definizione
Il replay deterministico consiste nel rieseguire una decisione registrata con gli input, la versione della policy, l’output del modello e la configurazione in vigore in quel momento, ottenendo di nuovo lo stesso esito. Per un agente AI, la decisione che conta di più sta nel punto di controllo: l’agente ha proposto un’azione, una policy l’ha valutata e il risultato è stato allow, warn, require_approval o block. Se un auditor può riprodurre quella valutazione e arrivare allo stesso risultato, il record sostiene l’affermazione che il controllo ha funzionato come descritto.
Il replay conta perché il comportamento di un agente è difficile da ricostruire a posteriori. Un modello linguistico di grandi dimensioni può restituire un completamento diverso per lo stesso prompt, e il modello dietro un’API può cambiare versione. Interrogare di nuovo il modello mette alla prova il modello di oggi. Un replay fedele usa ciò che è stato registrato. L’articolo 12 dell’AI Act impone ai sistemi di IA ad alto rischio di registrare eventi in modo che il loro funzionamento sia tracciabile in misura adeguata alla finalità prevista, e il replay è un test pratico della completezza dei log.
Tre parti di una decisione di un agente possono essere riprodotte esattamente, purché siano state registrate: la valutazione della policy (stesse regole, stessa versione, stessi campi di input), l’instradamento di un’azione trattenuta verso un revisore e qualsiasi calcolo di soglie o limiti. Il ragionamento del modello può essere riprodotto solo riusando l’output del modello registrato. Un replay mostra come si è arrivati alla decisione. Il risultato dello strumento, la conferma del pagamento o la ricevuta del sistema registrati dopo l’esecuzione mostrano se l’azione è avvenuta.
Perché il replay funzioni, registrate per ogni azione: l’azione proposta e i suoi argomenti, la versione della policy e l’hash del suo contenuto, i dati di input letti dalla policy, l’output del modello che ha portato alla proposta, l’esito e la regola che lo ha prodotto, l’eventuale decisione umana e un timestamp per ogni passaggio. Se manca un elemento, il replay diventa un’approssimazione, e il record dovrebbe dichiararlo.
In KLA una versione della policy può essere riprodotta sulle esecuzioni recenti registrate del tenant. Ogni esecuzione viene rivalutata e confrontata con l’esito registrato all’epoca, le esecuzioni registrate senza i loro input decisionali sono elencate come non riprodotte, e il replay non crea approvazioni né record di evidenza. In uno dei nostri cicli di QA su dati sintetici, una bozza di policy riprodotta su 200 esecuzioni registrate ne ha confrontate 195, ne ha escluse 5 con campi mascherati o mancanti e ha portato le richieste di approvazione da 37 a 40. Abbiamo scelto questo approccio dopo aver giudicato poco praticabili per il personale di compliance i casi di test costruiti a mano con molti campi.
Termini correlati
Lineage a prova di manomissione
Il lineage a prova di manomissione è un record append-only delle azioni di un agente e delle decisioni di governance applicate, la cui integrità può essere verificata in modo indipendente.
Traccia di audit
Un record cronologico delle attività, decisioni e interazioni umane di un sistema di IA che abilita tracciabilità e responsabilità.
Provenienza dei dati
La provenienza dei dati è il record che indica da dove proviene un dato, che cosa lo ha prodotto e come è cambiato prima di essere usato.
