La Ley 21.719, que moderniza la regulación chilena sobre protección de datos personales, debería abrir una conversación técnica importante en Chile: dejar de tratar los datos personales como si fueran simples campos de formulario.
Durante años muchas organizaciones usaron el RUT, el email o el teléfono como llaves primarias, identificadores de integración o campos cómodos para cruzar información entre sistemas.
Era práctico.
Pero también creó arquitecturas donde el dato personal está demasiado distribuido, demasiado expuesto y demasiado difícil de gobernar.
Mi tesis es simple: la Ley 21.719 no solo exige actualizar políticas de privacidad. En la práctica, también empuja a revisar cómo diseñamos identidad, integraciones, analítica, reportes, consentimiento y retención.
Del RUT como llave al RUT como dato gobernado
En una arquitectura moderna, una persona no debería ser "el RUT" dentro de un sistema.
Debería existir como una entidad interna representada por un identificador técnico no significativo:
person_id
customer_id
subject_id
El RUT, el email, el teléfono, la dirección o el nombre deberían ser atributos personales gobernados, no la identidad estructural del sistema.
Esto cambia la pregunta de diseño.
Antes:
¿Cuál es el RUT del cliente?
Después:
¿Qué dato personal necesito, para qué finalidad, bajo qué base legal,
durante cuánto tiempo y con qué evidencia de cumplimiento?
Tokenización: operar sin exponer de más
La tokenización puede ser una herramienta muy útil en este cambio.
En vez de que todos los sistemas guarden el RUT, email o teléfono real, pueden guardar tokens o identificadores internos. Solo una capa gobernada debería poder resolver esos tokens al dato real cuando exista una finalidad válida.
Ejemplo conceptual:
Sistema comercial:
cliente_id = 89231
rut_token = tok_7F92A1
email_token = tok_9CD114
Bóveda gobernada:
tok_7F92A1 -> 12.345.678-9
tok_9CD114 -> persona@correo.cl
Esto no significa que el dato deje automáticamente de estar regulado. Si la organización puede volver desde el token al dato real, sigue existiendo tratamiento de datos personales.
Pero reduce la exposición.
Y eso importa.
El RUT no debería viajar por todos los sistemas si muchos de ellos pueden operar con una referencia interna.
Tokenizar no es anonimizar
Este punto es importante.
Tokenizar reduce exposición, pero no convierte mágicamente un dato personal en dato anónimo.
Si la organización puede resolver el token y volver al RUT, email, teléfono o nombre real, entonces sigue existiendo un dato personal bajo gobierno. La diferencia es que ahora el acceso al dato real puede quedar concentrado, trazado y controlado.
La anonimización real es otra cosa: implica que no sea razonablemente posible volver a identificar a la persona.
Por eso el objetivo de tokenizar no debería ser "salirse de la ley".
El objetivo debería ser diseñar sistemas que operen con menos exposición, menos replicación y más control.
Una bóveda central de datos personales
En empresas con muchos sistemas, el problema no es solo proteger una base de datos.
El problema es saber:
- dónde están los datos personales,
- quién los consulta,
- para qué finalidad,
- bajo qué base legal,
- por cuánto tiempo se conservan,
- a qué proveedores se entregan,
- cómo se eliminan, bloquean o anonimizan.
Por eso tiene sentido pensar en una bóveda central de datos personales o, más ampliamente, una capa central de gobierno de identidad y datos personales.
Modelo conceptual:
CRM / ERP / BI / Soporte / Documentos
|
| usan person_id o tokens
v
Capa de gobierno de datos personales
|
| valida finalidad, permisos, auditoría, retención
v
Bóveda de datos personales
|
| contiene RUT, email, teléfono, dirección, datos sensibles
v
Dato real solo cuando corresponde
La bóveda no debería ser una base de datos más.
Debería ser el punto donde se decide qué sistema puede acceder a qué dato, bajo qué contexto, con qué finalidad y dejando qué evidencia.
También debería tener controles fuertes: cifrado, segregación de permisos, auditoría, monitoreo, gestión de llaves y reglas claras para resolver tokens.
Centralizar sin gobierno solo mueve el riesgo a un lugar más crítico.
El consentimiento no es un checkbox
Otra consecuencia técnica: el consentimiento no debería modelarse como una simple columna booleana.
accepted_terms = true
Eso dice muy poco.
Un consentimiento útil para gobierno debería registrar al menos:
- quién consintió,
- cuándo,
- para qué finalidad,
- bajo qué versión del texto,
- por qué canal,
- cómo puede revocarlo,
- qué sistemas usan esa autorización.
El consentimiento debería ser un evento auditable, no solo un checkbox.
Los derechos de las personas son capacidades de plataforma
Acceso, rectificación, supresión, oposición, bloqueo, portabilidad y revocación del consentimiento no son solo temas de atención al cliente.
Son capacidades que la arquitectura debería soportar.
Si una organización tiene CRM, ERP, mesa de ayuda, analítica, almacenamiento documental, email, OCR, reportes, integraciones y planillas, responder correctamente a una solicitud de una persona titular no es trivial.
Se necesita poder localizar datos, corregirlos, bloquearlos, exportarlos o eliminarlos en todos los sistemas relevantes.
Si no existe trazabilidad, inventario y gobierno transversal, estos derechos terminan dependiendo de procesos manuales frágiles.
Retención por diseño
Muchas organizaciones guardan datos "por si acaso".
La nueva lógica de protección de datos empuja a justificar la conservación.
Cada dato debería tener una política asociada:
dato: email
finalidad: contacto operacional
base legal: según el caso aplicable
retención: mientras exista la relación y por el plazo definido
acción final: eliminar, anonimizar o bloquear
La retención indefinida es una deuda técnica con forma legal.
La planilla Excel también es tratamiento
Este punto suele olvidarse.
No basta proteger el sistema principal si después los datos terminan en exportaciones, reportes, correos, planillas, carpetas compartidas, dashboards, logs o respaldos sin control.
La fuga muchas veces no ocurre en el core transaccional.
Ocurre en la planilla exportada "temporalmente" que nadie gobierna.
Los proveedores también son parte de la arquitectura
Cloud, email, OCR, analítica, CRM externo, storage, herramientas de IA, mesa de ayuda y marketing automation pueden tratar datos personales.
Por eso el perímetro real de protección de datos incluye proveedores, contratos, instrucciones de tratamiento, subencargados, transferencias internacionales y medidas de seguridad.
En protección de datos, la arquitectura también incluye a tus proveedores.
Seguridad de la información no es lo mismo que protección de datos
Este punto también suele confundirse.
ISO 27001, cifrado, backups, monitoreo, control de acceso, tokenización o anonimización ayudan mucho. Son controles relevantes para reducir riesgo.
Pero no reemplazan el cumplimiento de protección de datos personales.
La seguridad de la información pregunta principalmente:
¿Cómo protegemos la confidencialidad, integridad y disponibilidad de la información?
La protección de datos personales agrega otras preguntas:
- ¿Por qué tratamos este dato personal?
- ¿Cuál es la base legal?
- ¿La finalidad es legítima y específica?
- ¿El dato es proporcional o estamos pidiendo de más?
- ¿Cuánto tiempo lo conservamos?
- ¿Cómo ejerce sus derechos la persona titular?
- ¿Qué evidencia tenemos de cumplimiento?
Una empresa puede tener buenos controles de seguridad y aun así tratar datos personales sin finalidad clara, conservarlos indefinidamente o no poder responder una solicitud de supresión, acceso o rectificación.
Por eso anonimizar, seudonimizar, tokenizar o cifrar son medios.
No son el cumplimiento completo.
La finalidad es que el tratamiento sea lícito, proporcional, transparente, seguro y demostrable.
El cumplimiento se demuestra
Una de las ideas más relevantes de la Ley 21.719 es la responsabilidad.
No basta decir que se cumple.
Hay que poder demostrarlo.
Eso implica logs, políticas, controles, contratos, inventarios, registros de consentimiento, trazabilidad de accesos, gestión de incidentes, retención, bloqueo, eliminación y decisiones documentadas.
La protección de datos no se resuelve solo con políticas en PDF.
Se resuelve con arquitectura, gobierno y evidencia.
Una ruta práctica
Si tuviera que ordenar este cambio en pasos técnicos, partiría por algo así:
- Inventariar tratamientos y sistemas que almacenan o procesan datos personales.
- Identificar dónde se usa RUT, email o teléfono como llave técnica.
- Separar identidad interna de atributos personales.
- Definir políticas de finalidad, base legal, acceso y retención por tipo de dato.
- Tokenizar o seudonimizar donde el dato real no sea necesario.
- Crear una capa gobernada para resolver datos reales solo cuando corresponda.
- Registrar consentimiento, accesos, exportaciones, eliminaciones y bloqueos como eventos auditables.
- Revisar proveedores, integraciones, reportes, BI, logs y planillas.
No todo esto se implementa de una vez.
Pero sí se puede comenzar dejando de diseñar nuevos sistemas alrededor del RUT como identificador principal.
Cierre
La Ley 21.719 no debería leerse solo como una obligación legal.
También es una señal de madurez arquitectónica.
En Chile deberíamos dejar atrás sistemas donde el RUT, email o teléfono viajan por todas partes como llaves técnicas.
El futuro debería ser otro: identificadores internos, tokenización, bóvedas de datos personales, trazabilidad, retención, derechos automatizables y gobierno centralizado.
El desafío no es llenar formularios de cumplimiento.
Es rediseñar cómo las organizaciones capturan, usan, comparten, protegen y eliminan datos personales.
Si todos los sistemas necesitan el RUT para funcionar, probablemente el problema no es solo legal.
Es de diseño.
Fuentes y alcance
La ley no dice literalmente "use una bóveda central" ni "tokenice el RUT".
Eso sería una decisión de arquitectura.
Lo que sí establece son principios y obligaciones que hacen razonables estas soluciones: licitud, finalidad, proporcionalidad, calidad, responsabilidad, seguridad, transparencia, confidencialidad, derechos de las personas titulares, reglas de conservación, supresión o anonimización, y deberes del responsable y de quienes tratan datos bajo su responsabilidad.
Desde esa base, identificadores internos, seudonimización, tokenización, bóvedas de datos personales, trazabilidad y retención por diseño son formas técnicas de implementar mejor esos principios.
Fuentes:
Nota: esta publicación es una reflexión técnica y arquitectónica sobre protección de datos personales. No constituye asesoría legal.
Top comments (0)