Quando un progetto incrocia blockchain e GDPR, le tensioni emergono subito. Una tecnologia pensata per essere immutabile e replicata su molti nodi deve convivere con la minimizzazione dei dati, la limitazione della conservazione, il diritto alla cancellazione e la rettifica.

Il Comitato europeo per la protezione dei dati (EDPB) ha dedicato alla blockchain le Linee guida 02/2025. Le ha adottate in versione per consultazione l’8 aprile 2025 e in versione definitiva (2.0) il 7 luglio 2026. Oggi sono quindi il riferimento stabile per chi progetta un sistema su blockchain che tratta dati personali.

Questa guida traduce quelle indicazioni in scelte operative. Quando ha senso usare la blockchain, quale architettura scegliere, dove conservare i dati personali e come garantire i diritti degli interessati.

1. Il quadro normativo

Le Linee guida non introducono obblighi nuovi. Spiegano come si applicano le regole del GDPR a una tecnologia che, per come è costruita, mette alla prova diversi suoi principi.

Il punto di partenza è che la blockchain è una tecnologia, non un trattamento di dati personali in sé. La scelta di usarla però incide sul modo in cui i dati vengono trattati e sulla possibilità di rispettare il GDPR. Il titolare del trattamento, che risponde della conformità (art. 24 GDPR), deve valutare prima se la tecnologia gli consente di rispettare i principi (art. 5) e la protezione dei dati fin dalla progettazione (art. 25).

Per gli smart contract le Linee guida rinviano alla definizione del Data Act (Regolamento UE 2023/2854). L’art. 2, punto 39, definisce il «contratto intelligente» come “un programma informatico utilizzato per l’esecuzione automatica di un accordo o di parte di esso utilizzando una sequenza di registrazioni elettroniche di dati e garantendone l’integrità e l’accuratezza del loro ordine cronologico”.

La versione definitiva conferma l’impianto della bozza, con le stesse quattro domande di valutazione e le 16 raccomandazioni raccolte nell’allegato A. Aggiunge qualche precisazione, per esempio sugli strumenti che rafforzano la riservatezza e sui termini di conservazione imposti da altre norme europee.

2. Chi è coinvolto

Le Linee guida riguardano chiunque tratti dati personali con tecnologie di registro distribuito (DLT). Il perimetro è ampio. Pensiamo, per esempio, a identità digitale, tracciabilità di filiera, certificazione di credenziali, marketplace di NFT, applicazioni di finanza decentralizzata o notarizzazione di documenti.

Le blockchain controllate da un solo soggetto per uso interno sono in parte fuori dal perimetro delle Linee guida. Anche per queste, però, resta il dovere di valutare se la tecnologia sia davvero necessaria quando tratta dati personali.

L’EDPB distingue due assi, cioè blockchain pubblica o privata, e permissioned (con partecipanti autorizzati) o permissionless (aperta a chiunque). Le combinazioni più diffuse sono le blockchain pubbliche permissionless, come Bitcoin ed Ethereum, e quelle private permissioned, tipiche delle aziende. La scelta incide sulla ripartizione dei ruoli privacy, sui rischi per gli interessati e sulla possibilità stessa di essere conformi.

2.1 Chi è titolare

Per capire chi è titolare del trattamento serve una valutazione in concreto. Contano la natura del servizio, la governance, le caratteristiche tecniche e i rapporti tra i soggetti coinvolti.

In una blockchain permissioned con un’autorità chiaramente identificata, l’attribuzione delle responsabilità è più semplice. In una pubblica permissionless i nodi possono avere ruoli diversi. A volte non decidono finalità e mezzi del trattamento, altre volte esercitano un’influenza decisiva e diventano titolari o contitolari (art. 26 GDPR).

Quando i nodi decidono di fatto come gruppo, per esempio sulle modifiche al protocollo, l’EDPB incoraggia con forza a costituire un consorzio o un altro ente. Quell’ente, se esiste, è titolare del trattamento.

3. Il percorso decisionale in quattro domande

Le Linee guida chiedono di rispondere a quattro domande prima di scegliere una soluzione blockchain, e raccomandano di documentare le risposte.

1. I dati sulla blockchain conterranno dati personali? 2. Se sì, perché la blockchain è necessaria per questo trattamento? 3. Quale tipo di blockchain va usato? 4. Quali misure tecniche e organizzative si adottano?

3.1 Ci saranno dati personali?

Vanno considerati sia i metadati delle transazioni, come chiavi pubbliche e identificatori, sia il contenuto della transazione. Anche una chiave pubblica è un dato personale se può essere collegata a una persona fisica con mezzi ragionevolmente utilizzabili (art. 4, punto 1, e considerando 26 GDPR).

3.2 Perché proprio la blockchain?

Se ci sono dati personali, la scelta della blockchain va giustificata rispetto ad altre tecnologie. La giustificazione deve essere documentata e mostrare che le alternative meno invasive sono state valutate. Se non serve la forte garanzia di integrità che la blockchain offre, l’EDPB invita a usare altri strumenti.

3.3 Quale tipo di blockchain

L’EDPB preferisce le blockchain permissioned, perché consentono una ripartizione più chiara delle responsabilità, elemento chiave per la tutela degli interessati. Scegliere una blockchain pubblica permissionless richiede una giustificazione documentata. Va valutata anche un’architettura “zero-knowledge”, che usa tecniche crittografiche per nascondere gli identificatori a chi non partecipa alla transazione.

3.4 Quali misure: on-chain o off-chain

È il passaggio più operativo. La regola generale è non scrivere dati personali direttamente sulla blockchain, salvo gli identificatori strettamente necessari. La soluzione preferita è conservarli fuori dalla catena (off-chain), perché rende possibili rettifica e cancellazione. Sulla catena si registra, se serve, solo la prova dell’esistenza del dato.

Quando la conservazione sulla catena è inevitabile, le tecniche sono tre.

• Cifratura – rende il dato leggibile solo a chi ha la chiave. Il dato cifrato resta però un dato personale, e la cifratura di oggi può non bastare tra qualche anno.
• Hash con chiave o salt – sulla catena va solo l’impronta del dato, mentre dato e salt restano fuori. L’hash resta un dato personale. Cancellare il salt lo rende inservibile solo se l’algoritmo regge, le chiavi non sono compromesse e il salt non è trapelato o scelto male.
• Commitment crittografico – sulla catena va solo l’impegno crittografico, con dato e witness conservati fuori. Se lo schema usato è “perfectly hiding”, una volta cancellati dato e witness il commitment rimasto sulla catena non permette più di risalire al dato.

Scrivere dati personali in chiaro sulla catena può confliggere con diversi principi dell’art. 5 GDPR, e l’EDPB lo sconsiglia fortemente.

3.5 Conservazione e cancellazione

Il fatto che la blockchain non si possa modificare non autorizza a conservare i dati per tutta la sua vita. Il periodo di conservazione si fissa in base alla finalità (art. 5, paragrafo 1, lettera e), GDPR), e va sostenuto da una soluzione tecnica che garantisca la cancellazione o l’anonimizzazione alla scadenza.

Se il periodo di conservazione è più breve della vita della blockchain e nessuna soluzione tecnica garantisce la cancellazione, i dati personali non vanno scritti sulla catena. C’è poi il caso opposto. Alcune informazioni devono restare pubbliche e accessibili per tutta la vita della blockchain. Solo in questi casi l’EDPB ammette dati personali in forma direttamente identificabile su una blockchain pubblica, se la finalità lo giustifica e una valutazione d’impatto ha concluso che i rischi sono stati mitigati. Anche quella durata va giustificata come necessaria e proporzionata, e documentata.

Altre norme possono poi imporre termini di conservazione propri. Per i prestatori di servizi per le cripto-attività, per esempio, il regolamento MiCAR (Regolamento UE 2023/1114) impone di conservare le registrazioni dei servizi prestati per cinque anni, prorogabili fino a sette su richiesta dell’autorità (art. 68, paragrafo 9).

3.6 Checklist di progetto

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

• documentare perché la blockchain è necessaria e quali alternative sono state valutate;
• scegliere il tipo di blockchain, preferibilmente permissioned, e motivare la scelta;
• mappare quali dati andranno sulla catena e quali fuori;
• scegliere le tecniche di protezione in base ai rischi;
• definire ruoli e responsabilità tra tutti i soggetti (artt. 24, 26 e 28 GDPR);
• fissare il periodo di conservazione e la procedura di cancellazione o anonimizzazione;
• predisporre le procedure per accesso, rettifica e cancellazione;
• valutare se serve una DPIA;
• verificare i trasferimenti verso paesi fuori dallo Spazio economico europeo;
• preparare un piano per le vulnerabilità crittografiche e gli incidenti di sicurezza.

4. Gli errori più comuni

• Considerare l’impossibilità tecnica una giustificazione – l’EDPB lo esclude. La difficoltà di cancellare un blocco non autorizza a non rispettare il diritto alla cancellazione (art. 17 GDPR). Il progetto deve prevedere il problema fin dall’inizio.
• Scrivere dati in chiaro “tanto è sulla blockchain” – firma digitale e hash dei blocchi garantiscono l’integrità, non la riservatezza. Chi ha accesso alla catena legge il dato.
• Trattare la vita della blockchain come periodo di conservazione – la persistenza tecnica non rende lecita la conservazione.
• Trascurare i trasferimenti internazionali – nelle blockchain pubbliche i nodi sono spesso fuori dallo Spazio economico europeo, e i trasferimenti devono rispettare il Capo V del GDPR.
• Dimenticare la DPIA – è obbligatoria quando il trattamento può presentare un rischio elevato (art. 35 GDPR).
• Usare il consenso senza poter cancellare – se l’architettura non consente di cancellare i dati quando il consenso viene revocato, il consenso non va usato come base giuridica (raccomandazione 9 dell’allegato A).

4.1 La DPIA

L’EDPB non dice che la DPIA sia sempre obbligatoria. Rinvia ai criteri del Gruppo di lavoro articolo 29, per cui di norma serve una valutazione d’impatto quando ricorrono almeno due criteri di rischio. Nei progetti blockchain, secondo lo Studio, uno è quasi sempre presente, cioè l’uso di una tecnologia innovativa. Basta che se ne aggiunga un secondo, come il trattamento su larga scala, il monitoraggio sistematico o le decisioni automatizzate con effetti significativi, perché la DPIA diventi di norma necessaria.

4.2 I trasferimenti, una questione aperta

Se la replica del registro su nodi fuori dallo Spazio economico europeo sia sempre un trasferimento, e chi ne sia l’esportatore quando il nodo non lo sceglie nessuno, è, per lo Studio, una questione da valutare caso per caso, che le Linee guida non affrontano. L’EDPB propone, come esempio, di inserire le clausole contrattuali tipo nel contratto che un nodo firma per essere ammesso. È una soluzione praticabile in una blockchain permissioned, molto meno in una pubblica permissionless, dove quel contratto di solito non esiste.

5. Sanzioni e rischi

Le violazioni dei principi dell’art. 5 e dei diritti degli interessati possono costare fino a 20.000.000 euro o al 4% del fatturato mondiale annuo, se superiore (art. 83, paragrafo 5, GDPR). Le violazioni della protezione dei dati fin dalla progettazione e dell’obbligo di DPIA, che sono il cuore dei progetti blockchain, rientrano nella fascia fino a 10.000.000 euro o al 2% (art. 83, paragrafo 4).

Il rischio vero va oltre la sanzione. Un difetto strutturale può rendere necessario dismettere o ricostruire l’intera infrastruttura, e l’EDPB avverte che, se la cancellazione non è stata prevista fin dalla progettazione, può essere necessario cancellare l’intera blockchain. Una scelta sbagliata all’inizio è molto difficile da correggere a sistema avviato.

Si aggiungono i rischi indiretti. Contenziosi con utenti che non riescono a esercitare i propri diritti, contestazioni dei partner, operazioni di finanziamento o acquisizione bloccate in due diligence, ostacoli alle certificazioni.

Nelle blockchain pubbliche permissionless c’è infine un rischio specifico. La qualifica di contitolare può ricadere su soggetti che non l’avevano messa in conto, con tutti gli obblighi di trasparenza, registro dei trattamenti e gestione delle richieste che ne derivano.

Conclusioni

Le Linee guida EDPB non vietano la blockchain con dati personali. Chiedono di dimostrare, prima di sceglierla, che serve davvero e che l’architettura consente di rispettare il GDPR.

La strada più sicura è quasi sempre la stessa. Dati personali fuori dalla catena, sulla catena solo prove di esistenza, blockchain permissioned quando possibile e una DPIA che documenti le scelte. Con la versione definitiva del luglio 2026 questo impianto è diventato stabile.

Per lo Studio la domanda da porsi all’inizio è sempre una sola. Se il diritto alla cancellazione non si può garantire fin dalla progettazione, la blockchain non è la tecnologia giusta per quel trattamento.

Punti chiave

Fonti e risorse utili