Si tratas datos personales en Chile, hay dos preguntas que tu organización deberá poder responder con documentos a partir de diciembre de 2026: ¿dónde está tu registro de actividades de tratamiento? y ¿cómo gestionas el riesgo de cada tratamiento? Ese mes entra en plena vigencia la Ley 21.719, la nueva ley chilena de protección de datos personales — alineada al GDPR europeo — que crea la Agencia de Protección de Datos Personales. El detalle fino del régimen sancionatorio y sus plazos conviene validarlo con asesoría legal chilena; lo que no admite dudas es la fecha, y que la ley pide evidencia, no promesas.
Ya publicamos el panorama regional: por qué Chile y Brasil están convirtiendo el gobierno de datos en requisito, y cómo se ve el costo de no cumplir. Este artículo baja un nivel: qué artefactos concretos exige la ley chilena, y cómo un programa de gobierno de datos los produce y — más importante — los mantiene vivos.
La ley no pide intenciones: pide artefactos
El corazón de la Ley 21.719 es el principio de responsabilidad proactiva (accountability): no basta con tratar bien los datos, hay que poder demostrarlo documentalmente. En la práctica, esa demostración se concentra en tres artefactos.
1. El RAT — Registro de Actividades de Tratamiento. Un inventario vivo de cada tratamiento de datos personales de la organización. La guía oficial de la Secretaría de Gobierno Digital (RAT v1.0, publicada en noviembre de 2025) define su estructura en campos concretos: actividad · responsable o encargado · categoría de datos · universo de titulares · finalidad · base de legitimidad · destinatarios previstos · período de conservación · fuente de los datos. La guía está formulada para órganos públicos, pero su estructura es hoy la referencia práctica para cualquier responsable que deba acreditar responsabilidad proactiva.
2. El análisis y gestión de riesgo. Por cada tratamiento, evaluar probabilidad × impacto sobre los derechos de los titulares y asignar un nivel de riesgo (muy alto, alto, medio, bajo) a partir de un catálogo de factores: tipos de datos, alcance del tratamiento, categorías de titulares, factores técnicos. La salida típica es una matriz o mapa de calor de riesgo. Un matiz honesto: Chile aún no publica una guía oficial de gestión de riesgo equivalente a la del RAT; en la práctica se usa como referencia la metodología de la agencia española (AEPD), alineada a GDPR — un enfoque razonable que de todas formas conviene validar con asesoría legal local.
3. La EIPD — evaluación de impacto (DPIA). Cuando un tratamiento es de alto riesgo, la ley exige una evaluación documentada que justifique las medidas adoptadas y el riesgo residual aceptado. Qué tratamientos la gatillan exactamente es un detalle que recomendamos validar con asesoría legal chilena — pero la lógica es clara: la EIPD se apoya en los dos artefactos anteriores.
Hay más obligaciones (derechos de los titulares, medidas de seguridad, gestión de brechas), pero estos tres artefactos concentran la mayor brecha entre lo que las organizaciones tienen hoy y lo que deberán mostrar.
Por qué un documento estático no basta
La tentación obvia es tratar esto como un proyecto documental: encargar la elaboración del RAT, llenar la matriz en un taller, archivar los tres PDF y declararse cumplido.
El problema es de física, no de voluntad. Los tres artefactos describen sistemas que cambian cada semana: se contrata un SaaS nuevo, un equipo agrega un campo al CRM, marketing lanza una campaña con otra fuente de datos, alguien copia una tabla con RUT a un ambiente de analítica. El RAT de marzo es ficción en septiembre. Y un registro que contradice la realidad de tus sistemas no demuestra gestión — demuestra lo contrario.
Por eso las organizaciones que ya pasaron por revisiones bajo regímenes tipo GDPR descubren que el problema nunca fue redactar el documento: fue mantenerlo verdadero. Y eso no se resuelve con más consultoría documental; se resuelve desde la operación de datos misma.
Cómo un programa de gobierno produce cada artefacto
Un programa de gobierno de datos — estructurado con marcos como DAMA-DMBOK y DCAM — construye exactamente las capacidades de las que estos artefactos son vistas. (Si el concepto es nuevo, aquí lo explicamos desde cero.) El mapeo es directo.
El RAT es una vista de tu catálogo de datos. Repasa los campos: la categoría de datos sale del inventario y la clasificación (etiquetado de PII en todos los sistemas, no solo el CRM); el responsable sale del ownership (cada activo de datos con un dueño con nombre y rol); finalidad, base de legitimidad, destinatarios, conservación y fuente salen de la metadata de negocio — glosario, propiedades, políticas de ciclo de vida — que el programa documenta activo por activo. Cuando esa base existe y se alimenta de forma automatizada — con el catálogo nativo de tu nube o uno open-source como OpenMetadata; la herramienta importa menos que el programa — el RAT deja de ser un proyecto y pasa a ser un reporte: una vista que se ensambla desde metadata viva.
La matriz de riesgo consume clasificación, calidad y linaje. Evaluar probabilidad × impacto exige saber qué tipos de datos hay (clasificación), a cuántos titulares alcanza el tratamiento (inventario), quién accede y bajo qué políticas (ownership y controles), y por dónde fluyen los datos (linaje). Sin esos insumos, el scoring de riesgo es una opinión en un taller. Con ellos, es un método repetible: cuando cambia un sistema cambia el insumo, y la matriz se recalcula en lugar de quedar obsoleta.
La EIPD se para sobre las dos anteriores. Una evaluación de impacto justifica medidas frente a riesgos identificados: el RAT dice qué es el tratamiento, la matriz dice por qué es de alto riesgo, el linaje muestra los flujos reales y la calidad de datos evidencia los controles que efectivamente operan. El programa no redacta la EIPD por ti — es un ejercicio de proceso y juicio legal — pero convierte semanas de arqueología de datos en días de análisis, con la evidencia lista para el anexo.
La palabra clave en los tres casos es sostenible: el programa incluye los procesos — revisión periódica, alta de nuevos tratamientos, data owners responsables de actualizar su parte — que mantienen los artefactos verdaderos entre auditoría y auditoría. Eso es lo que aporta un marco como DAMA-DMBOK: no una herramienta, sino la disciplina de cultura, organización, procesos y tecnología operando juntas.
Lo que la tecnología no resuelve sola
Seríamos poco serios si dijéramos que esto se compra instalado. Tres cosas que ningún software resuelve por sí mismo:
- El ownership es una decisión organizacional. Nombrar responsables de datos, darles mandato y tiempo, y sostener un comité que arbitre — eso es cultura y organización, no configuración.
- La base de legitimidad es juicio legal. Qué base de licitud aplica a cada tratamiento, qué gatilla una EIPD obligatoria, cómo interpretar plazos y sanciones en detalle — eso lo define tu asesoría legal, no una plataforma. Nuestro trabajo es que, cuando el abogado pregunte, la evidencia exista y sea confiable.
- El proceso pesa más que el software. Un catálogo sin programa produce evidencia vacía: dashboards que nadie actualiza y un RAT tan ficticio como el Excel que reemplazó.
Un programa bien diseñado integra estas tres capas desde el día uno — por eso hablamos de programa y no de implementación.
Diciembre de 2026 está más cerca de lo que parece
Construir inventario, ownership, clasificación y linaje toma meses, no semanas — y la fecha no se mueve. La pregunta correcta hoy no es "¿qué herramienta compro?", sino "¿qué tengo ya gobernado y qué está huérfano?".
Nuestra evaluación de madurez de datos responde exactamente eso: un diagnóstico honesto de dónde está tu organización frente a lo que la Ley 21.719 va a pedirle — qué artefactos puedes producir hoy, cuáles no, y la hoja de ruta para cerrar la brecha con tiempo.
Fuentes: Registro de Actividades de Tratamiento — Wikiguías, Secretaría de Gobierno Digital