Control de ejecución de agentes de IA: qué es y cómo implementarlo en runtime

Escribir una buena política no sirve de nada si nadie la hace cumplir en el momento en que un agente intenta actuar. Esta guía es la parte operativa del marco de gobernanza de agentes de IA: qué es el control de ejecución, cómo se arma un policy enforcement point (PEP) y cómo se implementa sin acoplarte a un solo proveedor.

Runtime policy enforcement: por qué el control no puede vivir en el prompt

Es tentador resolver el control de agentes con un system prompt: "no borres nada en producción", "pedí confirmación antes de enviar un correo". El problema no es la intención, es la naturaleza del mecanismo. Un prompt es una instrucción en lenguaje natural que compite con todo lo demás que el modelo procesa —incluido contenido externo que puede contener instrucciones inyectadas— y que el modelo puede ignorar por ambigüedad, por un error de razonamiento o porque una entrada maliciosa lo convenció de lo contrario. No hay forma de auditar "el modelo decidió no hacerlo" como control técnico, porque no es determinístico y no deja evidencia verificable de por qué se comportó como se comportó.

El execution control resuelve esto moviendo la decisión fuera del modelo: a un punto del camino de ejecución por el que toda acción tiene que pasar, sin excepción, antes de tocar un sistema real. Eso es runtime policy enforcement: evaluar la política en el momento en que la acción está por ocurrir, no antes (en el diseño del prompt) ni después (en un log que alguien revisa la semana siguiente). Los guardrails —filtros de contenido sobre entradas y salidas del modelo— siguen siendo útiles como primera capa, pero actúan sobre texto. El control de ejecución actúa sobre la acción misma: la llamada a la API, el comando, la transacción.

La prueba que separa un control real de una buena intención es simple: si mañana un agente intenta la acción prohibida, ¿algo la detiene técnicamente, o solo queda registrada para lamentarla después?

Anatomía de un policy enforcement point (PEP) para agentes

Un PEP es el componente de software que se interpone entre la decisión de un agente de hacer algo y la ejecución real de esa acción. En la práctica tiene cuatro responsabilidades:

• Interceptar. Toda acción candidata —una llamada a herramienta, una función invocada, un comando— pasa por el PEP antes de llegar al sistema destino. Si existe un camino que la bypasea (el agente con acceso directo al SDK de la nube, por ejemplo), el PEP no cumple su función por más sofisticado que sea.
• Resolver contexto. Qué identidad ejecuta la acción, qué capacidad concreta está invocando, con qué parámetros y sobre qué recurso. Sin este contexto no hay nada contra qué evaluar la política.
• Evaluar contra política. Consultar las reglas vigentes para esa identidad, esa capacidad y ese contexto, y producir una decisión. Esto se apoya en policy-as-code —reglas versionadas y testeables, no prosa— para que la evaluación sea determinística y auditable.
• Ejecutar la decisión y dejar evidencia. Permitir, bloquear o derivar a aprobación, y registrar el resultado en un audit trail con integridad verificable, atribuible a la identidad que intentó la acción.

Un detalle de diseño que se paga caro si se ignora: el fail mode. Si el PEP no puede evaluar una política —por una caída del motor de reglas, por ejemplo— el default tiene que ser denegar (fail-closed). Fail-open convierte cualquier incidente de infraestructura en una ventana sin control alguno.

La decisión: allow, deny o require-approval

El PEP no produce una respuesta binaria. Produce una de tres:

• Allow. La acción está dentro de política, dentro del permiso asignado a esa identidad, y su clase de riesgo no exige más fricción. Se ejecuta y se registra.
• Deny. La acción excede el permiso, viola una regla explícita o cae fuera de lo contemplado por la política (y el default es denegar lo no contemplado). Se bloquea y se registra el motivo.
• Require-approval. La acción está dentro de lo que ese agente podría hacer, pero su riesgo o su reversibilidad exigen que un humano con contexto la autorice antes de ejecutar. Queda en espera, con un timeout que —si nadie responde— resuelve en denegación, no en ejecución por omisión.

Esta tercera rama es el puente hacia el diseño de aprobación humana, que tratamos en detalle en human-in-the-loop para agentes de IA: cómo enrutar el pedido, con qué contexto y con qué SLA para que la aprobación sea real y no un trámite que nadie lee.

Acciones irreversibles: el caso que exige más fricción

No todas las acciones pesan igual, y la variable que mejor las ordena es la reversibilidad. Una lectura (consultar un log, listar recursos) no tiene costo de deshacer. Una acción reversible (crear un archivo, abrir un ticket, escalar una réplica) tiene costo de deshacer bajo. Una acción irreversible —borrar datos sin backup, enviar un correo a un cliente, ejecutar un pago, revocar un certificado en producción— no se puede deshacer, solo mitigar después del hecho.

El PEP tiene que tratar esa tercera categoría de forma distinta por diseño, no por buena voluntad del operador: exigir aprobación humana previa siempre, sin excepción de "esta vez tengo apuro", y registrar esa decisión con el mismo nivel de detalle que el resto de la cadena de evidencia. La clasificación por reversibilidad —no por gravedad subjetiva ni por tipo de recurso— es lo que permite automatizar con confianza el 90% del tráfico (lecturas y acciones reversibles) y concentrar la fricción exactamente donde importa.

El patrón adapter: la decisión primero, la implementación después

Un error común al construir un PEP es acoplar la lógica de decisión al proveedor de infraestructura: "si es AWS, hacé esto; si es GCP, esto otro". El resultado es un motor de políticas distinto por cada integración, imposible de auditar como un todo y carísimo de mantener cuando cambia un SDK.

El patrón que evita esto es el adapter: la decisión de política se toma en una capa agnóstica —identidad, capability abstracta, contexto, riesgo— y solo al final, una vez resuelto allow/deny/require-approval, un adaptador específico traduce esa decisión a la llamada concreta contra el proveedor real. Esto tiene dos beneficios que se notan con el tiempo: podés auditar una sola lógica de decisión independientemente de cuántos sistemas destino tengas, y podés agregar un proveedor nuevo escribiendo un adaptador, sin tocar ni reescribir la política existente. La decisión es el activo estable; la implementación contra cada API es el detalle que cambia.

Un ejemplo concreto: el pipeline de gates de NexusOS

Este marco no es solo teoría: es exactamente lo que ejecuta NexusOS en cada acción que un agente propone. El pipeline atraviesa diez gates en secuencia —identidad → capability → contrato → política → permisos → riesgo → aprobación → punto de enforcement (PEP) → ejecución → auditoría— antes de que cualquier acción toque un sistema real. Las acciones se modelan como governed capabilities agnósticas de proveedor (102 en el core), siguiendo el patrón adapter descripto arriba, y el resultado de cada gate queda en un audit trail append-only. Podés ver el pipeline evaluando acciones reales, incluida una denegación en vivo, en la demo interactiva.

El control de ejecución es una pieza del marco: define cómo se hace cumplir una política en el momento. Cómo se registra esa decisión para un auditor es la otra mitad del problema, cubierta en auditoría técnica de agentes de IA.

Preguntas frecuentes

¿Un PEP reemplaza a los guardrails?

No, los complementa. Los guardrails filtran contenido: revisan el prompt de entrada y la salida del modelo en busca de toxicidad, PII o intentos de jailbreak. Operan sobre texto, antes de que exista una acción. El PEP opera después: evalúa la acción concreta que el agente quiere ejecutar —esta llamada, a esta API, con estos parámetros— contra la política vigente. Un guardrail puede dejar pasar una instrucción inyectada que suena inocente; el PEP bloquea la acción resultante aunque el texto le haya parecido legítimo al filtro anterior. Un sistema maduro tiene las dos capas.

¿Dónde conviene ubicar el punto de enforcement?

En el camino de ejecución, no en el modelo. Concretamente: en la capa que intermedia entre el agente y el mundo real, ahí donde las herramientas o funciones que el agente puede invocar están expuestas. Si el agente llama directamente a un SDK de la nube o a una API interna sin pasar por ese intermediario, no hay PEP: hay una esperanza de que el modelo se comporte. El requisito técnico es que ninguna acción pueda alcanzar el sistema destino sin atravesar antes el punto de enforcement.

¿Qué pasa si el policy engine se cae?

Depende del fail mode que hayas configurado, y acá el default correcto es fail-closed: si el PEP no puede evaluar una política, la acción se deniega, no se permite por omisión. Fail-open —dejar pasar todo cuando el evaluador no responde— convierte una caída de infraestructura en una ventana sin ningún control, justo cuando menos visibilidad tenés. La disponibilidad del PEP mismo, entonces, es un requisito de seguridad, no solo de performance.

¿El patrón adapter agrega latencia relevante?

La evaluación de política en sí —resolver identidad, capability, contrato y reglas contra una acción— es una operación liviana, del orden de milisegundos, y no se nota frente a la latencia propia de la llamada al modelo o a la API de destino. Lo que sí agrega tiempo es la aprobación humana cuando la acción la requiere, pero eso es una decisión de diseño (a qué acciones les pedís aprobación), no un costo del PEP en sí.