Cómo prepararse técnicamente para la Ley 21.719: inventario, RAT y trazabilidad

Si eres quien administra los sistemas donde viven los datos, este artículo es para ti. La Ley 21.719 suele presentarse como un tema legal, y en parte lo es. Pero su núcleo exigible es técnico: cuando la Agencia de Protección de Datos fiscalice, no va a pedir tus políticas de privacidad — va a pedir evidencia de que sabes qué datos personales tratas, dónde están, para qué los usas y quién accede a ellos. Nada de eso se redacta. Se construye sobre tus sistemas reales.

El principio que cambia el enfoque: privacidad desde el diseño

Antes de entrar en componentes, vale la pena internalizar el criterio que mejor resiste una auditoría: la protección de datos no se “agrega después” a un sistema que ya funciona. Se diseña desde el inicio. Las preguntas correctas — ¿necesito realmente este campo?, ¿cuánto tiempo debo conservarlo?, ¿quién debe tener acceso?, ¿está cifrado? — se responden al diseñar el sistema, no en la auditoría post-incidente. Construir cumplimiento retroactivo es caro y frágil; construirlo desde el diseño es la forma técnicamente correcta.

Dicho esto, la mayoría de las organizaciones ya tienen sistemas en producción y deben adecuarlos. Estos son los componentes técnicos que la ley exige poder demostrar.

1. Inventario de datos: qué tienes y dónde vive

El punto de partida de todo. No puedes proteger — ni documentar — lo que no sabes que tienes. El inventario responde a preguntas concretas: ¿qué datos personales recolecta la organización?, ¿en qué sistemas, bases de datos y planillas residen?, ¿con qué finalidad se recolectaron?, ¿cuánto tiempo se conservan?, ¿quién tiene acceso?

En la práctica esto implica recorrer todos los repositorios donde puede haber datos personales: la base de datos transaccional, el CRM, el sistema de RRHH, los archivos en SharePoint u OneDrive, las planillas sueltas de cada área, y los servicios externos a los que envías datos. Los datos personales incluyen lo evidente (nombre, RUT, correo, teléfono, dirección) y lo menos obvio (dirección IP, geolocalización, hábitos de consumo, historial). Y hay una categoría de datos sensibles con protección reforzada: salud, datos biométricos, afiliación sindical, opiniones políticas, vida sexual, datos de niños, niñas y adolescentes.

2. El RAT: el primer documento que pide un fiscalizador

El Registro de Actividades de Tratamiento (RAT) es el corazón técnico del cumplimiento. Documenta, para cada actividad de tratamiento, qué datos se procesan, con qué finalidad, bajo qué base de licitud, con quién se comparten y por cuánto tiempo se conservan.

Aquí hay un error común que conviene evitar: el RAT no es un listado de sistemas por departamento. Construirlo bien significa seguir el flujo de cada dato a través de los sistemas por los que pasa — del formulario que lo captura, al CRM que lo almacena, al proveedor externo que lo procesa. Eso es, literalmente, mapeo de flujos de datos e integración de fuentes: trabajo de ingeniería de datos con experiencia en ETL, no de redacción legal.

3. Control de accesos y trazabilidad: demostrar, no declarar

La ley exige poder responder quién accedió a qué dato personal y cuándo. Esto se traduce en requisitos técnicos concretos:

• Control de accesos: que cada persona acceda solo a los datos que su función requiere, con permisos definidos y revisables.
• Logs de auditoría: registros datados de quién accedió, modificó o eliminó datos personales. Estos logs son evidencia clave ante la Agencia en una investigación o una brecha.
• Cifrado: los campos que almacenan datos personales — especialmente los sensibles y financieros — deben estar protegidos, tanto en reposo como en tránsito.

La distinción operativa es esta: no basta con tener controles, hay que poder demostrar que operaron. Un control sin un log que lo registre es, ante una fiscalización, como si no existiera.

4. Notificación de brechas en 72 horas

Cuando ocurra una vulneración que afecte datos personales — un acceso no autorizado, una pérdida, una filtración —, la ley exige notificar a la Agencia dentro de las 72 horas desde que la organización toma conocimiento del incidente. Si la brecha implica un riesgo alto para los titulares, también hay que notificarles a ellos sin dilación indebida.

Un plazo de 72 horas no se cumple improvisando bajo presión. Requiere tener, antes del incidente, un procedimiento documentado y probado: cómo se detecta, quién lo evalúa, qué se comunica y a quién. Es un componente que se prepara en frío, no en caliente.

5. IA y datos personales: un frente que suele pasarse por alto

Si tus sistemas incorporan inteligencia artificial que procesa datos personales — un asistente de atención al cliente, un clasificador de solicitudes, un generador de reportes sobre datos de clientes —, la ley aplica íntegramente a ese tratamiento. El modelo de IA funciona como un subencargado que debe estar declarado en tu RAT, cubierto por un acuerdo con el proveedor, y configurado para no exponer datos personales en sus respuestas ni en sus logs. Es un punto ciego frecuente: se automatiza con IA sin considerar que ese flujo también trata datos regulados.

Cómo se conecta con el marco de ciberseguridad

Vale aclarar una confusión habitual: la Ley 21.719 (datos personales) es distinta de la Ley 21.663 (Marco de Ciberseguridad). No se superponen, se complementan: la 21.663 regula controles de ciberseguridad; la 21.719 regula el tratamiento de datos personales. Si tu organización está sujeta a ambas, conviene abordarlas de forma coordinada, porque comparten terreno técnico (logs, controles de acceso, respuesta a incidentes).

Un punto de partida realista: plan por fases

No intentes resolver todo a la vez. Un enfoque por fases ordena el trabajo:

1. Inventario y accesos: mapear qué datos personales hay, dónde residen y quién accede.
2. RAT y flujos: documentar las actividades de tratamiento siguiendo el recorrido real de los datos.
3. Controles técnicos: cifrado, logs de auditoría, gestión de accesos.
4. Procedimiento de brechas: definir y probar el flujo de notificación en 72 horas.
5. Mantención: la evidencia se desactualiza con cada cambio en los sistemas; el cumplimiento es un estado que se mantiene, no un proyecto que se cierra.

En el fondo, un proyecto de datos bien hecho

La preparación técnica para la Ley 21.719 es, en el fondo, un proyecto de datos bien hecho: inventario, mapeo de flujos, integración de fuentes, control de accesos y trazabilidad. Es exactamente el terreno de un ingeniero de datos — y es distinto del trabajo legal, que sigue siendo de los abogados (políticas, contratos, interpretación jurídica).

En DataLovelace construimos esa capa técnica: el inventario, el RAT, el mapa de flujos y los controles que permiten demostrar cumplimiento ante una fiscalización, complementando a tu asesoría legal. El primer paso es un diagnóstico de brechas de alcance acotado: qué exige la ley, qué tienes hoy y cuánto te falta.

¿Necesitas explicárselo a la gerencia primero? Comparte la versión no técnica: Ley 21.719: qué es, a quién aplica y por qué diciembre de 2026 te concierne →