FSB propone 12 pratiche di governance per l'IA nelle istituzioni finanziarie

Il 15 ottobre 2026, il Consiglio per la stabilità finanziaria (FSB) ha pubblicato il rapporto finale "Pratiche solide per l'adozione responsabile dell'intelligenza artificiale nelle istituzioni finanziarie", proponendo 12 pratiche di governance per le istituzioni finanziarie. Il rapporto copre vari aspetti come la strategia dell'IA, la valutazione dei rischi, la gestione dei dati, la supervisione umana, la sicurezza informatica e i servizi di terzi, rispondendo a una serie di problemi di gestione emersi negli ultimi anni a seguito dell'accelerazione nell'adozione dell'IA generativa e dell'IA agent.

La governance dell'IA nelle istituzioni finanziarie collega i responsabili aziendali, i team di rischio e i fornitori esterni.

Questo rapporto è stato finalizzato dopo una consultazione pubblica e fornisce un quadro pratico a livello internazionale, che le istituzioni possono adattare in base alle proprie attività e situazioni di rischio. Le istituzioni finanziarie devono comunque considerare le leggi e i requisiti normativi specifici della propria area.

Perché un insieme di pratiche deve coprire così tanti aspetti come il consiglio di amministrazione, i dati, i modelli e i fornitori? Può essere compreso attraverso un progetto comune: una banca sta preparando l'uso dell'IA per assistere nella gestione dei prestiti alle piccole imprese. Il team aziendale desidera ridurre i tempi di revisione, il team dei modelli è preoccupato per l'accuratezza dell'identificazione, il team di conformità si concentra sui dati dei clienti e sulla spiegazione delle decisioni, mentre il team operativo deve garantire che l'attività di prestito possa continuare anche se il fornitore smette di funzionare. Controllare solo le prestazioni del modello non può rispondere alle domande degli altri. Il rapporto del FSB cerca di far entrare queste decisioni in un unico processo di gestione.

1. Le 12 pratiche si estendono dalla governance istituzionale all'intero ciclo di vita dell'IA

Il FSB ha suddiviso le 12 pratiche in due gruppi. Le prime quattro si concentrano sulla governance a livello istituzionale, mentre le ultime otto coprono tutti gli aspetti dell'IA, dall'introduzione, allo sviluppo, al dispiegamento e all'uso continuato.

Le quattro pratiche di governance istituzionale iniziano a inserire responsabilità, registrazioni e aggiustamenti continui nel quadro di gestione.

La parte di governance istituzionale richiede innanzitutto che il consiglio di amministrazione e la direzione esecutiva considerino l'uso dell'IA in relazione al modello di business, alla propensione al rischio e alla strategia complessiva. Quando l'IA è coinvolta nella revisione del credito, nel servizio clienti, nel monitoraggio delle transazioni o nelle decisioni interne, la direzione deve comprendere dove viene utilizzata, quali funzioni svolge e quali impatti possono derivare da errori.

La seconda pratica sottolinea la divisione delle responsabilità. Le istituzioni devono chiarire quali responsabilità spettano ai team aziendali, tecnici, di rischio, di conformità e di audit, e integrare i rischi dell'IA nel quadro di gestione del rischio esistente. La terza pratica prosegue su questa linea, richiedendo di registrare il modo in cui viene utilizzata l'IA, la valutazione dei rischi e i controlli correlati.

Il valore della registrazione risiede nel fatto che, in caso di problemi, l'istituzione può ricostruire quali giudizi sono stati presi dal sistema, quali dati sono stati utilizzati, chi ha preso le decisioni e quali controlli erano già in atto. La quarta pratica ricorda alle istituzioni che l'ambiente tecnologico e aziendale può cambiare, e che la struttura di governance deve essere adeguatamente adattata.

Queste quattro pratiche determinano chi approva un progetto di IA, chi lo mantiene e chi ha il potere di fermarlo. Il consiglio di amministrazione non deve esaminare singolarmente i parametri del modello, ma deve essere a conoscenza delle importanti attività aziendali in cui l'IA è stata integrata, dei benefici attesi e del rischio che si è disposti a sostenere. La direzione poi traduce i requisiti generali nell'approvazione dei prodotti e nelle responsabilità lavorative. Ad esempio, il responsabile dell'attività di prestito decide a quale fase di approvazione può accedere il suggerimento dell'IA; il team di rischio del modello progetta i test; il personale di conformità verifica i diritti dei clienti; l'audit interno valuta se i controlli precedentemente menzionati siano effettivamente in atto. Se ci sono lacune tra i ruoli, è necessario designare un decisore finale prima del lancio.

La documentazione di cui parla il FSB non equivale a conservare un manuale del prodotto. Un caso d'uso deve almeno essere in grado di tracciare lo scopo aziendale, la fonte dei dati, la versione del modello, i risultati dei test, i punti di intervento umano, le dipendenze di terzi e le registrazioni delle modifiche significative. Se successivamente un cliente contesta il risultato dell'approvazione, l'istituzione può ricostruire il processo seguendo questi materiali. Lo stesso vale per il software per ufficio già acquistato: se un prodotto originariamente privo di IA aggiunge funzionalità di sintesi automatica o classificazione dei clienti, l'istituzione deve riconfermare il flusso e l'ambito dei dati in ingresso.

Le ultime otto pratiche partono da scenari di utilizzo specifici, coprendo l'importanza e la valutazione dei rischi dei casi d'uso dell'IA, la selezione di modelli e sistemi, la governance dei dati, l'interpretabilità e la trasparenza. Le pratiche successive riguardano anche le prestazioni del sistema, la supervisione umana, i rischi delle tecnologie dell'informazione e della comunicazione (ICT) e la dipendenza dall'IA di terzi.

Le 12 pratiche sono organizzate per temi di governance, con molte richieste che attraversano più fasi dell'uso dell'IA. Le istituzioni possono decidere la profondità delle misure di controllo in base alla propria dimensione, complessità aziendale, ruolo nel sistema finanziario e grado di integrazione dell'IA nelle attività chiave.

Qui la "valutazione dell'importanza" (materiality assessment), in parole semplici, è il giudizio su se un'applicazione dell'IA possa influenzare le attività chiave dell'istituzione, i diritti dei clienti o le decisioni di rischio. Gli strumenti utilizzati per organizzare i verbali delle riunioni, rispetto ai sistemi coinvolti nell'approvazione dei prestiti o nella gestione degli asset dei clienti, richiedono intensità di revisione diverse. Il FSB propone di configurare la governance in base agli scenari di applicazione e ai rischi, consentendo alle istituzioni di allocare più risorse di controllo agli usi che hanno un impatto maggiore.

Questo approccio alla gestione del ciclo di vita richiede alle istituzioni di esaminare insieme dati, modelli e scenari aziendali. La qualità dei dati di addestramento e di funzionamento influenzerà l'output del modello, l'aggiornamento del modello potrebbe cambiare le prestazioni originali, e i modi in cui clienti e dipendenti utilizzano il sistema possono comportare nuovi rischi. La valutazione dei rischi deve quindi attraversare la selezione, i test, il lancio e il funzionamento continuo.

La quinta pratica "valutazione dell'importanza e dei rischi" è adatta per completare il primo ciclo durante la fase di avvio, e successivamente deve essere ripetuta quando l'uso cambia, l'ambito dei dati si amplia o il modello viene aggiornato. Un knowledge base del servizio clienti che risponde agli orari di apertura dei prodotti, rispetto a un sistema che raccomanda automaticamente ai clienti di acquistare prodotti di investimento ad alto rischio, affronta conseguenze diverse per i consumatori. Le istituzioni possono includere nel modulo di valutazione il numero di persone influenzate, la reversibilità delle decisioni, la sensibilità dei dati, l'esposizione finanziaria e la capacità di intervento umano, per poi decidere quali test e approvazioni siano necessari. In questo modo, le risorse saranno prioritariamente allocate ai sistemi che potrebbero realmente danneggiare i clienti o interrompere il servizio.

La sesta pratica riguarda la selezione. Sul mercato ci sono modelli costruiti internamente, così come API esterne e funzionalità di IA integrate in software comuni. I team aziendali di solito vedono prima il prezzo e le funzionalità, mentre i team di rischio devono anche chiedere: il modello può funzionare stabilmente nelle lingue, nei gruppi di clienti e nelle condizioni di mercato della nostra istituzione? Il fornitore avvisa in caso di aggiornamenti? I dati verranno utilizzati per ulteriori addestramenti? Se si possono ottenere solo informazioni tecniche limitate, l'istituzione può prima limitare l'uso e l'ambito dei dati, continuando a testare con i propri campioni dopo il lancio, piuttosto che considerare la demo di acquisto come una verifica formale.

Le settima e ottava pratiche collegano dati e spiegazioni. Se il campione di storicità dei prestiti omette un certo tipo di cliente, il modello potrebbe continuare a non funzionare correttamente per tali domande; se i dipendenti in prima linea non possono spiegare i risultati delle raccomandazioni, sarà più difficile gestire le contestazioni dei clienti. La governance dei dati deve quindi riguardare integrità, accuratezza, autorizzazione delle fonti, accesso e sicurezza. Anche i requisiti di interpretabilità devono essere organizzati in base agli scenari: fornire fonti per la ricerca interna e spiegare ai clienti le decisioni che influenzano le loro opportunità di finanziamento richiedono livelli di chiarezza diversi. Il FSB consente alle istituzioni di impostare restrizioni d'uso, revisioni e test aggiuntivi come controlli compensativi su modelli difficili da spiegare, con l'obiettivo di garantire che chi prende le decisioni abbia informazioni sufficienti.

Le nono e decima pratiche entrano nella gestione quotidiana. Le istituzioni devono monitorare se le prestazioni del modello cambiano con l'ambiente aziendale, osservando tassi di errore, reclami, chiamate anomale e modifiche manuali; gli indicatori di monitoraggio devono essere collegati all'uso originale. La supervisione umana deve anche avere potere reale. Se un revisore può solo cliccare "approva" sullo schermo, senza vedere le basi, e non ha il potere di modificare l'output, la supervisione diventa difficile. I processi ad alto rischio possono impostare conferme obbligatorie, revisioni a campione e soglie di arresto automatico; registrare perché un operatore ha adottato o ribaltato il suggerimento del modello può migliorare i test.

Le ultime due pratiche riportano l'IA nell'ambiente tecnologico e nella catena di fornitura. Le interfacce dei modelli, i connettori dei dati e gli strumenti Agent possono diventare nuovi punti di attacco, e le esercitazioni di sicurezza informatica devono coprire iniezioni di suggerimenti, perdite di chiavi, chiamate errate agli strumenti e interruzioni dei servizi esterni. I rischi dei fornitori includono anche le prestazioni del modello, la trasparenza, la qualità dei dati di addestramento e di funzionamento, la catena di subappalto e la dipendenza centralizzata. Diverse banche che utilizzano contemporaneamente pochi fornitori di cloud o modelli di base possono subire un impatto commerciale più ampio in caso di guasto di un singolo fornitore. Le istituzioni devono almeno sapere dove si trovano le dipendenze chiave e chi subentrerà in caso di interruzione delle attività importanti.

2. Le opinioni pubbliche hanno arricchito il manoscritto finale con dettagli operativi

Il FSB ha pubblicato una bozza di consultazione nel giugno 2026 e ha chiuso la consultazione il 22 luglio. Ha ricevuto circa 160 feedback, provenienti da banche, compagnie assicurative, altre istituzioni finanziarie, associazioni di settore, fornitori di servizi tecnologici, accademici e settori pubblici. In generale, i partecipanti hanno sostenuto pratiche basate su principi che enfatizzano la proporzionalità; hanno anche sollevato difficoltà pratiche nell'implementazione.

Il manoscritto finale ha mantenuto il quadro orientato ai principi e tecnicamente neutro, e ha aggiunto spiegazioni su come le piccole istituzioni possano attuare la governance sfruttando le competenze esistenti e quelle esterne. La sezione dei casi ha incluso pratiche di compagnie assicurative, istituzioni di gestione patrimoniale e fornitori di servizi di pagamento, rendendo queste pratiche applicabili a più tipi di istituzioni. Il FSB ha presentato i casi come esempi di percorsi pratici, ma le disposizioni specifiche devono ancora essere adattate alla situazione dell'istituzione.

L'IA di terzi è stata uno dei problemi con il maggior numero di feedback. Quando le istituzioni finanziarie utilizzano modelli esterni o prodotti di IA integrati, le informazioni visibili sui modelli, sui dati e sulla catena di fornitura sono spesso limitate, aumentando la difficoltà di valutare i rischi in modo indipendente. La crescente quota di pochi fornitori chiave nell'infrastruttura dell'IA ha anche portato le istituzioni a preoccuparsi di come cambiare fornitore e ripristinare le attività in caso di interruzione del servizio.

La dipendenza da terzi e la sicurezza informatica sono state incluse nella gestione dell'intero ciclo di vita dell'IA.

Il manoscritto finale ha quindi ampliato ulteriormente la discussione sull'IA di terzi, coprendo l'IA integrata, i servizi in subappalto e la dipendenza dalla catena di fornitura, enfatizzando la gestione della concentrazione, la continuità aziendale e le disposizioni di uscita. Le disposizioni di uscita per i servizi chiave, in parole semplici, riguardano come le istituzioni possano cambiare servizio o mantenere le operazioni in caso di interruzione del fornitore, cessazione del contratto o superamento del rischio rispetto alla capacità dell'istituzione.

Nella negoziazione dei contratti, le istituzioni finanziarie possono ottenere informazioni su quattro aspetti: come il fornitore gestisce input e output, come vengono comunicati cambiamenti significativi ai modelli o ai servizi, quali registri possono essere forniti in caso di incidenti e come vengono restituiti o cancellati i dati dopo la cessazione della collaborazione. I grandi fornitori potrebbero non accettare termini personalizzati da ogni cliente, ma le istituzioni possono comunque ridurre la dipendenza da punti unici limitando l'accesso, mantenendo processi di backup interni e testando percorsi alternativi regolarmente. Le disposizioni di uscita devono infine riguardare persone, formati di dati e tempi di conversione, e non possono rimanere nel contratto come "può essere terminato".

L'IA agent è diventata un punto focale delle modifiche. Essa differisce dagli strumenti di generazione di testo comuni, poiché può eseguire più passaggi consecutivi dopo aver impostato un obiettivo, e alcuni sistemi possono anche richiamare strumenti esterni o accedere ai dati aziendali. I feedback hanno suggerito controlli come autorizzazione prima dell'esecuzione, accesso minimo, registrazioni delle operazioni non modificabili e monitoraggio in tempo reale. Il rapporto finale ha incluso considerazioni relative e ha spiegato che queste pratiche sono ancora in fase di sviluppo, e potrebbero richiedere linee guida più approfondite in futuro.

I feedback della consultazione hanno anche menzionato che se più istituzioni dipendono dallo stesso modello o da pochi fornitori, i comportamenti di mercato potrebbero diventare simili, amplificando i rischi. Il rapporto finale si concentra su come una singola istituzione finanziaria possa adottare responsabilmente l'IA; i rischi sistemici più ampi continueranno a essere monitorati attraverso altre valutazioni di stabilità finanziaria.

3. Per le istituzioni finanziarie, il lavoro chiave è integrare i principi nei processi quotidiani

Queste 12 pratiche devono essere integrate all'interno delle istituzioni, iniziando con un elenco di utilizzo dell'IA che possa essere continuamente aggiornato. L'elenco dovrebbe indicare a quale attività serve il sistema, chi è responsabile, quali clienti o processi chiave potrebbero essere influenzati, quali modelli e servizi cloud esterni sono utilizzati e come sospendere o cambiare in caso di anomalie. Le capacità di IA possono anche essere integrate in prodotti di ufficio, assistenza clienti o analisi comunemente utilizzati, quindi l'elenco deve coprire anche strumenti e software quotidiani al di fuori dei progetti di acquisto.

In secondo luogo, la valutazione dei rischi dell'IA deve iniziare dalla fase di acquisto e prova. Il team aziendale deve spiegare gli obiettivi di applicazione, il team tecnico deve valutare modelli e dati, e il personale di rischio e conformità deve giudicare l'impatto su decisioni dei clienti, attività chiave o obblighi legali. Dopo il lancio del sistema, l'istituzione deve continuare a monitorare le prestazioni operative e verificare se aggiornamenti di dati o modelli comportano nuovi rischi.

Quando il percorso decisionale del modello è difficile da spiegare, l'istituzione può ridurre i rischi limitando l'uso, aumentando le revisioni manuali o impostando test aggiuntivi. Questi "controlli compensativi" servono a mitigare i rischi derivanti dalla mancanza di trasparenza del modello e devono essere attuati insieme agli obblighi legali relativi alla protezione dei dati e ai diritti dei consumatori.

Un processo interno utilizzabile dovrebbe anche distinguere tra "sperimentazione" e "produzione". L'ambiente di sperimentazione può utilizzare dati anonimizzati o sintetici, limitando utenti e chiamate; prima di accedere a dati reali dei clienti e sistemi aziendali, è necessario che i team aziendali, tecnici, di sicurezza e legali confermino congiuntamente i dati e le autorizzazioni. L'approvazione del lancio non dovrebbe essere considerata un punto finale. Le istituzioni possono impostare attivatori di revisione per le modifiche di versione: quando si cambia modello di base, si accede a nuovi strumenti esterni, si espande a nuovi gruppi di clienti o si modifica il grado di automazione, deve avviarsi automaticamente una revisione. Molti rischi dell'IA si manifestano dopo che l'uso si è lentamente ampliato, mentre i materiali di avvio possono rimanere ancorati a scenari a basso rischio originali.

La gestione dei fornitori deve essere integrata anche nei processi di acquisto e contratto. Le istituzioni devono comprendere quali informazioni sui modelli possono fornire i fornitori, come vengono gestiti i dati, quali aziende di supporto ci sono per i servizi, come vengono comunicati ai clienti aggiornamenti significativi e quali alternative ci sono in caso di interruzione dei servizi chiave.

Quando i fornitori forniscono solo informazioni tecniche parziali sui modelli, le istituzioni finanziarie possono registrare le informazioni ottenute, i rischi da trattare e le disposizioni operative, come base per la due diligence e la gestione successiva.

Per l'IA agent, è necessario chiarire i confini di autorizzazione: quali dati può accedere, quali strumenti può richiamare, quali operazioni devono essere confermate dai dipendenti e come sospendere i compiti in caso di anomalie. Il personale di supervisione deve avere il potere di intervenire, tempo sufficiente e registrazioni delle operazioni consultabili.

Ad esempio, se un'istituzione consente a un Agent di organizzare i materiali di richiesta dei clienti, può permettergli di leggere una cartella specifica e generare un elenco da verificare, ma lasciare la modifica dei limiti di credito e l'invio delle decisioni ai dipendenti. Se lo stesso Agent deve completare tre azioni: interrogare, scrivere e notificare, il sistema può emettere un token temporaneo in diversi passaggi e registrare ogni chiamata. In questo modo, il team di rischio non vedrà più solo un'etichetta astratta come "è stato utilizzato l'Agent", ma una catena di esecuzione che può essere testata, auditata e sospesa.

Nella pratica, le 12 pratiche possono essere riassunte in quattro categorie di deliverable: principi di utilizzo dell'IA approvati dal consiglio di amministrazione, elenco di applicazioni e dipendenze in continuo aggiornamento, valutazioni e registrazioni dei test per ogni caso d'uso importante, e piani di disattivazione e ripristino in caso di anomalie. Questi quattro materiali sono interconnessi. L'elenco informa la direzione su quali progetti ci sono; le valutazioni decidono quali controlli siano più rigorosi; i test dimostrano se i controlli siano efficaci; le registrazioni degli incidenti spingono ulteriormente alla modifica delle regole. Anche le piccole istituzioni possono riutilizzare le riunioni di rischio esistenti e i processi di acquisto; la chiave è rendere le responsabilità e le prove tracciabili.

4. Questo è un riferimento alla gestione, l'applicazione dipende ancora dalla giurisdizione

Il FSB ha posizionato queste 12 pratiche come strumenti pratici che possono essere adattati alla situazione delle istituzioni. Quando applicano questo quadro, le istituzioni devono comunque confrontare i casi d'uso dell'IA con i requisiti specifici della propria giurisdizione riguardo alla protezione dei dati, ai diritti dei consumatori, alla gestione delle esternalizzazioni, ai rischi dei modelli o alla governance delle istituzioni finanziarie.

La sua funzione pratica è quella di fornire un elenco comune di governance: dalla responsabilità del consiglio di amministrazione, alla documentazione interna, fino alla selezione dei modelli, alla supervisione umana e alla gestione dei fornitori, le istituzioni possono utilizzarlo per verificare la copertura dei processi esistenti su aspetti chiave. Con l'ulteriore integrazione dell'IA nelle attività finanziarie, anche i responsabili, le misure di controllo e le disposizioni di emergenza dietro questo elenco devono essere continuamente aggiornati.

Dal punto di vista delle politiche internazionali, l'approccio del FSB ha un ulteriore valore: diverse giurisdizioni possono esaminare l'applicazione dell'IA nelle istituzioni finanziarie con problemi simili. I regolatori potrebbero non utilizzare lo stesso elenco, ma si preoccuperanno sempre di chi sostiene i rischi, di come i modelli funzionano nelle attività chiave e di come i clienti sono influenzati in caso di guasti nelle dipendenze esterne. Se le istituzioni possono preparare le prove sopra menzionate, sarà più facile spiegare le proprie disposizioni di controllo di fronte ai requisiti di protezione dei dati, dei consumatori e di vigilanza prudenziale in diverse regioni.

Questo contenuto è fornito a solo scopo informativo generale e non costituisce consulenza finanziaria, di investimento, legale o fiscale. Qualsiasi evento, ricompensa, promozione online o informazione correlata menzionata nel presente documento non deve essere considerata una raccomandazione, una sollecitazione o un invito ad acquistare, vendere, fare trading o altrimenti negoziare criptovalute. Le criptovalute sono altamente volatili e possono comportare perdite. La disponibilità dei servizi, dei prodotti e degli eventi correlati di WEEX può variare a seconda della regione. È tua responsabilità assicurarti che la tua partecipazione sia conforme alle leggi e ai regolamenti locali applicabili.