Prompt Injection e Bias di Retrieval: I Rischi che SR 11-7 Non Ha Mai Coperto

SR 11-7 è stato scritto nel 2011, dodici anni prima che chiunque nella finanza digitasse una domanda in ChatGPT e ricevesse indietro un numero che sembrava una risposta. Le linee guida della Fed e dell’OCC che hanno definito la gestione del rischio modello per una generazione presupponevano che un modello fosse una cosa che si costruiva, si documentava e si validava rispetto a dati tenuti da parte. Aveva input, equazioni e output riproducibili. Esegui gli stessi dati due volte, ottieni lo stesso risultato. Questa premessa ha retto per gli scorecard creditizi, i motori VaR e i modelli di pricing per oltre un decennio.

Non regge per un modello linguistico di grandi dimensioni. E il divario tra ciò che SR 11-7 è stato costruito per governare e ciò che un LLM fa davvero è dove vivono i nuovi fallimenti.

Tre fallimenti che il vecchio framework non ha mai dovuto nominare

Il rischio modello classico ha sempre avuto due grandi categorie: il modello è fondamentalmente sbagliato, oppure il modello viene usato in modo scorretto. Queste si applicano ancora. Ma un LLM collegato a un flusso di lavoro finanziario introduce tre modalità di fallimento che non hanno un analogo pulito in un manuale di validazione del 2011.

Allucinazione. Un modello tradizionale privo di dati restituisce un errore o un valore nullo. Un LLM, di fronte a un vuoto, produce comunque un numero sicuro di sé, fluente, plausibile. La Top 10 2025 di OWASP per le applicazioni LLM lo elenca come Disinformazione (LLM09) ed è schietta al riguardo: l’output suona autorevole indipendentemente dal fatto che sia radicato in qualcosa di reale. In un modello di credito, un campo mancante genera un’eccezione. In un LLM, un campo mancante viene silenziosamente riempito con un’invenzione.

Prompt injection. Questo è il fallimento che smonta le intuizioni più consolidate. OWASP classifica il prompt injection come il rischio LLM numero uno (LLM01), e la variante pericolosa è l’injection indiretta: istruzioni nascoste dentro i dati che il modello legge, non nella domanda che l’utente pone. Un modello non è un artefatto statico che si valida una volta sola. È un interprete che prende istruzioni da qualunque testo lo raggiunga, inclusa una nota a piè di pagina in un PDF caricato, un commento in un foglio di calcolo, o un campo di descrizione estratto dal tuo ERP. Il dato è la superficie d’attacco.

Bias di retrieval. La maggior parte dei sistemi LLM finanziari usa la generazione aumentata da retrieval: recupera documenti rilevanti, li consegna al modello, gli chiede di rispondere. La qualità della risposta è ostaggio di ciò che il retriever ha portato in superficie. OWASP definisce le debolezze sottostanti come Vector and Embedding Weaknesses (LLM08). Se il retriever recupera la presentazione del trimestre scorso invece di quella corrente, o restituisce tre note di analisti rialziste e zero cautelative, il modello ragiona fedelmente su un campione distorto e produce una conclusione sicura di sé, sbagliata, dall’aspetto difendibile. Nessuno ha iniettato nulla. Il bias sta in ciò che è stato recuperato.

Nessuno di questi è «il modello è mal calibrato». Non sono problemi che si colgono facendo backtesting su un set di controllo. È esattamente per questo che un framework di validazione progettato per gli scorecard non li vede arrivare.

Ogni fallimento si traduce in un controllo. Non in una clausola di esclusione di responsabilità.

La risposta pigra è un banner che recita «l’IA può commettere errori». Non è un controllo. È un trasferimento di responsabilità al lettore. Ciascuno di questi tre fallimenti si traduce in qualcosa di concreto che puoi costruire, e la forma della soluzione è la stessa in ogni caso: smettere di lasciare che il modello linguistico tocchi le parti del flusso di lavoro dove non ha alcun titolo per essere considerato attendibile.

Per l’allucinazione, il controllo è vietare al modello di produrre cifre. Il compito dell’LLM è capire la domanda e instradarla; i numeri provengono da un sistema di registrazione. Se la cifra non esiste nei dati sottostanti, l’output corretto è «non disponibile», restituito dallo strato dati, non un’ipotesi fluente sintetizzata dal modello. Questo si applica separando il recupero di un valore dalla generazione del linguaggio che ne parla.

Per il prompt injection, il controllo è l’isolamento tra ciò che il modello legge e ciò che il modello può fare. Tratta tutto il contenuto recuperato come input non attendibile, allo stesso modo in cui un’applicazione web tratta i dati inseriti da un utente in un modulo. Il testo estratto da un documento può informare una risposta, ma non deve mai poter cambiare quale calcolo viene eseguito o su quale conto viene eseguito. L’insieme di istruzioni è fissato dal tuo codice, non negoziabile da qualcosa scritto in una fattura di un fornitore.

Per il bias di retrieval, il controllo è tracciabilità più determinismo. Ogni cifra che un’IA presenta dovrebbe portare una citazione a una specifica riga sorgente in un modello riconciliato, in modo che chi revisiona possa verificare non solo il numero ma il campione da cui proviene. E i calcoli sopra a quelle cifre, tassi di crescita, margini, runway, covenant ratio, dovrebbero passare attraverso un motore deterministico che produce sempre la stessa risposta, non attraverso una previsione a token che produce una risposta diversa a seconda della formulazione.

La mossa architetturale: retrieval e calcolo sono lavori diversi

L’idea unica sotto a tutti e tre i controlli è la separazione. Il retrieval è un problema di ricerca. Il calcolo è un problema matematico. Il linguaggio è un problema di presentazione. SR 11-7 non ha mai dovuto distinguere questi aspetti perché i vecchi modelli facevano tutti e tre in modo deterministico. Gli LLM li collassano in un unico blob probabilistico, ed è proprio in quel collasso che si concentra il rischio.

Questo è il principio di progettazione su cui è costruito Rexfin. Collega le tue piattaforme di contabilità e dati finanziari, QuickBooks, Xero, NetSuite, Sage, SAP, Oracle, un data warehouse, oppure carica direttamente i bilanci, e la piattaforma costruisce un unico modello finanziario riconciliato che quadra con la contabilità generale. Quel modello è l’unica fonte di verità. Quando l’IA pone una domanda, recupera le cifre da quel modello anziché inventarle. Il calcolo passa attraverso un motore deterministico, non l’LLM, quindi la stessa domanda restituisce sempre lo stesso numero. E ogni output si ricollega a una riga sorgente, il che trasforma una risposta sicura di sé in una verificabile.

Detto in modo concreto: un’istruzione iniettata tramite prompt injection nascosta in un PDF caricato non può riscrivere il calcolo di un covenant, perché il calcolo è codice, non un suggerimento che il modello è libero di seguire. Un retrieval distorto non può gonfiare silenziosamente un tasso di crescita, perché il tasso viene calcolato in modo deterministico a partire da cifre riconciliate e la citazione mostra esattamente quali cifre. Un numero allucinato non può raggiungere una presentazione al consiglio, perché il modello non è la cosa che produce i numeri.

Cosa non risolve

L’onestà sui limiti fa parte del controllo. Isolare il calcolo dal retrieval non rende il tuo retrieval perfetto; se il modello riconciliato è sbagliato, la risposta tracciabile è tracciabilmente sbagliata, il che è comunque meglio di essere sbagliata in silenzio ma non è la stessa cosa di essere giusta. Il determinismo non convalida i dati sottostanti, semplicemente impedisce al modello di aggiungere nuovi errori sopra. E nessuna architettura elimina la necessità della revisione umana per le decisioni rilevanti. Ciò che fa è ridurre il raggio d’azione dell’LLM da «qualunque cosa dica è una potenziale cifra finanziaria» a «aiuta a trovare e formulare numeri che un sistema deterministico ha già garantito». È una superficie molto più piccola da governare, e molto più facile da validare.

Un CFO scettico non dovrebbe accettare «l’IA è attenta». Attenta non è un controllo. La domanda da porre a qualsiasi strumento IA per la finanza è più stretta e più difficile: cosa impedisce, meccanicamente, che un numero inventato dal modello, o un numero che un documento avvelenato gli ha detto di produrre, raggiunga una decisione? Se la risposta è un punteggio di fiducia o una clausola di esclusione di responsabilità, la risposta è nulla.

Per il quadro più ampio di come questi controlli si integrano, vedi il pilastro della governance IA per la finanza, l’architettura di riferimento per uno stack di controllo IA, e perché validare gli LLM dei fornitori deve avvenire sull’output, non sui pesi.

Se vuoi vedere retrieval, calcolo deterministico e tracciabilità end-to-end funzionare sulla tua contabilità generale, prenota una demo e porta un numero di cui hai avuto paura a fidarti.