Idea en 30 segundos
Agent governance es una capa de control sobre el runtime que verifica cada paso del agente: acceso a herramientas, límites, presupuestos y decisiones de policy antes de ejecutar acciones.
Cuándo se necesita: cuando el agente tiene acceso a tools, APIs, o ejecuta acciones reales en producción.
Problema
Sin governance, un agente en producción suele parecer "casi normal" hasta que ocurre un fallo. Puede llamar tools muchas veces, gastar presupuesto sin progreso y ejecutar acciones que nadie autorizó explícitamente.
Lo peor es que no se ve de inmediato: por fuera el run "sigue", pero por dentro ya crecen riesgos, costos y ruido en logs. Sin governance, el agente es un ciclo sin control con acceso a tools.
Analogía: es como un autopiloto de coche sin límite de velocidad, frenos ni registro de eventos. Mientras la carretera es recta, todo parece bien. Cuando algo sale mal, parar y entender se vuelve mucho más difícil.
Por eso se necesita governance: para que el sistema tenga límites antes del incidente, no después.
Solución
La solución es añadir al runtime una policy layer separada que toma una decisión técnica antes de cada acción.
La policy layer devuelve una de tres decisiones: allow, deny o approval_required.
Es un nivel separado del sistema, no una parte del prompt ni de la lógica del modelo.
Como en RBAC, estas verificaciones se ejecutan antes de cada acción del agente.
Governance es lo que está entre el agente y las acciones reales. En otras palabras, es el control plane para agentes de IA.
👉 Governance no obliga al agente a comportarse bien, limita lo que el agente puede hacer en absoluto.
Se implementa como middleware / policy layer (por ejemplo en LangGraph o en un tool gateway custom). En este artículo, la policy layer (tool gateway) es el componente que verifica y controla todas las tool calls.
Governance != Safety
Son dos niveles de control diferentes:
- Safety: si el agente propone la decisión correcta.
- Governance: si al agente se le permite ejecutar esa acción en runtime.
Si safety se equivoca, governance igual limita el daño en nivel runtime.
Ejemplo
Un agente de soporte sin governance puede, por alucinación, llamar la API de reembolso decenas de veces.
Con governance:
max_tool_calls = 3max_usd = 100→ el agente se detiene al llegar al límite, no después de perder dinero.
Governance detiene el incidente a nivel de ejecución y no depende de que el modelo se comporte correctamente.
Niveles de control (governance layers)
Estos niveles trabajan juntos en cada paso del agente.
| Nivel | Qué controla | Mecánicas clave | Para qué sirve |
|---|---|---|---|
| Access control | Acceso a acciones y tools | RBAC allowlist / denylist | Se verifica antes de cada tool call y bloquea acciones no permitidas |
| Execution control | Flujo de ejecución del run | max_steps rate limiting límites de tool calls | Detiene loops y tool spam |
| Cost control | Gasto | max_tokens max_tool_calls max_usd | Limita presupuesto y gasto runaway |
| Human control | Intervención humana | human approval kill switch | Permite confirmar o detener en emergencia |
| Observability | Visibilidad de eventos | audit logs traces métricas alerts (Slack / PagerDuty) | Permite detectar e investigar incidentes rápidamente |
| Lifecycle control | Actualizaciones del agente | versioning rollback | Permite releases seguros y rollback rápido |
Ejemplo de alerta:
Slack alert: 🛑 Agent Support-Bot hit max_usd limit ($100). Run stopped at step 12.
En producción, normalmente esto se ve como un dashboard con métricas: runs, tool calls, cost, errors.
Cómo se ve en la arquitectura
Agent governance se integra entre el runtime del agente y el mundo externo:
Ninguna tool call se ejecuta sin pasar por la policy layer.
La policy layer (tool gateway) actúa como gateway / middleware entre runtime y tools.
Cada llamada a herramienta pasa por:
- Policy layer -> verificación de acceso y límites
- Execution -> ejecutar solo si allow
- Logs -> registro en audit / trace
Stack mínimo de governance
- allowlist (default deny) — limita acceso a tools
- max_steps — detiene loops
- presupuestos — limitan gasto
- retry policy — evita caos de retries
- audit logs — permiten análisis de incidentes
- stop reasons — explican por qué el agente se detuvo
- kill switch — permite detener en emergencia durante incidente
Ese es el mínimo sin el cual un agente no es un sistema de producción.
Ejemplo
El agente llama un tool:
- se verifica allowlist
- se verifica RBAC
- se verifica presupuesto
- se verifica approval
→ solo entonces se ejecuta la acción.
Flow policy mínimo:
if not policy.allow(tool, args):
return deny("tool_not_allowed")
if not limits.steps_ok():
return stop("max_steps_exceeded")
if not budget.ok():
return stop("budget_exceeded")
result = tool.execute(args)
audit.log(tool, args, result)
return result
Errores típicos
- depender solo del prompt en lugar de control runtime
- no tener policy layer centralizada
- no tener allowlist con default deny
- no tener presupuestos y límites
- lógica de retry dispersa en varias capas
- falta de audit logs
- no tener forma de detener al agente
Como resultado, el sistema parece controlado, pero no lo está.
Autoevaluación
Revisión rápida antes de lanzar en producción:
Progreso: 0/8
⚠ Faltan controles base de governance
Antes de production necesitas como mínimo control de acceso, límites, audit logs y parada de emergencia.
FAQ
Q: ¿Por qué governance no puede reemplazarse con un único system prompt?
A: El prompt describe el comportamiento deseado. Governance impone límites reales sobre acciones en runtime.
Q: ¿Cuál es el mínimo de governance antes de producción?
A: Mínimo: allowlist con default deny, límites (max_steps, presupuestos), stop reason, audit logs y kill switch. Sin esto, el agente sigue sin control bajo carga.
Q: ¿Qué implementar primero: approval o presupuestos?
A: Primero límites runtime y presupuestos para limitar el riesgo base en cada run desde el inicio. Luego añade approval para acciones riesgosas e irreversibles (operaciones write, cambios financieros, borrado de datos).
Q: ¿Kill switch es suficiente para seguridad?
A: No. Kill switch es un freno de emergencia, pero no reemplaza control continuo de acceso, presupuestos, rate limits y auditoría de acciones.
Q: ¿Cómo se implementa técnicamente kill switch?
A: Normalmente como un flag global simple (por ejemplo en Redis) que policy layer revisa antes de cada paso para detener la ejecución.
Páginas relacionadas
Siguiente en este tema:
- Access Control (RBAC) — cómo limitar lo que el agente puede hacer.
- Budget Controls — cómo contener gasto de tokens, tool calls y $.
- Rate limiting para agentes — cómo protegerse de tool spam y picos de carga.
- Human approval — dónde se requiere confirmación humana para acciones críticas.
- Audit logs para agentes — cómo reconstruir la cadena de eventos e investigar incidentes.