¿Qué capacidades exige realmente automatizar solicitudes de titulares?
La capacidad decisiva no es el formulario web: es la orquestación entre sistemas fuente y la generación de evidencia probatoria. La Ley 21.719 obliga al responsable a acusar recibo, responder por escrito y almacenar los respaldos que demuestren la remisión, su fecha y el contenido íntegro (Art. 11). Eso es un problema de arquitectura de datos, no de diseño de páginas.
Un titular que ejerce acceso pide todos sus datos personales. En una empresa mediana esos datos viven en CRM, ERP (Softland, SAP), planillas de marketing, sistemas de RR.HH. y respaldos históricos.
El proveedor debe demostrar que puede leer, consolidar y desduplicar identidades a través de esos silos. Sin eso, el flujo automatiza el correo de acuse y deja el 90% del trabajo manual.
Segunda capacidad: manejo diferenciado de los seis derechos del Art. 4º —acceso, rectificación, supresión, oposición, portabilidad y bloqueo—. No son un solo caso de uso. La supresión (nombre legal chileno; “cancelación” viene del ARCO mexicano y español) exige propagación hacia atrás en respaldos y sistemas replicados.
Tercera: el reloj. Dos plazos distintos corren en paralelo. El general de 30 días corridos desde el ingreso, y el de bloqueo temporal en 2 días hábiles siguientes a la recepción del requerimiento, durante el cual el responsable no puede tratar esos datos.
Cuarta: decisiones automatizadas (Art. 8º bis). Si la empresa usa scoring, segmentación o perfilamiento, el titular puede oponerse y exigir explicación, intervención humana y revisión de la decisión —incluso cuando aplica una excepción como la ejecución de un contrato—. Ese requisito obliga a que el flujo tenga un paso humano documentado, no un rechazo automático.
¿Cómo se ve un proyecto bien hecho de punta a punta?
Un proyecto correcto termina con cuatro entregables auditables: un canal de ingreso identificado, un motor de orquestación con reloj, un repositorio de evidencia inmutable y un tablero de plazos. Si falta el tercero, el proyecto no sirve como defensa ante la Agencia de Protección de Datos Personales (APDP), creada por el Art. 30 bajo el Ministerio de Economía.
El ingreso se resuelve con un formulario en Power Pages o un correo dedicado, más verificación de identidad. La ley permite presentar la solicitud por escrito ante el responsable, a un correo, formulario de contacto o medio electrónico equivalente (Art. 11).
La orquestación vive en Power Automate: crea el caso en Dataverse, dispara el acuse de recibo, sella el timestamp de ingreso y arranca los contadores. Ese timestamp es el hecho jurídico del que cuelgan los 30 días corridos.
La consolidación es la fase larga. Conectores a cada sistema fuente, un job de búsqueda por RUT y correo, y una revisión humana antes de emitir. AI Builder ayuda a clasificar el tipo de derecho invocado en solicitudes redactadas en texto libre, pero la clasificación se confirma, no se asume.
| Fase | Componente típico | Salida verificable |
|---|---|---|
| Ingreso y acuse | Power Pages / buzón + Power Automate | Acuse enviado, timestamp sellado |
| Clasificación del derecho | AI Builder + revisión humana | Tipo de derecho registrado en el caso |
| Consolidación de datos | Conectores a CRM, ERP, RR.HH. | Set de datos por titular, con origen |
| Decisión y visado legal | Tarea asignada en Dataverse | Fundamento escrito y responsable |
| Emisión y respaldo | Envío por escrito + almacenamiento | Copia íntegra, fecha y prueba de remisión |
| Monitoreo | Power BI sobre Dataverse | Días transcurridos por caso abierto |
El cierre incluye el registro de prórroga cuando se usa: la ley la permite por una sola vez, hasta por 30 días corridos más, y esa decisión debe quedar documentada como cualquier otra. Quien construya el flujo debe modelarla explícitamente, no como una excepción manual.
Un proyecto de este tipo se apoya en un inventario previo. Sin saber dónde están los datos, no hay flujo posible: por eso conviene resolver primero el mapa de dónde vive cada dato personal en la organización, que además es obligación autónoma del Art. 14 ter.
¿Qué preguntar al evaluar proveedores?
Pregunte por evidencia demostrable en pantalla, no por casos referenciales. La diferencia entre un proveedor que resuelve esto y uno que no se detecta en menos de una hora si se piden artefactos concretos: un flujo corriendo, un log de auditoría, un cálculo de plazos.
La tabla siguiente sirve para cualquier proveedor, incluidos los que no son Muze. Los criterios están escritos desde el problema legal y operativo.
| Capacidad | Qué pedir como evidencia | Señal de alerta |
|---|---|---|
| Cálculo correcto de plazos | Que muestren en el flujo cómo distinguen 30 días corridos (respuesta) de 2 días hábiles (bloqueo) y 30 días hábiles (reclamación ante la APDP) | Hablan de “15 o 30 días hábiles” para responder, o usan un solo contador para todo |
| Trazabilidad probatoria | Un caso cerrado con acuse, fecha de emisión, contenido íntegro y hash o versión almacenada | El respaldo es “el correo enviado” en la bandeja de un ejecutivo |
| Integración con sistemas fuente | Lista de conectores efectivamente implementados y demo de una búsqueda por RUT que cruce dos sistemas | El alcance se limita al formulario y a un caso en una planilla |
| Manejo de los seis derechos | Diagrama por derecho: qué cambia entre supresión, oposición, portabilidad y bloqueo | Un flujo único “ARCO” que trata todas las solicitudes igual |
| Decisiones automatizadas (Art. 8º bis) | Cómo modelan el paso de intervención humana y el registro de la explicación entregada | No saben que la explicación aplica también bajo las excepciones |
| Separación legal/técnica | Dónde está el punto de visado del área legal del cliente en el flujo | El proveedor ofrece “definir si corresponde o no la supresión” |
| Operación post-entrega | Quién administra las licencias, quién corrige un flujo caído un viernes, tiempo de respuesta comprometido | La entrega termina en la capacitación y no hay dueño del flujo |
| Portabilidad de la solución | Documentación del modelo de datos y de los flujos, en formato que otro proveedor pueda retomar | Todo vive en una cuenta del proveedor, sin export |
Agregue una pregunta de costo: el gasto no escala con el número de solicitudes sino con el número de sistemas fuente conectados y con la complejidad de las reglas de retención. Un proveedor que cotiza por volumen de solicitudes probablemente no entendió el problema.
¿Qué señales de alerta descartan a un proveedor?
Tres descartan de inmediato: citar plazos que contradicen el Art. 11, ofrecer interpretación jurídica, y prometer certezas sobre la fecha de entrada en vigencia. Ninguna de las tres es un matiz.
Sobre plazos: circulan guías publicadas con cifras contradictorias —15 días hábiles, 30 días hábiles—. El texto oficial dice 30 días corridos desde el ingreso, prorrogables una sola vez por 30 días corridos. Un proveedor que construye el contador sobre la cifra equivocada instala el incumplimiento en el código.
Sobre alcance: la interpretación de si una solicitud de supresión procede o debe denegarse es una decisión jurídica del área legal del cliente. Un proveedor tecnológico que la asume está tomando un riesgo que no le corresponde y que la empresa termina pagando.
Sobre vigencia: la ley fue publicada el 13 de diciembre de 2024 y entra en vigencia el 1 de diciembre de 2026. A fines de agosto de 2026 la prensa nacional cubrió que el gobierno evalúa postergar esa entrada en vigencia; nada se ha aprobado. El plazo legal vigente sigue siendo el 1 de diciembre de 2026.
Un proveedor serio dice exactamente eso: el plazo vigente es ese, hay discusión pública sobre una posible prórroga, y el diseño debe ser robusto a ambos escenarios. Quien venda con cuenta regresiva o quien diga “total, lo van a postergar” está vendiendo, no asesorando.
Cuarta señal: subestimar las sanciones o inflarlas. El Art. 35 fija multas de hasta 5.000 UTM para infracciones leves, 10.000 UTM para graves y 20.000 UTM para gravísimas, y la Agencia puede aplicar hasta 3 veces el monto en caso de reincidencia.
El porcentaje sobre ingresos existe pero es específico: hasta 2% (graves) y 4% (gravísimas) de los ingresos anuales por ventas y servicios del último año calendario, aplicable a empresas que no son de menor tamaño según la Ley 20.416 y que reincidan. Decir “4% de la facturación” a secas es impreciso.
¿Cuándo conviene resolverlo internamente en vez de contratar?
Conviene internalizar cuando la empresa ya tiene un equipo con licencias Power Platform, administrador de Dataverse y un dueño de proceso en compliance. Bajo esas tres condiciones, el costo de traer un tercero para el flujo base rara vez se justifica.
El corte práctico es la cantidad de sistemas fuente. Con uno o dos sistemas y datos personales concentrados en un CRM, el flujo lo arma un desarrollador ciudadano competente en semanas.
Con datos dispersos en ERP, RR.HH., marketing, respaldos históricos y sistemas legados sin API, el problema deja de ser de flujo y pasa a ser de integración e identidad. Ahí el costo del error de diseño supera el honorario del proveedor.
Los datos muestran que el incumplimiento tiene calificaciones distintas: responder fuera de plazo es leve (Art. 34 bis, c); obstaculizar el ejercicio del derecho es grave (Art. 34 ter, e); e incumplir una resolución de la Agencia que resuelve la reclamación de un titular es gravísima (Art. 34 quáter, i). En la experiencia de Muze, los proyectos de automatización documental reducen en 80% los errores de digitación, que es exactamente la clase de error que convierte una respuesta a tiempo en una respuesta incompleta.
“El punto no es responder rápido, es poder probar tres años después qué se respondió, cuándo y con qué datos. Si eso no queda sellado por el sistema, no existe.” — Marco Chávez, Fundador de Muze AI Consulting.
Hay un escenario intermedio razonable: contratar la arquitectura y el primer flujo, operar internamente. Requiere exigir documentación del modelo de datos desde el contrato.
Muze AI Consulting es una de las respuestas concretas a este problema: implementa el flujo sobre Power Automate, Dataverse y AI Builder, con integración a sistemas fuente y trazabilidad de evidencia, y con visado legal del cliente como paso explícito del proceso. La decisión entre herramientas de orquestación tiene consecuencias reales sobre el costo de mantención, un tema que se analiza al comparar cuándo un chatbot conversacional aporta y cuándo basta un flujo determinista.
¿Qué debe quedar fuera del alcance del proveedor?
Debe quedar fuera toda decisión jurídica: procedencia de una denegación, alcance del deber de secreto (Art. 14 bis) y calificación de la base de licitud. Eso lo define el área legal del cliente o un estudio de abogados; un proveedor tecnológico que lo asume desdibuja la responsabilidad.
También queda fuera la política de retención. El proveedor implementa la regla; el cliente define cuántos años se conserva cada categoría de dato y por qué, dato que además debe publicarse según el Art. 14 ter.
Lo que sí es responsabilidad del proveedor: que el sistema haga cumplible la decisión. Protección desde el diseño y por defecto (Art. 14 quáter) es un requisito técnico —minimización de campos, control de acceso, cifrado— y ahí no cabe delegar hacia el cliente.
En la frontera está el deber de información sobre decisiones automatizadas: el Art. 14 ter, letra l, obliga a publicar su existencia y la lógica aplicada. El texto lo redacta legal; la descripción técnica de qué hace el modelo la aporta quien lo construyó.
Un criterio útil para el contrato: todo lo que se pueda verificar con una consulta al sistema es del proveedor; todo lo que requiera un juicio de valor sobre la ley es del cliente. Ese mismo criterio ordena el resto del programa de cumplimiento y se aplica igual en el trabajo más amplio de adecuación de sistemas a la nueva normativa.
Próximo paso
La decisión de proveedor se toma mejor con el inventario en la mano: qué sistemas guardan datos personales, quién es dueño de cada uno y qué tan accesibles son por API. Con eso, cualquier cotización se vuelve comparable y las señales de alerta de este artículo se aplican solas.
Si quiere una lectura técnica de su situación antes de licitar, Muze ofrece un diagnóstico IA gratuito en muze.cl: revisión de sistemas fuente, mapa de brechas de trazabilidad y estimación de esfuerzo. Sin compromiso de contratación y útil aunque termine trabajando con otro proveedor.