Ley 21.719: del checkbox al control real de consentimientos

La Ley 21.719, publicada el 13 de diciembre de 2024, introduce un nuevo marco para la protección de datos personales en Chile. Sus principales modificaciones entran en vigencia el 1 de diciembre de 2026. El desafío para las organizaciones es conocer sus tratamientos y documentar cuándo corresponde solicitar, registrar y respetar el consentimiento de las personas. El marketing necesita datos. Operaciones no puede paralizarse. TI arrastra sistemas legados con lógicas distintas. Y el directorio pide certezas: ¿estamos cumpliendo? ¿Podemos demostrarlo?

El problema no es el checkbox. Es la trazabilidad operativa que soporta ese click en todos los procesos donde los datos circulan: formularios web, apps móviles, call center, CRM, CDP, e-commerce, analítica, proveedores. Sin un control central del consentimiento —con versiones y revocación efectivos— la organización queda expuesta a incumplimientos, reclamos y pérdida de confianza.

Este artículo propone criterios ejecutivos y técnicos para decidir, una arquitectura aplicable y señales de alerta. Además, explica cómo un servicio SaaS de gestión de consentimientos —API-first, con SDKs y soporte de integración— acelera la implementación sin reescribir sus plataformas.

Estado de la posible postergación al 9 de noviembre de 2026

La postergación todavía no es ley. La Ley 21.719 mantiene por ahora como fecha de entrada en vigencia el 1 de diciembre de 2026. El Senado aprobó el 28 de octubre de 2026 el proyecto de ley Boletín 18.623-07, que propone cambiar la fecha al 15 de octubre de 2027. La iniciativa continúa en segundo trámite constitucional ante la Cámara de Diputadas y Diputados. La nueva fecha solo será exigible si se completa su tramitación y se publica la modificación legal. Para fines de cumplimiento conviene planificar con la fecha vigente y seguir el estado oficial del proyecto en la Cámara.

Qué cambia con la Ley 21.719 y cuándo

La Ley 21.719 modifica la Ley 19.628 y establece nuevos derechos y obligaciones a partir del 1 de diciembre de 2026. El consentimiento es una de las posibles bases de licitud del tratamiento, pero no la única: cada organización debe determinar cuál corresponde según la finalidad y el caso. La trazabilidad del consentimiento es especialmente útil cuando este es la base utilizada. Desde la perspectiva de negocio y TI, conviene revisar:

• Consentimiento informado y granular por finalidad: no basta un permiso genérico; debe quedar claro para qué se usarán los datos y en qué canales.
• Registro verificable del consentimiento: evidencia con marca de tiempo, versión del texto aceptado, canal, dispositivo y usuario que ejecuta la acción.
• Revocación simple y efectiva: la persona debe poder retirar su consentimiento, y la revocación debe propagarse a todos los sistemas que usan ese dato.
• Versionado de políticas y finalidades: si cambia el texto o el alcance, hay que conservar el histórico y vincularlo a cada consentimiento otorgado.
• Rendición de cuentas: capacidad de responder a auditorías internas/externas con reportes y evidencias.
• Seguridad y minimización: proteger el registro de consentimientos y limitar su uso sólo a lo autorizado.

Traducción operativa: si hoy su organización no puede responder —en minutos, con evidencia— a la pregunta “¿Cuál es el estado de consentimiento de esta persona y bajo qué versión de texto lo otorgó?”, hay una brecha que atender.

Dónde se rompe en la práctica: riesgos y puntos ciegos

• Consentimientos dispersos: formularios en web, SDKs móviles, campañas, y un call center que anota en el CRM. Cada uno registra distinto, a veces sin versión del texto.
• Revocaciones que no se propagan: alguien se desuscribe, pero la acción no llega al CDP o al proveedor de SMS. Resultado: envíos indebidos y riesgo reputacional/legales.
• Versiones sin trazabilidad: se actualiza la política de privacidad y se sobreescribe el texto previo, perdiendo el vínculo con consentimientos antiguos.
• Integraciones de terceros: herramientas de analítica o marketing con sus propias definiciones de “consent”. Si no hay un orquestador central, cada una opera por su cuenta.
• Auditorías reactivas: buscar evidencias en logs o correos cuando llega un requerimiento. Caro, lento y poco confiable.

Señales de alerta:

• No existe un “registro único de consentimientos” (RUC) consultable vía API.
• La revocación depende de tickets manuales o cargas masivas esporádicas.
• No hay tablero de cobertura: ¿qué porcentaje de contactos tiene consentimiento válido por canal/finalidad?
• El equipo legal no puede ver versiones históricas y muestras de evidencia sin pedir a TI.

Principios de diseño: consentimiento como capacidad transversal

Cuando el consentimiento sea la base jurídica aplicable, considérelo una capacidad transversal de plataforma. Un registro centralizado es una decisión de arquitectura, no una obligación legal universal:

1) Registro único, API-first

• Un servicio central que emite y consulta el estado de consentimiento por persona, canal y finalidad.
• API para crear, actualizar, revocar y auditar, más webhooks para propagar cambios a sistemas consumidores.

2) Modelo de datos explícito

• Persona (o identificador seudonimizado), canal (email, SMS, push, llamada), finalidad (marketing, analítica, fidelización), ámbito (marca/país), versión del texto, timestamp, fuente, evidencia (IP, user-agent, hash de contenido).

3) Versionado inmutable

• Las versiones de textos y finalidades se almacenan como artefactos inmutables. Todo consentimiento apunta a su versión.

4) Revocación como evento

• Una revocación genera un evento que notifica a sistemas suscritos (CRM, CDP, email, data lake) para bloquear usos futuros.

5) Gobernanza y auditoría

• Roles y permisos para aprobar nuevas finalidades/versiones.
• Logs de acceso, reportes de cobertura, exportables para auditoría.

6) Seguridad por diseño

• Cifrado en tránsito y en reposo del registro de consentimientos.
• Minimización: compartir sólo estados (permitido/denegado/expirado) y metadatos necesarios, no más datos personales.

Arquitectura de referencia (sin rehacer sus sistemas)

• Orquestador de Consentimientos (servicio central): API REST para alta/consulta/revocación, webhooks, catálogo de finalidades y motor de versiones.
• SDKs y adaptadores por canal:

- Web: widget o SDK para capturar consentimiento y vincularlo a la versión vigente. - Móvil: SDK iOS/Android para flujos nativos y sincronización offline/online. - Backend: SDKs para Java, .NET, Node.js, Python, PHP que incorporen la consulta del estado antes de enviar comunicaciones o procesar datos.

• Integración con plataformas clave:

- CRM/MA/CDP: conectores o jobs idempotentes que consumen webhooks de revocación y actualizan listas/supresiones. - Data Platform/BI: tabla de “estado de consentimiento” con vigencia histórica para segmentaciones y cumplimiento en analítica. - Call center: UI sencilla para leer/actualizar estados con grabación de evidencias (ej., consentimiento verbal con folio).

• Monitoreo y auditoría: métricas de cobertura por finalidad, latencia de propagación de revocaciones, tasas de error por canal, reportes de evidencia.

Trade-offs clave:

• Centralizar vs. federar: centralizar simplifica auditoría y propagación; federar puede ser útil en conglomerados con marcas independientes, pero exige contratos de integración y métricas comunes.
• CMP de cookies vs. consentimiento integral: un “cookie banner” no resuelve consentimientos para CRM, SMS o llamadas. Úselo como componente, no como estrategia.
• Construir vs. adoptar SaaS: construir da control fino pero toma meses y capitaliza deuda técnica; un SaaS especializado reduce tiempo de salida y riesgo, siempre que exponga API/SDK e integre con sus sistemas.

Hoja de ruta sugerida (8–12 semanas, adaptable)

Fase 1 — Diagnóstico y riesgos (1–2 semanas)

• Mapeo de finalidades, canales y sistemas que consumen datos personales.
• Inventario de textos/formatos vigentes y brechas de evidencia.
• Definición de métricas: cobertura por finalidad, tiempo de propagación de revocación, tasas de error.

Fase 2 — Diseño y piloto (3–4 semanas)

• Definición del modelo de datos y catálogo de finalidades.
• Selección del orquestador (SaaS/API-first) y SDKs por canal.
• Piloto en un flujo crítico (por ejemplo, newsletter y CRM) con versionado y revocación end-to-end.

Fase 3 — Integraciones prioritarias (3–4 semanas)

• Conexión con CDP, email/SMS, e-commerce y data platform.
• Activación de webhooks para revocaciones y reportes de auditoría.
• Operación paralela y validación de métricas.

Fase 4 — Operación y mejora continua (2 semanas+)

• Tableros ejecutivos y alarmas.
• Procedimientos de revisión de textos/versiones y controles de cambios.
• Entrenamiento a Legal, Marketing, Operaciones y TI.

Cuándo ajustar el plan:

• Conglomerados multi-marca o países: evalúe modelo federado con contratos de servicio y taxonomía común.
• Sistemas legados sin APIs: planifique adaptadores o colas intermedias.
• Altos volúmenes: considere colas/eventos y particionamiento del registro.

Métricas que importan a gerencia

• Cobertura de consentimiento por finalidad/canal: porcentaje de contactos con consentimiento válido y vigente.
• Latencia de revocación: tiempo desde la solicitud de revocación hasta reflejarse en todos los sistemas críticos.
• Incidentes evitados: envíos bloqueados por falta de consentimiento (indicador de control efectivo).
• Trazabilidad de auditoría: tiempo promedio para entregar evidencia completa por requerimiento.
• Debt radar: número de sistemas aún sin integración al orquestador.

Cómo ayudamos: SaaS de consentimientos con API y SDKs listos

Una opción para abordar el consentimiento a escala es evaluar un servicio SaaS que centralice su ciclo de vida y se integre con las plataformas existentes. Antes de contratar, verifique qué capacidades ofrece realmente el proveedor. Características a evaluar:

• API-first y webhooks: alta/consulta/revocación/auditoría vía REST, con eventos para propagar cambios a CRM, CDP, email y data platform.
• Versionado y catálogo de finalidades: gestionamos versiones inmutables de textos y finalidades; cada consentimiento referencia su versión.
• Evidencias completas: timestamp, canal, fuente, user-agent/IP (cuando aplica) y hash del contenido aceptado.
• Revocación efectiva: flujos y endpoints para retirar consentimiento por persona/canal/finalidad, con propagación a sistemas suscritos.
• SDKs y ejemplos: para stacks tecnológicos habituales (Java, .NET, Node.js, Python, PHP, Android, iOS, React/Vue) y guías de integración.
• Operación y soporte: monitoreo, métricas de cobertura, reportes de auditoría y acompañamiento de integración, previa evaluación del alcance.

Además, si su contexto lo requiere, un equipo especializado puede hacerse cargo de integrar la solución seleccionada en sus sistemas, evaluar excepciones de legado y dejar la operación estabilizada. Revise nuestras líneas de servicio en /servicios y experiencias en /casos-de-exito.

Cuándo este enfoque calza bien:

• Varias marcas/canales con herramientas distintas de marketing/CRM.
• Necesidad de cumplir y auditar sin rehacer frontends o apps móviles.
• Equipos de TI con backlog lleno que requieren SDKs y ejemplos listos.

Cuándo no es la mejor opción:

• Organizaciones con una sola app/stack muy homogéneo y bajo volumen, donde un módulo ligero embebido puede ser suficiente.
• Escenarios 100% on-prem sin conectividad saliente y con restricciones que impiden consumo de APIs externas (requiere análisis específico).

Checklist rápido antes de la vigencia

• ¿Tiene un registro único y consultable de consentimientos con versión y evidencia?
• ¿Puede revocar por persona/canal/finalidad y medir la propagación de la revocación a los sistemas críticos?
• ¿Legal/Compliance puede extraer un paquete de evidencia sin involucrar a TI cada vez?
• ¿Existen KPIs y alertas por latencia de revocación y cobertura de consentimiento?
• ¿Hay un procedimiento para publicar nuevas versiones de textos y mapear su vigencia?
• ¿Los proveedores que tratan datos (email, SMS, analítica) consumen su estado de consentimiento o siguen reglas propias?

Si respondió “no” a dos o más, está a tiempo de priorizar un piloto enfocado y cerrar brechas.

Cierre: decidir con criterio y moverse ahora

Prepararse para la Ley 21.719 no se resuelve solamente agregando un banner. Es dotar al negocio de una capacidad operativa para administrar, auditar y respetar el consentimiento en todo el ciclo de vida del dato. La decisión clave es si construye esa capacidad desde cero o la adopta como un servicio especializado, integrándola de forma incremental a sus sistemas críticos.

Si quiere un diagnóstico concreto y un plan de integración realista —alineado a sus riesgos, plazos y presupuesto— conversemos. Nuestro equipo puede mostrarle el SaaS en vivo, los SDKs, ejemplos de uso y una arquitectura de referencia para su contexto.

• Conozca nuestras capacidades: /servicios
• Revise experiencias: /casos-de-exito
• Agende una sesión consultiva: /contacto

Nota: este artículo es informativo y no constituye asesoría legal. Para obligaciones concretas y disposiciones transitorias, consulte el texto oficial y a su equipo legal.

Fuente oficial y actualización

Este artículo fue corregido el 9 de noviembre de 2026 para identificar correctamente la Ley 21.719 y su fecha de entrada en vigencia. La Ley 21.279 trata sobre la prórroga de documentos de identidad para votar, no sobre protección de datos. Consulte la Ley 21.719 en la Biblioteca del Congreso Nacional. Hasta el 30 de noviembre de 2026 sigue vigente el régimen anterior de la Ley 19.628, sin perjuicio de otras normas aplicables.

Lecturas y referencias

• Artículo relacionado de ZopiTech