Il 7 luglio 2026 l’EDPB ha adottato la versione 2.0, quella definitiva, delle Guidelines 02/2025 on processing of personal data through blockchain technologies, a quindici mesi dalla versione 1.1 (draft) adottata l’8 aprile 2025 e all’esito della consultazione pubblica.
Insieme al testo finale sono arrivati il report sull’esito della consultazione e una versione con le modifiche evidenziate.
Chi si aspettava una retromarcia resterà deluso.
L’impianto del draft esce confermato in ogni punto strutturale: gli identificativi presenti sulla blockchain possono essere dati personali, la preferenza va alle blockchain permissioned, l’impossibilità tecnica non giustifica l’inadempimento del Regolamento (UE) 2016/679 (GDPR).
Per chi progetta o utilizza soluzioni blockchain – nella finanza, nella supply chain, nella sanità – il tempo dell’attesa è dunque finito: il quadro è stabile e le autorità di controllo dispongono ora di un metro comune.
Vediamo allora cosa stabiliscono le nuove Linee Guida.
L’analisi che segue è a due voci: prima la ricostruzione tecnica dell’impianto e delle modifiche (§§ 1-4), poi la lettura giuridica dei diritti degli interessati e dei nodi che la versione finale lascia aperti (§§ 5-7) dalla nozione di dato personale dopo la sentenza Deloitte ai trasferimenti internazionali.
Indice degli argomenti
Blockchain e dati personali: dove nasce il problema
1.1 Il registro, i nodi, il consenso (paragrafi 15-20)
Il punto di partenza è semplice: una blockchain è un archivio distribuito che contiene un registro pubblico di transazioni. Due principi ne garantiscono la coerenza e l’integrità.
Il primo: le transazioni sono raggruppate in blocchi e ogni blocco è legato per via crittografica al precedente, così che tutti i blocchi formano una catena.
Il secondo: un algoritmo di consenso stabilisce quale sia il blocco valido da aggiungere.
Il paragrafo 15 precisa che le transazioni sono organizzate in una sequenza cronologica di blocchi; compare un rinvio alla nuova voce di glossario dedicata al consenso ed una nota chiarisce che nella maggior parte delle implementazioni i dati del registro (ledger), in particolare lo stato globale del sistema (world state), sono materializzati a livello di nodo tramite archivi chiave-valore come LevelDB o RocksDB.
Il capitolo prosegue richiamando i meccanismi di consenso: la proof of work e la proof of stake, con l’esempio di Bitcoin per la prima ed Ethereum per la seconda, la regola per cui in caso di blocchi in conflitto prevale la catena più lunga, e il fatto che una transazione si consideri definitiva solo dopo l’aggiunta di alcuni blocchi successivi.
Si chiude con gli smart contract: programmi memorizzati sulla blockchain, registrati automaticamente al momento della creazione, la cui esecuzione modifica lo stato delle informazioni memorizzate.
Le famiglie di blockchain
1.2 (paragrafi 21-24)
La classificazione delle blockchain poggia di solito su due assi: blockchain pubblica o privata, e blockchain ad accesso autorizzato (permissioned) o libero (permissionless). Le combinazioni più diffuse sono le pubbliche ad accesso libero, come Bitcoin ed Ethereum, e le private permissioned, scelta consueta dentro le imprese.
Nelle blockchain permissionless tutti i partecipanti hanno gli stessi diritti: chiunque può leggere, scrivere, creare blocchi, mentre in quelle permissioned esiste un’autorità che concede il permesso di partecipare e questa autorità può essere un soggetto singolo o un gruppo di soggetti con un interesse comune.
Il paragrafo 24 è stato leggermente ritoccato: nella versione 1.1 si diceva che alcune blockchain permettono di nascondere le “identità” delle parti coinvolte, mentre ora si parla di “identificativi”. Presa da sola sarebbe una limatura lessicale, se non fosse che il paragrafo 27, rimasto identico in entrambe le versioni, chiarisce che alcune tecniche permettono di nascondere gli identificativi con strumenti crittografici avanzati, ma i dati che li sostituiscono possono comunque costituire dati personali.
La correzione, in altre parole, allinea il lessico a una posizione che l’EDPB aveva già nella versione 1.1, dando coerenza al passaggio.
Dati on-chain e identificativi
1.3 (paragrafi 25-35)
Qui si colloca la modifica forse più rilevante della versione 2.0: una blockchain conserva metadati di transazione, tra cui gli identificativi degli utenti, tipicamente chiavi pubbliche derivate da una chiave privata ed un contenuto (payload), che può essere un importo, un collegamento a un documento, la chiamata a una procedura di uno smart contract.
Se l’utente è una persona fisica e quelle chiavi pubbliche possono essere usate per identificarla con mezzi ragionevolmente utilizzabili, allora quegli identificativi sono dati personali.
L’EDPB porta l’esempio di una violazione di dati, rinviando in nota a un archivio pubblico di attacchi su blockchain. Interagendo con una blockchain, attraverso applicazioni decentralizzate (dApp), wallet o intermediari, si generano anche dati che non finiscono on-chain, come gli indirizzi IP, e che possono comunque essere dati personali.
La novità è la nuova nota al paragrafo 30, che elenca in modo esplicito cosa va valutato: i metadati presenti on-chain (identificativi di transazione, indirizzi dei portafogli, registri di eventi, ricevute, transizioni di stato, memoria dei contratti intelligenti e altre tracce), possono costituire dati personali quando consentono l’identificazione diretta o indiretta di una persona fisica.
Nel Glossario – anche questo una novità della versione definitiva, da leggere assolutamente – è stata inserita la nuova voce wallet address/account/public key che definisce indirizzo del portafoglio, account e chiave pubblica come un identificativo legato ad una coppia di chiavi crittografiche e si precisa che esso si qualifica come dato personale ai sensi dell’articolo 4 del GDPR quando può essere associato a una persona fisica identificata o identificabile.
Il confronto con il report sulla consultazione è istruttivo perché tra le proposte respinte figura espressamente quella di escludere gli indirizzi dei portafogli e gli identificativi di transazione dalla nozione di dato personale a prescindere dalla loro capacità di identificare o isolare un individuo: chi ha chiesto di restringere il perimetro ha invece ottenuto un elenco più dettagliato di ciò che vi rientra.
Il capitolo si chiude con la rassegna delle tecniche applicabili alla memorizzazione on-chain: cifratura, funzioni di derivazione di chiave, codici di autenticazione basati su hash (HMAC), altre funzioni crittografiche a senso unico, impegni crittografici (commitment).
L’EDPB le qualifica come misure di sicurezza, che sono protezioni tecniche e organizzative, non garanzie piene di protezione dei dati.
La memorizzazione di dati personali in chiaro è fortemente sconsigliata, perché potrebbe confliggere con vari principi dell’articolo 5 del GDPR.
Governance e responsabilità nelle reti distribuite
1.4 (paragrafi 36-44)
Il modello di governance decentralizzata moltiplica gli attori coinvolti e l’EDPB mette un paletto: né questo fatto, né la scelta di una specifica infrastruttura tecnica possono essere invocati per non rispettare il GDPR.
Dove la legge non assegna già le responsabilità, serve una valutazione fattuale che consideri la natura del servizio offerto, il meccanismo di governance, le caratteristiche tecniche e organizzative della blockchain, le relazioni tra i diversi attori.
Il meccanismo di governance, precisa il paragrafo 39, è spesso l’elemento decisivo, perché definisce se il modello sia centralizzato o distribuito e stabilisce le regole tecniche, organizzative e giuridiche del sistema.
Il punto più sensibile dal punto di vista politico è rimasto intatto: le blockchain permissioned offrono una ripartizione più chiara delle responsabilità, che è un elemento chiave per la protezione degli interessati, e le organizzazioni dovrebbero preferirle.
Possono esplorare alternative solo in presenza di ragioni ben giustificate e documentate e in quel caso devono anche chiedersi se sia effettivamente appropriato usare una blockchain, valutando con attenzione se altre tecnologie siano comunque adatte allo scopo.
Su questo punto il report è esplicito: le critiche alla preferenza per le blockchain permissioned sono state esaminate e respinte, con la motivazione dichiarata che una blockchain di questo tipo offre un modo più semplice di allocare le responsabilità e di soddisfare gli altri requisiti del GDPR.
Sui nodi la posizione è articolata su tre scenari.
Quando il nodo si limita a preparare le transazioni da inserire nel blocco successivo e a verificare criteri tecnici, formato, dimensione, capacità dell’emittente di eseguire la transazione, senza interesse o beneficio nella scelta di transazioni specifiche, non determina finalità e mezzi del trattamento e potrebbe quindi non essere titolare.
Nelle blockchain pubbliche permissionless i nodi possono invece svolgere varie attività di trattamento per offrire servizi e possono essere qualificati come titolari o contitolari quando esercitano un’influenza determinante sulla definizione delle finalità e dei mezzi essenziali.
In certi casi i nodi non agiscono per conto di un titolare né ricevono istruzioni, e possono decidere di modificare finalità o mezzi essenziali per perseguire obiettivi propri. L’esempio citato dall’EDPB è la decisione su una biforcazione della blockchain (fork). Ciò può avvenire individualmente, scegliendo quali transazioni includere nel blocco che si mina, oppure collettivamente, accordandosi sulle modifiche al protocollo.
In quest’ultimo scenario l’EDPB incoraggia fortemente la costituzione di un consorzio o di altra entità giuridica tra i nodi.
Blockchain e dati personali nella conformità operativa
Il capitolo 4 è il cuore operativo.
La premessa va ripetuta perché viene spesso fraintesa: la blockchain è soltanto una tecnologia, come il cloud computing o le reti tra pari; non è di per sé un trattamento di dati personali, ma (ovviamente) incide sul trattamento e sulla sua conformità.
Vediamo allora cosa occorre fare.
Valutare prima di costruire
2.1 (paragrafi 45-48)
L’EDPB ammette che alcuni rischi di non conformità si mitigano facilmente con misure tecniche a monte, mentre per altri trovare una soluzione può essere difficile.
Da qui l’obbligo pratico: fare una valutazione preventiva prima di implementare la blockchain, e includerla nella valutazione d’impatto sulla protezione dei dati (data protection impact assessment, DPIA) quando questa è richiesta.
Le quattro domande a cui rispondere, riprese poi testualmente dalla prima raccomandazione dell’Allegato A:
– i dati on-chain conterranno dati personali?
– in caso affermativo, perché la blockchain è necessaria per questo trattamento? Qual è la ragione della scelta e quali erano le alternative?
– che tipo di blockchain va usato? Basta una blockchain privata? Si può usare una blockchain permissioned? È possibile un’architettura a conoscenza zero?
– quali misure tecniche e organizzative? I dati staranno on-chain oppure off-chain? Si usano tecnologie di rafforzamento della riservatezza, e se no, perché?
Segue il criterio della necessità: la scelta della tecnologia deve rispettare il principio di necessità previsto dal GDPR, e va documentato perché è stata compiuta; in nota le linee guida richiamano la giurisprudenza della Corte europea dei diritti dell’uomo (Sunday Times c. Regno Unito) secondo cui “necessario” non equivale a “indispensabile”, ma neppure ha la flessibilità di “utile” o “auspicabile”: implica un bisogno sociale pressante.
Poi il criterio della pubblicità (publicity), che nella versione 2.0 entra anche in Glossario: va valutato sia l’impatto della relativa pubblicità di chi invia transazioni a chi, sia la pubblicità dei dati coinvolti.
La conclusione operativa è secca: in generale non è consigliabile memorizzare dati personali sulla blockchain, e questi non vanno inseriti nel contenuto delle transazioni.
Se i dati finiscono on-chain
2.2 (paragrafi 49-56)
L’articolo 25, paragrafo 2, del GDPR impone che, per impostazione predefinita, i dati personali non siano resi accessibili senza l’intervento dell’interessato a un numero indefinito di persone fisiche.
L’EDPB ne trae una conseguenza diretta: le blockchain pubbliche vanno impiegate solo se l’accesso pubblico è necessario per almeno una delle finalità del trattamento.
Se la blockchain non è pubblica, vanno comunque adottate misure per limitare l’accessibilità dei dati a quanto necessario e per proteggerli da trattamenti non autorizzati.
Prima di elencare le misure, il paragrafo 50 spiega perché servono. Una volta memorizzato sulla blockchain, il dato nella maggior parte dei casi vi rimane senza possibilità pratica di cancellazione o modifica.
Modificare una blockchain è tecnicamente possibile ma molto difficile, perché richiede che tutti i nodi aggiornino la propria copia e concordino sul cambiamento ed anche allora la modifica potrebbe non raggiungere tutte le copie.
Segue l’affermazione che l’EDPB ha voluto lasciare in evidenza: l’impossibilità tecnica non può essere invocata per giustificare il mancato rispetto degli obblighi del GDPR.
Vengono quindi descritte tre misure per evitare la memorizzazione in forma direttamente identificativa.
Cifratura. Con algoritmi e chiavi allo stato dell’arte i dati restano leggibili solo a chi possiede la chiave; cancellata la chiave di decifratura, il dato diventa inintelligibile.
La protezione però non è definitiva: dura finché l’algoritmo non viene violato e finché le tecniche di decifratura non progrediscono abbastanza e viene meno del tutto se la chiave era già stata compromessa o divulgata prima della cancellazione.
L’EDPB ricorda tre cose: il dato cifrato resta dato personale, la cifratura non esonera dal GDPR ed anche una cifratura perfettamente implementata sarà superata dal tempo se la blockchain è conservata a tempo indeterminato.
Il titolare deve tenerne conto quando decide se memorizzare dati cifrati on-chain.
Impronta crittografica (hash) con salt o con chiave. On-chain va solo un hash del dato personale calcolato con un salt lungo e casuale (valore di dimensioni sufficienti combinato con il dato prima del calcolo dell’hash) o con una chiave segreta; il dato non sottoposto ad hash, insieme al salt o alla chiave, resta off-chain in modo riservato.
Il vantaggio è che il dato originale, cioè l’argomento della funzione di hash, non può essere facilmente recuperato a partire dall’hash medesimo: quest’ultimo sarà, in teoria, verificabile solo da chi ha accesso sia al dato originale sia alla chiave o al salt associati.
Quattro avvertenze.
- Anche se ci si riferisce a questa come memorizzazione off-chain, il GDPR continua ad applicarsi a quel trattamento.
- L’hash è esso stesso dato personale, e lo sono anche gli eventuali altri identificativi presenti.
- La memorizzazione esterna richiede un altro sistema, creando un trattamento in un’altra componente dell’infrastruttura, con rischi propri.
- Infine, gli hash privi di salt o di chiave non sono, in generale, sufficienti a garantire il livello di riservatezza necessario per memorizzare dati personali su una blockchain pubblica.
Impegni crittografici. Se calcolato con uno schema perfettamente occultante e allo stato dell’arte, una volta cancellati il dato originale e il witness (valore crittografico casuale segreto che consente di rivelare quale dato sia stato oggetto dell’impegno), l’impegno che permane sulla blockchain è inutile: non è possibile né recuperare né riconoscere il dato personale originale.
Se davvero i dati personali devono stare on-chain, meglio scriverci solo qualcosa che serva a provarne l’esistenza (proof of existence): un puntatore, un impegno crittografico, un hash generato con chiave.
Il dato che permette di verificare quella prova va tenuto off-chain, per esempio nei sistemi del titolare, e con un elevato livello di riservatezza, che qui l’EDPB pone come obbligo.
Resta un’eccezione, stretta.
Può capitare che il titolare debba rendere un’informazione pubblica e accessibile per tutta la vita della blockchain: solo allora ha senso scriverla on-chain in forma direttamente identificabile, e comunque a due condizioni: che la finalità lo giustifichi e che una DPIA abbia concluso che i rischi per gli interessati sono stati affrontati e mitigati.
Al paragrafo 56 la versione 2.0 introduce l’unica modifica che riconosce esplicitamente le tecniche crittografiche avanzate. Dove la versione precedente diceva soltanto che le misure descritte possono essere utili a ridurre i rischi, il testo ora vi affianca le tecnologie emergenti di rafforzamento della privacy (Privacy-Enhancing Technologies – PET), come le prove a conoscenza zero (Zero Knowledge Proof – ZKP) e altri protocolli crittografici avanzati, che possono contribuire a ridurre i rischi per gli interessati.
Ad ogni modo, il periodo si chiude con la clausola che l’EDPB ha scelto di conservare: tali tecniche vanno accuratamente testate e validate e devono comunque essere accompagnate da altre misure tecniche e organizzative appropriate, perché il trattamento risponda a tutti i requisiti del GDPR e garantisca i diritti degli interessati.
Blockchain e dati personali davanti ai principi del Gdpr
2.3 (paragrafi 57-69)
I principi di protezione dei dati vengono richiamati per esteso e non sono negoziabili, anche se la loro attuazione può variare secondo il contesto e il livello di rischio.
Correttezza. I dati non vanno trattati in modo ingiustificatamente pregiudizievole, illegittimamente discriminatorio, inatteso o fuorviante.
Trasparenza. Il titolare deve essere chiaro e aperto su come raccoglie, usa e condivide i dati, in modo che l’interessato possa comprendere ed eventualmente esercitare i propri diritti.
Limitazione della finalità. Qui l’EDPB individua un problema strutturale: la natura disintermediata della blockchain fa sì che le relazioni tra i partecipanti non possano sempre essere governate da contratti o altri atti giuridici che li vincolino a trattare i dati solo per le finalità inizialmente specificate.
Minimizzazione. La natura incrementale e in continua crescita della blockchain (append-only) mette in tensione il principio, aggravata dalla persistenza potenzialmente illimitata e dalla replicazione multipla.
Il titolare deve dimostrare che la tecnica scelta impiega il minimo di informazione necessaria e con il minimo livello di pubblicità.
Esattezza. I margini di intervento una volta che il dato è on-chain sono ridottissimi. Da qui l’enfasi sulle fasi preliminari e sulla massima cura nella selezione iniziale dei dati, che l’EDPB colloca esplicitamente all’interno della governance.
Limitazione della conservazione. La cancellazione a livello del singolo dato è difficile e richiede architetture progettate appositamente.
Se la cancellazione non è stata considerata fin dalla progettazione, potrebbe rendersi necessario cancellare l’intera blockchain.
Qualunque approccio si scelga deve essere efficace e se richiede la cancellazione di parte della blockchain, comprese le copie detenute dai nodi o da terzi, servono misure tecniche e organizzative sufficienti a realizzarla.
Segue il passaggio sulla non collegabilità.
Per impedire l’identificazione futura di un interessato va impedito il collegamento, con mezzi ragionevolmente utilizzabili, tra una transazione esistente e una transazione futura riferita alla stessa persona.
Modificando i dati esterni alla blockchain è possibile che gli interessati non siano più identificabili sulla base di ciò che resta on-chain, ma quella modifica precluderà verosimilmente ogni uso del dato per le finalità originarie.
La transazione anonimizzata avrà perso ogni significato, pur continuando a esistere per consentire la verifica di integrità delle altre.
Il principio di integrità in una blockchain è assicurato dal protocollo e poggia sulla fiducia nel meccanismo di consenso e nei nodi: la fiducia però non si può imporre, si può solo incentivare, per esempio con software certificato per interagire con la blockchain, garantendo un modo per identificare i nodi e, se necessario, ricorrendo a una blockchain permissioned.
La riservatezza è messa in tensione dalla tecnologia stessa: la disintermediazione si ottiene diffondendo ogni transazione, e per questo la riservatezza dei metadati dipende dal tipo di blockchain scelto.
Serve confinare le informazioni diffuse ai soli attori rilevanti della blockchain, mentre la riservatezza del contenuto dipende dai meccanismi impiegati (cifratura, commitment) e dalle misure classiche di sicurezza applicate ai dati off-chain.
Il principio va poi attuato con misure estese a tutte le istanze della blockchain e ai dati delle transazioni, sia on-chain sia off-chain.
Basi giuridiche e trasferimenti
2.4 (paragrafi 70-73)
Poiché su un’infrastruttura blockchain possono essere realizzati trattamenti diversi, non esiste un’unica base giuridica valida per tutti.
Ogni trattamento deve fondarsi su una delle basi previste dall’articolo 6, tenendo conto della sua specifica finalità; e se coinvolge categorie particolari di dati ai sensi dell’articolo 9, paragrafo 1, deve ricorrere una delle eccezioni dell’articolo 9, paragrafo 2.
Sul consenso il punto critico è quello della revoca: al momento della revoca i dati devono essere cancellati o resi anonimi.
La nona raccomandazione dell’Allegato A porta il ragionamento alla sua conseguenza logica: il consenso non dovrebbe essere usato per trattamenti che richiedono transazioni con individui, se l’architettura della blockchain non consente di cancellare i dati personali delle parti: perché il consenso è strettamente collegato alla possibilità di revoca ed alla eventuale cancellazione.
Sono richiamate poi le limitazioni ai diritti degli interessati ammesse dall’articolo 23, con esempi concreti (soluzioni blockchain imposte per finalità antiriciclaggio o per inventari di determinati beni, come quelli immobiliari) purché proporzionate, definite in modo rigoroso dalla legge e rispondenti a una necessità in una società democratica.
Una blockchain può essere poi utilizzata quando il trattamento è necessario per il perseguimento del legittimo interesse del titolare o di un terzo, salvo che prevalgano gli interessi o i diritti e le libertà fondamentali dell’interessato, ai sensi dell’articolo 6, paragrafo 1, lettera f).
È una sola frase, ma porta tre note a piè di pagina, di assoluto rilievo: due rinviano alle Linee guida 1/2024 sul legittimo interesse e ribadiscono che il trattamento deve essere necessario e bilanciato rispetto agli interessi e ai diritti fondamentali degli interessati.
La terza rinvia al Parere 11/2024 sul riconoscimento facciale negli aeroporti, e ne estrae un criterio: va valutato se l’impatto negativo sui diritti e sulle libertà fondamentali degli interessati sia proporzionato al beneficio atteso; se il beneficio è relativamente modesto, quell’impatto potrebbe non essere proporzionato.
Trasferimenti internazionali
2.5 (paragrafi 74-75)
Il Capo V del GDPR regola i trasferimenti di dati personali fuori dallo Spazio economico europeo, e la blockchain li comporta spesso, basta che la blockchain includa nodi collocati fuori dall’UE.
Il punto critico è che questi nodi non sono necessariamente né scelti né verificati (l’EDPB porta come esempio Bitcoin), il che può sollevare problemi di conformità.
Il titolare deve comunque individuare i trasferimenti e i meccanismi che li rendono legittimi: l’esempio proposto è l’inserimento di clausole contrattuali tipo nel contratto che il candidato nodo deve firmare prima di essere accettato.
E in ogni caso la questione va affrontata fin dalla progettazione, dove un’architettura di protezione dei dati by design può aiutare a valutare gli obblighi.
Conservazione e sicurezza nelle architetture blockchain
2.6 Conservazione: la durata della blockchain non è un periodo di conservazione (paragrafi 78-81)
Il titolare deve considerare ogni singolo dato in funzione della finalità del suo trattamento quando definisce il periodo di conservazione.
Il dato registrato su una blockchain è inalterabile: una volta che il blocco contenente la transazione è stato accettato dalla maggioranza dei nodi, ogni modifica verrebbe rilevata, ma questo non è una ragione per assumere che la durata di vita della blockchain costituisca un periodo di conservazione appropriato.
I dati vanno cancellati quando l’attività di trattamento giunge al termine.
Tra le cose da valutare ci sono le tecniche descritte nella sezione 4.2 delle Linee Guida, che in alcuni casi possono mitigare le conseguenze, secondo la valutazione del rischio.
Il periodo di conservazione non riguarda solo il payload. Una blockchain contiene diverse categorie di dati personali, e per la maggior parte delle catene gli identificativi degli utenti sono sempre visibili, perché essenziali al corretto funzionamento.
L’EDPB ricorda che il termine si applica anche a questi identificativi e, quando assumono la forma di chiavi pubbliche di verifica della firma, anche alle transazioni firmate con le corrispondenti chiavi private.
Alla scadenza i dati devono essere cancellati o resi anonimi.
A questo punto la versione 2.0 inserisce una nota: il diritto dell’Unione o di uno Stato membro può stabilire periodi di conservazione specifici, di cui tenere conto.
Gli esempi citati sono il Regolamento MiCA e il Regolamento antiriciclaggio, che impongono di conservare dati identificativi e di transazione per cinque anni, con la precisazione che il secondo sarà applicabile dal 10 luglio 2027.
La regola di sintesi arriva nel paragrafo finale, ed è quella da tenere a mente in fase di progettazione: se il trattamento non richiede un periodo di conservazione pari o superiore alla vita della blockchain, i dati personali non dovrebbero essere scritti sulla blockchain, a meno che ciò avvenga in modo da impedire efficacemente l’identificazione degli interessati con mezzi ragionevolmente utilizzabili.
Se invece il periodo coincide con la vita della blockchain, il titolare deve poter giustificare che tale durata è necessaria e proporzionata rispetto alla finalità e documentare l’analisi che lo ha portato a questa conclusione.
Sicurezza e rischio crittografico
2.7 (paragrafi 82-89)
Le proprietà della blockchain, distribuita, disintermediata, coerente, inalterabile e trasparente, non sono garantite dalla tecnologia in quanto tale ma dipendono da tre fattori: il comportamento dei partecipanti, il numero dei nodi e un insieme di meccanismi crittografici.
Se uno cede, cede anche la proprietà che vi si appoggia ed i paragrafi dedicati alla sicurezza passano in rassegna proprio i modi in cui ciascuno può cedere.
Il comportamento dei partecipanti e il numero dei nodi vengono trattati insieme, perché il rischio è lo stesso: dato atto che un gruppo di partecipanti che ottiene abbastanza “peso” nel meccanismo di consenso può fare un uso improprio della blockchain, l’EDPB raccomanda di valutare le garanzie necessarie a ridurre o prevenire tale uso improprio.
Nelle catene permissioned quelle garanzie possono essere inserite nel rapporto contrattuale tra i partecipanti e rafforzate con privilegi amministrativi per il titolare, con un processo di concessione e mantenimento dei permessi governato da vicino.
Servono poi garanzie contro transazioni non autorizzate o non volute, per esempio da parte di chi abbia il wallet compromesso o un dipendente infedele: il che implica, per i partecipanti stessi, l’obbligo di proteggere i propri sistemi.
I meccanismi crittografici cedono in un altro modo: qui l’EDPB raccomanda procedure tecniche e organizzative per limitare l’impatto di un guasto degli algoritmi, che può derivare dalla pubblicazione di una vulnerabilità o da problemi di implementazione, come un piano di emergenza che consenta di cambiarli o correggerli.
E poiché il trattamento vi si appoggia in modo determinante, il rischio di una loro compromissione va valutato rispetto alla durata di vita attesa della blockchain, non rispetto all’oggi.
Restano tre indicazioni operative: 1) documentare la governance dei cambiamenti a software e protocolli, con procedure che allineino permessi pianificati e applicazione pratica; 2) proteggere le chiavi segrete, per esempio conservandole su supporti sicuri; 3) valutare la sicurezza del trattamento nel suo complesso, anche quando i dati stanno off-chain, perché le violazioni possono nascere da vulnerabilità dell’infrastruttura con cui si interagisce con la blockchain, l’esempio dell’EDPB è il furto di identità.
In quest’ottica anche i dati on-chain vanno minimizzati.
In conclusione, considerato che la sicurezza è un requisito previsto dal GDPR, se non è possibile raggiungerne il livello appropriato al rischio usando soluzioni blockchain, il titolare non deve utilizzare la blockchain come parte delle proprie attività di trattamento.
Blockchain e dati personali nella valutazione d’impatto
2.8 La valutazione d’impatto: cosa deve contenere davvero (paragrafi 90-99)
Se il trattamento è suscettibile di presentare un rischio elevato per i diritti e le libertà delle persone fisiche, la valutazione d’impatto è obbligatoria; i criteri restano quelli elaborati dal Gruppo di lavoro Articolo 29 e fatti propri dall’EDPB.
Il paragrafo 92 aggiunge che, se il modello di blockchain scelto crea rischi che non possono essere mitigati con misure tecniche e organizzative appropriate, il titolare ha sempre l’opzione di usare un modello diverso o un’altra tecnologia che riduca quei rischi o non li introduca affatto.
I rischi non derivano solo dalla memorizzazione dei dati on-chain, ma anche dalle operazioni inerenti al modello.
L’EDPB elenca la comunicazione di transazioni e blocchi tra i diversi soggetti, la raccolta e conservazione delle transazioni in attesa di validazione per la creazione dei blocchi, la gestione dei blocchi nei rami senza sbocco, la conservazione off-chain dei dati collegati a identificativi o impronte presenti on-chain, la generazione e conservazione dei metadati di comunicazione e la gestione del materiale crittografico: chiavi, seed, salt.
Il paragrafo 96 chiede di gestire l’obsolescenza crittografica: tutti i sistemi di cifratura hanno una durata indeterminata ma limitata, e nel valutare il rischio va considerato lo sforzo computazionale necessario a violarli, incluso l’impatto potenziale di sviluppi come i computer quantistici rilevanti per la crittanalisi.
Il bilanciamento va fatto rispetto alla sensibilità e al valore dei dati e ai rischi per l’interessato, non rispetto al trattamento in sé e, a seconda del rischio, vanno pianificate in anticipo misure per rafforzare il sistema di cifratura o per migrare il trattamento su altre tecnologie.
Diritti degli interessati e progettazione
3.(paragrafi 100-107)
Veniamo ora al capitolo 5 delle linee guida (paragrafi 100-107), dedicato ai diritti degli interessati.
È il più breve del documento.
Ed è quello in cui la distanza tra l’architettura tecnica e le categorie del GDPR appare più forte.
Su informativa, accesso e portabilità l’EDPB non registra incompatibilità strutturali: l’esercizio di questi diritti è compatibile con le proprietà tecniche della blockchain, purché il titolare rispetti integralmente i requisiti che il GDPR detta per ciascuno di essi (artt. 12, 15 e 20 GDPR).
Il quadro cambia con cancellazione e opposizione (artt. 17 e 21 GDPR), che, dicono le linee guida, devono essere garantite by design.
L’EDPB prende atto che la cancellazione effettiva di un dato scritto sulla blockchain può essere tecnicamente impraticabile; la conseguenza non è però un’esenzione, bensì la presenza di specifiche caratteristiche di progettazione: in altre parole il titolare deve assicurare che ogni dato personale memorizzato sulla blockchain possa essere “effettivamente reso anonimo” quando la richiesta arriva.
Il che presuppone due condizioni: che i dati di transazione on-chain non consentano l’identificazione diretta dell’interessato, e che i dati off-chain (in grado di consentirne l’identificazione indiretta con mezzi ragionevolmente utilizzabili) possano essere cancellati.
E qui si precisa che se non è possibile ottenere questo risultato nella pratica, occorre considerare altri strumenti (par. 103).
In sostanza: se non si possono garantire i diritti occorre scegliere un’altra tecnologia.
Sulla rettifica (art. 16 GDPR) l’indicazione è pragmatica: in alcuni casi il diritto può essere soddisfatto con una transazione successiva che annuncia l’annullamento della precedente, la quale però resterà visibile sulla blockchain; dove la rettifica richiede la cancellazione del dato, valgono le soluzioni viste sopra.
Chiude il capitolo l’art. 22 GDPR.
L’esecuzione di uno smart contract può costituire, in certi casi, una decisione basata unicamente sul trattamento automatizzato; quando ricade nell’ambito dell’art. 22, il titolare deve garantire le tutele previste dalla norma – incluso l’intervento umano e la possibilità di contestare la decisione – anche se lo smart contract è già stato eseguito e a prescindere da ciò che è registrato sulla blockchain.
L’affermazione merita una sottolineatura: ciò che la blockchain registra e ciò che il diritto considera dovuto possono divergere, e in caso di divergenza prevale il secondo.
L’intervento umano opererà necessariamente off-chain, sul rapporto giuridico sottostante – con una transazione compensativa, un rimborso, una nuova decisione – perché il codice, una volta eseguito, non torna indietro.
La Raccomandazione 16 dell’Allegato A fissa infine il principio di chiusura: i diritti degli interessati non possono essere limitati né dalla scelta implementativa né dal consenso dell’interessato.
I nodi giuridici ancora aperti
La ricostruzione tecnica ha mostrato un documento coerente e ormai stabile.
La lettura giuridica deve però andare oltre: quattro nodi, in particolare, condizioneranno l’applicazione concreta delle linee guida.
Nessuno dei quattro è davvero chiuso.
Dato personale e anonimizzazione
Il primo nodo è il perimetro.
Le linee guida qualificano indirizzi dei portafogli, identificativi di transazione e impronte crittografiche come dati personali ogni volta che consentono l’identificazione diretta o indiretta di una persona fisica con mezzi ragionevolmente utilizzabili; e il report sulla consultazione, come si è visto, respinge espressamente la proposta di escluderli a priori.
Sul punto è però intervenuta (tra le due versioni) la CGUE, 4 settembre 2025, C-413/23 P, EDPS c. SRB (nota come sentenza Deloitte): i dati pseudonimizzati trasmessi a un terzo non costituiscono automaticamente dati personali per il destinatario; l’identificabilità va valutata in concreto, dalla prospettiva del soggetto che riceve i dati e dei mezzi che questi può ragionevolmente utilizzare.
A parere di chi scrive, esiste quindi una tensione con l’impostazione delle linee guida.
Per il titolare che ha generato l’impronta e conserva off-chain il dato originario, il salt o la chiave, l’impronta resta con ogni evidenza un dato personale: qui la qualificazione dell’EDPB è pienamente coerente con la sentenza.
Ma per il singolo nodo che detiene soltanto la copia del registro – senza alcun accesso ai dati off-chain, al salt o alla chiave – l’approccio Deloitte imporrebbe di chiedersi se quel soggetto disponga davvero di mezzi ragionevolmente utilizzabili per identificare qualcuno.
Le linee guida non sviluppano questa prospettiva differenziata e trattano la qualificazione come tendenzialmente unitaria per l’intera rete.
Il quadro, peraltro, è tutt’altro che assestato.
Nella stessa plenaria di luglio 2026 l’EDPB ha adottato le Guidelines 02/2026 sull’anonimizzazione, poste in consultazione pubblica fino al 30 ottobre 2026 (testo, dunque, non definitivo): è lì che si deciderà dove passa davvero il confine tra pseudonimizzazione e anonimizzazione – cioè il confine su cui poggia l’intero impianto delle linee guida blockchain, dalla qualificazione delle impronte alla cancellazione mediante anonimizzazione di cui subito si dirà.
Blockchain e dati personali tra cancellazione e anonimizzazione
4.2 La cancellazione che diventa anonimizzazione: adempimento dell’art. 17 GDPR?
Il secondo nodo discende dal primo.
Di fronte ad una richiesta ex art. 17 GDPR (cancellazione dei dati), lo schema delle linee guida è il seguente: si cancellano i dati off-chain (dato originario, sale, chiave), così che ciò che resta on-chain non consenta più l’identificazione (non a caso l’EDPB usa con costanza la formula “cancellati o resi anonimi”, mai “cancellati” soltanto).
Le condizioni sono però due.
- che l’anonimizzazione sia effettiva, cioè che il risultato superi il test dell’identificabilità con mezzi ragionevolmente utilizzabili; ed è esattamente il test che le Guidelines 02/2026 stanno ridefinendo, il che rende la soluzione giuridicamente instabile fino all’esito della consultazione.
- che la soluzione sia stata progettata prima, perché un’architettura che non ha separato fin dall’inizio dato identificativo off-chain e traccia sulla blockchain non ha, al momento della richiesta, nulla da cancellare che possa “spegnere” l’identificabilità.
Titolarità e influenza determinante
Il terzo punto è il più complesso: quali attività di un nodo integrano quella “influenza determinante” sulla finalità e mezzi essenziali tale da fondare la titolarità o la contitolarità del trattamento?
La CGUE ha costruito una nozione ampia e funzionale di contitolarità, che non richiede l’accesso ai dati né un contributo paritario e può riguardare singole fasi del trattamento (CGUE, 5 giugno 2018, C-210/16, Wirtschaftsakademie; CGUE, 29 luglio 2019, C-40/17, Fashion ID).
E le Guidelines 07/2020 dell’EDPB su titolare e responsabile distinguono i mezzi essenziali del trattamento (quali dati, per quanto tempo, chi vi accede) dai mezzi non essenziali, che possono essere rimessi a chi esegue.
Applicate ai tre scenari delineati dalle linee guida (v. § 2.4), queste categorie portano, a parere di chi scrive, a un risultato così sintetizzabile:
Il nodo che si limita a validare secondo le regole del protocollo esercita mezzi non essenziali: cioè esegue, non decide.
Il nodo che sceglie quali transazioni includere per estrarne valore, che censura selettivamente, che vota una biforcazione del protocollo, partecipa invece alla determinazione dei mezzi essenziali – e la contitolarità diventa difficilmente evitabile.
Il problema vero non è la qualificazione: è che l’art. 26 GDPR sulla contitolarità presuppone un accordo interno tra contitolari, e su una blockchain pubblica ad accesso libero non esiste né la sede né la controparte per concluderlo.
La raccomandazione dell’EDPB – costituire un consorzio o altra entità giuridica tra i nodi – risolve il problema solo in teoria: su una blockchain pubblica matura non è praticabile, perché nessuno può obbligare migliaia di validatori anonimi a consorziarsi.
Se il consorzio non si costituisce, la determinazione della titolarità può derivare solo da elementi fattuali.
Quindi probabilmente le autorità di controllo cercheranno – e troveranno – gli anelli identificabili della blockchain “decentralizzata”: chi sviluppa e promuove il protocollo, chi offre servizi sopra la blockchain e, soprattutto, chi vi costruisce sopra un’applicazione.
In sostanza chi usa una blockchain pubblica per un proprio trattamento sarà considerato titolare, senza potersi trincerare dietro la decentralizzazione dell’infrastruttura – che le linee guida escludono espressamente possa essere invocata per non rispettare il GDPR.
Trasferimenti internazionali e catene permissionless
L’ultimo nodo è, forse, il più dirimente.
Le linee guida riconoscono che una blockchain comporta spesso trasferimenti verso paesi terzi, perché i nodi sono ovunque; l’indicazione operativa – incorporare clausole contrattuali tipo nel contratto da firmare prima di essere ammessi come nodo – presuppone però, come osservato al § 2.5, un modello ad accesso autorizzato.
Su una blockchain pubblica permissionless quel momento contrattuale non esiste.
Quali alternative, allora?
Gli strumenti dell’art. 46 GDPR presuppongono tutti controparti identificate: clausole contrattuali tipo, norme vincolanti d’impresa, codici di condotta richiedono di sapere chi riceve i dati – e qui, invece, non si sa chi sia il ricevente.
Restano le deroghe dell’art. 49 GDPR, ma la strada è stretta: per costante impostazione (EDPB, Guidelines 2/2018 sulle deroghe dell’art. 49, adottate il 25 maggio 2018) le deroghe sono di interpretazione restrittiva e coprono trasferimenti occasionali e non ripetitivi.
In una blockchain pubblica il trasferimento non è l’eccezione: è il funzionamento ordinario del sistema, continuo e strutturale.
Fondarlo sulle deroghe significherebbe rovesciarne la logica.
Purtroppo, la realtà è che per un titolare stabilito nell’UE che scriva dati personali su una blockchain pubblica permissionless non esiste, allo stato, uno strumento del Capo V del GDPR utilizzabile a regime.
Ne discendono due sole vie: fare in modo che ciò che sta on-chain non sia dato personale – il che riporta al primo nodo, e al rigore del test di anonimizzazione – oppure scegliere un’architettura permissioned.
È il punto in cui la preferenza dell’EDPB per le catene ad accesso autorizzato smette di essere una preferenza e diventa, di fatto, un vincolo.
Blockchain e dati personali: la scelta tecnologica diventa conformità
Tiriamo le fila.
La versione 2.0 non cambia la sostanza: consolida un impianto severo e lo rende definitivo.
Per chi opera, gli adempimenti sono i seguenti:
– valutazione preventiva documentata: le quattro domande della Raccomandazione 1 dell’Allegato A (dati personali on-chain? perché la blockchain? quale tipo? quali misure?) vanno messe a verbale prima di scrivere una riga di codice, e la DPIA – quando dovuta – va tenuta viva come processo continuo;
– dati personali on-chain: la regola di default è non scriverli; l’architettura di riferimento è la prova di esistenza, con i dati identificativi off-chain ed on-chain solo impronte con salt o chiave, impegni crittografici o puntatori;
– base giuridica trattamento per il trattamento (con estrema cautela sul consenso): se l’architettura non consente cancellazione o anonimizzazione effettiva alla revoca, il consenso non è una base utilizzabile;
– ruoli scritti nella governance: nelle catene permissioned, contratti con i nodi che allochino le responsabilità e incorporino le clausole contrattuali tipo; nelle permissionless, consapevolezza che l’allocazione resterà fattuale e che l’autorità cercherà l’anello identificabile;
– diritti progettati, non subiti: procedura di anonimizzazione per le richieste ex artt. 17 e 21 GDPR, rettifica mediante transazione successiva, presidio umano ex art. 22 sugli smart contract;
– trasferimenti mappati: dove sono i nodi, quali dati vedono, con quale strumento del Capo V – e, se la risposta è “nessuno”, la scelta tecnologica va rivista.
Il filo conduttore delle Linee Guida è chiaro: se il modello scelto crea rischi che non possono essere mitigati, il titolare ha sempre l’opzione di usare un modello diverso o un’altra tecnologia.
Il messaggio dell’intero documento è dunque quello per cui la conformità non si ottiene correggendo a valle una tecnologia già scelta; si decide a monte, nella scelta della tecnologia.
La protezione dei dati entra così, a pieno titolo, tra i criteri di architettura dei sistemi – non tra i documenti da produrre dopo.
Il tassello finale
Il confine tra pseudonimizzazione e anonimizzazione – dal quale dipendono la qualificazione degli identificativi sulla blockchain, la tenuta della cancellazione mediante anonimizzazione e, in ultima analisi, la stessa praticabilità delle catene pubbliche – è in corso di ridefinizione nelle Guidelines 02/2026 sull’anonimizzazione, in consultazione fino al 30 ottobre 2026: chi opera nel settore farebbe bene a presidiare quella consultazione, non a subirne l’esito.
Partecipa alla community