Ogni azione automatica lascia una traccia replicabile.

No, e chi ve lo promette vi sta dicendo una cosa che non può mantenere. La conformità non è una proprietà di un software: è una proprietà di come un'organizzazione usa quel software dentro i propri processi, valutata rispetto a norme che riguardano voi e non noi.

Quello che un sistema può fare è fornire gli elementi strutturali che una conformità verificabile richiede, e che senza software sono costosissimi da ottenere: regole esplicite e versionate, controlli applicati dal motore e non dalle persone, tracciabilità completa e ricostruibile, poteri di deroga dichiarati e misurabili.

La differenza che questo fa, nella pratica, è sul costo di dimostrare la conformità più che sulla conformità stessa. Un'organizzazione che deve istruire una verifica passa dal ricostruire comportamenti al consultare descrizioni. È un cambiamento di natura del lavoro, e chi ha vissuto un'ispezione capisce immediatamente quanto valga.

È il punto in cui questo approccio si distingue di più, e vale la pena spiegarlo con precisione perché è controintuitivo.

In un sistema tradizionale le regole di lavorazione sono codice. Per sapere cosa fa davvero il sistema bisogna chiedere a chi lo ha scritto, e la risposta è necessariamente una descrizione di seconda mano. La funzione di controllo può verificare gli esiti — campionando casi — ma non il meccanismo. È il motivo per cui i controlli sono statistici invece che strutturali.

Nel modello dichiarativo le regole sono un documento strutturato leggibile: quali controlli esistono, con quali soglie, con quale decorrenza, chi può derogare e in quali condizioni. E quel documento non è la documentazione del sistema: è il sistema. Non può esistere uno scostamento fra ciò che è scritto e ciò che viene applicato, perché sono la stessa cosa.

Una funzione di controllo può quindi leggerlo, confrontarlo con la normativa interna e rilevare differenze senza dipendere da nessuno. Il lavoro sui casi concreti resta, ma cambia natura: da ricostruzione a riscontro.

Tre aspetti distinti che conviene tenere separati, perché hanno soluzioni diverse.

L'integrità della traccia. Gli eventi di audit sono scritti in sola aggiunta: il flusso normale del sistema non prevede un percorso per modificarli o cancellarli. Questo non equivale a un'immutabilità crittografica garantita contro un amministratore di sistema con accesso diretto alla base dati — nessun sistema applicativo può promettere questo da solo. Dove il requisito lo impone, la traccia può essere replicata verso un archivio esterno in sola aggiunta o un sistema di conservazione dedicato.

La conservazione nel tempo. I periodi di conservazione sono dichiarati per categoria e coerenti con i vostri obblighi: si stabilisce quali tracce restano per quanto, e la regola è esplicita invece di essere una conseguenza della configurazione di un database.

La minimizzazione. Un audit trail completo è anche un archivio di dati personali. Per questo si dichiara esplicitamente quali contenuti finiscono nella traccia e quali no: registrare che un campo è stato modificato non richiede necessariamente di conservarne per anni il valore precedente, e questa è una scelta da fare consapevolmente con chi si occupa di protezione dei dati.

La preoccupazione di un comitato rischi rispetto all'AI si riduce quasi sempre a tre domande precise. Vale la pena affrontarle una per una, perché formulate così hanno risposte verificabili.

"Può fare qualcosa che non dovrebbe?" No, e non per una policy ma per costruzione: un'azione non dichiarata come possibile per quell'utente in quel momento non ha un percorso di esecuzione. Il piano non compila. Questo è dimostrabile in demo, tentando di far eseguire a un agente un'operazione fuori dai permessi di chi la chiede.

"Possiamo fermarla prima che accada?" Sì: le azioni classificate come sensibili richiedono conferma umana esplicita con il contenuto esatto visibile. Quali azioni siano sensibili lo decidete voi, e la classificazione è essa stessa un documento leggibile che il comitato può approvare.

"Possiamo ricostruire cosa è successo?" Sì: intento, piano compilato, strumenti invocati, decisioni e motivazioni restano registrati in un audit indipendente. La ricostruzione non richiede di interpretare log tecnici.

Quello che non si può promettere, e che va detto al comitato, è che il modello non sbagli a interpretare una richiesta. Può sbagliare. La garanzia è che un errore di interpretazione non possa tradursi in un'azione non permessa, e che diventi visibile nel momento della conferma. È una garanzia diversa e più debole di quanto qualcuno vorrebbe sentirsi dire, ed è l'unica onesta.