Anonimización y seudonimización

1) Términos y diferencias clave

Anonimización: llevar irreversiblemente un conjunto a una forma donde el sujeto no puede ser identificado ni directa ni indirectamente con un esfuerzo razonable. Después de la correcta anonimización, los datos dejan de ser PD.
Seudonimización: reemplaza los identificadores directos (nombre, teléfono, correo electrónico, número de cuenta) por alias (tokens). La comunicación se almacena por separado y está protegida por procedimientos de criptografía y acceso. Legalmente, sigue siendo un dato personal.
Cuasi-identificadores: combinaciones de rasgos inofensivos (fecha de nacimiento, índice, sexo, ciudad, dispositivo) que, en conjunto, pueden indicar inequívocamente a una persona.
Re-identificación: restablecimiento de la comunicación con el sujeto por pegamento con fuentes externas o análisis de combinaciones raras de rasgos.

2) Objetivos y requisitos arquitectónicos

1. Privacidad predeterminada: minimizar la recopilación, almacenar sólo los campos necesarios, TTL estrictas.
2. Separación de contornos: los identificadores de producción están separados de los contornos analíticos y ML; acceso a las tablas de comunicación - por el principio need-to-know.
3. Auditoría y rastreabilidad: quién, cuándo y por qué accedió a la re-identificación.
4. Políticas de reutilización: los datos entregados a socios/investigadores externos deben tener garantías formales de privacidad y licencias de aplicación.
5. Evaluación del riesgo: métricas cuantitativas (k-anonimato, probabilidad de match, ε para privacidad diferencial) como SLO de ingeniería.

3) Técnicas de identificación

3. 1 Pseudonimización (reversible)

Tokenización: almacenar las coincidencias en el «registro de tokens».

Formas: determinista (una entrada → una señal), aleatorizado (entrada → diferentes tokens con sal y contexto).
Cuando corresponda: identificadores de pago, cuentas, vínculos de larga vida entre eventos.
FPE (Format-Preserving Encryption): cifrado guardado en formato (por ejemplo, PAN de 16 dígitos → texto cifrado de 16 dígitos). Conveniente para esquemas de legasi y validaciones.
HMAC/Encryption Deterministic: proporciona un alias estable para Joynes, pero requiere control de claves y dominios de aplicación (context binding).
Hashing: aceptable sólo con sal fuerte y sin necesidad de reversibilidad. Para dominios raros (teléfono, email), el hashing puro es vulnerable a la sobrecarga.

3. 2 Anonimización (irreversible)

k-anonimato: cada «quasi-retrato» grabado se encuentra ≥ k veces. Se logra generalizando (age→age_band) y suprimiendo combinaciones raras.
l-diversity: en cada grupo k, un atributo sensible tiene ≥ l valores diferentes para evitar ser revelado por clústeres homogéneos.
t-closeness: distribución de un atributo sensible en un grupo k «cercano» al global (restricción de info-fugas).
Privacidad diferencial (DP): añadir ruido controlado matemáticamente a las unidades o enseñar modelos con privacidad (ε -DP). Da garantías formales contra el conocimiento externo arbitrario del atacante.
Enmascaramiento/permutación/agitación: adecuado para entornos de demostración/sapport.
Datos sintéticos: generación de conjuntos de desarrollo/investigación «similares» sin relación con sujetos reales (GAN/VAEs/sintetizadores de tabla) con comprobación de fugas.

4) Patrones de arquitectura

4. 1 Privacy Gateway en la entrada

Flujo: Cliente → API Gateway → Privacy Gateway → bus de eventos/almacenamiento.

• normalización de los esquemas;
• Asignación de campos sensibles (PII/PHI/finanzas);
• Aplicación de las reglas: tokenización/FPE/enmascaramiento;
• lógica de directivas (policy_id, versión de claves, causa de procesamiento).

4. 2 Registro de tokens (Token Vault)

Servicio/BD separado con HSM/KMS.
RBAC/ABAC en la parte superior de la API; todas las operaciones son auditables.
Separación de «dominios» de tokenización (email/payment/user_id) que un solo token no se puede confundir con contextos.
Rotación de claves y versión de token ('token _ v1', 'token _ v2') con migración transparente.

4. 3 Análisis de dos circuitos

Circuito A (operativo): PII se almacena mínimamente, para el negocio, tokens.
Esquema B (analítico): sólo datacets/agregados anonimizados; acceso a través de notebooks seguros; exportar hacia fuera - a través de la puerta DP.

4. 4 ML transportador con privacidad

Fases: recolección → limpieza → seudonimización → anonimización/agregación DP → aprendizaje.
Para modelos personalizados, almacena fichas en tokens y limita el «brillo» del fich (caps sobre cardinalidad, recorte de colas, regularización DP).

5) Protocolos y flujos (ejemplo)

1. La API recibe 'email'.

2. Privacy Gateway вызывает Token Vault: `tokenize("email", value, context="signup:v1")`.

3. La aplicación guarda 'email _ token' en lugar de email.

4. Para notificaciones, un servicio separado que tiene el derecho de «desintoxicar» por case-by-case, con auditoría.

1. El analista forma una consulta al escaparate (sólo tokens/campos insensibles).

2. El motor aplica la anonimización k en los cuasi-identificadores ('country, age_band, device_class').

3. Para los indicadores con riesgo de divulgación, se agrega ruido DP.

4. La exportación se marca con 'anonymization _ profile _ id' y con el presupuesto ε.

6) Métricas de riesgo y validación

k-anonimato: tamaño mínimo de una clase equivalente (objetivo: k≥5/10/20 dependiendo del dominio).
l-diversity/t-closeness: controlan la fuga de valores sensibles dentro de las clases k.
Puntuación uniqueness: la proporción de retratos únicos entre los activos es reducir por generalización.
Linkability/Inference risk: la probabilidad de que la entrada se enrolle con un conjunto externo (estimado por simulaciones de ataque).
DP ε -budget: establece un «presupuesto de privacidad» por sujeto/dataset y trae su gasto.
Simulaciones de ataque: «comandos rojos» regulares para la re-identificación en los cortes de prueba.

7) Llaves, cripto y contorno operativo

KMS/HSM: generación y almacenamiento de claves para FPE/Encryption/HMAC.
Versionar: 'key _ id', 'created _ at', 'status = active' retiring 'retired'. En los datos almacenar 'kid' para reversibilidad.
Rotación: planificada (trimestral) y forzada (incidente). Mantener el «doble cifrado» durante el período de migración.
Políticas de acceso: prohibición de la desintoxicación masiva; límites en RPS/volumen; la indicación obligatoria 'purpose'.
Auditoría: registro sin cambios (WORM/append-only) con firmas.

8) Integración en microservicios y protocolos

Esquemas de contratos (Protobuf/JSON-Schema): marca los campos con las etiquetas 'pii: direct' quasi 'sensitive', 'policy _ id'.
Eventos: dos conjuntos de temas son «crudos» (circuito interno) y «impersonales» (para analistas/socios).
Puerta para socios: servicio egress con perfiles de anonimato (conjunto de reglas + métricas de riesgo + versión).
Logs/tracks: excluir PII; use tokens/hashes, y en la corulación aplique FPE/HMAC.

9) Anti-patrones

Almacenar los PII originales junto a los tokens/claves.
Confiar en un «super-acceso» sin apruvio multifactorial y registro.
Dar al exterior datasets «impersonales» sin métricas de riesgo y sin garantías formales.
Confiar sólo en el hash de correo electrónico/teléfono sin sal/contexto.
Anonimizar «una vez y para siempre» sin revisión al cambiar fuentes externas (las fugas aumentan el riesgo de linchamiento).
Considerar que k-anonimato es suficiente para textos/series de tiempo/geo-pistas - necesita DP/recorte y sintética.

10) Casos de aplicación (incluyendo fintech/industria del juego)

Antifraude & fiches conductuales: fichas deterministas para la pegatina de sesiones y devays, y los campos sensibles entran en un circuito separado.
Informes por región: k-anonimización de cuasi-identificadores (grupos de edad, región-clúster, tipo de método de pago), ruido DP a las métricas de ingresos.
Pruebas A/B y marketing: tokens de usuario, audiencias «blandas» a través de recortes de DP y registros de auditoría mínimos.
Compartiendo datos con proveedores: solo a través de una puerta de egresos con perfiles de anonimato y restricciones legales a las reconstrucciones incrementales.

11) Mini recetas (pseudocódigo)

Token determinista (email) con sal de dominio

function email_token(email, domain_key, context):
norm = normalize (email )//lower, trim, punycode salt = HMAC (domain_key, context )//context bound to use-case return BASE32 (HMAC (salt, norm) )//stable, non-brute force token

FPE para PAN (aproximadamente)

cipher = FPE_AES_FF1(kid="pay_v2")
enc_pan = cipher. encrypt(pan, tweak=merchant_id)
store(enc_pan, kid="pay_v2")

k-anonimización con supresión de cestas raras

groups = groupBy(dataset, [age_band, region3, device_class])
filtered = filter(groups, count >= k)
suppressed = replaceRare(groups, with="")

Agregación de métricas DP

function dp_sum(values, epsilon, sensitivity=1):
noise = Laplace(0, sensitivity/epsilon)
return sum(values) + noise

12) Pruebas y observabilidad

Pruebas unitarias de políticas: reproducibilidad de tokens, rotación correcta de 'kid', imposibilidad de desintoxicar sin derechos.
Privacidad CI: para cada PR, análisis estático de esquemas y código para fugas PII (comprobaciones de etiquetas/registros/exportaciones).
Métricas: proporción de columnas con etiquetas PII, número de desintoxicaciones por objetivos, k-min por conjuntos, ε-gasto.
Alertas: estallido de intentos de desintoxicación, aparición de cestas «finas» (k cae por debajo del umbral), exportación sin perfil de anonimato.

13) Circuito legal-procesador (nivel alto)

DPIA/TRA: evaluación del impacto sobre la privacidad de los nuevos flujos.
Retención de datos: TTL y política de eliminación de sustitutos y registros.
Solicitudes de sujetos: posibilidad de emitir una copia de los datos sin revelar claves internas/lógica de tokenización.
Contratos con socios: prohibición de re-identificación, restricciones a las joyas con conjuntos externos, métricas de privacidad obligatorias.

14) Check-list del arquitecto

1. ¿Definidos los PII/cuasi-identificadores y etiquetados en los esquemas?
2. ¿El Gateway de privacidad de entrada aplica las políticas de forma determinista y lógica las versiones?
3. ¿El registro de tokens está aislado (KMS/HSM, RBAC, auditoría, límites)?
4. Contornos separados: ¿operativo, analítico, ML, egreso?
5. ¿Están configuradas las métricas de riesgo (k, l, t, ε) y los umbrales SLO?
6. ¿Hay un plan de rotación de claves y migración de tokens reversible?
7. ¿Exportar hacia fuera pasa por un perfil de anonimato y ruido DP?
8. ¿Los registros/rastreos no contienen PII?
9. ¿Simulaciones regulares «red-team» de re-identificación?
10. ¿Está documentado un runbook sobre un incidente de filtración/comprometimiento de claves?

15) Patrones relacionados de la sección «Arquitectura y Protocolos»

Tokenización y administración de claves

Encriptación en el Tránsito En/En

Enrutamiento y localización geo

Observabilidad: registros, métricas, trazados (sin PII)

SLO/SLA para privacidad y cumplimiento

Conclusión

La anonimización y pseudonimización no es una operación aislada sobre una columna, sino una capacidad arquitectónica sistémica: políticas, servicios, claves, auditorías, métricas de riesgo y cultura de desarrollo. Al combinar seudonimización sostenible para los procesos de negocio y garantías formales de privacidad (DP, k-/l-/t-criterios) para la analítica y el intercambio, convierte la privacidad de un «freno a la innovación» a una ventaja competitiva y una capa obligatoria de la calidad de su plataforma.