Duemint
|
¿Qué exige técnicamente la Ley de Protección de Datos en Chile?
La Ley 21.719 llevará la protección de datos desde las políticas hacia la arquitectura, los sistemas y la operación diaria.
Los equipos de tecnología deberán saber qué información procesa la empresa, dónde se almacena, quién puede acceder, con qué plataformas se comparte y qué ocurre cuando deja de ser necesaria.
La Ley 21.719 fue publicada con entrada en vigencia fijada originalmente para el 1 de diciembre de 2026. El Gobierno propuso postergarla hasta diciembre de 2027, pero el cambio todavía no está confirmado.
Puedes revisar el contexto, las fechas y los principales cambios en la guía general sobre la Ley de Protección de Datos en Chile. En esta nota nos concentraremos en su implementación técnica: accesos, protección de información, trazabilidad, ambientes de prueba, continuidad, proveedores e incidentes.
Cómo se traduce la Ley 21.719 a los sistemas
La ley utiliza un enfoque basado en riesgo. No exige una arquitectura o tecnología específica: las medidas deben definirse según el tipo y volumen de información, su finalidad y el impacto que tendría una filtración, alteración o pérdida.
El Manual Fintech de Protección de Datos Personales, elaborado por Dentons y FinteChile, resume el cambio como el paso desde declarar a demostrar. No basta con afirmar que los datos están protegidos; la empresa debe conservar evidencia de que sus controles funcionan.
Área técnica | Qué revisar | Evidencia esperada |
|---|---|---|
Diseño y minimización | Datos solicitados, finalidades y configuración inicial | Revisión dentro del desarrollo |
Roles y permisos | Usuarios, administradores y permisos heredados | Matriz de accesos |
Protección de datos | Bases, archivos, respaldos y conexiones | Controles y administración de claves |
Segmentación | Separación de sistemas y ambientes | Diagrama de arquitectura |
Trazabilidad | Accesos críticos, cambios y exportaciones | Registros y alertas |
Ambientes de prueba | Uso de información real, anonimización y eliminación | Procedimiento de QA |
Conservación | Plazos y eliminación de datos | Reglas de retención |
Continuidad | Respaldos y recuperación | Pruebas de restauración |
La protección desde el diseño implica revisar la privacidad antes de lanzar una funcionalidad, producto o integración. Por defecto, los sistemas deberían recopilar únicamente los datos necesarios, limitar los accesos y evitar compartir información automáticamente.
Mapear el recorrido completo de los datos
El primer paso es crear un inventario que muestre qué información procesa cada sistema, desde dónde se obtiene, para qué se utiliza y con quién se comparte.
También debe identificar dónde se almacena, quién puede acceder, en qué país se procesa, cuánto tiempo se conserva y qué respaldos contienen copias.
No basta con hacer una lista de aplicaciones. El objetivo es seguir el dato desde que entra hasta que se elimina.
Por ejemplo, el teléfono de un cliente puede ingresar mediante un formulario, pasar al CRM, enviarse al facturador y terminar en una plataforma de cobranza. Si el cliente solicita corregirlo, la empresa debe saber en qué sistemas realizar el cambio.
Controles técnicos que conviene priorizar
Accesos y permisos
Las cuentas compartidas, los permisos amplios y los usuarios antiguos dificultan saber quién accedió a la información.
La empresa debería revisar periódicamente sus usuarios activos, cuentas administrativas, accesos de proveedores y permisos heredados. El principio recomendado es que cada persona pueda consultar únicamente la información necesaria para su función.
Tecnologías como RBAC, ABAC, autenticación multifactor o gestores de secretos pueden ayudar. La ley no obliga a utilizar una solución específica, pero la empresa debe poder explicar cómo controla los accesos.
Protección de datos y conexiones
La ley señala que las medidas de seguridad pueden incluir cifrado y seudonimización, según el riesgo.
Esto implica revisar la información almacenada en bases, archivos y respaldos, además de los datos que viajan entre aplicaciones, bancos, ERP, API y proveedores.
AES-256, TLS 1.3, KMS o HSM pueden ser alternativas adecuadas, pero no son exigencias literales de la ley. La empresa debe seleccionar controles proporcionales al riesgo y documentar esa decisión.
Trazabilidad
Los registros permiten investigar errores, accesos indebidos e incidentes. Los eventos relevantes pueden incluir cambios de permisos, accesos administrativos, exportaciones masivas, modificaciones de datos sensibles o intentos reiterados de autenticación.
La ley no obliga a registrar cada lectura realizada en todas las bases. Cada empresa debe definir qué eventos necesita conservar para controlar sus riesgos y demostrar que sus medidas funcionan.
Ambientes de prueba
Utilizar copias completas de producción en desarrollo o QA aumenta la exposición de información personal.
La ley no lo prohíbe de forma absoluta, pero su uso debe estar justificado y protegido. Siempre que sea posible, conviene utilizar datos sintéticos, anonimizados, enmascarados o bases reducidas.
Si se utiliza información real, deberían existir accesos temporales, autorización, aislamiento del ambiente y una fecha definida para eliminarla.
Respaldos y recuperación
Tener copias de seguridad no es suficiente. La empresa debe verificar que pueda restaurarlas y recuperar la operación dentro de tiempos razonables.
El RPO define cuánta información puede perderse. El RTO establece cuánto tiempo puede tardar en recuperarse el servicio.
La ley no obliga a usar múltiples zonas de disponibilidad o una arquitectura determinada. Sí exige adoptar medidas que protejan la disponibilidad y resiliencia de acuerdo con el riesgo.
Preparar los sistemas para responder solicitudes
La Ley 21.719 reconoce derechos de acceso, rectificación, supresión, oposición, portabilidad y bloqueo.
Solicitud | Qué debe permitir el sistema |
|---|---|
Acceso | Encontrar los datos asociados a una persona |
Rectificación | Corregirlos en los sistemas conectados |
Supresión | Eliminarlos cuando no exista una razón para conservarlos |
Oposición | Detener determinados usos |
Bloqueo | Suspender temporalmente el tratamiento |
Portabilidad | Exportar los datos en un formato estructurado |
No siempre será necesario automatizar el proceso completo. Lo importante es contar con un procedimiento repetible y verificable.
Antes de la entrada en vigencia, conviene probar una solicitud con una identidad ficticia. Así se puede verificar si el proceso funciona desde el canal de atención hasta los sistemas involucrados.
Preparación técnica ante incidentes
Una vulneración puede originarse en un ataque, una credencial expuesta, una mala configuración, un dispositivo perdido o un archivo enviado al destinatario equivocado.
El procedimiento debería permitir:
Detectar y registrar el incidente.
Identificar los sistemas y datos afectados.
Aislar los accesos comprometidos.
Evaluar cuántas personas podrían estar involucradas.
Conservar evidencia para investigar.
Determinar si corresponde notificar.
Documentar las medidas adoptadas.
La ley establece que determinadas vulneraciones deben informarse a la Agencia sin dilaciones indebidas cuando exista un riesgo razonable para los derechos de las personas.
No fija un plazo general de 24 o 72 horas. Por eso, la capacidad de investigar y escalar rápidamente será tan importante como la herramienta de detección.
Auditar proveedores, nube e integraciones
Los datos pueden pasar por servicios de nube, ERP, CRM, bancos, plataformas financieras y conexiones vía API.
Dimensión | Pregunta técnica |
|---|---|
Datos | ¿Qué información recibe el proveedor? |
Finalidad | ¿Para qué puede utilizarla? |
Permisos | ¿A qué sistemas y funciones puede acceder? |
Autenticación | ¿Cómo se valida la conexión? |
Almacenamiento | ¿En qué país se procesan los datos? |
Incidentes | ¿Cómo se informa una vulneración? |
Trazabilidad | ¿Qué registros de actividad entrega? |
Término del servicio | ¿Los datos se eliminan, devuelven o anonimizan? |
Una integración segura también debe coincidir con el contrato. No sirve limitar los permisos de una API si el acuerdo permite utilizar la información para finalidades más amplias.
Si la nube o un proveedor procesa información fuera de Chile, la empresa deberá identificar la transferencia internacional y revisar con el área legal qué mecanismo permite realizarla.
Inteligencia artificial y decisiones automatizadas
Los sistemas utilizados para scoring, evaluación de riesgo, detección de fraude, aprobación automática o segmentación requieren una revisión especial.
La empresa debe saber qué datos utiliza el modelo, qué decisión genera, qué efecto produce y cuándo participa una persona en la revisión.
También debe revisar si un proveedor conserva la información, la utiliza para entrenar modelos o la transfiere a otros servicios. La inteligencia artificial puede acelerar el análisis, pero no reemplaza la responsabilidad de la empresa.
Cuándo realizar una Evaluación de Impacto
Los tratamientos de alto riesgo pueden requerir una Evaluación de Impacto en Protección de Datos antes de comenzar.
Esto puede aplicar a procesos que involucren:
Evaluaciones automatizadas con efectos importantes sobre una persona.
Tratamiento masivo o a gran escala.
Monitoreo sistemático de espacios de acceso público.
Determinados tratamientos de datos sensibles.
La evaluación debe identificar el tratamiento, los riesgos para las personas y las medidas que se implementarán para reducirlos.
No es un documento que deba prepararse después de un incidente. Su objetivo es anticipar los riesgos antes de poner el proceso en funcionamiento.
Evidencia que debería conservar tecnología
Para demostrar que los controles funcionan, conviene mantener:
Inventario de sistemas y datos.
Diagrama de los principales flujos.
Matriz de roles y permisos.
Lista de proveedores e integraciones.
Reglas de conservación y eliminación.
Procedimiento y registro de incidentes.
Resultados de pruebas de restauración.
Prueba de una solicitud de acceso o eliminación.
Evaluaciones de impacto realizadas.
Evidencia de revisiones periódicas.
Qué no exige literalmente la Ley 21.719
La ley exige | No impone de manera universal |
|---|---|
Seguridad proporcional al riesgo | AES-256 en todos los sistemas |
Protección desde el diseño | Una arquitectura Zero Trust específica |
Confidencialidad, integridad y disponibilidad | Registrar cada lectura de todas las bases |
Capacidad de recuperación | Operar obligatoriamente en modalidad Multi-AZ |
Evaluar los controles | Implementar necesariamente un SIEM |
Minimizar y proteger los datos | Prohibir absolutamente los datos reales en QA |
Demostrar cumplimiento | Contar obligatoriamente con ISO 27001 |
Estas tecnologías pueden ser apropiadas. Su implementación dependerá del riesgo, la operación y la información tratada.
Conecta tu operación financiera con controles y trazabilidad
Los procesos financieros concentran datos de clientes, cuentas bancarias, facturas, pagos y proveedores. Cuando dependen de planillas, archivos o accesos compartidos, es más difícil controlar cómo circula la información.
Duemint conecta recaudación, tesorería y pago a proveedores mediante automatizaciones e integraciones vía API. La plataforma permite configurar roles y permisos, establecer flujos de autorización y mantener un historial auditable.
Conoce más sobre la seguridad de Duemint y su API financiera.
Estas capacidades no garantizan por sí solas el cumplimiento legal, pero ayudan a construir procesos financieros con mayor control, trazabilidad y seguridad.
Preguntas frecuentes
¿La Ley 21.719 exige una tecnología específica de cifrado?
No. Exige medidas proporcionales al riesgo. La empresa debe seleccionar y justificar los controles adecuados.
¿Es obligatorio registrar todos los accesos a una base de datos?
No. La empresa debe definir qué eventos necesita conservar para controlar sus riesgos y demostrar el funcionamiento de sus medidas.
¿Está prohibido utilizar datos reales en QA?
No existe una prohibición absoluta. Su uso debe ser necesario, estar justificado y contar con controles. Los datos sintéticos o anonimizados reducen la exposición.
¿La ley obliga a contar con ISO 27001?
No. La ISO 27001 puede ayudar a ordenar la seguridad, pero no reemplaza las obligaciones de la Ley 21.719.
Este contenido es informativo y no constituye asesoría legal. Cada empresa debe evaluar sus obligaciones según los datos, sistemas y procesos que utiliza.
