GDPR e Blockchain: problemi e soluzioni dell’Osservatorio Europeo

L’osservatorio Europeo sulla Blockchain (EU Blockchain Observatory Forum – di cui abbiamo già menzionato il prolifico account Twitter) ha pubblicato questo Report su Blockchain e GDPR.

Il Report non schiva i problemi e per precisione e chiarezza il tenore del Report è ben diverso da altri documenti della EU in tema di GDPR (ad esempio questo).

Il Report è strutturato così: dopo un breve riassunto (sì, questa cosa finirà in mano a gente molto impegnata che magari leggerà solo questo) e un’introduzione i blocchi sostanziali sono un’introduzione alla GDPR e alla blockchain.

A questo punto si passa alla sezione che più ci interessa – tensioni tra Blockchain e GDPR – e ai tentativi di conciliare queste tensioni che l’Osservatorio traduce in quattro principi/consigli per gli innovatori e sviluppatori di blockchain per essere sicuri di rispettare la normativa. In appendice, oltre a un’infografica, troviamo un glossario sui termini relativi alla blockchain – l’ultimo è particolarmente interessante per vedere come attori in senso lato istituzionali si approccino alla tecnologia.

Prima di entrare nel dettaglio sulle tensioni, occorre condensare brevemente il Report. L’Osservatorio ribadisce il supporto e l’importanza della blockchain come tecnologia ed osserva come non esistano cose tipo una blockchain che è conforme alle regole EU (“a GDPR compliant blockchain”) e una blockchain che non lo è.

La tecnologia è una e una sola, è possibile declinarla in vari modi e il rispetto del GDPR dipende da come la tecnologia viene usata, non è qualcosa che è già scritto. (Per questo, nell’ultima sezione, l’Osservatorio si premura di fornire qualche indicazione agli sviluppatori su come procedere al fine di ottimizzare le possibilità di essere conformi alle regole).

Le tensioni sono dovute al fatto che i lavori sulla GDPR (approvata nel 2016, entrata in vigore il 25 maggio del 2018) sono iniziati quando la blockchain era poco più di una curiosità. Semplifichiamo: ai tempi in cui si inizia a lavorare alla GDPR, possiamo immaginare che la situazione fosse più o meno la seguente in termini di conoscenza del fenomeno blockchain:

(i) blockchain = Bitcoin;

(ii) di smart-contracts si sapeva sì qualcosa, ma solo nei dipartimenti di computer di science (il paper di Szabo è di metà anni ‘90);

(iii) Buterin ed Ethereum etc etc ancora erano tutti da venire. Insomma, forse si poteva fare mining con la scheda grafica per giocare ad Unreal.

In modo leggermente più concettuale: la GDPR è scritta pensando a una rete centralizzata. Qual è il mantra principale di all things blockchain? (No, non dite “i pagamenti sulla Silk Road”).

Il punto è che ci troviamo con una sistema distribuito e decentralizzato che interagisce con una legge che presuppone una struttura gerarchica, organizzata e centralizzata dei sistemi. Questo, ancora, non ci porta a conflitti o tensioni necessariamente. Tutto sommato è vero che – semplificando – centralizzato e decentralizzato sono incompatibili, però non è detto che ci sia un casus belli che porti queste due qualificazioni a poter confliggere.

La GDPR tutela i dati personali e questi possono finire sulla blockchain. Ecco fatto.

Le tensioni tra blockchain e GDPR emergono almeno:

  1. Quando la GDPR tutela le persone consentendo loro la rimozione o la modifica di dati personali (il nome forse più noto per questa possibilità è ‘diritto all’oblio’);
  2. Quando la GDPR definisce ruoli precisi relativi a chi controlla i dati e, quindi, è responsabile di effettuare eventuali modifiche.

Il punto (2) ci rimanda al punto concettuale già emerso: la decentralizzazione (o presunta tale) delle blockchain. Il punto (1) si basa su un’altra proprietà molto declamata delle blockchain: l’immutabilità. Una volta che qualcosa finisce sulla blockchain, si dice, è per sempre.

C’è poi un altro punto: la GDPR richiede che decisioni importanti per gli individui e i loro dati non siano completamente automatizzate. Immaginiamo un “algoritmo per la decisione di un processo”: serve che un giudice umano controlli la decisione e la approvi, non si può finire in galera o essere assolti da una macchina. Se questo suona come fantascienza, pensiamo alla profilazione dei dati di navigazione (con cui paghiamo diversi servizi free).

Ora contestualizziamo questa idea della GDPR sugli smart-contracts e la blockchain che conosciamo adesso. Poniamo di usare alcuni smart-contracts per procedure di mediazione (ad esempio, si veda qui), ed ecco che qui sorgono dei problemi.

Immaginiamo che su una blockchain finiscano dei dati personali errati, ad esempio un CV con il voto di laurea errato. Vista l’immutabilità del blocco in cui è conservata questa informazione, non possiamo rettificare l’errore. Inoltre, anche ammettendo che questo fosse possibile, non sappiamo bene a chi rivolgerci affinché la correzione avvenga.

Inoltre, potrebbero sorgere ulteriori problemi: le copie della blockchain potrebbero essere presenti in hard disk sparsi per il mondo e tutelati da diverse giurisdizione e normative.

Ammesso che sia emerso il problema della tensione, vediamo come è possibile risolvere questi problemi.

Una prima strategia è quella di negare che sorgano problemi. Si tratta di valutare quali sono le condizioni che ci consentono di applicare la GDPR e di negare che queste condizioni si diano sulla blockchain. Possiamo negare che sulla blockchain ci siano dati personali, magari dicendo che tutto quello che è su blockchain è crittografato e anonimizzato. La strada è difficilmente percorribile. GDPR cerca di combattere la profilazione degli utenti (a loro insaputa) e la definizione di ‘dato’ è particolarmente ampia. Inoltre, la pseudoanonimizzazione della blockchain non basta: ciò che sembra crittograficamente sicuro oggi potrebbe non esserlo domani. Strada dunque non percorribile

Una strada più promettente sembra essere quella di dire: ok, ci sono dei dati che sono tutelati dalla GDPR sulla blockchain, però non ci sono le condizioni per applicare la GDPR stante la struttura della blockchain.

Con questa mossa si cerca di insistere sulla decentralizzazione e far saltare l’applicabilità della GDPR perché il tipo di architettura informativa è diversa (centralizzata vs. decentralizzata). Questa strategia è certamente più promettente ma si scontra con un fatto: la GDPR cerca di tutelare gli utenti e una blockchain senza utenti, transazioni, etc. è una blockchain morta.

Quando economisti o investitori si chiedono come migliorare la blockchain una delle cose che emerge è quella di “avere più certezze” per evitare truffe e frodi (scam). Quelli che possono apparire eccessi di regolamentazione vengono visti in ben altro modo appena il vostro exchange preferito dichiara fallimento e non vi restituisce i vostri soldi o in caso di hackeraggio.

Magari non vi interessa poter esercitare il vostro diritto all’oblio, però vi piacerebbe avere transazioni reversibili, ad esempio se effettuate un pagamento a X e non a Y. (Nel caso in cui il pagamento non sia cancellabile perché i dati sono immutabili, vorreste avere una norma che obblighi Y a ridarvi quanto volevate dare a X (o magari girarlo direttamente a X)).

Tuttavia, anche senza entrare nel dibattito “come e quanto regolamentare una blockchain?”, questa strategia porta a un muro contro muro. Chi invece vuole applicare la GDPR alla blockchain replicherà cercando di trovare, all’interno dell’architettura blockchain, quanto di più simile ai ruoli previsti dalla GDPR. A questo punto quanto individuato verrà identificato alla stregua di quanto previsto.

In alternativa, si può cercare di mediare, che è quanto proposto nel Report dell’Osservatorio Europeo su Blockchain. Il modo per mediare è quello di cercare di conoscere meglio la blockchain come tecnologia.

Ad esempio, per quanto il nostro archetipo di blockchain (il network dei Bitcoin) sia decentralizzato non tutte le blockchain devono essere così aperte e permissionless. Una blockchain permissioned, in cui è presente una qualche forma di controllo sui nodi o su chi effettua il mining consente di individuare con più facilità quanto richiesto dalla GDPR.

Inoltre, il Report invita a considerare se e come la blockchain sia davvero necessaria per tutte le fasi del progetto, soprattutto per quanto riguarda la custodia dei dati personali. La soluzione in questo caso diventa: tutto ciò che è passibile di tutela da parte della GDPR va messo off chain, la blockchain poi verrà integrate e utilizzata per il resto.

In queste strategie si ripropongono le dinamiche viste in precedenza. Con la divisione off chain/on chain cerchiamo di prevenire e rendere impossibile la tensione blockchain/GDPR. Introducendo una permissioned blockchain si cerca di rimediare alla decentralizzazione. Possiamo fare qualcosa per l’immutabilità? Qui le cose si fanno più complesse (e il Report non dice molto). Però non mi sembra si possano escludere diverse soluzioni: da time-stamped blocks (con cui, ad esempio, fornire una scadenza ai dati sensibili che, dopo tot, si distruggono) a soluzioni con più livelli (i dati sono on chain, però gli utenti sanno chi vuole vedere cosa e possono dare o meno l’autorizzazione a farlo). Dopo tutto, alcuni dei progetti in corso sulla blockchain cercano di fare proprio questo (ad esempio Enigma: https://enigma.co/ZNP15.pdf).

_____________

Guglielmo Feis

Ph.D. – Assegnista di ricerca

http://unimi.academia.edu/GuglielmoFeis

Dipartimento di Scienze Giuridiche Cesare Beccaria

Università degli Studi di Milano

Via Festa del Perdono, 7

20122, Milano

Rispondi