I trasferimenti di dati GDPR sono l'unico rischio di compliance che puoi eliminare con l'architettura

La maggior parte dei rischi GDPR è procedurale: un'informativa che puoi riscrivere, un periodo di conservazione che puoi accorciare, un flusso di consenso che puoi correggere. I trasferimenti internazionali di dati sono diversi. Dipendono da uno strumento giuridico che non controlli e che non puoi correggere, e quello strumento è stato annullato due volte in un decennio. L'unica soluzione duratura è architetturale: non trasferire mai i dati, in primo luogo.

Il meccanismo di trasferimento continua a crollare

Il Capo V del GDPR vieta l'invio di dati personali verso un paese privo di un livello di protezione adeguato, salvo che si disponga di un meccanismo di trasferimento valido. Per i flussi UE-USA, quel meccanismo ha il suo cimitero. La CGUE ha invalidato il Safe Harbour nel 2015 (Schrems I) e il Privacy Shield nel 2020 (Schrems II), in entrambi i casi perché il diritto statunitense sulla sorveglianza non offriva ai cittadini europei alcun rimedio effettivo.

Lo strumento attuale è l'EU-US Data Privacy Framework (DPF), adottato nel 2023. Il 3 settembre 2025 il Tribunale dell'Unione europea ha respinto il primo ricorso presentato contro di esso, nella causa Latombe v Commission (causa T-553/23), confermando la decisione di adeguatezza della Commissione.

Non è la fine della storia. Latombe ha proposto impugnazione davanti alla Corte di giustizia il 31 ottobre 2025, e noyb — l'organizzazione di Max Schrems — ha fatto sapere di stare preparando un ricorso più ampio contro il DPF sulle stesse basi legate alla sorveglianza che hanno affondato i due quadri precedenti. La corte che ha demolito il Safe Harbour e il Privacy Shield avrà un'altra occasione per esaminarlo.

Perché questo riguarda specificamente l'analytics

L'analytics è il modo più comune con cui un piccolo sito europeo finisce per effettuare un trasferimento verso gli Stati Uniti senza rendersene conto. Il browser invia un evento; un fornitore di analytics con sede negli Stati Uniti riceve l'indirizzo IP del visitatore e i dati comportamentali su infrastruttura statunitense. Questo è un trasferimento di dati personali, e ne eredita lo stato giuridico che il DPF ha in un dato giorno.

I regolatori lo trattavano già come illecito prima che il DPF esistesse. A seguito dei reclami coordinati di noyb, la DSB austriaca ha stabilito nel 2022 che i trasferimenti UE-USA tramite Google Analytics violavano il Capo V, e le autorità di protezione dei dati di Francia, Italia, Danimarca, Finlandia, Svezia e Norvegia hanno seguito con lo stesso ragionamento. L'indirizzo IP che raggiungeva i server statunitensi era sufficiente.

Se la CGUE invalida il DPF, quelle decisioni tornano a essere il modello, da un giorno all'altro, per ogni strumento che continua a instradare i dati dei visitatori europei verso gli Stati Uniti.

Eliminare il rischio con l'architettura

Non puoi rendere il DPF più stabile. Puoi costruire un flusso di dati che, sin dall'inizio, non ha alcuna esposizione al Capo V. Due proprietà bastano a ottenerlo:

Elaborare all'edge, in-region. La Data Localization Suite di Cloudflare permette a un Worker di confinare l'elaborazione e i log nei data center europei, così che la richiesta non lasci mai la regione in cui è stata originata. La decisione su dove vengono trattati i dati diventa configurazione dell'infrastruttura, non uno strumento giuridico che speri sopravviva all'appello.

Non conservare mai gli input identificativi. L'IP e lo User-Agent grezzi che rendono una richiesta un «dato personale» esistono in memoria solo il tempo necessario a calcolare un hash giornaliero del visitatore, poi vengono scartati:

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

Ciò che viene memorizzato è l'hash, non gli input. Poiché il salt ruota ogni giorno ed è segreto, l'hash non può essere invertito per risalire a un individuo né collegato tra un giorno e l'altro. Non c'è alcun profilo, e nulla di identificativo attraversa mai un confine perché nulla di identificativo viene mai conservato.

Puoi verificare la geografia del flusso direttamente sul filo. Un beacon di pageview è una singola richiesta verso un endpoint di prima parte che controlli:

POST /collect HTTP/2
Host: api.monoid.website
Content-Type: application/json

{"site_id":"...","path":"/pricing","referrer":"..."}

Se api.monoid.website risolve verso nodi edge europei e il Worker vincola il suo storage all'UE, non c'è alcun responsabile del trattamento statunitense nel percorso, nessuna decisione di adeguatezza su cui fare affidamento e nessun trasferimento da dichiarare. Il paese del visitatore continua comunque ad arrivare — derivato dalla geolocalizzazione dell'edge stesso, non dall'invio dell'IP a un terzo.

La postura di compliance che ne deriva

Un trasferimento che non effettui mai è un trasferimento che non devi mai difendere. Non c'è alcun DPF da citare nel tuo registro dei trattamenti, nessuna clausola contrattuale tipo da mantenere, nessuna valutazione d'impatto sul trasferimento da rifare quando cambia il fondamento giuridico, e nessun sub-responsabile in un paese terzo da dichiarare ai sensi delle regole di trasparenza che i regolatori stanno verificando nel 2026.

Ogni altra attività di compliance dell'analytics è qualcosa che continui a fare. Eliminare il trasferimento è qualcosa che fai una volta, nell'architettura, e poi smetti di pensarci — indipendentemente da come la CGUE deciderà sull'appello.

Fonti

• Corte di giustizia dell'UE — Comunicato stampa: il Tribunale respinge il ricorso Latombe (causa T-553/23)
• IAPP — Il Tribunale dell'UE respinge il ricorso Latombe e conferma l'EU-US Data Privacy Framework
• noyb — DSB austriaca: i trasferimenti di dati UE-USA verso Google Analytics sono illegali
• noyb — Altre autorità di protezione dei dati dell'UE ordinano lo stop a Google Analytics
• Cloudflare — Data Localization Suite