Compliance

RAT vs DPIA: cuándo necesitas cada uno (y cuándo ambos)

juan@preyhq.com
Juan O.
May 22, 2026
0 minutos de lectura
RAT vs DPIA: cuándo necesitas cada uno (y cuándo ambos)
TL;DR

Lo que necesitas saber sobre RAT vs DPIA

  • RAT: Inventario vivo de qué datos tratas, por qué, dónde y por cuánto tiempo. Obligatorio para casi todas las organizaciones bajo GDPR (Art. 30) y Ley 21.719 (Art. 15).
  • DPIA (EIPD): Análisis previo de los riesgos que un tratamiento concreto introduce para los derechos del titular. Solo obligatoria para tratamientos de alto riesgo (biometría, geolocalización masiva, decisiones automatizadas, datos de menores, vigilancia sistemática).
  • La diferencia útil: El RAT describe; la DPIA evalúa. La mayoría de las organizaciones necesitan RAT siempre y DPIA solo para tratamientos específicos.
  • La trampa: Si tienes RAT al día pero un tratamiento de alto riesgo sin DPIA, la sanción cae sobre la DPIA omitida. Hasta 300.000 € en España o 20.000 UTM en Chile.
  • Lo que aprueba el auditor: No es la documentación, es la evidencia operativa de que los controles documentados existen en los dispositivos donde viven los datos.

El RAT y la DPIA o EIPD son los dos documentos que la mayoría de los equipos de cumplimiento confunden y los dos que la mayoría de los auditores piden primero. Uno documenta lo que se hace con los datos. El otro documenta qué podría salir mal al procesarlos. Suenan parecidos. No lo son. Y necesitas saber cuándo te toca cada uno antes de que la Agencia te pregunte por ellos.

La confusión no es casualidad. La normativa mezcla "registro," "inventario," "evaluación" y "análisis de riesgos" en párrafos contiguos. Tu equipo legal te dice: "Haz ambos." Tu directiva pregunta "¿No es lo mismo?" Tu equipo de TI recibe un correo que pide "documentar los tratamientos" sin explicar qué significa eso en la práctica. Y nadie en la cadena tiene incentivo para preguntar.

El costo de equivocarse es desigual. Una RAT mal hecha constituye una infracción administrativa que puede corregirse. Una DPIA omitida cuando era obligatoria constituye una infracción grave: hasta 20.000 UTM en Chile, según la Ley 21.719. Pero el problema más caro no es la sanción. Es descubrir, durante una fiscalización, que los controles que documentaste no se reflejan en los dispositivos donde realmente reside la información.

En este artículo aclaramos qué es cada documento, cuándo necesitas el RAT, cuándo necesitas una DPIA, cuándo necesitas ambos y cómo sostenerlos sin que se conviertan en papelería que envejece en un cajón mientras tu flota sigue cambiando.

Qué es el RAT y qué es la DPIA, sin enredos legales

El RAT, o Registro de Actividades de Tratamiento, es un inventario vivo. No es un documento que rellenas una vez y luego archivas. Es la fotografía permanente de qué datos personales trata tu organización, con qué finalidad, en qué bases de datos viven, quién los procesa, a quién se transfieren, y por cuánto tiempo se conservan. Su base legal es el artículo 30 del GDPR para España y el resto de la UE, y el artículo 15 de la Ley 21.719 para Chile.

La DPIA (Data Protection Impact Assessment), llamada EIPD en español (Evaluación de Impacto en Protección de Datos), es algo distinto. No describe; evalúa. Es un análisis previo a un tratamiento concreto que identifica los riesgos que este introduce para los derechos del titular y las medidas técnicas y organizativas que vas a aplicar para mitigarlos. Su base es el artículo 35 del GDPR y el artículo 14 quáter de la Ley 21.719.

La diferencia más simple que existe: el RAT describe lo que haces. La DPIA evalúa qué podría salir mal al hacerlo. El RAT es continuo; la DPIA es por tratamiento específico. El RAT es casi universal; la DPIA solo aplica cuando el tratamiento es de alto riesgo.

Si tu organización procesa datos personales y tiene 250 o más empleados, el RAT es obligatorio sin excepciones. Si procesas datos sensibles (salud, biometría, ideología), también lo es aunque seas más pequeño. Si tu tratamiento implica decisiones automatizadas, vigilancia sistemática, perfilado a escala, o cruza categorías sensibles con volumen, la DPIA entra en juego.

Si operas entre España y Chile, esta es la traducción rápida del vocabulario:

Concepto GDPR (España) Ley 21.719 (Chile)
Inventario de tratamientos RAT (Art. 30) Registro de actividades de tratamiento (Art. 15)
Análisis de impacto EIPD / DPIA (Art. 35) EIPD (Art. 14 quáter)
Autoridad fiscalizadora AEPD (Agencia Española de Protección de Datos) Agencia de Protección de Datos

Quick win: Si no sabes cuál de los dos te corresponde, parte por el RAT. Es la base de cualquier programa de cumplimiento y el punto de partida para identificar después qué tratamientos disparan una DPIA.

Lectura relacionada
Cómo crear un RAT desde cero
Elaborar un registro de actividades paso a paso.

Tabla comparativa: RAT vs DPIA en una página

Dimensión RAT (Registro de Actividades) DPIA / EIPD (Evaluación de Impacto)
Pregunta que responde ¿Qué datos trato y cómo? ¿Qué riesgos introduce este tratamiento y cómo los mitigo?
Tipo de documento Inventario continuo y descriptivo. Análisis estratégico y preventivo previo al tratamiento.
Frecuencia Permanente y actualizable ante cualquier cambio técnico. Por proyecto o tratamiento específico de alto riesgo.
Obligatorio para Casi todas las organizaciones (salvo excepciones muy acotadas). Solo tratamientos que impliquen un riesgo alto intrínseco.
Quién lo elabora DPO en coordinación con TI y Compliance. DPO con TI, áreas de negocio afectadas y expertos externos.
Base legal (España) Art. 30 GDPR Art. 35 GDPR
Base legal (Chile) Art. 15 Ley 21.719 Art. 14 quáter Ley 21.719
Sanción por omisión Infracción leve a grave. Infracción grave (€40k–€300k / hasta 20.000 UTM).
Foco principal Descriptivo e informativo. Evaluativo y mitigador de riesgos.

La diferencia operativa que la tabla no muestra es esta: el RAT es quien vive con tu organización todos los días. La DPIA es la que se realiza cuando vas a hacer algo nuevo o de mayor riesgo. Si introduces un sistema de control biométrico de acceso, abres una nueva oficina con cámaras de vigilancia, o lanzas una app que perfila el comportamiento de usuarios, la DPIA entra en escena antes de que el tratamiento empiece. No después.

Para la ejecución detallada del análisis de impacto, hay material específico sobre cómo elaborar una DPIA siguiendo una metodología paso a paso.

Cuándo necesitas cada uno

La pregunta operativa nunca es "¿Qué dice la ley." Es: "¿Qué me toca a mí hoy con los tratamientos que tengo?”

El árbol de decisión es más simple de lo que parece:

  1. ¿Tu organización trata datos personales? Si la respuesta es sí, el RAT es obligatorio.
  2. ¿Algún tratamiento cumple con criterios de alto riesgo? Los indicadores son concretos: datos sensibles a escala (salud, biometría, origen étnico), decisiones automatizadas con efecto jurídico, vigilancia sistemática de espacios públicos, perfilado a escala, geolocalización masiva, datos de menores, o combinaciones de categorías que multiplican el riesgo.
  3. Si un tratamiento cumple esos criterios, la DPIA es obligatoria, además del RAT. Si no los cumple, solo te toca el RAT.

Hay casos límite en los que la DPIA es una buena práctica aunque no sea estrictamente obligatoria: cambios de proveedor de cloud que mueven datos a otra jurisdicción, lanzamiento de software propio que procesa datos personales, expansión geográfica a un país con un marco regulatorio distinto, integración de IA con toma de decisiones automatizada. En esos casos, realizar una DPIA es una medida defensiva. Cuesta poco frente al costo de tener que justificar después por qué no la hiciste.

Cómo se conectan en la práctica (la parte que nadie te explica)

Los dos documentos no son islas. Se alimentan el uno al otro.

El RAT es el repositorio inicial. Identifica todos los tratamientos que tu organización realiza. La DPIA usa el RAT como punto de partida: revisa el inventario, identifica qué tratamientos cumplen los criterios de alto riesgo y realiza la evaluación. Sin RAT actualizado, no puedes saber dónde tienes que aplicar DPIA.

La relación inversa también existe. Cuando una DPIA propone medidas de mitigación (cifrado obligatorio, control de acceso por roles, borrado remoto en caso de pérdida), estas son controles técnicos y organizativos que también deben figurar en la entrada correspondiente del RAT. Si la DPIA dice una cosa y el RAT otra, el documento que le importa al auditor es el que coincida con la realidad. Si ninguno coincide, peor.

El tercer flujo es el que más se rompe: cuando el RAT cambia, debe revisarse si dispara una DPIA nueva. Nuevo proveedor de procesamiento, nueva categoría de datos, nueva finalidad, expansión a otro país. Si tratas el RAT como una lista que se actualiza, pero no lo conectas con tu proceso de DPIAs, llegarás a la siguiente fiscalización con un RAT al día y DPIAs faltantes para tratamientos que han cambiado.

Sin esta retroalimentación bidireccional, ambos documentos se convierten en papelería estática. Aparecen en la auditoría de hace dos años, sin reflejar lo que hace tu organización hoy. Y entonces el auditor deja de leer la documentación y empieza a pedir evidencia: es el momento en que el cumplimiento real se separa del cumplimiento en papel.

Los equipos que lo sostienen bien tienen tres prácticas en común.

  • Primero, asignan un dueño operativo a cada actividad del RAT, no solo el dueño del documento global.
  • Segundo, tienen un calendario fijo de revisión (mínimo anual; idealmente, trimestral).
  • Tercero, conectan el proceso de cambio: cualquier modificación al RAT pasa por una pregunta automática sobre si requiere una DPIA.

Para auditorías, lo que importa es la trazabilidad: la evidencia operativa que respalda el cumplimiento cierra el ciclo entre la documentación y la realidad.

Cómo el control operativo de dispositivos sostiene el RAT y la DPIA

Aquí es donde la mayoría de los programas de cumplimiento se caen.

Un RAT creíble no puede decir "los datos viven en endpoints corporativos" como si fuera una abstracción. Tiene que poder demostrarlo, dispositivo por dispositivo, cuando el auditor lo pregunte. Una DPIA con mitigaciones técnicas (cifrado, borrado remoto, control de acceso) necesita evidencia de que esos controles están activos hoy, no de que existían cuando se redactó la DPIA hace 8 meses. La fiscalización no pregunta "¿Documentaron cifrado?" Pregunta: "Demuéstrenme que los 25 laptops del área comercial están cifrados ahora mismo."

Sin visibilidad operativa de los dispositivos, ambos documentos se convierten en hipótesis. Aspiraciones. Papel mojado.

Los controles que aparecen documentados deben ser auditables en tiempo real: estado de cifrado por dispositivo, capacidad de bloqueo y borrado remotos que funcionen realmente cuando se ejecuten, inventario actualizado de hardware y software, ubicación e historial, registro de incidentes con timestamps. Eso es la capa operativa. Sin ella, la DPIA es humo.

El segundo escenario operativo lo ilustra. Una empresa actualiza su RAT con la actividad "tratamiento de datos financieros de clientes." En la columna de medidas técnicas escribe: "almacenamiento cifrado en endpoints corporativos." El auditor llega y pide evidencia de que el cifrado está activo en las 25 laptops del área comercial. El equipo de TI no tiene cómo demostrarlo. Saben que la mayoría de los equipos tienen BitLocker, pero no tienen un dashboard que muestre el estado de cada dispositivo, la fecha de la última verificación ni qué hacer con las 12 laptops que aparecen como "estado desconocido.” El RAT estaba bien. La DPIA estaba bien. La operación, no.

El tercer escenario va por el otro lado. Una universidad implementa una app móvil para alumnos donde los docentes acceden a notas y datos académicos. Hace su DPIA correctamente. Identifica el riesgo: pérdida de dispositivo del docente con datos sensibles de estudiantes. Documenta la mitigación: "borrado remoto y rastreo de equipos institucionales en caso de pérdida." Seis meses después, un docente reporta que dejó su laptop institucional en un Uber. El equipo de TI no tiene capacidad de borrado remoto activa en ese laptop porque la implementación quedó pendiente desde el cambio de proveedor anterior. La DPIA decía una cosa; la realidad operativa, otra.

Lo que cierra esta brecha es una categoría concreta de herramientas: plataformas de gestión y protección de endpoints con visibilidad continua. Mantienen inventario en tiempo real, monitorean estado de cifrado dispositivo a dispositivo, ejecutan acciones remotas (lock, wipe, factory reset) y dejan trazabilidad auditable de cada acción. Prey es un ejemplo de esta categoría: opera en Windows, macOS, Linux, Android, iOS y Chromebook, lo que importa cuando tu fleet es mixto, y genera reportes que un auditor puede leer.

Pero el punto no es la herramienta específica. El punto es que, sin esta capa, ni el RAT ni la DPIA son verificables operativamente. Cualquier plataforma que cumpla esta función sirve. Lo que no sirve es no tener ninguna y esperar que la documentación legal sea suficiente cuando la fiscalización revise los dispositivos.

Para profundizar más en el tema, hay material específico sobre control de dispositivos como evidencia de cumplimiento y los controles técnicos mínimos exigibles bajo la Ley 21.719.

Errores comunes al gestionar RAT y DPIA (y cómo evitarlos)

Los mismos patrones se repiten en organizaciones de todos los tamaños. Reconocerlos es la diferencia entre un programa de cumplimiento que sobrevive a la primera fiscalización y otro que no.

  • Tratar RAT y DPIA como entregables únicos en lugar de documentos vivos. Se hacen una vez, se archivan, y nadie los toca hasta que llega la auditoría. Para entonces, la realidad de la organización había cambiado tres veces.
  • Realizar un DPIA tras implementar el tratamiento. La ley exige que sea previa. Si tu app biométrica lleva ocho meses operando y recién ahora alguien dice "deberíamos hacer la DPIA," ya estás en infracción. La DPIA debe formar parte del go-live, no del post-mortem.
  • Copiar plantillas sin adaptarlas al tratamiento real. Las plantillas que existen en internet son un punto de partida, no entregables. Una DPIA con riesgos genéricos no protege a nadie y no convence a ningún fiscalizador.
  • Documentar los controles que el equipo de TI no puede verificar. Si tu DPIA dice "borrado remoto disponible para todos los dispositivos institucionales" y tu equipo de TI sabe que solo está activo en el 60% de tu flota, estás generando evidencia de tu propia infracción. La documentación que no se sostiene en operación no protege: incrimina.
  • No conectar los cambios del RAT con la revisión de DPIAs. Cambios menores se acumulan. Llega un momento en el que el RAT y las DPIAs se refieren a organizaciones distintas.
  • Tener el RAT en una hoja de cálculo de un solo dueño que se va de la empresa. Sin versionado, sin múltiples dueños, sin acceso del equipo. La baja de un colaborador clave puede dejar tu programa de cumplimiento ciego durante meses.
  • Confundir el RAT con el inventario de activos. El RAT es de tratamientos (qué haces con los datos), no de hardware (qué dispositivos tienes). Son inventarios distintos que se complementan, pero no son el mismo. Si tu RAT empieza con "lista de laptops corporativos," hay un problema de fondo.

Para una visión más amplia del programa completo, la hoja de ruta para cumplir la Ley 21.719 ordena las prioridades de aquí a la vigencia plena en diciembre de 2026.

Conclusión

El RAT y la DPIA no son documentos que compitan entre sí. Son dos capas del mismo sistema de cumplimiento. El RAT te dice qué datos tratas; la DPIA te dice qué podría salir mal al tratarlos. Necesitas el primero casi siempre, y el segundo cuando el riesgo lo justifica.

Pero la verdad operativa que ningún artículo dice es la siguiente: tener ambos documentos al día no acredita el cumplimiento. Lo que aprueba el cumplimiento es la evidencia de que los controles documentados existen, funcionan, y se pueden auditar en cada dispositivo donde viven los datos. Una DPIA que promete cifrado, pero no se traduce en visibilidad operativa de cifrado por dispositivo, no protege a nadie. Un RAT que dice que los datos viven en "endpoints corporativos" sin poder demostrarlo dispositivo a dispositivo es un papel firmado.

El paso concreto para empezar el lunes es simple: toma tus tres tratamientos más sensibles del RAT, identifica qué controles técnicos prometen sus DPIAs (o deberían prometerlas), y abre una hoja con dos columnas. En la primera, el control documentado. En la segunda, dónde y cómo lo verificas hoy. Las filas con la segunda columna vacía son tu primer plan de trabajo. Todo lo demás es ajustar la documentación a la realidad antes de que la realidad ajuste tu cumplimiento por ti.

Preguntas frecuentes

¿Una PyME pequeña necesita RAT y DPIA?

El RAT es obligatorio salvo que se cumplan tres condiciones simultáneas: menos de 250 empleados, tratamiento ocasional, y sin datos sensibles ni alto riesgo. En la práctica, casi todas las PyMEs lo necesitan. La DPIA solo aplica cuando el tratamiento es de alto riesgo, sin importar el tamaño de la organización.

¿Quién es responsable de elaborar el RAT y la DPIA?

El responsable del tratamiento es el responsable legal. Operativamente, el DPO (si existe) coordina, el equipo de TI aporta los datos técnicos, y las áreas de negocio describen los procesos. La DPIA además puede involucrar a expertos externos para tratamientos complejos que requieran evaluación técnica especializada. Para más contexto sobre el rol, hay material sobre el rol del DPO.

¿Una sola DPIA cubre múltiples tratamientos?

Sí, cuando los tratamientos comparten naturaleza, riesgo y medidas. Por ejemplo, una DPIA puede cubrir todo el sistema de gestión de empleados aunque incluya varios procesos relacionados. No tiene sentido hacer DPIAs separadas para tratamientos virtualmente idénticos. Lo que sí hay que hacer es revisar la DPIA cuando alguno de esos tratamientos cambie significativamente.

¿Hay diferencia entre la DPIA del GDPR y la EIPD de la Ley 21.719 chilena?

Conceptualmente son lo mismo: análisis previo de riesgo de un tratamiento para proteger los derechos del titular. La Ley 21.719 sigue muy de cerca el modelo GDPR. Las plantillas y metodologías europeas son aplicables con adaptaciones menores al contexto chileno y a las atribuciones específicas de la Agencia de Protección de Datos creada por la ley.

¿Cómo se actualiza el RAT cuando cambia un proveedor o un tratamiento?

Cualquier cambio significativo (nuevo proveedor, nueva categoría de datos, cambio de finalidad, nueva geografía) debe reflejarse en el RAT inmediatamente. Si el cambio modifica el perfil de riesgo del tratamiento, dispara una revisión de la DPIA correspondiente. La regla práctica: si cambia el "qué," "por qué," "dónde" o "con quién," se actualiza el RAT y se evalúa si hay que revisar la DPIA.