Qué es la anonimización de datos y cuándo es obligatoria

El problema real detrás de esta pregunta

Una cadena de retail mediana en Perú tenía un programa de lealtad con años de historial de compra por cliente: qué compra, cuándo, en qué tienda, con qué frecuencia. Cuando quisieron usar ese historial para entrenar un modelo de recomendación con un proveedor externo, el área legal pidió ver el archivo antes de que saliera de la empresa. El archivo tenía nombre, número de documento y teléfono. El proyecto se detuvo ahí, no porque la idea fuera mala, sino porque nadie en el equipo de datos se había preguntado qué pasaba con esa información una vez que saliera de sus manos.

La primera reacción, casi siempre, es la misma: borrar la columna de nombre y la de documento, y asumir que el problema queda resuelto. En la práctica esa reacción no resuelve nada. El archivo seguía teniendo la tienda exacta, la fecha exacta y el monto exacto de cada compra, y con eso alcanza para reconstruir la identidad de una persona cruzando dos o tres columnas que a nadie le pareció sensible por separado. La empresa terminó con un archivo que se sentía anónimo y no lo era, que es el peor de los dos escenarios posibles: expone a la persona y además le da a la empresa una falsa sensación de que ya cumplió.

El problema real no es técnico, es de orden. Casi ninguna empresa decide desde el diseño del dato qué campos va a necesitar exponer y cuáles no; la pregunta de privacidad aparece al final, cuando el archivo ya está armado y alguien pide sacarlo de la empresa. Para entonces ya es tarde para diseñarlo bien y solo queda improvisar bajo presión.

Qué es la anonimización de datos

En términos de negocio, anonimizar un dato es lo que permite usar información real de personas sin que esa información siga siendo, legalmente y en la práctica, información de una persona identificable. No es una técnica de seguridad como cifrar un archivo; es un cambio de naturaleza del dato, que pasa de ser un dato personal a dejar de serlo por completo.

Esa palabra, irreversible, es la que separa un dato bien anonimizado de un dato que solo se ve anonimizado. Si en algún punto, con la clave correcta o el sistema correcto, un archivo puede volver a conectarse con la persona original, ese dato no está anonimizado: está seudonimizado, y sigue siendo un dato personal aunque en pantalla se vea como un código sin sentido. La diferencia no es un matiz legal menor, define si a esa base de datos le siguen aplicando las mismas obligaciones que a la base original o no.

Esta distinción conecta directo con lo que ya cubre la guía de privacidad de datos en IA: la anonimización es una de las herramientas para resolver ese problema, no el problema completo. Una empresa puede tener una política de privacidad impecable en el papel y seguir manejando, en la práctica, datos mal anonimizados en cada proyecto nuevo.

Anonimizar no es lo mismo que seudonimizar

La confusión entre anonimizar y seudonimizar es la más común que veo en equipos técnicos, y es la que más problemas genera después. Seudonimizar es reemplazar un dato identificable (el nombre, el documento) por un código o un identificador, guardando en algún lugar, aunque sea protegido, la clave que permite revertir ese cambio. Anonimizar es hacer ese mismo cambio sin dejar ninguna clave que permita revertirlo, ni siquiera para la propia empresa que lo hizo.

La prueba real no es qué tan difícil se ve el dato en pantalla, sino si existe, en cualquier lugar de la organización, una forma de recuperar la identidad original. Un archivo con un ID de cliente en vez de un nombre parece anónimo, pero si esa tabla de IDs vive en otra base de datos de la misma empresa, el conjunto completo sigue siendo un dato personal, con las mismas obligaciones que si hubiera dejado el nombre visible en cada fila.

Señales prácticas para distinguir uno de otro

• Si existe una tabla, archivo o sistema que permite revertir el cambio, es seudonimización, no anonimización.
• Si el mismo equipo que anonimizó los datos puede, con acceso a otro sistema, reconstruir la identidad, sigue siendo dato personal.
• Si el proceso se aplicó columna por columna sin mirar las combinaciones entre columnas, lo más probable es que sea seudonimización débil.
• Si el dato anonimizado se puede corregir o actualizar para una persona específica, es señal de que en algún lugar sigue existiendo el vínculo con ella.
• Si nadie en la empresa puede explicar en una frase por qué el cambio es irreversible, probablemente no lo es.

Por qué borrar el nombre no alcanza

Borrar el nombre de una fila da la sensación de que el trabajo está hecho, y es la razón por la que tantos proyectos de datos arrancan con esa falsa confianza. El riesgo real no está en una sola columna, está en la combinación de varias columnas que, juntas, apuntan a una sola persona aunque ninguna lo haga por separado.

Un caso típico: una aseguradora en Chile compartió con un proveedor un archivo de siniestros sin nombres, pero con distrito, año de nacimiento aproximado, tipo de siniestro y monto. Con esas cuatro columnas y un poco de información pública, como una noticia local de un accidente, alcanzó para identificar a más de una persona del archivo. Ninguna columna sola era sensible; la combinación sí lo era.

Esto se llama reidentificación por cruce, y es el motivo por el que la anonimización real exige mirar el archivo completo y no columna por columna.

Variables que casi nunca se tratan con el cuidado que merecen

• La ubicación geográfica fina (distrito, código postal, sucursal), que combinada con una fecha casi siempre reduce el universo de personas posibles a un grupo muy pequeño.
• Las fechas exactas de eventos (nacimiento, compra, siniestro, consulta), que funcionan como huella cuando se cruzan con otro dato público.
• Los montos y frecuencias inusuales, que hacen destacar a una persona del resto del grupo aunque no tenga nombre visible.
• Los identificadores técnicos que se reutilizan entre sistemas, como un mismo código de cliente en dos bases distintas, que reconectan lo que se había separado.
• La combinación de variables demográficas poco comunes, como una profesión específica en una ciudad pequeña, que por sí sola puede apuntar a muy pocas personas.

Cuándo es obligatoria en la práctica

La obligatoriedad no depende de una sola regla universal, depende del uso que se le va a dar al dato y de a quién se le va a entregar. Esto es justo lo que desarrolla con más detalle la guía sobre qué normativas regulan la IA en empresas; acá me enfoco en las señales operativas que indican que anonimizar deja de ser una buena práctica y pasa a ser un requisito.

Es prácticamente obligatorio cuando el dato sale de la empresa hacia un tercero que no tiene una relación directa con la persona titular, por ejemplo un proveedor de IA, una agencia de marketing o un partner de analítica. También lo es cuando el dato se usa para un fin distinto al que la persona autorizó originalmente, como usar el historial de compra para entrenar un modelo de crédito. Y lo es cuando el dato cruza fronteras hacia un país con reglas de protección de datos distintas a las del país de origen, algo cada vez más común cuando el proveedor de IA opera desde otra región.

Fuera de estos casos, la obligación puede ser menos estricta, pero eso no significa que no exista riesgo. Decidir si un caso puntual cae dentro de una obligación legal específica es responsabilidad del área legal de la empresa, no del equipo de datos; lo que el equipo de datos sí puede hacer es diseñar el dato para que, llegado el caso, ya esté anonimizado y no dependa de una revisión legal urgente de último momento.

Cuándo conviene aunque no sea obligatoria

Hay escenarios donde nadie te va a exigir anonimizar el dato, y aun así conviene hacerlo. El más común es cuando un equipo interno quiere probar un modelo o una integración de IA antes de comprometerse con un proveedor, y usa datos reales de producción porque es lo que tiene a la mano. Ese es exactamente el tipo de caso que cubre la guía de sandbox de IA: un entorno de prueba real necesita datos que se comporten como datos reales sin ser datos reales de una persona identificable.

También conviene cuando el dato se va a mostrar en una demo comercial, un reporte para un directorio, un caso de estudio o una presentación a inversionistas. En más de un proyecto he visto un dashboard con nombres reales de clientes proyectado frente a gente que no debía verlos, y no porque hubiera mala intención, sino porque nadie se detuvo a pensar que ese archivo iba a salir del sistema donde vivía protegido.

Y conviene, sobre todo, cuando el volumen de personas involucradas es alto y el daño de una filtración sería difícil de contener: mientras más grande la base, más grande el costo de un error, así la ley no lo exija en ese caso puntual. Anonimizar por defecto en estos escenarios cuesta menos que reaccionar después de una filtración.

Escenarios donde conviene anonimizar sin que nadie te lo exija

• Pruebas o demos internas de IA que usan datos reales de producción por comodidad, no por necesidad.
• Reportes o casos de estudio que se van a mostrar fuera del equipo que originalmente tenía acceso al dato.
• Bases de datos que van a vivir en un entorno de prueba o sandbox por un tiempo largo, no por una prueba puntual.
• Proyectos con un volumen alto de personas, donde el costo de una filtración sería difícil de contener.
• Cualquier dataset que va a pasar por manos de un proveedor externo aunque el contrato diga que los datos están protegidos.

Mi criterio

Cuándo sí, cuándo no

No todo proyecto con datos de clientes necesita el mismo nivel de anonimización, y tratar todos los casos igual termina frenando proyectos que no tenían por qué frenarse, o dejando pasar proyectos que sí debían detenerse. Estas son señales concretas, no la regla completa, para decidir en qué lado cae tu proyecto.

Señales de que necesitas anonimizar antes de avanzar

• El dato va a salir de la empresa hacia un proveedor, agencia o partner externo.
• El archivo combina ubicación, fecha y monto o frecuencia para el mismo registro.
• El uso que le vas a dar al dato es distinto al que la persona autorizó cuando lo entregó.
• El volumen de personas en el archivo es grande y una filtración sería difícil de contener.
• Nadie en el equipo puede explicar en una frase por qué el archivo no permite reidentificar a nadie.

Señales de que puedes avanzar sin anonimizar, por ahora

• El dato se queda dentro del mismo sistema y del mismo equipo que ya tenía acceso legítimo a él.
• El análisis es agregado desde el inicio (promedios, totales) y nunca baja al registro individual.
• El proyecto está en una etapa de exploración interna, sin conexión a un entorno externo ni a un proveedor.
• Existe un proceso de acceso y auditoría ya establecido para ese dato, con responsables claros.
• El volumen de personas es bajo y el equipo puede nombrar exactamente quién tiene acceso y por qué.

La idea de fondo

El orden con la anonimización siempre es el mismo: primero el dolor real, qué pasa si este dato se filtra o se usa mal; después el proceso, quién decide qué sale de la empresa y bajo qué condición; después el dato, cómo está diseñado el archivo antes de anonimizar nada; y solo al final la herramienta que ejecuta la anonimización. Cuando una empresa empieza por la herramienta, compra un software de anonimización sin haber resuelto lo anterior y termina con un archivo técnicamente procesado pero igual de expuesto, porque el problema nunca estuvo en la herramienta.

Anonimizar bien un dato no es un trámite de cumplimiento, es una forma de tomarse en serio a la persona que hay detrás de cada fila de una base de datos. Las empresas que lo hacen bien no lo hacen porque una ley las obligó esta vez, lo hacen porque ya decidieron que no van a exponer a nadie con tal de avanzar más rápido.