Privacy by design applicata a un caso di studio, metodo e visione strategica fin dall’individuazione delle basi giuridiche: sono queste le lezioni più notevoli delle linee guida n. 4/2020 dell’EDPB sull’uso dei dati di localizzazione e degli strumenti di contact tracing nel contesto dell’epidemia Covid-19.
E sono lezioni che hanno una gittata più lunga e implicazioni più vaste rispetto al caso specifico che le ha dettate. L’idea alla base del presente articolo non è allora di seguire punto per punto le indicazioni immediate delle linee guida, è stato già fatto ampiamente nei primi commenti pubblicati, ma di provare a estrarne, più a freddo, e a svilupparne le implicazioni profonde.
Per ragioni di spazio, limitiamo qui le considerazioni alla privacy by design e alla DPIA, concentrandoci solo sulla parte delle linee guida dedicata alla finalità di contact tracing.
Cominciamo con la privacy o, meglio, la data protection by design. La formula è chiara a tutti: vuol dire che la protezione dei dati personali è integrata nella progettazione informatica, anche se poi la data protection by design è spesso ignorata nei fatti o ridotta a minimi interventi di stile. Non in questo caso, tuttavia.
Indice degli argomenti
Misuriamo in concreto la data protection by design
Veniamo allora agli esempi concreti, perché è giusto toccare con mano. Primo esempio: è solo per ragioni di data protection by design che si è deciso di non integrare anche la geolocalizzazione (e, possiamo aggiungere noi, altre fonti incrociabili, es. transazioni con carte di credito) in un tracciamento di contatti basato sulla radiofrequenza di prossimità.
In termini pratici questo ha voluto dire no GPS sì Bluetooth Low Energy. E qui possiamo estrarre subito alcune conseguenze concrete: se questa scelta di tecnologia non è chiara fin dall’inizio, la conseguenza spiacevole è che si investono inutilmente risorse nell’implementazione di una struttura di funzionamento dell’app che va poi riscritta.
Un altro esempio: soluzione centralizzata o decentralizzata? Ossia: raccolta centralizzata in un data center dello storico dei contatti (significativi) di prossimità degli utilizzatori oppure archiviazione sullo smartphone di ognuno di essi, dunque in maniera distribuita, limitando, se del caso, l’upload a un data center unico per i soli soggetti dei quali sia accertata alla positività al virus? È evidente che scegliere una soluzione piuttosto che l’altra determina la riscrittura di ampie porzioni di codice e un ripensamento stesso dei requisiti strutturali del progetto.
Poiché l’uno o l’altro modello sono tecnicamente sostenibili, la scelta vera dipende soltanto da considerazioni di protezione dei dati personali, considerazioni, intendo dire, giuridiche. Qui le linee guida risultano alquanto “sporche” nel ragionamento, perché in due paragrafi presentano una netta preferenza per il modello distribuito, lasciando tuttavia aperta anche l’altra possibilità. Vi si legge in trasparenza un delicato compromesso, e sappiamo per certo che questo è stato, ed è tuttora, uno dei punti più tormentati nel dibattito.
Che cosa sposta l’asse del ragionamento?
Tuttavia, si deve essere più chiari, visto che occorre fornire indicazioni precise agli sviluppatori. Le ragioni giuridiche alla base della soluzione distribuita sono almeno le seguenti: applicazione del principio di limitazione della finalità, art. 5.1.b) GDPR, di quello di minimizzazione, art. 5.1.c) (applicabile anche ai trattamenti, non solo ai dati) e, ad avviso di chi scrive, di quello immanente in tutta la normativa, ossia il diritto di controllo dell’interessato sui propri dati personali. Il diritto di controllo è molto più chiaro e semplice di quanto si pensi, per intenderci è reso assai limpido dallo slogan: what is on your phone stays on your phone.
Se questi principi indicano la soluzione distribuita, non c’è alcuna preferenza possibile, si è obbligati a sceglierla: soddisfa meglio la minimizzazione del trattamento e garantisce maggior controllo, anche perché riduce la possibilità di incroci di dati a livello centralizzato. L’altra soluzione è allora giuridicamente sbagliata? L’elemento che, ad avviso di scrive, sposta veramente l’asse del ragionamento qui è il primo dei principi citati, quello di limitazione della finalità. Detto in termini più diretti: che cosa si vuole veramente fare dei dati raccolti? Se la finalità è quella di contact tracing da parte di un’autorità centrale, occorre domandarsi se essa sia veramente soddisfatta da una soluzione distribuita oppure se quest’ultima non permetta piuttosto di raggiungere la finalità di allerta, che è tuttavia diversa e ha lo scopo di permettere la notificazione di uno stato di rischio a coloro che si siano trovati a prolungato e ravvicinato contatto con un positivo (questa finalità poi, per avere senso, deve incontrare una precisa risposta nel sistema sanitario: tampone).
In altre parole, nel modello distribuito c’è il contact tracing ma è anch’esso distribuito, ognuno fa il proprio contact tracing e quest’ultimo si colloca, se si vuole essere sottili, non al livello della finalità ma a quello dello strumento per raggiungerla, vale a dire per raggiungere la diversa finalità di allerta, che poggia, strumentalmente appunto, sul tracciamento individuale dei contatti.
Se al contrario la finalità è quella di garantire il contract tracing da parte di un’autorità centrale, la scelta dovrà cadere sul modello centralizzato, a meno di non riuscire a sviluppare in ogni caso la soluzione distribuita in modo da permettere ugualmente il raggiungimento di questo scopo.
Non si pone dunque a ben vedere una questione di preferenza tra due modelli equivalenti, ma di chiarezza di idee su ciò che si vuole fare, ossia sulla finalità del trattamento.
Anonimi o pseudonimi?
La questione della possibilità di ricostruire le interazioni significative tra persone ci porta dritti sul tema più complesso dell’intera progettazione: dati personali o informazioni anonime? Anche qui è fondamentale l’approccio by design, perché la regola è che se si possono utilizzare informazioni anonime non è preferibile farlo, si deve necessariamente farlo.
Ma che vuol dire “anonime”? Nel dibattito, purtroppo anche istituzionale, si è assistito a un regresso completo dei concetti giuridici: si è confuso “anonimo” con “senza nome”, quasi che il nome sia l’unico identificatore possibile di un soggetto.
Per questa strada si è arrivati a utilizzare, a livello istituzionale, espressioni come “ID anonimi” (per favore non lo ripetete), che è una contraddizione in termini: per definizione, se individui qualcuno (dunque hai l’“ID”) sei fuori dall’anonimato, visto che connotato definitorio di ciò che è anonimo è proprio di non potersi individuare qualcuno all’interno di un gruppo, con il limite della ragionevole probabilità.
E non conta che tu, con i tuoi soli mezzi, non possa individuarlo, conta che non sia possibile neppure a terzi: si devono infatti considerare tutti i mezzi “di cui il titolare del trattamento o un terzo può ragionevolmente avvalersi per identificare detta persona” (cons. 26 GDPR). Anche un terzo, dunque.
Peraltro, leggiamo nel considerando citato la frase “può ragionevolmente avvalersi” ma dovremmo trovare “è ragionevolmente probabile che si avvalga”, nel testo inglese c’è “reasonably likely to be used”, ed è pacifico – anche dal seguito del cons. 26 – che stiamo parlando di probabilità, non di mera possibilità.
Quei refusi di traduzione che si trasformano in nuovi concetti
È evidente che qui tocchiamo anche il tema della traduzione del GDPR, invero in alcuni punti assai carente. Ci troviamo per esempio in Italia, per ragioni di capricci di traduzione, a confrontarci, temo caso più unico che raro, con il bizzarro concetto di “sufficientemente anonimo” che appare nella versione ufficiale in lingua italiana del considerando 26: “dati personali resi sufficientemente anonimi da impedire o da non consentire più l’identificazione dell’interessato”.
Ebbene è un refuso di traduzione: il testo inglese indica: “personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”. Il testo francese riporta: “données à caractère personnel rendues anonymes de telle manière que la personne concernée ne soit pas ou plus identifiable”.
Noi abbiamo trasformato una congiunzione dal valore consecutivo o modale in un nuova categoria ontologica, quella del “sufficiente anonimato” o dei dati “sufficientemente anonimi”, che confonde tra l’altro pericolosamente la pseudonimizzazione (non “pseudo-anonimizzazione”, per inciso) e l’anonimizzazione.
Mi piace qui citare la battuta di un amico: parlare di dati sufficientemente anonimi è come parlare di una donna sufficientemente incinta (cit. Francesco Pugliese). Il fatto è che l’anonimizzazione (perché di anonimizzazione qui propriamente stiamo parlando) è un punto d’approdo, il risultato di un processo di de-identificazione basato, questo sì, sulla “ragionevole probabilità”.
In quanto punto d’approdo, non ammette gradazioni, sfumature di colore, avverbi come “sufficientemente”, “alquanto”, “abbastanza”, “poco”: l’anonimato o c’è o non c’è. È dunque un risultato: una volta che sei arrivato a stabilire che è ragionevolmente improbabile l’individuazione di un soggetto, la conclusione è che hai un dato anonimo, non un dato sufficientemente anonimo.
Questo non vuol dire che il ragionamento alla base non possa variare nel tempo, ossia che ciò consideri oggi anonimo possa non rivelarsi più tale in futuro: la “ragionevole probabilità” di identificazione, o meglio di individuazione, è infatti un meccanismo delicato, sensibile al tempo e all’evoluzione tecnologica.
Su queste cose l’ex Gruppo di lavoro 29 aveva già costruito un’opinione sofisticata molti anni fa, la n. 5/2014, e spiace notare che invece di avanzare su quella strada siamo tornati indietro, in Italia. Addirittura, quell’opinione, salvo errore dello scrivente, è rimasta fuori dall’analisi fatta in sede governativa.
Sia solo permesso all’autore notare che i problemi, numerosissimi, di traduzione che affliggono il GDPR, e questo in particolare che riguarda il cons. 26, erano già stati segnalati in uno dei primi commentari del 2016, scritto assieme al collega Bolognini e alla dott.ssa Bistolfi (cfr. “il Regolamento privacy europeo”, Milano, pp. 741-742): sarebbe opportuno affrontare i refusi di traduzione prima che esplodano, come avvenuto in questo caso.
Evitiamo la “combo” con il diario sanitario
Veniamo, infine, all’ultimo sviluppo tangibile che possiamo trarre dall’applicazione di un ragionamento in chiave by design: niente diari sanitari in un’app per finalità di contact tracing. Ossia: niente compilazione nell’app di questionari sullo stato di salute attuale e pregresso. Perché? Per il principio di limitazione della finalità: se conveniamo che la finalità è quella di ricostruire i contatti significativi che un soggetto ha avuto, la valutazione (peraltro pericolosamente scivolosa se affidata ad algoritmi) del suo stato di salute rappresenta un trattamento ultroneo: non ne abbiamo cioè bisogno per il puro e semplice contact tracing, ma risponde semmai alla finalità, diversa, di valutazione dello stato di salute (ammesso che non basti a questo un tampone).
È possibile progettare ugualmente un’app a due finalità, ossia tanto di contact tracing quanto di ausilio per una successiva diagnosi medica, separandone le interazioni? Combo di questo tipo sono assai pericolose, essendo ciascuna di queste finalità già delicatissima di suo.
La DPIA non (ancora) svolta: fare prima la casa e poi il suo progetto
La conclusione di questi ragionamenti? Non si può oggi più seriamente pensare di sviluppare un’app (e un sottostante back-end) senza far lavorare in stretta sinergia il privacyista e il progettista/sviluppatore: l’app è il prodotto di entrambi.
Espresso diversamente: data protection by design non vuole banalmente dire anticipare il momento di intervento del privacyista ma costituisce una modalità di lavoro del tutto inedita: in quali altri casi il giurista è dentro allo sviluppo informatico? Data protection by design significa cioè che non solo il privacyista determina e dunque plasma i requisiti strutturali e il successivo sviluppo dell’app, ma che, in modo circolare e paritetico, il progettista/sviluppatore rappresenta al privacyista i limiti e i problemi tecnici che le indicazioni giuridiche pongono.
Per questo l’app è alla fine il lavoro di entrambi. Per questo, in termini assai concreti, non procedere con la data protection by design può voler dire riscrivere intere porzioni di codice, o peggio riscrivere l’architettura sottostante al progetto. Sono spese, è tempo perso.
Tutto questo le linee guida ovviamente non si spingono ad affermarlo, ma la conclusione credo sia sotto gli occhi.
E visto che siamo arrivati fin qui, concludiamo con la DPIA, ossia la valutazione d’impatto, obbligatoria in questo caso (non lo è sempre): le considerazioni appena sviluppate, e dunque la preferenza per una soluzione tecnologica invece che per un’altra (es., no GPS), l’applicazione del principio di minimizzazione e del principio di limitazione della finalità sono già parte della DPIA.
Detto in altri termini: le considerazioni che abbiamo svolto finora, tolte le coloriture, stanno perfettamente in una DPIA, sono proprio elemento costitutivo dei ragionamenti che occorre percorrere.
Così come la data protection by design va fatta durante la progettazione/sviluppo dell’app, non dopo, la DPIA va fatta prima, durante e dopo la progettazione/sviluppo dell’app, non soltanto dopo, perché è da lì che si deducono proprio le specifiche “privacy” e tecnico-informatiche da declinare nell’app (e nel relativo, fondamentale, back-end).
In Italia, abbiamo fatto finora il contrario, tanto è vero che risulta che la DPIA non sia ancora stata approntata o comunque impostata, se l’autore non si inganna, ma riuscire a conoscere queste cose si è rivelato impossibile anche attraverso accorate lettere aperte.
Il punto è che non si risparmia tempo a fare prima la casa e poi il progetto della casa: si perde tempo, perché si è poi costretti smontare tutto e a rifarlo daccapo. Il modo in cui si è proceduto è francamente incredibile, posto che già le linee guida europee sulla DPIA indicavano chiaramente: “La valutazione d’impatto sulla protezione dei dati va avviata il prima possibile nella fase di progettazione del trattamento anche se alcune delle operazioni di trattamento non sono ancora note”.
Le linee guida n. 4/2020 lo ribadiscono in modo netto: la DPIA deve essere effettuata “prima di implementare le app in questione”. Vero che progettando l’app non stai ancora trattando dati personali, ma è altrettanto vero che stai dando forma all’architettura e allo strumento con cui ti appresti a farlo, e l’architettura e lo strumento devono essere conformi.
In definitiva, data protection by design e DPIA, prima ancora di essere obblighi giuridici, sono esigenze di buon senso. Altrimenti vale la battuta di sapore gattopardesco riportata da Bruce Schneier: “Dobbiamo fare qualcosa, quest’app è qualcosa, dobbiamo fare quest’app”.
