Hashing y seudonimización: qué enviar a un LLM
Distingue eliminación, agregación, hashing y seudonimización al preparar datos para un LLM. Elige el contexto mínimo y controla claves, destinos y registros.
Aplicar un hash a un correo no convierte automáticamente los datos en anónimos. Si el identificador sigue permitiendo enlazar registros o comprobar candidatos, puede conservar riesgos de identificación. Antes de transformar un campo, decide si la tarea necesita ese campo.
Cuatro opciones para reducir el contexto
| Necesidad | Opción de diseño | Límite que revisar |
|---|---|---|
| El identificador no aporta nada | Eliminarlo | Otros campos pueden identificar indirectamente |
| Solo hacen falta totales | Agregar | Grupos pequeños pueden revelar individuos |
| Hace falta enlazar eventos | Token o identificador seudónimo | Protege la tabla de correspondencias |
| Hace falta un identificador estable derivado | HMAC con clave protegida | Define alcance, rotación y acceso a la clave |
Son opciones que deben validarse contra el caso de uso y el riesgo. No son una garantía de anonimato o cumplimiento legal.
Ejemplo: margen frente a recurrencia
Para explicar el margen de un canal, basta con periodo, moneda, ingresos y coste. El modelo no necesita un identificador de cliente.
Para estudiar compras repetidas, puede hacer falta distinguir registros del mismo cliente. Un identificador seudónimo permite mantener esa relación sin incluir el correo en el contexto. Mantén los campos de identidad y la capacidad de resolver la correspondencia fuera del modelo.
Hash simple y HMAC
Un hash determinista de un correo puede compararse con hashes de correos candidatos. Añadir una clave secreta cambia ese diseño: HMAC utiliza una clave además de la función hash. La referencia de NIST sobre HMAC describe esa construcción criptográfica; su uso no convierte por sí solo un conjunto de datos en anónimo.
No incluyas la clave en el prompt ni en los logs. Define si los identificadores deben ser estables entre periodos, sistemas o clientes. Un alcance demasiado amplio puede facilitar vínculos innecesarios. La rotación también necesita un plan si hay relaciones históricas que conservar.
Comprueba los datos indirectos
Un cargo poco frecuente, una fecha exacta o una combinación de localización y compra puede identificar a una persona sin su nombre. La guía de seudonimización del ICO distingue estas transformaciones de la anonimización. Evalúa los datos completos y el acceso a información adicional.
Aplica el mismo criterio a logs, exportaciones y cachés. Revisa además las condiciones de retención y uso del proveedor de modelos para el servicio concreto.
Un diseño comprobable
Para cada pregunta, documenta campos necesarios, transformación, permisos y destino. Prueba qué recibe realmente el modelo. La capa semántica puede servir como punto de definición; la autorización antes del prompt debe impedir que la minimización se eluda solicitando otro campo o herramienta.