Analítica y protección de datos personales en Colombia y México
Analizar datos personales es legítimo cuando existe una finalidad declarada que lo ampare. Habeas Data en Colombia y la LFPDPPP en México coinciden en el principio: el titular autorizó un uso concreto, y usar el dato para otro distinto exige revisar esa autorización antes, no después del análisis.
A continuación: qué exige la finalidad declarada, cuándo conviene anonimizar, cómo se diseña el acceso y qué conviene dejar registrado.
La conversación sobre datos personales suele llegar tarde al proyecto de analítica: cuando el tablero ya está construido y alguien pregunta si se puede usar. En ese punto las opciones son caras.
Llevarla al inicio no la vuelve más lenta; la vuelve más barata, porque las decisiones de diseño que la resuelven cuestan poco cuando aún no hay nada construido.
La finalidad declarada, y por qué manda
Ambos marcos parten de lo mismo: el titular de los datos autorizó un tratamiento con una finalidad determinada. Ese consentimiento no es un cheque en blanco, y la pregunta operativa no es «¿tenemos el dato?» sino «¿para qué dijimos que lo íbamos a usar?».
En la práctica esto define qué análisis son directos y cuáles requieren una revisión previa. Analizar el comportamiento de pago para gestionar cartera suele estar amparado por la relación contractual. Usar esos mismos datos para construir un modelo comercial dirigido a otro producto es un uso distinto, y conviene resolverlo antes de construir.
Cuando la finalidad no cubre el uso previsto, hay tres caminos: ampliar la autorización, apoyarse en otra base legal aplicable, o trabajar con datos que ya no identifiquen a nadie.
Cuándo conviene anonimizar
La mayoría de los análisis no necesita saber quién es la persona. Necesita saber cuántos, de qué tipo y con qué comportamiento. Si el resultado no cambia al reemplazar el identificador por un código, ese análisis no debería estar tocando datos identificables.
Conviene distinguir dos cosas que se confunden. Seudonimizar es reemplazar el identificador conservando la posibilidad de revertirlo: sigue siendo dato personal y sigue sujeto a la norma. Anonimizar es hacer irreversible esa asociación, y solo entonces el dato sale del alcance.
La irreversibilidad es más difícil de lo que parece: la combinación de pocos atributos puede reidentificar a una persona en un conjunto pequeño. En una base de clientes de una ciudad intermedia, tres o cuatro campos pueden bastar.
Cómo se diseña el acceso
La regla práctica es que el acceso siga a la función y no a la jerarquía. Quien gestiona cartera necesita ver el detalle de un cliente; quien analiza tendencias no.
Eso se implementa en la capa donde se definen las métricas, no en cada tablero. Repartir las reglas de acceso entre veinte reportes garantiza que alguno quede abierto y que nadie sepa cuál.
Y conviene revisar el acceso cuando alguien cambia de rol, que es el momento en que las organizaciones acumulan permisos sin retirarlos. Esa acumulación silenciosa es lo que convierte un incidente menor en uno reportable.
El error de diseño que más cuesta corregir
Copiar la base completa a un entorno analítico «para explorar» es la decisión que más exposición crea y la más difícil de revertir. Una vez que existen tres copias del maestro de clientes en tres lugares distintos, nadie sabe cuántas hay realmente ni quién accede a cada una.
La alternativa no es prohibir la exploración: es acordar dónde vive el dato identificable y trabajar contra esa fuente en lugar de replicarla. Lo que se copia a los entornos de análisis debería salir ya seudonimizado, salvo que el caso justifique lo contrario y alguien lo autorice de forma explícita.
Esa decisión cuesta poco al inicio del diseño y mucho después, porque cada copia adicional tiene sus propios consumidores que hay que migrar.
Qué conviene dejar registrado
Tres cosas, y las tres sirven además para operar mejor. Qué datos personales se usan en cada análisis y con qué finalidad. Quién accedió a qué y cuándo. Y durante cuánto tiempo se conserva cada conjunto, con un criterio de eliminación que efectivamente se ejecute.
Ese último punto es el que más se descuida. Conservar indefinidamente «por si acaso» aumenta la exposición sin aportar valor analítico: los datos muy antiguos rara vez mejoran un modelo y siempre amplían la superficie de un incidente.
Cómo encaja con el resto de la capacidad
La protección de datos no es un requisito que se satisface al final: es una restricción de diseño que ordena decisiones de arquitectura. Por eso se evalúa junto con el gobierno del dato y no aparte.
Un assessment de madurez de datos y analítica revisa el gobierno contra la norma que le aplica en Colombia o en México, y la parte de custodia y control de acceso se trabaja con ciberseguridad. El resultado es una capacidad de analítica que puede crecer sin rehacerse.
Preguntas frecuentes
¿Se pueden analizar datos personales de clientes?
Sí, cuando existe una finalidad declarada que ampare ese uso. La pregunta operativa no es si se tiene el dato, sino para qué se dijo que se iba a usar. Un uso distinto al autorizado exige revisar la autorización antes de construir el análisis.
¿Anonimizar y seudonimizar son lo mismo?
No. Seudonimizar reemplaza el identificador conservando la posibilidad de revertirlo, así que sigue siendo dato personal sujeto a la norma. Anonimizar hace irreversible esa asociación, y solo entonces el dato sale del alcance.
¿Qué norma aplica en Colombia y en México?
En Colombia el régimen de Habeas Data, cuyo eje es la Ley 1581. En México la Ley Federal de Protección de Datos Personales en Posesión de los Particulares. Coinciden en el principio de finalidad, y difieren en procedimientos y en la autoridad competente.
¿Cuánto tiempo conviene conservar los datos?
El que la finalidad justifique, con un criterio de eliminación que efectivamente se ejecute. Conservar indefinidamente amplía la exposición sin aportar valor: los datos muy antiguos rara vez mejoran un modelo.
