Le tre linee di difesa per l'IA: chi possiede i numeri quando il modello è l'autore

Un controller firma il pacchetto trimestrale. Quella firma ha sempre significato qualcosa di specifico: possiedo questi numeri, posso difendere ogni riga e so da dove viene ciascuna di esse. Ora un agente ha redatto il commento sugli scostamenti, ha prelevato le cifre e ha calcolato i rapporti. Il controller firma comunque. Ma chi possiede davvero il numero?

Questa è la domanda a cui il modello delle tre linee di difesa non è mai stato costruito per rispondere, ed è quella che tiene svegli i comitati rischio nella notte, in vista del 2026.

Un framework che presupponeva un autore umano

Il modello a tre linee è la spina dorsale della governance nei servizi finanziari. L’Institute of Internal Auditors lo ha formalizzato nel 2013 e aggiornato nel 2020, e la struttura è abbastanza semplice da recitare a memoria. La prima linea possiede e gestisce il rischio nel business. La seconda linea, rischio e compliance, inquadra, supervisiona e mette in discussione. La terza linea, l’audit interno, fornisce assicurazione indipendente che le prime due stiano facendo il loro lavoro.

Funziona grazie a un’assunzione non dichiarata: una persona ha creato il numero. Quando un analista finanziario costruisce un forecast, puoi chiedergli perché ha assunto un churn del 4%. Quando il team FP&A calcola l’EBITDA rettificato, puoi risalire alla formula in un foglio che qualcuno ha scritto. La responsabilità confluisce in un nome.

Un LLM spezza quella catena. Il modello è ora, di fatto, l’autore dell’output. Ha selezionato le cifre, applicato il ragionamento e prodotto il commento. Non può possedere nulla. Non può essere messo in discussione in una riunione, non ricorda perché ha scelto un’assunzione rispetto a un’altra tra un’esecuzione e l’altra, e produrrà una risposta leggermente diversa martedì prossimo se gli lasci fare la matematica. Inserisci un autore non deterministico in un framework che presupponeva un autore umano, e le linee si sfumano esattamente dove devono essere più nitide.

Dove ogni linea fallisce davvero

Ripercorri le tre linee con un agente nel ciclo e le crepe emergono in fretta.

La prima linea doveva possedere le assunzioni. Quando un pianificatore imposta un tasso di crescita, la proprietà è ovvia. Quando un agente deduce un tasso di crescita dai periodi precedenti e lo fa emergere dentro un forecast, chi possiede quell’assunzione? L’utente business che ha accettato l’output senza vedere l’assunzione? Il team dati che ha collegato l’integrazione? Nessuno, di solito, ed è questo il problema. L’assunzione viene rivendicata solo dopo che si è rivelata sbagliata.

La seconda linea doveva validare. Validare cosa? Il playbook classico validava un modello che potevi aprire e ispezionare. Non puoi ispezionare i pesi di un LLM di terze parti, e anche se potessi, la validazione del trimestre scorso ti dice poco sull’output di questo trimestre perché lo stesso prompt può produrre un numero diverso. La validazione deve spostarsi dal modello all’output: cosa ha recuperato il sistema, cosa ha calcolato, e questo torna con il libro mastro?

La terza linea doveva verificare il percorso. Con una persona, il percorso è il workpaper. Con un agente che risponde in linguaggio naturale su PDF e fogli di calcolo, spesso non c’è alcun percorso. L’agente ha detto che il ricavo è cresciuto del 18%. Da quale fonte? Calcolato come? Un revisore che non può ripercorrere il numero non può assicurarlo, e “lo ha detto l’IA” non è una posizione di audit che qualcuno firmerà.

La soluzione è architetturale, non un nuovo memo di policy

Puoi riscrivere quanto vuoi la matrice RACI. Se il sistema sottostante non riesce a dirti da dove viene un numero e come è stato calcolato, le tre linee non hanno nulla da difendere. La riassegnazione della proprietà tiene solo quando l’architettura rende la proprietà osservabile.

Questo significa che tre cose devono essere vere prima che il modello di governance possa reggere:

• Ogni cifra risale alla fonte. Non “il modello ha riassunto il 10-K”, ma questo numero equivale a questa riga nel libro mastro, con una lineage che puoi seguire cliccando. La tracciabilità è ciò che permette alla prima linea di possedere un’assunzione invece di scoprirla dopo.
• La matematica è deterministica e ripetibile. Gli stessi input producono la stessa cifra ogni volta, calcolata da un motore anziché prevista dal modello linguistico. Questo dà alla seconda linea qualcosa di stabile da validare e alla terza linea qualcosa da ripercorrere.
• Il ragionamento e l’aritmetica sono separati. All’LLM è permesso ragionare, formulare e spiegare. Non gli è permesso fare il calcolo. Nel momento in cui il modello calcola il rapporto, gli hai consegnato la paternità di un numero che nessuno può difendere.

Questo è il design attorno a cui Rexfin è costruita. Si connette alle tue piattaforme contabili e di dati finanziari (QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, il tuo data warehouse) o a estratti conto caricati, e costruisce un unico modello finanziario riconciliato che torna con il libro mastro. L’IA recupera le cifre da quel modello ed esegue ogni calcolo tramite un motore deterministico, non l’LLM. Gli scenari what-if vivono in versioni sopra la base riconciliata, mai nella base stessa. Ogni risposta porta con sé la propria lineage fino alla fonte.

Metti questo sotto le tre linee e le domande sulla proprietà tornano ad avere risposte. La prima linea possiede le assunzioni perché le assunzioni sono esplicite e visibili, non sepolte nel ragionamento nascosto di un modello. La seconda linea valida gli output rispetto a una verità di base riconciliata invece di scrutare pesi che non può vedere. La terza linea ripercorre qualsiasi numero come farebbe con una formula da ricontrollare, perché la cifra è stata prodotta in modo deterministico e porta con sé il proprio percorso.

Cosa questo non risolve

L’architettura non assolve nessuno. Uno strato riconciliato e tracciabile rende la proprietà possibile; non la assegna. Devi comunque decidere quale persona possiede ciascuna assunzione, chi firma la cadenza di validazione e cosa può fare l’agente senza supervisione rispetto a cosa richiede una persona nel ciclo. Sono decisioni di governance, e appartengono al tuo comitato rischio, non al tuo fornitore. Ciò che lo strato cambia è se quelle decisioni sono applicabili o solo aspirazionali.

Non renderà neanche buona un’assunzione sbagliata. Se il tasso di crescita è sbagliato, la matematica deterministica calcolerà perfettamente il forecast sbagliato, ogni volta. Il punto della tracciabilità non è la correttezza, è la responsabilità. Puoi trovare l’assunzione sbagliata, vedere chi la possiede e correggerla prima che arrivi al board.

Il punto chiave

Le tre linee di difesa funzionano ancora per l’IA in finanza, ma solo dopo aver accettato che il modello è l’autore e aver ricostruito le fondamenta in modo che la paternità possa risalire a una persona. La proprietà delle assunzioni, la validazione degli output e l’audit del percorso convergono tutti sullo stesso requisito: uno strato di numeri riconciliato dove ogni cifra risale alla fonte e ogni calcolo è deterministico. Fallo bene e il framework regge. Saltalo, e stai firmando numeri che nessuno può difendere.

Vale la pena leggere in seguito come cambia la validazione quando non puoi vedere i pesi: validazione basata sull’output per LLM di terze parti, e lo spostamento più ampio nel framework di model risk 2026. L’intero pillar sulla governance dell’IA in finanza si trova un livello sopra.

Se vuoi vedere numeri tracciabili e deterministici sotto le tue stesse tre linee, prenota una demo e porta una cifra che al momento non riesci a dimostrare.