Le organizzazioni che progettano, addestrano o acquistano soluzioni di intelligenza artificiale lavorano sempre più spesso su grandi quantità di dati. In questo scenario, definire un dataset “anonimizzato” può sembrare una scorciatoia rassicurante: se i dati non sono più personali, si pensa, il GDPR non si applicherebbe più. Ma l’anonimizzazione non è un’etichetta da assegnare a valle di una trasformazione tecnica. È una valutazione concreta del rischio di identificazione, collegamento e inferenza.
L’European Data Protection Board (EDPB), l’8 luglio 2026, ha adottato le Linee guida 02/2026 sull’anonimizzazione, aperte alla consultazione pubblica fino al 30 ottobre 2026. Il documento non introduce nuovi obblighi immediatamente applicabili, ma offre un metodo utile per chi deve decidere se un dataset può essere impiegato in analisi, ricerca o progetti IA senza trasformare un rischio privacy in un rischio operativo e reputazionale.
Perché pseudonimizzare non significa anonimizzare
Il punto di partenza è semplice: il GDPR considera personale qualunque informazione riferita a una persona identificata o identificabile. Togliere nome, email o codice fiscale può ridurre l’esposizione, ma non rende automaticamente anonimo un dataset. Se i record possono essere ricondotti a una persona usando altri dati, conoscenze del contesto o informazioni ragionevolmente disponibili, il trattamento resta nel perimetro della protezione dei dati.
La pseudonimizzazione separa o sostituisce gli identificativi diretti, mantenendo però una possibilità di ricollegamento, spesso attraverso una chiave. L’anonimizzazione, invece, deve rendere non ragionevolmente possibile identificare o distinguere l’interessato. È una differenza decisiva per le imprese: la prima è una misura di sicurezza e minimizzazione; la seconda richiede un esame più ampio su dati, destinatari, finalità e capacità tecniche nel tempo.
Questo conta in modo particolare per l’IA. Un dataset di ticket di assistenza, CV, log di utilizzo, recensioni o documenti aziendali può contenere combinazioni apparentemente innocue ma molto distintive. Un modello non vede necessariamente “una persona”; può però apprendere pattern che permettono di associare, isolare o dedurre informazioni su persone reali.
Il test EDPB: isolamento, collegamento, inferenza
Le linee guida propongono un quadro basato su tre criteri. Non è una checklist automatica né una certificazione, ma un modo disciplinato per discutere le assunzioni prima di riusare i dati.
1. Nessun record isolation
Occorre chiedersi se un soggetto può essere distinto dagli altri nel dataset. Un record raro, una combinazione insolita di ruolo, territorio, data e comportamento, oppure una sequenza di eventi molto specifica possono rendere una persona distinguibile anche senza identificatori diretti.
2. Nessun linkage
Bisogna verificare se due o più record relativi alla stessa persona possono essere collegati tra loro, o se il dataset può essere unito a fonti esterne. La domanda non è soltanto “abbiamo una chiave di reidentificazione?”, ma anche “quali fonti esterne sono realisticamente accessibili a chi riceverà questi dati?”.
3. Nessuna inferenza
Va valutato se dal dataset sia possibile dedurre un attributo di una persona con una probabilità elevata. Nelle applicazioni IA questo aspetto è particolarmente delicato: aggregazioni, segmentazioni e correlazioni possono produrre inferenze su caratteristiche, preferenze o situazioni che non erano presenti in modo esplicito nel dato originario.
Se anche uno solo di questi profili rimane problematico, non è prudente concludere che i dati siano anonimi. Serve un’analisi ulteriore e, se i dati restano personali, un percorso GDPR coerente con la finalità effettiva.
La valutazione dipende anche da chi riceve i dati
L’EDPB sottolinea che la valutazione può dipendere dalle capacità dei soggetti coinvolti. Non esiste quindi una tecnica di anonimizzazione valida in astratto per ogni contesto. Un dataset può presentare un rischio diverso se resta in un ambiente controllato, se è condiviso con un fornitore, se viene pubblicato oppure se viene combinato con dati accessibili sul mercato.
Per un’azienda ciò significa evitare formule generiche nei contratti e nella documentazione di progetto. Dire “i dati saranno anonimizzati” è insufficiente se non sono chiari il perimetro dei destinatari, le possibilità di incrocio, le misure di accesso e i test svolti. Anche il passare del tempo è rilevante: nuove fonti disponibili e capacità di analisi più potenti possono modificare la valutazione iniziale.
Cosa cambia in pratica per i progetti IA
La decisione non va lasciata alla sola fase di data preparation. Conviene inserirla nel ciclo di vita del sistema, prima dell’addestramento, del fine-tuning, della condivisione con terzi e del riuso dei dati per finalità diverse.
Una procedura operativa può partire da cinque passaggi:
- mappare finalità, origine, categorie di dati e destinatari del dataset;
- distinguere i dati effettivamente anonimi dai dati pseudonimizzati o ancora personali;
- simulare i tre rischi di isolamento, collegamento e inferenza con scenari realistici;
- documentare misure, limiti, assunzioni e controlli di accesso, compresi quelli richiesti ai fornitori;
- riesaminare la valutazione quando cambiano modello, fonti, finalità, destinatari o capacità di analisi.
Questa disciplina aiuta anche a scegliere il livello corretto di governance. Se i dati sono personali, occorre affrontare in modo esplicito basi giuridiche, informativa, minimizzazione, conservazione, sicurezza, rapporti con responsabili e, quando ricorrono i presupposti, valutazione d’impatto. Se invece l’anonimizzazione è solida e documentata, l’organizzazione può valorizzare i dati con maggiore libertà, senza rappresentare come “privacy-free” un trattamento che non lo è.
Un’occasione per allineare privacy, sicurezza e procurement
L’anonimizzazione è spesso assegnata a un singolo team tecnico. Nei progetti più maturi dovrebbe diventare un punto di incontro tra data owner, IT, sicurezza, privacy, legale e procurement. Il procurement, in particolare, deve chiedere al fornitore come gestisce dati, log, prompt, output, riaddestramento e trasferimenti, non solo quale algoritmo utilizza.
La domanda utile non è “possiamo togliere gli identificativi?”. È: “possiamo dimostrare, nel nostro contesto e rispetto ai destinatari previsti, che il dato non consente più di isolare, collegare o inferire informazioni su una persona?”. Questo sposta la governance dalla dichiarazione alla prova.
Conclusione
Le Linee guida EDPB 02/2026 sono in consultazione, ma il messaggio operativo è già chiaro: l’anonimizzazione va progettata, verificata e riesaminata. Per le imprese che investono nell’IA, è un passaggio concreto per ridurre il rischio e costruire progetti più affidabili.
Se stai valutando l’uso di dati aziendali in un progetto IA, contattami: posso aiutarti a tradurre requisiti privacy e di sicurezza in un percorso di governance pratico e verificabile.
*Nota di trasparenza: questo contenuto testuale e la relativa immagine sono stati realizzati in parte con il supporto di strumenti di intelligenza artificiale, con revisione editoriale umana.*