GDPR en 2026: lo que cambió desde 2018.

Por qué el texto se quedó quieto y la práctica se movió

El GDPR no ha sido reescrito. Los números de artículo que aprendió en 2018 son los números de artículo que aplica en 2026. Lo que cambió está una capa por debajo: la jurisprudencia que interpreta el texto, las directrices del EDPB que lo operativizan, las cláusulas contractuales tipo que dan soporte a sus transferencias y el mecanismo de adecuación que gobierna dónde pueden aterrizar legalmente los datos. Un programa de privacidad construido en 2018 y nunca tocado desde entonces no está mal sobre el papel. Está desfasado en la práctica, y lo desfasado es lo que la actividad sancionadora encuentra ahora.

Esta página es para la persona que ya entiende el reglamento y necesita saber qué actualizar. Da por supuesto que sabe definir qué son datos personales, un responsable y una base jurídica. Se centra en las cuatro piezas en movimiento que realmente generan hallazgos en 2026: las transferencias internacionales, el Transfer Impact Assessment, el solapamiento con la AI Act y la cuestión de si está obligado a nombrar un Data Protection Officer.

Transferencias internacionales: el árbol de decisión, no el titular

La mayoría de los equipos conoce los titulares. Schrems II invalidó el Privacy Shield en 2020. El EU-US Data Privacy Framework lo reemplazó en 2023. Las SCC de 2021 reemplazaron a las versiones de 2010. Los titulares son ciertos y casi inútiles por sí solos, porque el verdadero trabajo consiste en hacer coincidir una transferencia concreta con un instrumento concreto y después decidir si hace falta un Transfer Impact Assessment además. Eso es un árbol de decisión, y lo recorre por cada flujo de datos, no una sola vez para toda la empresa.

Empiece por el destino. Si el importador se encuentra en un país con una decisión de adecuación de la UE vigente, transfiere sobre la base de la decisión de adecuación y no necesita SCC ni un TIA para ese flujo. Si el destino es Estados Unidos y el importador está autocertificado bajo el Data Privacy Framework para las categorías de datos pertinentes, ese flujo se apoya en el DPF como su propia base de adecuación: sin SCC, sin medidas complementarias. En cuanto sale de ambos supuestos, queda bajo las garantías del Article 46, lo que en la práctica significa las SCC de 2021, y las SCC conllevan una obligación de TIA que Schrems II hizo no opcional.

El Transfer Impact Assessment en la operación

Un TIA es el documento que responde a una pregunta: ¿la legislación y la práctica del país de destino socavan la protección que sus SCC prometen sobre el papel? No es una casilla que marcar. Es una pequeña pieza de análisis jurídico y técnico que produce por cada transferencia (o por cada grupo de transferencias materialmente idénticas) y conserva en archivo para el día en que un regulador pregunte.

En la práctica, un TIA defendible hace cuatro cosas. Describe la transferencia de forma concreta: quién exporta, quién importa, qué datos, qué volumen, qué finalidad. Evalúa el régimen jurídico de destino, con especial atención a las facultades de acceso gubernamental y a si un interesado dispone de algún recurso efectivo. Identifica medidas complementarias cuando el régimen jurídico es débil, y la medida que realmente marca la diferencia es el cifrado que usted controla, en el que el importador nunca posee las claves. Y registra una conclusión razonada: proceder, proceder con medidas o no transferir.

1. Mapee el flujo con precisión, incluidas las transferencias ulteriores que su encargado realice a subencargados. Los flujos que olvida son los que afloran en una brecha.
2. Evalúe la legislación de destino frente a los criterios del EDPB, no según su intuición sobre el país.
3. Aplique medidas complementarias cuando sea necesario, y trate el cifrado robusto con gestión propia de las claves como la medida técnica por defecto, en lugar de promesas contractuales por sí solas.
4. Documente la conclusión y féchela, después fije un detonante de revisión para que no expire en silencio.

Donde el GDPR se encuentra con la AI Act

La AI Act no reemplaza al GDPR ni lo relaja. Cuando un sistema de IA trata datos personales, ambos se aplican en su totalidad y usted satisface ambos. La forma más clara de ver el solapamiento es a través del artefacto que cada régimen espera. El GDPR exige un Data Protection Impact Assessment cuando es probable que el tratamiento suponga un alto riesgo para las personas. La AI Act exige una evaluación de conformidad, documentación técnica y (para algunos sistemas) una evaluación de impacto sobre los derechos fundamentales para la IA de alto riesgo. Son documentos diferentes que responden a preguntas diferentes, y un sistema de IA de alto riesgo que trata datos personales necesita ambos, coherentes entre sí.

Los puntos de fricción son problemas conocidos del GDPR con ropa nueva. Las decisiones automatizadas con efecto jurídico o similarmente significativo ya activaban las obligaciones del Article 22; la AI Act añade encima deberes de transparencia y supervisión humana. Los datos de entrenamiento plantean cuestiones de base jurídica y de limitación de la finalidad que no desaparecen porque la salida sea un modelo. La elaboración de perfiles y las inferencias siempre estuvieron en el ámbito de aplicación. La regla práctica para 2026: no ejecute una línea de trabajo de gobernanza de la IA que ignore a su DPO, y no ejecute un programa de privacidad que finja que el entrenamiento de modelos es problema de otro. Las dos evaluaciones deben remitirse la una a la otra.

Los ingenieros de privacidad que tienen que tender puentes entre estos regímenes en las decisiones de construcción son precisamente el público de la certificación CDPSE, que se estructura en torno a la gobernanza, la arquitectura y el ciclo de vida del dato más que al texto legal por sí solo. Para operativizar la privacidad como un sistema de gestión que conviva limpiamente junto a un ISMS, el curso ISO 27701 Foundation cubre el modelo PIMS, y el curso ISO 27701 Lead Implementer le guía por su construcción y operación.

La actividad sancionadora es una señal, no solo un riesgo

Lea la actividad sancionadora reciente como un mapa de dónde están mirando las autoridades, porque le indica dónde se encuentra probablemente su propia exposición. El patrón a lo largo de 2023 a 2025 es coherente. Las transferencias internacionales produjeron las mayores sanciones individuales, con la decisión sobre Meta (1.200 millones de euros) girando en torno a los flujos de datos entre la UE y EE. UU. La publicidad comportamental y la base jurídica para la segmentación publicitaria motivaron la decisión sobre LinkedIn (310 millones de euros). Los datos biométricos extraídos mediante scraping impulsaron acciones reiteradas contra Clearview AI ante múltiples autoridades. Las autoridades activas son las que cabría esperar: la CNIL en Francia, la DPC en Irlanda para las grandes plataformas y la AEPD en España.

La conclusión operativa es dejar de tratar la actividad sancionadora como el titular de otro. Si las transferencias, el consentimiento publicitario y el tratamiento biométrico o cercano a la IA son donde caen las multas, esos son los tres expedientes sobre los que un regulador tiene estadísticamente más probabilidad de preguntarle. Un programa que puede presentar un TIA vigente, un registro de consentimiento defendible y una DPIA para su tratamiento de mayor riesgo es un programa que sobrevive a las preguntas que realmente se formulan.

¿Necesita realmente un DPO?

La cuestión del DPO es la que más a menudo se responde por reflejo en lugar de por el texto. El Article 37 hace obligatorio un DPO en tres situaciones: usted es una autoridad u organismo público; sus actividades principales consisten en una observación habitual y sistemática de los interesados a gran escala; o sus actividades principales consisten en el tratamiento a gran escala de categorías especiales de datos o de datos sobre condenas penales. Si no se da ninguna de esas, el GDPR no obliga al nombramiento, aunque algunas legislaciones nacionales añaden sus propios detonantes y un DPO voluntario suele ser la opción sensata.

La expresión que decide la mayoría de los casos reales es "actividades principales". Un hospital observa datos de salud como su actividad principal, así que necesita un DPO. Un fabricante que gestiona nóminas trata datos personales, pero eso es una función de apoyo, no una actividad principal, así que las nóminas por sí solas no activan la obligación. Los errores se concentran en los límites: nombrar a alguien que carece de la independencia y la línea de reporte que exige el Article 38, designar un DPO que tiene un conflicto de interés porque también es propietario del tratamiento que se supone debe supervisar, o nombrar sobre el papel sin dar autoridad al rol. Un DPO que no puede llegar al consejo y no puede decir que no es un hallazgo esperando a ser redactado.

Si el rol es suyo para cubrir o para supervisar, la profundidad importa. El curso GDPR Foundation es el punto de partida adecuado para el equipo en torno al rol, y el curso GDPR Certified Data Protection Officer está pensado para la persona que ostenta el cargo, cubriendo la independencia, las tareas y la rendición de cuentas que el reglamento realmente exige.

Qué actualizar antes de su próxima auditoría

Ponga al día las piezas en movimiento y el resto del programa prácticamente se cuida solo. Confirme que toda transferencia está sobre las SCC de 2021, no sobre el conjunto retirado de 2010, porque las cláusulas heredadas son un hallazgo inmediato. Compruebe que cada transferencia no adecuada tiene un TIA fechado y vinculado desde su RoPA. Verifique que cualquier proveedor estadounidense del que dependa está actualmente certificado bajo el DPF para los datos que envía, y que dispone de un plan de contingencia con SCC si no lo está. Asegúrese de que su tratamiento de mayor riesgo cuenta con una DPIA, y de que todo lo impulsado por IA tiene a su lado los artefactos de la AI Act. Por último, vuelva a contrastar la cuestión del DPO frente a sus actividades principales reales, en lugar de la respuesta que dio en 2018.