Guía de consentimento de cookies do EU-US Data Privacy Framework (DPF) para editores en 2026
O EU-US Data Privacy Framework (DPF) é a estrutura xurídica que permite que os datos persoais europeos — incluíndo identificadores de cookies, enderezos IP, correos electrónicos con hash e cargas útiles de solicitudes de anuncios — flúan cara a provedores con sede nos EUA sen que cada editor teña que negociar as súas propias Cláusulas Contractuais Estándar. Adoptado pola Comisión Europea en xullo de 2023 e xa en uso real desde hai varios anos, o DPF é o terceiro intento de substituír o invalidado Privacy Shield, e está de novo ante un desafío xurídico no Tribunal de Xustiza da Unión Europea. Para os editores que canalizan tráfico da UE a través de SSP, DSP, ferramentas de análise e CMP con sede nos EUA, comprender o DPF — e a capa de consentimento que se sitúa enriba del — xa non é opcional. Esta guía explica o que o DPF autoriza realmente, como encaixa o consentimento de cookies e os pasos operativos que manteñen as túas transferencias defendibles se o marco volve ser anulado.
O que fai realmente o DPF
O DPF é unha decisión de adecuación emitida pola Comisión Europea ao abeiro do artigo 45 do GDPR. Unha decisión de adecuación establece que un país terceiro — neste caso, os Estados Unidos — proporciona un nivel de protección de datos persoais esencialmente equivalente ao da UE, pero só para as organizacións que se adhiren a un marco específico. O DPF é ese mecanismo de adhesión. As empresas dos EUA autocertifícanse ante o Departamento de Comercio, comprométense a un conxunto de Principios de Privacidade e quedan suxeitas á execución da FTC ou do DOT deses compromisos.
Para un editor da UE, o efecto práctico é que os datos persoais poden transferirse a un provedor estadounidense certificado no DPF sen Cláusulas Contractuais Estándar (SCCs) separadas, sen Avaliacións de Impacto da Transferencia adaptadas a ese provedor nin medidas suplementarias do tipo requirido após a sentenza Schrems II. O DPF fai o traballo pesado na capa da base xurídica.
Tres cousas que o DPF non fai, e que os editores confunden constantemente:
- Non substitúe o consentimento. Colocar unha cookie non esencial nun visitante da UE segue a requirir consentimento de grao GDPR/ePrivacy independentemente de onde vaian parar os datos.
- Non cobre as transferencias a provedores dos EUA non certificados. Se o teu SSP ou provedor de análise non está na lista activa do DPF, aínda precisas SCCs e unha TIA.
- Non cobre as transferencias a filiais dos EUA que operan fóra do ámbito certificado. Moitos provedores grandes só certifican determinadas liñas de negocio.
O consentimento de cookies segue sendo a porta principal
O DPF resolve a parte da transferencia do percorrido. Non fai nada sobre o momento en que se deposita unha cookie, se le un identificador de anuncio ou se envía un evento a unha etiqueta. Ese momento está rexido pola Directiva ePrivacy (artigo 5(3)) e o GDPR (artigos 6 e 7). Ambos esixen consentimento previo, informado, específico e libremente outorgado para calquera acceso non estritamente necesario ao almacenamento do equipo terminal.
Dito doutro modo, aínda que todos os provedores do teu stack estean certificados no DPF, seguirás a necesitar unha Plataforma de Xestión do Consentimento que:
- Bloquee as cookies e etiquetas non esenciais antes de capturar o consentimento.
- Presente unha elección clara con paridade entre rexeitar-todo e aceptar-todo (o EDPB foi explícito nisto desde 2022).
- Rexistre o evento de consentimento cun selo de tempo a proba de falsificación e unha copia do aviso que o usuario viu realmente.
- Reenvíe o estado de consentimento a cada ferramenta á baixada mediante TCF v2.3, Google Consent Mode v2 ou API nativas do provedor.
O DPF substitúe a base xurídica da transferencia; o CMP proporciona a base xurídica da recollida. Omitir calquera dos dous lados déixache exposto.
Como verificar o estado DPF dun provedor
O Departamento de Comercio dos EUA mantén a lista oficial do DPF en dataprivacyframework.gov. Antes de apoiarte na alegación DPF dun provedor, comproba tres cousas na súa ficha.
Estado de certificación activa
As certificacións deben renovarse anualmente. Un provedor cuxo estado apareza como Inactivo, Retirado ou Caducado non pode ser empregado como mecanismo de transferencia, aínda que as súas páxinas de marketing sigan amosando un distintivo DPF. Engade a ficha ao teu inventario de provedores e comproba de forma trimestral.
Entidades e filiais cubiertas
Moitas compañías holding certifican algunhas filiais e non outras. A entidade contratual no teu DPA debe coincidir coa entidade certificada. Un erro frecuente é asinar con Acme Marketing UK Ltd cando a certificación DPF está en poder de Acme Inc. en Delaware — o fluxo de datos escapa entón do ámbito certificado.
Categorías de datos cubiertas
O DPF permite certificacións limitadas a datos de RR.HH. só, datos non de RR.HH. só ou ambos. Unha certificación só non-RR.HH. cobre os teus datos de anuncios e análise; unha certificación só RR.HH. non o fai. Le a ficha detidamente.
Que facer cando un provedor non está certificado no DPF
Moitos provedores dos EUA útiles — especialmente os actores máis pequenos do ad-tech e as ferramentas de análise de nicho — nunca se certificaron ou deixaron caducar a certificación. Para estes, o DPF é irrelevante e recórrense ao kit de ferramentas anterior a 2023:
- Cláusulas Contractuais Estándar (SCCs) — as versións do módulo 2 ou módulo 3 de 2021, asinadas por ambas as partes e incorporadas ao DPA.
- Avaliación de Impacto da Transferencia (TIA) — unha análise específica do provedor sobre a lei de vixilancia dos EUA, as categorías de datos en risco e as medidas técnicas e organizativas que mitigan a exposición.
- Medidas suplementarias — cifrado en tránsito e en repouso, pseudonimización, compromisos contractuais de transparencia e un plan de resposta documentado para as solicitudes de acceso do goberno dos EUA.
Mantén un rexistro que liste cada provedor dos EUA no teu stack, a base xurídica empregada para cada un (DPF, SCCs, derrogación) e a data da revisión máis recente. Os reguladores e auditores pedirán este rexistro; non telo é en si mesmo un achado.
O risco Schrems III e como prepararse para o futuro
O activista da privacidade Max Schrems e a súa organización NOYB presentaron unha acción contra o DPF pouco despois de adoptarse, argumentando que a reforma da vixilancia dos EUA ao abeiro da Orde Executiva EO 14086 segue sen alcanzar os estándares de dereitos fundamentais da UE. Espérase amplamente unha remisión ao CJEU, e o marco ten unha probabilidade non trivial de ser anulado — o terceiro en vinte anos.
Os editores que trataron o Privacy Shield como o único mecanismo de transferencia en 2020 tiveron que reaccionar de urxencia dunha noite para a outra cando Schrems II o invalidou. A mesma situación de urxencia é evitable esta vez tratando o DPF como mecanismo principal cunha copia de seguranza lista para activarse.
Manter as SCCs en cada DPA
Insiste en que os teus DPA inclúan as SCCs de 2021 como cláusula de reserva que se active automaticamente se a decisión de adecuación do DPF é invalidada ou caduca a certificación do provedor. Este xa é linguaxe estándar; se un provedor se nega, é un sinal de alerta.
Executar unha TIA de todos xeitos
O DPF elimina o requisito legal dunha TIA, pero realizar unha lixeira — especialmente para provedores que xestionan sinais publicitarios sensibles ou grandes poboacións da UE — ofrécete documentación defendible se o marco colapsa. Reutiliza o mesmo modelo entre provedores para manter o custo baixo.
Localizar onde as contas saen
Para algúns casos de uso — análise de primeira parte, datos de comportamento de usuarios rexistrados ou sitios con contido sensible — pasar a un provedor aloxado e controlado na UE elimina por completo a cuestión da transferencia. O análise custo-beneficio só resulta viable para fluxos de alto risco ou alto volume, pero debería estar no roadmap como opción.
Conectar o DPF ao teu CMP
Un CMP moderno non aplica o DPF directamente — non existe ningún campo GPP nin TCF que diga "esta transferencia está cuberta polo DPF". O que o CMP debe facer é recoller o consentimento para cada provedor de forma que sosteña a documentación que un regulador pedirá eventualmente.
Granularidade por provedor
Agrupar todos os provedores de ad-tech dos EUA nun único interruptor "Marketing" xa non é defendible. A lista de provedores TCF v2.3, que a maioría dos CMP certificados sincroniza, proporciona finalidades e bases xurídicas por provedor. Utilízaa. Cando un regulador preguntar "con que base fluíron os datos persoais ao provedor X na data Y", deberías ser capaz de sinalar a unha cadea TCF, un rexistro de certificación DPF e un DPA.
Reflectir o aviso de privacidade no banner
A lista de destinatarios no teu aviso de privacidade debe corresponderse exactamente coa lista de provedores cargados tras o consentimento. As discrepancias son o obxectivo de aplicación máis doado — a AEPD española e a CNIL francesa sancionaron editores en 2024 por listas de provedores que omitían socios activos.
Rexistrar o estado do provedor no momento do consentimento
Almacena, para cada evento de consentimento, a instantánea de qué provedores estaban no TCF GVL, cales estaban certificados no DPF e que base xurídica empregaba cada un. Esta é a pista de auditoría que transforma unha carta estresante do regulador nunha resposta rutineira. FlexyConsent e outros CMP certificados por Google ofrecen este rexistro de serie; moitos banners máis antigos non o fan.
Lista de verificación de migración práctica
Se estás a mover un sitio existente dun setup pre-DPF ou parcialmente DPF a unha configuración limpa de 2026, traballa esta lista:
- Fai un inventario de todos os provedores dos EUA no teu xestor de etiquetas, stack de anuncios e contedor do lado do servidor.
- Cruza cada un coa lista activa do DPF. Clasifícaos como cuberto polo DPF, cuberto por SCCs ou acción necesaria.
- Actualiza os DPA para incluír as SCCs de 2021 como copia de seguranza automática.
- Executa unha TIA para os provedores de alto risco independentemente do estado no DPF.
- Confirma que o teu CMP expón unha IU de consentimento por provedor e é compatible con TCF v2.3.
- Verifica que Google Consent Mode v2 está conectado a GA4, Ads e calquera ferramenta de perda de sinal.
- Programa unha revisión trimestral no calendario para volver a comprobar certificacións, adhesión ao GVL e versións dos DPA.
- Informa conxuntamente ao equipo xurídico e ao de operacións publicitarias sobre o que cambia se o DPF é invalidado, para que o plan de resposta non se improvise baixo presión.
Ideas erróneas comúns
Algúns erros repítense nas auditorías de editores e precisan corrección explícita.
«Estar certificado no DPF significa que non necesitamos consentimento.» Non. O DPF é un mecanismo de transferencia. O consentimento é un requisito de recollida. Atópanse en capas xurídicas diferentes.
«O noso CDN ten sede nos EUA, polo que o DPF cóbreo.» Só se o CDN está el mesmo certificado no DPF para as categorías de datos pertinentes. Moitos provedores de infraestrutura ofrecen rexións da UE que evitan a cuestión por completo.
«O provedor X di que está preparado para o DPF.» Linguaxe de marketing. Comproba a lista oficial, o nome da entidade certificada e as categorías de datos.
«O DPF substitúe o banner de cookies.» Non. A norma de consentimento previo da Directiva ePrivacy é independente das normas de transferencia do GDPR. Ambas se aplican.
Conclusión
O DPF fai o ad-tech transatlántico operativamente máis sinxelo en 2026 do que era en 2021, pero non exime aos editores do consentimento de cookies, a debida dilixencia coa provedores nin a documentación das transferencias. Trata o DPF como un mecanismo de transferencia válido entre varios, mantén as SCCs como respaldo contractual, emprega un CMP que rexistre o consentimento por provedor fronte a un inventario de provedores mantido, e asume que a estabilidade xurídica do marco é condicional. Os editores que constrúan esa resiliencia agora non terán que rediseñar de noite se a sentenza Schrems III cae como as dúas anteriores. Os que traten o DPF como unha resposta permanente están preparándose para o mesmo axite que seguiu á invalidación do Privacy Shield — só que desta vez os reguladores son menos pacientes e as multas son maiores.