GDPR, il diritto alla portabilità dei dati

L’articolo 1.1 del GDPR (EU) 2016/679, cita una frase “…and rules relating to the free movement of personal data…” ricca di aspettative ma densa di problematiche operative. Il principio è ottimo, suona bene, ma quando l’intensità delle parole citate svanisce, rimane un po’ di perplessità sulla fattibilità operativa. La portabilità dei dati è un diritto introdotto dal GDPR, decisamente innovativo ma dalla chiara connotazione tecnica, pertanto la sua efficacia operativa va verificata nella pratica.

La libera circolazione dei dati personali

La portabilità è il modo migliore di favorire la libera circolazione dei dati personali, garantendone nel contempo la correttezza del trattamento. Il trasferimento da sistema a dispositivo, o da sistema a sistema è sempre da preferire al caricamento dati manuale, certamente per la velocità dell’operazione ma soprattutto per l’esattezza del dato e la tracciabilità dell’operazione a garanzia della legittimità del trasferimento stesso. A livello di maturità operativa stenta a dimostrare di essere all’altezza dei propositi originali delle “Linee guida sul diritto alla portabilità dei dati” del Working Party article 29 (WP29)^[1]. Qualche miglioramento è però possibile.

Portabilità dei dati e GDPR

Vediamo sul GDPR come è declinata la portabilità dei dati personali. L’antipasto alla portabilità è servito dall’articolo 1.1 che parla di regole relative alla libera circolazione dei dati personali. Se di regole si parla, allora una authority deve emanare le direttive per la gestione operativa di questo principio e qui entra in gioco l’European Data Protection Board (EDPB) ^[2]. Fin dalla sua origine ha sostenuto la continuità con le linee guida emesse da WP29 e ha proseguito con regole aggiuntive. A questo si deve aggiungere il lavoro dell’ISA² Programme^[3] nel definire tecnicamente il concetto di dato personale per garantire l’interoperabilità del dato. Sembra un lavoro ben fatto, sicuramente ben organizzato ma presenta delle debolezze. Continuiamo con il piatto forte, l’enunciazione del diritto di portabilità dei dati personali nel GDPR.

Il paragrafo 20.1 stabilisce che per esercitare il diritto alla portabilità, i dati personali dell’interessato devono essere predisposti dal titolare in un formato strutturato, di uso comune e leggibile da una macchina. Per stabilire su quali dati applicare questo diritto, ci sono i chiarimenti della lettera 20.1.a che identifica idonei quelli relativi a trattamenti basati sul consenso oppure basati su contratto ed in aggiunta, la lettera 20.1.b restringe ai soli trattamenti effettuati con mezzi automatizzati. Possiamo anche notare che il diritto alla portabilità dei dati personali si applica a due tipi di relazione. Il paragrafo 20.1 descrive una relazione interessato-titolare, mentre il paragrafo 20.2 descrive una relazione titolare-titolare. Sembra un menù invitante e completo ma le ricette non sono così ben dettagliate per arrivare subito ad avere un risultato concreto e soddisfacente.

Lo scambio di dati tra dispositivi

Sicuramente l’intento di rendere semplice la vita dell’interessato è definito con estrema chiarezza. Il punto centrale della tematica è lo scambio dati tra dispositivi ma la necessità della legge di generalizzare i concetti va a scapito della descrizione delle azioni operative per raggiungere questo obiettivo. Stiamo parlando di informazioni che sono affidate alla cura di computer e il vincolo per essere trattate automaticamente è che le istruzioni operative siano non ambigue. In alternativa, si creerebbe uno stato d’ansia nel computer per l’imbarazzo nell’identificare i dati personali dell’interessato oggetto del trasferimento e nella scelta di un formato idoneo all’invio dei dati affinché siano leggibili da un altro computer.

Il dessert è servito dal considerando 68 con una nota dal sentore dolce e un punto di sapore amaro. Esaminiamo la frase “…Data controllers should be encouraged to develop interoperable formats that enable data portability…”. La parte piacevole è nella parola “interoperable” che aggiunge un tocco in più alla semplice leggibilità di un dispositivo, come richiesto dal paragrafo 20.1. Un meccanismo di interoperabilità presuppone la cooperazione e l’interscambio di informazioni a doppio senso. Questo richiama più l’idea della necessità di un protocollo standard di comunicazione che di un semplice meccanismo di export dati, è anche una giustificazione all’operato dell’ISA² Programme. La parte meno gradevole è nel verbo “develop” perché, da un punto di vista di efficacia dell’interoperabilità, doveva essere “adopt”. Questo perché non deve essere il titolare a sviluppare un proprio meccanismo di scambio dati ma deve adottare un meccanismo standard adatto ai propri sistemi e certificato da un opportuno organismo (EDPB molto probabilmente) come interoperabile al fine della portabilità dei dati personali.

Il diritto di portabilità titolare-titolare

Un altro punto di dubbia opportunità è nel passo di chiusura del paragrafo 20.2, ossia, il diritto di portabilità titolare-titolare è possibile ma “…where technically feasible…”. Tecnicamente, fare un export o un import di dati da un database è sempre possibile, se autorizzati e se è noto il formato destinazione o quello origine. L’uso di procedure o script serve a poter ripetere l’operazione in tempi rapidi come richiesto dalla legge. Questa frase però, lascia al titolare la scappatoia di non applicarsi a dovere e sembra una caduta di tono per evitare di circostanziare in quali casi è dovuta la portabilità e per quali tipologie di dati personali. Per la sua vaghezza, il punto in questione può rappresentare una debolezza e andrebbe migliorato imponendo al titolare delle regole ben definite.

Utilizziamo un esempio per chiarire come praticamente si può affrontare questo tema. Supponiamo di voler cambiare operatore di un servizio e di voler trasferire i contenuti amministrativi di natura personale (es. dati di contatto, residenza, fiscali, …) a un altro, per poi perfezionare i termini contrattuali nel nuovo. Probabilmente nel primo operatore ci saranno anche dati di profilazione dell’uso del servizio che non desideriamo vengano trasferiti, e quindi deve essere consentita la raccolta del consenso al trasferimento per categorie di dato. La facoltà di scegliere cosa effettivamente trasferire è necessaria. Possiamo ricorrere a un flusso di operazioni, assolutamente fattibile utilizzando protocolli di comunicazione noti, che risponderebbe ai requisiti di legge.

Uno standard per le specifiche di formato dei blocchi di dati

Per cominciare serve uno standard per definire le specifiche di formato dei blocchi di dati legati alle categorie (es. dati fiscali, indirizzi, dati sanitari, dati bancari, passaporto, e così via). Ci avviciniamo molto al Core Person vocabulary dell’ISA² Programme ma deve essere rivisto su due fronti. Il primo è la specializzazione, ogni categoria deve essere descritta da un suo vocabolario e come secondo punto limitata alle sole informazioni significative secondo il principio del need-to-know. I vocabolari sono descritti da un markup language, meglio se identificato da un nome proprio per maggior enfasi (ad esempio PIML, Personal Information Markup Language ma totale libertà nella scelta del nome).

Il package dei dati trasmessi sarà formato da un core predefinito di tag specifici delle categorie dei dati personali più eventuali tag tecnici per consentire una più efficace transizione di titolarità del servizio. I tag tecnici (es. dati di termine contratto, di identificazione di eventuali componenti hardware, …), potrebbero avere un loro vocabolario diviso per tipologie di contratto di servizio. In questo modo si consente la sincronizzazione delle operazioni nel momento di passaggio tra i due titolari senza intervento dell’interessato, se non per il consenso.

È un trasferimento dell’erogazione servizio a nuovo operatore, con continuità, e questo dovrebbe limitare le pretese di richieste di balzelli di cessazione del servizio (non lo è) con beneficio dei consumatori. Altri benefici derivano dal lavorare con categorie predefinite di dati personali. Questo aiuta le comunicazioni nel cambio della pratica commerciale, ma anche la classificazione dei dati sarebbe facilitata nell’identificare categorie ben definite. Il privacy audit sarebbe agevolato nell’esecuzione degli audit test dal lavorare in un ambiente ben strutturato e pure la tracciabilità delle operazioni si semplifica come gestione.

Un form specifico per attivare la portabilità

Una volta definito tecnicamente il modo di incapsulare i dati, deve essere data facoltà all’interessato di attivare la portabilità per mezzo di un form specifico, che consenta di scegliere le tipologie di dati da trasferire. Inoltre, una volta che queste sono state selezionate, devono essere visualizzati all’interessato i relativi dati con possibilità di modifica prima della conferma all’invio. Ci potrebbe essere l’esigenza di trasferire eventuali blocchi di dati binari con formati specifici di quel tipo di servizio. Ad esempio, per i dati sanitari, il trasferimento di alcune radiografie. Per far questo è sufficiente ricorrere a un vocabolario generico definito tramite un protocollo di tipo MIME^[4], come nelle caselle di posta per inviare contenuti binari, restringendo le coppie oggetto/formato a quelle prive di vulnerabilità di sicurezza gravi.

Conclusioni

Un meccanismo di questo tipo deve essere autorizzato e regolato da un’apposita autorità (EDPB). Come conseguenza, nel mondo degli open source non mancheranno soluzioni idonee a gestire il processo della portabilità, neanche mancheranno applicazioni per l’interessato per visualizzare i suoi dati secondo le categorie gestite dal titolare. In sintesi, quello che non può dare direttamente il GDPR sono delle chiare regole operative, può solo tracciare il percorso della strada ma poi altri devono intervenire per costruirla.

Sicuramente non possono essere lasciate al libero arbitrio dei titolari le decisioni operative sul meccanismo di attuazione della portabilità. Non ci sarebbe interoperabilità senza una soluzione univoca, supportata dagli open source. Resta compito di una authority definire, con sano pragmatismo e semplicità, le specifiche tecniche riutilizzando quanto già c’è ma in attesa di regole autorevoli.

Note

1. Article 29 Working Party, Guidelines on the right to data portability, 16/EN WP 242 rev.01, last revised and adopted on 5 April 2017 – Art. 29 WP has been replaced, in May 2018, by the European Data Protection Board (EDPB) – http://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=611233 ↑
2. EDPB (European Data Protection Board), Right to data portability, 25 May 2018 – https://edpb.europa.eu/our-work-tools/our-documents/guidelines/right-data-portability_en ↑
3. ISA² – Interoperability solutions for public administrations, businesses and citizens, GDPR Data Portability and Core Vocabularies, 22 November 2018 – https://ec.europa.eu/isa2/publications/gdpr-data-portability-and-core-vocabularies_en ↑
4. IETF (Internet Engineering Task Force), MIME (Multipurpose Internet Mail Extensions), RFC 2045 (https://tools.ietf.org/html/rfc2045), RFC 2046 (https://tools.ietf.org/html/rfc2046), RFC 2047 (https://tools.ietf.org/html/rfc2047), RFC 4288 (https://tools.ietf.org/html/rfc4288), RFC 4289 (https://tools.ietf.org/html/rfc4289), RFC 2049 (https://tools.ietf.org/html/rfc2049)