Privacy by design: la privacy si progetta, non si aggiunge alla fine

Privacy by design è il principio per cui la protezione dei dati personali va pensata prima di scrivere la prima riga di codice, non rincorsa dopo, quando il sistema è già in produzione e il danno è fatto. È l’opposto del modello dominante, quello in cui si raccoglie tutto il possibile, si espone per impostazione predefinita, e alla fine si incolla un banner di consenso e un’informativa sperando che bastino. La privacy by design ribalta questa abitudine: raccogliere il minimo, proteggere per impostazione predefinita, costruire le tutele dentro l’architettura invece che attorno ad essa.

Per anni questa è stata una buona pratica predicata e poco seguita. Poi è diventata un obbligo. Con l’articolo 25 del GDPR la protezione dei dati fin dalla progettazione e per impostazione predefinita è entrata nella legge, e non è più qualcosa che un’organizzazione sceglie di fare se ha tempo e sensibilità, ma qualcosa che deve dimostrare di aver fatto. Il problema è che tra il principio, semplice da enunciare, e la sua realizzazione tecnica c’è una distanza che molti non hanno mai colmato.

Proattivo, non reattivo: i sette principi

I sette principi fondamentali della privacy by design vengono formulati nel 2009 da Ann Cavoukian, allora Commissaria per l’informazione e la privacy dell’Ontario, a coronamento di un approccio che lei stessa aveva sviluppato fin dagli anni Novanta. Sono noti e vale la pena richiamarli: essere proattivi e non reattivi, prevenire invece di rimediare; fare della privacy l’impostazione predefinita; incorporarla nel design dei sistemi; perseguire la piena funzionalità, in una logica a somma positiva e non a scapito di altro; garantire la protezione lungo l’intero ciclo di vita del dato; mantenere visibilità e trasparenza; e rispettare la privacy dell’utente, mettendolo al centro.

Due di questi principi sono quelli che mordono di più nella pratica. Il primo è la privacy come impostazione predefinita: i dati personali devono essere protetti automaticamente, senza che l’utente debba fare nulla, mentre troppi sistemi fanno il contrario, esponendo per default e chiedendo all’utente di rinunciare attivamente. Il secondo è l’incorporazione nel design: la privacy va costruita nell’architettura del sistema, non aggiunta come strato esterno di policy e avvisi. Sono i due punti in cui un principio astratto diventa una scelta di progettazione concreta, e sono anche quelli che la maggior parte delle organizzazioni continua a disattendere.

Da principio a obbligo: l’articolo 25

Il passaggio dalla teoria alla legge è avvenuto con il GDPR, che ha trasformato la privacy by design nell’obbligo di protezione dei dati fin dalla progettazione e per impostazione predefinita. La norma stabilisce due doveri complementari. La protezione fin dalla progettazione chiede di adottare misure tecniche e organizzative adeguate a incorporare i principi di protezione dei dati in ogni sistema che tratta dati personali, citando esplicitamente esempi come la pseudonimizzazione e la minimizzazione. La protezione per impostazione predefinita chiede che, salvo intervento dell’utente, siano trattati solo i dati personali necessari per ciascuna specifica finalità, limitando la quantità raccolta, l’estensione del trattamento, la durata della conservazione e l’accessibilità. Su come attuare concretamente questi due doveri, le Guidelines 4/2019 dell’EDPB sull’articolo 25 offrono il riferimento operativo.

Va detta con precisione una sfumatura che la letteratura specialistica conosce bene. Il quadro di Cavoukian precede il GDPR e ne ha influenzato l’articolo 25, ma i sette principi non sono elencati nella norma, e la loro corrispondenza con il testo di legge è interpretativa, non esplicita. È una distinzione utile per non confondere il riferimento culturale con l’obbligo giuridico: l’articolo 25 è la versione vincolante e operativa del principio, non la trascrizione dei sette punti. Non a caso c’è chi ha definito questa norma il gigante dormiente del GDPR, una previsione potente e a lungo poco applicata.

Privacy by design è un principio, la privacy engineering è il mestiere

Qui sta il nodo che separa le organizzazioni che lo dichiarano da quelle che lo fanno. Un principio non è un controllo, e affermare di seguire la privacy by design è facile quanto è difficile tradurla in un sistema. Quel lavoro di traduzione ha un nome, privacy engineering, ed è la disciplina che converte i principi e gli obblighi di legge in architettura concreta: dove si raccolgono i dati e quanti, come si separano dall’identità delle persone, quali impostazioni predefinite proteggono senza chiedere nulla all’utente, per quanto tempo si conservano, come si applicano le tecnologie che riducono l’esposizione del dato.

È un mestiere ingegneristico a tutti gli effetti, con un proprio vocabolario tecnico, e si appoggia anche all’insieme delle tecnologie per la privacy, dalla pseudonimizzazione all’anonimizzazione fino alle tecniche più avanzate di calcolo che lavorano sui dati senza esporli. È, in sostanza, la controparte per la privacy di ciò che la sicurezza per progettazione è per la sicurezza: non un documento, ma un modo di costruire. Senza questo strato ingegneristico, la privacy by design resta uno slogan nelle slide della conformità, scollegato da come il sistema tratta davvero i dati.

La minimizzazione come pratica centrale

Se si dovesse indicare la singola pratica più potente, sarebbe la minimizzazione dei dati: raccogliere, conservare ed esporre solo ciò che serve davvero a una finalità precisa, e nulla di più. È il cuore tecnico della protezione per impostazione predefinita, ed è anche la difesa più efficace contro le conseguenze di un incidente, per una ragione elementare: ciò che non si possiede non si può perdere. Un sistema progettato per detenere il minimo riduce insieme la superficie di un’eventuale violazione, l’ambito degli obblighi di conformità e il valore di ciò che un attaccante può sottrarre. La minimizzazione lega così la privacy alla riduzione del rischio, e mostra che progettare per la privacy e progettare per la sicurezza, spesso, sono la stessa cosa vista da due angolazioni.

Perché conta adesso

La pressione su questo fronte è cresciuta su più lati insieme. Sul piano normativo, l’articolo 25 è sempre più invocato e sanzionato, e dimostrare la protezione fin dalla progettazione è diventato parte di ciò che un’autorità si aspetta di trovare. Sul piano tecnologico, l’addestramento dei sistemi di intelligenza artificiale su grandi masse di dati personali ha alzato la posta, rendendo le scelte di raccolta e conservazione più consequenziali che mai. E sul piano economico, il costo di aggiungere la privacy a posteriori, fatto di rifacimenti, violazioni e sanzioni, supera quasi sempre quello di averla progettata dall’inizio.

In definitiva, la privacy by design è il riconoscimento che la privacy è una proprietà architetturale e non un documento: non la si può aggiungere alla fine, come non si può aggiungere la solidità strutturale a un edificio già costruito. Il principio è vecchio di oltre quindici anni ed è ormai vincolante per legge; ciò che manca ancora, nella maggior parte delle organizzazioni, è la pratica ingegneristica che lo trasforma in un sistema reale. Chi progetta per la privacy detiene meno dati, ne espone meno e ha meno da perdere, e scopre che la privacy ben fatta non è un freno alla funzionalità ma, spesso, una forma più matura di sicurezza.