No toda necesidad de proteger datos exige “anonimizar”. A veces conviene seudonimizar, otras tokenizar, cifrar, agregar, sintetizar o enmascarar dinámicamente. Esta guía práctica te ayuda a elegir la técnica correcta según objetivo, riesgo de reidentificación y obligaciones legales bajo la Ley 21.719 en Chile.
Árbol de decisión
¿Necesitas compartir/publicar datos sin identificar a nadie?
→ Anonimización y evaluación de reidentificación.
¿Necesitas trazar individuos pero reducir riesgo?
→ Seudonimización con llaves separadas + controles de acceso + rotación de seudónimos.
¿Pagos o identificadores muy sensibles (RUT, tarjetas, cuentas)?
→ Tokenización + lista blanca + segregación de cofres y monitoreo.
¿Analítica/BI con diferentes perfiles de acceso?
→ Enmascaramiento dinámico por rol + agregación para vistas ejecutivas.
¿Ambientes de prueba/desarrollo?
→ Datos sintéticos o enmascaramiento irreversible (hash + perturbación).
¿Intercambio con terceros / partners?
→ Clean rooms con privacidad diferencial o agregación; contratos y auditoría.
¿Solo proteger confidencialidad en tránsito/descanso?
→ Cifrado fuerte (no sustituye anonimización/seudonimización).
Lo que no debes hacer
- “Quitar el nombre y dejar fecha de nacimiento + comuna + evento raro” → reidentificable.
- Usar el mismo seudónimo en todos los sistemas → triangulación fácil.
- No separar llaves/tokens del equipo que usa los datos.
- Llevar datos personales reales a QA/Dev “para probar rápido”.
- Asumir que cifrar = anonimizar.
Implicancias Técnicas
| Tipo de técnica | Descripción | Cuándo usar | Implicancia técnica |
|---|---|---|---|
| Anonimización | Compartir/publicar sin identificación. | El dataset será abierto o difundido externamente y no necesitas trazabilidad individual. | k 5–20, l-diversity/t-closeness, pruebas de reidentificación; menor granularidad. |
| Seudonimización | Seguir individuos sin exponer identidad. | Requieres análisis por cohortes/retención/LTV y posibilidad de reconciliar identidades bajo control. | Llaves en HSM/KMS, rotación; sigue siendo dato personal; auditoría. |
| Tokenización | Sustituye valores sensibles por tokens. | Cuando manipulas RUT/PAN/cuentas en pagos, KYC/AML o CRM y necesitas formato preservante. | Vault HA/DR, mTLS, rate-limit; tokens formato-preservantes. |
| Enmascaramiento dinámico | Oculta según rol/uso. | Cuando múltiples perfiles acceden al mismo dato (BI, soporte) con vistas limitadas por política. | Políticas en DB/proxy/app; cuidar cachés; gobierno de consultas. |
| Agregación | KPIs/estadística sin microdatos. | Solo necesitas indicadores ejecutivos/regulatorios sin riesgo de reidentificación. | Umbrales (evitar n<k), cell suppression, control de diferenciales. |
| Datos sintéticos | Datos “ficticios” con distribución realista. | Conviene cuando necesitas QA/Dev/PoCs sin PII real ni riesgos de exposición. | Tests de utilidad y leakage; versionado de semillas/modelos. |
| Privacidad diferencial | Consultas con ruido calibrado. | Compartes insights entre áreas/terceros sin revelar microdatos. | Definir ε/δ y budget; auditoría y plantillas seguras. |
| Clean rooms / analítica federada | El dato no sale; resultados agregados. | Colaboras con partners (retail media, telco-ads) y debes evitar el intercambio de microdatos. | Matching con IDs hash/seudónimos; salidas auditadas. |
| Cifrado | Confidencialidad en tránsito/descanso. | Cuando buscas proteger acceso/robo, pero mantendrás uso operativo del dato. | AES-GCM/ChaCha20-Poly1305; KMS/HSM; determinístico solo si es imprescindible para joins. |
| HE/MPC (PETs avanzadas) | Cálculo colaborativo seguro. | Conviene cuando el valor del análisis conjunto es alto y la sensibilidad impide cualquier exposición. | Mayor latencia/costo; librerías maduras; casos acotados. |
Contáctanos: dgrandon@qbitx.cl
