Gobernanza verificable para la IA agéntica: de principios que aconsejan a watchdogs que deniegan en runtime

La brecha de gobernanza en la IA agéntica es estructural, no filosófica. Casi toda la gobernanza de IA — principios, códigos éticos, model cards, marcos consultivos — describe cómo debería comportarse la IA. Nada de eso impide que la IA haga otra cosa cuando nadie mira. Para modelos predictivos sin efectos en el mundo real, esa brecha es tolerable. Para agentes que actúan mediante tool calls — enviar correos, ejecutar operaciones, modificar datos de producción, gastar dinero — no lo es.

El paper reciente Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Fradelos, enero de 2026) pone nombre a esta brecha sin rodeos: «muchos principios de gobernanza son consultivos, mientras que los agentes modernos actúan mediante tool calls con consecuencias en el mundo real». Y propone un patrón de ingeniería para cerrarla: un Watchdog en runtime que media los tool calls con semántica fail-close (denegar por defecto), gobernanza expresada como políticas como código (OPA/Rego) y un almacén de evidencia inmutable que impide que la IA alucine su propio cumplimiento.

Este es el patrón que llevaba tiempo esperando que alguien escribiera. Merece la pena entenderlo en detalle porque las decisiones no son obvias — y he operado suficientes guardrails en producción para saber que los modos de fallo de las alternativas más débiles son reales, no hipotéticos.

La idea central: fronteras de acción, no comportamiento medio

Tres enfoques de gobernanza dominan la práctica actual:

1. Guardrails en el prompt: añadir instrucciones de seguridad al system prompt.
2. Supervisión con modelo de recompensa: entrenar el modelo para que rechace ciertas acciones.
3. Supervisión de proceso: poner revisores humanos en los puntos de decisión.

Los tres mejoran el comportamiento medio. Ninguno, por sí solo, ofrece garantías en la frontera de acción para herramientas irreversibles.

De esta idea se deriva todo el resto del patrón. Un agente entrenado para «no exfiltrar datos de clientes» no exfiltrará datos de clientes en promedio. Puede hacerlo en condiciones adversariales, con distribuciones de prompts inusuales, en secuencias de tool calls que nadie anticipó, o simplemente porque el escenario concreto no estaba en la distribución de entrenamiento. Una mejora del promedio no es una garantía de seguridad para acciones irreversibles.

El patrón VGA parte de la postura contraria: no intentes que el agente sea fiablemente bueno. Haz que las acciones que puede ejecutar estén acotadas por algo que el agente no puede saltarse.

El Watchdog: una frontera que el agente no puede saltarse

El Watchdog es la capa de runtime que media cada tool call antes de que llegue a la herramienta. Toda acción que el agente quiere ejecutar pasa por él. Tiene tres propiedades que lo distinguen de las alternativas más laxas:

Fail-close (denegar por defecto)

Si el Watchdog no puede verificar positivamente que una acción está permitida, la deniega. Es justo lo contrario de la mayoría de los guardrails en producción, que son fail-open por defecto: si ninguna regla coincide, la acción sigue adelante.

Para la IA agéntica, fail-close no es negociable, precisamente porque el modo de fallo de fail-open es «el agente hizo algo que nadie autorizó porque la política no contemplaba el caso». Con fail-close, el modo de fallo es «el agente se detuvo y preguntó», que es recuperable.

Media la superficie de herramientas, no la del modelo

El Watchdog no se coloca entre el usuario y el modelo, sino entre el modelo y las herramientas. Esto importa porque el razonamiento del modelo, el contenido del prompt y las salidas intermedias entran en el ámbito de la moderación de contenido, pero no son la frontera de acción. La frontera de acción es el tool call. Situar el Watchdog en la superficie de herramientas garantiza que la política que se aplica es la que de verdad importa.

Autorización multiparte para acciones sensibles

Algunas acciones requieren más de un aprobador, y el Watchdog lo expresa con naturalidad: un tool call de «transferir más de 10.000 $» exige un paquete de verificación firmado por el agente y por un aprobador humano antes de ejecutarse. Un tool call de «modificar el esquema de la base de datos de producción» exige un pipeline de CI/CD que haya pasado las comprobaciones de seguridad de la migración. La arquitectura es la misma; la política varía según la sensibilidad.

La matriz MVV: vincular cada norma a un artefacto verificable

La segunda idea central es la matriz de Verificación Mínima Viable (MVV): vincula cada regla de gobernanza a un artefacto concreto y verificable, y a una cadencia concreta con la que ese artefacto debe producirse.

Sin MVV, las reglas de gobernanza se quedan en aspiraciones. «El sistema debe ser auditable» suena bien y no verifica nada. Con MVV, «el sistema debe ser auditable» se traduce en artefactos concretos:

• Un log inmutable de cada tool call con la decisión de política adjunta.
• Un paquete de evidencia firmado que liga intención → tool call → resultado.
• Un informe de atestación semanal a cargo de un auditor designado.
• Una revisión externa trimestral con escenarios de red team.

Cada artefacto tiene productor, formato y cadencia definidos. Verificar el cumplimiento se reduce a «¿se produjo el artefacto a tiempo, en el formato correcto y con firmas válidas?» — algo que un pipeline de CI/CD puede comprobar.

Esto es lo que significa «gobernanza como código» en la práctica. No son solo políticas en Rego: es la evidencia verificable de que las políticas se aplican, producida por el runtime, con un calendario, en formatos que un regulador podría auditar.

Por qué el almacén de evidencia tiene que ser inmutable

La decisión de diseño más sutil es el almacén de evidencia inmutable. El Watchdog deja constancia de cada decisión, y ese registro va a un almacén que el propio agente no puede modificar ni retrodatar.

La razón es lo que el paper llama alucinaciones de gobernanza: el modo de fallo en el que el agente produce un informe de cumplimiento de aspecto plausible que no se corresponde con lo que pasó de verdad. Si el almacén de evidencia es modificable por cualquier cosa al alcance del agente, este — de forma deliberada o como comportamiento emergente — puede generar evidencia de cumplimiento que no refleja las acciones ejecutadas.

La solución es estructural: el cumplimiento depende del almacén de evidencia, el almacén solo puede modificarlo el Watchdog, y el Watchdog está fuera de la superficie de herramientas del agente. Aunque el agente produzca un resumen de cumplimiento de aspecto impecable, la auditoría puede contrastarlo con el almacén inmutable y detectar la divergencia.

Es el mismo principio que separar la autoridad de escritura en base de datos del código de aplicación en cualquier sistema de producción serio. La novedad es aplicarlo a la evidencia de gobernanza de IA.

Derechos de decisión según la antigüedad

La cuarta idea es importante en lo operativo: los agentes tienen antigüedad. Un agente «junior» tiene acceso restringido a herramientas y necesita autorización multiparte para casi cualquier acción no trivial. Un agente «profesional» tiene un acceso más amplio. Un agente «senior» puede autorizar acciones de alcance más acotado en nombre de otros.

Suena a control de acceso corporativo porque lo es. La clave está en aplicarlo específicamente a agentes de IA, con el mismo rigor y la misma auditabilidad que el control de acceso por roles para humanos. En la práctica, esto significa:

• Los agentes nuevos empiezan como junior, con acceso restringido a herramientas. Solo ganan (o se les configura) un alcance mayor tras superar verificaciones concretas.
• La frontera es el acceso a herramientas, no «el entrenamiento del modelo» ni «el system prompt». Dos agentes sobre el mismo modelo pueden tener derechos de decisión muy distintos según sus políticas de acceso.
• Los ascensos son explícitos y auditados. Cuando un agente pasa de alcance profesional a senior, el cambio queda registrado, la evidencia se conserva y revertirlo es sencillo.

Esta es la parte que veo fallar todavía en la mayoría de los sistemas agénticos en producción en 2026: un único rol de agente con todas las herramientas, y la frontera es un system prompt. El patrón de antigüedad representa con más honestidad lo que de verdad hace falta.

El cumplimiento pasa a ser una propiedad de los artefactos

El patrón está diseñado explícitamente para encajar con las obligaciones de registro y robustez del EU AI Act. El almacén de evidencia cubre el registro. El Watchdog fail-close cubre la robustez. La matriz MVV cubre los requisitos de auditabilidad. La autorización multiparte cubre los requisitos de supervisión humana para sistemas de alto riesgo.

No es casualidad. La arquitectura está diseñada para que el cumplimiento sea una propiedad de los artefactos producidos, no una cuestión de «si el agente se portó bien». Es la única forma duradera de cumplir con regulaciones que exigen evidencia en lugar de confianza.

Qué significa esto si estás construyendo sistemas agénticos ahora

Acciones prácticas para cualquier equipo que ponga IA agéntica en producción en 2026:

1. Lleva la aplicación de políticas a la superficie de herramientas. Si tus guardrails viven en el system prompt, tienes gobernanza consultiva. Pon un mediador fail-close entre el modelo y las herramientas.

2. Adopta políticas como código. OPA/Rego es la opción más madura; la herramienta concreta importa menos que la disciplina. Las políticas en código se pueden revisar, versionar, probar en CI y auditar. Las políticas en prompts, no.

3. Construye el almacén de evidencia antes de escalar. Un log inmutable y firmado de las acciones del agente es mucho más difícil de añadir a posteriori que de diseñar desde el principio. Aunque todavía no necesites la auditoría, solo el valor que aporta para depurar en operación ya es enorme.

4. Aplica antigüedad a los agentes. Los agentes nuevos reciben un alcance estrecho. Ampliarlo es algo explícito, auditado y reversible. No ejecutes todos tus agentes con el mismo nivel de autorización.

5. Exige autorización multiparte en las acciones irreversibles. Todo lo financiero, todo lo que toque datos de clientes, todo lo que modifique producción. El coste en rendimiento de la autorización multiparte es mucho menor que el coste de una sola mala acción.

Lo que VGA no hace

Dos límites honestos que conviene nombrar.

No mejora el modelo. VGA acota lo que el agente puede hacer; no cambia lo bien que razona dentro de esos límites. Mejorar el comportamiento del modelo sigue siendo importante — pero ahora es un problema de optimización dentro de límites de seguridad conocidos, no el mecanismo de seguridad en sí.

Cuesta latencia. Cada tool call pasa por una evaluación de política. Con bundles de OPA bien ajustados son milisegundos, pero no es cero. En las rutas sensibles a la latencia tendrás que hacer ingeniería fina — normalmente con decisiones cacheadas para las rutas calientes y evaluación por petición para las sensibles.

El coste es real. El coste de no tenerlo es mucho mayor, y se manifiesta en forma de titulares.

El paso de la gobernanza consultiva a la verificable en IA agéntica ya está en marcha. El patrón está sobre la mesa; adoptarlo es hoy una decisión de ingeniería, no un proyecto de investigación.

---

Fuente: Fradelos, G. Verifiable Governance Architecture (VGA) for Organisations and Teams with Human and AI Employees (Ginebra, 9 de enero de 2026). SSRN 6306840.

¿Estás construyendo sistemas agénticos y necesitas capacidad de ingeniería que ya trabaja con políticas como código, watchdogs fail-close y almacenes de evidencia inmutables? Habla con un CTO sobre desplegar un squad nearshore con la disciplina que exige la gobernanza verificable de IA.