Quando un progetto incrocia blockchain e GDPR, le tensioni emergono subito: una tecnologia pensata per essere immutabile e replicata su più nodi deve convivere con principi come minimizzazione, limitazione della conservazione, diritto all’oblio e rettifica. Le Linee Guida EDPB 02/2025, adottate l’8 aprile 2025 in versione per consultazione pubblica, forniscono il primo quadro organico a livello europeo per affrontare questa convivenza. Questa guida traduce quel quadro in scelte operative concrete: quando ha senso usare blockchain, quale architettura scegliere, dove conservare i dati personali, come gestire i diritti degli interessati.

1. Il quadro normativo

Le Linee Guida EDPB 02/2025 sul trattamento di dati personali tramite tecnologie blockchain non introducono nuovi obblighi, ma chiariscono come le regole già vigenti del GDPR si applicano a una tecnologia che, per sua natura, sfida diversi principi cardine della protezione dei dati.

Il punto di partenza è netto: la blockchain è una tecnologia, non un trattamento di dati personali in sé. Ma la scelta di usarla incide sul modo in cui i dati vengono trattati e sulla possibilità di rispettare il GDPR. Il titolare del trattamento, ai sensi dell’art. 24 GDPR, deve quindi valutare a monte se questa tecnologia consente di adempiere agli obblighi normativi, in particolare a quelli derivanti dall’art. 5 GDPR (principi) e dall’art. 25 GDPR (privacy by design e by default).

Il riferimento normativo non si esaurisce qui. Le Linee Guida richiamano espressamente anche il Reg. UE 2023/2854 (Data Act), che all’art. 2, par. 39, definisce lo smart contract come “un programma informatico utilizzato per l’esecuzione automatizzata di un accordo o di parte di esso”. Ed evocano, in filigrana, l’AI Act (Reg. UE 2024/1689) e il regolamento MiCAR per i progetti che combinano blockchain, intelligenza artificiale e cripto-attività.

Va precisato un dato importante: si tratta ancora di una versione adottata per la consultazione pubblica. Il testo definitivo potrebbe contenere modifiche, ma l’impianto e le 16 raccomandazioni dell’Annex A rappresentano già un riferimento concreto per chi sta progettando un sistema blockchain.

2. Chi è coinvolto e in quali casi si applicano le regole

Le Linee Guida si rivolgono a chiunque tratti dati personali utilizzando tecnologie di registro distribuito (DLT). Il perimetro applicativo è ampio e include scenari molto diversi tra loro: piattaforme di gestione dell’identità digitale, supply chain tracciate on-chain, sistemi di certificazione di credenziali, marketplace NFT, applicazioni DeFi, soluzioni di notarizzazione documentale, smart contract per assicurazioni parametriche.

Le blockchain controllate da una singola entità per uso interno sono parzialmente fuori scope, ma anche per esse vale comunque il dovere di valutare la necessità del ricorso a questa tecnologia quando si trattano dati personali.

L’EDPB distingue due assi di classificazione: pubblica o privata e permissioned o permissionless. Le combinazioni più diffuse sono blockchain pubbliche permissionless (Bitcoin, Ethereum) e blockchain private permissioned, tipicamente adottate in contesti aziendali. La scelta tra queste opzioni non è solo tecnica: incide direttamente sull’allocazione dei ruoli ex art. 4 GDPR, sui rischi per gli interessati e sulla fattibilità stessa della compliance.

Chi assume il ruolo di titolare del trattamento? La risposta richiede una valutazione fattuale che tenga conto della natura del servizio, del modello di governance, delle caratteristiche tecniche e dei rapporti tra gli attori coinvolti. In una blockchain permissioned con un’autorità chiaramente identificata, l’attribuzione delle responsabilità è più lineare. In una permissionless pubblica, i nodi possono assumere ruoli diversi a seconda dell’attività: in alcuni casi non determinano finalità e mezzi essenziali, in altri esercitano un’influenza decisiva e possono qualificarsi come titolari o contitolari ai sensi dell’art. 26 GDPR. Quando i nodi agiscono di fatto come gruppo decisionale, l’EDPB raccomanda di costituire un consorzio o altra entità giuridica che assuma formalmente il ruolo di titolare.

3. Cosa fare in concreto: il percorso decisionale per progetti blockchain e GDPR

Le Linee Guida propongono un percorso decisionale strutturato su quattro domande, che il titolare deve documentare prima di implementare qualsiasi soluzione blockchain. Va affrontato in sequenza, perché ogni risposta incide su quella successiva.

3.1 Valutare se servono davvero dati personali on-chain

La prima domanda è semplice ma decisiva: i dati registrati sulla blockchain conterranno dati personali? Vanno considerati sia i metadati delle transazioni (chiavi pubbliche, identificatori utente) sia il payload (contenuto della transazione). Anche una chiave pubblica, se associata a una persona fisica con mezzi ragionevolmente utilizzabili, costituisce dato personale ai sensi dell’art. 4, par. 1, GDPR.

Se la risposta è affermativa, occorre giustificare la necessità della blockchain rispetto ad altre tecnologie. Questa giustificazione non è una formalità: deve essere documentata e dimostrare che le alternative meno invasive sono state valutate e scartate per ragioni concrete, in linea con il principio di necessità.

3.2 Scegliere il tipo di blockchain corretto

L’EDPB esprime una preferenza chiara: le organizzazioni dovrebbero privilegiare blockchain permissioned, perché consentono un’allocazione più chiara delle responsabilità e un controllo più efficace sugli accessi. La scelta di una blockchain pubblica permissionless richiede una giustificazione documentata e una valutazione approfondita dei rischi.

In parallelo, va valutato se è possibile adottare architetture “zero-knowledge”, che usano tecniche crittografiche avanzate per nascondere gli identificatori a chi non è parte della transazione.

3.3 Decidere on-chain o off-chain (e come)

Questo è probabilmente il passaggio più operativo. La regola generale è chiara: evitare di scrivere dati personali direttamente sulla blockchain, oltre agli identificatori strettamente necessari alla transazione. La conservazione off-chain è la soluzione preferita perché facilita rettifica, cancellazione e applicazione dei principi di minimizzazione e limitazione della conservazione.

Quando la conservazione on-chain è inevitabile, si possono usare tre tecniche, ciascuna con vantaggi e limiti:

• Cifratura del payload: rende il dato leggibile solo a chi ha la chiave. Il dato cifrato resta dato personale. La cifratura state-of-the-art di oggi può non bastare nel lungo periodo.
• Hash con chiave o salt: si memorizza on-chain solo l’output della funzione hash, mentre il dato originale e il salt restano off-chain. La cancellazione del salt rende l’hash inutilizzabile per identificare l’interessato.
• Cryptographic commitment: si memorizza on-chain solo l’impegno crittografico, con il dato originale e il witness off-chain. È la soluzione più protettiva, perché un commitment “perfectly hiding” diventa privo di valore identificativo una volta cancellato il dato off-chain.

La memorizzazione di dati personali in chiaro on-chain è fortemente sconsigliata: confligge con quasi tutti i principi dell’art. 5 GDPR.

3.4 Definire periodo di conservazione e governance

Il fatto che la blockchain sia tamper-proof non autorizza a conservare i dati per la sua intera durata. Il periodo di conservazione va stabilito in base alla finalità, secondo l’art. 5, par. 1, lett. e), GDPR, e va supportato da una soluzione tecnica che garantisca la cancellazione o l’anonimizzazione effettiva alla scadenza.

Se nessuna soluzione tecnica garantisce questa cancellazione, i dati personali non devono essere scritti on-chain. È un principio operativo netto, che ribalta l’approccio frequente di chi considera la persistenza on-chain una caratteristica e non un problema.

3.5 Checklist operativa di progetto

Prima di mettere in produzione un sistema blockchain che tratta dati personali:

1. Documentare l’analisi sulla necessità della blockchain e sulle alternative valutate.
2. Scegliere il tipo di blockchain (preferibilmente permissioned) e motivare la scelta.
3. Mappare quali dati personali finiranno on-chain e quali off-chain.
4. Selezionare le tecniche di protezione (cifratura, hash con salt, commitment) in base ai rischi.
5. Definire ruoli e responsabilità ex artt. 24, 26 e 28 GDPR tra tutti gli attori coinvolti.
6. Stabilire il periodo di conservazione e la procedura di cancellazione/anonimizzazione.
7. Predisporre meccanismi per rispondere alle richieste di accesso, rettifica e cancellazione.
8. Condurre una DPIA ai sensi dell’art. 35 GDPR quando il trattamento presenta rischi elevati.
9. Verificare i trasferimenti internazionali ex Capo V GDPR, soprattutto se i nodi sono fuori UE.
10. Predisporre un piano di gestione delle vulnerabilità crittografiche e degli incidenti di sicurezza.

4. Gli errori più comuni da evitare quando si combinano blockchain e GDPR

Dalla lettura delle Linee Guida emergono alcuni errori ricorrenti nei progetti blockchain che trattano dati personali. Sono pattern che si ripetono e che vale la pena conoscere prima di entrare in produzione.

Il primo è assumere che l’impossibilità tecnica giustifichi la non conformità. L’EDPB lo esclude in modo netto: il fatto che cancellare un blocco sia tecnicamente difficile non autorizza a non rispettare il diritto all’oblio ex art. 17 GDPR. La progettazione deve anticipare il problema, non subirlo.

Il secondo è conservare dati personali in chiaro on-chain “tanto è cifrato dalla blockchain”. La firma digitale e l’hash di blocco non sono misure di confidenzialità del payload: chi ha accesso alla chain legge il dato in chiaro.

Il terzo è trattare la durata della blockchain come periodo di conservazione. La persistenza tecnica non determina la liceità della conservazione: il termine deve essere stabilito in base alla finalità, e se non è gestibile sulla chain occorre scegliere un’altra architettura.

Il quarto è trascurare i trasferimenti internazionali. Le blockchain pubbliche hanno nodi distribuiti globalmente, spesso fuori UE. Questo configura trasferimenti ai sensi del Capo V GDPR che vanno valutati e, dove possibile, regolati con clausole contrattuali tipo o altri strumenti idonei.

Il quinto è non predisporre una DPIA. Un trattamento blockchain con dati personali presenta quasi sempre quei criteri di rischio elevato che, secondo l’art. 35 GDPR e le linee guida WP29 sulla DPIA, rendono obbligatoria la valutazione d’impatto: uso innovativo della tecnologia, monitoraggio sistematico, processo automatizzato con effetti significativi.

Il sesto è affidarsi al consenso come base giuridica senza meccanismi di revoca effettivi. La Raccomandazione 9 dell’Annex A è chiara: se l’architettura non consente di cancellare i dati personali a fronte della revoca del consenso, il consenso non è una base giuridica utilizzabile.

5. Sanzioni e rischi nei progetti blockchain non conformi al GDPR

I rischi sanzionatori per un trattamento non conforme via blockchain seguono le regole generali del GDPR. Le violazioni dei principi dell’art. 5 e dei diritti degli interessati possono comportare sanzioni amministrative fino a 20 milioni di euro o al 4% del fatturato annuo globale, ai sensi dell’art. 83, par. 5, GDPR.

Ma il rischio reale, nei progetti blockchain, va oltre la sanzione. Una non conformità strutturale può rendere necessario dismettere o ricostruire da zero l’intera infrastruttura, con costi enormi e impatti reputazionali. Per questo l’EDPB insiste sull’approccio by design: una scelta architetturale sbagliata in fase iniziale è molto difficile da correggere a sistema avviato.

A questi si aggiungono i rischi indiretti: contenziosi con utenti che esercitano diritti non esercitabili, contestazioni da parte di partner commerciali, blocco di operazioni di funding o M&A in fase di due diligence, ostacoli all’ottenimento di certificazioni o all’accesso a mercati regolati.

C’è poi un rischio specifico delle blockchain pubbliche permissionless: la qualificazione come contitolare può ricadere su soggetti che non avevano valutato questa eventualità, con tutto il carico di obblighi di trasparenza, tenuta del registro, gestione delle richieste degli interessati e accountability che ne deriva.

In breve: