Collega, ti svelo un segreto che molti consulenti privacy non ti diranno mai: l'anonimizzazione vera è difficilissima. Cancellare il nome non basta. Sostituirlo con [PAZIENTE_001] non basta. Il GDPR Considerando 26 è chiarissimo: un dato è anonimo solo se la re-identificazione è impossibile con mezzi ragionevoli. E con un dataset clinico, raramente lo è. Però c'è un workflow operativo che riduce drasticamente il rischio. Eccolo.
Esempio reale. Cartella di "Mario Rossi, nato 12/3/1962, Frosinone, infarto miocardico 2019, diabete tipo 2, in cura presso Dr. Bianchi". Tu togli "Mario Rossi" e metti [PAZIENTE]. Pensi sia anonimo? In Frosinone, maschio nato il 12/3/1962, paziente del Dr. Bianchi, post-infartuato 2019: lo identifichi in cinque minuti con LinkedIn e una telefonata in segreteria. Questa è pseudonimizzazione, non anonimizzazione. Resta dato personale ai sensi art. 4 GDPR.
Anonimizzazione a quattro livelli
Livello 1: rimozione identificatori diretti. Nome, cognome, codice fiscale, tessera sanitaria, indirizzo, città (se piccola), CAP completo (lascia solo prima cifra), numero di telefono, email, IBAN, numeri cartella clinica, ID paziente interno.
Livello 2: generalizzazione dei quasi-identificatori. Data di nascita diventa fascia di età di dieci anni ("60-69 anni"). Città diventa regione o macroarea ("Nord/Centro/Sud Italia"). Professione diventa categoria ("lavoro sedentario", non "magistrato Tribunale Frosinone"). Date eventi diventano mese/anno o stagione.
Livello 3: rimozione dettagli rari. Patologie ultra-rare che identificano (prevalenza inferiore a uno su centomila). Combinazioni uniche tipo "atleta olimpico con sclerosi multipla". Riferimenti familiari ("figlio del sindaco di..."). Tatuaggi, cicatrici descrittive uniche, segni distintivi che renderebbero il paziente riconoscibile.
Livello 4: verifica k-anonymity. Il dato anonimizzato deve essere indistinguibile da almeno k-1 altri pazienti del tuo database. Per usi clinici si raccomanda k=5 minimo, k=10 per usi di ricerca. Sotto k=3 sei in zona rossa.
Quello che si può fare bene
Esistono modelli di intelligenza artificiale che girano in locale, in Europa, sul tuo server, addestrati specificatamente sul riconoscimento di entità sensibili nel testo clinico italiano. Riconoscono nomi, codici fiscali, indirizzi, date, riferimenti relazionali, e li mascherano. Possono fare un primo passaggio automatico, tu controlli e correggi. Non delegare la verifica finale al sistema: una svista può costare cara.
Per casi d'uso pubblici (ricerca, didattica, condivisione tra colleghi), il workflow è: anonimizzazione automatica con sistema in casa, revisione manuale, k-anonymity check sul dataset, sign-off del DPO se è ricerca strutturata. Per casi d'uso interni (supporto IA in clinica) la regola è più semplice: se il sistema gira in casa, la pseudonimizzazione spinta più i controlli di accesso bastano. Se invece esce dalle tue mura, anonimizzazione vera o non si fa.
Cosa non delegare, mai
La verifica della re-identificazione non si delega. Tu (o il DPO) devi guardare il dataset anonimizzato e chiederti onestamente: con quello che è rimasto, posso ricostruire chi è il paziente se sono motivato? Se la risposta è "forse", il dato non è anonimo.
I modelli di anonimizzazione automatica hanno tassi di errore: capita che lascino un cognome, un indirizzo, una data specifica. Sempre revisione manuale a campione sui dataset prima di qualsiasi uso che esca dalle mura dello studio.
La Cassazione 28985/2019 sulla responsabilità del medico copre anche le scelte sui trattamenti dei dati. Il Garante italiano sul caso Synlab 2024 ha sanzionato 2,5 milioni: una parte sostanziale era proprio per gestione discutibile della pseudonimizzazione spacciata per anonimizzazione.
Le cose che davvero non puoi fare
Anonimizzare "a manina" un dataset di mille pazienti per pubblicare un'analisi: non hai il tempo, e gli errori sono inevitabili. Senza sistema strutturato, qualche identificativo passa sempre. Ed è quello che basta per ricevere la diffida del Garante.
Caricare cartelle "anonimizzate" su servizi cloud non sanitari: anche se la tua anonimizzazione fosse perfetta (raramente lo è), il fornitore cloud può ricombinare i dati con altri datasets. Il linkage attack è uno dei problemi noti della privacy preservation. Sui server in casa il rischio è zero.
I paletti privacy che non si toccano
Server in Europa, modelli in casa, log accessibili, DPA conforme se ci sono fornitori, audit log delle anonimizzazioni e dei controlli effettuati. Sign-off del DPO per i dataset che vengono usati in ricerca. K-anonymity test documentato. Nell'informativa al paziente la voce "uso anonimizzato dei dati per finalità di ricerca/qualità" dichiarata, con possibilità di opt-out.
La regola d'oro
Davanti a un dataset, la domanda è: quanto è sicuro che il paziente non sia ricostruibile? Se la risposta è "abbastanza", non hai un dato anonimo: hai un dato pseudonimizzato che vale come dato personale. Tutti i livelli di protezione GDPR si applicano comunque. Solo se la risposta è "praticamente impossibile la ricostruzione" sei davanti a un anonimo vero.
Una nota personale
Io di mestiere costruisco roba così — sistemi IA privati per medici, studi associati, piccole imprese italiane. Non vendo corsi, non vendo abbonamenti, non vendo formule magiche. Mi occupo di gente che ha cose serie da proteggere e poco tempo per smanettare. Se ti capita di avere domande, sul gruppo Telegram di Super Squalo (t.me/Squalogruppo) si discute di queste cose ogni giorno, e si risponde gratis.
Il dataset anonimizzato bene è uno strumento potente: ti permette ricerca, qualità, condivisione tra colleghi senza rischi. Il dataset anonimizzato male è una bomba che sembra spenta. Vale la pena fare il lavoro a metà? Direi proprio di no.