Enforcement vs. observación: por qué registrar lo que hacen tus automatizaciones no es gobernanza

En el último año, «gobernanza de agentes de IA» se ha convertido en una etiqueta pegada a casi cualquier producto capaz de producir un dashboard. La mayoría de lo que se vende bajo esa etiqueta es observabilidad: el agente actúa, la plataforma registra, alguien revisa. Esa arquitectura es familiar, útil — y estructuralmente incapaz de hacer lo único que significa gobernar.

El reflejo de la observabilidad

Históricamente, cuando el software se portaba mal, lo instrumentábamos. Métricas, trazas, logs — toda la disciplina asume que el coste de una mala acción es acotado y reversible, y que basta con detectarla rápido. Un endpoint lento cuesta latencia; lo encuentras, lo arreglas.

Los agentes rompen esa premisa. Un agente con credenciales de producción no produce endpoints lentos; produce órdenes de compra, reembolsos, cláusulas contractuales y transferencias de datos. Para cuando la anomalía aparece en un dashboard, la acción ya tiene existencia legal y financiera. Un e-commerce europeo con el que hablamos vio a su agente de inventario emitir 127 órdenes de compra duplicadas — 340.000 € — en cuatro horas. Los logs eran perfectos. Nadie miraba a las 2 de la madrugada.

Un log no es un control

Los auditores distinguen entre controles detectivos y preventivos, y esa distinción es exactamente la que importa aquí. Un log — incluso uno perfecto, inmutable y sellado criptográficamente — es un control detectivo. Cambia lo que puedes demostrar, no lo que puede pasar.

La observación cambia lo que puedes demostrar. El enforcement cambia lo que puede pasar.

Para los empleados humanos, las empresas nunca aceptaron controles solo detectivos en acciones con consecuencias. Los pagos exigen cadenas de aprobación; los accesos, aprovisionamiento; los contratos, poder de firma. La pregunta incómoda es por qué un agente — más rápido que cualquier empleado y menos predecible que cualquier script — debería operar con controles más débiles que el becario.

Qué cambia la autorización pre-ejecución

Un punto de decisión de políticas delante de la acción invierte el valor por defecto. El agente pregunta primero; una política declarativa responde en milisegundos; el veredicto — allow, review o block — va firmado y acotado en el tiempo. El agente de inventario desbocado corre otra suerte: la tercera orden duplicada incumple la política, las autorizaciones se detienen y un humano recibe el aviso con todo el contexto de la decisión. La pérdida la acota la política, no quien se despierte primero.

Lo crucial: esto no exige reconstruir el agente. El punto de decisión puede vivir dentro de un flujo de n8n como nodo, dentro de Salesforce como conector, o detrás de una llamada de SDK — los raíles del propio agente ejecutan la acción, bajo un veredicto que ya existe cuando lo hacen.

Qué preguntará el regulador

Las disposiciones de supervisión humana del AI Act (artículo 14) están escritas en lenguaje de prevención: medidas que permiten a los humanos «intervenir» e «interrumpir» el sistema. Una arquitectura que solo puede narrar lo que ya pasó no tiene historia de intervención. Una donde cada acción con consecuencias lleva un veredicto pre-ejecución, un humano responsable y un registro sellado — sí la tiene.

Los stacks de observabilidad siguen siendo esenciales — después de que Kimetai autorice una acción, la traza de su ejecución sigue perteneciendo a tu SIEM, y exportamos allí de forma nativa. La cuestión es más concreta: esa capa se llama monitorización. La gobernanza es la capa que decide.