Perché i finance agent devono chiamare strumenti, non calcolare

Chiedete a un large language model di sommare due numeri a nove cifre e spesso restituirà qualcosa che sembra esattamente giusto ed è sbagliato di qualche migliaio. Le cifre sono plausibili. L’ordine di grandezza è corretto. La risposta è sbagliata. Questo singolo comportamento è il motivo per cui la maggior parte delle demo di “IA per la finanza” crolla nel momento in cui un controller verifica i conti.

Ecco il meccanismo scomodo. Un LLM non esegue l’aritmetica. Predice il token successivo. Quando chiedete quanto fa 14.820.116 meno 9.335.402, il modello non sta sottraendo; sta generando la sequenza di cifre statisticamente più probabile in base a tutto ciò che ha assorbito durante l’addestramento, dato il vostro prompt. Per somme piccole e comuni ha effettivamente memorizzato gli schemi e le indovina correttamente. Per le cifre lunghe e irregolari che riempiono un vero libro mastro generale, sta indovinando una forma. A volte l’ipotesi va a segno. Non avete modo di sapere quando, solo dall’output, perché un numero sbagliato detto con sicurezza si legge in modo identico a uno giusto detto con la stessa sicurezza.

Il numero sembra giusto, ed è questo il problema

Questo è peggio dei normali bug software perché la modalità di fallimento è un mimetismo. Una formula rotta in un foglio di calcolo di solito genera #REF! o un totale palesemente impossibile. Un modello linguistico produce una cifra che si colloca comodamente nell’intervallo che un CFO si aspetterebbe. Un fatturato che dovrebbe essere 47,3 milioni torna come 46,9 milioni. Un margine lordo che dovrebbe quadrare al 62% torna al 64%. Niente grida allarme. L’errore sopravvive alla revisione proprio perché è stato generato per sembrare la verità.

I benchmark lo confermano. Su FinanceBench, una suite di test composta da terzine domanda-risposta-evidenza tratte da comunicazioni pubbliche societarie, GPT-4-Turbo abbinato a un sistema di retrieval ha risposto correttamente o tentato solo una minoranza di domande, sbagliando o rifiutandone circa quattro su cinque nella valutazione originale. Anche quando gli viene fornito esattamente il documento contenente la risposta, l’accuratezza sulle domande relative ai bilanci è stata riportata tra un livello basso e uno superiore all’ottanta per cento a seconda della formulazione e della posizione del contesto. Gli stack specializzati più recenti spingono molto più in alto, ma la variabilità stessa è il segnale d’allarme. Un sistema la cui accuratezza oscilla di quaranta punti a seconda di dove mettete la domanda nel prompt non è qualcosa su cui costruire un numero da presentare al consiglio.

Nulla di tutto ciò significa che il modello sia inutile. Significa che gli avete chiesto di fare l’unica cosa che strutturalmente non può garantire.

Ragionamento nel modello, matematica nello strato

La soluzione non è un prompt migliore o un modello più grande. È una divisione del lavoro.

I modelli linguistici sono genuinamente bravi nelle parti più soft del lavoro finanziario: capire che “burn” significa uscita netta di cassa, decidere che una domanda sulla “runway” richiede il saldo di cassa diviso per il burn mensile, notare che un utente probabilmente vuole la cifra da inizio anno piuttosto che trimestrale, e cucire una spiegazione in linguaggio semplice attorno al risultato. Questo è ragionamento, ed è lì che il modello si guadagna il suo posto.

Ciò che il modello non deve fare è la sottrazione, la divisione, la conversione valutaria, l’aggregazione dei periodi, o il rapporto. Quelli vanno a strumenti deterministici, codice vero che esegue la formula allo stesso modo ogni volta. Il compito del modello è scegliere lo strumento giusto, fornire gli argomenti giusti, e leggere il risultato. È esattamente ciò per cui è stato costruito il tool calling, o function calling: lasciate che la componente linguistica sia flessibile e che la componente computazionale sia esatta, e non confondete mai le due.

Detto chiaramente: l’agente dovrebbe ragionare su cosa calcolare e poi chiamare qualcos’altro per calcolarlo davvero. Quando un agente calcola un margine dentro la propria testa, state affidando i vostri conti verificati a una distribuzione di probabilità. Quando chiama uno strumento, state affidandovi all’aritmetica.

Perché una chiamata a uno strumento ha comunque bisogno di un modello riconciliato sotto

Il tool calling da solo non completa il lavoro, ed è qui che molte architetture del 2026 si fermano un passo troppo presto. Dare a un agente una funzione calculate_ratio() è necessario ma non sufficiente, perché la funzione è affidabile solo quanto i numeri che le fornite. Se l’agente estrae una cifra di fatturato da un sistema, una cifra di costo da un’esportazione obsoleta, e un numero di dipendenti da una slide, lo strumento calcolerà un rapporto perfettamente deterministico su input incoerenti. Il determinismo su dati cattivi vi dà solo una risposta sbagliata ripetibile.

Quindi gli strumenti devono operare su un unico modello riconciliato: un singolo modello finanziario che quadra con il registro contabile, dove ogni cifra ha una fonte nota e gli input concordano già tra loro. Questa è la parte che Rexfin tratta come fondamenta. Colleghiamo le vostre piattaforme contabili e di dati finanziari (QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, un data warehouse) o bilanci caricati, costruiamo un unico modello riconciliato che quadra con il registro contabile, e poi esponiamo strumenti di calcolo deterministici su di esso. L’agente ragiona; il motore deterministico calcola; ogni output risale alla fonte.

La sequenza conta. Collegare, riconciliare, poi lasciare che il motore faccia i calcoli: saltare il passaggio intermedio è il motivo per cui la maggior parte delle demo produce numeri che nessun controller firmerà. Percorriamo questo flusso in come funziona, e lo stesso principio è il motivo per cui MCP per la finanza non basta da solo: un accesso governato al vostro ERP dà al modello dati live, ma senza uno strato riconciliato e calcolo deterministico, l’LLM sta comunque facendo aritmetica probabilistica fragile su campi grezzi.

Cosa ottiene un CFO scettico

Tre cose, concretamente.

Primo, la ripercorribilità. La stessa domanda, posta due volte, restituisce lo stesso numero, perché la matematica è stata eseguita nel codice anziché in un campionatore. Potete dimostrare una cifra nello stesso modo in cui dimostrate una formula in un foglio di calcolo: rieseguendola.

Secondo, la tracciabilità. Poiché il calcolo è stato eseguito su un modello riconciliato, ogni output risale alle righe sorgente che lo hanno prodotto. Un revisore che chiede “da dove viene questo” ottiene una filiera, non una scrollata di spalle.

Terzo, un confine difendibile per l’autonomia. Una volta che la matematica esce dal modello, potete lasciare che gli agenti facciano di più senza restare svegli la notte a preoccuparvene. Questo è il presupposto per i livelli di autonomia che decidono quali flussi di lavoro un agente può gestire da solo, ed è ciò che rende l’autonomia governata più sicura che mettere un essere umano dentro ogni transazione. Non potete governare un agente i cui numeri non potete riprodurre.

La conclusione

Un LLM che calcola sta indovinando la forma di un numero. Un LLM che chiama uno strumento su un modello riconciliato sta chiedendo all’aritmetica di fare aritmetica e lasciando il linguaggio al linguaggio. Il primo sembra magico in una demo e fallisce in un audit. Il secondo è noioso, ed è esattamente ciò che volete sotto una presentazione al consiglio.

Se state valutando strumenti di finanza agentica, fate al fornitore una domanda: il modello calcola la cifra, o chiama qualcosa di deterministico che lo fa? Se non riescono a rispondere in modo netto, la matematica è un’ipotesi. Prenotate una demo e vi mostreremo la differenza sui vostri stessi numeri.