Costruire lo Stack di Controllo IA per i Dati Finanziari: un'Architettura di Riferimento
Un modello di controllo a cinque livelli per l'IA sui dati finanziari: qualità dei dati, calcolo deterministico, audit degli output, controllo degli accessi e logging immutabile.
Di The Rexfin team
Un controller chiede all’assistente IA il free cash flow dell’ultimo trimestre. Risponde in due secondi, sicuro, formattato, con un’aria di fonte verificata. Il numero è sbagliato del 4%. Nessuno se ne accorge perché non c’è nulla che lo possa intercettare. Il modello ha recuperato una cifra, ha fatto qualche calcolo a mente e ha stampato il risultato. Nessun secondo controllo, nessun ricalcolo, nessun log.
Questo è il vuoto con cui vengono lanciate la maggior parte delle implementazioni di “IA per la finanza”. Il modello va bene. Manca l’architettura attorno ad esso. Quando la domanda è se un CFO può presentare un numero generato dall’IA a un comitato di audit, la risposta dipende quasi interamente da ciò che si trova tra il modello linguistico e il libro mastro.
Questa è un’architettura di riferimento per quella zona intermedia. Pensatela come cinque livelli di controllo, ciascuno in grado di intercettare un errore diverso, impilati in modo che un numero non possa raggiungere una persona senza passare attraverso tutti e cinque.
Perché un singolo modello non è un controllo
Partiamo dal dato di benchmark scomodo. Sui compiti di foglio di calcolo finanziario, i modelli 2026 più forti si fermano intorno all’82% di accuratezza, all’incirca un errore ogni sei domande. Sul ragionamento finanziario multi-step più complesso, anche i modelli di frontiera si collocano tra l’80 e il 90%, e crollano sul ragionamento temporale e sugli scenari, che è esattamente la sostanza della finanza. Nessun modello linguistico autonomo raggiunge tassi di errore abbastanza bassi per un uso in produzione non supervisionato. Non è un problema di prompt risolvibile con l’ingegneria. È una proprietà del modo in cui questi sistemi generano testo.
Quindi l’obiettivo progettuale non è un modello migliore. È rendere irrilevante la capacità più debole del modello (fare i conti in modo affidabile) e circondare la sua capacità più forte (leggere e spiegare) con dei controlli. Ciascun livello seguente svolge un compito.
Livello 1: qualità dei dati alla frontiera
I dati sporchi in ingresso restano la causa dominante di risposte sbagliate, ed è l’aspetto meno affascinante da correggere. Prima che qualcosa raggiunga il modello, gli input devono essere riconciliati, non semplicemente presenti. Ciò significa che le cifre estratte da QuickBooks, Xero, NetSuite, Sage, un’istanza SAP o Oracle, un data warehouse o un estratto conto PDF caricato manualmente confluiscono tutte in un unico modello che quadra con il libro mastro generale. Conti mappati, periodi coerenti, infragruppo eliminato, un piano dei conti documentato.
Il controllo qui è la riconciliazione stessa: un controllo di quadratura che fallisce in modo evidente quando il modello assemblato non corrisponde al libro mastro fino al centesimo. Se il livello 1 non passa, nulla a valle viene eseguito. Un calcolo pulito su input sporchi è solo una risposta sbagliata detta con sicurezza. Questa base riconciliata è la parte che la maggior parte dei team salta, ed è il motivo per cui le loro demo crollano non appena arrivano dati reali, un punto che approfondiamo in perché un foglio di calcolo è la base sbagliata per l’IA in finanza.
Livello 2: calcolo deterministico
Questo è il livello portante. Il modello linguistico non calcola mai il free cash flow, non inverte mai un rapporto, non decide mai se una variazione è assoluta o percentuale. Identifica cosa sta chiedendo l’utente e quali cifre sono coinvolte, poi chiama un motore deterministico che esegue la formula effettiva sul modello riconciliato.
Stessi input, stesso output, ogni volta. Un controller può dimostrare il risultato nello stesso modo in cui dimostrerebbe una cella di foglio di calcolo: risalire agli operandi, verificare la formula, ricalcolare. L’aritmetica vive nel codice con una definizione fissa, non in una distribuzione di probabilità su token. Questo è l’unico cambiamento che porta da “solitamente corretto” a “corretto e dimostrabile”, ed è il motivo per cui il calcolo deterministico e riproducibile è diventato l’aspettativa che i revisori portano agli output dell’IA.
Livello 3: audit degli output
Anche con input puliti e matematica deterministica, serve un controllo tra il risultato del motore e l’utente. L’audit degli output è un insieme di regole eseguito su ogni risposta prima che venga mostrata: la cifra rientra in un intervallo plausibile, lo stato patrimoniale quadra, il segno ha senso per un’uscita di cassa, il ricavo di questo trimestre rientra in una fascia plausibile rispetto ai trimestri precedenti?
Non sono giudizi dell’IA. Sono gli stessi controlli di buon senso che un analista attento applica in modo automatico, codificati come asserzioni deterministiche. Quando uno fallisce, la risposta viene trattenuta e segnalata anziché rilasciata. I regolatori si aspettano sempre più esattamente questo tipo di validazione comportamentale, testare ciò che il sistema produce anziché limitarsi a ispezionare il modello, perché con un LLM di terze parti i pesi non sono comunque ispezionabili da voi. Trattiamo questo vincolo in validazione basata sull’output per LLM di fornitori terzi.
Livello 4: controllo degli accessi
Chi è autorizzato a chiedere, e cosa è autorizzato a vedere? Un’interfaccia IA che appiattisce i permessi è una violazione dei dati con una chat box. Il livello di controllo deve applicare le stesse restrizioni per entità, periodo e campo che applicano i sistemi sottostanti, e deve attribuire ogni interrogazione a un’identità umana reale, non a un account di servizio condiviso che rende inutile la tracciabilità.
Questo conta di più con l’IA rispetto a un report statico, perché l’interfaccia invita a domande aperte. Qualcuno in un team regionale che pone una domanda ampia non dovrebbe ricevere numeri a livello di gruppo solo perché il modello si è mostrato disponibile. Il controllo degli accessi si colloca sul percorso della query, non aggiunto in seguito.
Livello 5: logging immutabile
L’ultimo livello registra tutto ciò che hanno fatto gli altri quattro, in una forma che non può essere modificata silenziosamente. Per ogni risposta: chi ha chiesto, cosa è stato chiesto, quali dati sorgente e quale versione hanno alimentato il calcolo, quale formula è stata eseguita, cosa hanno restituito i controlli di audit dell’output e quale cifra è stata restituita. Solo in append, con timestamp, conservato.
Questo è ciò che trasforma un numero in un numero difendibile. Mesi dopo, quando un membro del consiglio mette in dubbio una cifra o un revisore chiede supporto, si riproduce la voce e si ottiene esattamente lo stesso risultato dagli stessi input esatti. Il log è anche il punto in cui convergono silenziosamente le aspettative regolamentari: i framework di model risk 2026 che hanno sostituito SR 11-7 puntano molto su tracciabilità e riproducibilità, e i requisiti di logging dell’EU AI Act vanno nella stessa direzione.
Come i livelli falliscono bene insieme
Il senso di impilarli è la difesa in profondità. Un valore sorgente sbagliato viene intercettato al livello 1. Un errore di ragionamento non accade mai perché il livello 2 ha rimosso il ragionamento dai calcoli. Un risultato fuori intervallo viene trattenuto al livello 3. Un utente che vede dati che non dovrebbe vedere viene fermato al livello 4. E se qualcosa va comunque storto, il livello 5 permette di scoprire con precisione cosa e quando.
È bene essere onesti sui limiti. Questa architettura non rende il modello linguistico accurato; rende la sua inaccuratezza non fatale. Non elimina la necessità di revisione umana sulle cifre rilevanti; rende quella revisione rapida e fondata invece che un atto di fede. E aggiunge latenza e costo di ingegneria: il motore deterministico, la riconciliazione, il logging sono lavoro vero. Il compromesso è che l’output ottenuto è uno che un controller firmerà davvero.
Vale la pena nominare una scorciatoia allettante: collegare un LLM al vostro ERP tramite un protocollo come MCP e considerarlo fatto. Questo dà al modello un accesso governato ai dati live, che è quasi il livello 4, ma lascia il modello a fare aritmetica fragile su campi grezzi del libro mastro, senza riconciliazione e senza calcolo deterministico. Il recupero dei dati non è la parte difficile. Sono i livelli intermedi.
La conclusione
Se dovete ricordare una sola cosa: il modello è il componente meno importante di un sistema IA finanziario affidabile. Il valore sta nella base riconciliata sottostante e nei controlli che la circondano. Costruite questi cinque livelli e l’IA potrà recuperare, spiegare e modellare scenari tutto il giorno, con ogni numero tracciabile fino alla fonte. Saltateli e avrete un modo veloce per generare errori pieni di sicurezza.
Rexfin è il livello che svolge questo lavoro: un modello riconciliato, un motore di calcolo deterministico e logging immutabile, con l’LLM mantenuto sul ragionamento e sul recupero dati, dove è forte. Se volete vedere una cifra tracciata da una risposta in un board deck fino alla voce del libro mastro che l’ha generata, prenotate una demo.
Parte di Governare l'AI in finanza: rischio modello, controlli e validazione nell'era degli LLM