Ley 21.719 desde los sistemas: qué hacer con tu software antes del 1 de diciembre

La ley tiene fecha, y tus sistemas no se enteraron.

La Ley 21.719 de protección de datos personales entra en vigencia el 1 de diciembre de 2026. En la mayoría de las empresas que conozco, el tema llegó por el área legal o por un correo del directorio, y quedó ahí: una reunión, una presentación, un "hay que revisar". Pero cuando uno baja a lo concreto, casi todo lo que la ley pide se resuelve o se rompe en los sistemas. En el ERP, en la tienda online, en el CRM y, sobre todo, en las planillas que nadie tiene inventariadas.

Una aclaración antes de seguir: esto no es asesoría legal. La interpretación de la ley, los contratos y las políticas van con un abogado. Yo escribo desde los sistemas, que es donde llevo más de 25 años trabajando.

Lo que dice la ley 21.719 para empresas, en una página

La Ley 21.719 crea la Agencia de Protección de Datos Personales, que fiscaliza y sanciona. Las multas llegan hasta 5.000 UTM por infracciones leves, 10.000 UTM por graves y 20.000 UTM por gravísimas, Si hay reincidencia, la multa puede triplicarse; y si una empresa que no es de menor tamaño reincide en una infracción grave o gravísima, puede llegar al 2% o 4% de sus ingresos anuales.

Para quien trabaja en TI, eso se traduce en preguntas muy prácticas. ¿Sabes qué datos personales guardas? ¿Puedes decir quién los ve? ¿Puedes entregarle a una persona sus datos si los pide, corregirlos o borrarlos? ¿Sabes qué hacen tus proveedores con ellos? Si la respuesta honesta a alguna es "no sé", ahí está tu trabajo de los próximos dos meses.

Inventario: dónde viven de verdad los datos personales

El primer error es pensar que los datos personales están en un sistema. Están en todos lados, y los más peligrosos son los que nadie anotó.

Imagina una distribuidora mediana. Tiene un ERP con clientes, trabajadores y contactos de proveedores. Una tienda online con direcciones, teléfonos y compras. Un CRM donde ventas registra conversaciones. Y además, cosas que no aparecen en ningún diagrama:

• Planillas exportadas del ERP que circulan por correo y viven en el escritorio de alguien.
• Respaldos de la base de datos guardados en un disco o en una carpeta compartida desde hace años.
• Ambientes de prueba o desarrollo cargados con una copia completa de producción, con datos reales.
• Formularios web que envían los datos a un correo o a una herramienta que alguien contrató con su tarjeta.
• Integraciones que dejan copias intermedias en archivos o tablas temporales que nunca se limpian.

El ambiente de pruebas con datos reales es el que más veo, y el que menos se discute. Pero esa copia suele tener menos control de acceso que producción, la ven proveedores externos y no tiene logs.

El inventario no necesita una herramienta cara. Una planilla bien hecha basta para empezar: sistema, qué datos personales tiene, de quién (clientes, trabajadores, proveedores), para qué se usan, dónde está alojado, quién tiene acceso y quién es el dueño interno.

Proveedores y encargados: tus datos también viven afuera

Tu SaaS de correo masivo, la agencia que maneja las campañas, el proveedor del sistema de remuneraciones, la plataforma de la tienda. Todos procesan datos personales por cuenta tuya. En la mayoría de los casos, tu empresa sigue siendo la responsable.

Desde TI, lo que puedes hacer es armar la lista de proveedores que tocan datos personales y, para cada uno, pedir lo básico: dónde se alojan los datos, qué medidas de seguridad tienen, cómo avisan un incidente y cómo te devuelven o eliminan los datos al terminar. Los contratos los revisa legal, pero sin tu lista no tienen qué revisar.

---

Accesos, logs y datos que sobran

Una cosa es cuidar los datos y otra poder demostrarlo. Si un día la Agencia o un cliente pregunta quién vio un registro, necesitas una respuesta que no dependa de la memoria de alguien.

Lo mínimo que revisaría en cada sistema del inventario:

1. Usuarios con acceso, cruzado contra la lista actual de trabajadores. Siempre aparecen cuentas de gente que ya se fue.
2. Perfiles y permisos. Si todos entran como administrador porque "así era más fácil", eso se corrige primero.
3. Cuentas compartidas. Un usuario "bodega" que usan cinco personas hace imposible saber quién hizo qué.
4. Registro de accesos y cambios sobre datos personales, con fecha, usuario y acción.
5. Acceso de proveedores externos: qué cuentas tienen, desde dónde entran y si caducan.

Muchos ERP y plataformas ya traen auditoría; solo que nadie la activó. En sistemas propios, agregar un registro de cambios sobre las tablas de clientes y trabajadores suele ser un trabajo acotado. En sistemas antiguos es otra historia, y lo veo más abajo.

La forma más barata de proteger un dato es no tenerlo. Revisa los formularios: ¿de verdad necesitas el RUT, la fecha de nacimiento y el teléfono para cotizar? Cada campo que eliminas es un campo que no tienes que proteger, corregir ni borrar.

Lo mismo con el tiempo. Hay datos que tienes que conservar por obligaciones tributarias o laborales, y eso lo define tu abogado y tu contador. Pero hay muchos otros que se guardan "por si acaso": postulantes de hace cinco años, clientes que compraron una vez, logs con datos personales sin fecha de borrado. Definir plazos de retención es una decisión de negocio; implementarlos es un proceso programado que archiva o elimina lo que venció.

Derechos de los titulares: lo que implica técnicamente responderlos

La ley reconoce a las personas los derechos de acceso, rectificación, supresión, oposición y portabilidad. En los sistemas, cada uno tiene su propio problema.

Para responder un acceso tienes que encontrar a la persona en todos los sistemas del inventario. Si en el ERP está por RUT, en la tienda por correo y en el CRM por nombre, eso es trabajo manual y propenso a olvidos. La rectificación tiene que propagarse: si corriges una dirección en el ERP y la tienda online no se entera, el dato malo sigue vivo. La supresión choca con la contabilidad, porque no puedes borrar a un cliente que tiene facturas emitidas; ahí lo que corresponde suele ser anonimizar o bloquear, y la regla exacta la define el abogado. La portabilidad exige poder exportar los datos en un formato ordenado, no en un pantallazo.

Si tus sistemas están integrados con una fuente única de clientes, todo esto es mucho más manejable. Si cada sistema tiene su propia copia, lo que tienes es un problema de integración, y es de los que resolvemos en integraciones. Pasa algo parecido con la tienda online: la integración de Shopify con el ERP define también cuántas copias del mismo cliente existen.

---

Sistemas legados y datos personales: aislar, enmascarar, documentar

Siempre hay uno. El sistema de hace quince años, escrito por alguien que ya no está, que funciona y que nadie quiere tocar. No tiene perfiles finos ni logs, y no hay cómo agregarle un botón de "exportar mis datos".

No lo reescribas a la carrera antes de diciembre. Un reemplazo apurado es una forma segura de sumar riesgo, no de bajarlo. Lo que sí se puede hacer en semanas:

• Aislarlo: sacarlo de la red abierta, dejarlo accesible solo a quien lo necesita y registrar los accesos desde afuera (VPN, servidor intermedio) si el sistema no los registra.
• Enmascarar los datos en cualquier copia que use soporte o desarrollo.
• Documentar qué datos tiene, para qué y por qué hoy no se puede modificar, con un plan de modernización y fechas reales.

Un sistema antiguo con riesgos conocidos, controlados y con plan es muy distinto de uno que nadie sabía que tenía datos de clientes. Si ese sistema además frena la operación, probablemente ya es deuda técnica que conviene pagar, con o sin ley.

Documentar un riesgo no lo elimina, pero convierte un descuido en una decisión. Y las decisiones se pueden defender.

Cómo priorizar en los dos meses que quedan

No vas a llegar a todo antes del 1 de diciembre, y está bien. Lo que importa es llegar con el inventario hecho, los riesgos más visibles cerrados y un plan para lo demás. El orden que yo seguiría:

1. Semanas 1 y 2: inventario de sistemas, datos, accesos y proveedores, con un dueño interno por sistema.
2. Semanas 3 y 4: limpiar accesos (cuentas de ex trabajadores, cuentas compartidas, administradores de más) y sacar los datos reales de los ambientes de prueba.
3. Semanas 5 y 6: activar logs donde ya existen, aislar el sistema legado y definir cómo vas a responder una solicitud de acceso o supresión, aunque sea con un procedimiento manual bien escrito.
4. Semanas 7 y 8: plazos de retención, lista de proveedores para legal y un plan con fechas para lo que quedó pendiente.

La relación entre la ley 21.663 y la 21.719

La Ley 21.663, marco de ciberseguridad publicado en abril de 2024, va por otro carril pero toca los mismos sistemas. Para las instituciones que regula, exige reportar incidentes al CSIRT con una alerta temprana dentro de 3 horas. Si tu empresa está alcanzada por ella, el trabajo se superpone: el mismo inventario, los mismos logs y los mismos accesos te sirven para las dos. Tener que reconstruir en 3 horas qué pasó con un sistema que no registra nada no es un escenario realista.

Si quieres ordenar esto con alguien que mire tus sistemas y no solo el papel, en 45 minutos revisamos tu inventario, lo que está expuesto y qué atacar primero. Agenda un diagnóstico.