Gestione del rischio di modello per l’IA e il machine learning

Gestione del rischio di modello rappresentata da una bilancia che pesa un modello

In sintesi

  • La gestione del rischio di modello (MRM) è la disciplina che individua, misura e tiene sotto controllo il rischio di perdita derivante da decisioni basate su modelli errati o utilizzati in modo improprio.
  • Negli Stati Uniti le aspettative di vigilanza sono cambiate nel 2026: SR 26-2 sostituisce SR 11-7, in vigore da quindici anni, e passa dalla riconvalida annuale obbligatoria a una sorveglianza commisurata alla materialità dei modelli.
  • SR 26-2 lascia deliberatamente l’IA generativa e l’IA agentica al di fuori del proprio perimetro, aprendo una lacuna di governance che i quadri specializzati devono colmare.
  • Il machine learning e i modelli generativi contraddicono diverse ipotesi della gestione tradizionale: derivano, restano opachi e si comportano in modo non deterministico.
  • Un programma moderno ancora la gestione del rischio di modello a un inventario centrale e proietta i suoi controlli sul regolamento IA, sulla ISO/IEC 42001 e sul NIST AI RMF.

Che cos’è la gestione del rischio di modello?

Il rischio di modello rappresenta la possibilità di conseguenze negative, che si tratti di perdite finanziarie, decisioni inadeguate, sanzioni regolamentari o danni reputazionali, quando una decisione poggia su un modello inesatto, applicato male o frainteso. La gestione del rischio di modello riunisce le politiche, i ruoli e i controlli con cui un’organizzazione mantiene tale rischio entro una propensione definita, lungo l’intero ciclo di vita. La definizione di riferimento proviene dalla vigilanza bancaria statunitense. Nell’aprile 2011 la Federal Reserve e l’Office of the Comptroller of the Currency pubblicarono SR 11-7 (OCC Bulletin 2011-12), che descrive un modello come un metodo quantitativo che applica una teoria statistica, economica, finanziaria o matematica per trasformare i dati di ingresso in una stima quantitativa. Quel documento è diventato il riferimento della disciplina, ben oltre il settore bancario. Due idee reggono l’insieme. In primo luogo, ogni modello resta un’approssimazione, sicché l’errore è una proprietà del modello e non un difetto. In secondo luogo, l’errore diventa rischio soltanto quando un modello alimenta una decisione. La gestione del rischio di modello concentra dunque lo sforzo dove un output errato provocherebbe il danno maggiore, ragione per cui la materialità, ossia la posta in gioco legata a un modello, si colloca al centro di ogni programma serio. La stessa logica sostiene la più ampia gestione del rischio dell’IA, di cui il rischio di modello è una componente.

I tre pilastri: sviluppo, convalida, governance

SR 11-7 ha organizzato la disciplina attorno a tre pilastri che tuttora la definiscono. Lo sviluppo e l’implementazione riguardano una progettazione solida, ipotesi documentate, dati adeguati e prove prima della messa in produzione. La convalida consiste in un riesame indipendente ed efficace: un gruppo separato dagli sviluppatori verifica la solidità concettuale, il monitoraggio continuo e l’analisi dei risultati. La governance avvolge entrambi con politiche, ruoli, un inventario e una responsabilità chiara, affinché l’organizzazione sappia quali modelli esistono, chi ne risponde e come sono controllati. Questi pilastri si sovrappongono alla più ampia mappatura del rischio IA che i team di governance oggi seguono.

Da dove nasce il rischio di modello

Il rischio di modello ha quattro fonti ricorrenti, ciascuna amplificata quando il modello è un sistema di machine learning. I dati. Un modello vale quanto i dati da cui apprende e su cui opera. Lacune di campionamento, errori di etichettatura, variabili obsolete e popolazioni non rappresentative si propagano tutti negli output. L’apprendimento automatico allarga questa esposizione, poiché i modelli assorbono i difetti di qualità su vasta scala e li riproducono in ogni previsione. La progettazione e le ipotesi. Ogni modello codifica ipotesi sul mondo. Quando queste cessano di valere, per esempio un modello di scoring costruito su comportamenti precedenti a uno shock, gli output si deteriorano benché il codice resti invariato. L’implementazione. Gli errori entrano nella codifica, nell’integrazione o nel rilascio: una pipeline di variabili disallineata, una differenza di arrotondamento tra addestramento e produzione, o un aggiornamento di libreria passato inosservato. Tali difetti sfuggono facilmente, perché il modello continua a restituire numeri plausibili. L’uso e l’uso improprio. Le perdite più gravi derivano spesso da un modello impiegato al di fuori della propria finalità, ritenuto affidabile oltre l’intervallo testato, o i cui limiti vengono ignorati. Un enunciato di ambito chiaro e istruzioni d’uso sono controlli, non burocrazia.

Da SR 11-7 a SR 26-2: che cosa è cambiato nel 2026

Per quindici anni SR 11-7 è stato il punto fermo della pratica. La situazione è cambiata il 17 aprile 2026, quando la Federal Reserve, l’OCC e la FDIC hanno pubblicato SR 26-2, un orientamento interagenzia rivisto sulla gestione del rischio di modello che sostituisce SR 11-7. La direzione è basata sul rischio e scalabile. Le autorità di vigilanza si attendono ora che la profondità di un programma corrisponda alla dimensione, alla complessità e al profilo di rischio dell’ente, una precisazione rivolta agli operatori più piccoli e meno complessi. Il cambiamento operativo più rilevante consiste nel fatto che la riconvalida annuale obbligatoria cede il passo a una sorveglianza legata alla materialità dei modelli, cosicché lo sforzo di convalida segue la posta in gioco anziché il calendario. SR 26-2 restringe inoltre ciò che vale come modello, escludendo i calcoli aritmetici semplici dei fogli elettronici, i processi deterministici basati su regole e il software ordinario. L’orientamento riguarda soprattutto le banche con attivi superiori a 30 miliardi di dollari, è esplicitamente non vincolante ed è accompagnato dall’OCC Bulletin 2026-13. Per gli enti regolati è l’occasione di abbandonare gli adempimenti dettati dal calendario e reinvestire la capacità di convalida dove il rischio di modello è davvero elevato. Per tutti gli altri il segnale è chiaro: il controllo diventerà proporzionato e fondato sulle evidenze, non uniforme. La stessa impostazione orientata alla materialità attraversa i moderni programmi di conformità e gestione del rischio.

La lacuna sull’IA generativa lasciata da SR 26-2

Esiste un limite deliberato. SR 26-2 mantiene l’IA generativa e l’IA agentica al di fuori del proprio perimetro, sul presupposto che tali tecnologie siano nuove e in rapido movimento. La scelta è difendibile, ma lascia la categoria di modelli in più rapida crescita priva di uno standard MRM dedicato da parte delle autorità bancarie statunitensi. Chi utilizza grandi modelli linguistici o agenti di IA autonomi non può attendere la prossima revisione. Queste organizzazioni devono estendere sin d’ora i principi della disciplina a tali sistemi, servendosi dei quadri di governance concepiti proprio a questo scopo.

Perché l’IA e il machine learning scardinano la MRM tradizionale

La MRM tradizionale era pensata per modelli relativamente stabili, ispezionabili e deterministici. Il machine learning e i sistemi generativi violano tutte e tre le ipotesi, ragion per cui i team di convalida non possono riutilizzare tale e quale il vecchio metodo. Il non determinismo. Un modello generativo può restituire output diversi per la stessa richiesta. I metodi di convalida costruiti attorno a un unico risultato atteso non si trasferiscono a sistemi probabilistici per costruzione. La deriva. I modelli di ML si deteriorano man mano che il mondo si allontana dalla loro distribuzione di addestramento. Senza monitoraggio continuo, un modello convalidato in modo pulito al lancio diventa silenziosamente inaffidabile. L’opacità. I modelli complessi resistono all’ispezione, il che complica il riesame della solidità concettuale e si scontra con le aspettative regolamentari in materia di spiegabilità. I revisori non sempre riescono a ricostruire il perché di un output. Distorsioni ed esposizione avversariale. I modelli addestrati su dati mal governati ereditano le distorsioni e le amplificano, e i sistemi generativi aggiungono l’iniezione di prompt e l’elusione, che la convalida tradizionale non aveva mai considerato. Fuga di dati e provenienza. Quando i dati di addestramento sono mal governati, informazioni sensibili possono riaffiorare negli output e l’organizzazione può rivelarsi incapace di dimostrare su che cosa un modello sia stato addestrato. Il caso più acuto resta il rischio principale dell’IA generativa, l’allucinazione, in cui un output fluido e sicuro è semplicemente falso.

La gestione del rischio di modello incontra la governance dell’IA

La lacuna lasciata dalla vigilanza bancaria è colmata da tre strumenti di governance, che un programma maturo tratta come un unico insieme di controlli anziché come tre audit separati. Il regolamento IA dell’Unione europea traduce in legge obblighi vicini alla disciplina per i sistemi ad alto rischio. I fornitori devono gestire un sistema di gestione dei rischi lungo il ciclo di vita (Articolo 9), applicare la governance dei dati (Articolo 10), tenere una documentazione tecnica (Allegato IV), assicurare la sorveglianza umana (Articolo 14) e soddisfare i requisiti di accuratezza, robustezza e cibersicurezza (Articolo 15), prima di superare una valutazione di conformità (Articolo 43). La guida operativa al regolamento IA precisa come tali doveri siano ripartiti. Il NIST AI RMF propone una struttura volontaria fondata su quattro funzioni, Govern, Map, Measure e Manage, che si allineano naturalmente a sviluppo, convalida e monitoraggio. La nostra guida al NIST AI RMF esamina ciascuna funzione. La ISO/IEC 42001 offre un sistema di gestione dell’IA certificabile, dotato di controlli in Allegato A e di un ciclo di certificazione triennale, che dà alla disciplina una sede verificabile, come illustra la nostra presentazione della ISO 42001. Persino le autorità settoriali convergono verso le stesse aspettative. La Guida della BCE sui modelli interni, rivista nel luglio 2025, ha aggiunto una sezione dedicata al machine learning che tratta la spiegabilità, il rapporto tra prestazione e complessità, la convalida e la gestione del rischio di modello per le banche che impiegano il ML nei modelli interni regolamentari.

Un unico insieme di controlli per tutti i quadri

I quadri si sovrappongono più di quanto divergano. Un solo esercizio di convalida può soddisfare al tempo stesso il riesame efficace di SR 26-2, l’Articolo 9 del regolamento IA, la funzione Measure del NIST e i controlli di monitoraggio della ISO 42001, a condizione di raccogliere l’evidenza una volta sola e di collegarla a ciascun requisito. La nostra corrispondenza tra NIST AI RMF, ISO 42001 e regolamento IA mostra dove i requisiti si incontrano, così da evitare di eseguire tre volte lo stesso controllo.

Costruire un programma moderno di gestione del rischio di modello

Un programma che abbraccia i modelli tradizionali e quelli di IA poggia su tre fondamenta operative.

L’inventario dei modelli come fondamento

Non si governa ciò che non si è censito. Un inventario completo, che registra ogni modello con il proprietario, la finalità, la materialità, le fonti di dati e lo stato di convalida, è la precondizione di ogni altro controllo. Il problema più arduo non riguarda i modelli noti all’IT, bensì quelli che le sfuggono: fogli elettronici, notebook e strumenti di IA di terze parti che compongono la shadow AI. Un registro che scopre e traccia tali sistemi trasforma la disciplina da esercizio periodico in capacità viva.

Le tre linee di difesa applicate ai modelli di IA

Una MRM efficace separa i compiti. La prima linea, proprietari e sviluppatori dei modelli, costruisce e documenta. La seconda linea, convalida indipendente e funzione di rischio, contesta e approva. La terza linea, l’audit interno, verifica che il processo stesso funzioni. Per i modelli di IA questa struttura richiede una profondità trasversale, poiché un unico sistema generativo può sollevare al contempo questioni di governance dei dati, di sicurezza e di etica.

Convalida e monitoraggio continui

Poiché i modelli di ML derivano, la convalida non può essere un varco unico. Un programma moderno monitora con continuità le prestazioni, la stabilità dei dati e i risultati, e riconvalida quando cambiano la materialità o il comportamento anziché a scadenza fissa. È esattamente l’impostazione fondata sulla materialità che SR 26-2 ora incoraggia, applicata a sistemi che mutano più rapidamente di qualsiasi ciclo annuale. Costituire questa traccia di evidenze è anche ciò che rende un sistema verificabile.

La gestione del rischio di modello oltre il settore bancario

La disciplina è nata nella finanza, ma l’obbligo si estende a ogni settore che impiega un’IA con conseguenze rilevanti. Gli assicuratori modellano la tariffazione e le riserve, la sanità modella il triage e la diagnosi, il settore pubblico modella l’ammissibilità e i controlli, ciascuno con poste in gioco umane reali. Il regolamento IA non distingue se un modello ad alto rischio si trovi in una banca o in un ospedale: i doveri di gestione dei rischi, documentazione e sorveglianza si applicano allo stesso modo. Di conseguenza, la gestione del rischio di modello sta diventando un requisito generale della governance dell’IA anziché una specialità bancaria, e le organizzazioni già dotate di una funzione matura partono avvantaggiate sulla conformità.

Domande frequenti

Quali sono i tre pilastri della gestione del rischio di modello? I tre pilastri provengono da SR 11-7: sviluppo e implementazione, convalida e governance. Lo sviluppo copre una progettazione solida, ipotesi documentate e prove. La convalida è il riesame indipendente ed efficace della solidità concettuale, del monitoraggio e dei risultati di un modello. La governance fornisce le politiche, i ruoli, l’inventario e la responsabilità che tengono insieme il programma. SR 26-2 conserva questa logica rendendo però l’intensità di ciascun pilastro proporzionale alla materialità. Qual è la differenza tra SR 11-7 e SR 26-2? SR 11-7 (2011) era l’orientamento statunitense fondativo sulla gestione del rischio di modello. SR 26-2, pubblicato il 17 aprile 2026 dalla Federal Reserve, dall’OCC e dalla FDIC, lo sostituisce. I cambiamenti principali sono il passaggio dalla riconvalida annuale obbligatoria a una sorveglianza legata alla materialità, una definizione più stretta di ciò che conta come modello e aspettative proporzionate alla dimensione dell’ente. SR 26-2 esclude inoltre l’IA generativa e agentica dal proprio perimetro formale. La gestione del rischio di modello si applica all’IA generativa? Non ancora per il tramite della vigilanza bancaria statunitense, ed è proprio la lacuna da osservare. SR 26-2 lascia fuori l’IA generativa e agentica. In pratica, le organizzazioni estendono i principi della disciplina a tali sistemi mediante il regolamento IA, il NIST AI RMF e la ISO/IEC 42001, che trattano direttamente i modelli di IA. I sistemi generativi richiedono inoltre controlli contro il non determinismo, la deriva, l’opacità e gli attacchi basati sui prompt, che la convalida tradizionale non aveva mai previsto. Qual è un esempio di rischio di modello? Un esempio classico è un modello di scoring del credito addestrato su un’economia stabile che continua ad approvare prestiti mentre le condizioni peggiorano, perché le sue ipotesi non valgono più. Un esempio moderno è un modello generativo che produce una risposta sicura ma inventata, un’allucinazione, che un processo a valle tratta come un fatto. In entrambi i casi la perdita non nasce dall’esistenza del modello ma da una decisione fondata su un output difettoso. Come si collega la gestione del rischio di modello al regolamento IA? Il regolamento IA trasforma le pratiche centrali della disciplina in obblighi giuridici per i sistemi ad alto rischio. L’Articolo 9 impone un sistema di gestione dei rischi lungo il ciclo di vita, l’Articolo 10 la governance dei dati, l’Allegato IV la documentazione tecnica, l’Articolo 14 la sorveglianza umana e l’Articolo 15 l’accuratezza e la robustezza, il tutto confermato dalla valutazione di conformità dell’Articolo 43. Un’organizzazione con una funzione MRM operativa svolge già la maggior parte di queste attività e può ricondurle al regolamento anziché ricominciare da capo. Chi è responsabile della gestione del rischio di modello? La responsabilità è ripartita su tre linee di difesa. I proprietari e gli sviluppatori dei modelli costruiscono e documentano. Una funzione indipendente di convalida o di rischio contesta e approva. L’audit interno verifica che il processo complessivo funzioni. L’alta direzione e il consiglio si fanno carico della propensione al rischio e del quadro stesso. Per i modelli di IA questa struttura richiede di solito il contributo delle funzioni dati, sicurezza ed etica, poiché un unico sistema può toccare tutte e tre le dimensioni.

Conclusione

La gestione del rischio di modello è passata da specialità bancaria stabile a tessuto connettivo tra la disciplina dei modelli quantitativi e la governance dell’IA. SR 26-2 ha modernizzato l’aspettativa statunitense, ma lasciando fuori l’IA generativa e agentica ha reso evidente una cosa: ora sono i quadri che governano i modelli di IA, il regolamento IA, la ISO/IEC 42001 e il NIST AI RMF, a reggere il peso. Le organizzazioni vincenti li tratteranno come un unico insieme di controlli, ancorato a un inventario vivo che vede ogni modello, compresi quelli che nessuno ha dichiarato. È lì che la gestione del rischio di modello e la governance dell’IA diventano un solo programma. Scopri come un approccio basato su un registro porta i tuoi modelli sotto il controllo della governance dell’IA.

Valutazione dei fornitori di IA: le dodici domande mancanti

La valutazione dei fornitori nasce per una catena di fornitura senza IA. Ecco le dodici domande da aggiungere e l'obbligo giuridico che le impone.

Gestione del rischio di modello per l’IA e il machine learning

La gestione del rischio di modello cambia con l'IA. SR 26-2, regolamento IA, ISO 42001 e NIST AI RMF: il quadro per il machine learning e l'IA generativa.

Gestione delle policy aziendali: la guida all’acquisto nell’era dell’IA

La gestione delle policy aziendali oggi deve dimostrare che le policy sull'IA funzionano, non solo che sono state firmate. Criteri, obblighi e trappole.

Sorveglianza umana: l’articolo 14 dell’AI Act in pratica

La sorveglianza umana è un obbligo dell'articolo 14 dell'AI Act, non un principio. Cosa costruisce il fornitore, cosa presidia il deployer e da quando.

Comitato di governance dell’IA: statuto, seggi, decisioni

Un comitato di governance dell'IA vale solo se regge un audit. Gli articoli che lo fondano, i seggi, i diritti decisionali e le tracce da conservare.

Software GRC: che cosa cambia con l’IA

Un software GRC deve ora inventariare i sistemi di IA, mappare gli obblighi del regolamento europeo e conservare prove verificabili. La griglia completa.