Gestión de consentimiento y derechos ARCOP: automatización e integración de procesos bajo la Ley 21.719
- Por Amparo Silva | Amsoft
Introducción
El 1 de diciembre de 2026 entra en plena vigencia la Ley N°21.719 de Protección de Datos Personales en Chile. Para muchas organizaciones, ese plazo parece lejano. Para sus áreas de TI, no lo es.
La ley impone dos bloques de obligaciones que tienen un componente tecnológico insoslayable: gestionar el consentimiento de los titulares de forma auditable, y atender sus solicitudes de derechos ARCOP -Acceso, Rectificación, Cancelación/Supresión, Oposición y Portabilidad- dentro de los plazos establecidos. Ninguno de esos dos bloques puede resolverse con procesos manuales a escala. Ambos requieren integración con los sistemas donde viven los datos.
Este artículo analiza cómo construir esa capacidad operativa: qué arquitectura de sistemas necesita una organización para gestionar el consentimiento de forma centralizada, cómo automatizar el ciclo de vida completo de una solicitud ARCOP, cómo integrar esos flujos con los sistemas legados que ya existen, y qué métricas permiten demostrar cumplimiento ante la Agencia de Protección de Datos Personales.
1. El modelo legal-técnico del consentimiento: qué exige la ley y qué implica para los sistemas
1.1 Los cuatro atributos del consentimiento válido bajo la Ley 21.719
El artículo 12 de la Ley 21.719 define el consentimiento como la manifestación de voluntad libre, informada, específica e inequívoca del titular. Cada uno de esos cuatro atributos tiene implicancias directas sobre cómo debe construirse el sistema que lo gestiona.
Libre significa que no puede ser condición para acceder a un servicio. El sistema no puede bloquear funcionalidades esenciales si el usuario no consiente tratamientos no necesarios.
Informada exige que el titular conozca, antes de consentir, qué datos se recopilarán, con qué finalidad, durante cuánto tiempo y con quién se compartirán. El sistema debe registrar la versión del aviso de privacidad que el titular leyó al momento de consentir.
Específica implica que cada finalidad de tratamiento requiere su propio consentimiento. Un consentimiento genérico para “usar los datos según la política de privacidad” no es válido bajo la ley.
Inequívoca prohíbe las casillas premarcadas, el consentimiento tácito o por omisión. El sistema debe registrar una acción afirmativa explícita del titular, con marca de tiempo y trazabilidad de la acción.
1.2 El ciclo de vida del consentimiento: obtención, almacenamiento, renovación y revocación
El consentimiento no es un evento único. Es un ciclo que el sistema debe gestionar en todas sus etapas. La obtención debe producirse en el momento adecuado del flujo del usuario, con un mecanismo que garantice la acción afirmativa. El almacenamiento debe conservar el registro completo: qué consintió, cuándo, en qué versión del aviso, desde qué canal y mediante qué acción. La renovación es necesaria cuando cambian las finalidades o el aviso de privacidad. La revocación debe estar disponible en todo momento, ser tan simple como el otorgamiento, y propagarse a todos los sistemas que estaban usando esos datos.
Este ciclo no puede gestionarse con una base de datos de marketing o con registros dispersos en distintos sistemas. Requiere una capa centralizada de gestión de consentimiento -una plataforma de gestión del consentimiento o CMP (Consent Management Platform)- que funcione como fuente única de verdad sobre el estado del consentimiento de cada titular, y que esté integrada con todos los sistemas que tratan sus datos.
2. Arquitectura de sistemas para la gestión centralizada del consentimiento
2.1 Los componentes clave de una arquitectura de consentimiento auditable
Una arquitectura funcional para la gestión del consentimiento bajo la Ley 21.719 necesita al menos cinco componentes articulados:
- Capa de captura: los puntos de contacto digitales (sitio web, app, portal de clientes, formularios) donde se obtiene el consentimiento. Cada punto debe estar conectado a la CMP y registrar la acción del usuario con marca de tiempo.
- Repositorio central de consentimientos: la base de datos que almacena el estado de consentimiento de cada titular por finalidad, con historial completo de cambios. Es la fuente que consultarán todos los sistemas antes de tratar datos.
- API de consentimiento: la interfaz que permite a los sistemas internos (CRM, plataforma de marketing, ERP) consultar en tiempo real si existe consentimiento válido antes de tratar datos con una finalidad específica.
- Motor de propagación: el componente que, cuando un titular revoca un consentimiento, notifica automáticamente a todos los sistemas conectados para que dejen de usar esos datos con esa finalidad.
- Registro de auditoría inmutable: el log que conserva cada evento del ciclo de vida del consentimiento, diseñado para ser presentado ante la Agencia de Protección de Datos sin necesidad de reconstrucción manual.
2.2 El mapa de tratamientos como precondición técnica
Antes de implementar cualquier arquitectura de consentimiento, la organización necesita construir su Registro de Actividades de Tratamiento (RAT): un inventario de qué datos trata, con qué finalidad, en qué sistemas, con qué base de licitud y durante cuánto tiempo. Sin ese mapa, es imposible determinar qué finalidades requieren consentimiento, qué consentimientos hay que solicitar, y qué sistemas deben consultar la API de consentimiento antes de actuar.
Este inventario no es un documento de cumplimiento legal: es el insumo técnico que define la arquitectura. Organizaciones que intentan implementar una CMP sin tener el RAT terminan construyendo una plataforma que gestiona consentimientos para finalidades que no están mapeadas, o que omite finalidades que sí requieren consentimiento.
3. Automatización end-to-end del ciclo de vida de solicitudes ARCOP
3.1 Por qué la gestión manual de solicitudes ARCOP no escala
Una solicitud ARCOP no es un correo electrónico que llega al área legal. Es un evento que desencadena un proceso técnico que involucra múltiples sistemas: verificar la identidad del solicitante, localizar todos sus datos en los sistemas de la organización, compilar o modificar esa información según el tipo de derecho ejercido, notificar al titular con una respuesta documentada y dentro del plazo legal, y registrar todo el proceso para efectos de auditoría.
Para organizaciones que manejan decenas o cientos de solicitudes al mes, ese proceso no puede ser manual. La Ley 21.719 establece plazos de respuesta que la Agencia de Protección de Datos fiscalizará, y el incumplimiento sistemático de esos plazos constituye infracción. La automatización no es una opción de eficiencia: es una condición de cumplimiento a escala.
3.2 El flujo automatizado de una solicitud ARCOP: etapa por etapa
Un sistema automatizado de gestión de solicitudes ARCOP debe cubrir las siguientes etapas sin intervención manual:
- Recepción multicanal: el titular debe poder enviar su solicitud por cualquier canal habilitado (portal web, correo, presencial), y el sistema debe ingresarla automáticamente al flujo de gestión con marca de tiempo que inicia el plazo de respuesta.
- Verificación de identidad: el sistema verifica que el solicitante es efectivamente el titular de los datos o su representante legal, sin exponer datos a terceros no autorizados.
- Localización de datos: el sistema consulta todos los repositorios de datos de la organización donde pueden existir datos del titular: CRM, ERP, plataformas de comunicación, bases de datos analíticas, sistemas de facturación.
- Ejecución del derecho: dependiendo del tipo de solicitud, el sistema compila los datos para acceso, los modifica para rectificación, los suprime para cancelación, aplica restricciones de tratamiento para oposición, o los exporta en formato portable para portabilidad.
- Respuesta documentada y registro: el sistema envía la respuesta al titular con la documentación correspondiente, registra el resultado en el log de auditoría y cierra el caso dentro del plazo legal.
4. Integración con sistemas legados: el desafío técnico real
4.1 El problema del ecosistema heterogéneo
El principal obstáculo técnico para implementar un sistema de gestión de consentimiento y derechos ARCOP no es la lógica del proceso: es la integración con los sistemas donde realmente están los datos. La mayoría de las organizaciones chilenas opera con un ecosistema heterogéneo que incluye sistemas legados con décadas de antigüedad, CRMs de distintas generaciones, ERPs con APIs limitadas o inexistentes, y bases de datos analíticas que no fueron diseñadas para responder consultas individuales en tiempo real.
Para esos sistemas, la integración requiere una capa de mediación tecnológica que traduzca las consultas del motor de ARCOP al lenguaje que cada sistema puede entender. No todos los sistemas expondrán una API REST. Algunos requerirán conectores específicos, procesos batch de sincronización, o capas de abstracción que normalicen los datos antes de presentarlos al titular.
Para esos sistemas, la integración requiere una capa de mediación tecnológica que traduzca las consultas del motor de ARCOP al lenguaje que cada sistema puede entender. No todos los sistemas expondrán una API REST. Algunos requerirán conectores específicos, procesos batch de sincronización, o capas de abstracción que normalicen los datos antes de presentarlos al titular.
4.2 Estrategias de integración según el tipo de sistema
La estrategia de integración depende de las características del sistema a conectar:
- Sistemas modernos con API: integración directa mediante API REST o GraphQL. El motor de ARCOP consulta en tiempo real y recibe respuestas estructuradas.
- Sistemas con acceso a base de datos: integración mediante conectores de base de datos con vistas de solo lectura para consultas y procedimientos almacenados para modificaciones. Requiere mapeo previo de la estructura de datos.
- Sistemas legados sin API ni acceso directo: integración mediante extracción periódica de datos a un repositorio intermedio, con sincronización programada. Las solicitudes ARCOP se resuelven contra el repositorio intermedio y las modificaciones se propagan al sistema fuente en el siguiente ciclo.
- Sistemas de terceros (SaaS externos): integración mediante las APIs de gestión de datos que el proveedor expone. Si el proveedor no permite acceso a los datos del cliente, es necesario revisar el contrato de procesamiento de datos bajo la Ley 21.719.
5. Métricas, KPIs y dashboard de cumplimiento: cómo demostrar que el sistema funciona
5.1 Lo que la Agencia de Protección de Datos va a querer ver
La responsabilidad proactiva (accountability) es uno de los principios centrales de la Ley 21.719. No basta con cumplir: hay que poder demostrarlo. La Agencia de Protección de Datos puede requerir evidencia del funcionamiento del sistema en cualquier momento, y esa evidencia debe estar disponible sin necesidad de reconstrucción manual.
Las métricas esenciales que un sistema de cumplimiento debe registrar y reportar incluyen:
- Tasa de consentimiento válido por finalidad: porcentaje de titulares con consentimiento activo, revocado o pendiente para cada finalidad de tratamiento.
- Tiempo de respuesta a solicitudes ARCOP: mediana y percentil 95 del tiempo transcurrido entre la recepción y la respuesta, por tipo de derecho ejercido.
- Tasa de cumplimiento de plazos: porcentaje de solicitudes respondidas dentro del plazo legal establecido por la ley.
- Cobertura de integración: porcentaje de sistemas de la organización que contienen datos personales y están conectados al motor de ARCOP. Un 80% de cobertura con el 20% sin integrar no es cumplimiento.
- Integridad del registro de auditoría: confirmación de que todos los eventos del ciclo de vida del consentimiento y de las solicitudes ARCOP están registrados de forma completa, con marca de tiempo y sin posibilidad de modificación retroactiva.
5.2 El dashboard de cumplimiento como herramienta de gestión directiva
Un dashboard de cumplimiento bajo la Ley 21.719 no es solo un reporte técnico para el área de TI. Es una herramienta que debe ser legible para el CIO, el Director Legal y, eventualmente, para la Agencia de Protección de Datos en una auditoría. Debe mostrar el estado de cumplimiento en tiempo real, alertar cuando alguna métrica cae por debajo de los umbrales definidos, y permitir la generación de reportes históricos que demuestren la consistencia del sistema en el tiempo.
Ese dashboard es también la herramienta que transforma el cumplimiento en una conversación directiva: en lugar de responder preguntas sobre el estado de adecuación con estimaciones, el CIO puede mostrar números verificables sobre qué porcentaje de los tratamientos tiene base de licitud documentada, cuántas solicitudes ARCOP se recibieron el mes pasado y en qué tiempo se respondieron, y cuáles sistemas aún no están integrados al motor de gestión de derechos.
Conclusión
La Ley 21.719 no es un problema legal con un componente tecnológico secundario. Es un problema de arquitectura de sistemas que tiene un componente legal como marco. Las organizaciones que lo entiendan así, y que empiecen hoy a construir su mapa de tratamientos, su arquitectura de consentimiento y su motor de gestión de derechos ARCOP, llegarán al 1 de diciembre de 2026 con un sistema que funciona. Las que esperen a que el área legal haya terminado de interpretar la ley para empezar el trabajo técnico, llegarán tarde.
La diferencia entre una implementación exitosa y una fallida no está en el conocimiento de la normativa, sino en la capacidad de integrar esa lógica en el ecosistema tecnológico real de la organización.
¿Cómo puede Amsoft ayudarte en este camino?
En Amsoft contamos con células de trabajo especializadas para la adecuación tecnológica a la Ley 21.719: desde la construcción del Registro de Actividades de Tratamiento hasta la implementación de la arquitectura de consentimiento, la automatización del ciclo de vida de solicitudes ARCOP y la integración con los sistemas existentes de la organización.
Contáctanos para revisar el estado de preparación técnica de tu organización y diseñar un plan de implementación realista para el plazo de vigencia de la ley.
Este artículo fue elaborado por Amparo Silva, miembro del equipo de Amsoft, comprometida con la innovación y la excelencia en el ámbito tecnológico.
Referencias
- Biblioteca del Congreso Nacional de Chile. (2024, Diciembre 13). Ley N°21.719 que regula la protección y el tratamiento de los datos personales y crea la Agencia de Protección de Datos Personales. https://www.bcn.cl/leychile/navegar?idNorma=1209272
- InfoProtección. (2025). Todo lo que debes saber sobre la ley 21719 en Chile. https://www.infoproteccion.com/leyes-ciberseguridad/chile/todo-lo-que-debe-saber-sobre-la-ley-21719-en-chile-proteccion-de-datos-personales/
- Codevsys. (2026, Enero 16). Ley 21.719: Guía práctica de protección de datos personales para empresas en Chile. https://www.codevsys.cl/blog/ley-21719-guia-practica
- ResGuard Solutions. (2026, Febrero). La Nueva Ley de Protección de Datos de Chile (Ley 21.719): Guía Completa. https://resguard-solutions.com/blog/es/chile-data-protection-law-21719-guide/
- Amsoft. (2026, Enero 8). Adecuación tecnológica integral: Preparando tu empresa para la Ley 21.719 de Protección de Datos Personales. https://www.amsoft.cl/ley-21719-adecuacion-tecnologica-proteccion-datos/
- FCGroup. (2025, Agosto 12). Puntos claves de la Ley 21719 – Derechos ARCOP https://fcgroup.cl/puntos-claves-de-la-ley-21719/