Data Drift e Re-Assessment: quando Aggiornare DPIA e FRIA dopo il Deployment

Fonti: Reg. UE 2016/679 (GDPR) Art. 35, par. 11 — Revisione della DPIA · Reg. UE 2024/1689 (AI Act) Art. 9 — Sistema di gestione del rischio continuo · EDPB — Guidelines on DPIA, par. 7 (Review and update) · NIST — AI Risk Management Framework, sezione Monitor · ICO — Guidance on data protection and AI systems: monitoring and review

Nella pratica della compliance AI, la DPIA viene redatta prima del deployment, approvata, e spesso archiviata. Nel frattempo, il sistema AI continua a operare, i dati su cui è stato addestrato diventano sempre meno rappresentativi della realtà corrente, il modello inizia a degradare, le sue metriche di fairness si modificano, il contesto applicativo cambia. Quando arriva un'ispezione o una due diligence, la DPIA presente in data room descrive un sistema diverso da quello effettivamente in esercizio. Questa situazione, molto comune, è trattata dalle autorità garanti con la stessa severità dell'assenza di DPIA. Per il quadro completo sulla documentazione di compliance, si veda la guida alla valutazione integrata DPIA+FRIA per sistemi AI. Per la DPIA specifica per sistemi RAG con pipeline in evoluzione, si veda la guida alla DPIA per sistemi RAG e AI generativa.

Cos'è il data drift e perché rilevante per la compliance

Il data drift (o distributional shift) è il cambiamento statistico nel tempo della distribuzione dei dati in ingresso al modello rispetto ai dati su cui il modello è stato addestrato. Esistono diverse varianti:

Data drift (input drift). Le caratteristiche degli input del modello cambiano nel tempo. Esempio: un modello di credit scoring addestrato nel 2022 sul comportamento finanziario pre-inflazione riceve nel 2024 pattern di spesa significativamente diversi; il modello applica regole calibrate su una realtà che non esiste più.

Concept drift. Il rapporto tra input e output cambia nel tempo, anche se la distribuzione degli input rimane stabile. Esempio: le caratteristiche che nel 2021 prevedevano la solvibilità di un lavoratore autonomo sono diverse da quelle che la prevedono nel 2025, dopo i cambiamenti nel mercato del lavoro.

Label drift. La distribuzione degli output effettivi (i risultati reali che il modello doveva predire) cambia nel tempo. Esempio: un modello di rilevazione frodi addestrato prima dell'emergere di un nuovo tipo di frode produce falsi negativi sistematici sulle nuove frodi perché il pattern non era presente nel dataset di training.

Fairness drift. Anche se le metriche di performance globale del modello rimangono stabili, le metriche di fairness disaggregate per sottogruppo possono deteriorarsi nel tempo, se la composizione demografica degli utenti cambia.

I trigger obbligatori di re-assessment per DPIA e FRIA

Trigger normativi

L'Art. 35, par. 11 GDPR stabilisce che il Titolare del trattamento deve riesaminare la DPIA "ove necessario", e in ogni caso quando i rischi del trattamento possono cambiare. L'Art. 9 AI Act impone un sistema di gestione del rischio continuo durante tutto il ciclo di vita del sistema AI, non solo nella fase di pre-deployment.

In pratica, i trigger che richiedono obbligatoriamente il re-assessment includono:

Modifiche al modello. Qualsiasi aggiornamento dei pesi del modello (fine-tuning, re-training con dati aggiornati, upgrade alla versione successiva del modello base) richiede la verifica che il rischio documentato nella DPIA rimanga accurato. Non tutti gli aggiornamenti richiedono una DPIA completamente nuova, ma tutti richiedono almeno una valutazione documentata dell'impatto sull'analisi di rischio esistente.

Modifiche al dataset di training. Se il modello viene ri-addestrato con nuovi dati (anche in aggiunta ai dati originali), le caratteristiche del trattamento cambiano: la base giuridica per il nuovo dataset deve essere verificata, il dataset deve essere analizzato per i rischi specifici che introduce.

Cambiamenti nel contesto di deployment. Il sistema viene esteso a nuove categorie di utenti, a nuove aree geografiche, a nuovi casi d'uso rispetto a quelli documentati nella DPIA originale. Un sistema di credit scoring originariamente usato per i prestiti al consumo che viene esteso ai mutui è un sistema diverso che richiede una nuova valutazione.

Rilevazione di incidenti o anomalie. Un incidente di sicurezza, la scoperta di un bias sistematico non previsto, o reclami significativi da parte degli interessati richiedono un re-assessment del rischio e, se la DPIA originale non copriva il tipo di rischio manifestatosi, un aggiornamento della documentazione.

Nuove norme applicabili. L'entrata in vigore di nuovi obblighi normativi (come le disposizioni AI Act per i sistemi ad alto rischio dal 2 agosto 2026, o i decreti attuativi della Legge 132/2025) può richiedere l'integrazione della DPIA con le nuove sezioni richieste.

Come monitorare il data drift in produzione

Il monitoring del data drift è una funzione tecnica che deve essere prevista nell'architettura del sistema fin dal deployment. I componenti principali:

Distribution monitoring. Calcolare periodicamente la distanza statistica tra la distribuzione degli input in produzione e la distribuzione del dataset di training. Metriche comuni: Population Stability Index (PSI), KL divergence, Kolmogorov-Smirnov test. Una soglia di allerta (es. PSI > 0,1) attiva la revisione del modello.

Performance monitoring. Tracciare nel tempo le metriche di performance del modello (accuracy, precision, recall, F1) disaggregate per sottogruppi rilevanti. Un deterioramento delle metriche di fairness per un gruppo demografico può precedere il deterioramento delle metriche globali.

Output monitoring. Analizzare la distribuzione degli output del modello nel tempo: se la percentuale di approvazioni di credito cala o cresce significativamente senza una corrispondente variazione nel profilo degli applicant, è un segnale di drift.

Feedback loop monitoring. Se il sistema riceve feedback sulle decisioni (es. il tasso effettivo di default sui prestiti approvati), confrontare periodicamente le previsioni del modello con gli outcome reali.

Come documentare il re-assessment

Il re-assessment non deve produrre necessariamente un documento completamente nuovo: può essere un addendum alla DPIA originale che documenta:

• La data del re-assessment e il trigger che lo ha attivato
• I cambiamenti intervenuti rispetto alla versione precedente della DPIA (modello, dataset, contesto)
• I rischi nuovi o modificati identificati
• Le misure aggiuntive adottate o le misure esistenti confermate come ancora adeguate
• La conclusione: il rischio residuo rimane nel perimetro accettabile documentato nella DPIA originale, o è necessaria una revisione sostanziale

Conservare la traccia storica di tutti i re-assessment: la sequenza di documenti dimostra che il processo di gestione del rischio è stato continuo, non episodico.

Articolo aggiornato al 27 maggio 2026. L'obbligo di gestione del rischio continua (Art. 9 AI Act) è applicabile ai sistemi ad alto rischio dal 2 agosto 2026. Per supporto specifico, contatta lo studio.