Armar un RAT es una cosa. Que ese RAT resista una fiscalización de la Agencia de Protección de Datos Personales es otra muy distinta. La mayoría de las organizaciones que ya empezaron con su Registro de Actividades de Tratamiento tienen el documento listo, pero con errores de fondo que solo se notan cuando alguien con criterio regulatorio lo revisa.
Un matiz importante: la Ley 21.719 no usa el término "RAT" de forma explícita ni lo exige como documento con ese nombre. Pero el artículo 14 ter impone obligaciones de transparencia que en la práctica hacen indispensable tener un registro estructurado: la organización debe mantener información completa, veraz y actualizada sobre sus tratamientos, y ponerla a disposición de la Agencia cuando esta lo requiera.
En otras palabras, la ley no dice "RAT", pero te obliga a tener todo lo que un RAT organiza.
Y ahí es donde aparecen los problemas reales. No estamos hablando de errores de formato o de olvidar una columna en la plantilla. Estamos hablando de problemas de contenido: finalidades tan vagas que no dicen nada, bases legales mal asignadas, transferencias internacionales que nadie registró, plazos de conservación que dicen "indefinido" y tratamientos completos que directamente no aparecen.
Estos errores no son menores. Un RAT con información genérica o incompleta no demuestra que tu organización conoce, controla y puede explicar cómo trata los datos personales. Si la Agencia pide ver tu registro y encuentra finalidades tipo "mejorar nuestros servicios" o bases legales copiadas de un template, el problema no es cosmético. Es sustantivo.
Esta guía repasa los errores más frecuentes que encontramos en RATs reales, explica por qué cada uno es una señal de alerta y te da criterios concretos para corregirlos.
Finalidades genéricas que no explican nada
Este es probablemente el error más extendido. Finalidades como "gestión de datos", "mejorar la experiencia del usuario" o "fines comerciales" aparecen en la mayoría de los RATs que se arman apurados. El problema es que no cumplen el principio de finalidad que establece la ley: los datos personales deben tratarse con propósitos específicos, explícitos y lícitos.
Una finalidad genérica hace imposible evaluar si el tratamiento es proporcional, si la base legal aplica o si los datos que se recolectan son los estrictamente necesarios. Además, si un titular ejerce su derecho de acceso o de oposición, una finalidad vaga dificulta responder con precisión qué se hace con sus datos y por qué.
Cómo se ve el error:
- "Gestión interna"
- "Fines administrativos"
- "Mejorar nuestros servicios"
- "Procesamiento de información"
Cómo debería verse:
- "Gestión de nómina y cálculo de remuneraciones de empleados"
- "Envío de comunicaciones comerciales a clientes que otorgaron consentimiento"
- "Verificación de identidad durante el proceso de onboarding de proveedores"
- "Análisis de uso del sitio web para optimización de rendimiento técnico"
La regla es simple: si lees la finalidad y no puedes entender exactamente qué tratamiento ocurre, está mal redactada. Cada finalidad debe ser lo suficientemente específica como para que alguien externo entienda qué datos se usan, para qué y en qué contexto.
Bases legales incorrectas o mal asignadas
La Ley 21.719 establece bases de licitud específicas para tratar datos personales. El consentimiento es solo una de ellas, pero en la práctica muchas organizaciones lo asignan como base legal por defecto a todos los tratamientos, incluso cuando no corresponde.
El problema con abusar del consentimiento es doble. Primero, si el consentimiento no cumple los requisitos que exige la ley (libre, informado, específico, inequívoco), ese tratamiento queda sin base legal válida. Segundo, hay tratamientos que tienen una base legal más apropiada y que no dependen de la voluntad del titular.
Errores frecuentes:
- Poner "consentimiento" como base legal para el procesamiento de remuneraciones (corresponde: ejecución de contrato o cumplimiento legal)
- Usar "interés legítimo" sin documentar la ponderación de intereses (la ley exige que el interés legítimo se justifique y no prevalezca sobre los derechos del titular)
- Asignar "cumplimiento legal" a tratamientos comerciales que no tienen obligación normativa detrás
- Usar la misma base legal para todos los tratamientos del RAT, sin diferenciar
Cómo corregirlo:
Para cada tratamiento en tu RAT, pregunta: cuál es la razón legal que habilita este procesamiento. Las principales bases bajo la Ley 21.719 son:
- Consentimiento del titular
- Ejecución o negociación de un contrato
- Cumplimiento de una obligación legal (ejemplo: reportes a la Unidad de Inteligencia Financiera o declaraciones ante el Servicio de Impuestos Internos)
- Protección de intereses vitales (ejemplo: compartir datos de salud de un trabajador con el SAMU en una emergencia)
- Interés legítimo del responsable (con ponderación documentada; ejemplo: videovigilancia en oficinas para seguridad patrimonial)
- Datos de fuente de acceso público (ejemplo: información del Conservador de Bienes Raíces o del Diario Oficial)
- Interés público o ejercicio de funciones públicas
Si tu RAT tiene una sola base legal repetida en todas las filas, es una señal clara de que no se hizo el análisis caso a caso.
Transferencias internacionales que nadie registró
Aquí hay un punto ciego que afecta a casi todas las organizaciones y que pocas detectan al armar su RAT: las transferencias internacionales de datos. Si tu empresa usa Salesforce, Google Workspace, AWS, HubSpot o cualquier plataforma SaaS con servidores fuera de Chile, hay transferencia internacional. Y si eso no aparece en tu RAT, tienes un problema.
La Ley 21.719 regula las transferencias internacionales de datos personales con requisitos específicos. El país de destino debe ofrecer un nivel de protección adecuado, o en su defecto deben existir garantías apropiadas (cláusulas contractuales, normas corporativas vinculantes, consentimiento expreso del titular).
Lo que suele faltar en el RAT:
- Identificación del país de destino de los datos
- Nombre del proveedor o encargado que recibe los datos en el extranjero
- Mecanismo de legitimación de la transferencia (decisión de adecuación, cláusulas contractuales tipo, consentimiento)
- Categorías de datos que se transfieren
Cómo identificar transferencias que probablemente no están documentadas:
- Herramientas de marketing y CRM (HubSpot, Mailchimp, ActiveCampaign)
- Almacenamiento cloud (AWS, Google Cloud, Azure)
- Plataformas de RRHH y nómina SaaS
- Herramientas de comunicación (Slack, Teams, Zoom)
- Servicios de soporte y ticketing
El ejercicio es directo: revisa cada proveedor tecnológico de tu organización y verifica dónde procesan o almacenan datos. Si la respuesta es "fuera de Chile", debe estar en el RAT con su mecanismo de legitimación correspondiente.
Plazos de conservación indefinidos o inexistentes
"Mientras sea necesario" o "según política interna" no son plazos de conservación. Son formas elegantes de decir que nadie ha pensado cuánto tiempo se guardan los datos. Y bajo la Ley 21.719, el principio de limitación de la conservación exige que los datos se mantengan solo durante el tiempo necesario para cumplir la finalidad para la que fueron recolectados.
Un RAT sin plazos definidos genera dos problemas concretos. Primero, imposibilita cumplir con solicitudes de supresión. Segundo, si ocurre un incidente de seguridad, el volumen de datos expuestos es mayor del necesario porque la organización acumula información sin criterio de descarte.
Errores típicos:
- "Indefinido"
- "Según necesidad operativa"
- "Mientras dure la relación comercial" (sin definir qué pasa después)
- Campo vacío
Cómo debería verse:
- "5 años desde el término de la relación laboral (obligación legal tributaria y laboral)"
- "2 años desde la última interacción comercial, luego anonimización"
- "6 meses desde la finalización del proceso de selección, salvo consentimiento para bolsa de trabajo (12 meses adicionales)"
- "Duración del contrato de servicio + 1 año para defensa legal"
La clave es vincular cada plazo con una justificación: obligación legal, necesidad contractual, o criterio proporcional definido por la organización. Si no puedes explicar por qué guardas los datos durante ese período, el plazo probablemente está mal definido.
Tratamientos completos que no aparecen en el RAT
Un RAT incompleto es peor que no tener RAT, porque genera una falsa sensación de cumplimiento. Los tratamientos que más frecuentemente quedan fuera son los que ocurren "en los bordes" de la operación: procesos informales, herramientas adoptadas sin pasar por TI, o flujos de datos que nadie percibe como tratamiento de datos personales.
Tratamientos que suelen quedar fuera:
- Videovigilancia con cámaras de seguridad (CCTV)
- Control de asistencia con datos biométricos (huella, rostro)
- Monitoreo de dispositivos corporativos (geolocalización, actividad)
- Bases de datos de candidatos en procesos de reclutamiento
- Grabaciones de llamadas telefónicas o videollamadas
- Datos recolectados en eventos presenciales (formularios en papel, tablets)
- Cookies y tracking en sitios web y apps
- Datos de visitantes en recepciones o control de acceso físico
Cada uno de estos es un tratamiento de datos personales que requiere base legal, finalidad definida, plazo de conservación y medidas de seguridad. Si no están en el RAT, la organización no puede demostrar cumplimiento sobre ellos.
Cómo detectarlos:
La forma más efectiva es hacer un mapeo área por área, preguntando no solo "qué datos manejan" sino "qué herramientas usan" y "qué información recolectan en su operación diaria". Los talleres internos con cada departamento siguen siendo el mejor método. Si ya creaste tu RAT y quieres validar que no falten tratamientos, nuestra guía para crear el RAT desde cero incluye el proceso de mapeo paso a paso.
No documentar medidas de seguridad por tratamiento
Muchos RATs incluyen una referencia genérica a "medidas de seguridad" que aplica por igual a todos los tratamientos: "cifrado", "control de acceso", "antivirus". Pero la Ley 21.719 exige que las medidas de seguridad sean proporcionales al riesgo de cada tratamiento. No es lo mismo proteger un listado de correos de marketing que una base de datos de salud ocupacional.
Lo que suele faltar:
- Diferenciación de medidas por nivel de riesgo del tratamiento
- Vinculación entre tipo de dato (sensible, general, financiero) y control específico
- Estado real de implementación de la medida (activa, planificada, no implementada)
- Referencia a la capacidad de verificación de la medida
Lo mínimo que debería documentarse por tratamiento:
- Cifrado: ¿el dato está cifrado en tránsito y en reposo? ¿Con qué estándar?
- Control de acceso: ¿quién tiene acceso y bajo qué criterio?
- Trazabilidad: ¿existe log de quién accede y cuándo?
- Respaldo: ¿hay backup? ¿Con qué frecuencia?
- Capacidad de respuesta: ante pérdida o robo del dispositivo donde residen estos datos, ¿se puede actuar remotamente?
Este último punto es donde la gestión de endpoints se vuelve relevante. Si tu RAT declara que los datos de nómina están protegidos con cifrado en los laptops de RRHH, pero no tienes forma de verificar que BitLocker esté activo en esos equipos, la medida es declarativa. La Agencia puede pedir evidencia, y "creemos que está activo" no es evidencia.
El RAT como señal de alerta temprana
Un RAT bien construido no es solo un documento de compliance. Es una herramienta de diagnóstico que revela dónde están las vulnerabilidades reales de tu programa de privacidad. Cada error de los que describimos arriba es, en realidad, una señal de alerta que apunta a un problema mayor:
- Finalidades genéricas indican que no hay claridad sobre para qué se usan los datos
- Bases legales incorrectas revelan que no se hizo análisis jurídico por tratamiento
- Transferencias omitidas muestran falta de visibilidad sobre el ecosistema de proveedores
- Plazos indefinidos evidencian ausencia de política de retención y descarte
- Tratamientos no documentados señalan puntos ciegos operativos
- Medidas genéricas sugieren que la seguridad no se evalúa caso a caso
Si corriges estos errores, no solo mejoras el RAT. Fortaleces todo el programa de cumplimiento, porque cada corrección implica tomar una decisión informada sobre cómo tu organización trata datos personales.
Y si estás construyendo o revisando un Modelo de Prevención de Infracciones (MPI), el RAT es su columna vertebral. Un MPI con un RAT deficiente no va a pasar la certificación ante la Agencia.
Dónde entra Prey en la corrección de tu RAT
Varios de los errores que revisamos tienen un componente técnico que no se resuelve solo con mejor redacción. Cuando tu RAT declara medidas de seguridad, necesitas poder demostrarlas. Cuando registras tratamientos que involucran dispositivos, necesitas visibilidad sobre qué pasa en esos endpoints.
Prey le da a los equipos de TI las herramientas para respaldar lo que el RAT declara:
- Inventario de dispositivos en tiempo real: sabes qué equipos existen, quién los usa y en qué estado están. Eso alimenta directamente la columna de medidas de seguridad del RAT.
- Verificación de cifrado: puedes confirmar, dispositivo por dispositivo, si BitLocker o FileVault está activo. Eso transforma una declaración ("todos los equipos están cifrados") en evidencia auditable.
- Respuesta ante incidentes: si un equipo con datos personales se pierde, puedes ejecutar bloqueo o borrado remoto y generar un reporte con marca de tiempo. Eso es exactamente lo que la Agencia espera ver cuando evalúa si las medidas de seguridad eran proporcionales al riesgo.
- Geofencing y alertas: si tu RAT registra tratamientos que no deben salir del territorio nacional, las alertas de zona te avisan cuando un dispositivo cruza los límites configurados.
No se trata de agregar otra herramienta al stack. Se trata de que el RAT deje de ser un documento que dice lo que debería pasar y pase a reflejar lo que efectivamente ocurre en los dispositivos de tu organización.
Si estás revisando tu RAT y necesitas cubrir el frente de endpoints, agenda una demo para ver cómo Prey se integra con tu estrategia de cumplimiento.
Preguntas frecuentes
Cuáles son los errores más comunes en un RAT bajo la Ley 21.719?
Los más frecuentes son: finalidades genéricas que no especifican el propósito real del tratamiento, bases legales asignadas por defecto sin análisis individual, transferencias internacionales no documentadas (especialmente a proveedores SaaS), plazos de conservación indefinidos y tratamientos completos que no aparecen en el registro.
Cómo sé si mi RAT está mal hecho?
Una revisión rápida: si todas las filas tienen la misma base legal, si las finalidades usan frases como "fines comerciales" o "gestión interna", si no hay plazos numéricos de conservación, o si no aparecen proveedores cloud internacionales, tu RAT probablemente necesita correcciones.
Qué pasa si la Agencia encuentra errores en mi RAT durante una fiscalización?
Un RAT incompleto o con información genérica puede ser considerado incumplimiento del deber de registro. Dependiendo de la gravedad, la Agencia puede calificarlo como infracción leve o grave, con multas de hasta 10.000 UTM. Además, un RAT deficiente debilita cualquier defensa ante una sanción por otro tipo de infracción.
Cada cuánto debería revisar y actualizar mi RAT?
Al menos trimestralmente, y siempre que ocurra un cambio relevante: nuevo proveedor, nueva herramienta, nuevo flujo de datos, cambio en la estructura organizacional o modificación regulatoria. Un RAT que no se actualiza al menos dos veces al año probablemente ya tiene información obsoleta.
Puedo usar una plantilla para armar mi RAT?
Sí, las plantillas son un buen punto de partida, pero no las copies sin adaptar. Cada organización tiene tratamientos, bases legales y proveedores distintos. Una plantilla te da la estructura; el contenido debe reflejar tu realidad operativa. Si necesitas una base, nuestra guía para crear el RAT desde cero incluye una plantilla adaptada a la Ley 21.719.
Qué relación tiene el RAT con el Modelo de Prevención de Infracciones?
El RAT es uno de los 9 elementos obligatorios del MPI. Sin un RAT robusto, no puedes construir la matriz de riesgo que el MPI exige, ni demostrar ante la Agencia que conoces tu ecosistema de datos. Un RAT con errores debilita directamente la certificación del MPI.
