Dati anonimi e GDPR: togliere i nomi basta?
Togliere i nomi basta per rendere anonimo un database?
Un’impresa riceve un archivio di informazioni sui clienti, sui dipendenti o sull’uso di un servizio. I nomi sono stati rimossi e il fornitore presenta il database come anonimo, quindi utilizzabile senza applicare il GDPR. Prima di fare affidamento su questa indicazione, occorre capire quali informazioni rimangano nell’archivio e se, nel contesto concreto, permettano ancora di identificare le persone.
La questione torna al centro dell’attenzione con il provvedimento del Garante per la protezione dei dati personali nei confronti di IQVIA, adottato il 23 settembre 2026 e illustrato nel comunicato del 2 ottobre. L’Autorità ha irrogato una sanzione di 7 milioni di euro per il trattamento di dati sanitari nell’ambito di un progetto che alimentava una banca dati destinata a successive analisi. Fra i punti esaminati vi è proprio l’efficacia delle tecniche di anonimizzazione. La decisione riguarda quel trattamento e le sue caratteristiche: per le altre imprese offre un’occasione per verificare come vengono raccolti, trasformati e utilizzati i dati.
Quando un dato resta personale
Il GDPR protegge le informazioni riferite a una persona identificata o identificabile. L’identificazione può essere diretta, come avviene con il nome, oppure indiretta, attraverso altri elementi. Un archivio privo di nomi può quindi contenere ancora dati personali, quando le informazioni disponibili consentono ragionevolmente di risalire agli interessati.
Il considerando 26 richiede di valutare i mezzi di identificazione ragionevolmente utilizzabili dal titolare o da altri soggetti, tenendo conto anche di costi, tempi e tecnologie disponibili. Non serve immaginare qualsiasi attacco teoricamente possibile, ma neppure limitarsi a osservare che nell’archivio non compare una colonna denominata “nome e cognome”. L’analisi riguarda ciò che una persona può ricavare dall’insieme delle informazioni e dagli incroci concretamente praticabili.
Si pensi, come esempio ipotetico, a un archivio che conservi l’età esatta, un’area geografica molto circoscritta e una successione di eventi rari. Ciascun elemento, preso da solo, può sembrare poco significativo; la loro combinazione potrebbe rendere riconoscibile un individuo. La valutazione cambia se quei dati vengono sostituiti con fasce più ampie o aggregazioni sufficientemente robuste, purché anche il risultato sia verificato.
La differenza fra anonimizzazione e pseudonimizzazione
La pseudonimizzazione consiste nel trattare i dati in modo che non possano essere attribuiti a uno specifico interessato senza informazioni aggiuntive, custodite separatamente e protette da misure adeguate. È una misura utile: può ridurre l’esposizione delle persone e limitare l’accesso alle loro identità, senza eliminare la necessità di valutare il trattamento.
L’anonimizzazione ha un obiettivo diverso: ottenere informazioni rispetto alle quali la persona non sia o non sia più identificabile secondo il criterio dei mezzi ragionevolmente utilizzabili. Se questo risultato è effettivamente raggiunto, il GDPR non si applica alle informazioni anonime. Le operazioni precedenti svolte su dati personali, compresa la trasformazione che dovrebbe anonimizzarli, rimangono invece da valutare sul piano della liceità.
Sostituire un nome con un codice, anche mediante un algoritmo, non dimostra da solo che il risultato sia anonimo. Occorre esaminare la struttura del database, le informazioni aggiuntive e le possibilità di collegamento. Un codice stabile può consentire di seguire la stessa persona nel tempo; la ricchezza del profilo così ricostruito può aumentare il rischio di identificarla attraverso altre fonti.
Che cosa conta nel caso IQVIA
Il provvedimento esamina dati longitudinali relativi ai pazienti e informazioni che, secondo l’Autorità, mantenevano la possibilità di individuare e reidentificare gli interessati. Il Garante ha inoltre contestato il ruolo di semplice partner tecnologico prospettato dalla società, valorizzando la sua influenza sulle finalità e sui mezzi del progetto.
Il punto utile per chi organizza un trattamento è che l’analisi deve comprendere l’intero processo. Un report finale aggregato non rende automaticamente anonimi i dati individuali utilizzati per produrlo; allo stesso modo, una trasformazione eseguita da un fornitore non esonera il titolare dal verificare le scelte che incidono sul trattamento. I ruoli dipendono dalle attività effettive e dalle decisioni assunte, oltre che dagli accordi sottoscritti.
Perché anche il destinatario dei dati conta
La valutazione richiede attenzione al soggetto e al contesto del trattamento. Nella sentenza del 4 settembre 2025, causa C-413/23 P, relativa al regolamento applicabile alle istituzioni dell’Unione, la Corte di giustizia ha chiarito che dati pseudonimizzati non devono essere considerati personali in ogni caso e per qualsiasi destinatario: misure efficaci possono impedire a un soggetto diverso dal titolare di identificare gli interessati, anche attraverso altri mezzi.
Questa precisazione non consente di qualificare qualsiasi archivio codificato come anonimo. Occorre verificare le possibilità del destinatario e la capacità delle misure di impedire l’attribuzione dei dati alle persone. Restano inoltre distinti gli obblighi del soggetto che li raccoglie e dispone delle informazioni identificative. Nel caso IQVIA, il Garante ha affrontato questa distinzione alla luce del ruolo concretamente svolto dalla società nel progetto.
Le verifiche da fare prima di usare il database
Una verifica utile può partire dal tracciato effettivamente consegnato. La descrizione commerciale del servizio andrebbe confrontata con i campi presenti, la precisione delle informazioni, gli identificatori persistenti e l’eventuale testo libero. Anche poche annotazioni possono contenere dettagli identificativi che il processo automatico non ha eliminato.
È poi opportuno chiedere quali tecniche siano state applicate, come siano state valutate e quali ipotesi sostengano l’analisi del rischio di reidentificazione. Se la valutazione presume che il destinatario non abbia accesso a determinati archivi, quella limitazione deve trovare riscontro nelle condizioni reali di utilizzo. Lo stesso vale per la gestione delle chiavi o di altre informazioni che permettano di ricostruire il collegamento con le persone.
Le misure vanno considerate anche rispetto all’utilità cercata dall’impresa. Se l’obiettivo è conoscere l’andamento complessivo di un servizio, potrebbe non essere necessario mantenere un profilo dettagliato per ciascun utente. Ridurre la granularità o usare dati aggregati può essere un’alternativa da valutare, purché non si presuma che qualsiasi aggregazione elimini il rischio di identificazione, soprattutto quando i gruppi sono molto piccoli.
Se i dati restano personali
Quando l’analisi porta a qualificare le informazioni come personali, il progetto deve essere organizzato secondo il GDPR. Servono una base giuridica adeguata, finalità definite, informazioni agli interessati e misure proporzionate ai rischi. Per i dati relativi alla salute occorre anche una delle condizioni previste dall’articolo 9, oltre alla base di liceità dell’articolo 6.
I dati da conservare e i tempi di conservazione devono essere giustificati; quando ricorrono i presupposti dell’articolo 35 è inoltre necessaria una valutazione d’impatto. La pseudonimizzazione può far parte di queste garanzie, insieme ai controlli sugli accessi e alle altre misure richieste dal trattamento, senza sostituire la verifica dei suoi presupposti.
Per l’impresa che riceve o costruisce un database, il passaggio concreto è raccogliere elementi sufficienti a motivare la qualificazione dei dati e le responsabilità di ciascun soggetto. Una conclusione documentata permette di impostare il progetto correttamente e di rivederlo quando cambiano le informazioni disponibili, le tecnologie o le modalità d’uso. La dicitura “anonimo” deve corrispondere a quel risultato verificato.
