Articolo 12 dell'AI Act UE: perché ogni decisione finanziaria dell'IA deve registrare se stessa

Un supervisore chiama a marzo 2027 e fa una sola domanda: mostrami come l’IA è arrivata alla cifra di svalutazione contabilizzata a settembre scorso. Se la tua risposta è uno screenshot di una finestra di chat, hai un problema. Non di reputazione. Legale.

Questa è la realtà che l’articolo 12 dell’AI Act UE crea per qualsiasi funzione finanziaria che utilizzi un sistema di IA ad alto rischio. Il testo è breve e diretto. I sistemi di IA ad alto rischio “devono consentire tecnicamente la registrazione automatica degli eventi (log)” per l’intera durata di vita del sistema. Automatica, non manuale. Integrata nel sistema, non aggiunta come una cartella di PDF esportati che qualcuno si ricorda di salvare. Per un decennio, le tracce di audit nella finanza sono state una buona prassi che potevi implementare bene o male. La normativa le sposta nella colonna segnata obbligo.

Cosa richiede davvero l’articolo 12

Il testo conta, quindi leggilo come farebbe un revisore. Il sistema deve registrare da solo. Non puoi soddisfare il requisito chiedendo a un analista di prendere appunti, perché gli appunti sono selettivi ed è proprio la selettività che la normativa vuole evitare. La registrazione deve funzionare per l’intera durata di vita del sistema, dal giorno in cui va in produzione al giorno in cui viene dismesso, non solo per la versione corrente del modello.

E i log devono essere utili agli scopi specifici che la normativa indica. L’articolo 12 collega la registrazione a tre compiti: identificare situazioni in cui il sistema potrebbe presentare un rischio, supportare il monitoraggio post-commercializzazione e supportare gli obblighi di sorveglianza umana previsti altrove dalla legge. In parole semplici, il log non è una funzione decorativa. Esiste perché qualcuno possa tornare indietro, ricostruire cosa è successo e decidere se il sistema si è comportato correttamente.

Poi arriva la parte che i team finance saltano. L’articolo 19 stabilisce il periodo minimo di conservazione: i log devono essere conservati per un periodo adeguato alla finalità del sistema e “per almeno sei mesi”, salvo che la normativa sulla protezione dei dati o le regole di settore richiedano un periodo più lungo. Sei mesi sono il minimo, non l’obiettivo. E c’è una clausola scritta quasi direttamente per banche, assicurazioni ed enti regolamentati: i fornitori che sono istituti finanziari già soggetti a requisiti di governance interna ai sensi della normativa UE sui servizi finanziari devono conservare questi log dell’IA come parte della documentazione che già mantengono in base a quella normativa. La legge non offre alla finanza un regime separato e più leggero. Integra la registrazione dell’IA nella disciplina documentale su cui sei già sottoposto ad audit.

Perché un log di chat non è un audit trail

Ecco la trappola. Molti team presumono di essere conformi perché il loro strumento di IA conserva una cronologia della conversazione. Puoi scorrere in alto e vedere cosa hai chiesto e cosa ha risposto. Non è forse quello il log?

Non lo è, e questo divario è il punto centrale dell’articolo. Una cronologia di chat registra parole. L’articolo 12 riguarda la ricostruzione di decisioni. Sono cose diverse. Quando un’IA dice al tuo controller che l’EBITDA rettificato è sceso del 12% su base trimestrale, le domande legalmente rilevanti non sono nella chat. Quali cifre sorgente ha estratto? Da quale sistema, in quale versione, al momento di quale chiusura? Quale calcolo ha prodotto il 12%? Ha eseguito lei stessa quel calcolo o ha chiamato un motore deterministico? Se rieseguissi oggi la stessa richiesta, otterresti la stessa risposta?

Una trascrizione di conversazione non risponde a nulla di tutto ciò. Peggio ancora, se l’IA ha calcolato internamente la percentuale, la trascrizione è attivamente fuorviante, perché il numero che ti mostra potrebbe non essere affatto riproducibile. Abbiamo già scritto della classe nascosta di errori in cui il modello ottiene le cifre giuste ma la matematica sbagliata: rapporti invertiti, confusione tra valori assoluti e percentuali, errori di segno sui flussi di cassa. Un log di chat conserva la risposta sbagliata con perfetta fedeltà e non ti dice nulla sul perché sia sbagliata.

Quello che l’articolo 12 chiede davvero è la tracciabilità (lineage). Non “l’IA ha detto X” ma “l’IA ha visto questi input, ha applicato questa operazione, ha prodotto questo output, ed ecco il percorso dalla fonte alla cifra”. Questo è un artefatto strutturalmente diverso, e la maggior parte degli strumenti finance basati su LLM non lo produce.

L’architettura decide se puoi essere conforme

È qui che la normativa smette di essere un problema di policy e diventa un problema di ingegneria. Non puoi registrare ciò che il tuo sistema non ha mai saputo. Se un LLM legge un PDF, tiene alcuni numeri nella sua finestra di contesto ed emette una risposta in un unico passaggio indifferenziato, non c’è un evento pulito da registrare. Il ragionamento e l’aritmetica sono intrecciati dentro un modello probabilistico, e ottieni una frase plausibile, non una decisione ricostruibile.

La via d’uscita è separare i livelli. Collega i sistemi sorgente, il tuo libro mastro, il tuo ERP, la tua piattaforma contabile, e riconciliali in un unico modello che quadra con i libri. Lascia che l’IA recuperi le cifre da quel modello riconciliato invece di rileggere ogni volta i documenti grezzi. Instrada ogni calcolo attraverso un motore deterministico invece del modello linguistico, così la matematica è identica a ogni esecuzione. Ora ciascuno di questi passaggi è un evento discreto e registrabile. Il recupero ha una fonte e un timestamp. Il calcolo ha input nominati e una formula definita. L’output ripercorre entrambi.

Quando l’architettura funziona così, la conformità all’articolo 12 è quasi automatica, perché il sistema è stato costruito fin dall’inizio per registrare decisioni. Il log non è una funzione che ti sei ricordato di attivare. È un sottoprodotto di come vengono prodotti i numeri. Stessi input, stessi output, percorso completo: esattamente ciò che un revisore intende per replicabile.

Vale la pena fare una concessione, perché gli scettici la meritano. Nulla di tutto ciò rende l’IA di per sé più veritiera. Un livello riconciliato e deterministico con registrazione completa può comunque presentare una cifra che poi si rivela basata su un’assunzione sorgente errata. Ciò che cambia è la tua posizione quando questo accade. Invece di alzare le spalle davanti a un supervisore, puoi mostrare l’input, la versione, il calcolo e il momento in cui la cifra è stata generata. Puoi dimostrare cosa ha fatto il sistema. La normativa non richiede che l’IA sia infallibile. Richiede che l’IA sia responsabile, e la responsabilità è una scelta architetturale.

Cosa significa prima che scattino le scadenze

Il calendario si sta muovendo, e gli obblighi per l’alto rischio sono slittati, ma la direzione non è cambiata. Qualunque siano le date finali di applicazione, il livello fissato dall’articolo 12, registrazione automatica, conservazione di almeno sei mesi, log dell’IA integrati nella documentazione dei servizi finanziari che già mantieni, non si allenterà. È il tipo di requisito facile da ignorare fino a un audit, e molto costoso da recuperare a posteriori una volta che hai un anno di decisioni IA non registrate in produzione.

Il test onesto è semplice. Scegli un numero qualsiasi che un’IA ha presentato al tuo team finance nell’ultimo trimestre. Puoi ricostruire, oggi, esattamente come è stato prodotto, fonte, versione, calcolo, timestamp, senza chiedere al modello di indovinare a posteriori? Se sì, sei quasi arrivato all’articolo 12. Se no, non hai una lacuna documentale. Hai una lacuna architetturale, e la lacuna documentale ne è solo il sintomo.

Se vuoi vedere come appare in pratica un audit trail ricostruibile dietro ogni cifra, prenota una demo e porta la tua domanda più difficile del tipo “dimostra questo numero”. È quella a cui vale la pena rispondere prima che sia un regolatore a chiedertelo.