La definición legal: artículo 4.1 del RGPD
El RGPD establece deliberadamente un alcance muy amplio. El artículo 4.1 define los datos personales como:
«Toda información sobre una persona física identificada o identificable ("el interesado"); se considerará persona física identificable toda persona cuya identidad pueda determinarse, directa o indirectamente, en particular mediante un identificador, como por ejemplo un nombre, un número de identificación, datos de localización, un identificador en línea o uno o varios elementos propios de la identidad física, fisiológica, genética, psíquica, económica, cultural o social de dicha persona».
Artículo 4.1, Reglamento (UE) 2016/679
Cuatro elementos hacen que esta definición funcione, y cada uno de ellos importa a la hora de clasificar los datos en toda tu organización:
- «Toda información»: sin límite de formato. Texto, números, fotos, grabaciones de audio, plantillas biométricas, metadatos y patrones de comportamiento, todos cuentan.
- «Sobre»: la información debe referirse a la persona, ya sea por su contenido (la describe), por su finalidad (se utiliza para evaluarla) o por su resultado (su tratamiento la afecta).
- «Identificada o identificable»: no es necesario que la persona aparezca nombrada. Si puedes individualizarla combinando datos, es suficiente.
- «Persona física»: el RGPD protege a las personas vivas, no a las empresas. Pero los datos sobre un autónomo o un empleado identificado por su nombre son datos personales.
La consecuencia práctica: si existe una posibilidad razonable de que alguien (no solo tú, sino cualquier parte con acceso) pueda vincular los datos con una persona, se trata de datos personales según el RGPD. Por eso los errores de clasificación se propagan en cascada por todo tu programa de cumplimiento.
Ejemplos reales: qué cuenta y qué no
La frontera entre datos personales y datos no personales es menos evidente de lo que la mayoría de las organizaciones suponen. Así se clasifican los tipos de datos habituales según el RGPD, conforme a las directrices regulatorias y la jurisprudencia del TJUE:
| Tipo de dato | ¿Dato personal? | Por qué |
|---|---|---|
| Nombre completo | Sí | Identifica directamente a una persona |
| Correo: [email protected] | Sí | Identifica a una persona física por su nombre |
| Correo: [email protected] | No | Dirección genérica, sin persona identificable |
| Dirección IP dinámica | Sí | Sentencia Breyer del TJUE (C-582/14): identificable con los registros del proveedor de internet |
| ID de cookie / huella del dispositivo | Sí | Identificador en línea según el considerando 30; individualiza a un usuario |
| Número de identificación de empleado | Sí | Número de identificación vinculado a una persona concreta |
| Datos de localización GPS | Sí | Rastrea los movimientos de una persona; identificador de localización |
| Datos salariales vinculados al puesto | Sí | Combinados con el departamento o el puesto, identifican a la persona |
| Resultados de encuestas anonimizadas | Depende | Solo son no personales si la reidentificación no es razonablemente posible |
| Registros de clientes seudonimizados | Sí | La reidentificación es posible con la clave conservada por separado |
| Imágenes de videovigilancia | Sí | Imágenes de personas identificables |
| Estadísticas agregadas (gran conjunto de datos) | No | Solo si no se puede individualizar a las personas a partir del agregado |
| Resultados de pruebas genéticas | Sí (categoría especial) | Categoría especial del artículo 9: datos genéticos |
| Afiliación sindical | Sí (categoría especial) | Categoría especial del artículo 9: enumerada de forma explícita |
La trampa del «efecto mosaico»
Muchas organizaciones clasifican datos individuales de forma aislada (un número de empleado aquí, un código de departamento allí) y concluyen que no son datos personales. Pero el RGPD analiza la identificabilidad mediante la combinación. Cuando tu sistema de RR. HH., tu plataforma de nóminas y tus registros de control de accesos pueden cruzarse, los datos que parecen anónimos en un sistema se convierten en datos personales en el conjunto. Esta es exactamente la brecha que el mapeo de datos entre entidades está diseñado para cerrar.
Categorías especiales: los datos del artículo 9 requieren protección adicional
El RGPD trata determinados tipos de datos personales como intrínsecamente de alto riesgo. El artículo 9 prohíbe el tratamiento de estas categorías salvo que se aplique una excepción legal concreta, y las sanciones por equivocarse son proporcionalmente más altas.
Las categorías especiales son:
- Origen racial o étnico: incluye los campos de nacionalidad en los sistemas de RR. HH. si revelan el origen étnico
- Opiniones políticas: donaciones a partidos políticos, datos del censo electoral
- Convicciones religiosas o filosóficas: campos de preferencias dietéticas que revelan la religión (p. ej., «halal» o «kosher» en sistemas de catering)
- Afiliación sindical: deducciones en nómina por cuotas sindicales
- Datos genéticos: resultados de pruebas de ADN, información hereditaria
- Datos biométricos (cuando se utilizan para identificación): escaneos de huellas dactilares, plantillas de reconocimiento facial. Nota: los datos biométricos utilizados para autenticación (desbloquear un teléfono) pueden no activar el artículo 9 en todas las interpretaciones, pero los registros de acceso por huella dactilar sin duda lo hacen
- Datos de salud: registros de bajas por enfermedad, ajustes por discapacidad, evaluaciones de salud laboral, reclamaciones a seguros. Esta es la categoría que con más frecuencia se clasifica mal en entornos empresariales
- Vida sexual u orientación sexual: campos de seguimiento de diversidad en RR. HH., designaciones de beneficiarios que revelan el género de la pareja
Dónde se atascan las organizaciones multientidad
El fallo más común que observamos en las organizaciones que gestionan la privacidad en varias filiales: la incoherencia en la clasificación de los datos de salud. Un registro de baja por enfermedad se clasifica como «datos estándar de RR. HH.» en una filial y como «datos de salud del artículo 9» en otra. Cuando una autoridad de control audita al grupo, la propia incoherencia se convierte en prueba de una gobernanza inadecuada. Por eso una taxonomía de datos unificada en todas las entidades no es opcional: es la base de un cumplimiento defendible.
Bases jurídicas para el tratamiento de categorías especiales
El tratamiento de datos de categorías especiales requiere tanto una base jurídica conforme al artículo 6 como una excepción aparte conforme al artículo 9.2. Las excepciones más habituales incluyen:
- Consentimiento explícito (artículo 9.2.a): debe ser libre, específico, informado e inequívoco. El consentimiento implícito nunca es suficiente.
- Obligaciones del Derecho laboral (artículo 9.2.b): tratamiento necesario para el cumplimiento de obligaciones en el ámbito del Derecho laboral y de la seguridad social
- Intereses vitales (artículo 9.2.c): situaciones médicas de emergencia en las que el interesado no puede consentir
- Interés público esencial (artículo 9.2.g): debe ser proporcional y contar con garantías
Datos seudonimizados vs. anonimizados: la distinción crítica
Aquí es donde más programas de cumplimiento se equivocan que en casi cualquier otro punto. La distinción determina si el RGPD se aplica en absoluto, y la línea es mucho menos clara de lo que la mayoría de las organizaciones suponen.
Datos seudonimizados = siguen siendo datos personales
La seudonimización sustituye los identificadores directos por otros artificiales (tokens, códigos, hashes) y mantiene la clave de reidentificación por separado. El RGPD define explícitamente la seudonimización en el artículo 4.5 y trata los datos seudonimizados como datos personales en todo momento.
¿Por qué? Porque la reidentificación es posible. La clave existe en algún lugar. Mientras cualquier parte (tú, un encargado del tratamiento, un destinatario de los datos o un atacante con un esfuerzo razonable) pueda reconectar el seudónimo con la persona, sigue siendo un dato personal sujeto a todas las obligaciones del RGPD.
La seudonimización es una medida de seguridad, no una excepción. Puede reducir el riesgo (y el RGPD la reconoce como garantía en los artículos 25 y 32), pero no excluye los datos del ámbito del RGPD.
Datos anonimizados = fuera del ámbito del RGPD
Los datos verdaderamente anonimizados (en los que la reidentificación es irreversible y no es razonablemente posible por ninguna parte mediante ningún medio que razonablemente pueda emplearse) quedan totalmente fuera del RGPD (considerando 26).
La prueba es rigurosa: debes tener en cuenta todos los medios «que razonablemente puedan emplearse» para la reidentificación, incluidos los avances tecnológicos futuros, el coste de la reidentificación y la disponibilidad de conjuntos de datos complementarios. El Comité Europeo de Protección de Datos (CEPD) ha fijado un listón alto, y las autoridades de control han constatado de forma reiterada que conjuntos de datos que las organizaciones creían anónimos eran, en realidad, seudónimos.
Implicación práctica para tu registro de tratamientos
Si tu registro de actividades de tratamiento excluye conjuntos de datos partiendo de que están «anonimizados», verifica ese supuesto con una evaluación documentada del riesgo de reidentificación. Si te equivocas, esos conjuntos de datos deberían haber estado en tu registro de tratamientos desde el principio, y cada actividad de tratamiento que los implique ha quedado sin documentar. La gestión del registro de tratamientos de Priverion incluye flujos de trabajo de clasificación de datos que detectan exactamente este tipo de brechas en todas las entidades del grupo.
Datos de condenas penales: artículo 10
Los datos relativos a condenas e infracciones penales tienen su propia regla en el artículo 10. No son una categoría especial del artículo 9, pero su tratamiento se limita a la autoridad oficial o a los casos autorizados por el Derecho de la UE o de los Estados miembros con garantías adecuadas.
Para los empleadores: las verificaciones de antecedentes, la divulgación de antecedentes penales e incluso la anotación de que un empleado carece de antecedentes entran dentro del artículo 10. Si tus filiales en distintas jurisdicciones gestionan la selección previa al empleo de forma diferente, el tratamiento incoherente de los datos del artículo 10 es un hallazgo de auditoría habitual.
Datos de menores: protecciones reforzadas conforme al artículo 8
Cuando se tratan datos personales de menores sobre la base del consentimiento para servicios de la sociedad de la información, el RGPD exige el consentimiento parental para los menores de 16 años (aunque los Estados miembros pueden rebajarlo a los 13). El responsable del tratamiento debe hacer esfuerzos razonables para verificar que el consentimiento lo otorga el titular de la patria potestad.
Si tu organización trata datos de menores (plataformas educativas, programas de prestaciones familiares, servicios para jóvenes), esto añade una capa de clasificación que tu mapeo de datos debe reflejar.
Mapear datos personales en una organización multientidad
Comprender la definición es el punto de partida. El verdadero reto para las organizaciones con varias filiales es aplicar esa definición de forma coherente en cada entidad, cada sistema y cada jurisdicción.
Este es el proceso que funciona, y lo que hemos visto fracasar:
Lo que funciona: taxonomía centralizada, ejecución distribuida
- Establece una taxonomía de clasificación de datos para todo el grupo: define las categorías de datos personales de forma idéntica en todas las entidades. «Datos de salud» significa lo mismo en tu filial suiza y en la alemana.
- Mapea las actividades de tratamiento a nivel de entidad: cada filial documenta sus propias actividades de tratamiento utilizando la taxonomía compartida. Esto garantiza la precisión local con coherencia en todo el grupo.
- Identifica los flujos de datos entre entidades: cuando los datos personales se desplazan entre filiales o hacia terceros, mapea esos flujos de forma explícita. Las transferencias dentro del grupo siguen requiriendo una base jurídica.
- Automatiza la recertificación: cuando una clasificación cambia (p. ej., se añade un nuevo tipo de dato a los sistemas de RR. HH.), ese cambio debe propagarse al registro de tratamientos de cada entidad. Las cadenas de correos manuales no escalan.
- Revisa y audita con regularidad: la clasificación de datos no es un ejercicio puntual. Los nuevos sistemas, los nuevos proveedores y las directrices regulatorias cambian lo que se considera dato personal.
Lo que fracasa: clasificación descentralizada sin supervisión
Cuando cada filial define los datos personales de forma independiente (o cuando el DPD del grupo no tiene visibilidad sobre las clasificaciones a nivel de filial), las incoherencias se acumulan en silencio. La filial alemana clasifica las preferencias dietéticas como datos de salud (correcto según muchas interpretaciones de las autoridades de protección de datos). La filial del Reino Unido clasifica el mismo campo como «datos estándar de empleado». El registro de tratamientos parece completo en ambas entidades, pero la postura de cumplimiento del grupo tiene una brecha que cualquier auditoría transfronteriza detectará.
Este es exactamente el problema que llevó a la fundación de Priverion: una empresa con 12 filiales que gestionaba el cumplimiento del RGPD en 47 hojas de cálculo, sin una forma coherente de garantizar que los mismos datos se clasificaran de la misma manera en todas partes.
