Anonimización de datos: qué exige el RGPD y cómo usar IA sin exponer a tus clientes

La anonimización de datos es la conversación que casi todo el mundo se salta y casi todo el mundo acaba teniendo. Aparece el día que alguien quiere entrenar un modelo con el histórico de clientes, o mandar un extracto de la base de datos a un proveedor, o dejar que un equipo de analítica trabaje con datos reales. Y entonces surge la pregunta incómoda: ¿esto se puede hacer? La respuesta depende de una distinción técnica y jurídica que se confunde constantemente, y confundirla sale caro: la mayoría de lo que las empresas llaman «datos anonimizados» son, en realidad, datos personales seudonimizados y sujetos al RGPD de arriba abajo.

Esta guía separa las dos cosas, explica qué técnicas existen de verdad, y baja al terreno de lo que hay que hacer antes de meter datos de clientes en cualquier sistema de IA. Sin humo y sin la fantasía de que un `REPLACE` sobre la columna del nombre resuelve algo.

¿Qué es la anonimización de datos y en qué se diferencia de la seudonimización?

Un dato está anonimizado cuando ya no permite identificar a una persona por ningún medio razonablemente disponible, ni ahora ni cruzándolo con otra información. En el momento en que eso se cumple, deja de ser dato personal y sale del ámbito del RGPD. Es una puerta de un solo sentido: bien hecha, no hay vuelta atrás.

Un dato está seudonimizado cuando se ha sustituido el identificador directo por otro valor —un código, un token, un hash— pero existe en algún sitio la información que permite deshacer esa sustitución. Sigue siendo dato personal. Sigue estando sujeto al reglamento entero: base jurídica, derechos del interesado, notificación de brechas, transferencias internacionales, todo.

La confusión práctica es esta: casi todas las herramientas comerciales que dicen «anonymization» hacen seudonimización. Y casi todos los proyectos internos que sustituyen el DNI por un identificador incremental creen haber anonimizado cuando solo han movido el problema a la tabla de correspondencias.

| | Anonimización | Seudonimización | |---|---|---| | ¿Reversible? | No, por diseño | Sí, con la clave o tabla de equivalencias | | ¿Sigue siendo dato personal? | No | Sí | | ¿Aplica el RGPD? | No | Sí, íntegro | | Uso típico | Publicación, estadística, cesión abierta | Trabajo interno, entornos de test, minimizar riesgo | | Riesgo principal | Pérdida de utilidad analítica | Reidentificación si se filtra la clave | | Coste de hacerlo bien | Alto | Medio |

Si puedes recuperar quién era esa persona, no has anonimizado. Has reducido el riesgo, que también vale, pero el RGPD te sigue mirando.

Esta distinción no es académica. Determina si necesitas base jurídica para tratar esos datos, si puedes mandarlos a un tercero, si un incidente es una brecha notificable y si puedes usarlos para un fin distinto del original.

¿Cuándo exige el RGPD cada una?

El reglamento no dice «anonimiza aquí, seudonimiza allá». Lo que hace es dejar la anonimización fuera de su ámbito (Considerando 26) y convertir la seudonimización en una medida de seguridad y de minimización recomendada (artículos 25 y 32). De ahí se deducen reglas prácticas bastante claras.

Necesitas anonimización real cuando:

• Vas a publicar el conjunto de datos o cederlo sin contrato de tratamiento detrás.
• Quieres usar los datos para un fin nuevo que no encaja con la finalidad original y no tienes base para ampliarla.
• Quieres conservar información más allá del plazo de retención que tienes definido. Anonimizar es la alternativa legítima a borrar.
• Vas a entrenar un modelo cuyos parámetros van a salir de tu control y podrían memorizar ejemplos.

Te basta con seudonimización cuando:

• El tratamiento es interno, tienes base jurídica y la finalidad no cambia.
• Estás poblando un entorno de desarrollo o pruebas y necesitas datos con forma realista.
• Trabajas con un encargado de tratamiento bajo contrato del artículo 28 y quieres reducir la superficie de exposición.
• Necesitas poder responder a un derecho de supresión o de acceso, que con datos anonimizados es imposible por definición.

Ese último punto se olvida mucho. Si anonimizas de verdad, pierdes la capacidad de atender los derechos del interesado sobre ese conjunto. No es un fallo: es la consecuencia lógica. Pero conviene decidirlo, no descubrirlo.

¿Qué técnicas de anonimización existen y cuál elegir?

Aquí es donde la mayoría de guías se quedan en la lista de nombres. Lo útil es saber qué protege cada técnica y qué te cuesta en utilidad del dato.

Supresión. Borrar la columna. Es la técnica más infravalorada y la más eficaz. Antes de discutir algoritmos, pregunta si de verdad necesitas el campo. En la mayoría de proyectos de analítica, el nombre y el correo no aportan nada al modelo.

Generalización. Sustituir un valor preciso por un rango o una categoría: la fecha de nacimiento por el tramo de edad, el código postal por la provincia, el importe exacto por un intervalo. Reduce la granularidad y con ella la capacidad de señalar a una persona concreta.

Enmascaramiento y tokenización. Reemplazar el valor por otro con el mismo formato. Un DNI que sigue pareciendo un DNI, un IBAN que valida. Sirve para entornos de test donde el software necesita formatos válidos. Ojo: si el token es determinista y reversible, esto es seudonimización.

Perturbación y ruido. Alterar valores numéricos de forma controlada para que las agregaciones sigan siendo válidas pero ningún registro individual sea exacto. Útil en datos de facturación, consumo o métricas de uso.

Agregación. No publicar registros, sino sumas y medias por grupo. Con un tamaño mínimo de grupo bien definido, es de lo más robusto que hay.

Privacidad diferencial. El enfoque más sólido teóricamente: añade ruido calibrado de forma que se pueda demostrar matemáticamente cuánto revela cada consulta sobre un individuo. Es la respuesta correcta para conjuntos que se van a consultar muchas veces, y también la más costosa de implantar bien. No la propongas si no tienes a alguien capaz de razonar sobre el presupuesto de privacidad.

Datos sintéticos. Generar registros nuevos que reproducen la distribución estadística del original sin corresponder a personas reales. Ha mejorado mucho y es una opción real para desarrollo y demos. La trampa: un generador entrenado con pocos datos puede reproducir casi literalmente registros del original. Hay que verificarlo, no asumirlo.

La regla de selección es sencilla: empieza por suprimir lo que no necesitas, generaliza lo que puedas, y solo después discute técnicas avanzadas sobre lo que quede.

¿Por qué falla la anonimización que parece suficiente?

Porque la identificación casi nunca viene del campo obvio. Viene de la combinación. A esto se le llama cuasi-identificadores: campos que por sí solos no dicen quién eres, pero juntos sí. Código postal, fecha de nacimiento y sexo son el ejemplo clásico; con esos tres campos se identifica a un porcentaje enorme de la población de cualquier país.

Los fallos que vemos una y otra vez:

• Se limpia la columna del nombre y se deja todo lo demás. El historial de pedidos de un cliente con fechas, importes y ubicación es una huella tan única como su DNI.
• Se hashea sin sal. Un hash de un DNI o de un correo es trivial de revertir por fuerza bruta: el espacio de posibles valores es pequeño y conocido. Un hash sin sal secreta no anonimiza nada.
• Se anonimiza el conjunto pero no los adjuntos. El CSV está impecable y en la carpeta de al lado están los PDF originales con el nombre en la cabecera.
• Se ignora el campo de texto libre. Las observaciones, las notas del comercial y los tickets de soporte están llenos de nombres, teléfonos y direcciones escritos a mano. Es el sitio donde más datos personales se escapan y el que menos se revisa.
• Se olvida el riesgo de cruce. Un conjunto anonimizado puede dejar de estarlo cuando se combina con otro que la empresa —o cualquiera— ya tiene.

La prueba práctica, antes de dar nada por anonimizado: coge tres registros al azar y pídele a alguien del equipo que intente averiguar de quién son usando solo información interna. Si lo consigue en menos de diez minutos, no está anonimizado.

¿Cómo usar IA sin exponer los datos de tus clientes?

Este es el caso que trae a la mayoría de empresas a esta conversación. Quieres usar un modelo de lenguaje, un sistema de extracción documental o un motor de recomendación, y hay datos personales en el circuito. El orden que funciona es este.

1. Decide antes qué categorías de dato pueden salir del perímetro. No archivo por archivo: por categoría. Datos de contacto, datos económicos, datos de salud, identificadores oficiales. Es una decisión de dirección, no de un técnico a las once de la noche.

2. Minimiza en origen. Si el caso de uso es clasificar tickets de soporte, el modelo no necesita el nombre del cliente. Filtrar antes de enviar es más barato y más robusto que cualquier cláusula contractual.

3. Aplica detección y sustitución de entidades en el texto libre. Un paso automático que localice nombres, teléfonos, correos, matrículas, direcciones y números de documento y los sustituya por marcadores de tipo antes de que el texto salga de tu infraestructura. No es perfecto, y por eso conviene medir su tasa de fallo con una muestra real antes de confiar en él.

4. Elige dónde se procesa y con qué retención. Dónde se ejecuta el modelo, cuánto tiempo se guarda la entrada, si se usa para reentrenar. Esto es contrato, no confianza. Si el proveedor no puede responder por escrito, tienes tu respuesta.

5. Registra el tratamiento. Qué datos, para qué, con qué base jurídica, quién los ve. Si no está en el registro de actividades, no existe para el regulador.

6. Vigila las salidas, no solo las entradas. Un modelo puede devolver en su respuesta un dato personal que estaba en su contexto. Los registros de conversación son datos personales y suelen almacenarse en el sitio menos protegido de toda la arquitectura.

Para el caso concreto de proveedores que tratan datos de terceros, hay una capa adicional de responsabilidad que desarrollamos en la guía de IA para asesorías. Y si lo que tienes por delante es ordenar los datos antes de cualquier proyecto de IA, el orden correcto está en datos antes que IA.

¿Qué hacer esta semana si no tienes nada de esto montado?

Un plan mínimo, sin comité ni presupuesto extraordinario:

• Día 1. Lista las cinco fuentes de datos personales más usadas de la empresa y quién accede a cada una. Con eso ya sabrás dónde está el problema.
• Día 2. Marca en cada una los campos que son identificadores directos, los que son cuasi-identificadores y los que son texto libre. El texto libre es siempre el más urgente.
• Día 3. Define, por escrito y en una página, qué categorías pueden salir del perímetro y hacia dónde.
• Día 4. Monta el filtrado más simple que funcione para el primer caso de uso real. Un script de supresión de columnas cuenta.
• Día 5. Haz la prueba de reidentificación con tres registros. Documenta el resultado, incluido si sale mal.

Eso no te deja certificado en nada, pero te deja en una posición defendible y con criterio para la siguiente decisión. Que es exactamente lo que no tiene la empresa que descubre el problema el día que llega una consulta del cliente o una reclamación.

Preguntas frecuentes

¿Un hash del DNI cuenta como anonimización? No. El conjunto de DNI posibles es pequeño y conocido, así que un hash se revierte por fuerza bruta en minutos. Con una sal secreta y bien custodiada pasa a ser seudonimización, no anonimización, porque quien tenga la sal puede deshacerlo.

¿Puedo usar datos de clientes para entrenar un modelo si están seudonimizados? Siguen siendo datos personales, así que necesitas base jurídica y compatibilidad con la finalidad original. La seudonimización reduce el riesgo y ayuda en el análisis de impacto, pero no te saca del RGPD ni sustituye a la decisión sobre la finalidad.

¿Los datos sintéticos son automáticamente anónimos? No de forma automática. Un generador entrenado con pocos registros puede reproducir ejemplos casi idénticos a los originales. Hay que evaluar el riesgo de memorización con pruebas específicas antes de tratar el conjunto sintético como anónimo.

¿Puedo anonimizar en lugar de borrar cuando vence el plazo de retención? Sí, y suele ser la salida razonable cuando quieres conservar el valor estadístico del histórico. La condición es que la anonimización sea real e irreversible: si mantienes en algún sitio la tabla que permite deshacerla, no has cumplido el plazo, solo lo has escondido.

El resumen honesto

La anonimización de datos no es una casilla que se marca con una herramienta. Es una decisión sobre qué información necesitas de verdad y qué estás dispuesto a perder a cambio de poder usarla con tranquilidad. La mayoría de empresas que se plantean IA no necesitan privacidad diferencial: necesitan dejar de mandar campos que nadie usa, revisar el texto libre y escribir en una página quién puede ver qué. Eso quita el 80% del riesgo con el 10% del esfuerzo.

Si tienes un proyecto de IA parado porque nadie sabe si los datos pueden salir, la auditoría incluye exactamente ese mapa: qué datos tocan cada proceso, cuáles son personales y qué hay que hacer con ellos antes de automatizar nada. Y si ya lo tienes claro y solo quieres contrastar el enfoque con alguien que lo haya montado antes, hablemos.