Deriva del modello: rilevarla e governarla con l’AI Act

La deriva del modello è ciò che accade quando un modello di intelligenza artificiale, validato e messo in produzione, smette senza rumore di essere il modello che avete validato. Nessuno ha toccato il codice, nessun rilascio è partito, eppure le previsioni si spostano perché si è spostata la realtà che le alimenta. La maggior parte delle guide tratta la deriva del modello come un fastidio da ingegneri, da risolvere con un job di riaddestramento. Chi lavora nella compliance la vede diversamente: con l’AI Act, il principio di esattezza del GDPR e la vigilanza bancaria, la deriva è il punto in cui un sistema che ha superato la valutazione della conformità può smettere di garantire l’accuratezza dichiarata, senza che nessuno abbia firmato quel cambiamento.

In sintesi

• La deriva del modello è il calo di prestazioni di un modello dopo il rilascio, causato da cambiamenti nei dati in ingresso (data drift) o nel rapporto tra input ed esiti (concept drift).
• L’articolo 15 dell’AI Act chiede ai sistemi ad alto rischio prestazioni costanti per tutto il ciclo di vita e livelli di accuratezza dichiarati: una deriva non rilevata rende falsa quella dichiarazione.
• L’articolo 72 impone ai fornitori un sistema di monitoraggio successivo all’immissione sul mercato. Con l’Omnibus digitale, il modello di piano arriverà come linea guida entro il 2 settembre 2027.
• Riaddestrare dentro un perimetro di modifiche predeterminato non è una modifica sostanziale (art. 43, par. 4). Fuori da quel perimetro, può diventarlo.
• Nei modelli linguistici di terzi la deriva arriva spesso dal fornitore: bloccare le versioni e pretendere preavviso contrattuale sono controlli a tutti gli effetti.

Che cos’è la deriva del modello?

La deriva del modello, detta anche decadimento del modello (model decay), è la perdita, graduale o improvvisa, della qualità predittiva di un modello di machine learning una volta esposto a dati reali. La definizione proposta da IBM coincide con quella usata in letteratura: il modello è stato addestrato su una fotografia della realtà, e la realtà ha continuato a muoversi. Dietro l’etichetta si nascondono tre meccanismi distinti, che richiedono risposte diverse.

• Deriva dei dati (data drift o covariate shift). Cambia la distribuzione statistica degli input. Un modello antifrode addestrato su pagamenti con carta fisica comincia a vedere quasi solo pagamenti tramite wallet digitale. Il modello lavora ormai in zone dei dati che in addestramento aveva visto appena.
• Concept drift (deriva concettuale). Cambia il rapporto tra input e variabile obiettivo. Lo stesso profilo di reddito e indebitamento che indicava un rischio di credito basso in un’economia stabile segnala un rischio più alto durante uno shock inflazionistico.
• Label drift (prior probability shift). Cambia la frequenza di base dell’esito. Se le frodi raddoppiano, un modello calibrato sul vecchio tasso genera troppo poche allerte.

La deriva del modello può essere improvvisa (una pandemia, una nuova norma, il lancio di un prodotto), graduale (un lento cambiamento demografico), stagionale (la domanda nel commercio al dettaglio) o ricorrente. Attenzione ai falsi positivi: un campo rinominato a monte o un importo passato da euro a centesimi producono gli stessi sintomi, ma sono difetti di qualità dei dati.

Deriva del modello, data drift e concept drift a confronto

<table header-row=”true”> <tr> <td>Termine</td> <td>Che cosa cambia</td> <td>Segnale tipico</td> <td>Prima risposta</td> </tr> <tr> <td>Data drift</td> <td>Distribuzione degli input</td> <td>Test PSI o KS sulle variabili</td> <td>Verificare la pipeline, poi valutare l’impatto</td> </tr> <tr> <td>Concept drift</td> <td>Rapporto tra input ed esito</td> <td>Calo di accuratezza sugli esiti etichettati</td> <td>Rivalidare, probabilmente riaddestrare</td> </tr> <tr> <td>Label drift</td> <td>Frequenza di base dell’esito</td> <td>Scarto tra tassi previsti e osservati</td> <td>Ricalibrare le soglie</td> </tr> <tr> <td>Deriva del modello</td> <td>Prestazioni complessive (l’effetto)</td> <td>Uno qualsiasi dei precedenti</td> <td>Individuare la causa prima di agire</td> </tr> </table> In breve: data drift e concept drift sono cause, la deriva del modello è l’effetto osservabile sulle prestazioni.

Perché la deriva del modello è un problema di compliance, non solo di MLOps

Le spiegazioni più diffuse della deriva del modello si fermano a cruscotti e riaddestramenti. Ma un revisore non chiederà «avete riaddestrato?», bensì «come ve ne siete accorti, che cosa avete deciso e dove sta la traccia?». Tre ancoraggi giuridici trasformano la deriva del modello in un evento di compliance. L’accuratezza che avete dichiarato. L’articolo 15 dell’AI Act chiede che i sistemi di IA ad alto rischio raggiungano un livello adeguato di accuratezza, robustezza e cibersicurezza e che mantengano prestazioni costanti sotto questi profili per l’intero ciclo di vita. Il paragrafo 3 aggiunge che i livelli di accuratezza e le metriche pertinenti vanno dichiarati nelle istruzioni per l’uso. Se il richiamo dichiarato era del 94% e oggi, per effetto della deriva, è dell’86%, la documentazione non descrive più il prodotto. I sistemi che continuano ad apprendere devono inoltre gestire i circuiti di retroazione, in cui gli output distorti di oggi diventano i dati di addestramento di domani. Il principio di esattezza nella protezione dei dati. Quando un modello prende o supporta decisioni su persone, previsioni degradate equivalgono a dati personali inesatti ai sensi dell’articolo 5, paragrafo 1, lettera d), del GDPR. Il Garante europeo della protezione dei dati (EDPS) lo ha scritto nero su bianco nelle sue linee guida sulla gestione del rischio dei sistemi di IA dell’11 novembre 2025, che elencano tra i rischi l’output inesatto dovuto al data drift e al deterioramento della qualità dei dati personali in ingresso. L’esempio scelto parla da sé: un modello di credit scoring addestrato in un’economia stabile e poi usato durante una crisi, con inflazione e disoccupazione in forte movimento. Le misure raccomandate sono quattro: rilevamento della deriva, monitoraggio della qualità dei dati, riaddestramento a cadenza fissa o al rilevamento della deriva, canali di feedback per gli utenti. Il testo vale come riferimento anche per il settore privato. L’equità che si consuma. Un modello può mantenere intatta l’accuratezza aggregata mentre il tasso di errore di un sottogruppo cresce, perché i dati di quel sottogruppo si sono spostati e quelli della maggioranza no. Un monitoraggio della deriva che guarda solo le metriche globali non lo vedrà mai. Per questo le metriche di equità vanno nello stesso piano di monitoraggio, come spieghiamo nella guida sul bias nell’IA.

Che cosa chiedono le norme sulla deriva del modello

Nessun testo definisce formalmente la deriva del modello, ma diversi regimi chiedono proprio ciò che la sua gestione produce. <table header-row=”true”> <tr> <td>Regime</td> <td>Disposizione</td> <td>Che cosa significa per la deriva</td> </tr> <tr> <td>AI Act</td> <td>Art. 15, par. 1 e 3</td> <td>Prestazioni costanti nel ciclo di vita; metriche di accuratezza dichiarate</td> </tr> <tr> <td>AI Act</td> <td>Art. 9, par. 2, lett. c)</td> <td>La gestione del rischio valuta i rischi emersi dai dati di monitoraggio post-commercializzazione</td> </tr> <tr> <td>AI Act</td> <td>Art. 12</td> <td>Registrazione automatica degli eventi che rende possibile il monitoraggio</td> </tr> <tr> <td>AI Act</td> <td>Art. 26, par. 5</td> <td>I deployer sorvegliano il funzionamento e informano il fornitore dei rischi</td> </tr> <tr> <td>AI Act</td> <td>Art. 72</td> <td>I fornitori gestiscono un sistema e un piano documentati di monitoraggio successivo all’immissione sul mercato</td> </tr> <tr> <td>AI Act</td> <td>Art. 73</td> <td>Incidenti gravi segnalati entro 15 giorni, o 10 e 2 giorni in casi specifici</td> </tr> <tr> <td>NIST AI RMF</td> <td>MEASURE 2.4, MANAGE 4.1</td> <td>Comportamento in produzione confrontato con i risultati pre-rilascio</td> </tr> <tr> <td>ISO/IEC 42001</td> <td>Clausola 9.1, controllo dell’Allegato A su funzionamento e monitoraggio</td> <td>Monitoraggio, misurazione e valutazione delle prestazioni del sistema di IA</td> </tr> <tr> <td>Banche USA</td> <td>SR 26-2 (aprile 2026)</td> <td>Gestione del rischio di modello basata sul rischio, sostituisce SR 11-7</td> </tr> </table> Il monitoraggio successivo all’immissione sul mercato. L’articolo 72 obbliga i fornitori di sistemi ad alto rischio a istituire e documentare un sistema di monitoraggio che raccolga e analizzi in modo attivo e sistematico i dati sulle prestazioni per tutta la vita del sistema. Il piano fa parte della documentazione tecnica dell’Allegato IV. Il testo originale prevedeva un atto di esecuzione della Commissione, con modello di piano, entro il 2 febbraio 2026. Il regolamento (UE) 2026/1744, l’Omnibus digitale sull’IA pubblicato in Gazzetta ufficiale il 24 luglio 2026, lo ha sostituito con linee guida della Commissione, comprensive di modello, attese entro il 2 settembre 2027. Gli obblighi per i sistemi ad alto rischio autonomi dell’Allegato III si applicano ora dal 2 dicembre 2027, quelli per i sistemi integrati in prodotti dell’Allegato I dal 2 agosto 2028. Non serve aspettarlo: gli elementi di un piano credibile sono già noti. Il NIST AI RMF. La sottocategoria MEASURE 2.4 stabilisce che funzionalità e comportamento del sistema di IA siano monitorati in produzione, e il playbook del NIST cita la deriva come motivo esplicito. Chiede di confrontare le metriche di produzione con i risultati dei test pre-rilascio e di generare allerte quando le distribuzioni di input o di previsioni divergono. Il nostro approfondimento sulla gestione del rischio IA mostra come far convergere i due quadri. Le banche: BCE, Banca d’Italia e il vuoto americano. Per una banca italiana il riferimento è la Guida BCE ai modelli interni, rivista a luglio 2025 con una nuova sezione sul machine learning (spiegabilità, prestazioni rispetto alla complessità, validazione): la deriva del modello rientra in ciò che la vigilanza, BCE o Banca d’Italia, si aspetta di vedere monitorato. Sul fronte statunitense, il 17 aprile 2026 la Federal Reserve ha pubblicato la SR 26-2, che sostituisce la storica SR 11-7 del 2011 e la SR 21-8, affiancata da un bollettino parallelo dell’OCC. Una nota esclude i modelli di IA generativa e agentica, in attesa di una richiesta di informazioni: proprio i modelli più esposti alla deriva lato fornitore restano fuori dalla guida. La nostra guida alla gestione del rischio di modello approfondisce la transizione.

Deriva del modello o modifica sostanziale? La decisione di riaddestrare

Il riaddestramento è la cura standard della deriva del modello, e apre una questione giuridica che quasi tutte le guide tecniche saltano. Secondo l’articolo 3, punto 23, è modifica sostanziale una modifica successiva all’immissione sul mercato che non era prevista né pianificata nella valutazione iniziale della conformità e che incide sulla conformità del sistema o ne modifica la finalità prevista. Una modifica sostanziale comporta una nuova valutazione della conformità. L’articolo 43, paragrafo 4 offre una via d’uscita. Per i sistemi che continuano ad apprendere, le modifiche al sistema e alle sue prestazioni predeterminate dal fornitore al momento della valutazione iniziale e descritte nella documentazione tecnica non costituiscono modifica sostanziale. La conseguenza pratica è netta: il perimetro di riaddestramento va scritto prima del lancio, non improvvisato dopo un’allerta. Un perimetro difendibile precisa:

1. Che cosa può cambiare. Per esempio i pesi del modello, tramite riaddestramento sullo stesso insieme di variabili e sulle stesse fonti. Non nuove variabili, non una nuova famiglia di modelli.
2. I dati utilizzabili. Fonti, finestre temporali, controlli di qualità e verifiche di rappresentatività richieste dall’articolo 10.
3. I criteri di accettazione. Accuratezza minima, calibrazione ed equità per sottogruppo che un modello riaddestrato deve raggiungere prima del rilascio, agganciate alle metriche dichiarate ai sensi dell’articolo 15, paragrafo 3.
4. Il metodo di validazione. Disegno del campione di test, confronto con il modello in produzione, ruoli di approvazione.
5. Il confine. Quali modifiche escono dal perimetro e fanno scattare una verifica di modifica sostanziale.

La logica ricalca la guida della Food and Drug Administration statunitense, finalizzata nel dicembre 2024, sui piani di controllo delle modifiche predeterminate (PCCP) per i dispositivi medici con IA: descrivere in anticipo modifiche previste, metodo di sviluppo e validazione, valutazione d’impatto.

Come rilevare la deriva del modello

Il rilevamento lavora su due livelli, e un programma maturo li presidia entrambi. Monitoraggio delle prestazioni sugli esiti reali. Quando gli esiti arrivano (il prestito va in default o no, il sinistro si rivela fraudolento o no), si confrontano le previsioni con la realtà e si seguono accuratezza, richiamo, calibrazione e tassi di errore per sottogruppo rispetto alla baseline dichiarata. È l’unica misura diretta della deriva del modello. Il limite è il ritardo: nel credito servono mesi. Monitoraggio delle distribuzioni come allarme precoce. Poiché le etichette arrivano tardi, si osservano input e output:

• Population Stability Index (PSI), che confronta distribuzioni suddivise in classi tra una finestra di riferimento e una finestra corrente. Una regola pratica molto diffusa legge un valore sotto 0,1 come stabile, tra 0,1 e 0,25 come spostamento moderato, sopra 0,25 come spostamento significativo. Sono convenzioni, non norme: ogni soglia adottata va motivata nel piano di monitoraggio.
• Test di Kolmogorov-Smirnov per le variabili continue e chi quadrato per quelle categoriali.
• Distanza di Wasserstein e divergenza di Jensen-Shannon quando serve misurare l’ampiezza dello spostamento più che un p-value.
• Deriva delle previsioni: la distribuzione dei punteggi o delle classi emessi dal modello, che si muove prima che le etichette confermino qualcosa.

Due cautele. Primo, sui grandi volumi i test statistici segnalano come significativi spostamenti trascurabili: vanno accoppiati a soglie di effect size. Secondo, un data drift senza perdita di prestazioni è frequente. Un’allerta deve aprire un’indagine, non avviare un riaddestramento automatico. Sul ruolo dei benchmark nella baseline, si veda la guida al benchmark AI.

La deriva del modello negli LLM e nei modelli di terzi

I grandi modelli linguistici derivano in un modo per cui gli strumenti MLOps classici non sono stati pensati: spesso il cambiamento avviene dal lato del fornitore. In uno studio molto citato, Chen, Zaharia e Zou hanno confrontato le versioni di GPT-4 di marzo e giugno 2023: l’accuratezza nel distinguere numeri primi da numeri composti è scesa dall’84% al 51%, e anche il rispetto delle istruzioni è peggiorato. Per un deployer, la deriva del modello linguistico è quindi un rischio di terze parti tanto quanto un rischio tecnico. I controlli:

• Bloccare le versioni quando il fornitore offre snapshot datati, e considerare gli alias mobili non approvati per gli usi ad alto rischio.
• Eseguire un set di valutazione fisso (prompt di riferimento, test di rifiuto, controlli di formato) a ogni cambio di versione e a cadenza regolare, conservandone i risultati.
• Prevedere contrattualmente il preavviso: notifica anticipata di aggiornamenti e dismissioni, accesso alle note di rilascio. La nostra guida alla due diligence dei fornitori IA elenca le clausole.
• Sorvegliare anche gli input. Utenti e corpus documentali dei sistemi con retrieval cambiano, e spostano gli output senza alcun aggiornamento del fornitore.

Un piano di monitoraggio della deriva del modello che regge all’audit

Qualunque forma prenda il modello della Commissione, un piano che copre questi sette punti regge davanti ad articolo 72, ISO/IEC 42001 e NIST.

1. Perimetro e responsabilità. Quali versioni del modello, quali casi d’uso, e un responsabile nominativo delle decisioni sulla deriva. Collegate ogni modello alla sua scheda nel vostro registro dei sistemi di IA.
2. Metriche e baseline. Le metriche di accuratezza dichiarate nelle istruzioni per l’uso, le metriche di equità per sottogruppo e le metriche di distribuzione usate come allarme precoce, ciascuna con il valore di riferimento e il dataset da cui proviene.
3. Fonti dei dati. Dove vengono registrati input, previsioni ed esiti in produzione (i log dell’articolo 12 sono la fonte naturale) e come il feedback dei deployer arriva al fornitore.
4. Cadenza. Con quale frequenza ogni metrica viene calcolata e riesaminata, e da chi.
5. Soglie ed escalation. Livelli di attenzione e di intervento per ogni metrica, e chi viene avvisato a ciascun livello.
6. Procedura di risposta. I passaggi dall’allerta alla decisione, compresa la verifica di modifica sostanziale e quella di incidente grave.
7. Registrazioni. Ogni allerta, indagine, decisione, ciclo di riaddestramento e risultato di validazione, conservati insieme alla documentazione tecnica.

Le registrazioni sono la parte più trascurata. Un cruscotto passato dal rosso al verde non prova nulla se nessuno sa mostrare che cosa è stato deciso nel mezzo. È il terreno più ampio del monitoraggio della conformità dei sistemi di IA: la deriva del modello ne è un capitolo concreto.

Rispondere alla deriva del modello: un piano d’azione in cinque passi

1. Qualificare la causa. Escludere prima i difetti di pipeline: modifiche di schema, join interrotti, cambi di unità di misura, valori mancanti.
2. Valutare l’impatto. Le prestazioni sugli esiti etichettati sono sotto i criteri di accettazione? Per quali sottogruppi? Quali decisioni ne sono state toccate?
3. Contenere. In base alla gravità: aumentare la quota di revisione umana, stringere le soglie decisionali, tornare a una versione precedente o sospendere le decisioni automatizzate. Le misure di sorveglianza umana previste dall’articolo 14 dovrebbero già definire questi interruttori.
4. Correggere. Riaddestrare o ricalibrare dentro il perimetro documentato, validare rispetto ai criteri di accettazione e rilasciare attraverso il normale percorso di approvazione. Se la correzione esce dal perimetro, aprire la verifica di modifica sostanziale prima del rilascio.
5. Segnalare e imparare. Se la deriva del modello ha prodotto un esito che rientra nella definizione di incidente grave dell’articolo 3, punto 49, scatta il termine dell’articolo 73: 15 giorni come regola generale, 10 giorni in caso di decesso, 2 giorni per violazioni diffuse o per perturbazioni gravi di infrastrutture critiche. La nostra guida alla segnalazione degli incidenti IA dettaglia la procedura. In ogni caso, l’esito rientra nel processo di gestione del rischio, come chiede l’articolo 9, paragrafo 2, lettera c), soprattutto per i sistemi di IA ad alto rischio.

Domande frequenti

Che cos’è la deriva del modello, in parole semplici? La deriva del modello si verifica quando un modello di machine learning peggiora dopo il rilascio perché i dati che riceve, o il loro significato, sono cambiati rispetto all’addestramento. Si vede da accuratezza in calo, punteggi mal calibrati o errori crescenti per alcuni gruppi. Capita in quasi tutti i sistemi in produzione: va monitorata, non data per esclusa. Qual è la differenza tra data drift e deriva del modello? Il data drift è un cambiamento nella distribuzione degli input del modello. La deriva del modello è la perdita di prestazioni che ne deriva. Può esserci data drift senza deriva del modello, se il modello generalizza bene sui nuovi input, e può esserci deriva del modello senza data drift visibile, quando il concept drift cambia il rapporto tra input ed esiti. Monitorate entrambi: distribuzioni come allarme, prestazioni come conferma. Che cos’è la deriva nei modelli linguistici (LLM)? È un cambiamento del comportamento di un modello linguistico nel tempo. Può derivare dall’aggiornamento del modello da parte del fornitore sotto lo stesso nome, da cambiamenti nei prompt, nel comportamento degli utenti o nei documenti recuperati, oppure da un fine-tuning. Una ricerca su GPT-4 ha misurato forti oscillazioni di prestazioni tra versioni distanti tre mesi. Contromisure: versioni bloccate, set di valutazione fisso, preavviso contrattuale. Riaddestrare un modello per correggere la deriva del modello è una modifica sostanziale ai sensi dell’AI Act? No, se il riaddestramento era predeterminato. L’articolo 43, paragrafo 4, stabilisce che le modifiche pianificate dal fornitore al momento della valutazione iniziale della conformità e descritte nella documentazione tecnica non sono modifiche sostanziali. Un riaddestramento che cambia variabili, fonti dei dati o finalità prevista, oppure che non rispetta i criteri di accettazione documentati, può invece esserlo e richiederebbe una nuova valutazione della conformità. Ogni quanto va controllata la deriva del modello? Non esiste una frequenza fissata dalla legge. La cadenza si stabilisce in base al rischio e alla velocità con cui cambia il dominio: controlli delle distribuzioni quotidiani o continui per le decisioni ad alto volume, riesami settimanali o mensili delle prestazioni dove arrivano le etichette, e una revisione formale almeno annuale. La motivazione va documentata nel piano di monitoraggio successivo all’immissione sul mercato, perché è esattamente ciò che un valutatore verificherà. La deriva è un incidente grave ai sensi dell’articolo 73? Di per sé no. Diventa oggetto di segnalazione quando porta, direttamente o indirettamente, a un esito compreso nella definizione dell’articolo 3, punto 49: decesso o grave danno alla salute, perturbazione grave e irreversibile di infrastrutture critiche, violazione degli obblighi a tutela dei diritti fondamentali, danno grave a beni o all’ambiente. Un modello di credito in deriva che discrimina su larga scala può ricadere nell’ipotesi dei diritti fondamentali.

Conclusione

La deriva del modello è una certezza; ciò che cambia da un’organizzazione all’altra è la capacità di dimostrare di averla gestita. Gli strumenti tecnici esistono già. Il lato scoperto è la governance, perché AI Act, GDPR e vigilanza bancaria pongono la stessa domanda con parole diverse: il modello ha continuato a fare ciò che avevate dichiarato, e potete dimostrarlo? La risposta passa da tre documenti scritti prima del lancio: metriche dichiarate con le relative baseline, un piano di monitoraggio con soglie e responsabili, un perimetro di riaddestramento che tiene le correzioni ordinarie fuori dal terreno della modifica sostanziale. Poi tenete le registrazioni. AI Sigil collega ogni modello del vostro registro al suo piano di monitoraggio, alle decisioni prese sulla deriva del modello e alle relative evidenze, così che la risposta a un revisore sia un report e non una ricostruzione.