Ley 21.719: qué le exige a tu aplicación antes del 1 de diciembre de 2026

El 1 de diciembre de 2026 entra en vigencia la Ley 21.719, que reemplaza casi por completo el régimen de la antigua Ley 19.628 sobre protección de la vida privada. Para cualquier empresa que tenga una aplicación con usuarios, clientes o empleados registrados, la pregunta ya no es si la ley le aplica, sino si puede demostrar que protege esos datos.

Este artículo resume lo que la ley pide en materia de seguridad y qué significa en la práctica para una aplicación web o una API.

Importante: este es un resumen técnico, no asesoría legal. Para decisiones de cumplimiento, revisa el texto oficial en la Biblioteca del Congreso Nacional con tu equipo jurídico.

A quién aplica

La ley aplica a quien trata datos personales: recopilarlos, almacenarlos, usarlos, compartirlos o eliminarlos. En la práctica, eso incluye a casi cualquier empresa con una aplicación: un SaaS con cuentas de usuario, un e-commerce, una plataforma de RR.HH. o un portal de clientes.

La ley distingue entre el responsable (quien decide para qué y cómo se tratan los datos) y el encargado (quien los trata por cuenta del responsable, como un proveedor de software o de hosting). Si vendes software a otras empresas, probablemente seas encargado de los datos de tus clientes, y ellos te van a exigir garantías.

El deber de seguridad

La ley obliga a adoptar medidas que aseguren la confidencialidad, integridad, disponibilidad y resiliencia de los sistemas que tratan datos personales. No fija una lista cerrada de controles: las medidas deben ser proporcionales al tipo de datos, al tamaño de la empresa, a su actividad y al volumen de datos tratados. La Agencia de Protección de Datos Personales podrá fijar estándares mínimos mediante instrucciones generales.

Eso tiene una consecuencia práctica: no basta con tener controles; hay que poder demostrar que son adecuados. Un inventario de medidas, una evaluación de riesgos y pruebas periódicas, como un pentest con su retest, son la evidencia que vas a necesitar si algo sale mal.

Reportar vulneraciones

Cuando una vulneración de seguridad provoca la destrucción, filtración, pérdida o alteración de datos, o un acceso no autorizado, y existe un riesgo razonable para los derechos de los titulares, el responsable debe reportarla a la Agencia “por los medios más expeditos posibles y sin dilaciones indebidas”.

Algunos puntos que suelen confundirse:

• La ley chilena no fija un plazo en horas. Las 72 horas que se mencionan a menudo vienen del reglamento europeo (RGPD), no de la Ley 21.719, aunque sirven como referencia práctica.
• También hay que avisar a los afectados cuando la vulneración involucra datos sensibles, datos de niños y niñas menores de 14 años, o datos sobre obligaciones económicas, financieras, bancarias o comerciales. El aviso debe estar en lenguaje claro y sencillo.
• Hay que llevar un registro de las vulneraciones y de su comunicación.

Para reportar algo “sin dilaciones indebidas”, primero hay que detectarlo. Muchas filtraciones se descubren semanas después, cuando alguien publica los datos. Los registros de acceso, las alertas y un plan de respuesta a incidentes dejan de ser opcionales.

Las multas

Para empresas que no son de menor tamaño, las multas pueden calcularse como un porcentaje de los ingresos anuales del giro (2% o 4%, según el caso), y en caso de reincidencia pueden triplicarse. Entre los atenuantes se consideran la reparación del daño, la colaboración con la investigación y la autodenuncia.

La ley también permite adoptar un modelo de prevención de infracciones voluntario, con un delegado de protección de datos y protocolos internos, que puede considerarse a la hora de evaluar la responsabilidad.

¿Se posterga?

Existe un proyecto de ley que propone trasladar la vigencia a diciembre de 2027. Al momento de escribir este artículo no ha sido aprobado, y mientras no se publique una modificación en el Diario Oficial la fecha sigue siendo el 1 de diciembre de 2026. Esperar una prórroga para empezar es una apuesta arriesgada.

Qué significa para tu aplicación: por dónde empezar

1. Inventario de datos. Qué datos personales guardas, dónde (base de datos, backups, logs, proveedores) y quién accede. No puedes proteger lo que no sabes que tienes.
2. Control de acceso y autorización. Una de las fallas más comunes en aplicaciones web es que un usuario puede ver datos de otro cambiando un identificador en la URL o en la API (IDOR). Los escáneres automáticos casi nunca la detectan, y es una vulneración de datos personales de manual.
3. Cifrado. HTTPS en todo el sitio, datos sensibles cifrados en reposo, contraseñas con hash robusto y secretos fuera del código.
4. Registros y detección. Logs de acceso a datos personales y alertas ante comportamientos anómalos, para enterarte antes que los afectados.
5. Proveedores. Revisa qué datos compartes con terceros (hosting, analítica, soporte, email) y qué garantías de seguridad te dan.
6. Plan de respuesta a incidentes. Quién decide, cómo se evalúa el riesgo, quién reporta a la Agencia y a los afectados, y con qué plantilla.
7. Pruebas periódicas. Un pentest de la aplicación, con un reporte que documente qué se probó, qué se encontró y qué se corrigió, es una de las evidencias más concretas de que tus medidas de seguridad funcionan.

En resumen

La Ley 21.719 no exige una tecnología específica, pero sí exige demostrar que te tomaste en serio la seguridad de los datos personales y que puedes reaccionar rápido si algo falla. Para una empresa con una aplicación, eso empieza por saber qué datos tienes, cerrar las fallas de autorización y dejar evidencia de que lo revisaste.

Fuentes: resumen de la Ley 21.719 de Figueroa & Streit Abogados y guía de notificación de incidentes de Confidata. Texto oficial en la Biblioteca del Congreso Nacional.