Blockchain e GDPR dopo le Linee Guida EDPB 02/2025 versione 2.0: continuità interpretativa, metadati on-chain e il ruolo decisivo dell’anonimizzazione

Abstract

Il Comitato europeo per la protezione dei dati ha adottato, in data 7 luglio 2026, la versione definitiva delle Linee Guida 02/2025 sul trattamento dei dati personali mediante tecnologie a registro distribuito, all’esito della consultazione pubblica conclusasi il 9 giugno 2025. Il documento conferma nella sostanza l’impianto della prima versione dell’aprile 2025 : preferenza per architetture permissioned, possibile qualificazione dei nodi come titolari o contitolari ai sensi dell’articolo 26 del Regolamento (UE) 2016/679, centralità della valutazione d’impatto ex articolo 35 e affermazione per cui l’impossibilità tecnica non giustifica la non conformità. Le integrazioni riguardano i metadati on-chain quali dati personali, il riconoscimento condizionato delle Privacy Enhancing Technologies, il raccordo con gli obblighi di conservazione di MiCAR e AMLR e un glossario ampliato. Si sostiene in questa sede che il baricentro pratico della conformità si sposti sull’anonimizzazione progettata by design, letta alla luce delle Linee Guida 02/2026 e della giurisprudenza della Corte di giustizia sull’approccio relativo all’identificabilità.

Premessa

In premessa va detto che il rapporto fra tecnologie a registro distribuito e disciplina europea di protezione dei dati personali non nasce con le Linee Guida in commento. Trattasi di un tema che accompagna il dibattito applicativo del Regolamento (UE) 2016/679 sin dalla sua entrata in vigore, e che aveva già trovato riscontri parziali in contributi nazionali e in studi commissionati dalle istituzioni europee. La ragione della difficoltà è nota: il Regolamento presuppone che esista un soggetto identificabile in grado di determinare finalità e mezzi del trattamento, di cancellare i dati quando non più necessari, di rettificarli quando inesatti e di rispondere agli interessati; la blockchain, specie nella variante pubblica e permissionless, è concepita per rendere strutturalmente arduo ciascuno di questi passaggi, poiché la sua utilità funzionale risiede proprio nell’assenza di un centro di imputazione unico e nella tendenziale immodificabilità delle registrazioni.

Il perimetro dell’analisi che segue è duplice. Da un lato si esamina che cosa la versione 2.0 delle Linee Guida 02/2025 confermi rispetto alla prima stesura e che cosa invece integri, con particolare attenzione ai passaggi che producono effetti immediati sulla documentazione di conformità delle organizzazioni: registro dei trattamenti ex articolo 30 del Regolamento, informative ex articoli 13 e 14, valutazione d’impatto ex articolo 35, politiche di conservazione. Dall’altro si prova a ricostruire il punto di equilibrio che, secondo il parere di chi scrive, le Linee Guida stesse suggeriscono senza enunciarlo in modo del tutto esplicito: la conformità di un trattamento su registro distribuito non si gioca sulla capacità — di norma inesistente — di cancellare un dato già scritto in catena, bensì sulla capacità di progettare l’architettura in modo che, decorso il periodo di conservazione, il residuo on-chain non sia più riconducibile a una persona fisica con mezzi ragionevolmente utilizzabili.

Restano fuori dal perimetro le questioni di diritto dei contratti relative agli smart contract, i profili di qualificazione delle cripto-attività sotto il profilo finanziario e le implicazioni fiscali, che pure toccano gli stessi operatori ma seguono logiche autonome. L’analisi si mantiene sul piano della protezione dei dati personali e dei suoi raccordi con la disciplina antiriciclaggio e con il Regolamento (UE) 2023/1114, nella misura in cui le Linee Guida stesse li richiamano.

Il quadro normativo di riferimento

La disciplina europea generale

Il fondamento dell’intera costruzione resta l’articolo 4 del Regolamento (UE) 2016/679, che definisce il dato personale come “qualsiasi informazione riguardante una persona fisica identificata o identificabile” e precisa che “si considera identificabile la persona fisica che può essere identificata, direttamente o indirettamente, con particolare riferimento a un identificativo come il nome, un numero di identificazione, dati relativi all’ubicazione, un identificativo online”. In sostanza, la nozione è funzionale e non formale: non conta la forma alfanumerica dell’informazione, conta la sua attitudine a ricondurre a un individuo. In termini più pragmatici, un indirizzo di portafoglio composto da caratteri privi di significato linguistico è dato personale se, unito ad altre informazioni disponibili, consente di risalire al titolare del portafoglio; e non lo è se tale collegamento risulta irrealizzabile con mezzi ragionevolmente utilizzabili.

Su questa base poggiano i principi dell’articolo 5, e in particolare la minimizzazione — i dati devono essere “adeguati, pertinenti e limitati a quanto necessario rispetto alle finalità” — e la limitazione della conservazione, per cui i dati devono essere conservati “per un arco di tempo non superiore al conseguimento delle finalità per le quali sono trattati”. A questi si aggiunge l’accountability del paragrafo 2, che impone al titolare non solo di rispettare i principi ma di essere in grado di dimostrarlo. Va detto che, nel contesto delle tecnologie distribuite, l’accountability assume un peso specifico superiore alla media: laddove la struttura tecnica non consente rimedi ex post, la documentazione delle scelte progettuali diventa l’unico presidio dimostrativo disponibile.

Rilevano altresì l’articolo 24 sulla responsabilità del titolare, l’articolo 25 sulla protezione dei dati fin dalla progettazione e per impostazione predefinita, l’articolo 26 sulla contitolarità, l’articolo 28 sui responsabili del trattamento, l’articolo 32 sulla sicurezza — che menziona espressamente la pseudonimizzazione e la cifratura fra le misure appropriate — e l’articolo 35 sulla valutazione d’impatto. Sul versante dei diritti, vengono in gioco l’articolo 16 sulla rettifica, l’articolo 17 sulla cancellazione, l’articolo 18 sulla limitazione e l’articolo 23 sulle restrizioni che il diritto dell’Unione o degli Stati membri può introdurre. Non da ultimo, il Capo V sui trasferimenti verso Paesi terzi assume rilievo pratico non banale quando i nodi che replicano il registro sono distribuiti su scala globale.

Le fonti di settore richiamate dalle Linee Guida

La versione 2.0 introduce un richiamo espresso agli obblighi di conservazione derivanti dal Regolamento (UE) 2023/1114 relativo ai mercati delle cripto-attività — con riferimento agli articoli 68, paragrafo 9, e 76, paragrafo 15 — e dal Regolamento (UE) 2024/1624 in materia di prevenzione dell’uso del sistema finanziario a fini di riciclaggio, con riferimento all’articolo 77. Entrambe le previsioni impongono, per quanto qui rileva, la conservazione dei dati identificativi e transazionali per un periodo di almeno cinque anni dalla cessazione del rapporto d’affari. La nota precisa altresì che il Regolamento (UE) 2024/1624 troverà applicazione dal 10 luglio 2027 e che, nel frattempo, resta operativo l’articolo 40 della direttiva (UE) 2015/849.

Il raccordo non è meramente compilativo. L’articolo 5, paragrafo 1, lettera e), del Regolamento (UE) 2016/679 impone di conservare i dati per il tempo necessario alle finalità, ma il tempo necessario può essere determinato altrove da una norma di legge; l’articolo 6, paragrafo 1, lettera c), fornisce a sua volta la base giuridica dell’obbligo legale. Ne discende che il prestatore di servizi per le cripto-attività non versa in una condizione di conflitto insanabile fra antiriciclaggio e protezione dei dati: la retention quinquennale è, per l’appunto, la traduzione normativa del periodo necessario, purché il titolare documenti la corrispondenza fra categorie di dati conservati e categorie di dati che la norma settoriale impone effettivamente di conservare, evitando l’estensione indiscriminata del termine a informazioni non contemplate.

Il contesto nazionale

Sul piano interno il decreto legislativo 196/2003, come modificato dal decreto legislativo 101/2018, integra la disciplina europea senza introdurre previsioni specifiche in materia di registri distribuiti. Rilevano piuttosto le disposizioni in tema di designazione del responsabile della protezione dei dati e i provvedimenti generali del Garante per la protezione dei dati personali in materia di misure di sicurezza e di valutazione d’impatto, fra cui l’elenco delle tipologie di trattamenti soggetti al requisito di una valutazione d’impatto ai sensi dell’articolo 35, paragrafo 4, del Regolamento. Non si ha evidenza, allo stato, di provvedimenti dell’Autorità italiana specificamente dedicati all’impiego di tecnologie a registro distribuito per il trattamento di dati personali; ciò non significa che il tema sia estraneo all’attenzione dell’Autorità, ma che il parametro di riferimento immediato per gli operatori nazionali resta, per l’appunto, il documento del Comitato europeo.

L’impianto confermato: le quattro posizioni non modificate

La preferenza per le architetture permissioned

Il primo profilo confermato è la preferenza per le blockchain permissioned, ossia quelle in cui un soggetto o un gruppo di soggetti determina chi possa leggere il registro, scrivervi o creare blocchi. La ragione addotta dal Comitato è di ordine giuridico prima che tecnico: un’architettura autorizzata consente un’allocazione più chiara dei ruoli e delle responsabilità, e dunque rende praticabile l’individuazione del titolare, la stipula di accordi di contitolarità ex articolo 26 e la designazione dei responsabili ex articolo 28. Le organizzazioni dovrebbero pertanto privilegiare tali architetture ed esplorare alternative di governance soltanto in presenza di ragioni giustificate e documentate, interrogandosi in quel caso sull’opportunità stessa del ricorso alla tecnologia.

Appare chiaro allo scrivente che quest’ultimo inciso costituisca il passaggio più impegnativo dell’intero documento. Il Comitato non si limita a suggerire una preferenza fra varianti tecnologiche, ma introduce un test di necessità della tecnologia in quanto tale: se la finalità perseguita può essere conseguita con un database tradizionale, l’impiego di un registro distribuito che moltiplica le copie del dato personale e ne rende ardua la cancellazione difficilmente supera il vaglio di minimizzazione e di protezione fin dalla progettazione. La critica mossa dagli operatori — secondo cui un simile approccio equivarrebbe a una presunzione di inidoneità della tecnologia — merita certamente grandissima attenzione; si ritiene tuttavia che la formulazione delle Linee Guida non giunga a tanto, poiché non esclude in radice le architetture aperte ma ne subordina l’impiego a una motivazione documentata. In questo senso, la differenza fra un divieto e un onere di motivazione rafforzato non è nominalistica ma assume valore altamente pragmatico.

I nodi come titolari o contitolari

Il secondo profilo riguarda la qualificazione soggettiva dei partecipanti alla rete. Le Linee Guida confermano che i nodi dotati di potere decisionale limitato potrebbero non qualificarsi come titolari, mentre i nodi delle reti pubbliche permissionless possono essere qualificati come titolari o contitolari qualora esercitino un’influenza determinante sulla definizione delle finalità e dei mezzi essenziali del trattamento. Resta fermo l’invito, anch’esso invariato, alla costituzione di consorzi o di altre entità giuridiche fra i nodi.

La nozione va introdotta con ordine. Il titolare, ai sensi dell’articolo 4, punto 7, del Regolamento, è chi determina finalità e mezzi del trattamento; la contitolarità dell’articolo 26 ricorre quando due o più soggetti determinano congiuntamente tali elementi. La giurisprudenza della Corte di giustizia ha da tempo chiarito che la contitolarità non presuppone né una simmetria di poteri né l’accesso ai dati da parte di ciascun contitolare. In termini più concreti, applicato a una rete distribuita, ciò significa che il soggetto il quale si limiti a eseguire un software di validazione secondo regole predeterminate da altri difficilmente determina qualcosa; mentre chi partecipa alla governance del protocollo, chi decide quali dati siano ammessi in catena, chi definisce le regole di consenso o chi gestisce l’applicazione che scrive in catena per finalità proprie, quello sì determina finalità e mezzi.

Si ritiene che la difficoltà pratica non stia nel principio, che è coerente con l’impianto del Regolamento, bensì nella sua applicazione a reti in cui i partecipanti sono migliaia, mutevoli e anonimi. L’invito alla costituzione di un consorzio è, sotto questo profilo, un suggerimento di ingegneria giuridica: costituire un’entità che assuma il ruolo di titolare — o di contitolare individuato negli accordi ex articolo 26 — è il modo più lineare per fornire agli interessati un punto di contatto ai sensi dell’articolo 26, paragrafo 1, e per rendere esigibili i diritti del Capo III.

Il quadro di valutazione preliminare e la DPIA

Il terzo profilo confermato è il quadro di valutazione preliminare richiesto al titolare prima di adottare una soluzione basata su registro distribuito: necessità del ricorso alla blockchain, scelta della tipologia di architettura, individuazione delle misure tecniche e organizzative, collocazione dei dati on-chain oppure off-chain. A tale valutazione si affiancano la centralità della valutazione d’impatto ex articolo 35, che nella generalità dei casi risulterà dovuta, e le sedici raccomandazioni dell’Allegato A, oggetto di soli affinamenti redazionali.

Va detto che la sequenza logica proposta dal Comitato ricalca, nella sostanza, la struttura dell’articolo 25 del Regolamento: la protezione dei dati fin dalla progettazione non è un adempimento documentale successivo, ma una serie di scelte architetturali compiute “al momento di determinare i mezzi del trattamento”. In termini più pragmatici, la decisione su che cosa scrivere in catena e che cosa tenere fuori è una decisione di protezione dei dati prima ancora che una decisione tecnica, e va assunta quando l’architettura è ancora modificabile a costi ragionevoli. Nell’esperienza applicativa dei sistemi di gestione, l’errore ricorrente consiste nel coinvolgere la funzione di protezione dei dati quando il progetto è già in fase di collaudo: nel caso dei registri distribuiti tale errore è, per ragioni strutturali, difficilmente rimediabile.

La cancellazione e il monito sull’impossibilità tecnica

Il quarto profilo è quello che ha suscitato le maggiori resistenze. Le Linee Guida confermano che, laddove la cancellazione dei dati non sia stata prevista fin dalla progettazione, il rispetto del principio di limitazione della conservazione potrebbe richiedere la cancellazione dell’intera blockchain — esito che risulta sostanzialmente incompatibile con la natura delle reti permissionless, le quali per struttura non possono essere costrette alla distruzione del registro distribuito. Resta parimenti immutato il monito per cui l’impossibilità tecnica non può essere invocata per giustificare la non conformità al Regolamento.

Secondo il parere di chi scrive, i due passaggi vanno letti insieme e non isolatamente. Il monito sull’impossibilità tecnica non afferma che il diritto possa imporre l’impossibile; afferma, più limitatamente, che la scelta di una tecnologia che rende impossibile l’adempimento non è opponibile all’interessato come causa di esonero. In sostanza, l’impossibilità rileva a monte, nella fase di scelta della tecnologia, e non a valle, come esimente. La conseguenza logica è severa ma, in definitiva, coerente: chi opta per un’architettura che non consente la cancellazione assume su di sé il rischio giuridico di tale scelta, e deve pertanto strutturare il trattamento in modo che la cancellazione non sia necessaria, perché il dato residuo non è più personale. Ed è qui che entra in gioco l’anonimizzazione.

L’anonimizzazione come baricentro effettivo della conformità

Ed in effetti, le Linee Guida indicano, accanto alla posizione di principio sulla cancellazione dell’intera catena, una via d’uscita più realistica. Quando la combinazione fra dati on-chain e dati off-chain è stata concepita by design in ottica di conformità, la limitazione della conservazione può essere soddisfatta impedendo la futura identificabilità dell’interessato mediante la cancellazione dei soli elementi off-chain — chiavi, salt, witness — di modo che la transazione residua sulla catena, ormai priva di valenza semantica, sopravviva al solo fine di preservare l’integrità del registro.

Il meccanismo merita di essere ricostruito in termini progressivamente più concreti. Il titolare non scrive in catena il dato personale, ma un suo derivato crittografico: un hash calcolato con l’aggiunta di un valore casuale segreto — il salt — oppure con una chiave, ovvero un impegno crittografico che vincola il valore senza rivelarlo. Il dato in chiaro, il salt e la chiave restano in un archivio esterno controllato dal titolare. Finché tale archivio esiste, il derivato on-chain è un dato personale pseudonimizzato, perché il collegamento è ripristinabile. Nel momento in cui l’archivio esterno viene distrutto, il derivato on-chain resta scritto ma non è più riconducibile ad alcuna persona: la cancellazione della chiave produce, sul piano funzionale, l’effetto che la cancellazione del dato produrrebbe in un database tradizionale.

Va detto che l’efficacia di tale meccanismo non è una questione di fede tecnologica ma di verifica puntuale. Se l’insieme dei valori possibili è ristretto — si pensi a un hash calcolato su un codice fiscale senza salt — l’attacco per forza bruta ricostruisce il dato in tempi banali, e nessuna cancellazione della chiave produce anonimato. Se invece il salt è di lunghezza adeguata, generato in modo imprevedibile e distrutto in modo irreversibile, l’inversione diventa computazionalmente non praticabile. La differenza fra le due ipotesi non è dogmatica, è misurabile; e appare chiaro allo scrivente che sia proprio questa misurazione, documentata, a costituire il cuore della DPIA di un progetto su registro distribuito.

Il punto va inoltre letto in combinato disposto con le Linee Guida 02/2026 sull’anonimizzazione, adottate nella medesima sessione plenaria del 7 luglio 2026 e sottoposte a consultazione pubblica fino al 30 ottobre 2026, che aggiornano il parere 05/2014 del Gruppo di lavoro articolo 29 alla luce della giurisprudenza della Corte di giustizia, con particolare riferimento alle pronunce nella causa C-582/14, Breyer, e nella causa C-413/23 P, EDPS contro Comitato di risoluzione unico. Recependo l’approccio relativo e contestuale affermato dalla Corte, il nuovo documento chiarisce che un dato può considerarsi anonimo quando la probabilità di identificazione dell’interessato, con i mezzi ragionevolmente utilizzabili dalle entità rilevanti, risulti insignificante, e articola il test nei tre criteri della non isolabilità del singolo record, della non collegabilità e della non inferibilità.

Il passaggio da un approccio assoluto a un approccio relativo all’identificabilità non è una concessione di comodo agli operatori. È il riconoscimento che il considerando 26 del Regolamento — il quale impone di considerare “tutti i mezzi […] di cui il titolare del trattamento o un terzo può ragionevolmente avvalersi” — richiede una valutazione contestuale e non un giudizio astratto sulla possibilità teorica di reidentificazione. In termini più pragmatici, la domanda corretta non è se qualcuno al mondo possa in linea di principio ricollegare quel dato a una persona, ma se le entità che hanno accesso al registro dispongano ragionevolmente dei mezzi per farlo. Applicato alla catena, il criterio consente di sostenere che una transazione residua, privata degli elementi off-chain che le conferivano significato, non consenta più di isolare, collegare o inferire alcunché di riferibile a una persona fisica.

Ne discende un’indicazione operativa nitida per chi progetta trattamenti su reti permissionless: strutturare sin dall’origine l’architettura on-chain e off-chain in modo che, decorso il periodo di conservazione, la cancellazione degli elementi off-chain renda i dati residui in catena effettivamente anonimi ai sensi del nuovo quadro, con conseguente fuoriuscita dall’ambito di applicazione del Regolamento e venir meno degli stessi obblighi di cancellazione. Si evita così lo scenario — problematico sul piano teorico e difficilmente praticabile su quello concreto — della distruzione dell’intero registro.

Si ritiene tuttavia doveroso segnalare due elementi di cautela. Il primo attiene al carattere non definitivo delle Linee Guida 02/2026, ancora in consultazione: fondare un’architettura su un documento suscettibile di modifiche espone a un rischio di disallineamento, che va gestito prevedendo margini di adattamento. Il secondo attiene alla dimensione temporale dell’anonimato: la valutazione sui mezzi ragionevolmente utilizzabili è ancorata allo stato della tecnica in un dato momento, mentre la catena conserva il dato per un tempo indefinito. In sostanza, ciò che oggi non è invertibile potrebbe non esserlo più fra vent’anni, e la questione dell’evoluzione della capacità computazionale — inclusa la prospettiva delle tecnologie quantistiche — non è puramente speculativa per registri destinati a durare. Non si ha evidenza che le Linee Guida affrontino compiutamente tale profilo; si suggerisce pertanto di includerlo espressamente fra le assunzioni della valutazione d’impatto, con un impegno a riesame periodico.

Le integrazioni della versione 2.0

I metadati on-chain quali dati personali

Il principio per cui i dati registrati in catena non si esauriscono nel payload delle transazioni era già presente nella prima versione. La versione definitiva lo rende operativo mediante una nota che elenca espressamente le categorie di metadati suscettibili di costituire dati personali quando consentono l’identificazione diretta o indiretta di una persona fisica: identificativi di transazione, indirizzi di portafoglio, registri degli eventi, ricevute, transizioni di stato, storage degli smart contract e relative tracce.

Il chiarimento va in direzione opposta rispetto alle richieste dell’industria di escludere tali identificativi dalla nozione di dato personale e impone una mappatura più granulare. In termini più concreti, la conseguenza per il DPO è che il registro dei trattamenti non può limitarsi a descrivere l’informazione applicativa che il progetto intendeva registrare — l’attestazione, il certificato, il titolo — ma deve dare conto anche degli elementi che l’infrastruttura genera automaticamente e che, presi insieme, consentono di ricostruire il comportamento di un individuo nel tempo. Un registro degli eventi che documenti ogni interazione di un determinato indirizzo con un contratto intelligente è, sotto il profilo funzionale, un profilo comportamentale; e la circostanza che sia generato dalla macchina anziché dall’applicazione non ne muta la natura.

Il riconoscimento condizionato delle tecnologie di rafforzamento della riservatezza

La versione finale integra il passaggio sulle misure di protezione dei dati in catena — cifratura, hashing con salt o con chiave segreta, impegni crittografici — con un richiamo espresso alle tecnologie emergenti di rafforzamento della riservatezza, quali le prove a conoscenza zero, ossia i protocolli che consentono di dimostrare la veridicità di un’affermazione senza rivelarne il contenuto, e ad altri protocolli crittografici avanzati, riconosciuti come tecniche utili a ridurre i rischi per gli interessati.

Il riconoscimento è però accompagnato da una duplice cautela, anch’essa nuova: tali tecnologie devono essere attentamente testate e validate, e non sono in ogni caso autosufficienti, dovendo essere sempre affiancate da ulteriori misure tecniche e organizzative idonee a garantire la conformità e l’esercizio dei diritti. Si ritiene che la cautela sia condivisibile e che rifletta un’esigenza ricorrente nella prassi di audit: l’adozione di una tecnologia crittograficamente robusta non equivale alla sua corretta implementazione, e la letteratura tecnica documenta con frequenza vulnerabilità derivanti non dal protocollo ma dalla sua configurazione, dalla generazione dei parametri o dalla gestione delle chiavi. In termini più pragmatici, il titolare che intenda avvalersi di una prova a conoscenza zero come misura ex articolo 32 deve essere in grado di esibire non la denominazione del protocollo, ma la documentazione della sua validazione.

Il raccordo con la disciplina delle cripto-attività e antiriciclaggio

Della nota sui periodi di conservazione si è già detto in sede di ricostruzione normativa. Va qui aggiunto il rilievo sistematico: per i prestatori di servizi per le cripto-attività autorizzati ai sensi del Regolamento (UE) 2023/1114, il richiamo offre un ancoraggio esplicito, interno alle Linee Guida, per la costruzione delle politiche di conservazione, confermando che i termini stabiliti dal diritto dell’Unione o degli Stati membri vanno tenuti in considerazione nella determinazione dei periodi di retention.

Il beneficio pratico è duplice. Da un lato consente al soggetto vigilato di motivare, in sede di valutazione d’impatto, un periodo di conservazione quinquennale senza doverlo giustificare caso per caso in termini di necessità. Dall’altro — e appare allo scrivente il profilo meno considerato — impone di distinguere accuratamente fra i dati che l’obbligo settoriale copre e quelli che non copre: la retention imposta dalla disciplina antiriciclaggio riguarda i dati identificativi e transazionali funzionali alle finalità di prevenzione, non l’intero patrimonio informativo raccolto dal prestatore nel corso del rapporto. L’estensione indiscriminata del termine quinquennale a ogni categoria di dato costituisce, secondo il parere di chi scrive, uno degli errori più diffusi nelle politiche di conservazione del settore, e si presta a rilievi in sede ispettiva.

Le restrizioni ai diritti degli interessati

Merita attenzione, sul piano sistematico, la riformulazione del passaggio dedicato alle restrizioni dei diritti. La versione finale chiarisce che gli esempi rilevanti — fra cui i casi antiriciclaggio e gli inventari di determinati beni — presuppongono che sia il diritto dell’Unione o dello Stato membro a imporre il ricorso a soluzioni basate su registro distribuito. Resta fermo che le restrizioni devono essere proporzionate, rigorosamente definite dalla legge e rispondenti al requisito di necessità in una società democratica.

La precisazione ha un effetto restrittivo significativo. L’articolo 23 del Regolamento consente al legislatore, e non al titolare, di limitare la portata dei diritti degli interessati; il titolare che abbia scelto autonomamente una tecnologia incompatibile con l’esercizio del diritto di cancellazione non può invocare l’articolo 23 per giustificare l’inadempimento, poiché la restrizione deve trovare fondamento in una misura legislativa e non in una scelta d’impresa. Si ritiene che il chiarimento fosse necessario, poiché nella prassi si è talora registrata la tendenza a leggere le previsioni settoriali sull’antiriciclaggio come un’autorizzazione generalizzata a comprimere i diritti, laddove esse operano entro confini definiti e per finalità determinate.

Il glossario ampliato

La versione 2.0 arricchisce l’Allegato B con nuove definizioni. Quella di consenso precisa che i meccanismi di accordo fra i nodi possono essere probabilistici o eventuali e che possono insorgere versioni concorrenti della catena. Quella di pubblicità è intesa come il grado di visibilità e accessibilità dei dati trattati in connessione con una blockchain, nozione centrale nell’impianto delle Linee Guida ma priva di definizione nella prima versione. Un’ampia definizione di smart contract ne cataloga le tipologie — contratti di emissione di token, di governance, multifirma o di deposito a garanzia, ponti, proxy, factory, contratti collegati a oracoli — e ne descrive le esecuzioni a cascata. Soprattutto, la definizione di indirizzo di portafoglio, account e chiave pubblica ne cristallizza la qualificazione come dato personale ai sensi dell’articolo 4 ogniqualvolta l’identificativo sia associabile a una persona fisica identificata o identificabile. Completano il quadro l’integrazione della definizione di registro — con la precisazione che nella maggior parte delle implementazioni i dati sono materializzati a livello di nodo mediante basi dati chiave-valore — e la sostituzione, nel corpo del testo, del riferimento alle “identità” delle parti con quello ai loro “identificativi”.

Quest’ultima sostituzione terminologica, apparentemente minima, ha un valore concettuale non trascurabile. Parlare di identificativi anziché di identità segnala che l’oggetto della disciplina non è l’anagrafica della persona, che nella catena non compare quasi mai, bensì il segno che la rappresenta e che, per l’appunto, la rende identificabile in senso tecnico-giuridico. Si tratta di una precisazione che allinea il lessico del documento a quello dell’articolo 4 del Regolamento e che rimuove un possibile equivoco difensivo, secondo cui l’assenza del nome in catena escluderebbe la presenza di dati personali.

Profili critici

Il primo profilo critico attiene alla tenuta della preferenza per le architetture autorizzate rispetto al principio di neutralità tecnologica, cui il considerando 15 del Regolamento fa riferimento affermando che la protezione delle persone fisiche dovrebbe essere neutrale sotto il profilo tecnologico. Si potrebbe obiettare che indicare una tipologia architetturale preferita costituisca una deviazione da tale principio. Si ritiene, con la doverosa cautela, che l’obiezione non colga nel segno: la neutralità tecnologica impone che la disciplina non favorisca né penalizzi una tecnologia in quanto tale, non che il regolatore si astenga dal rilevare che una determinata configurazione rende materialmente inesigibili obblighi che la norma impone. La preferenza espressa dal Comitato non è per una tecnologia, è per un assetto di responsabilità identificabile.

Il secondo profilo riguarda l’effettività della qualificazione dei nodi come contitolari nelle reti aperte. Anche ammettendo la correttezza dogmatica dell’inquadramento, resta il problema dell’enforcement: individuare, notificare e sanzionare migliaia di operatori di nodo dislocati in giurisdizioni diverse è impresa che, allo stato, non risulta essere stata tentata. Non si ha evidenza di procedimenti dell’Autorità italiana o di altre autorità di controllo europee che abbiano contestato a operatori di nodo la qualifica di titolare. Ne discende un rischio di scollamento fra l’affermazione di principio e la sua applicazione, che secondo il parere di chi scrive non giova alla certezza del diritto.

Il terzo profilo attiene alla posizione sulla cancellazione dell’intera catena. Anche accogliendo la lettura sopra proposta — secondo cui si tratta di una conseguenza logica dell’imputazione del rischio a chi sceglie la tecnologia, e non di una prescrizione operativa realistica — resta il fatto che l’enunciazione, isolata dal contesto, si presta a essere letta come una sanzione sproporzionata. Si sarebbe forse potuto valorizzare maggiormente, già nel corpo del testo e non solo nei passaggi successivi, il percorso dell’anonimizzazione by design, che costituisce la soluzione effettivamente praticabile. La critica è formulata in termini di tecnica redazionale e non di merito dell’orientamento.

Il quarto profilo concerne la dimensione dei trasferimenti internazionali. Le Linee Guida affrontano il tema, ma la struttura stessa di una rete globale rende la disciplina del Capo V di difficile applicazione: la replicazione del registro su nodi collocati in Paesi terzi costituisce un trasferimento, e non si vede quale strumento fra quelli dell’articolo 46 possa essere concluso con soggetti non identificati e non identificabili. Si ritiene che, allo stato, l’unica strada praticabile consista nel non collocare in catena alcun dato personale, riconducendo il trasferimento a un flusso di informazioni prive di riferibilità soggettiva — il che riporta, ancora una volta, al tema dell’anonimizzazione come precondizione architetturale.

Il quinto profilo riguarda l’articolazione fra le Linee Guida in commento e il complesso delle discipline digitali europee di recente introduzione. L’operatore che gestisce un’infrastruttura basata su registro distribuito e che rientri fra i soggetti essenziali o importanti ai sensi della direttiva (UE) 2022/2555, come recepita in Italia dal decreto legislativo 138/2024, si trova a dover conciliare obblighi di sicurezza e di notifica con vincoli di protezione dei dati; e ove l’infrastruttura incorpori componenti di “intelligenza artificiale”, si aggiungono gli obblighi del Regolamento (UE) 2024/1689. Non si ha evidenza che le Linee Guida affrontino tali sovrapposizioni, il che è comprensibile stante il loro oggetto, ma il coordinamento resta a carico del titolare.

Che cosa devono fare in concreto DPO e imprese

Il primo adempimento consiste in una verifica di necessità della tecnologia, da svolgere prima di qualunque altra valutazione e da formalizzare in un documento che dia conto delle finalità perseguite, delle alternative tecnologiche considerate e delle ragioni per cui un archivio centralizzato tradizionale non consentirebbe di conseguirle. Si suggerisce di redigere tale documento in forma sintetica ma argomentata, poiché costituisce il primo elemento che un’autorità di controllo esaminerebbe in caso di accertamento, e poiché la sua assenza rende difficilmente sostenibile il rispetto degli articoli 5, paragrafo 1, lettera c), e 25 del Regolamento. Ove l’esito della verifica sia favorevole all’impiego della tecnologia, il documento prosegue con la scelta dell’architettura, che secondo l’orientamento del Comitato dovrebbe orientarsi verso configurazioni autorizzate e che, ove si opti per una rete aperta, richiede una motivazione ulteriore e specifica sulle ragioni che rendono inadeguata l’alternativa permissioned.

Segue la mappatura granulare dei dati on-chain, che alla luce della nuova nota della versione 2.0 va estesa oltre il contenuto delle transazioni per abbracciare identificativi di transazione, indirizzi di portafoglio, registri degli eventi, ricevute, transizioni di stato e storage dei contratti intelligenti. Si ritiene che tale mappatura non possa essere condotta dalla sola funzione giuridica: richiede un confronto strutturato con chi ha progettato l’infrastruttura, poiché l’individuazione di ciò che il protocollo scrive automaticamente presuppone una conoscenza tecnica dell’implementazione specifica. L’esito confluisce nell’aggiornamento del registro dei trattamenti ai sensi dell’articolo 30, che deve descrivere le categorie di dati con un grado di dettaglio superiore a quello abituale, e nella revisione delle informative ex articoli 13 e 14, le quali dovrebbero rappresentare all’interessato, in termini comprensibili, che determinate informazioni saranno registrate in modo tendenzialmente irreversibile e replicate su una pluralità di nodi.

Sul piano della progettazione, l’adempimento centrale è la definizione della separazione fra dati on-chain e dati off-chain, che costituisce la vera misura di protezione fin dalla progettazione ai sensi dell’articolo 25. Si suggerisce di adottare come regola di lavoro il principio per cui nessun dato personale in chiaro venga mai scritto in catena, e che in catena figurino esclusivamente derivati crittografici il cui collegamento al dato in chiaro dipenda da elementi conservati fuori catena e sotto il controllo del titolare. A tale scelta si accompagna la gestione documentata del ciclo di vita delle chiavi e dei salt, che deve prevedere generazione con entropia adeguata, custodia in ambienti protetti, registrazione degli accessi e — profilo decisivo — una procedura di distruzione irreversibile allo scadere del periodo di conservazione, con evidenza dell’avvenuta esecuzione. Chi scrive ritiene che sia proprio la dimostrabilità della distruzione, e non la sua mera previsione procedurale, a fare la differenza in sede di verifica.

Ne discende, quale adempimento correlato, la valutazione documentata dell’effettività dell’anonimizzazione del residuo on-chain, da condurre secondo i tre criteri della non isolabilità, della non collegabilità e della non inferibilità, con espressa considerazione dei mezzi ragionevolmente utilizzabili dai soggetti che hanno accesso al registro. Si suggerisce di includere in tale valutazione un’assunzione esplicita sullo stato della tecnica e un impegno a riesame periodico dell’assunzione medesima, quantomeno con cadenza annuale e comunque al verificarsi di sviluppi rilevanti nella capacità computazionale disponibile, poiché la persistenza indefinita del dato in catena rende inadeguata una valutazione compiuta una tantum.

L’insieme di tali elementi confluisce nella valutazione d’impatto sulla protezione dei dati ex articolo 35, che nella generalità dei casi risulterà dovuta e che deve affrontare specificamente i profili indicati dalle Linee Guida, incluse le sedici raccomandazioni dell’Allegato A. Si ritiene opportuno che la valutazione dia conto anche del rischio di reidentificazione derivante dall’analisi delle catene di transazioni, tecnica ormai consolidata che consente di correlare indirizzi apparentemente distinti, e delle misure adottate per attenuarlo. Ove permanga un rischio elevato non mitigabile, si ricorda che l’articolo 36 impone la consultazione preventiva dell’autorità di controllo.

Sul versante soggettivo, occorre procedere alla qualificazione dei ruoli privacy di tutti i soggetti coinvolti — sviluppatori del protocollo, operatori di nodo, gestori di applicazioni, fornitori di servizi di custodia — e alla formalizzazione degli assetti individuati mediante accordi di contitolarità ex articolo 26, corredati della sintesi da mettere a disposizione degli interessati, oppure mediante atti di designazione a responsabile ex articolo 28. Ove l’architettura preveda una pluralità di partecipanti stabili, si suggerisce di valutare la costituzione di un’entità giuridica dedicata che assuma il ruolo di titolare o di punto di contatto unico, secondo l’indicazione del Comitato, poiché ciò risolve a monte il problema dell’individuazione del soggetto responsabile verso gli interessati e verso l’autorità.

Va poi predisposta una procedura per la gestione dei diritti degli interessati che affronti realisticamente i limiti dell’infrastruttura: il diritto di rettifica ex articolo 16 potrà essere soddisfatto mediante registrazione di una transazione correttiva successiva, non mediante modifica della registrazione originaria; il diritto di cancellazione ex articolo 17 potrà essere soddisfatto mediante distruzione degli elementi off-chain, con conseguente perdita di riferibilità del residuo; la limitazione ex articolo 18 richiederà interventi sul livello applicativo. Si ritiene essenziale che tali modalità siano descritte all’interessato già nell’informativa, per evitare che l’aspettativa disattesa si traduca in reclamo.

Per i soggetti vigilati, l’adempimento specifico consiste nella costruzione di una politica di conservazione differenziata, che tenga distinti i dati coperti dagli obblighi quinquennali derivanti dal Regolamento (UE) 2023/1114 e dal Regolamento (UE) 2024/1624 — nonché, sino al 10 luglio 2027, dall’articolo 40 della direttiva (UE) 2015/849 — dai dati per i quali il periodo di conservazione va determinato secondo il criterio ordinario della necessità. Si suggerisce di documentare la corrispondenza fra ciascuna categoria di dato e la fonte normativa che ne impone la conservazione, evitando estensioni indiscriminate.

Sul piano delle misure di sicurezza ex articolo 32, l’adempimento consiste nella validazione documentata delle tecnologie crittografiche adottate, con particolare riguardo alle prove a conoscenza zero e agli altri protocolli avanzati, di cui il Comitato riconosce l’utilità subordinandola a test e validazione e affiancandovi in ogni caso ulteriori misure tecniche e organizzative. Si suggerisce di acquisire dai fornitori evidenze di verifiche indipendenti dell’implementazione e non la sola dichiarazione di conformità.

Occorre infine considerare la verifica dei flussi transfrontalieri ai sensi del Capo V, che nelle reti a diffusione globale richiede quantomeno di documentare l’assenza di dati personali in catena come presupposto della non applicabilità della disciplina sui trasferimenti, e il coordinamento con le altre discipline applicabili, segnatamente gli obblighi di sicurezza e notifica derivanti dalla direttiva (UE) 2022/2555 e dal decreto legislativo 138/2024 per i soggetti che vi rientrano, nonché quelli del Regolamento (UE) 2024/1689 ove l’infrastruttura incorpori sistemi di “intelligenza artificiale”. Chiude il quadro la formazione mirata delle funzioni tecniche e di controllo, poiché nell’esperienza applicativa dei sistemi di gestione la principale causa di non conformità non risiede nell’assenza di procedure ma nella loro incomprensione da parte di chi dovrebbe attuarle.

Conclusioni

L’esito della consultazione non ha modificato l’asse regolatorio. Chi confidava in un ammorbidimento delle posizioni sulla cancellazione, sui ruoli dei nodi o sulla preferenza per le architetture autorizzate deve prendere atto che l’orientamento risulta ormai consolidato e costituisce il parametro interpretativo cui le autorità di controllo europee faranno riferimento. Con l’adozione della versione definitiva, le Linee Guida cessano di essere un documento in formazione e assumono la funzione di riferimento stabile per la valutazione dei trattamenti fondati su registro distribuito.

Restano tuttavia aperte questioni di non poco conto. La prima riguarda il grado di stabilità del quadro sull’anonimizzazione, che alla data indicata dalla fonte è ancora in consultazione: poiché la praticabilità stessa delle architetture aperte dipende dalla possibilità di qualificare come anonimo il residuo on-chain dopo la distruzione degli elementi esterni, l’esito di quella consultazione avrà sui progetti basati su blockchain un impatto probabilmente superiore a quello delle Linee Guida qui commentate. La seconda concerne l’enforcement nelle reti pubbliche: non si ha evidenza di procedimenti che abbiano contestato a operatori di nodo la qualifica di titolare, e finché tale evidenza non maturi resterà difficile misurare l’effettiva portata dell’impostazione del Comitato. La terza riguarda la dimensione temporale della valutazione di anonimato, che le Linee Guida non appaiono affrontare compiutamente e che, per registri destinati a permanere indefinitamente, solleva un problema di tenuta prospettica delle assunzioni tecniche.

Vi è poi una questione di sistema. L’affermazione per cui l’impossibilità tecnica non giustifica la non conformità è coerente con l’impianto del Regolamento, ma sposta interamente sul progettista l’onere di prevedere, al momento della scelta architetturale, ogni scenario futuro di esercizio dei diritti. Si ritiene che ciò renda la fase di progettazione il momento decisivo dell’intera vicenda di conformità, molto più della documentazione successiva; e che il ruolo del responsabile della protezione dei dati, in questi progetti, si giochi nella capacità di intervenire quando le scelte tecniche sono ancora reversibili. Nell’esperienza applicativa dei sistemi di gestione, tale tempestività è più spesso una questione organizzativa che giuridica.

Infine, si segnala che il raccordo esplicito con il Regolamento (UE) 2023/1114 e con il Regolamento (UE) 2024/1624 rappresenta, per quanto di stretto interesse in questa sede, il segnale di una tendenza più generale: le autorità di protezione dei dati mostrano crescente attenzione al coordinamento con le discipline settoriali, superando la tradizionale trattazione isolata del Regolamento generale. Trattasi di un’evoluzione che, secondo il parere di chi scrive, va accolta con favore, poiché la moltiplicazione delle fonti digitali europee rende il coordinamento interpretativo un bisogno concreto degli operatori prima ancora che un’esigenza dottrinale.

Riferimenti normativi

• Regolamento (UE) 2016/679 (GDPR)
• Regolamento (UE) 2023/1114 (MiCAR)
• Regolamento (UE) 2024/1624 (AMLR)
• Regolamento (UE) 2024/1689 (AI Act)
• Direttiva (UE) 2015/849
• Direttiva (UE) 2022/2555 (NIS2)
• decreto legislativo 196/2003
• decreto legislativo 101/2018
• decreto legislativo 138/2024
• Linee Guida EDPB 02/2025, versione 2.0
• Linee Guida EDPB 02/2026
• Parere WP29 05/2014 sulle tecniche di anonimizzazione
• Corte di giustizia dell’Unione europea, causa C-582/14, Breyer
• Corte di giustizia dell’Unione europea, causa C-413/23 P, EDPS contro Comitato di risoluzione unico