Dati sintetici e dati anonimizzati: cosa significa la differenza

Dati sintetici e dati anonimizzati sembra una scelta tra due varianti della stessa cosa, e trattarla come tale causa problemi reali. Uno dei due non è mai appartenuto a nessuno; l’altro apparteneva a qualcuno ed è stato trattato per rimuoverlo. La differenza decide chi può vedere i dati, per quanto tempo possono essere conservati e se possono essere condivisi al di fuori dell’organizzazione.

Questo articolo espone i quattro approcci che le persone usano effettivamente per i dati di test, cosa ciascuno garantisce e non garantisce, e perché la combinazione dei campi è il dettaglio che in silenzio sconfigge la maggior parte dei tentativi di rimozione.

I quattro approcci, a confronto

La maggior parte dei dataset di test è prodotta con uno di quattro metodi, e spesso vengono descritti con la stessa parola.

Solo il primo parte dal nulla. Gli altri tre iniziano tutti da record reali, ed è per questo che ciascuno eredita un obbligo che il primo non ha mai avuto.

Perché rimuovere i nomi non rende anonimo un dataset?

Perché un nome è solo uno dei molti modi per individuare una persona, e di solito non il più affidabile. Una tabella con la colonna del nome rimossa ti dice comunque che una donna sulla trentina lavora presso un particolare piccolo datore di lavoro in una particolare piccola città, e in quella popolazione potrebbe esserci esattamente una persona così. Nulla è stato anonimizzato; l’identificatore è stato semplicemente sostituito da un insieme di identificatori che richiedono uno sforzo lievemente maggiore.

La versione statistica dello stesso problema è che qualunque dataset porta quasi-identificatori — valori che non sono unici da soli ma diventano unici in combinazione. Data di nascita, codice postale, genere e occupazione sono l’insieme classico, e l’aritmetica è implacabile: una combinazione che sembra ampia in un intero paese può essere unica all’interno di una città, e un database di test è di solito una fetta di un solo mercato anziché un campione del mondo.

La re-identificazione quindi non è esotica. È la conseguenza ordinaria del combinare poche colonne con informazioni pubblicamente disponibili, e diventa più facile con ogni dataset aggiuntivo che si rende disponibile. È per questo che un’affermazione onesta di anonimizzazione deve affrontare ciò che rimane, non soltanto ciò che è stato cancellato.

Cosa conta davvero come anonimo?

Un dato è anonimo quando gli individui in esso non possono essere identificati da nessuno, con qualunque mezzo ragionevolmente probabile che venga usato — che è una condizione più forte di quanto la maggior parte dei team presuma, perché include informazioni detenute altrove. In pratica, ciò significa che un’adeguata affermazione di anonimizzazione si basa su una valutazione documentata: quali campi sono stati rimossi o generalizzati, come appare la popolazione risultante, cosa rimane in combinazione e perché l’identificazione non è ragionevolmente possibile.

Due conseguenze meritano di essere prese sul serio. Primo, la valutazione è specifica di un dataset e di un contesto, quindi un approccio che funziona per una release potrebbe non funzionare per la successiva se vengono aggiunte nuove colonne. Secondo, la valutazione è davvero difficile, perché dimostrare un negativo sull’identificazione è molto più lavoro che dimostrare che una colonna di stringhe è stata rimossa.

Dove la difficoltà è alta, la risposta onesta di solito è smettere di chiamare anonimi i dati. Pseudonimizzato, limitato o solo interno sono tutte descrizioni difendibili; anonimo è un’affermazione che va guadagnata.

Quale approccio dovrebbe usare un ambiente di test?

Dati sintetici, nella grande maggioranza dei casi, perché rimuovono l’obbligo invece di gestirlo. Un dataset generato da regole e da un input fisso non contiene alcun individuo, quindi non c’è alcun orologio di conservazione, alcuna questione di consenso, alcuna richiesta di rimozione da soddisfare e alcuna violazione da segnalare se viene divulgato. Può essere versionato in un repository di test, inviato per email tra team e incollato in un ticket senza un secondo pensiero su di chi siano le informazioni che contiene.

Evita anche un problema pratico che i dati camuffati continuano a generare: la mappatura. I dati pseudonimizzati hanno bisogno di una mappatura conservata da qualche parte, e quella mappatura è essa stessa un dataset sensibile che deve essere protetto, ruotato e sottoposto ad audit. I team spendono regolarmente più sforzo a proteggere la mappatura di quanto avrebbero speso a generare i dati.

Ciò che i record sintetici non fanno è riprodurre automaticamente ogni proprietà dei dati reali. Se un test dipende dalla distribuzione — la frequenza di un caso limite raro, la correlazione tra due campi, la forma di una coda lunga — questa deve essere modellata di proposito anziché ereditata. I requisiti di coerenza dei campi sono un esempio calzante: un generatore deve essere costruito per mantenere d’accordo i campi correlati, perché la sola casualità non lo farà.

Come si mantiene riproducibile un dataset generato?

Rendendolo una funzione di un input che controlli anziché dell’orologio o di una fonte casuale che non puoi riprodurre. La disposizione abituale è un seed: un valore breve, registrabile da un umano, che guida ogni decisione presa dal generatore, così che lo stesso seed produca gli stessi record su qualunque macchina e in qualunque giorno.

La riproducibilità conta per tre ragioni facili da dimenticare sotto pressione di tempo. Un test automatizzato può conservare un campione fisso e asserire su di esso, così un guasto è diagnosticabile anziché un lancio di moneta. Una segnalazione di bug può nominare il record esatto che ha visto, così chiunque può ricostruirlo sulla propria macchina. E una revisione può riprodurre esattamente una dimostrazione, cosa che conta quando un dataset viene offerto come prova che non sono coinvolti record reali.

I record generati dal generatore di identità e dati di test funzionano in questo modo, e i valori seguono le convenzioni di formattazione reali di ogni paese pur restando interamente inventati. Sono record sintetici destinati solo ai test software; non descrivono una persona reale e non possono essere usati per sostituirne una né per superare alcuna verifica reale.

Come si dimostra che un dataset di test non contiene record reali?

Essendo in grado di descrivere da dove proviene ogni valore. Questa è una questione di provenienza, e viene risolta al momento della generazione anziché al momento dell’audit. Un dataset prodotto eseguendo un generatore con un seed noto, da un generatore che non legge alcuna fonte di produzione, ha una risposta di una riga. Un dataset prodotto trasformando un’esportazione di produzione ha una risposta che dipende dal fatto che la trasformazione sia corretta, e l’onere di dimostrarlo non svanisce mai del tutto.

Due abitudini rendono durevole la provenienza. Etichetta i dati stessi — una colonna o un’intestazione che contrassegna le righe come sintetiche — così che una copia che viaggia dentro un ticket, un foglio di calcolo o uno screenshot annunci comunque cosa è. E tieni il passo di generazione sotto controllo di versione, così che produrre di nuovo lo stesso dataset sia un comando anziché una storia tramandata a voce.

C’è un controllo finale che vale la pena applicare a qualunque dataset che dichiari di essere sicuro: prova a identificare una persona al suo interno. Se il tentativo riesce anche una sola volta, l’affermazione era esagerata, e la risposta corretta è un’affermazione più ristretta anziché più rumorosa.

Per gli sviluppatori: seed, distribuzioni e affermazioni oneste

Progetta il generatore in modo che ogni decisione casuale scorra dal seed attraverso un unico percorso documentato. Due generatori che accettano entrambi un seed ma consumano la casualità in ordini diversi discordaranno, e la discordanza sembrerà un bug nel test anziché nel generatore.

Modella la distribuzione di proposito. I dati reali hanno quantità irregolari di tutto, e un’estrazione uniforme produce un dataset troppo ordinato: nessun nome raro, nessuna età insolita, nessun campo assente. Se il test ha bisogno di una coda lunga, il generatore deve produrne una di proposito, e questa è una questione di specifica sui dati anziché una proprietà che emerge.

Mantieni l’affermazione sui dati ristretta e vera. Sintetici e generati per i test è un’affermazione che può essere verificata leggendo il passo di generazione. Per un revisore vale molto più di un’affermazione più ampia sull’anonimato che nessuno può riprodurre. E porta il vincolo nelle note delle fixture: i record prodotti in questo modo esistono per esercitare il software, non per impersonare qualcuno né per essere offerti da qualche parte come identità reale.

Passi successivi

Trova un dataset nei tuoi ambienti di test di cui nessuno sa indicare l’origine e risali alla sua provenienza; quella risposta è di solito più interessante del dataset stesso. Poi sostituiscilo con un lotto generato e registra il seed accanto ai dati, così che chiunque possa ricostruirlo. Se stai soppesando le alternative, l’articolo sulle regole sulla privacy per i dati di test copre ciò che ogni scelta ti obbliga a fare in seguito.