Nuevo Hype Cycle™: avances y desafíos en la modernización de servicios sociales. Descubre el informe de Gartner.
La Ley 21.719 de protección de datos personales de Chile entra en vigencia el 1 de diciembre de 2026. Cumplir con las obligaciones no implica sólo procesos de auditoría, sino también operaciones técnicas en aplicaciones y bases de datos.
Cuando los equipos legales reciben una nueva ley de datos, el reflejo natural es redactar políticas, actualizar avisos de privacidad y preparar formularios para que los usuarios ejerzan sus derechos. Todo eso es necesario. Pero en organizaciones con múltiples sistemas - CRMs, aplicaciones legacy, microservicios, bases de datos en la nube - hay una pregunta que ningún documento responde: ¿dónde están exactamente los datos personales que debemos tratar?
Esa pregunta es el corazón del problema técnico que plantea la Ley 21.719. Este artículo revisa los artículos más relevantes para las empresas y traduce cada uno a sus implicancias concretas de arquitectura y sistemas.
La ley de protección de datos personales de Chile regula la forma y condiciones en que se efectúa el tratamiento de datos de personas naturales. En términos prácticos, abarca a toda entidad que recopile, almacene, utilice o transfiera cualquier información que pueda identificar a una persona. Desde grandes corporaciones hasta PYMES, emprendedores y organizaciones sin fines de lucro. Si su organización trata datos personales, en cualquier forma y por cualquier medio, debe cumplirla.
La única excepción relevante para el sector privado es el tratamiento realizado por personas naturales en el contexto de sus actividades estrictamente personales.
Según el Artículo 1° bis, la ley aplica cuando:
Este alcance extraterritorial tiene una consecuencia práctica inmediata. Cada herramienta SaaS que procesa datos de usuarios chilenos es un tercero mandatario o encargado bajo la ley (Art. 2°, literal x). El responsable (su empresa) responde por cómo ese tercero trata los datos. El inventario de sistemas requerido no es solo un mapa de las propias bases de datos: es un registro de la cadena completa de procesamiento de datos, incluyendo a todos los proveedores externos.
Para los equipos técnicos, los principios de la normativa no son abstracciones filosóficas: son restricciones de diseño que deben estar implementadas en los sistemas. Los principios clave son: licitud y lealtad; finalidad (datos recolectados para fines específicos); proporcionalidad (solo los datos necesarios, por el tiempo necesario); calidad; seguridad; y confidencialidad.
Usar datos reales de usuarios en un ambiente de desarrollo o QA viola directamente el principio de finalidad (Art. 3°, letra b). La propia ley define la anonimización (Art. 2°, literal k) como un procedimiento irreversible en virtud del cual el dato no puede vincularse a una persona determinada. La simple pseudonimización no es suficiente. Los pipelines de generación de datos de prueba deben producir datos sintéticos o verdaderamente anonimizados.
El principio de proporcionalidad (Art. 3°, letra c) establece que los datos solo pueden conservarse por el período necesario para cumplir con los fines del tratamiento. Una tabla que acumula eventos sin fecha de expiración, o campos capturados por inercia pero nunca utilizados, son ejemplos directos de tratamiento desproporcionado. Cada dataset debe tener una justificación de negocio activa y un período de retención definido.
El principio de confidencialidad (Art. 3°, letra h) no aplica solo hacia afuera. Un desarrollador que accede a la base de datos de producción completa para depurar un bug, o un analista que puede consultar datos personales sin restricción de propósito, representa un riesgo de cumplimiento. El control de acceso interno basado en roles y la auditoría de consultas son parte del problema técnico.
La Ley 21.719 consagra derechos que son personales, intransferibles e irrenunciables. El responsable debe poder satisfacerlos en un plazo máximo de treinta días corridos (prorrogable por una vez hasta treinta días más) según el Artículo 11. Para una organización con múltiples sistemas, cada uno de estos derechos plantea un problema de ingeniería diferente.
El titular puede solicitar confirmación de si sus datos están siendo tratados y acceder a ellos junto con información asociada. Satisfacer esa solicitud requiere un mapa de datos sensibles que cubra todas las aplicaciones del ecosistema tecnológico. Sin un inventario actualizado, esta respuesta es sencillamente imposible de dar con certeza dentro del plazo legal.
El titular puede solicitar la modificación de sus datos cuando sean inexactos, desactualizados o incompletos. Los datos rectificados deben ser comunicados a todas las entidades a quienes el responsable los haya cedido previamente. "Efectuada la rectificación, no se podrán volver a tratar los datos sin rectificar." En arquitecturas con datos desnormalizados y replicados en múltiples sistemas esta puede ser una operación no trivial e inviable.
El titular puede solicitar la eliminación de sus datos en seis causales específicas. La ley también establece causales en que la supresión no procede, por ejemplo, cuando el tratamiento es necesario para cumplir una obligación legal. Técnicamente, esto no es un DELETE FROM usuarios WHERE id = X. Es una política de ciclo de vida del dato. Para profundizar en la implementación correcta, consulta nuestro artículo sobre cómo debe ejercerse el derecho de supresión.
Si a esta información sumamos el principio de finalidad contemplado en los Artículos 3 y 4, entendemos que los datos sólo pueden conservarse y utilizarse durante un tiempo determinado y siempre y cuando haya un motivo explícito para su tratamiento.
Entonces, ¿Qué sucede, por ejemplo, cuando se finaliza un contrato o una relación comercial? En esos casos, las organizaciones no deberían conservar ni utilizar los datos de sus exclientes. Para ello, a nivel técnico, deben proceder al bloqueo y, luego, a la supresión definitiva de los mismos. A continuación, explicitaremos las implicaciones técnicas de estos procesos.
El titular puede solicitar la suspensión temporal de cualquier operación de tratamiento mientras se resuelve una solicitud. Una aclaración relevante es que el bloqueo suspende el procesamiento activo pero no obliga a eliminar los datos. Esta distinción requiere un mecanismo de marcado a nivel de sistema. La solicitud de bloqueo debe responderse en dos días hábiles, un plazo que hace imposible un proceso manual.
El sistema de permisos debe estar granularizado por finalidad de uso: desactivar los datos para marketing mientras se conservan para el contrato vigente requiere una lógica de filtro que pocos sistemas tienen por defecto.
El titular puede solicitar una copia de sus datos en formato electrónico estructurado para transferirlos a otro responsable. Exportar la información de un usuario de forma completa y legible por máquinas revela la deuda técnica de los sistemas legacy: en organizaciones con bases de datos fragmentadas o esquemas inconsistentes, este derecho es sencillamente inejecutable sin trabajo de ingeniería previo.
Protección desde el diseño: El responsable debe aplicar medidas técnicas adecuadas con anterioridad y durante el tratamiento. Las nuevas funcionalidades deben pasar por una evaluación de impacto en privacidad antes de entrar a producción (el Art. 15 ter formaliza esta evaluación para casos de alto riesgo).
Protección por defecto: La configuración predeterminada de cualquier sistema debe ser la más restrictiva en términos de datos recolectados, no la más permisiva. Aplicar primero y filtrar después no es compatible con este principio.
El Artículo 14 sexies obliga a reportar a la Agencia, sin dilaciones indebidas, las vulneraciones que ocasionen destrucción, filtración, pérdida o acceso no autorizado a datos personales. Existe además una obligación de notificación directa a los titulares cuando la brecha afecte datos sensibles, datos de menores de catorce años, o datos financieros/bancarios/comerciales.
Los sistemas de detección y respuesta a incidentes deben ser capaces de clasificar automáticamente los datos comprometidos por tipo para determinar si se activa la notificación ampliada. Cuando ocurre una brecha no es el momento de descubrir qué datos estaban almacenados dónde.
El Artículo 48 establece que todos los responsables deben adoptar acciones para prevenir las infracciones descritas en la ley. El Artículo 49 describe el modelo de prevención de infracciones como un programa voluntario y certificable que actúa como atenuante en el proceso sancionatorio y que se consigna en el Registro Nacional de Sanciones y Cumplimiento, de carácter público.
El programa debe incluir la designación de un delegado de protección de datos (DPO), un inventario de bases de datos administradas, la identificación de actividades de riesgo y protocolos de prevención. Un DPO sin capacidad de operar sobre los sistemas (sin acceso a los data maps, sin visibilidad sobre los flujos de datos) es un título, no una función.
| Tipo de infracción | Multa máxima | Reincidencia |
| Leve | 5.000 UTM o amonestación | — |
| Grave | 10.000 UTM | Hasta 2% de ingresos anuales |
| Gravísima | 20.000 UTM | Hasta 4% de ingresos anuales |
Además de las multas, existen sanciones accesorias (incluyendo suspensión de operaciones de tratamiento en casos de infracciones gravísimas reiteradas) y la inclusión en el Registro Nacional de Sanciones, de carácter público. En muchos casos, este último es el daño más costoso, debido a que puede dañar de manera notable la reputación y la confianza de los clientes en la organización.
El cumplimiento de la Ley 21.719 es un proyecto tecnológico con un marco legal. Cumplir con la ley es ante todo un problema de gobernanza: requiere que los equipos de ingeniería, seguridad, datos y legal trabajen sobre los mismos datos con los mismos criterios, al mismo tiempo.
Antes de implementar cualquier derecho o configurar cualquier herramienta, la pregunta fundamental es: ¿qué datos personales trata su organización, en qué sistemas y bajo qué estructura? Identificar sistemáticamente esa información requiere un proceso de análisis estructurado. Para saber más, consulte nuestro artículo sobre el mapeo de datos sensibles.
Existen plataformas que permiten gestionar el consentimiento de forma centralizada: capturarlo, registrarlo, versionarlo y procesarlo cuando el titular lo revoca. Son soluciones probadas en mercados con regulación exigente que contemplan la adaptación a normativas en Latinoamérica.
Sin embargo, se debe considerar que gestionar el consentimiento no implica actuar efectivamente sobre las bases de datos. Una plataforma puede dar trazabilidad acerca de qué usuario dio o retiró el permiso para el tratamiento de sus datos, y elevar notificaciones cuando se presenta una solicitud. Pero no siempre tendrá la capacidad de automatizar el bloqueo o la supresión.
Ejecutar los derechos implica actuar sobre los datos donde sea que estén, propagando la acción a través de múltiples sistemas, con trazabilidad completa y dentro de plazos legales estrictos. El caso más ilustrativo es el derecho de supresión. Sin automatización, este proceso es propenso a errores, difícil de auditar y prácticamente inescalable.
Para entender por qué, basta con seguir los pasos que implica ejecutarlo de forma manual. Primero, localizar todos los datos del titular en la organización: no solo en la base de datos principal, sino en cada sistema que los haya recibido, con distintas nomenclaturas, esquemas y estructuras.
Segundo, no se debe eliminarlos de forma inmediata e irreversible. Se establece un período de bloqueo previo durante el cual los datos deben existir, pero no ser procesados. Esto que obliga a definir y aplicar reglas de anonimización específicas para cada campo y cada sistema.
Tercero, ese bloqueo debe ser reversible mientras esté vigente — por si la solicitud es impugnada o resulta improcedente—, lo que añade otra capa de gestión.
Y cuarto, una vez vencido el plazo, los datos deben eliminarse definitivamente en todos los sistemas donde fueron bloqueados. Esto implica recordar qué se bloqueó, cuándo, dónde, y ejecutar la supresión sin dejar rastros activos.
Hacer esto de forma manual, caso a caso, con volúmenes reales de usuarios, requiere horas de trabajo especializado por solicitud. Y aun así, ya sea que se gestione una solicitud a la vez o mediante desarrollos internos ad hoc, no existe una forma sencilla de verificar que el bloqueo y la eliminación posterior se hayan ejecutado correctamente en todos los sistemas. Esa falta de trazabilidad es exactamente donde se concentran los errores y donde la Agencia puede encontrar incumplimientos.
icaria Data Privacy automatiza la ejecución de los derechos ARCOPOL actuando directamente sobre las bases de datos de la organización, en entornos productivos y con trazabilidad completa de cada acción realizada.
Como vimos, los principios de finalidad y proporcionalidad establecen que los datos personales solo pueden tratarse para el fin con el que fueron recolectados, y únicamente por el tiempo necesario. Cuando un usuario facilita sus datos para contratar un servicio, ese es el único uso autorizado. Utilizarlos en entornos de desarrollo o QA sin consentimiento explícito para ese fin, no está permitido. Ese consentimiento rara vez existe.
Entonces, el problema es que los datos de producción son los más representativos para hacer pruebas. Pero usarlos tal cual no es una opción. Lo que corresponde es anonimizarlos de forma masiva para que sigan siendo útiles - manteniendo distribuciones, formatos y relaciones entre campos - sin que correspondan a personas identificables.
Para resolver esta problemática, herramientas como icaria TDM ofrecen datos realistas y coherentes para entornos de prueba, garantizando que los equipos de desarrollo y QA puedan trabajar con información representativa sin exponer datos personales. Además de resolver el problema de cumplimiento, icaria TDM reduce hasta un 50% los tiempos de espera de los equipos de prueba.
La Ley 21.719 es la nueva ley de protección de datos personales de Chile. Regula el tratamiento de datos de personas naturales por parte de cualquier organización pública o privada, crea la Agencia de Protección de Datos Personales y establece derechos ARCOPOL, obligaciones de privacidad por diseño y sanciones de hasta 20.000 UTM o el 4% de los ingresos anuales. Entra en plena vigencia el 1 de diciembre de 2026.
La Ley 21.719 entra en plena vigencia el 1 de diciembre de 2026. Las organizaciones deben completar su implementación técnica y organizacional antes de esa fecha.
A toda persona natural o jurídica (incluyendo órganos públicos) que trate datos personales en Chile, sin importar el tamaño de la organización. También aplica a empresas extranjeras que ofrezcan bienes o servicios a usuarios en Chile o monitoreen su comportamiento.
RCOPOL es el acrónimo de los derechos reconocidos a los titulares: Acceso, Rectificación, Cancelación (supresión), Oposición, Portabilidad y bLoqueo temporal. El responsable debe poder satisfacerlos en un plazo máximo de 30 días corridos.
Las multas van desde amonestación hasta 5.000 UTM (leves), 10.000 UTM (graves) y 20.000 UTM (gravísimas). En caso de reincidencia de empresas no consideradas de menor tamaño, las multas pueden alcanzar el 2% o el 4% de los ingresos anuales.
Es la obligación establecida en el Artículo 14 quáter de aplicar medidas técnicas de protección de datos antes y durante el tratamiento, y de configurar los sistemas para que, por defecto, solo traten los datos estrictamente necesarios. No es una buena práctica opcional: es una exigencia legal.
La Ley 21.719 da a Chile un marco de protección de datos comparable a los estándares internacionales más exigentes. Para las empresas, significa que el cumplimiento real —no el cosmético— requiere que los equipos de ingeniería, seguridad, datos y legal trabajen sobre los mismos problemas al mismo tiempo. El plazo de dos años no es holgado. En el mejor de los casos, es suficiente.
¿Tienes preguntas sobre la implementación técnica de alguno de estos requisitos? Contacta con nuestros expertos.
