Por qué la decisión CNIL IQVIA no trata solo de códigos, sino de personas razonablemente identificables

Resumen

La Commission nationale de l’informatique et des libertés, formation restreinte, Délibération SAN-2026-008 du 26 mai 2026 concernant la société IQVIA OPERATIONS FRANCE —en adelante, CNIL IQVIA— es una decisión especialmente relevante para entender los límites de la seudonimización en tratamientos masivos de datos de salud.

La CNIL sancionó a IQVIA OPERATIONS FRANCE con una multa de cinco millones de euros por incumplimientos vinculados a la gestión de almacenes de datos de salud, el deber de información, la efectividad de derechos, la seguridad y la protección de datos desde el diseño. La propia autoridad destacó que el caso afectaba a datos de salud tratados a gran escala y dentro de una actividad empresarial centrada en el análisis de datos sanitarios. (cnil.fr)

El interés del caso no está solo en la sanción. Está en la forma de razonar. La CNIL no se limita a preguntar si los datos llevaban nombre y apellidos. La cuestión es más precisa: cuando un conjunto seudonimizado conserva suficiente densidad informativa para seguir tratamientos, enlazar episodios, reconstruir recorridos sanitarios y permitir la identificación de una persona mediante medios razonablemente susceptibles de ser utilizados en ese contexto, ¿puede tratarse como si hubiera quedado fuera del RGPD por ser anónimo?

La respuesta de la CNIL es negativa. En IQVIA, los datos estaban seudonimizados, pero no eran anónimos. El código reducía ciertos riesgos, pero no eliminaba la capacidad identificadora e inferencial del conjunto.

1. El código no hace magia

La seudonimización es una herramienta valiosa. En salud puede ser imprescindible. Permite trabajar con datos personales reduciendo la exposición directa de la identidad. Evita que el nombre, el número de identificación o el dato más obvio acompañen cada operación.

Pero también puede generar una falsa tranquilidad. A veces se presenta como si el simple cambio de nombre por código resolviera el problema. No lo resuelve siempre. Depende del dato, del contexto, de la técnica, de quién conserva la información adicional y de lo que el conjunto siga permitiendo saber.

Una imagen sencilla ayuda a verlo. Si en una clase se cambia el nombre de cada alumno por un número, los nombres desaparecen de la lista. Pero los alumnos no desaparecen. Si alguien conserva la tabla que une número y nombre, la identificación sigue siendo posible. Y aunque nadie vea esa tabla, quizá un alumno pueda ser identificado por su rastro: dónde se sienta, qué libros lee, qué días falta o con quién juega.

Con datos de salud ocurre algo parecido, pero el riesgo es mayor. Un código puede ocultar el nombre de un paciente. Pero si ese código permite seguir medicamentos, consultas, diagnósticos, síntomas, tratamientos o zonas geográficas, el conjunto puede mantener capacidad identificadora e inferencial. No siempre. No por regla automática. Pero sí cuando, en el contexto concreto, la persona sigue siendo identificable mediante medios razonablemente susceptibles de ser utilizados.

Ese es el punto fino de CNIL IQVIA. No se trata de negar el valor de la seudonimización. Se trata de impedir que se use como una palabra tranquilizadora cuando el sistema conserva demasiados caminos hacia la persona.

2. Qué hacía IQVIA

La resolución describe a IQVIA OPERATIONS FRANCE como una sociedad que ejerce, entre otras, actividades de consultoría y realización de estudios, para su propio beneficio o para laboratorios farmacéuticos. Para ello se apoyaba en dos almacenes de datos de salud autorizados por la CNIL: LRX, alimentado con datos procedentes de farmacias, y EMR, alimentado con datos procedentes de médicos.

El almacén LRX permitía analizar dispensaciones de medicamentos procedentes de farmacias y seguir recorridos de pacientes mediante identificadores únicos. El almacén EMR integraba datos procedentes de consultas médicas, entre ellos diagnósticos, síntomas, alergias, peso, talla, vacunas, pruebas, bajas laborales y prescripciones.

No eran datos aislados ni descontextualizados. Eran fragmentos de vida sanitaria organizados en el tiempo.

La CNIL reprochó a IQVIA varios incumplimientos: información insuficiente o inexacta a los pacientes, falta de efectividad práctica del derecho de oposición, deficiencias de seguridad, reutilización de datos para estudios sin respetar plenamente el marco aplicable y transmisión de datos desde programas de farmacia incluso cuando la farmacia había optado por no participar en el panel LRX. (cnil.fr)

La compañía sostuvo, a la luz de EDPS v SRB, que los datos contenidos en sus almacenes debían considerarse anónimos desde su propia perspectiva. La CNIL rechazó esa tesis: para la autoridad, la seudonimización aplicada no eliminaba la posibilidad de reidentificación por medios razonablemente susceptibles de ser utilizados, atendiendo a la arquitectura completa del tratamiento, a la riqueza de los datos y al papel desempeñado por IQVIA.

3. Qué es realmente seudonimizar

El artículo 4.5 del RGPD define la seudonimización como el tratamiento de datos personales de forma que ya no puedan atribuirse a una persona concreta sin utilizar información adicional, siempre que esa información adicional se conserve por separado y esté protegida mediante medidas técnicas y organizativas.

La definición parece técnica, pero la idea es comprensible: seudonimizar no es destruir el vínculo con la persona. Es separar ese vínculo y protegerlo.

ENISA lo explica con claridad en Deploying Pseudonymisation Techniques. The case of the Health Sector. La seudonimización busca ocultar la identidad de las personas dentro de un conjunto de datos, sustituyendo uno o varios identificadores por seudónimos y protegiendo el vínculo que permite asociar esos seudónimos con los identificadores originales. Ese vínculo es el punto delicado: ENISA lo denomina secreto de seudonimización, que puede conservarse en una tabla de asociación o en un mecanismo equivalente.

Esta precisión evita un error frecuente. Seudonimización y anonimización no son lo mismo. Los datos seudonimizados siguen siendo datos personales si la persona es identificable directa o indirectamente por medios razonablemente susceptibles de ser utilizados; los datos anónimos, en cambio, son aquellos en los que esa identificabilidad razonable ha desaparecido. La diferencia no es decorativa: decide si el RGPD sigue aplicándose.

Por eso, cuando una organización afirma que los datos están seudonimizados, la conversación no debería terminar. Debería empezar. Hay que preguntar cómo se ha hecho, frente a quién protege, qué información adicional existe, quién la controla, qué datos quedan en el conjunto y qué puede reconstruirse con ellos.

4. La técnica importa, pero no decide sola

Una seudonimización seria no consiste en quitar nombres y seguir igual. ENISA distingue técnicas como contadores, números aleatorios, funciones hash, HMAC o cifrado. También advierte que no todas ofrecen la misma protección. Un hash simple puede ser débil frente a ataques de diccionario o de fuerza bruta; una técnica basada en clave puede ofrecer más protección si está bien implementada y si la clave está adecuadamente protegida.

Pero la técnica no vive sola. Importa también la política de seudonimización. No es lo mismo asignar siempre el mismo código a una persona que generar códigos distintos por contexto, por documento o por operación. Un seudónimo estable facilita el seguimiento longitudinal; eso puede ser útil para determinados estudios, pero también aumenta la capacidad de reconstruir una trayectoria.

Aquí aparece el problema de IQVIA. No bastaba con afirmar que existían códigos, hashes, terceros de confianza o capas de separación. Había que mirar la arquitectura completa: datos de salud, riqueza clínica, seguimiento en el tiempo, posibilidad de correlación, fuentes externas y posición real de IQVIA dentro del sistema.

ENISA recuerda, además, que no existe una única forma correcta de aplicar la seudonimización. Puede ser una opción sencilla o un proceso complejo, técnico y organizativo. Por eso hay que definir sus objetivos en cada tratamiento concreto.

La técnica es una parte de la respuesta. No es toda la respuesta.

5. Breyer, Scania y EDPS v SRB: la identificabilidad se mira en contexto

La decisión CNIL IQVIA se entiende mejor dentro de una línea europea sobre identificabilidad.

En Tribunal de Justicia de la Unión Europea, sentencia de 19 de octubre de 2016, Patrick Breyer contra Bundesrepublik Deutschland, asunto C-582/14 —Breyer—, el Tribunal de Justicia sostuvo que, para saber si una persona es identificable, deben tenerse en cuenta los medios razonablemente susceptibles de ser utilizados por el responsable o por otra persona. El dato no se examina en el vacío. Se examina en un mundo en el que existen otros actores, otras fuentes y otros medios de conexión.

En Tribunal de Justicia de la Unión Europea, sentencia de 9 de noviembre de 2023, Gesamtverband Autoteile-Handel e.V. contra Scania CV AB, asunto C-319/22 —Scania—, el Tribunal analizó el número de bastidor de un vehículo, el VIN. El VIN no es el nombre de nadie. Es un identificador técnico. Pero puede ser dato personal si quien lo trata dispone de medios razonables para vincularlo con el propietario o usuario del vehículo. (EUR-Lex)

Scania no es un caso de seudonimización sanitaria. No conviene forzarlo. Su utilidad aquí es más modesta: muestra que un identificador técnico puede terminar hablando de una persona. No hace falta que el dato lleve un nombre escrito para que pueda ser personal.

El caso más próximo al debate de IQVIA es Tribunal de Justicia de la Unión Europea, sentencia de 4 de septiembre de 2025, European Data Protection Supervisor contra Single Resolution Board, asunto C-413/23 P —en español, Supervisor Europeo de Protección de Datos contra Junta Única de Resolución, conocido como EDPS v SRB o SEPD/JUR—. El Tribunal trató ahí el concepto de dato personal en un contexto de comentarios seudonimizados transmitidos a un destinatario externo. (infocuria.curia.europa.eu)

La enseñanza de EDPS v SRB es fina, y conviene no simplificarla. El Tribunal no dice que los datos seudonimizados queden fuera del RGPD siempre que el destinatario no tenga acceso directo a la tabla de correspondencia. Dice algo más casuístico: hay que analizar si, desde la posición concreta de ese destinatario, existen medios razonablemente utilizables para identificar a las personas. La separación formal no basta por sí sola; el análisis depende del contexto, de los medios razonables y de la posibilidad práctica de atribución.

IQVIA intentó apoyarse en esa línea. La CNIL no la niega. La sitúa. Y ahí está la diferencia decisiva: según la CNIL, IQVIA no era un destinatario externo que recibía una caja cerrada. La autoridad considera que IQVIA había definido y gobernado el circuito completo: finalidades, módulos de extracción, flujos, terceros de confianza, almacenes, seudonimización y reutilización posterior.

La comparación con EDPS v SRB tenía, por tanto, un límite claro. No es lo mismo recibir datos seudonimizados que construir la maquinaria que los recoge, transforma, conserva y explota.

6. Seudonimizar no sustituye la base jurídica ni el régimen de datos de salud

Hay un punto que conviene no perder. La discusión sobre seudonimización no sustituye la pregunta por la licitud del tratamiento.

Si los datos siguen siendo personales, el tratamiento necesita una base jurídica del artículo 6 RGPD. Si además son datos de salud, entra en juego el artículo 9 RGPD, porque estamos ante categorías especiales de datos. ENISA recuerda que los datos relativos a la salud forman parte de esas categorías especialmente protegidas y que su tratamiento plantea exigencias reforzadas.

En IQVIA, la CNIL no analiza los almacenes como simples bases privadas de datos ordinarios. Los sitúa dentro del régimen francés específico para tratamientos de datos de salud con fines de investigación, estudio o evaluación. IQVIA había obtenido autorizaciones para constituir los almacenes LRX y EMR conforme al artículo 66 de la Loi Informatique et Libertés, y esas autorizaciones incluían condiciones y garantías concretas.

Esto es importante. No basta con decir “los datos están seudonimizados”. Si siguen siendo datos personales de salud, hay que cumplir el RGPD, el régimen nacional aplicable y, en este caso, las condiciones de las autorizaciones concedidas por la CNIL.

La seudonimización puede ayudar a justificar, proteger y modular un tratamiento. Pero no sustituye la base jurídica, no elimina el artículo 9 RGPD y no vacía el régimen francés de autorización de tratamientos de salud.

7. La CNIL mira la arquitectura, no solo el código

El argumento de IQVIA tenía una fuerza aparente. Los datos habían pasado por procesos de seudonimización, intervenían terceros de confianza, el nombre del paciente no aparecía en claro y, según la compañía, desde su propia posición los datos de los almacenes LRX y EMR debían considerarse anónimos.

La CNIL no niega que existiera seudonimización ni que esa medida redujera riesgos. Lo que rechaza es que baste para cerrar el análisis. La autoridad no mira solo el código que sustituye al nombre. Mira el sistema que rodea ese código: cómo se recogen los datos, quién define los flujos, qué identificadores se usan, durante cuánto tiempo se conservan, qué usos posteriores se prevén y qué actores intervienen.

En LRX, los datos no eran simples dispensaciones farmacéuticas sueltas. El sistema permitía asociar operaciones a un mismo identificador y seguir en el tiempo el recorrido farmacológico de una persona. En EMR, tampoco se trataba de notas médicas aisladas: el almacén reunía diagnósticos, síntomas, alergias, medidas corporales, pruebas, vacunas, bajas laborales y prescripciones. Mirado dato a dato, el riesgo podía parecer menor. Mirado como conjunto, el sistema conservaba una capacidad mucho mayor de individualización, correlación e inferencia.

Por eso la posición de IQVIA resultaba decisiva. Según la CNIL, la compañía no era un destinatario externo que recibía una base ya cerrada y ajena a su control. Era quien había definido la finalidad de los almacenes, organizado los flujos, encargado módulos de extracción, fijado normas técnicas, seleccionado terceros de confianza y previsto usos posteriores para estudios. Esa posición impedía analizar la identificabilidad como si IQVIA solo apareciera al final de la cadena.

Aquí está el límite de la comparación con EDPS v SRB. En ese asunto, el Tribunal de Justicia examinaba la posición de un destinatario concreto de datos seudonimizados. En CNIL IQVIA, la autoridad francesa entiende que IQVIA ocupaba otro lugar: el de un actor situado en el centro del diseño y funcionamiento del tratamiento.

La conclusión no es que todo dato seudonimizado sea siempre identificable para cualquiera. La conclusión es más precisa: en un tratamiento de datos de salud a gran escala, con identificadores estables, seguimiento longitudinal, atributos ricos y varios actores técnicos, la seudonimización debe evaluarse dentro de la arquitectura completa. El código ayuda, pero no borra por sí solo lo que el sistema sigue permitiendo hacer.

En datos de salud, la pregunta no puede limitarse a si el nombre ha desaparecido. Hay que preguntar si, dentro de ese sistema concreto, la persona sigue siendo identificable mediante medios razonablemente susceptibles de ser utilizados.

8. La taxonomía del dato: no todos los datos pesan igual

El primer error al hablar de seudonimización es mirar solo si el dato contiene nombre, DNI, número de seguridad social o dirección. Esa mirada se queda corta. Un dato puede no identificar de forma directa y, aun así, mantener una capacidad relevante para hacer identificable a una persona cuando se combina con otros elementos.

En CNIL IQVIA, el problema no estaba solo en que los datos fueran de salud. Estaba en la combinación de varios rasgos: eran datos sensibles, ricos, contextuales y longitudinales. Esa mezcla cambia el análisis.

Un medicamento aislado puede decir poco. Una secuencia de medicamentos durante meses o años puede revelar mucho. Si a esa secuencia se añaden edad, sexo, zona geográfica, tipo de profesional sanitario, fecha de visita, diagnóstico, síntomas, alergias, pruebas o bajas laborales, el dato deja de ser una pieza suelta y empieza a formar una trayectoria.

La taxonomía del dato permite ver esa diferencia. No estamos ante datos administrativos simples. Estamos ante varias capas de información.

Hay datos observados, como dispensaciones, consultas, diagnósticos, síntomas, vacunas, pruebas o prescripciones. Hay datos contextuales, como el tipo de profesional, la zona geográfica, el momento de la atención o el entorno farmacia-consulta. Hay datos longitudinales, porque el sistema no mira un instante aislado, sino una evolución. Hay datos relacionales, porque conectan al paciente con farmacias, médicos, tratamientos, patologías y circuitos asistenciales. Y hay datos inferenciales, porque a partir del conjunto pueden deducirse situaciones que no aparecen escritas de forma directa: cronicidad, fragilidad, salud mental, fertilidad, tratamientos oncológicos, enfermedades raras, dependencia o discapacidad.

Esta última capa es decisiva. En privacidad, el dato más delicado no siempre es el que se recoge directamente. A veces es el que se puede deducir después.

Por eso, en IQVIA, el análisis no podía quedarse en comprobar si el nombre del paciente había sido sustituido por un identificador. La cuestión era qué capacidad identificadora e inferencial mantenía el conjunto una vez sustituido el nombre.

El dato de salud, cuando se combina con tiempo, contexto y repetición, no solo informa. Puede reconstruir.

9. De la taxonomía del dato a la taxonomía del riesgo

La taxonomía del riesgo nace de la taxonomía del dato. No hay riesgo en abstracto. Hay riesgo porque determinados datos, tratados en determinado contexto y con determinada arquitectura, permiten hacer ciertas cosas.

En IQVIA, la seudonimización reducía el riesgo de identificación directa, pero no eliminaba otros riesgos relevantes. La CNIL no reprocha simplemente que alguien pudiera encontrar un nombre. Su preocupación es más amplia: el sistema permitía aislar, seguir, relacionar e inferir.

El primer riesgo era la individualización. Aunque no se conozca el nombre de una persona, si el sistema permite distinguirla dentro de la base, ya existe un sujeto observable. Ese sujeto puede ser seguido, comparado y analizado. La persona queda convertida en una trayectoria.

El segundo riesgo era el seguimiento longitudinal. En LRX, el identificador permitía seguir dispensaciones de medicamentos asociadas a un mismo paciente. En EMR, el sistema permitía seguir episodios de atención dentro del entorno médico correspondiente. El paso del dato aislado a la secuencia es clave: una foto puede ser ambigua; una película revela patrones.

El tercer riesgo era la correlación. Cuando distintos registros se conectan entre sí, el sistema deja de almacenar eventos separados y empieza a construir un recorrido sanitario. Esa correlación puede ser interna, dentro del propio almacén, o externa, si se cruza con información disponible fuera del sistema.

El cuarto riesgo era la inferencia sensible. La combinación de medicamentos, fechas, síntomas, especialidades y zona geográfica puede permitir deducir enfermedades o situaciones personales que el dato no declara de forma expresa. Este riesgo es especialmente grave en salud, porque muchas inferencias pueden afectar a dignidad, intimidad, autonomía, vida familiar, expectativas profesionales o acceso futuro a servicios.

El quinto riesgo era la reidentificación por singularidad. No todas las personas son igualmente identificables en una base. Una enfermedad común, un tratamiento frecuente y una zona amplia pueden ofrecer cierto margen de ocultación. Una enfermedad rara, un medicamento muy específico, una edad concreta y una zona pequeña pueden estrechar mucho el círculo. La rareza convierte el rastro en señal.

El sexto riesgo era la pérdida de control. Este riesgo no depende solo de que alguien externo reidentifique al paciente. También aparece cuando la persona no sabe que sus datos se tratan, no comprende la arquitectura del tratamiento o no puede ejercer sus derechos de forma realista. En ese punto, el riesgo deja de ser solo técnico y se convierte en riesgo de gobernanza.

El séptimo riesgo era la opacidad estructural. Farmacias, médicos, editores de software, terceros de confianza, almacenes, autorizaciones, estudios posteriores y flujos diferenciados construyen una arquitectura difícil de entender incluso para un profesional. Para un paciente medio, el circuito resulta prácticamente invisible.

Esta lectura evita una confusión habitual. La pregunta no es solo si IQVIA podía o quería reidentificar a una persona concreta. La pregunta es si el sistema creaba condiciones razonables para que las personas quedaran individualizadas, perfiladas, inferidas o privadas de control sobre datos especialmente sensibles.

La visión pobre pregunta: “¿aparece el nombre?”. La visión madura pregunta: “¿qué puede hacerse con este rastro?”.

10. De la taxonomía del riesgo a la taxonomía del daño

El daño es el punto que devuelve el análisis a la persona. Sin esta tercera capa, la discusión sobre seudonimización corre el riesgo de quedarse en un debate técnico elegante, pero incompleto.

En IQVIA, el daño no debe imaginarse solo como el peor escenario: una filtración masiva con nombres y apellidos publicados en internet. Ese sería un daño evidente, pero no el único. En protección de datos, el daño puede empezar antes, cuando una persona pierde el control sobre una parte significativa de su vida.

El primer daño posible es el daño por exposición sanitaria. La persona queda representada en un almacén privado de datos de salud sin haber comprendido realmente que eso ocurría. Aunque el nombre no figure en claro, su historia sanitaria parcial queda disponible para análisis, estudios y reutilizaciones.

El segundo es el daño por pérdida de control. Si el paciente no recibe información efectiva, no sabe que sus datos han sido incorporados al sistema. Si el derecho de oposición exige aportar detalles muy precisos, como fecha, hora o contenido de una prescripción, el derecho existe en el papel, pero se debilita en la vida real. La persona no controla el dato porque ni siquiera puede localizar fácilmente la puerta de salida.

El tercer daño es el daño por inferencia sensible. Un conjunto de medicamentos puede revelar una enfermedad. Una secuencia de consultas puede sugerir un problema crónico. Una combinación de síntomas, pruebas y especialidades puede dejar ver una situación que la persona nunca quiso compartir fuera de la relación asistencial.

El cuarto es el daño por inferencia errónea. El dato no solo puede revelar demasiado; también puede ser mal interpretado. Una medicación puede tener varios usos. Una consulta no siempre confirma una patología. Una secuencia clínica parcial puede conducir a conclusiones equivocadas. Y una inferencia equivocada sobre salud puede ser tan lesiva como una verdadera.

El quinto es el daño por singularización social. En enfermedades raras o tratamientos muy específicos, la persona puede ser identificable dentro de una comunidad, una zona o un grupo reducido. No hace falta que el mundo entero sepa quién es. A veces basta con que pueda saberlo quien comparte su entorno laboral, familiar, sanitario o social.

El sexto es el daño por discriminación futura. Los datos de salud no solo afectan al presente. Pueden influir en seguros, empleo, crédito, relaciones comerciales, acceso a servicios o percepción social de la persona. Aunque el caso IQVIA no trate directamente de esas decisiones, la taxonomía del daño obliga a considerar qué podría ocurrir si trayectorias sanitarias se conectan con otros ecosistemas de decisión.

El séptimo es el daño por erosión de confianza. La farmacia y la consulta médica son espacios de necesidad. Una persona no acude a ellos como quien navega por una tienda en línea. Acude porque necesita atención, medicación, consejo o tratamiento. Si descubre que sus datos alimentan circuitos complejos que no comprendía, puede deteriorarse la confianza en el entorno sanitario.

Y hay un daño más profundo, más silencioso: el daño por reducción de la persona a materia informacional. El paciente deja de ser visto solo como alguien que recibe atención sanitaria y pasa a ser una fuente de señales, patrones, trayectorias y valor analítico. Esta transformación no siempre produce un perjuicio visible inmediato, pero altera la relación de poder entre la persona y quienes explotan su rastro.

La cadena puede formularse así:

dato sensible y longitudinal → riesgo de individualización, correlación e inferencia → posible daño por exposición, pérdida de control, discriminación o erosión de confianza.

La seudonimización debe evaluarse dentro de esa cadena. Si solo reduce una parte del riesgo, pero deja intactos otros caminos hacia la persona, no puede presentarse como una solución completa.

11. Seguridad: la seudonimización reduce riesgo, pero no sustituye el artículo 32 RGPD

La seudonimización también es una medida de seguridad. El propio artículo 32 RGPD la menciona, junto al cifrado, como una de las medidas que pueden contribuir a garantizar un nivel de seguridad adecuado al riesgo. Pero esa mención no debe leerse al revés. Que la seudonimización pueda formar parte de la seguridad no significa que baste, por sí sola, para asegurar un tratamiento.

Este punto es importante en CNIL IQVIA. La CNIL no niega que la seudonimización reduzca riesgos. Lo que rechaza es que pueda funcionar como una especie de escudo general frente a cualquier deficiencia de seguridad. Si los datos siguen siendo personales, y además son datos de salud tratados a gran escala, el sistema necesita medidas técnicas y organizativas coherentes con el riesgo residual.

La autoridad francesa examinó, en particular, varias capas de seguridad.

La primera fue la segmentación o compartimentación de red. En un tratamiento de esta naturaleza, no basta con que los usuarios tengan permisos diferenciados dentro de una aplicación. También importa dónde está situado el almacén de datos dentro de la arquitectura técnica. Si el entorno que aloja datos de salud se encuentra dentro de una red demasiado plana o demasiado accesible desde otros equipos internos, aumenta el riesgo de movimiento lateral: un atacante que compromete un puesto de trabajo puede intentar desplazarse hacia sistemas más críticos. Por eso, la segmentación de red no es una medida decorativa. Es una forma de reducir la superficie de ataque y de limitar el impacto de una intrusión.

La segunda fue la autenticación fuerte o multifactor. En datos de salud seudonimizados, el hecho de que no aparezca el nombre del paciente no elimina la necesidad de controlar de forma robusta quién entra al sistema. Si un usuario puede acceder solo con usuario y contraseña, el riesgo de acceso indebido aumenta, especialmente en entornos donde las credenciales pueden ser robadas, reutilizadas o comprometidas. La autenticación multifactor no elimina todos los riesgos, pero añade una barrera esencial: no basta con conocer una contraseña; hace falta un segundo factor de verificación.

La tercera fue la trazabilidad de accesos y operaciones. Registrar que alguien ha entrado en el sistema es necesario, pero puede ser insuficiente. En un almacén de datos de salud, la trazabilidad debe permitir saber quién accedió, cuándo, desde dónde, sobre qué conjunto de datos, qué consultas realizó, qué exportó o qué modificó. La seguridad no consiste solo en cerrar la puerta; también consiste en saber qué ocurre cuando alguien la cruza.

La cuarta fue el análisis regular de registros y la detección de comportamientos anómalos. Los registros que nadie revisa sirven de poco. La CNIL presta atención a si existen mecanismos para analizar las trazas, detectar accesos inusuales, consultas excesivas, patrones extraños, exportaciones anómalas o usos que no encajan con la función del usuario. En este punto, la diferencia entre “tener logs” y “gobernar los logs” es enorme. Lo primero acumula evidencia. Lo segundo permite reaccionar.

La quinta fue el principio de mínimo privilegio. No todas las personas que trabajan en una organización necesitan acceder a los mismos datos ni con la misma profundidad. En un entorno como IQVIA, la asignación de permisos debía estar conectada con funciones concretas, proyectos definidos, periodos limitados y revisiones periódicas. Cuanto más rico es el conjunto de datos, más importante es evitar accesos amplios por comodidad operativa.

La sexta fue la separación de entornos y funciones. Los datos de salud, los identificadores, los sistemas de extracción, los terceros de confianza, los entornos de análisis y los sistemas de administración no deberían mezclarse sin controles claros. La seudonimización exige separación del vínculo de atribución; la seguridad exige, además, separación de entornos, separación de funciones y separación de permisos.

La séptima fue la capacidad de prueba. En tratamientos de alto riesgo no basta con afirmar que existen controles. Hay que poder demostrarlo. Esto exige documentación técnica, evidencias de configuración, resultados de pruebas, registros de revisión, controles periódicos, alertas tratadas y decisiones de seguridad trazables. La seguridad, como la responsabilidad proactiva, se demuestra.

Estas medidas conectan directamente con la lógica del artículo 32 RGPD. El nivel de seguridad debe ser adecuado a la naturaleza, alcance, contexto y finalidad del tratamiento, así como a los riesgos para los derechos y libertades de las personas. En IQVIA, esos riesgos no eran menores: datos de salud, escala masiva, seguimiento longitudinal, posibilidad de inferencias sensibles y arquitectura con varios actores. La CNIL examinó expresamente la segmentación de red, la autenticación fuerte, la trazabilidad de acciones y el análisis de registros, y tomó nota de determinadas medidas correctoras adoptadas durante el procedimiento, como el traslado de almacenes a entornos más seguros, la autenticación multifactor y mejoras de trazabilidad.

Por eso, la seudonimización no podía ser la única respuesta. Reducía el riesgo de identificación directa, pero no eliminaba la necesidad de segmentar redes, reforzar la autenticación, limitar accesos, registrar operaciones, analizar trazas, detectar usos anómalos y revisar de forma continua la eficacia de las medidas.

La fórmula correcta sería esta: la seudonimización es una capa de seguridad, no la seguridad completa. En datos de salud, esa capa debe convivir con otras medidas. Si una falla, las demás deben limitar el daño. Esa es la lógica de defensa en profundidad que exige un tratamiento de esta sensibilidad.

12. No hay seudonimización madura sin taxonomía

La decisión IQVIA permite extraer una lección metodológica que va más allá del caso concreto. Una organización no debería afirmar que ha seudonimizado correctamente sin haber hecho antes tres ejercicios.

Primero, una taxonomía del dato: identificar no solo categorías jurídicas, sino la densidad real del conjunto. Qué datos son observados, cuáles son contextuales, cuáles permiten seguimiento, cuáles generan inferencias y cuáles pueden volverse singulares en combinación con otros.

Segundo, una taxonomía del riesgo: describir qué puede ocurrir con esos datos. No solo reidentificación final, sino individualización, correlación, inferencia, cruce externo, pérdida de control y opacidad.

Tercero, una taxonomía del daño: traducir esos riesgos a efectos sobre personas. Exposición, pérdida de control, inferencias sensibles o erróneas, discriminación, erosión de confianza, afectación a la autonomía y reducción de la persona a objeto de análisis.

Sin esos tres niveles, la seudonimización se convierte en una palabra tranquilizadora. Con esos tres niveles, se convierte en una medida que puede ser evaluada, discutida y mejorada.

En IQVIA, la CNIL no castiga la seudonimización. Castiga, en buena medida, la confianza excesiva en que la seudonimización bastaba para neutralizar lo que el conjunto de datos todavía permitía ver.

13. El papel de IQVIA: la etiqueta contractual no decide por sí sola

La CNIL dedica una parte importante de la decisión a explicar por qué IQVIA debía considerarse responsable del tratamiento. Este punto no es secundario. Es una de las columnas del caso.

IQVIA defendía que los farmacéuticos eran responsables de la transmisión inicial de los datos en LRX y que los médicos ocupaban una posición similar en EMR. Según esa tesis, IQVIA solo asumiría responsabilidad en fases posteriores, cuando los datos llegaban a determinados entornos técnicos.

La CNIL rechaza esa fragmentación. Su razonamiento es funcional: hay que mirar quién decide realmente las finalidades y los medios esenciales. En este caso, la autoridad considera que IQVIA definía la finalidad, los módulos, las normas técnicas, los flujos, los terceros de confianza y la arquitectura de constitución de los almacenes.

Esta lectura encaja con las Guidelines 07/2020 on the concepts of controller and processor in the GDPR del Comité Europeo de Protección de Datos: los roles no dependen de cómo las partes prefieran llamarse en un contrato, sino de las funciones reales que desempeñan. (EDPB)

La frase puede parecer dura, pero es la clave del caso: no es responsable quien mejor se coloca en el papel; es responsable quien decide el plan.

14. Qué se rompe cuando el rol se asigna mal

Asignar mal el rol no es un error administrativo. Es un fallo de gobernanza.

Si IQVIA se considera una receptora tardía, la información al paciente puede desplazarse hacia farmacias o médicos como si fueran los únicos obligados. Si se considera responsable desde el diseño del circuito, la conclusión cambia: debe garantizar que la información llegue efectivamente a las personas.

Lo mismo ocurre con los derechos. Un paciente que no sabe quién decide el tratamiento no sabe a quién dirigirse, quién puede registrar su oposición, quién puede bloquear usos futuros o quién puede explicar la lógica del sistema.

También se rompe la visión del riesgo. Un tratamiento único se trocea en pequeñas operaciones, y cada actor mira solo su tramo. Esa fragmentación puede ser cómoda para repartir contratos, pero es peligrosa para proteger personas.

La Tribunal Supremo, Sala de lo Contencioso-Administrativo, sentencia 772/2020, de 15 de junio, ROJ: STS 1562/2020, ECLI:ES:TS:2020:1562 —STS 772/2020— resulta útil como apoyo prudente. En un contexto distinto, el Tribunal Supremo sostuvo que una entidad responsable que contrata con otra la publicidad de sus productos debe adoptar cautelas razonables para garantizar la efectividad del derecho de oposición, sin quedar exonerada por las cláusulas del contrato celebrado con la otra entidad.

La conexión con IQVIA no exige forzar los hechos. La lección es sencilla: cuando el responsable organiza una actividad con terceros, no puede esconder los derechos de las personas detrás del contrato.

15. Artículo 25 RGPD: el dato que no debe salir debe quedarse dentro

Uno de los puntos más sólidos de la decisión es el artículo 25 RGPD. Aquí la CNIL no se limita a decir que IQVIA debió proteger mejor los datos. Dice algo más exigente: el sistema debió estar diseñado para que determinados datos no salieran desde el principio.

El problema era concreto. Los módulos integrados en programas de gestión de farmacia transmitían datos de pacientes al primer tercero de confianza incluso cuando la farmacia había optado por no participar en el panel LRX. IQVIA sostenía que el filtrado se hacía después. La CNIL responde que ese diseño no respeta la lógica de protección de datos desde el diseño y por defecto: si la farmacia no participa en LRX, los datos de sus pacientes no son necesarios para esa finalidad y no deben salir del software de farmacia. (cnil.fr)

Este punto merece quedarse en el centro del artículo. La seudonimización reduce el riesgo de datos que deben tratarse. No convierte en correcto el tratamiento de datos que nunca debieron circular.

La solución conforme al artículo 25 no era “extraer todo y filtrar después”. Era filtrar en origen. El módulo debía comprobar antes de generar el flujo si la farmacia participaba en LRX. La configuración por defecto debía ser restrictiva. Los flujos debían separarse por finalidad. Las altas y bajas de farmacias participantes debían tener reflejo técnico y trazable. Los proveedores de software debían recibir instrucciones claras de privacidad desde el diseño. Y IQVIA debía poder demostrar, con pruebas técnicas, que en farmacias no participantes no salían datos de pacientes para ese flujo.

Las directrices del Comité Europeo de Protección de Datos sobre el artículo 25 recuerdan que la protección de datos desde el diseño y por defecto exige integrar garantías adecuadas desde la planificación del tratamiento y durante todo su ciclo de vida, para hacer efectivos los principios del RGPD y proteger derechos y libertades. (EDPB)

Aquí puede utilizarse con prudencia Tribunal de Justicia de la Unión Europea, sentencia de 9 de enero de 2025, Mousse contra Commission nationale de l’informatique et des libertés y SNCF Connect, asunto C-394/23 —Mousse—. La sentencia se refiere a un supuesto distinto: la recogida obligatoria del término de cortesía “Señor” o “Señora” al comprar billetes de tren en línea. Su utilidad para IQVIA no es directa, sino conceptual: ayuda a recordar que la minimización exige preguntarse si un dato es realmente necesario para una finalidad concreta. (infocuria.curia.europa.eu)

En IQVIA, si la farmacia no participaba en LRX, el dato del paciente no debía salir para LRX. No debía salir seudonimizado. No debía salir para ser filtrado después. Debía quedarse dentro.

16. Cuando ejercer un derecho se parece demasiado a resolver un acertijo

La CNIL también reprocha a IQVIA la falta de efectividad práctica del derecho de oposición en EMR.

La dificultad es fácil de entender. Los pacientes podían oponerse antes de que sus datos alimentaran el almacén. Pero, si los datos ya estaban incorporados, la oposición dependía de que el paciente aportara información muy precisa, como fecha y hora de consulta o contenido de la prescripción. Además, esa información solo permitía actuar si conducía a un único registro.

Esto revela una tensión frecuente en sistemas seudonimizados. El responsable puede decir que no identifica directamente al paciente y que por eso no puede atender fácilmente sus derechos. Pero si ese mismo responsable diseñó el sistema, la respuesta no puede ser tan cómoda.

La CNIL no cuestiona que el derecho existiera formalmente en la documentación. Lo que cuestiona es su efectividad real. Una cosa es declarar que el paciente puede oponerse. Otra es diseñar un procedimiento que pueda ser utilizado sin convertir al paciente en investigador de su propio rastro clínico.

Una seudonimización madura debe proteger la identidad sin convertir los derechos en una búsqueda del tesoro. Si el sistema hace casi imposible ejercer el derecho de oposición, el problema no está en el paciente. Está en el diseño.

17. El ejemplo de Anne: por qué el secreto de seudonimización importa

ENISA ofrece un caso sencillo que ayuda a explicar lo que está en juego. Una paciente, Anne, realiza pruebas en un laboratorio. El laboratorio usa un Patient_ID para asociar los resultados médicos sin utilizar directamente sus datos identificativos. Mientras la asociación entre Anne y ese Patient_ID esté separada y protegida, la seudonimización reduce el riesgo. Pero si el médico recibe también la asociación, accede al secreto de seudonimización y puede identificar directamente a Anne.

El ejemplo muestra que el problema no está solo en el código. Está en quién conoce el vínculo, quién puede reconstruirlo, qué información se combina y qué papel ocupa cada actor.

En IQVIA, esa pregunta se vuelve mucho más compleja. No hablamos de un resultado de laboratorio aislado. Hablamos de almacenes de datos de salud, seguimiento longitudinal, terceros de confianza, módulos de extracción, estudios posteriores y millones de personas potencialmente afectadas.

18. Qué aporta CNIL IQVIA

La decisión aporta una lección de madurez. No dice que la seudonimización no sirva. Dice que no debe usarse como una palabra tranquilizadora cuando el sistema sigue permitiendo ver demasiado.

Aporta, al menos, cinco ideas.

La primera es que la seudonimización no equivale a anonimización. La segunda, que la identificabilidad depende del contexto, pero ese contexto incluye la posición real del actor. La tercera, que los datos de salud longitudinales tienen una fuerza identificadora propia. La cuarta, que los derechos deben funcionar en la práctica, no solo existir en un aviso informativo. La quinta, que la protección desde el diseño empieza antes de que el dato salga.

La secuencia jurisprudencial ayuda a ordenar el razonamiento. Breyer enseña a mirar los medios razonablemente susceptibles de ser utilizados. Scania muestra, como analogía útil, que un identificador técnico puede ser personal si permite vincularlo razonablemente con una persona. EDPS v SRB aplica esa sensibilidad a datos seudonimizados y a la posición del destinatario, pero de forma casuística y sin crear una exclusión general del RGPD. CNIL IQVIA añade el límite: quien, según la autoridad de control, diseña el sistema no puede presentarse como si solo recibiera datos ya cerrados e inaccesibles.

19. Una prueba práctica para no engañarse con la seudonimización

El caso permite formular una prueba sencilla, útil para futuros tratamientos de salud, investigación, analítica o inteligencia artificial.

Antes de decir que un tratamiento está “bien seudonimizado”, habría que preguntarse si el conjunto permite aislar a una persona, seguirla en el tiempo, enlazar episodios, deducir información sensible o hacerla identificable con ayuda de fuentes externas. También habría que preguntarse quién controla el secreto de seudonimización, quién decide la política de códigos, quién puede acceder a los datos, cómo se registran las operaciones, qué ocurre si alguien se opone y si los datos que circulan son realmente necesarios.

La seudonimización debe pasar una prueba jurídica, técnica y humana. Técnica, porque la medida debe ser robusta. Jurídica, porque no puede sustituir obligaciones de licitud, información, minimización, seguridad o derechos. Humana, porque al final lo que está en juego no es una tabla, sino una persona cuya historia de salud puede seguir siendo identificable mediante medios razonablemente susceptibles de ser utilizados en el contexto del tratamiento.

20. Conclusión

La seudonimización es una buena herramienta. En muchos tratamientos, especialmente en salud, resulta indispensable. Pero no debe convertirse en una forma cómoda de mirar hacia otro lado.

CNIL IQVIA recuerda que un dato puede dejar de llevar nombre y seguir manteniendo capacidad identificadora e inferencial. Puede hacerlo por su riqueza, por su contexto, por su secuencia temporal, por los medios razonablemente susceptibles de ser utilizados o por el papel que ocupa quien gobierna el sistema.

La falsa tranquilidad del dato seudonimizado aparece cuando creemos que el código ha resuelto todo. No es así. El código puede reducir el riesgo, pero no borra por sí solo la posibilidad de atribución razonable en un contexto concreto.

La lección más importante no está en desconfiar de la seudonimización. Está en tomarla en serio. Si se toma en serio, hay que diseñarla bien, limitar lo que se recoge, impedir que salgan datos innecesarios, asignar correctamente los roles, garantizar derechos reales, aplicar controles de seguridad en capas y evaluar daños posibles para personas reales.

En IQVIA, el problema no era solo que hubiera códigos. Era que, según la CNIL, detrás de esos códigos seguían existiendo pacientes identificables mediante medios razonablemente susceptibles de ser utilizados en el ecosistema del tratamiento.

Bibliografía y fuentes de referencias