I framework per agenti già pronti non sono sufficienti per il settore bancario. Sì, è proprio da questo che partirei, e no, né una strategia di prompt più chiara né un gateway API più rigoroso cambiano questa realtà.
Uno stack standard composto da LangChain, strumenti, un database vettoriale e un gateway API è in grado di rendere un agente pienamente operativo. Può instradare un intento, recuperare il contesto, richiamare uno strumento e restituire una risposta ben strutturata. Va bene. Ma il settore bancario non fallisce al livello della semplice domanda: “È in grado di richiamare l’API?”. Il settore bancario fallisce proprio a livello di: “Questa chiamata è stata autorizzata, circoscritta, verificata, registrata e può essere tranquillamente mostrata a questo cliente?”. Questo è un problema di architettura di altro tipo.
Ci sono tre motivi per cui non utilizzerei uno stack di agenti generico in prossimità dei flussi di lavoro bancari di produzione senza aggiungere un livello di fiducia dedicato.
Innanzitutto, i dati finanziari sono dati relativi alle passività. Una risposta errata fornita da un chatbot nel settore della vendita al dettaglio è imbarazzante. Un saldo, lo stato di una transazione, la spiegazione delle commissioni o una decisione di credito errati possono comportare rischi legali. Ai sensi del Obblighi della FCA nei confronti dei consumatori, ad esempio, l’istituto deve dimostrare che i clienti ricevano un’assistenza equa, comprensibile e adeguata. Se il modello propone un’opzione di rimborso o spiega un prodotto in modo errato, non è possibile scrollarsi di dosso la responsabilità e dare la colpa all“”IA”. La banca è responsabile dei risultati. Pertanto, l’architettura deve considerare ogni affermazione fattuale come un elemento da verificare rispetto a un sistema di riferimento.
In secondo luogo, il multi-tenancy non è solo una scelta di progettazione del prodotto. Se si gestiscono diversi clienti bancari, esercenti, unità aziendali o regioni da un’unica piattaforma, l’isolamento dei tenant deve essere garantito a ogni livello: prompt, memoria, indici vettoriali, autorizzazioni degli strumenti, log, chiavi Redis, righe del database, segreti ed esportazioni di audit. Una singola fuga di dati tra tenant non è un semplice ticket di bug. Può essere un incidente da segnalare. Ecco perché non mi piacciono le architetture in cui l’agente dispone di un accesso esteso e il livello applicativo si “ricorda” di filtrare i dati in un secondo momento. È proprio il filtraggio a posteriori che causa le fughe di dati.
In terzo luogo, l’LLM è l’elemento meno affidabile della catena. Può sembrare un’affermazione severa, ma è l’ipotesi corretta. Il modello è probabilistico. Può seguire istruzioni dannose, riporre eccessiva fiducia nel contesto recuperato o divulgare informazioni personali identificative (PII) in un riepilogo. Può generare una chiamata a uno strumento che sembra valida finché non si esaminano i parametri. Pertanto, non permetterei mai che il modello fosse collegato direttamente alle API bancarie principali.
L'approccio più sicuro consiste nel lasciare che sia il modello a ragionare, mantenendo però l'applicazione delle regole all'interno di sistemi deterministici. Il ragionamento appartiene al livello dell’agente. L’applicazione delle regole appartiene ai validatori di schemi, ai controlli delle politiche, alle autorizzazioni a livello di tenant, ai controlli di approvazione e ai registri di audit. Una volta effettuata questa separazione, l’architettura smette di essere una catena di chiamate API guidate dal modello e diventa un sistema di fiducia controllato, in cui l’LLM viene trattato come una componente di ragionamento utile ma inaffidabile.
Un certo modo di inquadrare la questione rende più facile applicare questa distinzione. Quando osservo un agente bancario, la domanda che mi interessa è: quanta autorità detiene e quanto deve allontanarsi tale autorità dalla persona che gliel’ha concessa? La capacità indica la qualità della demo. L’autorità determina quanto controllo il sistema è autorizzato a esercitare. Un modello brillante collegato a strumenti di sola lettura è un assistente leggero. Un modello poco brillante dotato di una chiave permanente che permette di trasferire fondi rappresenta un problema diverso e necessita di tutti i livelli sottostanti. Nell’articolo ho suddiviso quell’asse dell’autorità in quattro classi: assistente, orchestratore, operatore e attore economico. Non tutti gli agenti sono soggetti economici.
Assumeteci
Chi siamo