Schrems II e i pixel di tracciamento: dove il DPF ti lascia nel 2026

Nel luglio 2020 la CGUE ha emesso la sentenza Schrems II (C-311/18). Il Privacy Shield, che era stato il meccanismo predefinito per i trasferimenti di dati UE-USA dal 2016, è stato invalidato. Da un giorno all'altro, ogni team di marketing che gestiva un Meta Pixel o un Google Tag stava trasferendo dati senza un meccanismo legale valido, si affannava a eseguire le Clausole Contrattuali Standard o si affidava all'interpretazione ottimistica che il GDPR non raggiungesse uno snippet JavaScript nel browser di un utente.

Seguirono tre anni di linee guida sulle misure supplementari, template di Transfer Impact Assessment e azioni di enforcement delle autorità di vigilanza. Poi, nel luglio 2023, la Commissione europea ha adottato la decisione di adeguatezza del Data Privacy Framework UE-USA, ripristinando l'adeguatezza per le aziende statunitensi certificate DPF. Meta, Google, Salesforce e HubSpot sono tutte nell'elenco.

La domanda per i team di marketing e compliance nel 2026 non è "esiste il DPF" - esiste. La domanda è cosa copre effettivamente, dove si trova il rischio residuo e come appare in pratica un'architettura di trasferimento che regge di fronte a una potenziale contestazione del DPF.

TL;DR#

• Il Privacy Shield (2016) è stato invalidato da Schrems II nel luglio 2020. Le SCC più le misure supplementari hanno coperto il gap dal 2020 al 2023.
• Il Data Privacy Framework UE-USA (luglio 2023) è l'attuale decisione di adeguatezza. I trasferimenti delle aziende certificate DPF beneficiano dell'adeguatezza senza richiedere SCC o TIA.
• I pixel client-side verso i fornitori certificati DPF sono giuridicamente difendibili nel 2026, a condizione che l'entità destinataria sia certificata, l'interessato sia stato informato e il consenso ePrivacy sia in atto ove richiesto.
• Il DPF è oggetto di una sfida legale anticipata. Il tracciamento in doppia modalità - client-side sotto la copertura DPF, inoltro server-side dall'infrastruttura UE come fallback strutturale - è l'architettura che sopravvive a una terza sentenza Schrems.

Cosa ha effettivamente detto Schrems II#

Vale la pena leggere la sentenza direttamente piuttosto che tramite un riassunto. Il ragionamento operativo si trova nei paragrafi 180–202. La conclusione centrale non è che i trasferimenti di dati negli USA siano per se illegali. È che il diritto di sorveglianza statunitense - specificamente FISA 702 e Executive Order 12333 - conferisce alle agenzie di intelligence statunitensi l'accesso ai dati personali dei soggetti dell'UE in un modo che non prevede alcun rimedio efficace per tali soggetti ai sensi degli articoli 77–79 del GDPR.

L'articolo 44 del GDPR vieta i trasferimenti verso paesi terzi a meno che non si applichi uno dei meccanismi del capitolo V. Il Privacy Shield era una decisione di adeguatezza ai sensi dell'articolo 45. La conclusione della Corte che il Privacy Shield fosse invalido ha quindi privato della base di adeguatezza ogni trasferimento che vi faceva affidamento.

Le Clausole Contrattuali Standard non sono state invalidate - ma la Corte ha stabilito nella stessa sentenza che le SCC non sono automaticamente sufficienti per i trasferimenti verso gli USA. Il titolare o responsabile del trattamento che usa le SCC deve verificare, caso per caso, se il sistema giuridico del paese di destinazione impedirebbe ai protocolli di protezione SCC di funzionare in pratica. Questo requisito è la Transfer Impact Assessment: una valutazione documentata del diritto di sorveglianza statunitense e del suo effetto sui dati trasferiti.

Le Raccomandazioni 01/2020 dell'EDPB sulle misure supplementari hanno operazionalizzato questo requisito. Delineano un processo in sei fasi e un catalogo di misure supplementari - tecniche (crittografia, pseudonimizzazione), contrattuali e organizzative - che i titolari dovrebbero valutare quando si affidano alle SCC per i trasferimenti negli USA. Per i pixel di marketing standard, la maggior parte di quelle misure tecniche era praticamente impossibile: non puoi crittografare in modo significativo un payload il cui scopo è consentire a Meta di attribuire una conversione a un'impression pubblicitaria.

Questa è l'architettura con cui i team di marketing hanno vissuto dal luglio 2020 al luglio 2023. Le SCC sono state firmate. Le TIA sono state tentate. I DPA in Austria, Francia e Italia hanno ritenuto implementazioni specifiche - Google Analytics in primis - non conformi nonostante le SCC, perché le misure supplementari erano insufficienti.

Cosa è cambiato con il Data Privacy Framework#

Il Data Privacy Framework UE-USA (Decisione della Commissione (UE) 2023/1795, in vigore dal 10 luglio 2023) è una decisione di adeguatezza ai sensi dell'articolo 45 del GDPR. La sua premessa legale è che il quadro giuridico statunitense - come modificato dall'Executive Order 14086 del Presidente Biden e dalle successive norme che istituiscono il Data Protection Review Court - fornisce un livello di protezione essenzialmente equivalente a quello garantito nell'UE.

Per fini pratici, il DPF significa questo: i trasferimenti verso aziende statunitensi certificate DPF beneficiano dell'adeguatezza. Non hai bisogno di SCC. Non hai bisogno di una TIA. Devi verificare che l'entità destinataria figuri nell'elenco dei partecipanti DPF, che è consultabile pubblicamente e aggiornato in quasi tempo reale.

Meta Platforms, Inc. è certificata DPF. Google LLC è certificata DPF. Salesforce, Inc. è certificata DPF. HubSpot, Inc. è certificata DPF. Per questi fornitori, i trasferimenti di dati personali dell'UE in relazione alla pubblicità e all'analytics sono coperti dall'adeguatezza a partire dal luglio 2023, a condizione che ricevano i dati nella loro veste certificata DPF.

Sono importanti due precisazioni. Prima, la certificazione DPF è volontaria. Non tutte le aziende statunitensi che trattano dati dell'UE si sono auto-certificate. L'elenco dei partecipanti è la fonte autorevole; non dare per scontata la certificazione. Seconda, la certificazione DPF copre attività specifiche. Un'azienda certificata DPF può trattare i tuoi dati pixel nell'ambito certificato o in base a un'altra base giuridica a seconda del tipo di dati e della finalità. Per la normale attribuzione di marketing tramite pixel, l'ambito DPF la copre.

Cosa significa per i pixel di marketing in pratica#

Con la copertura DPF in vigore, la postura legale per i pixel di marketing client-side verso i fornitori certificati appare così.

Il Meta Pixel client-side, quando invia dati a Meta Platforms Inc. (certificata DPF), è un trasferimento verso una destinazione adeguata. Il meccanismo di trasferimento è la decisione di adeguatezza DPF, non le SCC. La tua voce nel Registro delle Attività di Trattamento (RoPA) ai sensi dell'articolo 30 per il Meta Pixel documenta la base del trasferimento come "decisione di adeguatezza (DPF)" piuttosto che "SCC". La TIA che sarebbe stata necessaria nel percorso SCC non è richiesta.

La stessa analisi si applica a Google Tag Manager e GA4 che inviano dati a Google LLC, al pixel di tracciamento di HubSpot che invia dati a HubSpot Inc. e agli eventi di attribuzione di Salesforce Marketing Cloud che inviano dati a Salesforce Inc.

Tuttavia, l'adeguatezza è uno strato di un quadro di conformità a più livelli. Devono essere in atto tre ulteriori requisiti prima che questa postura regga.

Consenso ePrivacy. La Direttiva ePrivacy 2002/58/CE, articolo 5(3), richiede il consenso prima di qualsiasi archiviazione o accesso non essenziale sull'apparecchio terminale dell'utente. I pixel di marketing non sono essenziali. I banner di consenso devono essere specifici per il pixel in questione, liberamente concessi e revocabili. Il fatto che la destinazione del trasferimento sia adeguata ai sensi del DPF non modifica il requisito di consenso ePrivacy. Si tratta di strumenti giuridici separati.

Trasparenza verso gli interessati. L'articolo 13 del GDPR richiede che il titolare del trattamento informi gli interessati, al momento della raccolta, sui destinatari dei loro dati e su eventuali trasferimenti verso paesi terzi. Il DPF non modifica quest'obbligo di trasparenza. Se la tua informativa sulla privacy dice "utilizziamo Meta Pixel" e "i trasferimenti verso gli USA sono coperti dall'adeguatezza", ciò è sufficiente. Se non menziona affatto il trasferimento negli USA, la decisione di adeguatezza non sana il gap dell'articolo 13.

DPA ai sensi dell'articolo 28 con il fornitore. Il fornitore del pixel rimane un responsabile del trattamento ai sensi dell'articolo 28 del GDPR. Il DPF copre il meccanismo di trasferimento; non sostituisce il DPA. I termini standard per il trattamento dei dati di Meta, Google e HubSpot sono gli strumenti ai sensi dell'articolo 28 per la relazione con il pixel. Assicurati che siano stati sottoscritti.

I rischi residui#

Il DPF non è un accordo definitivo. È una decisione di adeguatezza che può essere contestata davanti alla CGUE da qualsiasi tribunale di uno Stato membro, dal Parlamento europeo o da qualsiasi autorità di vigilanza nazionale. Max Schrems e NOYB hanno segnalato pubblicamente l'intenzione di contestare il DPF - un potenziale Schrems III. La teoria giuridica di questa contestazione è simile a quella di Schrems II: che l'EO 14086 e il Data Protection Review Court non forniscano, nella sostanza, rimedi equivalenti a quelli disponibili ai sensi del diritto dell'UE.

Le autorità di vigilanza non hanno atteso una sentenza della CGUE. Il DSB austriaco ha emesso una decisione su un'implementazione di Google Analytics ancora nel 2022 - prima che il DPF fosse in vigore - concludendo che il trasferimento era illegittimo perché le SCC e le misure supplementari in atto erano insufficienti. La CNIL francese e il Garante italiano hanno emesso conclusioni simili. Queste decisioni erano sotto il regime pre-DPF, ma stabiliscono un pattern di supervisione: i DPA sono disposti a esaminare le meccaniche tecniche dei trasferimenti basati su pixel, non solo la documentazione contrattuale. Una futura decisione nell'ambito di una contestazione post-DPF esaminerebbe probabilmente se l'ordine giuridico stabilito dall'EO 14086 limiti genuinamente l'accesso FISA 702 ai dati archiviati delle aziende certificate.

La preoccupazione specifica riguardo ai pixel di tracciamento va oltre il meccanismo legale. Un pixel client-side fa più che trasferire dati a un'azienda certificata. Esegue JavaScript nel browser dell'utente, imposta cookie di prima e terza parte nel contesto del dominio del pixel e invia i dati direttamente dal browser. I dati che lasciano il browser sono fuori dal tuo controllo - non puoi applicare l'hashing degli identificatori prima che partano, non puoi limitare quali campi vengono popolati e non puoi verificare cosa invia effettivamente il pixel in fase di esecuzione senza un'ispezione di rete. L'adeguatezza DPF copre la destinazione; non riguarda ciò che il pixel raccoglie prima del trasferimento.

Questa combinazione - potenziale contestazione legale del DPF, scrutinio delle autorità di vigilanza sulle meccaniche piuttosto che solo sulla documentazione, e limiti strutturali su ciò che un titolare può verificare riguardo al comportamento del pixel client-side - è il motivo per cui una strategia client-side esclusiva rimane architetturalmente fragile.

La postura pratica: tracciamento in doppia modalità#

L'architettura che regge sia sotto il DPF che in caso di una potenziale invalidazione del DPF è quella in doppia modalità.

La prima modalità è costituita dai pixel client-side verso i fornitori certificati DPF, che operano nell'ambito dell'adeguatezza attuale con il consenso ePrivacy in atto. Questa fornisce il segnale di attribuzione più ampio finché il DPF regge. Per la maggior parte dei team di marketing, questa è la modalità che riempie i tuoi dashboard di attribuzione oggi.

La seconda modalità è l'inoltro delle conversioni server-side dall'infrastruttura UE. Quando un utente clicca un link, l'edge in regione UE di Elido riceve il clic, lo registra nell'infrastruttura di analisi UE e inoltra il segnale di conversione server-to-server all'API di conversione della piattaforma pubblicitaria - Meta CAPI, GA4 Measurement Protocol o equivalente. Il browser dell'utente non contatta l'endpoint statunitense. I dati che lasciano l'infrastruttura UE sono stati sottoposti a hashing (SHA-256 su indirizzi email e numeri di telefono, come richiede Meta CAPI), e il trasferimento ha origine dall'infrastruttura sotto il tuo controllo piuttosto che dal codice in esecuzione nel browser dell'utente.

Se il DPF viene invalidato, il pixel client-side diventa un meccanismo di trasferimento non conforme finché non è in vigore un framework sostitutivo. Il percorso server-side, che opera tramite SCC con misure supplementari applicate - crittografato in transito, identificatori sottoposti a hashing prima della partenza, con scope ristretto al segnale di attribuzione - è il fallback che il tuo team legale può difendere con una TIA coerente. Poiché il percorso server-side elabora prima i dati nell'infrastruttura UE, il trasferimento può essere documentato come controller-to-processor piuttosto che come trasferimento diretto browser-to-US-endpoint.

Dove disponibile, preferisci l'endpoint UE del fornitore. GA4 con data_collection_endpoint impostato su region1.google-analytics.com mantiene più elaborazione nell'infrastruttura UE di Google, anche se parte dell'elaborazione avviene ancora nell'infrastruttura statunitense secondo la documentazione di Google stessa. Meta CAPI attualmente non offre un endpoint in regione UE; il trasferimento server-to-server è comunque diretto agli USA indipendentemente. La misura supplementare è l'hashing degli identificatori, non la geografia dell'endpoint.

Per le meccaniche complete del percorso di inoltro server-side e come si integra con l'attribuzione dei clic sui link abbreviati, cookieless attribution explained copre l'architettura tecnica. Per il quadro più ampio della residenza UE - dove inizia e finisce "ospitato nell'UE" in uno stack di strumenti di marketing - EU data residency for marketing è il post complementare.

Consenso dei sub-incaricati nel contesto del DPF#

Ogni fornitore di pixel certificato DPF è comunque un responsabile del trattamento ai sensi dell'articolo 28 del GDPR. La decisione di adeguatezza DPF copre il meccanismo di trasferimento; non dice nulla degli obblighi di responsabile del trattamento che si applicano in parallelo.

Ciò significa che il titolare del trattamento ha bisogno di un Accordo per il Trattamento dei Dati (DPA) con ogni fornitore di pixel, che copra gli obblighi dell'articolo 28(3)(a)-(h). I termini standard per la pubblicità di Meta, l'addendum per il trattamento dei dati di Google e il DPA di HubSpot sono gli strumenti qui. Sono pre-firmati e incorporati per riferimento quando si accettano i termini di servizio del fornitore; la domanda è se hai documentato tale accordo nei tuoi archivi di conformità.

L'elenco dei sub-incaricati su cui il tuo DPO chiederà informazioni copre questi fornitori. Ogni fornitore di pixel diventa un sub-incaricato nella catena di attribuzione tra la tua piattaforma di tracciamento dei link e la piattaforma pubblicitaria. L'elenco pubblico dei sub-incaricati di Elido nomina i suoi cinque fornitori; i fornitori di pixel sono sub-incaricati a livello di titolare del trattamento, non a livello di Elido. Il tuo RoPA ai sensi dell'articolo 30 dovrebbe enumerarli separatamente.

Una sfumatura: l'articolo 28(2) del GDPR richiede che il responsabile del trattamento ottenga l'autorizzazione del titolare prima di coinvolgere sub-incaricati. Per la relazione con il pixel, sei tu il titolare che coinvolge direttamente Meta o Google - si tratta di una relazione titolare-responsabile del trattamento, non di una relazione sub-incaricato in catena attraverso Elido. Il DPA ai sensi dell'articolo 28 è tra te e il fornitore del pixel. Il tratto di inoltro server-side - dove l'edge di Elido inoltro gli eventi a Meta CAPI per tuo conto - è una relazione di sub-incaricato: Elido è il responsabile del trattamento, Meta CAPI è il sub-incaricato, e l'obbligo DPA scorre attraverso il DPA standard di Elido.

Questa distinzione è importante per il tuo RoPA. Un team di compliance che esamina i tuoi archivi vuole vedere due voci separate: una per la relazione con il responsabile del trattamento Elido (che copre gli eventi di clic a livello di link) e una per ogni relazione con il fornitore del pixel (che copre i dati di attribuzione lato browser). Confonderle produce una voce del RoPA imprecisa in entrambe le direzioni.

Per gli obblighi di responsabile del trattamento GDPR a livello di articolo nella loro interezza, GDPR for URL shorteners è il post fondamentale di questo cluster.

La checklist del DPO per la valutazione dei fornitori di pixel#

Cinque domande da porre a ogni fornitore di pixel di tracciamento durante la valutazione. Queste sono scritte per una revisione dell'era DPF; adatta la domanda sul meccanismo di trasferimento se lo stato del DPF è cambiato nel momento in cui le leggi.

1. La tua azienda è attualmente elencata nell'elenco dei partecipanti DPF e quali attività copre la tua certificazione?

L'elenco si trova su dataprivacyframework.gov. Chiedi l'ambito specifico della certificazione, non un generico "sì, siamo certificati". La certificazione è limitata all'ambito di attività; un fornitore potrebbe essere certificato DPF per i dati delle risorse umane ma non per i dati di attribuzione dei clic commerciali.

2. Dove vengono effettivamente archiviati i dati che invio tramite il pixel e c'è un endpoint in regione UE che posso usare?

Il DPF copre il trasferimento verso un destinatario statunitense certificato. Se è disponibile un endpoint in regione UE, il suo utilizzo riduce l'esposizione al trasferimento e potrebbe influire sull'analisi TIA se il DPF venisse successivamente contestato. Documenta la risposta nella tua voce del RoPA.

3. Qual è il tuo Accordo per il Trattamento dei Dati standard e copre esplicitamente gli obblighi dell'articolo 28(3)(a)-(h)?

I DPA pre-firmati che sono incorporati per riferimento nei termini di servizio vanno bene; devi sapere che il DPA esiste e dove trovarlo. Il DPA regola la relazione con il responsabile del trattamento indipendentemente dal meccanismo di trasferimento.

4. Come gestite le richieste di esercizio dei diritti degli interessati - in particolare la cancellazione ai sensi dell'articolo 17 - per i dati raccolti tramite pixel?

Per i pixel client-side, la cancellazione viene in genere gestita tramite i controlli sulla privacy della piattaforma (Privacy Centre di Meta, My Ad Centre di Google). Documenta il processo in modo da poter rispondere a una richiesta di un interessato senza improvvisare.

5. Se il DPF viene invalidato, quale meccanismo di trasferimento alternativo offrirete e in quali tempi?

Questa domanda verifica se il fornitore ha un piano di contingenza. Durante la transizione da Privacy Shield a SCC (2020–2021), alcuni fornitori erano lenti nell'aggiornare i propri accordi. Un fornitore che ha già documentato le SCC come fallback in caso di invalidazione del DPF - con le misure supplementari specificate - ha già svolto questo lavoro. Un fornitore che dice "aggiorneremo il nostro DPA quando necessario" non lo ha fatto.

Per l'implementazione specifica di Elido: l'inoltro delle conversioni server-side è disponibile oggi, con hashing SHA-256 degli identificatori prima che qualsiasi dato lasci l'infrastruttura UE. La configurazione è per workspace ed è documentata nel DPA standard su /legal/dpa. Se la tua tolleranza al rischio DPF è bassa, il percorso server-side è disponibile come meccanismo di inoltro primario, non solo come fallback.