Privacy by design: progettare l’errore, non dipendere da utenti perfetti

Occorre interpretare la privacy by design come criterio di progettazione dell’errore, più che come semplice obbligo di conformità formale.

A partire dall’articolo 25 GDPR e dalle Linee guida EDPB 4/2019, il contributo sostiene che la protezione dei dati non debba essere costruita sull’idea di utenti perfetti, ma su sistemi capaci di prevenire, contenere e rilevare condotte errate o abusive ragionevolmente prevedibili.

In questa prospettiva, la vera qualità progettuale non consiste nel demandare tutto alla formazione o alla diligenza individuale, ma nell’incorporare nel trattamento regole, limiti, automatismi, segregazioni e controlli che rendano la condotta corretta la via ordinaria e quella rischiosa un’eccezione difficile, limitata e visibile.

La privacy by design oltre la teoria

La privacy by design è senza dubbio una delle novità più dirompenti introdotte dal Regolamento Generale sulla Protezione dei Dati, sia in termini concettuali che pratici.

Nel tempo ha travalicato i limiti della normativa sulla protezione dei dati stessa: l’espressione by design, infatti, viene ormai associata a diverse dimensioni, prima fra tutte quella della security (anche fisica), arricchendole di un elemento progettuale, quasi architettonico, ma prima di tutto organizzativo preventivo.

Fiumi di inchiostro sono scorsi per elimitare il concetto e individuarne l’evoluzione giurisprudenziale e dottrinaria nel tempo e il Comitato europeo dei Garanti ha pubblicato nel 2020 la versione definitiva delle Linee guida 4/2019 sull’articolo 25, che disciplinano appunto la privacy by design e by default, ancora oggi utile documento di indirizzo.

È bene ricordare che l’articolo in esame impone al titolare del trattamento di integrare la protezione dei dati fin dalla progettazione e di trattare per impostazione predefinita solo i dati strettamente necessari.

L’aspetto della progettazione è senz’altro preliminare perché pone le fondamenta del trattamento nel suo complesso, cioè non solo dell’operazione sui dati in sé, ma anche delle modalità e degli strumenti attraverso cui essa si estrinseca: il titolare del trattamento deve implementare misure tecniche e organizzative adeguate fin dalla fase di progettazione di un prodotto, comprendendo tra queste anche l’architettura, le procedure, i protocolli e il layout.

Il messaggio sostanziale è che la tecnologia deve sposarsi con l’organizzazione, non bastando un accorgimento tecnologico se manca un protocollo.

Il mito da superare

La privacy by design non deve rendere le persone infallibili. Deve rendere il sistema capace di prevenire, contenere e intercettare le conseguenze delle condotte errate, siano esse prevedibili o intenzionali.

L’obiettivo non è quindi il rischio zero, concretamente impossibile da raggiungere, ma una protezione efficiente e strutturale che miri a prevenire e a resistere all’errore umano e che venga progettata avendo come punto di partenza non la colpa dell’operatore ma la prevedibilità della condotta non conforme o illecita.

Di fronte all’errore, che può derivare da dimenticanza, distrazione, eccesso di fiducia nelle proprie competenze, fra le tante, la barriera non può essere costituita esclusivamente dalla formazione.

Il titolare del trattamento deve partire dal presupposto che l’attenzione individuale è una risorsa limitata: non si può pertanto costruire la protezione dei dati sull’assunto che ogni persona ricordi sempre la procedura, interpreti correttamente ogni situazione, non scelga mai la scorciatoia e verifichi sempre ciò che il sistema potrebbe verificare automaticamente.

Se un errore banale consente un accesso o una comunicazione che non dovrebbe essere possibile, il problema non è soltanto comportamentale: è anche progettuale.

Partire dalla fallibilità

Chi progetta deve considerare la possibilità che l’utente commetta un errore involontario o che realizzi una condotta intenzionalmente scorretta.

Il lavoratore può sbagliare destinatario in un’email, selezionare un documento sbagliato, dimenticare di revocare un accesso o un’autorizzazione, utilizzare un’impostazione non corretta o accedere a più dati di quelli necessari;.

Può inoltre consultare dati non necessari alla propria attività, utilizzare un’autorizzazione oltre la finalità per cui gli è stata concessa, esportare dati che non gli servono e farlo per fini strettamente personali, condividere informazioni e cercare di aggirare un limite.

Il punto di partenza deve essere non solo prendere atto della fallibilità delle persone, ma anche non progettare come se la malafede fosse impossibile.

Progettare la privacy, quindi, significa considerare non soltanto ciò che l’utente dovrebbe fare, ma anche ciò che potrebbe ragionevolmente fare.

Cosa chiede davvero l’articolo 25 del GDPR

Sebbene l’articolo 25 del Regolamento, in linea con la neutralità tecnologica dell’atto, non imponga né preferisca alcune tecnologie ad altre, le citate Linee guida riconoscono nella formazione base del personale una possibile garanzia e misura tecnica od organizzativa adeguata.

Questo però non deve far pensare che la discrezionalità del titolare del trattamento possa spingersi fino a poter affidare la protezione dei dati alla perfezione degli utenti formati; anche perché la stessa norma non richiede un sistema infallibile, ma di incorporare la protezione nel modo in cui il trattamento si progetta e gestisce.

Il titolare deve individuare il rischio inerente del trattamento, cioè insito nell’operazione sui dati, e attuare delle misure di mitigazione che rendano il rischio residuo tollerabile e minimo.

L’accountability è il passaggio successivo, perché richiede, specialmente in sede ispettiva e di reazione alla violazione dei dati, di poter dimostrare non solo di aver attuato quelle misure ma anche che queste ultime fossero adeguate.

Dalla policy al vincolo strutturale: quando la regola non basta

Il salto qualitativo avviene quando la protezione non viene soltanto comunicata all’utente, ma incorporata nel sistema.

La progettazione forte non si limita a dire quale sia la condotta corretta: rende la condotta corretta la più semplice e quella rischiosa o da evitare più difficile, limitata o rilevabile.

Il vincolo strutturale, che poi è la misura efficace per eccellenza, non può esistere senza la regola e il controllo, ma questi ultimi hanno dei limiti: l’efficacia della regola dipende dalla corretta valutazione dell’operatore, ripetuta ogni volta; il controllo può intercettare l’errore solitamente solo dopo che il trattamento è già avvenuto.

Per esempio, l’accesso da parte di una persona che ha cambiato ruolo o azienda a un archivio o a una cartella condivisa non dovrebbe cessare perché qualcuno ricorda di revocarlo: sarebbe più efficace e robusto un meccanismo automatico che, collegando le autorizzazioni al ruolo effettivo, le revoca allo scattare di alcune modifiche (trigger).

I workflow di approvazione, i riesami periodici e la disattivazione tempestiva manuale sono forme di controllo e di intervento immediato.

La progettazione dell’errore

In un certo senso, il titolare deve svolgere una progettazione dell’errore, prevedendo quelli che gli utenti e gli operatori potrebbero ragionevolmente e statisticamente compiere: l’errore prevedibile deve diventare un requisito di progettazione, attraverso una logica che porta a una sorta di threat modeling della condotta umana.

Prima di implementare un trattamento, bisogna chiedersi: quale errore può commettere l’utente o l’operatore? Perché potrebbe commetterlo? Quanto è facile commetterlo? Che cosa potrebbe vedere, modificare, esportare o comunicare? Il sistema può impedire l’azione? Se non può impedirla, può limitarne la portata? Se non può limitarla completamente, può rilevarla rapidamente?

Il trattamento, in altre parole, deve essere a prova di errore prevedibile.

Efficacia preventiva: le tre barriere

La vera svolta consiste nel progettare una struttura capace di anticipare, rendere visibile e gestire l’errore come comportamento anomalo, sia esso colposo o intenzionale. In questa prospettiva, il punto non è domandarsi se l’errore si verificherà, ma quanto rapidamente il sistema saprà impedirlo, limitarne gli effetti o segnalarlo.

Anticipare l’errore è decisivo, perché un’anomalia intercettata prima dell’esecuzione non produce le stesse conseguenze di una scoperta solo dopo la diffusione dei dati.

Nella consapevolezza che non esiste un’unica misura capace di coprire ogni condotta, si propone qui una configurazione a tre barriere (o layer), vale a dire prevenzione, contenimento e rilevazione; questo in linea con la sequenza che permea la protezione da progettazione: la regola orienta, il sistema previene, il limite contiene, il monitoraggio rileva e la risposta riduce la durata dell’evento e quindi il suo impatto e le sue conseguenze.

Prima, quindi, si cerca di impedire l’errore. Se non è possibile, se ne limita la portata; se anche questo non basta, lo si rileva rapidamente e si riduce il tempo necessario per intervenire.

Quando la privacy by design diventa una proprietà concreta dell’architettura

È in questa sequenza che la privacy by design smette di essere soltanto una dichiarazione di principio e diventa una proprietà concreta dell’architettura, del trattamento.

L’affermazione che la privacy deve essere incorporata nel sistema sin dalla progettazione evolve nella capacità del sistema stesso di comportarsi (cioè di attivare alert e misure) in un certo modo al verificarsi di un comportamento anomalo.

La tabella tiene fuori la reazione (o risposta) all’errore e l’apprendimento della lezione: entrambe, per quanto importanti, si collocano in un momento successivo alla prevenzione, con la rilevazione che funge da collegamento. L’evento anomalo verificatosi deve servire da lezione appresa (lesson learned) per migliorare il presidio di protezione.

La protezione che dura

Se il sistema parte già dalla configurazione meno esposta, l’impostazione predefinita, evita di trasferire sull’utente decisioni che possono essere fonte di errore.

Ogni default è una decisione preventiva su ciò che il sistema consentirà di fare senza ulteriori verifiche.

La privacy by default non rappresenta quindi un capitolo separato dalla progettazione preventiva dell’errore, ma ne costituisce una delle applicazioni più immediate: il sistema assume come configurazione ordinaria quella che riduce l’esposizione e richiede un intervento ulteriore quando occorre discostarsene.

Ma anche il default deve essere progettato per non diventare una protezione soltanto nominale. Se il contesto cambia, occorre verificare che il presidio continui a produrre l’effetto per cui era stato progettato: questo perché la progettazione preventiva non è una fotografia scattata al momento dell’implementazione, ma deve essere vista come un insieme di presìdi che devono continuare a svolgere la propria funzione anche quando il contesto nel quale operano cambia.

Non la perfezione, ma l’efficacia

La privacy by design non serve a costruire organizzazioni nelle quali nessuno sbaglia e questo non deve neanche essere il presupposto su cui la progettazione del trattamento deve poggiare: serve, invece, a costruire sistemi nei quali l’errore e la condotta anomala prevedibili non trovano un percorso semplice per trasformarsi in una violazione vera e propria e in un evento impattante.

La progettazione, quindi, incorpora la regola nel processo e nell’intera architettura, ma non si limita ad enunciarla: organizza limiti e controlli atti a renderla realmente operativa e rispettata concretamente.

La privacy by design non è robusta quando richiede utenti perfetti: lo è quando rende la condotta corretta la via ordinaria e più semplice da seguire, mentre quella rischiosa un’eccezione difficile, limitata e rilevabile.