01
Inventario dei sistemi di IA e data mapping
Non si può valutare ciò che non si è catalogato. Una AI PIA difendibile parte da un inventario completo di ogni sistema di IA, dei dati personali che acquisisce e dei flussi di dati tra entità e responsabili del trattamento. Questo deve essere collegato al registro delle attività di trattamento, non gestito in un silo separato.
Si collega a: gestione del registro dei trattamenti con data mapping cross-entità
02
Limitazione della finalità e analisi della base giuridica
Per ogni caso d'uso dell'IA, documenta la finalità specifica, la base giuridica del trattamento (consenso, interesse legittimo o un altro fondamento valido) e come viene garantita la limitazione della finalità quando i modelli vengono riaddestrati o riutilizzati. Le raccomandazioni della CNIL richiedono espressamente che ogni sistema di IA che utilizza dati personali abbia un obiettivo ben definito, esplicito e legittimo, stabilito fin dall'avvio del progetto.
Fonte: raccomandazioni CNIL sullo sviluppo dell'IA, 2025
03
Classificazione del rischio algoritmico
Classifica ogni sistema di IA secondo i livelli di rischio dell'EU AI Act: inaccettabile, alto, limitato e minimo. Quindi associa tale classificazione alla soglia dell'articolo 35 del GDPR, ossia "suscettibile di presentare un rischio elevato". La CNIL ha dichiarato che, per tutti i sistemi ad alto rischio ai sensi dell'AI Act, una DPIA sarà presunta necessaria quando lo sviluppo o l'implementazione coinvolge dati personali.
Fonte: linee guida CNIL sulle DPIA per i sistemi di IA; framework dei rischi dell'EU AI Act (Regolamento 2024/1689)
04
Transfer Impact Assessment (TIA)
Quando i dati di addestramento, gli output del modello o i dati personali attraversano i confini, è richiesta una TIA accanto alla PIA. Questo è particolarmente critico per le organizzazioni che utilizzano servizi di IA basati su cloud con sub-responsabili in Paesi non adeguati. Un modello di IA addestrato su dati di dipendenti dell'UE, implementato in una controllata statunitense e ospitato da un responsabile del trattamento a Singapore, fa scattare obblighi sovrapposti ai sensi del GDPR, delle leggi statali statunitensi sulla privacy e delle normative locali.
Si collega a: workflow integrati DPIA/TIA e gestione delle SCC
05
Consultazione degli stakeholder e approvazione
L'articolo 35(9) del GDPR impone ai titolari del trattamento di raccogliere il parere degli interessati, ove opportuno. Oltre a questo minimo normativo, una AI PIA dovrebbe coinvolgere ingegneri ML, product owner, l'ufficio legale e il RPD, con approvazione documentata in ogni fase. Le autorità si aspettano di vedere non solo che la consultazione sia avvenuta, ma anche chi è stato consultato e quando.
Fonte: GDPR articolo 35(9); linee guida ICO sui requisiti delle DPIA
06
Misure di mitigazione e documentazione del rischio residuo
Per ogni rischio identificato, documenta la misura di mitigazione, il responsabile, la scadenza di attuazione e il livello di rischio residuo. Le autorità si aspettano che i rischi vengano affrontati, non solo identificati. Ai sensi dell'EU AI Act, i sistemi di IA ad alto rischio richiedono un'identificazione, un'analisi, una stima e una mitigazione continue dei rischi lungo tutto il ciclo di vita del sistema.
Fonte: EU AI Act, articolo 9 (gestione dei rischi); sanzioni per non conformità fino a 35 mln EUR o al 7% del fatturato globale
07
Trigger di ricertificazione e monitoraggio continuo
Definisci gli eventi che fanno scattare una rivalutazione: riaddestramento del modello, nuove fonti di dati, espansione a nuove giurisdizioni o modifiche normative. L'EU AI Act impone ai fornitori di sistemi di IA ad alto rischio di istituire un sistema di monitoraggio post-commercializzazione che raccolga e analizzi in modo attivo e sistematico i dati sulle prestazioni per tutta la durata di vita del sistema. Una valutazione una tantum non è più sufficiente.
Fonte: EU AI Act, articolo 72 (obblighi di monitoraggio post-commercializzazione)