Construir compliance al final cuesta el triple. Construirlo al principio, casi nada. Esta es la diferencia que estamos viendo en productos agentic.
La obligación que muchos están descubriendo tarde
El AI Act europeo entró en vigor el 1 de agosto de 2024 y sus obligaciones se aplican por fases hasta agosto de 2026. La parte que afecta a productos agentic comerciales — los que automatizan comunicación con clientes, gestionan pipelines, ejecutan acciones — cae dentro de "limited risk" o "high-risk" según el caso. Para "limited risk" la exigencia mínima es transparencia (el usuario debe saber que interactúa con un sistema de IA). Para "high-risk" se suma trazabilidad, supervisión humana significativa, evaluación de riesgos y registro técnico (texto consolidado).
Hay productos que están añadiendo logs ahora, en producción. Ese trabajo es órdenes de magnitud más caro que diseñarlo desde el principio.
Qué es exactamente un ActionLog inmutable
Un ActionLog no es un timeline de eventos. Es un registro append-only de cada decisión del agente con suficiente información para que un auditor externo pueda reconstruirla. Concretamente, cada entrada incluye:
- Input context. Qué datos vio el agente para tomar la decisión: lead, mensajes previos, custom fields relevantes, scoring vigente. Snapshot en el momento, no referencia que pueda mutar después.
- Policy aplicada. Qué versión de qué playbook estaba activa. Las políticas también versionan.
- Proposal. Qué quería hacer el agente exactamente: enviar mensaje X, mover stage a Y, programar tarea Z.
- Approval state.
proposed,approved,rejected,auto-approved(con la regla que disparó),expired. - Outcome. Qué pasó realmente cuando se ejecutó. Si la API externa falló, queda registrado. Si el lead respondió, también.
- Identifiers. Workspace, agente, modelo, run id. Todo firmado para que la cadena sea verificable.
La inmutabilidad importa. Si un operador puede editar el log a posteriori, deja de ser auditoría. Append-only y firmado son requisitos no opcionales.
Por qué esto se diseña desde el principio
Hay tres razones técnicas por las que retroactivar trazabilidad es caro.
El contexto que veía el agente en T-1 ya no existe. Cuando un lead avanza, sus campos cambian. Si solo guardas referencias, no puedes reconstruir qué leyó el agente cuando decidió. Tienes que guardar snapshots desde el inicio, lo que cambia el modelo de datos entero.
Las políticas evolucionan más rápido que el código. Los playbooks que rigen al agente se editan semanalmente. Si no los versionas con identifier estable, no puedes responder "¿por qué el agente hizo esto en marzo si la política actual diría otra cosa?".
Los outcomes son asincrónicos. Una propuesta del agente puede ejecutarse minutos después (porque pasa por aprobación) y su outcome real puede llegar horas después (porque depende de la respuesta del cliente). El log tiene que enlazar las tres fases sin romperse cuando algo se queda pendiente.
Construir esto desde el día 1 cuesta una semana de diseño. Añadirlo en producto vivo, con datos heredados, cuesta meses de migración.
Cómo no frena la velocidad
La objeción habitual: "compliance frena el producto". En agentic es al contrario, por dos razones.
El log es el debugger. Cuando un agente se equivoca, el log es lo único que te dice por qué. Sin él, los bugs son misterios. Equipos que iteran rápido en producto agentic tienen mejor observabilidad, no peor. El ActionLog es esa observabilidad por defecto.
Las aprobaciones humanas reducen el riesgo de iterar. Cuando cada acción sensible pasa por revisión, puedes desplegar políticas nuevas sin tirar todo el sistema a producción. El humano es el circuit breaker. Eso permite hacer cambios más agresivos en el modelo o en los prompts sin miedo.
Qué hace falta para que el log sea defendible legalmente
Tres propiedades técnicas y tres organizativas.
Técnicas. Append-only a nivel de almacenamiento (no solo a nivel de aplicación — la base de datos no debe permitir UPDATE/DELETE en la tabla del log). Firma criptográfica por workspace para que un export sea verificable. Retención mínima de 6 años para alinearse con normas de protección de datos europeas.
Organizativas. Un Data Protection Impact Assessment (DPIA) público o disponible bajo NDA. Un proceso documentado de revisión humana — quién aprueba qué, cuándo, con qué autoridad. Un canal para que un usuario afectado solicite explicación de una decisión que le afectó.
Si tu producto no tiene esas seis cosas, no estás listo para vender al mercado europeo enterprise. Y los compradores europeos lo van a preguntar antes que el precio.
Lo que construimos en CloserGaaS
ActionLog es uno de los tres ciudadanos de primera clase de la plataforma — junto con aprobaciones nativas y kill switch global. La decisión de hacerlo así no fue compliance — fue debugability. Pero el efecto secundario es que el AI Act se cumple por construcción, no por parche.
El kill switch corta toda actividad del agente en menos de 10 segundos. Las aprobaciones permiten al operador definir scopes granulares por tipo de acción. El ActionLog registra todo, append-only, firmado, exportable.
No vendemos esto como "compliance feature". Lo vendemos como infraestructura de operación responsable. Pero cuando un comprador europeo nos pregunta "¿cómo cumples el AI Act?", la respuesta cabe en una pantalla.
Si estás construyendo agentic en 2026 y todavía no has decidido cómo vas a registrar las decisiones del agente, ese es el siguiente sprint. Antes que el modelo, antes que el feature.
Lecturas relacionadas
- Metimos un agente encima de GoHighLevel y descubrimos que no escala — por qué la trazabilidad nativa solo se construye desde una capa propia.
- Multi-CRM por diseño vs IA bolted-on — sin log propio no eres apto para venta enterprise europea.
Si estás construyendo agentic en 2026 y necesitas auditoría desde el día 1, únete a la waitlist — CloserGaaS tiene ActionLog inmutable, aprobaciones nativas y kill switch como ciudadanos de primera clase.