Quando un Hash È un Dato Personale? La Sentenza SRB della CGUE e l'Identità in Analytics

La domanda che ogni fornitore di analytics evita è facile da porre e difficile da risolvere: l'identificatore nel tuo database è un dato personale? Il 4 settembre 2025 la CGUE ha dato la risposta più rilevante da anni, riformulando l'intero test attorno al contesto anziché al dato isolato.

Cosa ha deciso davvero EDPS contro SRB

Il caso — EDPS contro SRB, C-413/23 P — è nato dalla risoluzione del Banco Popular. Il Single Resolution Board ha raccolto i commenti degli azionisti, sostituito l'identità di ogni autore con un codice alfanumerico e trasmesso i commenti codificati a Deloitte come valutatore indipendente. Deloitte non aveva chiavi per invertire i codici né altra via verso gli autori.

La CGUE ha stabilito che i dati pseudonimizzati non sono automaticamente dati personali per ogni parte che li tratta. Se un insieme di dati è personale si valuta rispetto a chi lo detiene — dalla posizione del destinatario specifico, considerando i mezzi tecnici, organizzativi e giuridici realisticamente disponibili a lui.

Questo è il test dell'identificabilità relativa (o contestuale), ed è la lettura operativa dei "mezzi che ragionevolmente possono essere utilizzati" del Considerando 26. Un dato personale nelle mani del titolare può essere non personale nelle mani di un destinatario che davvero non può reidentificare nessuno.

La tensione con l'EDPB

La corte non ha concesso un lasciapassare ai fornitori. Le Linee guida 01/2025 dell'EDPB sulla pseudonimizzazione adottano una linea deliberatamente più rigida: i dati pseudonimizzati restano dati personali finché chiunque — il titolare o un terzo — conserva i mezzi per reidentificare. La relazione dell'EDPB del febbraio 2026 su anonimizzazione e pseudonimizzazione è il comitato che lavora esattamente su questa distanza tra la sua posizione e quella della corte.

Per chi sviluppa, la lettura pratica è prudente. Non dare per scontato che un valore con hash sia fuori dall'ambito del GDPR solo perché il tuo servizio non può invertirlo. La domanda giusta è se la reidentificazione sia ragionevolmente probabile per chiunque detenga l'informazione aggiuntiva — e se questa informazione aggiuntiva esista ancora.

Perché la maggior parte degli hash di analytics non supera il test

Applicare un hash a un identificatore non è anonimizzazione. Un SHA-256 di un indirizzo email è deterministico: la stessa email produce sempre lo stesso digest. Chi ha una lista di email candidate può applicarvi l'hash e confrontarle. L'hash è una chiave stabile e collegabile — pseudonimizzazione nel migliore dei casi, e dato personale sotto entrambe le letture, perché i mezzi per reidentificare sono banalmente disponibili.

La stessa trappola coglie un IP con hash, un ID dispositivo con hash o qualunque digest di un input tratto da uno spazio piccolo ed enumerabile. Determinismo più input indovinabile uguale reidentificazione. La funzione di hash cambia i byte, non la collegabilità.

Cosa rende un hash davvero difendibile

Due proprietà spostano un hash da "dato personale pseudonimizzato" verso "non ragionevolmente reidentificabile": un salt segreto mai memorizzato accanto al dato, e un input che non può essere indovinato in modo esaustivo e non persiste nel tempo. Il modello di identità di Monoid è costruito esattamente su questo:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

L'IP e lo User-Agent grezzi vivono solo nella memoria del Worker il tempo necessario a calcolare il digest; D1 memorizza l'hash, mai gli input. Il SALT_SECRET è custodito lato server e mai scritto accanto al dato, così un attacco rainbow table o di forza bruta contro gli hash memorizzati non ha alcun ancoraggio. E poiché la data è un input, il digest dello stesso visitatore ruota a ogni mezzanotte UTC. Non esiste una chiave stabile tra giorni con cui correlare.

Passa questa costruzione attraverso entrambi i test. Secondo lo standard relativo della CGUE, nessun destinatario degli hash memorizzati — incluso Monoid che interroga la propria D1 — detiene i mezzi ragionevolmente idonei a reidentificare, perché il salt è segregato e l'input non è enumerabile. Secondo lo standard più rigido del "chiunque" dell'EDPB, l'informazione aggiuntiva necessaria (IP grezzo più UA più il salt segreto di quella data specifica) non è conservata da nessuna parte una volta completata la richiesta. I mezzi per reidentificare non sono solo limitati: cessano di esistere.

Come verificare il tuo stack

La sentenza fornisce una checklist concreta da applicare a qualsiasi analytics su cui fai affidamento:

• L'input con hash è enumerabile? Un'email, un numero di telefono o un IP grezzo possono essere sottoposti a hash e confrontati con una lista di candidati. Se lo spazio di input è piccolo, l'hash è reversibile in pratica.
• C'è un salt segreto separato dal dato memorizzato? Un hash senza salt, o con il salt nello stesso archivio, non offre alcuna barriera reale alla reidentificazione.
• L'identificatore persiste tra le sessioni? Una chiave stabile che collega l'attività di una persona per settimane è dato personale sotto ogni lettura. Una chiave che ruota ogni giorno non può accumulare un profilo.

La CGUE non ha dichiarato la pseudonimizzazione un porto sicuro, e l'EDPB sta facendo in modo che nessuno la legga così. La posizione durevole è quella che non ha bisogno di alcuna interpretazione per vincere: un hash con salt, a rotazione giornaliera, su un input non enumerabile non è ragionevolmente reidentificabile da nessuno, perché il materiale necessario per invertirlo non è mai stato conservato.

Fonti

• Sentenza della CGUE nella causa C-413/23 P, GEPD contro SRB (4 settembre 2025)
• Linee guida 01/2025 dell'EDPB sulla pseudonimizzazione
• Relazione dell'EDPB sull'evento con le parti interessate su anonimizzazione e pseudonimizzazione del 12 dicembre 2025
• Considerando 26 del GDPR — Non applicabile ai dati anonimi