La mayoría de las organizaciones que dicen "anonimizamos los datos" en realidad solo los desidentifican, es decir, solo borran datos como el nombre o el RUT, y dejan intacto todo lo demás. Eso no es anonimización, es solo uno de los cinco pasos para lograrlo y con el resultado final es uno de los errores más caros que pueden pagar las organizaciones en la protección de los datos personales, porque un dato mal anonimizado sigue haciendo identificable a una persona y por ende considerado como dato personal que tiene que cumplir con todas las obligaciones ante la ley.

A continuación, se  presentan aspectos claves para comprender y aplicar correctamente la anonimización, éstos van desde entender su importancia, entender el vocabulario correcto, conocer la diferencia entre la tokenización y el cifrado de una anonimización real, saber cuándo es necesaria, definir un plan de aplicación, para llevar la teoría a las herramientas concretas y saber cuáles son los errores más comunes que deben evitarse. 

El objetivo es pasar del concepto a la práctica y entender cuándo una técnica realmente protege la identidad de las personas y cuándo solo ofrece una falsa sensación de anonimato del dato personal.

1. El p​roblema: por qué esto importa ahora

Existen tres fuerzas que actualmente están empujando la anonimización de ser un tema de nicho legal a una decisión de arquitectura tecnológica.

• Regulatoria: leyes de nueva generación como por ejemplo la Ley 21.719 en Chile, que está inspirada en el GDPR y definen la anonimización con bastante precisión técnica y además le dan el peso de sacar de obligación a las organizaciones si logran que realmente sea irreversible, aunque también elevan el estándar de qué cuenta como "anonimizado".
• Económica: un incidente sobre datos anonimizados no exige notificación ni genera el mismo costo reputacional; en promedio, una filtración de datos anonimizados cuesta menos por incidente que una de datos personales.
• La IA como nuevo consumidor de datos: entrenar o alimentar modelos con datos reales de clientes es cada vez más común, y cada vez más riesgoso si esos datos no pasaron por un proceso de anonimización o síntesis antes de llegar al modelo.

2. Vocabulario correcto: los cinco estados de un dato

Antes de comenzar a anonimizar los datos, hay que saber en qué estado se encuentra, porque la obligación legal aplicable depende en que estado se encuentre, es por ello que mostramos los que apoyan a la identificarlos:

Estado	Qué significa	¿Sigue siendo dato personal?
Identificado	Tiene identificadores directos (nombre, RUT, email) que singularizan a la persona sin ambigüedad.	Sí, se aplica la ley íntegramente.
Pseudonimizado	Los identificadores directos se reemplazan por un código, pero existe una tabla de correspondencia en algún lado que permite revertir el proceso.	Sí.  Es la trampa más común: pseudonimizar no saca el dato del alcance de la ley.
Pseudonimización fuerte	Además de reemplazar identificadores directos, se generalizan o suprimen los indirectos (edad exacta por rango ó código postal completo por región) para bajar el riesgo de reidentificación por combinación.	Sí,  pero con riesgo residual mucho menor.
Anonimizado	El vínculo con la persona se rompe de forma irreversible; ni siquiera cruzando con otras fuentes es razonablemente posible reidentificar.	No.  Deja de ser dato personal.
Anónimo desde el origen	Nunca tuvo relación con una persona (ej. temperatura de una sala).	No aplica la ley.

El error clásico, es eliminar el nombre pero dejar intactos el restaurante favorito, la fecha de nacimiento, el género y el empleador. Esos cuatro campos combinados casi siempre vuelven a apuntar a una sola persona: es pseudonimización, no anonimización, aunque el nombre ya no esté.

La consecuencia práctica de confundir ambas categorías se ve mejor en un incidente, por ejemplo:

Qué se filtró	¿Hay que notificar la brecha?
Solo la tabla de correspondencia	Probablemente no
Datos pseudonimizados  +  tabla de correspondencia	Sí, es brecha de datos personales
Solo datos pseudonimizados (sin la tabla)	Zona gris, depende de si la tabla es recuperable por otra vía
Solo datos anonimizados	No.  No son datos personales

3. Tokenización, cifrado y encriptación: el resto de la caja de herramientas

Anonimización y pseudonimización son las categorías legales. Tokenización, cifrado y encriptación son técnicas concretas que se usan para llegar a esas categorías, pero ninguna de las tres es, por sí sola, anonimización. Vale la pena aclarar cada una porque es común que un proveedor venda "tokenizamos tus datos" como si fuera sinónimo de "los sacamos del alcance de la ley", y casi nunca lo es.

Cifrado o encriptación

El término técnico correcto es cifrado;  la encriptación es un anglicismo de "encryption" que se ha extendido en industria y ya aceptado coloquialmente, pero ambos designan exactamente la misma técnica, que es transformar un dato en algo ilegible mediante un algoritmo y una clave, de forma que solo quien tiene la clave puede revertir el proceso.

• Cifrado simétrico (AES es el estándar de facto): la misma clave cifra y descifra. Es rápido, ideal para grandes volúmenes de datos en reposo o en tránsito.
• Cifrado asimétrico (RSA): un par de claves pública y privada, donde lo que cifra una clave solo lo descifra la otra. Es más lento, se usa típicamente para intercambiar claves simétricas o firmar, no para cifrar volúmenes grandes.
• Dónde se aplica: en reposo (bases de datos, discos), en tránsito (TLS) y, cada vez más, en uso (cifrado homomórfico o enclaves seguros, todavía de adopción limitada).

Tokenización

Reemplaza un identificador (número de tarjeta, RUT, nombre) por un token sin relación matemática con el valor original. A diferencia del cifrado, no hay una fórmula que conecte token y dato real; la única forma de revertirlo es consultando una bóveda (vault) que guarda la correspondencia entre el token y el valor original, protegida por separado con sus propios controles de acceso.

Dos variantes técnicas, con implicancias prácticas distintas:

• Tokenización que preserva el formato (format-preserving): el token tiene el mismo formato, longitud y tipo de carácter que el dato original, es decir, un número de tarjeta tokenizado sigue "pareciendo" un número de tarjeta de 16 dígitos. Esto permite que sistemas legados, validaciones de formulario o integraciones existentes sigan funcionando sin modificarse, porque el token pasa las mismas validaciones sintácticas que el dato real. Es el estándar de facto en el mundo de pagos (PCI DSS) precisamente por esto.
• Tokenización que no preserva el formato: el token no se parece en nada al original (puede mezclar letras y números sin ninguna estructura reconocible). Es más simple de implementar y, en algunos esquemas, más difícil de confundir accidentalmente con datos reales, pero rompe cualquier sistema que valide el formato del campo.

Una variante híbrida es el cifrado que preserva el formato (Format-Preserving Encryption, FPE, estandarizado por NIST en los modos FF1 y FF3-1, SP 800-38G), que logra el mismo resultado visual que la tokenización con formato preservado pero por la vía del cifrado; ésto es matemáticamente reversible con la clave, pero no depende de una bóveda externa; es muy útil cuando no se quiere mantener y asegurar un almacén de tokens separado, a cambio de asumir la gestión de claves criptográficas.

Tabla comparativa

Técnica	Mecanismo de reversión	¿Preserva formato?​	Estado legal (GDPR/Ley 21.719)	Caso de uso típico
Cifrado simétrico/asimétrico	Clave criptográfica	No necesariamente (depende del modo)	Pseudonimización (mientras exista la clave)	Datos en reposo/tránsito, cumplimiento genérico
Cifrado con preservación de formato (FPE)	Clave criptográfica	Sí, por diseño	Pseudonimización	Legados que validan formato sin poder modificarse
Tokenización con formato preservado	Bóveda (vault) externa	Sí, por diseño	Pseudonimización	Pagos (PCI DSS), sistemas que validan longitud/tipo
Tokenización sin formato preservado	Bóveda (vault) externa	No	Pseudonimización	Documentos, texto libre, corpus para IA
Datos sintéticos	No aplica (no hay dato real que revertir)	No busca preservarlo	Puede llegar a anonimización si no hay trazabilidad al original	Entrenamiento de modelos de IA
Anonimización (generalización, supresión, agregación, k-anonimidad)	Ninguno, irreversible por diseño	No	Anonimización (fuera del alcance de la ley)	Conservación indefinida, estadística, investigación

Vale la pena resaltar que  solo la última fila saca el dato del alcance de la ley. Cifrar, tokenizar (con o sin formato) y hasta la mayoría de los esquemas de "datos sintéticos con trazabilidad" siguen dejando el dato dentro del perímetro legal de "dato personal". Son controles de seguridad excelentes y a menudo obligatorios, pero no sustituyen la anonimización cuando el objetivo es salir del alcance de la ley.

4. ¿Cuándo es necesaria la anonimización? 

Checklist de decisión  

Cuanto más se anonimiza un conjunto de datos, menor es su valor analítico. Por ello, la anonimización no debe verse como un simple trámite normativo, sino como un compromiso (trade-off) técnico. Se recomienda optar por la anonimización en lugar de la pseudonimización, el cifrado o mantener los datos intactos en los casos que se cumpla una o varias de las siguientes condiciones:

• Se necesita conservar el dato indefinidamente. Los datos pseudonimizados siguen sujetos a plazos de conservación; los anonimizados no.

• El dato va a salir de la organización, sea a un tercero, a un proveedor o a una entidad pública para fines estadísticos, y no hay forma de controlar qué hace el receptor con él después.
• El dato va a alimentar un modelo de IA (entrenamiento, fine-tuning, o incluso un prompt con contexto real de clientes). Es el caso de uso que más está creciendo hoy.
• Se quiere explorar una finalidad secundaria distinta de la que originó la recolección, sin tener que volver a pedir consentimiento.
• Se busca reducir la superficie de riesgo de una base de datos sensible (salud, financiera) que hoy exige controles caros de seguridad y auditoría.
• El dato ya cumplió su finalidad original pero tiene valor estadístico o de investigación: la alternativa a eliminarlo es anonimizarlo.

Y NO conviene forzar la anonimización cuando:

- El caso de uso exige poder identificar a la persona más adelante (ej. atención al cliente, cobranza, cumplimiento de un contrato), ahí corresponde pseudonimizar, no anonimizar.

- Los datos son sobre personas muy expuestas o una población muy pequeña una empresa con 3 ejecutivos, por ejemplo, donde la reidentificación es casi evidente incluso después de anonimizar. En ese caso, el esfuerzo de anonimización real es alto y puede no ser viable técnicamente.

- El valor comercial del dato depende de la granularidad exacta que se perdería al anonimizar, ese es precisamente el trade-off a evaluar antes de decidir.

 En resumen, la anonimización es necesaria cuando se prioriza la eliminación definitiva de riesgos legales y plazos de retención. Por el contrario, debe evitarse si el caso de uso exige volver a identificar al usuario, si la población es vulnerable a la reidentificación directa o si el negocio depende de la granularidad exacta del dato.

5. Plan de aplicación en cinco pasos

Un proceso de anonimización real, no cosmético, sigue esta secuencia:

Paso 1: Conocer los datos

Antes de tocar nada, hay que saber qué hay, conocer cuáles son los identificadores directos (nombre, RUT, email), cuáles los indirectos o posibles identificadores (edad, género, código postal, cargo), y cuáles son los atributos objetivo que dan valor al dataset (diagnóstico, salario, historial de compras). Este inventario es exactamente lo que hace un motor de descubrimiento y clasificación de datos. Sin él, los pasos siguientes se hacen a ciegas.

Paso 2: Desidentificar

Remover o enmascarar los identificadores directos. Este es el paso que la mayoría de las organizaciones confunde con ya anonimizamos y es solo el comienzo.

Paso 3: Tratar los identificadores indirectos

Acá está el trabajo real. Técnicas disponibles, combinables entre sí:

• Generalización: reemplazar un valor exacto por un rango, por ejemplo si la edad es 34, entonces cambiarlo por un rango de 30-39.

• Enmascaramiento: ocultar parte del valor, por ejemplo: número de tarjeta: `**** **** **** 4521`).

• Supresión: eliminar directamente una columna de alto riesgo.

• Agregación: reportar sumas o promedios en vez de registros individuales.

• Perturbación: introducir ruido controlado en los valores numéricos.

• Tokenización o cifrado con preservación de formato: se usa generalmente cuando el sistema de destino necesita seguir validando el campo como si fuera el original. Es importante destacar que por sí solas dejan el dato en pseudonimización, no en anonimización; si el objetivo final es anonimizar, deben combinarse con supresión y generalización de los identificadores indirectos y, eventualmente, con la destrucción irreversible de la clave o la bóveda.

Paso 4: Medir el riesgo de reidentificación (k-anonimidad)

La k-anonimidad mide cuántos registros del dataset son indistinguibles entre sí después del tratamiento. Si k=1, hay al menos una persona que sigue siendo única y, por tanto, identificable: el proceso falló. La recomendación práctica es no conformarse con menos de k=3 o k=4, porque cuanto más alto el k, menor el riesgo, pero también menor la utilidad analítica del dato. Este es el número que convierte "creo que anonimicé bien" en una afirmación verificable.

Paso 5: Gestionar el riesgo residual

Ningún proceso de anonimización llega a tener un riesgo cero,  La propia ciencia de datos lo reconoce, aunque la ley hable de "irreversibilidad", es por ellos que el proceso no termina en el paso 4, se debe gobernar lo que queda.

• Controles técnicos: cifrado de lo que aún necesite protección, control de accesos, revisión periódica.

• Controles de proceso: plan de gestión de brechas, registro de a quién se le compartió qué, eliminación programada, auditorías.

• Controles legales: acuerdos de tratamiento de datos que prohíban contractualmente intentar reidentificar, definan los fines permitidos y fijen responsabilidad por incumplimiento.

6. De la teoría a la herramienta

El plan de cinco pasos se traduce en un flujo de trabajo con dos capas de tecnología que conviene mantener separadas:

La primera, la Capa 1 hacer un Descubrimiento y clasificación, por medio de un motor de discovery que escanee las fuentes de datos (estructuradas y no estructuradas), identifique los campos que son identificadores directos, cuáles indirectos y dónde viven cada uno. 

Sin este inventario, cualquier proyecto de anonimización arranca adivinando.

Y en la Capa 2 tener un Motor de anonimización, tokenización y cifrado , ya que una vez identificados los campos, el motor especializado aplique el tratamiento real. 

Actualmente en el mercado existen arquitecturas típicas, no mutuamente excluyentes, que son:

1. Redacción o máscaras, para documentos que se van a compartir tal cual (contratos, expedientes).
2.  Tokenización (con o sin preservación de formato), que reemplaza cada entidad por un token consistente a lo largo del documento y entre documentos; ejemplo: "Persona 1" siempre es la misma persona en todos los documentos; reversible mediante la bóveda, por lo que técnicamente es pseudonimización fuerte y no anonimización pura. Importante no confundir el nombre comercial con la categoría legal.
3. Cifrado, incluido el que preserva formato (FPE): cuando conviene evitar mantener una bóveda externa y se prefiere gestionar la reversión vía claves criptográficas.
4. Datos sintéticos: genera datos ficticios, pero estadísticamente coherentes con el original. Es la opción más adecuada para entrenar modelos de IA, porque no hay ningún dato real en el resultado, y es la única de esta lista que puede llegar a calificar como anonimización real si se implementa sin trazabilidad al dato de origen.

Cuando la capa de discovery y la de anonimización están integradas, cuando el discovery le dice al motor exactamente qué campos tratar y con qué técnica, el flujo desde "no sabemos qué datos tenemos" hasta "tenemos un dataset con k-anonimidad medible y gobernanza del riesgo residual", se puede ejecutar sin trabajo manual de mapeo campo por campo.

7. Errores comunes a evitar

1.- Llamar "anonimización" a la desidentificación. Es el error más frecuente y el más caro: un incidente sobre esos datos sigue siendo notificable.

2. - Llamar "anonimización" a cifrar o tokenizar. Son controles de seguridad valiosos y a menudo exigidos por norma (PCI DSS, por ejemplo), pero mientras exista la clave o la bóveda, el dato sigue siendo personal ante la ley (ver sección 3).

3. - Anonimizar sin medir k-anonimidad. Sin esa métrica no hay forma de defender, ante un regulador o un cliente, que el proceso realmente redujo el riesgo a un nivel razonable.

4. - Tratar la anonimización como un evento único. El riesgo de reidentificación cambia con el tiempo (nuevas fuentes de datos públicas, nuevas técnicas de correlación); requiere revisión periódica, no una foto fija.

5. - Aplicar el mismo nivel de anonimización a todo. Una base con población pequeña o personas muy expuestas necesita pseudonimización fuerte o supresión adicional; aplicar la misma receta a un dataset masivo y a uno pequeño ignora que el riesgo de reidentificación no es lineal con el tamaño de la muestra.

6. - Olvidar la base de licitud del propio proceso. Anonimizar, pseudonimizar, tokenizar y cifrar son, en sí mismos, tratamientos de datos personales: necesitan su propia base legal (normalmente interés legítimo, salvo datos sensibles).

Conclusión

La anonimización no es un interruptor binario ni un trámite de compliance. Es un proceso técnico medible con un resultado legal concreto​​. La diferencia entre hacerlo bien y hacerlo a medias no se nota hasta el día de un incidente, cuando la pregunta deja de ser ¿anonimizamos esto? y pasa a ser ¿tenemos que notificar esto?

Un plan que empieza por saber qué datos existen, sigue con un tratamiento técnico verificable (k-anonimidad) y termina con gobernanza del riesgo residual es la diferencia entre esas dos preguntas.

Contáctenos