Dati di test senza persone reali: perché lo pseudonimizzato resta personale e il sintetico no

Copiare la produzione è un trattamento, non una scorciatoia

Il riflesso è comprensibile. I dati veri hanno la forma dei dati veri: nomi di ogni lunghezza, indirizzi che non stanno nel modulo, ordini con quaranta righe, la cliente il cui cognome contiene un apostrofo che ha rotto tutto lo scorso marzo. Un dump di produzione ripristinato è il set di prova più fedele che esista, e costa un comando. Il problema è che quel comando è un trattamento in senso giuridico, e il Regolamento ha qualcosa da dire in proposito.

Due dei principi dell'articolo 5 lo toccano direttamente e in modo autonomo. La limitazione della finalità, articolo 5, paragrafo 1, lettera b), esige che i dati personali siano raccolti per finalità determinate, esplicite e legittime e non ulteriormente trattati in modo incompatibile con tali finalità. L'indirizzo è stato raccolto per consegnare un ordine. Riprodurre un difetto di impaginazione non è quella finalità, e se sia compatibile con essa è una domanda vera con una risposta vera che qualcuno deve costruire: il Regolamento dà criteri per la valutazione di compatibilità, non un sì o un no. La minimizzazione, articolo 5, paragrafo 1, lettera c), esige che i dati siano adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità. Una copia integrale di tutti i clienti, per provare una pagina di pagamento, è difficile da descrivere come limitata al necessario.

C'è una dimensione pratica che non ha nulla a che vedere con il diritto e tutto a che vedere con ciò che va storto davvero. Un ambiente di test non ha i controlli di accesso della produzione, né il suo monitoraggio, né le sue regole di conservazione dei backup. Sta su un portatile, in un container che qualcuno ha avviato, in uno snapshot dentro un bucket che nessuno ricorda di aver creato. L'invio di posta è spesso ancora configurato, ed è così che un giro di staging una volta ha scritto a un elenco di clienti veri. L'obbligo di proteggere i dati non si indebolisce perché la macchina si chiama staging, e l'esposizione pratica è lì maggiore che in produzione. I due argomenti puntano nella stessa direzione.

Lo pseudonimizzato resta personale: è qui che ci si sbaglia

L'articolo 4, paragrafo 5, definisce la pseudonimizzazione come il trattamento dei dati personali in modo tale che non possano più essere attribuiti a un interessato specifico senza l'utilizzo di informazioni aggiuntive, a condizione che tali informazioni aggiuntive siano conservate separatamente e soggette a misure tecniche e organizzative. Leggilo una volta: le parole decisive sono senza l'utilizzo di informazioni aggiuntive. Quelle informazioni aggiuntive esistono. Sono conservate da qualche parte. Il collegamento è ancora lì; è stato reso più difficile da seguire, non rimosso.

Il considerando 26 trae la conclusione esplicitamente: i dati personali sottoposti a pseudonimizzazione, che potrebbero essere attribuiti a una persona fisica mediante l'utilizzo di informazioni aggiuntive, dovrebbero essere considerati informazioni su una persona fisica identificabile. In altre parole, i dati pseudonimizzati sono dati personali, dentro l'ambito, con tutti gli obblighi che ne conseguono: diritti di accesso e cancellazione, obbligo di notifica delle violazioni, regole sui trasferimenti. Le Linee guida 01/2025 del Comitato europeo per la protezione dei dati, adottate il 16 gennaio 2025, formulano la stessa conclusione nella sintesi e aggiungono un punto da tenere a mente: vale anche se i dati pseudonimizzati e le informazioni aggiuntive non sono nelle mani della stessa persona.

L'anonimizzazione è un'affermazione diversa e assai più impegnativa. Il considerando 26 dice che i principi di protezione dei dati non dovrebbero applicarsi a informazioni anonime, vale a dire informazioni che non si riferiscono a una persona fisica identificata o identificabile, né a dati resi sufficientemente anonimi da impedire o da non consentire più l'identificazione dell'interessato. Ma lo stesso considerando fissa il criterio: per stabilire se una persona sia identificabile si dovrebbe tener conto di tutti i mezzi ragionevolmente utilizzabili, considerando fattori oggettivi come i costi e il tempo necessari. Un insieme in cui i nomi sono stati sostituiti ma restano codici postali, date di nascita e storici degli ordini spesso non supera quel criterio, perché la combinazione re-identifica. Un'anonimizzazione che regga all'esame comporta di solito distruggere proprio la struttura che l'ambiente di test doveva riprodurre.

I dati sintetici sfuggono all'intero ragionamento non entrandoci mai. Una riga assemblata da un elenco fisso di nomi, un elenco fisso di cognomi e un elenco fisso di città non si riferisce a una persona fisica identificata o identificabile, perché dietro non c'è nessuno e non esistono informazioni aggiuntive che vi condurrebbero. L'articolo 4, paragrafo 1, definisce i dati personali come qualsiasi informazione riguardante una persona fisica identificata o identificabile; se nulla riguarda nessuno, la definizione non è soddisfatta, e il Regolamento semplicemente non raggiunge l'insieme. Nessuna base giuridica, nessuna valutazione di compatibilità, nessun periodo di conservazione, nessuna richiesta di cancellazione che possa mai arrivare. È una differenza di categoria, ed è la ragione per generare.

Che cosa produce davvero questo generatore, misurato

Lo strumento attinge da sei serbatoi per paese — Francia, Regno Unito, Germania, Spagna, Italia e Portogallo — ciascuno con trentadue nomi, trentadue cognomi e dodici città. Fanno 192 nomi, 192 cognomi, 72 città e 6144 nomi completi distinti su tutto lo spazio, e una riga sta in piedi: una persona di Lisboa riceve un nome portoghese e una parte locale dell'indirizzo che ne deriva, non un cognome tedesco su un numero francese. Misurato su quattrocento estrazioni, cento righe danno in media 99,2 nomi distinti e mille righe ne danno 922,5. Il primo nome ripetuto compare verso la riga 100, che è il limite del compleanno su uno spazio di 6144 e non un difetto.

Gli indirizzi email non collidono affatto, perché non sono lasciati al caso. Ogni esecuzione tiene le parti locali già distribuite e aggiunge un contatore a una ripetizione: la seconda Marie Martin riceve marie.martin2 come parte locale. Diecimila righe danno diecimila indirizzi distinti, e duecentomila ne danno duecentomila: misurato sulla funzione che costruisce le righe, dato che il modulo si ferma a mille righe per esecuzione. L'indice UNIQUE che prima respingeva l'import a metà strada, lasciando una tabella riempita a metà, non ha più nulla da acchiappare. Due limiti di questa garanzia vale la pena conoscerli. Il contatore vive quanto una singola esecuzione, quindi due export separati possono ancora ripetersi: tieni un set in un solo file, oppure dai a ogni lotto un prefisso suo. E il numero di nomi distinti non è quello degli indirizzi distinti: una query che conta i clienti per nome anziché per indirizzo arriverà un po' sotto il tuo numero di righe, di circa l'otto per cento a mille righe.

Ogni indirizzo finisce in example.com, example.net o example.org, e in nient'altro. Tutti e tre sono riservati dalla RFC 2606 per fare da esempio, e tutti e tre pubblicano un record MX nullo — lo 0 . della RFC 7505, un dominio che dichiara nel DNS di non accettare posta di alcun tipo — così un mittente si ferma prima ancora di aprire una connessione. È l'accoppiata a contare, ed è più severa di quanto sembri. Un dominio che semplicemente non ha un server di posta non è sicuro: la RFC 5321 fa ripiegare sul record di indirizzo il mittente che non trova un MX, quindi un dominio dall'aria documentaria, con un A vivo e senza MX, resta un bersaglio di consegna. Riservato più MX nullo è ciò che chiude la porta, ed è il motivo per non inventarsi un dominio di esempio proprio.

La colonna del telefono è l'unico punto in cui lo strumento risponde a una domanda lasciando un campo vuoto. La Francia riserva numeri alla finzione: il piano nazionale di numerazione assegna le radici 01 99 00, 02 61 91, 03 53 01, 04 65 71, 05 36 49 e 06 39 98 alle opere audiovisive, e 06 39 98 è l'unica mobile, così una riga francese porta +33 6 39 98 seguito da quattro cifre a caso e nient'altro. Ofcom mette da parte 07700 900000 fino a 07700 900999 per la fiction televisiva e radiofonica, quindi una riga britannica porta +44 7700 900 e tre cifre. La Bundesnetzagentur ha pubblicato due blocchi mobili per le produzioni mediatiche, 0171 3920000 fino a 3920099 e 0176 04069000 fino a 04069099, e una riga tedesca esce da uno dei due. Spagna, Italia e Portogallo non pubblicano nulla di equivalente, perciò le loro righe escono con il campo del telefono vuoto. I paesi sono estratti in modo uniforme, il che significa che circa metà delle righe ha lì uno spazio bianco — 49,99 % su duecentomila righe — e una nota sotto il modulo dice perché, perché una colonna vuota senza spiegazione sembra uno strumento rotto.

Una regola praticabile, e dove si ferma

Genera, non copiare, e fai in modo che i dati generati siano palesemente finti. Usa un dominio riservato per ogni indirizzo invece di un miscuglio, metti nella parte locale un prefisso che nessun account vero porterebbe, e scegli una radice telefonica che il tuo paese riservi alla finzione, se ne ha una. Quel «se ne ha una» merita una risposta, perché per metà dei mercati di questo sito la risposta è no. Francia, Regno Unito e Germania pubblicano ciascuno un blocco; Spagna, Italia e Portogallo non ne pubblicano nessuno. Quello che quei tre hanno invece è spazio per ora non assegnato, che è una promessa molto più debole: un regolatore che non ha ancora distribuito un intervallo può distribuirlo l'anno prossimo, e un set di test scritto oggi starebbe chiamando qualcuno. Dove un intervallo riservato esiste, usalo; dove non esiste, l'output onesto è nessun numero, ed è quello che questo strumento ora fa. Il punto non è giuridico — i dati sintetici restano fuori campo qualunque aspetto abbiano — è che una persona che dà un'occhiata a un ticket di assistenza o a una riga di log deve poter capire in un secondo che quella riga non è un cliente. Un dato che sembra vero viene trattato come vero, ed è così che un indirizzo di prova finisce in una lista di distribuzione.

Dove la generazione si ferma davvero è il difetto che si riproduce solo su un record. A volte il guasto sta nei dati di quel cliente e da nessun'altra parte, e nessuna riga sintetica lo mostrerà. Quel caso non si risolve facendo finta, si risolve stringendo. Estrai il singolo record e non la tabella, prendi solo i campi che il difetto tocca, lavora su una macchina con gli stessi controlli della produzione, registra l'accesso, e cancella tutto quando hai finito. Quello è un trattamento documentato, minimizzato e limitato nel tempo, con una finalità che puoi mettere per iscritto: una cosa completamente diversa da un dump notturno verso un cluster di staging condiviso, ed è la forma che il tuo responsabile della protezione dei dati riconoscerà, perché è quella che il Regolamento è fatto per accogliere.

Domande frequenti

I dati pseudonimizzati restano dati personali secondo il GDPR?

Sì. L'articolo 4, paragrafo 5, definisce la pseudonimizzazione come il trattamento dei dati personali in modo che non possano più essere attribuiti a un interessato specifico senza l'utilizzo di informazioni aggiuntive, e il considerando 26 afferma che i dati pseudonimizzati che potrebbero essere attribuiti a una persona fisica mediante l'utilizzo di quelle informazioni aggiuntive dovrebbero essere considerati informazioni su una persona fisica identificabile. Il Comitato europeo per la protezione dei dati lo ha ribadito nelle sue Linee guida 01/2025 sulla pseudonimizzazione, adottate il 16 gennaio 2025, aggiungendo che vale anche quando i dati pseudonimizzati e le informazioni aggiuntive non sono nelle mani della stessa persona. La pseudonimizzazione è una garanzia che il Regolamento incoraggia, può ridurre il rischio e sostenere una valutazione di compatibilità, ma non porta un insieme di dati fuori dall'ambito di applicazione.

Posso copiare il database di produzione nello staging se poi lo cancello?

Cancellare dopo non rende lecita la copia; limita quanto dura il trattamento, che è un'altra questione. La copia è un trattamento dal momento in cui avviene, ha bisogno di una base giuridica e deve superare la prova della limitazione della finalità dell'articolo 5, paragrafo 1, lettera b): il Regolamento chiede se la nuova finalità sia compatibile con quella per cui i dati sono stati raccolti e dà criteri per valutarlo. L'articolo 5, paragrafo 1, lettera c), si applica in modo autonomo: prendere una tabella intera quando basterebbero tre campi non è limitato al necessario. È esattamente il giudizio per cui esiste un responsabile della protezione dei dati, e la risposta dipende dal tuo settore, dalla tua informativa e da che cosa stai davvero provando. Chiedi prima di lanciare il ripristino, non dopo.

I dati sintetici sono davvero fuori dal GDPR?

Quando sono genuinamente sintetici, sì — ma la parola sta lavorando. Dati assemblati da un elenco fisso di parole, senza alcun apporto da un record reale, non si riferiscono a una persona fisica identificata o identificabile, quindi l'articolo 4, paragrafo 1, non è soddisfatto e il Regolamento non si applica. Il considerando 26 dice che i principi di protezione dei dati non dovrebbero applicarsi a informazioni che non si riferiscono a una persona fisica identificata o identificabile. L'avvertenza è che non tutto ciò che si chiama sintetico è costruito così: un insieme generato da un modello addestrato su record reali è un'altra faccenda, perché il modello ha visto gli originali e l'output può conservarne abbastanza da isolare qualcuno. Se il tuo generatore legge dalla produzione, l'analisi ricomincia da capo. Se legge un elenco fisso di centonovantadue nomi che non sono mai stati di nessuno in particolare, no.

Si può davvero consegnare qualcosa agli indirizzi email generati?

No, e il motivo vale la pena riprenderlo per i tuoi set di test. Ogni indirizzo usa example.com, example.net o example.org. La RFC 2606 riserva tutti e tre come nomi di esempio, quindi nessuno può registrarne uno e mettersi a ricevere posta lì, e tutti e tre pubblicano un record MX nullo: la forma 0 . definita dalla RFC 7505, cioè un dominio che annuncia nel DNS di non accettare posta. Un mittente conforme lo legge e si ferma senza aprire una connessione. L'accoppiata conta: un dominio del tutto privo di MX non è equivalente, perché la RFC 5321 fa ripiegare il mittente sul record di indirizzo, così un dominio plausibile che risolve ma non ha un server di posta resta un bersaglio di consegna. Se scrivi un generatore tuo, prendi i nomi riservati invece di inventarne uno che sembri riservato — e blocca anche la posta in uscita a livello di ambiente, cosa che dovresti fare comunque.

Quante righe posso generare prima che i nomi comincino a ripetersi?

I nomi cominciano a ripetersi verso la riga 100; gli indirizzi email mai. I serbatoi tengono trentadue nomi e trentadue cognomi per ciascuno dei sei paesi, cioè 6144 nomi completi distinti, e il limite del compleanno su uno spazio di quella misura colloca la prima collisione intorno a cento estrazioni — misurata a 99,6 su tremila esecuzioni. A cento righe ottieni in media 99,2 nomi distinti, a mille righe 922,5. Gli indirizzi sono un'altra faccenda: a un nome ripetuto viene aggiunto un contatore nella parte locale, così diecimila righe danno diecimila indirizzi distinti e un indice UNIQUE sulla colonna email non ha nulla da respingere. Un limite a questo: il contatore vale per una singola esecuzione, e il modulo genera al massimo mille righe per volta, quindi se te ne servono di più rilancialo con un altro seed e aggiungi un tuo prefisso per lotto invece di dare per scontato che i due export non possano sovrapporsi.