EL RAT no se improvisa: por qué necesita primero sus inventarios de TI

La Ley 21.719 de Protección de Datos Personales entra en vigencia en diciembre de 2026 y trae consigo una obligación que muchas organizaciones aún subestiman: el Registro de Actividades de Tratamiento, o RAT. Es el documento que la Agencia de Protección de Datos Personales exigirá para acreditar, de forma concreta y verificable, qué datos personales trata la empresa, con qué finalidad, quién los recibe, dónde se almacenan y qué medidas de seguridad los protegen.

El error más común que se observa en las empresas que están comenzando su proceso de adecuación es tratar el RAT como un ejercicio de llenado de formularios: una planilla con columnas de "finalidad", "base de licitud" y "plazo de conservación" que alguien completa desde su memoria o entrevistando rápidamente a un par de jefaturas. El resultado es previsible: un registro incompleto, desactualizado y que no resiste una fiscalización ni, peor aún, no sirve para reaccionar cuando ocurre un incidente de seguridad y hay que notificar en 72 horas.

Un RAT confiable no nace de una entrevista. Nace de un inventario.

Sin estos 4 inventarios, el RAT no se sostiene ante una investigación

Del proceso de negocio al dato personal

Todo tratamiento de datos personales ocurre dentro de un proceso de negocio: reclutar personal, facturar a un cliente, gestionar una postventa, ejecutar una campaña de marketing, administrar una nómina. Si la empresa no tiene mapeados sus procesos, no puede identificar con precisión en qué puntos se capturan, transforman o transfieren datos personales, y el RAT terminará describiendo actividades genéricas ("gestión de clientes") en lugar de actividades reales y trazables.

El primer inventario, entonces, es el de procesos de negocio: qué procesos existen, quién es su dueño, qué información de entrada y salida manejan, y en qué etapa intervienen datos de clientes, colaboradores, proveedores o terceros. Este mapeo de procesos es, en rigor, un ejercicio de gestión que debería existir independientemente de la ley de datos, pero que la 21.719 convierte en un insumo obligatorio.

Del proceso al sistema que lo soporta

Ningún proceso relevante hoy se ejecuta sin un sistema de información detrás: un ERP, un CRM, un sistema de remuneraciones, una plataforma de e-commerce, una herramienta de firma electrónica. Cada uno de esos sistemas es, desde la perspectiva de la ley, un lugar donde residen datos personales y donde deben aplicarse medidas de seguridad técnicas y organizativas.

Por eso el segundo inventario necesario es el de aplicaciones y sistemas: qué software soporta cada proceso, quién lo administra, si es propio o de un proveedor externo (lo que activa la figura del encargado de tratamiento), dónde están alojados los servidores y si hay transferencias internacionales de datos. Sin este catastro, la columna del RAT que pregunta "¿dónde se almacenan los datos?" o "¿existen transferencias a terceros países?" queda respondida a medias o directamente en blanco.

Del sistema a la licencia

Un tercer nivel, menos obvio pero igual de crítico, es el de las licencias de software. Saber qué sistemas existen no basta si no se sabe quién tiene autorización para usarlos, bajo qué contrato, con qué condiciones de soporte y con qué vigencia. Este inventario de licencias es lo que permite responder, con evidencia, preguntas de gobierno de datos como quién puede acceder a qué información, qué proveedores tienen contratos vigentes que los constituyen en encargados de tratamiento, y si existe software no autorizado (shadow IT) procesando datos personales fuera del control de la empresa. La Ley 21.719 exige poder demostrar el control sobre estos accesos, y ese control comienza en un registro de licencias ordenado, no en el recuerdo de quién instaló qué.

Del usuario al equipo físico

El cuarto inventario, y probablemente el más ignorado en los proyectos de cumplimiento, es el de hardware: qué equipo usa cada colaborador, con qué número de serie, en qué proceso interviene y qué nivel de acceso a datos personales tiene asociado. Este nivel de detalle no es un capricho administrativo.

Es la base para demostrar medidas de seguridad concretas (cifrado de equipos, control de acceso físico, gestión de dispositivos móviles) y, sobre todo, es indispensable cuando ocurre un incidente: ante una filtración o pérdida de información, la empresa debe poder identificar en minutos qué equipo, de qué usuario y con qué acceso estuvo involucrado, para cumplir con el plazo de notificación de 72 horas que exige la ley.

Un RAT que no se apoya en un inventario de hardware trazable por usuario y número de serie es, en la práctica, una promesa de cumplimiento que no se puede sostener frente a un incidente real.

La secuencia correcta

En síntesis, el camino hacia un RAT defendible sigue una secuencia lógica y no puede saltarse pasos: primero se inventarían los procesos de negocio, porque ahí nace el tratamiento de datos; luego las aplicaciones y sistemas que los soportan, porque ahí residen los datos; después las licencias de software, porque de ahí surge el control de acceso y la relación contractual con terceros; y finalmente el hardware asignado a cada usuario, porque ahí se juega la seguridad física y la capacidad de reacción ante incidentes. El RAT es, en el fondo, la consolidación ordenada de estos cuatro inventarios traducida al lenguaje que exige la autoridad.

Cómo CumpleDatos Enterprise resuelve esta secuencia

Esta es exactamente la lógica sobre la que está construido CumpleDatos Enterprise: una solución desarrollada en FileMaker que no parte generando el RAT como un formulario aislado, sino que estructura primero los cuatro inventarios —procesos de negocio, aplicaciones y sistemas, licencias de software y hardware por usuario y número de serie— como módulos interrelacionados de una misma base de datos.

Esto significa que cada proceso queda vinculado a los sistemas que lo soportan, cada sistema queda vinculado a sus licencias y contratos, y cada licencia queda vinculada al equipo y al usuario que la utiliza. Cuando llega el momento de generar el RAT, la información no se redacta desde cero: se consolida automáticamente desde datos que ya están cargados, actualizados y relacionados entre sí. El resultado es un registro que refleja la operación real de la empresa, que se puede mantener vivo con actualizaciones incrementales, y que entrega la trazabilidad exacta que un fiscalizador —o un incidente de seguridad— va a exigir.

Para las empresas que hoy están evaluando cómo abordar la Ley 21.719, la recomendación es clara: antes de sentarse a llenar el RAT, hay que construir la base sobre la que se sostiene. Procesos, sistemas, licencias y hardware, en ese orden, son el cimiento. El RAT es solo la fachada visible de un edificio que, si no tiene estructura debajo, se cae a la primera fiscalización.