¿Cuándo Es un Hash un Dato Personal? La Sentencia SRB del TJUE y la Identidad en Analítica

La pregunta que todo proveedor de analítica esquiva es fácil de plantear y difícil de responder: ¿es el identificador de tu base de datos un dato personal? El 4 de septiembre de 2025 el TJUE dio la respuesta más relevante en años, y replanteó toda la prueba en torno al contexto, no al dato aislado.

Qué decidió realmente EDPS v SRB

El caso —EDPS v SRB, C-413/23 P— surgió de la resolución del Banco Popular. La Junta Única de Resolución recopiló comentarios de accionistas, sustituyó la identidad de cada autor por un código alfanumérico y envió los comentarios codificados a Deloitte como evaluador independiente. Deloitte no tenía clave para revertir los códigos ni ninguna otra vía hasta los autores.

El TJUE sostuvo que los datos seudonimizados no son automáticamente datos personales para toda parte que los maneja. Si un conjunto de datos es personal se evalúa en relación con quien lo posee: desde la posición del destinatario concreto, considerando los medios técnicos, organizativos y jurídicos realmente disponibles para él.

Esta es la prueba de la identificabilidad relativa (o contextual), y es la lectura operativa de los "medios que razonablemente puedan ser utilizados" del Considerando 26. Un dato que es personal en manos del responsable puede ser no personal en manos de un destinatario que genuinamente no puede reidentificar a nadie.

La tensión con el EDPB

El tribunal no dio vía libre a los proveedores. Las Directrices 01/2025 del EDPB sobre seudonimización adoptan una línea deliberadamente más estricta: los datos seudonimizados siguen siendo datos personales mientras cualquiera —el responsable o algún tercero— conserve los medios para reidentificar. El informe del EDPB de febrero de 2026 sobre anonimización y seudonimización es el consejo trabajando precisamente sobre esa brecha entre su posición y la del tribunal.

Para quien desarrolla, la lectura práctica es conservadora. No asumas que un valor con hash queda fuera del ámbito del RGPD solo porque tu servicio no puede revertirlo. La pregunta correcta es si la reidentificación es razonablemente probable para quien posea la información adicional, y si esa información adicional todavía existe.

Por qué la mayoría de los hashes de analítica fallan la prueba

Aplicar hash a un identificador no es anonimización. Un SHA-256 de una dirección de correo es determinista: el mismo correo siempre produce el mismo digest. Quien tenga una lista de correos candidatos puede aplicarles hash y cruzarlos. El hash es una clave estable y enlazable: seudonimización en el mejor caso, y dato personal bajo cualquier lectura, porque los medios para reidentificar están trivialmente disponibles.

La misma trampa atrapa a una IP con hash, un ID de dispositivo con hash o cualquier digest de una entrada tomada de un espacio pequeño y enumerable. Determinismo más entrada adivinable es igual a reidentificación. La función de hash cambia los bytes, no la enlazabilidad.

Qué hace que un hash sea realmente defendible

Dos propiedades mueven un hash de "dato personal seudonimizado" hacia "no razonablemente reidentificable": un salt secreto que nunca se almacena junto al dato, y una entrada que no puede adivinarse de forma exhaustiva y no persiste en el tiempo. El modelo de identidad de Monoid se construye exactamente sobre eso:

SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)

La IP y el User-Agent en bruto viven solo en la memoria del Worker el tiempo necesario para computar el digest; D1 almacena el hash, nunca las entradas. El SALT_SECRET se guarda en el servidor y nunca se escribe junto al dato, así que un ataque de rainbow table o de fuerza bruta contra los hashes almacenados no tiene ancla. Y como la fecha es una entrada, el digest del mismo visitante rota cada medianoche UTC. No hay clave estable entre días con la que correlacionar.

Pasa esa construcción por ambas pruebas. Bajo el estándar relativo del TJUE, ningún destinatario de los hashes almacenados —incluido Monoid consultando su propia D1— posee los medios razonablemente susceptibles de reidentificar, porque el salt está segregado y la entrada no es enumerable. Bajo el estándar más estricto del "cualquiera" del EDPB, la información adicional necesaria (IP en bruto más UA más el salt secreto de esa fecha concreta) no se retiene en ningún sitio una vez completada la solicitud. Los medios para reidentificar no solo están restringidos: dejan de existir.

Cómo auditar tu propia stack

La sentencia te da una lista concreta para aplicar a cualquier analítica de la que dependas:

• ¿Es enumerable la entrada con hash? Un correo, un teléfono o una IP en bruto pueden someterse a hash y cruzarse con una lista de candidatos. Si el espacio de entrada es pequeño, el hash es reversible en la práctica.
• ¿Hay un salt secreto segregado del dato almacenado? Un hash sin salt, o con el salt en el mismo repositorio, no ofrece barrera real a la reidentificación.
• ¿Persiste el identificador entre sesiones? Una clave estable que enlaza la actividad de una persona durante semanas es dato personal bajo cualquier lectura. Una clave que rota a diario no puede acumular un perfil.

El TJUE no declaró la seudonimización un puerto seguro, y el EDPB se asegura de que nadie la lea así. La posición duradera es la que no necesita ninguna interpretación para ganar: un hash con salt, rotado a diario, sobre una entrada no enumerable no es razonablemente reidentificable por nadie, porque el material necesario para revertirlo nunca se guardó.

Fuentes

• Sentencia del TJUE en el asunto C-413/23 P, SEPD contra JUR (4 de septiembre de 2025)
• Directrices 01/2025 del EDPB sobre seudonimización
• Informe del EDPB sobre el evento con partes interesadas sobre anonimización y seudonimización del 12 de diciembre de 2025
• Considerando 26 del RGPD — No aplicable a datos anónimos