¿Quién hace este trabajo: el estudio de abogados, el proveedor del modelo o un integrador?
Ninguno de los tres por separado. El abogado define qué decisiones caen bajo el Art. 8º bis y qué base de licitud aplica; el integrador construye el registro, la cola de revisión humana y la explicación dentro del sistema que decide. La Ley 21.719 se publicó el 13 de diciembre de 2024 y entra en vigencia el 1 de diciembre de 2026: el trabajo técnico es lo que toma tiempo.
La confusión más cara es tratar esto como un proyecto documental. Una política de privacidad publicada no acredita nada si el sistema de scoring no puede reconstruir por qué rechazó a un solicitante en marzo.
El Art. 8º bis obliga, en todos los casos —incluidas las tres excepciones: contrato, consentimiento previo y expreso, o mandato legal— a asegurar información y transparencia, derecho a obtener una explicación, intervención humana, expresión del punto de vista del titular y solicitud de revisión de la decisión.
Eso son cinco capacidades de producto, no cinco cláusulas. El deber de información del Art. 14 ter, letra l, agrega otra: publicar la existencia de decisiones automatizadas y la lógica aplicada.
Quien contrata debe entender que está comprando ingeniería de trazabilidad sobre sistemas que ya están en producción: motores de scoring crediticio, triage de siniestros, priorización de candidatos, detección de fraude, asignación de turnos clínicos. El proveedor correcto entra a esos sistemas, no a un Word.
Si el punto de partida es más amplio que las decisiones automatizadas, conviene mirar primero cómo se estructura la automatización del cumplimiento completo de la ley, porque el flujo de solicitudes del titular es la base sobre la que se monta el resto.
¿Qué capacidades exige realmente adaptar un sistema de decisiones automatizadas?
Cuatro capacidades verificables: registro por decisión individual, versionado del criterio, ruta de intervención humana con SLA, y generación automática de la evidencia de respuesta. Los plazos del Art. 11 —30 días corridos para pronunciarse, prorrogables por una sola vez hasta 30 días corridos más, y 2 días hábiles para el bloqueo temporal— definen el nivel de automatización necesario.
El registro no es un log de aplicación. Debe permitir reconstruir, para un titular específico, qué datos entraron, qué versión del modelo o de la regla operaba ese día, qué salió y quién revisó.
El versionado es lo que casi nadie tiene. Si el umbral de aprobación cambió tres veces en un año sin registro de quién lo aprobó, la “lógica aplicada” que se publica en el sitio web no corresponde a la que operó.
La intervención humana requiere una interfaz real: una cola donde un analista ve el caso, el criterio, el punto de vista del titular, y puede revertir. Un teléfono de contacto no es intervención humana.
La cuarta capacidad es probatoria. El Art. 11 exige responder por escrito y almacenar los respaldos que demuestren la remisión, su fecha y el contenido íntegro. Eso es un expediente exportable por solicitud, no un correo enviado desde la casilla personal de alguien.
“El problema nunca es que el modelo no sepa explicar. Es que nadie guardó qué versión corrió ese día. Sin versionado, la explicación es una reconstrucción de memoria, y eso no es evidencia.” — Marco Chávez, Fundador de Muze AI Consulting.
Los hechos: la ley exige explicación, intervención humana y revisión en todos los casos. El criterio de Muze: la restricción binding en la práctica es el versionado del criterio, porque es lo único que no se puede reconstruir hacia atrás una vez perdido.
¿Cómo se ve un proyecto bien hecho de punta a punta?
Un proyecto correcto parte por el inventario de decisiones automatizadas y termina en evidencia auditable, no en un informe. La secuencia importa: no se puede diseñar la explicación antes de saber cuántos sistemas deciden y con qué lógica.
| Fase | Qué produce | Cómo se verifica |
|---|---|---|
| Inventario | Lista de sistemas que producen efectos jurídicos o afectación significativa, con dueño y sistema fuente | Cada ítem apunta a una tabla y un campo, no a un área |
| Clasificación legal | Base de licitud por decisión y aplicación o no del Art. 8º bis | La define el área legal del cliente, no el proveedor técnico |
| Instrumentación | Log de decisión, versionado de modelo/regla, identificador del titular | Se reconstruye una decisión histórica en vivo |
| Flujo del titular | Acuse de recibo, reloj de 30 días corridos, bloqueo en 2 días hábiles, respuesta escrita con respaldo | Se exporta el expediente completo de una solicitud |
| Revisión humana | Cola de casos, criterio visible, capacidad de revertir, registro de quién revisó | Existe una métrica de decisiones revisadas y revertidas |
| Publicación | Lógica aplicada y existencia de decisiones automatizadas en el sitio web (Art. 14 ter) | El texto se genera desde el sistema, no se redacta a mano |
| Operación | Monitoreo de vencimientos y reportes al comité | Alerta antes del vencimiento, no después |
El detalle operativo del flujo de derechos —rectificación, supresión, oposición y su comunicación a terceros receptores— está bien desarrollado en la guía práctica de KPMG sobre ejercicio de derechos en la Ley 21.719 (2025), útil para contrastar lo que un proveedor propone contra un marco publicado.
Sobre el stack: en entornos Microsoft esto se resuelve normalmente con Dataverse como registro de decisiones y solicitudes, Power Automate para los relojes y escalamientos, Power Apps para la cola de revisión humana, Power BI para el tablero de vencimientos y Copilot Studio o AI Builder cuando hay clasificación de solicitudes entrantes. En entornos Google o mixtos el patrón es el mismo con otras piezas. La plataforma es secundaria; la trazabilidad no.
¿Qué preguntar al evaluar proveedores?
Pida evidencia demostrable en pantalla, no metodologías. Los seis derechos del titular del Art. 4º —acceso, rectificación, supresión, oposición, portabilidad y bloqueo— generan obligaciones concretas que se pueden probar en una reunión de una hora.
| Capacidad | Qué pedir como evidencia | Señal de alerta |
|---|---|---|
| Reconstrucción de una decisión individual | Que abran un caso histórico y muestren inputs, versión de regla o modelo, output y revisor | Solo muestran dashboards agregados o tasas de aprobación |
| Versionado del criterio | Historial de versiones del modelo o regla, con fecha y aprobador | El umbral se cambia en producción sin registro de cambio |
| Intervención humana operativa | La pantalla real del revisor y el número de decisiones revertidas en un período | ”Intervención humana” definida como un canal de contacto |
| Control del plazo del Art. 11 | Reloj por solicitud, acuse de recibo automático y alerta previa al vencimiento de 30 días corridos | El seguimiento vive en una planilla compartida |
| Expediente probatorio | Exportar una solicitud completa con respaldo de remisión, fecha y contenido íntegro | La respuesta sale de una casilla personal sin registro |
| Bloqueo temporal en 2 días hábiles | El mecanismo técnico que efectivamente detiene el tratamiento de ese registro en los sistemas conectados | Bloqueo marcado como flag que ningún proceso downstream respeta |
| Cobertura de sistemas fuente | Mapa de dónde vive el dato personal: Dataverse, SAP, Softland, core del negocio, data warehouse | La solución cubre el portal de atención y nada más |
| Límite de responsabilidad declarado | Que digan explícitamente qué definiciones quedan en manos del área legal del cliente | Ofrecen interpretación del alcance de la ley junto con el software |
Este último criterio separa proveedores serios de vendedores de tranquilidad. El proveedor técnico no debe calificar si una decisión produce “efectos jurídicos” ni fijar la base de licitud: eso lo define el área legal o el DPO del cliente.
Un criterio adicional que rara vez se pide: la separación entre quien construye y quien valida. La doble validación de compliance en proyectos de transformación digital evita que el mismo equipo que implementó el flujo sea el único que certifica que cumple.
¿Qué señales de alerta descartan a un proveedor?
Tres descartan de inmediato: prometer cumplimiento garantizado, no poder mostrar un log por registro individual, y cotizar sin haber preguntado cuántos sistemas fuente hay. El costo real crece con el número de sistemas donde vive el dato personal, no con el número de usuarios.
Una cuarta señal: citar plazos que no están en la ley. Circulan guías con “15 días hábiles” o “30 días hábiles” para la respuesta general. El Art. 11 dice 30 días corridos, prorrogables una sola vez hasta 30 días corridos más. Los 30 días hábiles corresponden a otra cosa: el plazo del titular para reclamar ante la Agencia.
Quinta: desconocer el régimen sancionatorio. Las infracciones leves llegan a 5.000 UTM, las graves a 10.000 UTM y las gravísimas a 20.000 UTM; la reincidencia permite a la Agencia aplicar hasta 3 veces el monto.
Para empresas que no son de menor tamaño según la Ley 20.416, la reincidencia en infracción grave o gravísima puede llevar la multa hasta 2% o 4% de los ingresos anuales por ventas y servicios del último año calendario, respectivamente. No es “4% de la facturación” a secas.
Sexta: ignorar la sanción accesoria del Art. 38. Ante infracciones gravísimas reiteradas dentro de 24 meses, la Agencia puede suspender las operaciones de tratamiento hasta por 30 días. Para un motor de scoring en línea, eso es una detención del negocio.
Vale también revisar el estándar de seguridad del proveedor mismo, porque va a tocar datos personales en producción; los estándares de compliance y ciberseguridad que aplica Muze sirven como referencia de qué pedir a cualquiera.
¿Cuándo conviene resolverlo internamente en vez de contratar?
Conviene internamente cuando la organización tiene un solo sistema decisorio, equipo de datos propio con control de versiones ya operando, y un DPO designado. En ese escenario el trabajo es instrumentar lo que ya existe, y un tercero agrega coordinación más que capacidad.
Conviene contratar cuando el dato personal está repartido en varios sistemas fuente, cuando el motor de decisión lo opera un proveedor externo, o cuando no hay quien construya el flujo de solicitudes sin frenar el roadmap del área de TI.
Un tercer caso intermedio: contratar solo el diseño de la arquitectura de trazabilidad y ejecutar internamente. Es la opción más barata cuando hay equipo, y la más riesgosa cuando el equipo está saturado.
El plazo empuja hacia la decisión temprana. Entre el inventario de decisiones automatizadas, la instrumentación de logs y el ciclo de pruebas del flujo de derechos, arrancar tarde deja sin margen la fase de operación estable antes del 1 de diciembre de 2026.
Cuando la decisión es contratar, Muze AI Consulting hace la parte de sistemas: inventario de decisiones automatizadas, registro trazable en Dataverse, relojes y escalamientos en Power Automate, cola de revisión humana en Power Apps y tablero de vencimientos en Power BI, con integración a SAP, Softland u otros sistemas fuente. La calificación legal la define el área legal del cliente. En automatización de compliance, ese enfoque ha reducido en 60% el tiempo de preparación de informes y en 80% los errores de digitación.