Servizi finanziari

Il responsabile acquisti nei servizi finanziari che intraprende un progetto di IA nel 2026 non si chiede se implementare gli LLM. La LLM Suite di JPMorgan raggiunge già circa 230,000 to 250,000 dipendenti attraverso circa 450 casi d'uso in produzione, con l'obiettivo di arrivare a 1,000 entro la fine dell'anno; Goldman Sachs, Morgan Stanley, BBVA, Citi, HSBC e la maggior parte delle banche tier-1 hanno sviluppato le proprie soluzioni. La vera domanda è come far superare a un sistema di IA in produzione la validazione del rischio di modello, i test sul fair lending, la verifica di terze parti DORA e l'esame di vigilanza FINRA, mantenendolo al contempo pienamente utilizzabile a livello operativo.

Cosa costruiamo e gli artefatti rilasciati a corredo

Il nostro approccio consiste nel creare sistemi di IA su misura per banche, desk dei mercati dei capitali, asset e wealth manager, infrastrutture fintech e di pagamento e le funzioni trasversali di rischio e tesoreria sovraordinate — ciascuno strutturato affinché gli artefatti effettivamente richiesti dalle autorità di regolamentazione vengano prodotti insieme al sistema, anziché aggiunti a posteriori quando una demo deve giustificare la conformità burocratica:

• Pacchetti di validazione del modello progettati per soddisfare l'"effective challenge" ai sensi di SR 11-7 e OCC 2011-12 anche quando il modello conta 70 billion di parametri.
• Pipeline di conservazione che trattano prompt e output degli LLM come comunicazioni aziendali ai sensi della FINRA SEA Rule 17a-4, con esportazione in formato WORM verso qualsiasi archivio di conformità già in uso presso l'istituto.
• Harness di test per il fair lending in grado di superare una verifica CFPB in materia di impatto disparato ai sensi di ECOA (dettagliato nella nostra ricerca sulla crisi di responsabilità nel fair lending).
• Log decisionali che un audit di gestione delle modifiche conforme a Reg SCI possa esaminare senza alcuna ambiguità.

A quali normative sull'IA deve conformarsi un sistema finanziario nel 2026?

Cinque regimi normativi gravano oggi contemporaneamente su qualsiasi implementazione in produzione. Progettiamo in funzione di questo stack in continua evoluzione, non secondo un manuale del 2021.

Come impedire che un CFO deepfake autorizzi un bonifico?

Un dipendente di Arup a Hong Kong ha trasferito circa US$25 million nel febbraio 2024 a seguito di una videochiamata deepfake in cui venivano impersonati il CFO e altri dirigenti. Lo stack antifrode di tesoreria esistente, basato su regole NICE Actimize e su rilevamenti di liveness del 2022, non lo ha intercettato.

Il nostro approccio consiste nel creare sistemi di verifica in tempo reale dell'autenticità di voce e video integrati nel flusso di approvazione dei bonifici di tesoreria, con controlli deterministici sui trasferimenti di valore elevato — affinché il rischio deepfake non dipenda da un analista sotto stress che tenta di riconoscere un volto sintetico durante una chiamata Zoom (dettagliato nella nostra ricerca sulla violazione deepfake di Arup).

È possibile validare un LLM da 70 billion di parametri ai sensi di SR 11-7?

L'"effective challenge" ai sensi di SR 11-7 presuppone che un validatore possa interrogare i meccanismi interni del modello; un LLM da 70 billion di parametri vanifica tale presupposto per progettazione. Le banche stanno reagendo in tre modalità incompatibili, nessuna delle quali supera brillantemente un esame ispettivo:

• Alcune banche frenano l'implementazione.
• Altre banche aumentano le assunzioni nell'MRM di validatori con competenze di ML — un mercato che non offre volumi sufficienti.
• Altre ancora tacitamente si affidano alle dichiarazioni dei fornitori.

Il nostro approccio rende il livello di vincoli deterministici — basato su un knowledge graph ancorato al dominio — la componente validata, producendo percorsi decisionali che un validatore può verificare direttamente, senza dover esaminare i pesi dei tensori.

Il modello generativo opera dietro tale livello come input circoscritto e non autorevole — vincolato nelle azioni consentite, continuamente monitorato e verificato nei risultati rispetto all'harness di valutazione — anziché essere trattato come modello validato a pieno titolo. Il pacchetto di documentazione (inventario, data lineage, harness di valutazione, monitoraggio delle prestazioni) viene prodotto nel medesimo formato già utilizzato dai team MRM per i modelli classici, rendendo le evidenze perfettamente comprensibili nella verifica di effective challenge applicata durante un esame orizzontale.

Ogni comparto poggia su una diversa dorsale normativa

Mercati dei capitali, asset management e retail banking condividono lo stesso problema architetturale, ma ciascuno poggia su una diversa dorsale normativa; pertanto sviluppiamo in funzione della dorsale specifica, non di un modello generico per "IA nei servizi finanziari". Individuate il vostro ambito e l'obbligo a cui lo sviluppo deve conformarsi:

In cosa differisce da piattaforme, Big 4 e fornitori specializzati

Ciascuna categoria di fornitori risolve una parte del problema; nessuna ricompone l'intero stack. Questa integrazione rappresenta il fulcro del nostro lavoro — la differenza tra un sistema concepito per superare l'esame di un comitato rischi e uno che rimane bloccato in una sandbox.

L'intero stack comprende ontologia di dominio, retrieval ancorato con provenienza dei dati, applicazione deterministica dei vincoli, presidi human-in-the-loop ove sussistano rischi fiduciari o di tutela dei consumatori, log decisionali difendibili dinanzi ai regolatori, valutazione continua e un'architettura immune dai rischi di concentrazione verso terze parti.