Quando un’azienda deve analizzare dati reali senza esporre subito nomi, email o codici fiscali, la protezione non può limitarsi a nascondere una colonna del database. La pseudonimizzazione dei dati offre un modo pratico per ridurre il rischio di identificazione, mantenendo però la possibilità di collegare nuovamente le informazioni alla persona autorizzata. Vediamo come funziona, cosa richiede il GDPR, quali tecniche usare e quali errori evitare.
La pseudonimizzazione riduce il rischio senza cancellare l’identità
- Obiettivo: sostituire gli identificativi diretti con codici o token.
- GDPR: i dati pseudonimizzati restano dati personali.
- Sicurezza: la tabella di corrispondenza va separata e protetta.
- Tecniche: tokenizzazione, cifratura, hashing con chiave e identificativi casuali.
- Limite: pseudonimizzare non significa anonimizzare.
Che cos’è e come funziona nella pratica
La pseudonimizzazione consiste nel trattare i dati in modo che non possano essere attribuiti immediatamente a una persona specifica senza utilizzare informazioni aggiuntive conservate separatamente. Al posto di “Laura Bianchi”, per esempio, un sistema può mostrare il codice “UT-84721”.
Il collegamento tra il codice e l’identità originale viene custodito in una tabella distinta, spesso chiamata mapping table o tabella di corrispondenza. Solo gli utenti autorizzati, seguendo una procedura precisa, possono consultarla per risalire all’interessato.
Immaginiamo un negozio online che vuole studiare gli acquisti ricorrenti. Il team marketing può lavorare con un identificativo cliente, la fascia d’età e la categoria dei prodotti acquistati, senza visualizzare nome, indirizzo e numero di telefono. Se il servizio clienti deve gestire un reso, invece, può usare il codice per recuperare l’identità attraverso un accesso separato.
La mia regola è semplice: il codice non deve essere una scorciatoia per chiunque abbia accesso al database operativo. Una pseudonimizzazione efficace separa dati utilizzabili e chiave di reidentificazione, limitando anche chi può collegarli.
Pseudonimizzazione, anonimizzazione e cifratura non sono la stessa cosa
Queste tecniche vengono spesso confuse, ma producono risultati diversi. La distinzione è importante perché determina gli obblighi dell’organizzazione e il livello di protezione realmente ottenuto.
| Tecnica | Che cosa succede | Il GDPR continua ad applicarsi? | Uso tipico |
|---|---|---|---|
| Pseudonimizzazione | L’identità viene sostituita da un codice, ma può essere recuperata con informazioni separate. | Sì | Analisi, ricerca, CRM e ambienti di test |
| Anonimizzazione | Il collegamento con la persona viene eliminato in modo effettivamente irreversibile. | Non per i dati realmente anonimi | Statistiche pubbliche e report aggregati |
| Cifratura | I dati vengono trasformati e diventano leggibili solo con una chiave. | Sì, finché la chiave consente di recuperarli | Archivi, backup e comunicazioni |
Un file cifrato può tornare leggibile usando la chiave corretta. Un dataset pseudonimizzato può essere ricollegato alla persona attraverso la tabella di corrispondenza. Nell’anonimizzazione, invece, l’obiettivo è impedire la reidentificazione anche combinando il dataset con altre informazioni ragionevolmente disponibili.
Ne deriva un punto spesso sottovalutato: un hash non rende automaticamente anonimo un dato. Se l’algoritmo è prevedibile, il valore originale è facile da indovinare oppure lo stesso hash viene riutilizzato in molti sistemi, il rischio di collegamento resta elevato. Per questo, password, codici fiscali ed email non dovrebbero essere protetti con un semplice hash privo di adeguate misure supplementari.
Che cosa richiede il GDPR a chi la utilizza
Il Regolamento generale sulla protezione dei dati definisce la pseudonimizzazione all’articolo 4, paragrafo 5, e la cita tra le misure utili per la sicurezza del trattamento. Non è però un lasciapassare: il titolare deve continuare a rispettare base giuridica, finalità, minimizzazione, trasparenza e diritti degli interessati.
Il Garante considera questa tecnica una misura che può ridurre i rischi e sostenere i principi di minimizzazione, integrità e riservatezza. La scelta deve comunque dipendere dal rischio concreto, dal tipo di dati, dalle persone coinvolte e dalle conseguenze di una possibile violazione.
I dati restano personali
Finché esiste una possibilità ragionevole di risalire all’interessato, il dataset pseudonimizzato resta composto da dati personali. Continuano quindi ad applicarsi, tra gli altri, gli obblighi relativi alla conservazione, agli accessi, alle richieste degli interessati e alla gestione dei data breach.
La pseudonimizzazione può rendere una violazione meno dannosa, ma non elimina automaticamente l’obbligo di valutarla. In caso di incidente, il titolare deve considerare quali informazioni sono state esposte, se la chiave era separata e quanto fosse realistico ricostruire le identità.
Privacy by design e valutazione del rischio
L’articolo 25 del GDPR invita a integrare la protezione già nella progettazione dei sistemi. L’articolo 32 richiama misure tecniche e organizzative adeguate, tra cui pseudonimizzazione e cifratura, mentre l’articolo 35 può richiedere una valutazione d’impatto quando il trattamento presenta rischi elevati.
Non esiste una soglia universale che imponga sempre la stessa tecnica. Un archivio con dati sanitari e un registro di semplici preferenze di acquisto non hanno lo stesso profilo di rischio. Quello che conta è documentare perché la misura scelta è adeguata e verificare periodicamente se lo rimane.
Come progettare un sistema solido in cinque passaggi
Una buona implementazione parte dal processo, non dal software acquistato. Prima di scegliere uno strumento, definisco quali dati servono davvero, chi deve utilizzarli e in quali momenti è indispensabile conoscere l’identità.
- Mappare gli identificativi. Elencare nomi, email, numeri di telefono, codici fiscali, indirizzi IP e altri elementi che permettono l’identificazione diretta o indiretta.
- Ridurre i dati. Eliminare ciò che non serve allo scopo. Se basta il mese di nascita, non è necessario conservare la data completa.
- Sostituire gli identificativi. Generare token casuali o codici specifici per il trattamento. Evitare codici costruiti partendo da nome, data di nascita o numero cliente.
- Separare la chiave. Conservare la tabella di corrispondenza in un ambiente distinto, con autorizzazioni ristrette, autenticazione forte e registrazione degli accessi.
- Testare e controllare. Verificare tentativi di reidentificazione, qualità dei dati, rotazione dei codici e gestione degli incidenti.
La separazione deve essere anche organizzativa, quando possibile. Il team che produce statistiche non dovrebbe poter recuperare autonomamente la tabella d’identità solo perché tecnicamente si trova nello stesso cloud.
Quale tecnica scegliere
| Soluzione | Punto di forza | Rischio o limite |
|---|---|---|
| Token casuale | Riduce i collegamenti intuitivi con l’identità. | Richiede una tabella di corrispondenza ben protetta. |
| Hash con chiave o HMAC | Consente di riconoscere lo stesso valore senza mostrarlo in chiaro. | La ripetizione dello stesso risultato può facilitare il tracciamento. |
| Cifratura separata | Protegge il dato e permette il recupero controllato. | La perdita o l’abuso della chiave compromette il sistema. |
| Codici rotativi | Limitano la correlazione tra dataset e periodi diversi. | Rendono più complessa l’analisi storica e la riconciliazione. |
Per dati ad alto rischio preferisco spesso una combinazione di tecniche. Un token casuale, una chiave custodita separatamente e codici diversi per ambienti diversi offrono in genere una protezione più realistica rispetto a un singolo algoritmo applicato ovunque.
Dove porta valore a imprese e organizzazioni
La tecnica è utile quando l’azienda deve conservare la possibilità di collegare i dati, ma non vuole distribuire le identità a ogni reparto o fornitore. Il vantaggio non è soltanto normativo: una buona separazione riduce l’esposizione e rende più ordinati i flussi informativi.
Analisi commerciale e marketing
Un’impresa può analizzare frequenza degli acquisti, valore medio dell’ordine e risposta alle campagne usando identificativi pseudonimi. Gli analisti ottengono dati coerenti nel tempo, mentre nome e contatti restano disponibili solo ai sistemi che devono inviare comunicazioni o gestire il rapporto con il cliente.
Ricerca e dati sanitari
Università, ospedali e aziende farmaceutiche possono lavorare su cartelle o risultati clinici sostituendo l’identità con un codice. Qui la protezione deve essere particolarmente rigorosa, perché anche età, località, date e combinazioni rare possono contribuire alla reidentificazione.
Leggi anche: Data Act europeo, cosa cambia per dati, cloud e privacy
Sviluppo software e intelligenza artificiale
Nei test applicativi è spesso inutile usare dati identificativi reali. Un ambiente di sviluppo può ricevere record pseudonimizzati, con campi generalizzati o mascherati, riducendo il rischio che sviluppatori e consulenti accedano a informazioni non necessarie.
Per addestrare o valutare sistemi di intelligenza artificiale, però, la pseudonimizzazione non risolve ogni problema. Un modello può apprendere o ricostruire pattern sensibili, quindi servono anche minimizzazione, controllo degli output, gestione degli accessi e valutazione delle finalità del trattamento.
Gli errori che indeboliscono la protezione
Il primo errore è chiamare “anonimo” un dataset nel quale esiste ancora una chiave di collegamento. Questa confusione porta a cancellare controlli importanti e a sottovalutare gli obblighi previsti per i dati personali.
- Chiave nello stesso ambiente: se database e tabella di corrispondenza condividono gli stessi permessi, la separazione è solo apparente.
- Codici prevedibili: trasformare “mario.rossi1980” in una stringa diversa non offre una protezione sufficiente.
- Riutilizzo universale: lo stesso identificativo in CRM, analytics e assistenza facilita la correlazione tra archivi.
- Dati indirettamente identificativi: piccoli comuni, professioni rare e date precise possono rendere riconoscibile una persona.
- Accessi senza tracciamento: non sapere chi ha consultato la chiave impedisce controlli e indagini efficaci.
- Assenza di procedure: anche la tecnica migliore fallisce se nessuno sa quando autorizzare una reidentificazione.
Un altro errore frequente è pensare che il fornitore cloud o il responsabile IT abbia automaticamente risolto il problema. La responsabilità resta legata alle decisioni del titolare, che deve definire ruoli, istruzioni, tempi di conservazione e verifiche.
Quando i dati sono numerosi, sensibili o condivisi con più soggetti, conviene documentare il flusso con un diagramma e svolgere test periodici. La domanda utile non è soltanto “il dato è nascosto?”, ma chi può identificarlo, con quali informazioni e in quanto tempo.
La scelta giusta dipende dalla possibilità di reidentificare
La pseudonimizzazione è una misura concreta per lavorare con dati utili limitando l’esposizione delle persone. Funziona bene quando il codice, la chiave e i permessi sono progettati insieme, con controlli tecnici e organizzativi coerenti.
Non sostituisce la minimizzazione, la cifratura, la gestione degli accessi o una corretta base giuridica. Prima di adottarla, verifico sempre se il business ha davvero bisogno di poter riconnettere i record: se la risposta è no, una vera anonimizzazione può offrire una protezione più forte, anche se spesso comporta una perdita maggiore di dettaglio analitico.
La decisione migliore nasce quindi da un compromesso misurabile tra utilità del dato e rischio residuo. È questo equilibrio, più della semplice sostituzione di un nome con un codice, a trasformare una tecnica di privacy in una pratica affidabile per l’innovazione digitale.
