El EDPB endurece el mensaje: derechos, brechas de salud y uso de datos ya concentran la presión del GDPR

La agenda publicada por el Comité Europeo de Protección de Datos (EDPB) en septiembre de 2026 contiene una señal más útil que cualquier declaración solemne: la aplicación práctica del GDPR se está desplazando hacia tres zonas donde muchas organizaciones todavía trabajan con controles separados y responsabilidades difusas. Derechos de los afectados, seguridad de los datos sanitarios y reutilización de información para inteligencia artificial ya no son asuntos independientes.

La señal llega con dos decisiones nacionales de la CNIL francesa. El 11 de septiembre, la autoridad anunció una multa de 300.000 euros a EXTIA por no respetar los derechos de las personas. Dos días antes comunicó otra sanción de 500.000 euros al Hôpital Privé de la Loire por una brecha de datos de salud. Son 800.000 euros en 48 horas, aunque conviene no convertir esa cifra en una falsa estadística de tendencia: la página del EDPB no ofrece en el material disponible el detalle de los hechos, la facturación de las entidades ni el razonamiento completo de ambas resoluciones.

Lo que sí permite analizar la agenda es el criterio que las empresas deberían extraer. El GDPR no está siendo aplicado únicamente contra el gran incidente visible o la política de privacidad manifiestamente defectuosa. La presión se reparte entre la capacidad de responder a una persona, la calidad de las medidas técnicas y organizativas y la legitimidad de nuevos usos de datos. La burocracia documental, por sí sola, no cubre ninguno de los tres frentes.

La página de noticias no es una resolución, y esa diferencia importa

El propio EDPB advierte que las noticias de las autoridades nacionales aparecen con fines informativos y no constituyen comunicados oficiales ni recomendaciones del Comité. En otras palabras: el listado sirve para detectar líneas de enforcement, pero no sustituye la lectura de una decisión nacional.

La cautela es especialmente necesaria con las dos sanciones francesas. Sabemos las fechas, los importes y la descripción general del incumplimiento. No sabemos, a partir del contenido facilitado, qué derecho concreto se vulneró en EXTIA, si hubo reiteración, qué categorías de datos estaban implicadas en el hospital, cuándo se detectó la brecha o qué medidas fueron consideradas insuficientes. Cualquier artículo que rellenase esos huecos estaría haciendo algo muy poco compatible con el periodismo regulatorio: convertir una ficha de noticias en una sentencia imaginaria.

La lectura correcta es otra. Las decisiones activan obligaciones que sí están claramente delimitadas en el Reglamento 2016/679. Los derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición se articulan principalmente en los artículos 15 a 21, con los plazos y excepciones del artículo 12. Las brechas se conectan con los artículos 32, 33 y 34: seguridad del tratamiento, notificación a la autoridad de control y comunicación a los afectados cuando el riesgo sea alto. En datos de salud aparece además el artículo 9, que establece el régimen reforzado para categorías especiales.

Para compliance, la consecuencia es inmediata: no basta con registrar que existe un procedimiento de derechos ni con tener un plan de respuesta a incidentes. Hay que demostrar que ambos funcionan con datos reales, responsables identificados y tiempos medidos.

El caso EXTIA apunta al punto débil de muchas organizaciones: atender derechos no es abrir un buzón

La multa de 300.000 euros a EXTIA se describe como un incumplimiento de los derechos de las personas. Sin el texto completo de la CNIL no procede atribuirle una conducta concreta. Pero la referencia permite revisar una confusión recurrente: una dirección de correo para privacidad no equivale a un sistema de ejercicio de derechos.

El artículo 12 del GDPR exige que la información y las comunicaciones relativas al tratamiento sean concisas, transparentes, inteligibles y de fácil acceso, y que la entidad facilite el ejercicio de los derechos. El mismo artículo fija, como regla general, la respuesta sin dilación indebida y, en cualquier caso, dentro de un mes desde la recepción de la solicitud. El plazo puede ampliarse otros dos meses por la complejidad o el número de solicitudes, pero el responsable debe informar al interesado dentro del primer mes y explicar el motivo.

Ese plazo se convierte en un problema operativo cuando la identidad del solicitante se valida en un sistema, los datos están repartidos entre varias filiales y la eliminación depende de copias de seguridad, herramientas de marketing, plataformas de recursos humanos y proveedores externos. El equipo jurídico puede conocer el artículo 17 sobre supresión; el equipo de tecnología puede conocer dónde viven los datos; atención al cliente puede recibir la petición. Si nadie gobierna la cadena completa, la organización no tiene un proceso de derechos: tiene una carrera de relevos sin testigo.

Qué debería poder demostrar una entidad

Una respuesta defendible ante una autoridad no se limita a enseñar una política. Debería permitir reconstruir, al menos, estos pasos: fecha y canal de entrada, identidad verificada, alcance de la búsqueda, sistemas consultados, decisión sobre cada derecho, excepciones aplicadas, fecha de respuesta y evidencia de la comunicación al interesado.

El registro no tiene que convertirse en una novela administrativa. Sí debe explicar por qué se accedió a unos datos, por qué se retuvo otro conjunto, qué tercero recibió instrucciones y cuándo se cerró el expediente. El artículo 5.2 introduce el principio de responsabilidad proactiva: el responsable debe cumplir los principios del tratamiento y ser capaz de demostrarlo. Esa segunda mitad suele recibir menos atención que la primera, hasta que llega una inspección.

El artículo 15 merece un tratamiento particular porque el acceso no consiste únicamente en exportar una tabla. Incluye confirmar si se tratan datos personales, facilitar una copia y proporcionar información sobre fines, categorías, destinatarios, plazo de conservación, origen de los datos y existencia de decisiones automatizadas, entre otros elementos. En organizaciones con sistemas de perfilado, la respuesta requiere coordinación entre privacidad, producto, datos y seguridad.

La supresión del artículo 17 tampoco es absoluta. Tiene excepciones, entre ellas el cumplimiento de una obligación legal, la defensa de reclamaciones o el ejercicio de la libertad de expresión e información. La entidad no puede rechazar la solicitud con una fórmula genérica, pero tampoco borrar datos sujetos a conservación obligatoria sin documentar el conflicto normativo. La decisión debe ser específica para el caso.

El hospital francés vuelve a poner los datos de salud en el centro

El 9 de septiembre de 2026, la CNIL anunció una multa de 500.000 euros al Hôpital Privé de la Loire por una brecha de datos de salud. La información disponible no detalla el vector de ataque, el volumen de registros, la duración de la exposición ni la medida exacta sancionada. Conviene mantener esa frontera factual.

Lo que sí está claro es que los datos de salud entran en las categorías especiales del artículo 9 del GDPR. Eso no significa que todo tratamiento sanitario sea ilícito: el propio artículo contempla bases específicas, como la prestación de asistencia sanitaria, la gestión de sistemas de salud, la salud pública o la investigación bajo las condiciones aplicables. Sí significa que una filtración puede tener una gravedad mayor por la naturaleza de la información, aunque la cuantía de una multa nunca dependa de una sola etiqueta.

El análisis técnico debe comenzar en el artículo 32. El responsable y el encargado deben aplicar medidas apropiadas al riesgo, teniendo en cuenta el estado de la técnica, los costes de aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento, así como la probabilidad y gravedad del riesgo para las personas. El artículo menciona, entre otras medidas, el cifrado y la seudonimización, la capacidad de garantizar confidencialidad, integridad, disponibilidad y resiliencia permanentes, la restauración oportuna del acceso y un proceso de verificación, evaluación y valoración regulares.

La lista no es un catálogo que se pueda marcar como completado. Cifrar una base de datos no compensa unas credenciales privilegiadas sin control, una segmentación inexistente o copias de seguridad accesibles desde el mismo dominio comprometido. Del mismo modo, comprar una plataforma de detección no demuestra que la organización pueda restaurar la atención clínica tras un incidente.

En un entorno sanitario, la pregunta relevante no es solo si los datos se exfiltraron. También es si el incidente impidió consultar historiales, alteró información clínica, bloqueó sistemas de citación o forzó procedimientos manuales. La disponibilidad forma parte de la seguridad del artículo 32. Un hospital que evita una filtración pero no puede recuperar sus sistemas sigue teniendo un problema de resiliencia, aunque el titular periodístico sea menos espectacular.

Las 72 horas no son un período de gracia

El artículo 33 obliga a notificar una violación de seguridad a la autoridad de control sin dilación indebida y, cuando sea posible, dentro de las 72 horas desde que el responsable tenga constancia de ella, salvo que sea improbable que constituya un riesgo para los derechos y libertades. Si la notificación se presenta después, debe explicar los motivos del retraso.

El plazo no empieza cuando el comité ejecutivo aprueba el comunicado ni cuando el proveedor termina su análisis forense. Empieza cuando el responsable tiene un grado suficiente de certeza de que se ha producido una violación de datos personales. En una organización compleja, esa frontera debe estar definida antes del incidente.

La notificación debe incluir, como mínimo, la naturaleza de la violación, las categorías y el número aproximado de interesados y registros afectados, los datos de contacto del delegado de protección de datos o punto de contacto, las consecuencias probables y las medidas adoptadas o propuestas para remediar el incidente y mitigar sus efectos. Si toda la información no está disponible en 72 horas, el artículo 33 permite facilitarla por fases, no esperar a tener un informe forense perfecto.

El artículo 34 añade la comunicación a los afectados cuando la violación pueda entrañar un alto riesgo para sus derechos y libertades. Los datos sanitarios elevan la sensibilidad del análisis, pero no eliminan la necesidad de valorar el riesgo concreto. La comunicación debe describir la naturaleza del incidente en lenguaje claro y explicar las medidas recomendadas o adoptadas.

Para un hospital o proveedor sanitario, una prueba útil consiste en simular un incidente en el que no se conoce todavía el número exacto de pacientes afectados. Si la respuesta interna se bloquea porque nadie quiere notificar hasta cerrar el perímetro, el procedimiento no está preparado. Y si el proveedor tecnológico es quien controla toda la información, el contrato tampoco está suficientemente gobernado.

La agenda del EDPB conecta GDPR, IA y competencia

Las entradas publicadas durante 2026 muestran que el EDPB no está tratando la privacidad como una disciplina aislada. El Comité anunció un evento para elaborar directrices sobre la interacción entre protección de datos y derecho de la competencia; publicó una referencia a la anonimización y el web scraping para inteligencia artificial generativa; adoptó la versión final de sus directrices sobre blockchain y comunicó trabajos conjuntos con la Autoridad Europea contra el Blanqueo de Capitales y la Financiación del Terrorismo (AMLA).

Son asuntos distintos, pero comparten una pregunta: quién puede utilizar qué datos, con qué base jurídica, bajo qué límites y con qué capacidad de control. El departamento que responde a solicitudes de acceso no puede resolver por sí solo el tratamiento de datos para entrenar modelos. Tampoco puede hacerlo el equipo de innovación sin pasar por la evaluación de finalidad, minimización, conservación, seguridad y derechos.

El web scraping para IA generativa ilustra el problema. Que una información sea accesible en internet no la convierte automáticamente en libre de obligaciones del GDPR. El análisis debe distinguir entre datos personales y no personales, origen, expectativa razonable, finalidad compatible, base jurídica, minimización y posibilidad real de ejercer derechos. En determinados casos, la anonimización puede sacar los datos del ámbito del Reglamento, pero la seudonimización no: el artículo 4.5 la define como una técnica en la que los datos aún pueden vincularse a una persona mediante información adicional.

La diferencia es crítica para los equipos de producto. Sustituir nombres por identificadores internos no permite afirmar que se trabaja con datos anónimos. Para llegar a la anonimización debe desaparecer, de forma razonablemente irreversible, la posibilidad de reidentificación teniendo en cuenta todos los medios que puedan utilizarse razonablemente. La documentación técnica debe explicar el modelo de amenaza, no limitarse a utilizar la palabra anonimizado en una diapositiva.

El artículo 25 exige protección de datos desde el diseño y por defecto. En proyectos de IA, esa obligación debería traducirse en decisiones concretas: limitar la recopilación, separar datos de entrenamiento y producción, restringir el acceso a conjuntos de datos, registrar las transformaciones, evaluar la retención y crear mecanismos para atender solicitudes sobre datos utilizados en el sistema. El artículo 35 puede exigir una evaluación de impacto cuando el tratamiento, especialmente mediante nuevas tecnologías, entrañe un alto riesgo para las personas.

AMLA y el intercambio de información: más cooperación no significa barra libre

El 1 de julio de 2026, el EDPB anunció que trabajaría con AMLA en directrices conjuntas sobre alianzas para el intercambio de información. La fecha importa porque muestra que el Comité está entrando en un problema muy operativo: las entidades necesitan compartir señales para combatir el blanqueo de capitales y la financiación del terrorismo, pero esa finalidad no convierte cualquier intercambio en legítimo.

El GDPR incorpora principios que siguen siendo aplicables cuando el objetivo es combatir delitos financieros. El artículo 5 exige licitud, lealtad y transparencia; limitación de la finalidad; minimización; exactitud; limitación de la conservación; integridad y confidencialidad. El artículo 6 exige una base jurídica para el tratamiento. Si se manejan categorías especiales, el artículo 9 añade condiciones específicas.

Para bancos, fintech y proveedores de pagos, el reto es evitar dos extremos igualmente peligrosos. El primero es compartir demasiado: perfiles de riesgo, sospechas no verificadas o información de clientes más allá de lo necesario. El segundo es utilizar la privacidad como excusa para no compartir información que la legislación antiblanqueo exige comunicar. La solución no está en una frase genérica sobre interés legítimo, sino en mapear finalidad, base jurídica, categorías de datos, destinatarios, conservación y controles de acceso para cada flujo.

La futura cooperación entre EDPB y AMLA también explica por qué el Comité publicó en junio una noticia sobre la necesidad de una base jurídica para el intercambio de información entre reguladores. Los supervisores pueden coordinarse, pero esa coordinación debe tener una arquitectura legal. Para las empresas, el mensaje es incómodo y saludable: si dos autoridades necesitan una base jurídica clara para compartir información, una compañía no debería dar por supuesto que puede transferir internamente cualquier dato entre equipos de cumplimiento.

Blockchain, cookies y el derecho a borrar: la tecnología no suspende el GDPR

La lista de noticias incorpora otros dos asuntos que parecen alejados de las multas francesas, pero no lo están. El EDPB publicó el 8 de julio la versión final de sus directrices sobre blockchain y el 14 de julio pidió a la autoridad belga que examinara el fondo de una reclamación de NOYB sobre banners de cookies.

Blockchain vuelve a plantear el conflicto entre inmutabilidad y derechos de rectificación y supresión. El artículo 16 reconoce el derecho de rectificación y el artículo 17 el de supresión, con sus excepciones. Una organización que almacena datos personales directamente en una cadena de bloques debe poder explicar cómo hará efectivos esos derechos. La respuesta no puede consistir en que la tecnología no permite cambiar el registro. Esa es una propiedad del diseño, no una excepción legislativa.

Una arquitectura con referencias, hashes o almacenamiento fuera de la cadena puede reducir el problema, pero no lo resuelve automáticamente. Hay que valorar si el hash sigue siendo un dato personal, quién controla las claves, qué ocurre cuando se destruye el dato original y cómo se evita que un registro auxiliar permita reconstruir la identidad. El análisis corresponde al tratamiento concreto, no al nombre comercial de la infraestructura.

Con las cookies ocurre algo parecido. Un banner que ofrece aceptar o rechazar no es necesariamente un mecanismo válido de consentimiento. El artículo 7 exige que el responsable pueda demostrar que la persona consintió y que retirar el consentimiento sea tan fácil como prestarlo. El artículo 5.1.a exige transparencia y el artículo 6 determina que el consentimiento es solo una de las posibles bases jurídicas, no una licencia para colocar cualquier tecnología de seguimiento.

La reclamación de NOYB, tal como aparece en la página del EDPB, se refiere a una petición para que la autoridad belga examine el fondo. No permite concluir que exista una decisión final ni anticipar su resultado. Sí permite recordar algo práctico: los diseños de interfaz también forman parte del cumplimiento. Si el rechazo está escondido, si el usuario recibe presión visual o si retirar la elección exige navegar por varias pantallas, la discusión ya no es puramente estética.

Qué cambia para los responsables de privacidad y los CISO

La agenda de septiembre no exige inventar nuevos controles. Exige conectar los que ya deberían existir. El responsable de privacidad necesita saber cómo se detectan y escalan las brechas; el CISO necesita conocer qué datos activan obligaciones específicas; compras debe traducir esas obligaciones a contratos; producto debe integrar derechos y minimización desde el diseño; dirección debe recibir métricas que no oculten los casos difíciles.

Una revisión útil puede comenzar con cuatro preguntas. ¿Puede la entidad demostrar que responde a una solicitud de acceso dentro del plazo del artículo 12 sin depender de búsquedas manuales improvisadas? ¿Puede decidir en las primeras horas si una alerta de seguridad es una violación del artículo 4.12 y si debe notificarse conforme al artículo 33? ¿Sabe qué conjuntos de datos personales alimentan modelos, procesos de detección de fraude o herramientas de marketing? ¿Puede identificar, para cada proveedor, quién notifica el incidente y en cuánto tiempo?

El artículo 28 regula la relación con los encargados del tratamiento. El contrato debe recoger, entre otros elementos, el tratamiento documentado, la confidencialidad, las medidas del artículo 32, la asistencia para responder a derechos y obligaciones de seguridad, la devolución o supresión de datos y la información necesaria para demostrar cumplimiento y permitir auditorías. En una brecha sanitaria, un contrato que solo promete “seguridad adecuada” vale poco cuando el reloj de 72 horas está corriendo.

También conviene medir la calidad, no solo el volumen. El número de solicitudes cerradas no revela si se excluyeron sistemas, se aplicaron mal las excepciones o se respondió tarde. El número de incidentes notificados tampoco demuestra resiliencia si nunca se prueba la restauración. Y una tasa alta de consentimientos no prueba que el banner fuera libre, específico, informado e inequívoco.

La lectura para 2026: enforcement fragmentado, expectativas convergentes

El EDPB no ha anunciado en el material disponible una nueva sanción europea coordinada que unifique estos casos. Lo que muestra la agenda es algo menos llamativo y más relevante para la gestión: las autoridades nacionales siguen aplicando el GDPR en ámbitos distintos, mientras el Comité intenta construir criterios comunes sobre derechos, inteligencia artificial, blockchain, cookies, cooperación regulatoria y datos financieros.

La fragmentación institucional no elimina la convergencia de expectativas. Una empresa que opera en varios Estados miembros puede recibir la noticia de una sanción de una autoridad nacional y pensar que se trata de un caso local. El artículo 63 del GDPR establece el mecanismo de coherencia y el artículo 60 regula la cooperación entre la autoridad principal y las autoridades interesadas en tratamientos transfronterizos. Pero los controles que evitan una brecha, permiten responder a un acceso o justifican una transferencia no dejan de ser necesarios porque el expediente tenga un supervisor distinto.

La conclusión práctica es poco glamourosa: hay que probar los procesos antes de que una autoridad, un paciente, un empleado o un regulador los pruebe por nosotros. Las dos multas francesas suman 800.000 euros, pero la cifra no es la lección principal. La lección es que los fallos de derechos y seguridad se materializan en operaciones concretas: un plazo incumplido, una base de datos no protegida, un proveedor que no escala una alerta, una copia de seguridad que no se puede restaurar o un modelo que utiliza datos sin una respuesta clara a la pregunta más básica del GDPR: para qué.