La riproducibilità nell'intelligenza artificiale non significa solo rieseguire il modello con gli stessi input. Significa ricostruire la decisione specifica così com'era stata presa, contro lo stato che l'ha prodotta, senza nemmeno invocare nuovamente il modello. La maggior parte dei sistemi AI aziendali è in grado di fare la prima cosa, mentre quasi nessuno riesce a realizzare la seconda, ed è proprio questa che i regolatori stanno richiedendo.

Il contesto: audit replay vs. model replay

Nel decimo articolo di una serie sull'economia ingegneristica dell'AI regolamentata, si è affrontato come, dopo nove mesi di operatività di una pipeline di rischio climatico per il cliente DCarbon, un revisore abbia richiesto una risposta su un singolo record fornitore. La richiesta era estremamente circoscritta: “Nella data di valutazione, qual era lo stato esatto del sistema e quale evidenza ha sostenuto la classificazione?”

L'istinto naturale del team di ingegneria – e di quasi tutti i team AI – è stato quello di ricaricare la versione corrente del classificatore, alimentare il record e fornire il punteggio generato. Questo approccio è quello che la maggior parte dei discorsi sulla riproducibilità in azienda identifica con la frase “possiamo rigenerare l'output”. Tuttavia, l'auditor non chiedeva un nuovo punteggio, ma lo stato del sistema al momento della valutazione originale, avvenuta sette mesi prima.

Nel frattempo, il classificatore era stato riaddestrato due volte, il corpus di recupero aggiornato, le regole di escalation erano passate attraverso tre iterazioni versionate e il record del fornitore aveva subito quattro eventi successivi, di cui uno solo materiale per la decisione in questione. Eseguire la catena attuale sul record corrente produceva una risposta valida per il presente, ma non rispondeva alla domanda dell'auditor, né era ammissibile come prova per la disclosure.

Grazie alla persistenza completa dello stato – progettata nella “escalation layer” della pipeline – è stato possibile ricostruire il vettore di feature esatto, il contesto di recupero, la versione del ruleset, la versione del modello, l'impronta dell'ambiente di runtime e il bundle di evidenze associato all'evento di scoring. Questa ricostruzione, accompagnata da una prova deterministica di fedeltà, è stata accettata entro quarantotto ore, salvando la disclosure.

Perché il model replay non è sufficiente

Il modello di riproducibilità più diffuso nelle AI di produzione si concentra sulla rigenerazione dell'output. Con gli stessi input, il modello dovrebbe produrre gli stessi risultati: la determinismo bit‑per‑bit è lo standard d'oro, mentre il determinismo statistico è un fallback accettabile. Questi sono traguardi ingegneristici importanti, ma non rispondono alla domanda regolamentare fondamentale:

    • Puoi produrre, come prova, lo stato esatto che ha generato un output passato?
    • Puoi dimostrare che quello stato è realmente quello che il modello ha usato?

Queste richieste riguardano l'architettura di persistenza che circonda il modello, non il modello stesso. La differenza si manifesta sotto tre pressioni specifiche.

1. Separazione temporale

Le richieste normative arrivano spesso mesi o anni dopo la decisione. Il modello che ha prodotto la decisione può essere stato ritirato, il corpus di recupero ri‑indicizzato, il ruleset sostituito e l'infrastruttura migrata. Un model replay risponde a “cosa farebbe il sistema oggi con gli stessi input”, mentre l'auditor vuole sapere “cosa ha fatto il sistema nella data specifica con lo stato allora vigente”.

Secondo l'Articolo 22 del GDPR, i soggetti hanno diritto a ottenere “informazioni significative sulla logica coinvolta” in una decisione passata; la risposta deve riferirsi allo stato al momento della decisione, non a quello attuale.

2. Entanglement di stato

I sistemi AI aziendali non sono funzioni pure: dipendono da contesti di recupero, versioni di regole, pipeline di feature e fonti dati dinamiche. Per rigenerare esattamente l'output bisognerebbe “pinnare” ogni dipendenza al suo stato storico – proprio quello richiesto dall’audit replay. La maggior parte dei sistemi può fissare la versione del modello, pochi riescono a fissare il corpus di recupero, ancora meno il ruleset, e quasi nessuno riesce a fissare tutti e tre simultaneamente per un timestamp storico.

3. Valore probatorio

Quando un auditor accetta una ricostruzione come prova, la ricostruzione stessa deve portare una dimostrazione di fedeltà: lo stato presentato deve essere quello realmente visto dal modello. Questa prova non è un extra; è un requisito normativo. Sotto le direttive CSRD e le obbligazioni di audit‑trail per le disclosure AI‑assistite, una ricostruzione la cui fedeltà non può essere verificata indipendentemente è contestabile e perde valore probatorio.

Queste tre pressioni si combinano: la separazione temporale rende il model replay meno pertinente; l'entanglement rende più difficile la rigenerazione bit‑per‑bit; e il valore probatorio richiede una prova di fedeltà che il model replay non fornisce.

Come implementare l’audit replay: disciplina ingegneristica

Per colmare il divario, è necessario adottare un’architettura di persistenza completa. Di seguito i componenti chiave:

    • Persistenza del vettore di feature: ogni evento di scoring deve salvare il vettore esatto inviato al modello.
    • Versionamento dei corpus di recupero: ogni set di documenti, indice o embedding deve essere immutabile e referenziabile da un identificatore di versione.
    • Ruleset versionato: le regole di escalation, filtraggio o soglia devono essere gestite tramite un sistema di versionamento con hash verificabili.
    • Fingerprint dell’ambiente di runtime: container, librerie, configurazioni hardware devono essere catturati in un hash crittografico.
    • Bundle di evidenze: tutti i documenti, log e giustificazioni associati al risultato devono essere archiviati e collegati all’evento.
    • Prova deterministica di integrità: mediante Merkle tree o firme digitali, si deve garantire che nessuna parte del bundle sia stata alterata.

Una volta che tutti questi elementi sono salvati in modo immutabile, l’audit replay consiste nel:

    • Recuperare l’identificatore dell’evento (ad es. ID di scoring).
    • Estrarre il vettore di feature, il corpus, il ruleset, il modello e l’ambiente di runtime associati.
    • Presentare questi artefatti insieme alla prova di integrità al richiedente.

Questa procedura non richiede l’esecuzione del modello; il risultato è una dimostrazione di cosa il modello ha visto, non una nuova predizione.

Conseguenze per le organizzazioni

Le aziende che hanno investito solo nella riproducibilità del modello hanno acquistato un’assicurazione sbagliata. In caso di verifica regolamentare, si trovano a dover fornire risposte insufficienti o a ricorrere a ricostruzioni non verificabili, con il rischio di sanzioni, perdita di credibilità o revoca della certificazione. Al contrario, chi implementa l’audit replay ottiene:

    • Conformità alle richieste di GDPR, CSRD e altre normative emergenti.
    • Un vantaggio competitivo nella trasparenza dei processi AI.
    • Una riduzione del rischio legale grazie a prove verificabili.
    • Una base solida per future richieste di audit su altri modelli o processi.

Prossimi passi e conclusioni

Il prossimo articolo della serie affronterà il model version pinning come primitivo regolamentare, dimostrando perché la risposta “abbiamo aggiornato a un modello più recente” è inadeguata a una query di conformità, e illustrerà il pattern architetturale corretto.

In sintesi, la differenza tra model replay e audit replay è una delle più importanti distinzioni architetturali nell’AI regolamentata. Mentre il primo si concentra sulla rigenerazione dell’output, il secondo garantisce la ricostruzione fedele dello stato storico, supportata da prove verificabili. Solo adottando una disciplina di persistenza completa le organizzazioni potranno rispondere adeguatamente alle richieste normative e ridurre il rischio di non conformità.