L’FSB fissa 12 pratiche per l’IA in banca: la supervisione resta umana

Il 15 ottobre 2026 il Financial Stability Board (FSB) ha pubblicato 12 pratiche per l’adozione responsabile dell’IA nelle istituzioni finanziarie, banche comprese. Il rapporto finale precisa che le pratiche non sono prescrittive e non costituiscono uno standard internazionale vincolante: offrono controlli da adattare al contesto e al rischio di ciascun utilizzo, inclusa una supervisione umana effettiva.

L’autorità canadese OSFI ha accolto le pratiche nella dichiarazione del 15 ottobre 2026, richiamando responsabilità chiare, governo dei dati e controlli proporzionati. Per una banca o una fintech italiana, il documento offre una griglia per distinguere le decisioni del consiglio dalle verifiche su modelli, dati, fornitori e intervento umano. L’applicazione delle pratiche non sostituisce gli obblighi legali e regolamentari locali.

Il consiglio definisce i limiti, il risk management documenta i casi

Le pratiche sulla governance collocano consiglio di amministrazione e alta direzione all’inizio della catena di responsabilità. L’adozione dell’IA va collegata al modello di business, alla strategia e alla propensione al rischio dell’istituto. Il consiglio stabilisce quindi l’indirizzo e i limiti generali; la direzione deve tradurli in ruoli, risorse e controlli riconoscibili nelle attività quotidiane.

Per il risk management, il punto è integrare i rischi dell’IA nel quadro già usato dall’istituto e documentare gli impieghi concreti. La valutazione dovrebbe identificare lo scopo del sistema, la funzione che ne risponde, la rilevanza del caso d’uso e i rischi da presidiare. Le funzioni di controllo devono poter esaminare queste informazioni senza dipendere soltanto dal giudizio di chi sviluppa o utilizza il modello.

La governance comprende anche la capacità di adattarsi. Quando cambiano tecnologia, attività affidate al sistema o competenze necessarie per controllarlo, direzione e funzioni interessate devono riconsiderare l’assetto adottato. È una responsabilità diversa dalla sola approvazione iniziale: permette al consiglio di ricevere informazioni utili anche dopo che un’applicazione è entrata nei processi della banca.

Scelta del modello e qualità dei dati entrano nella valutazione del rischio

La valutazione di un caso d’uso comincia prima della scelta tecnica e prosegue dopo l’avvio. La sua rilevanza può cambiare se l’applicazione raggiunge più clienti, utilizza nuovi dati o assume compiti ulteriori. Una descrizione aggiornata di finalità, responsabile, limiti d’impiego e verifiche consente al risk management di rivedere il rischio senza trattare ogni versione del sistema come identica alla precedente.

Nella selezione, la funzione che propone l’utilizzo e l’IT devono confrontare obiettivo di business, esigenze operative, capacità tecniche e rischi. La scelta può riguardare uno sviluppo interno, un sistema acquistato o una combinazione di componenti. Un modello più complesso o performante non è automaticamente il più adatto se il suo funzionamento è difficile da spiegare o da governare nel caso previsto.

Il governo dei dati ha un compito distinto: verificare che le informazioni per addestramento, test e utilizzo siano adeguate allo scopo, accurate, complete, coerenti, affidabili e sicure. La questione riguarda anche i sistemi esterni, soprattutto quando ricevono dati dell’istituto o li usano per produrre risposte. Se l’accesso ai dati del fornitore è limitato, la valutazione può richiedere informazioni sui suoi processi e controlli di qualità.

Prestazioni e supervisione umana si misurano durante l’uso

Prima dell’impiego e nel monitoraggio successivo, le verifiche delle prestazioni devono essere proporzionate alla rilevanza e al rischio dell’applicazione. Test iniziali, osservazione degli esiti e riesame quando il comportamento cambia rispondono a momenti diversi del ciclo di vita. La funzione responsabile del caso d’uso deve sapere quali risultati sono accettabili e quando coinvolgere chi gestisce il rischio o la tecnologia.

La spiegabilità incide sia sulla scelta del sistema sia sulla possibilità di controllarne gli esiti. Dove è appropriato e fattibile, si può preferire un modello più spiegabile; altrimenti servono controlli compensativi adatti al rischio. Per chi valuta una decisione assistita dall’IA, la trasparenza utile è quella che permette di comprendere capacità, limiti e ragioni operative dell’esito, non una descrizione tecnica indistinta.

La supervisione umana deve variare con rilevanza, rischio, autonomia, complessità e spiegabilità del caso d’uso. Può assumere la forma di approvazione delle singole decisioni, intervento sulle eccezioni o controllo dei limiti entro cui opera un sistema autonomo. In ogni forma, chi controlla deve avere capacità e autorità per intervenire: una conferma formale ha poco valore se la persona non può valutare l’esito, correggerlo o fermare l’operazione.

IT e acquisti presidiano anche l’IA fornita dall’esterno

Le pratiche comprendono i rischi informatici e tecnologici legati all’IA. Per l’IT, questo significa considerare scenari specifici nei test e negli esercizi di gestione del rischio, oltre a definire i limiti di accesso dei sistemi più autonomi. La capacità di interrompere o restringere un’azione deve essere prevista nel funzionamento del sistema quando il rischio lo richiede, non affidata a un intervento impossibile da eseguire in tempo.

Per acquisti e gestione dei fornitori, la verifica riguarda prestazioni, trasparenza, qualità dei dati, continuità del servizio e concentrazione delle dipendenze. Il rapporto richiama anche diritti di accesso alle informazioni, monitoraggio e audit negli accordi con i fornitori, secondo il rischio del servizio. Se un componente esterno cambia versione o introduce funzioni di IA in un servizio già acquistato, l’istituto deve poter riconoscere la nuova dipendenza e rivalutare i controlli che la accompagnano.

Leggi anche:

• LangGraph con approvazione umana: senza checkpoint l’agente non riparte
• Agenti IA con approvazione umana: troppe conferme diventano un rischio
• ItaliaAperta porta l’IA nella burocrazia, ma Pino non può fare pratiche