Agentes de IA gobernados: un modelo de política, varios puntos de aplicación en tiempo de ejecución.
Cómo controlar los costos, la elección del modelo, los datos, las herramientas y las llamadas MCP en tiempo de ejecución: un marco de gobernanza, un esquema de política neutral, soluciones alternativas, límites de seguridad y seguimiento.
Fuentes: Building Governed AI Agents: How to Control Cost, Data, Tools and Actions at Runtime
Un agente de soporte recibe una solicitud de reembolso. El mensaje incluye un número de cuenta y un número de teléfono. Para gestionarla, el agente necesita un modelo de lenguaje para leer la solicitud, una herramienta interna para buscar el pedido, un CRM al que se accede a través de MCP para agregar una nota, y posiblemente otro agente para revisar un reembolso excepcionalmente alto. Nada de eso es ya algo exótico. Lo difícil es que cada paso en esa cadena cruza un límite de política diferente, y cada cruce plantea su propia pregunta.
- ¿Está permitido que estos datos del cliente lleguen al proveedor de modelos seleccionado?
- ¿La solicitud sigue estando dentro de su presupuesto de gastos?
- ¿Puede esta carga de trabajo utilizar ese modelo en esta región?
- ¿Debería el servidor del CRM recibir toda la conversación?
- ¿Puede la herramienta de reembolsos pagar 2,000 dólares sin que lo apruebe un humano?
En principio, un documento de política puede responder a este tipo de preguntas, y un prompt del sistema puede recordarle al agente algunos puntos clave. Sin embargo, ninguno de ellos aplica las reglas de manera consistente. Por eso, la gobernanza de los agentes se convierte en un problema durante su ejecución.
Un marco publicado para agentes gobernados describe bien este cambio: la gobernanza establece las reglas, y una pasarela es uno de los lugares donde esas reglas se aplican al tráfico en tiempo real. Organiza el trabajo en cinco actividades: Gobernar, Decidir, Proteger, Observar y Asegurar. Un punto útil dentro de este marco es que las llamadas a modelos, las llamadas a herramientas, las llamadas MCP y los intercambios entre agentes conllevan riesgos diferentes. Dicha distinción permite un diseño mejor que intentar incluir todos los controles en un único prompt o una única pasarela enorme.
Deje que la política viaje junto con la solicitud
La imagen más simple es un sobre de gobernanza que acompaña a una interacción a través del sistema. Contiene suficiente contexto como para tomar una decisión antes de cruzar un límite:
- identidad e inquilino,
- carga de trabajo y agente,
- nivel de riesgo y clasificación de datos,
- gasto actual y límites,
- proveedores y regiones permitidos,
- Herramientas permitidas y alcances de acción,
- Límites que requieren aprobación humana,
- versión de la política, además de un ID de seguimiento o decisión.
No todos los componentes necesitan cada campo. El sobre existe para que se puedan responder de manera consistente los mismos tipos de preguntas dondequiera que vaya el agente.
- Para una llamada a un modelo, los datos relevantes son el gasto, el proveedor, la región, la retención y la redacción.
- Para una herramienta de reembolso, son la identidad del usuario, la titularidad del pedido, el monto y el nivel de aprobación.
Por lo tanto, el diseño no consiste en un filtro universal, sino en un único modelo de política con varios puntos de aplicación. La gobernanza en tiempo de ejecución se vuelve concreta en esta etapa, ya que la pregunta relevante no es si existe una política, sino qué componente puede detener la interacción antes de que surjan efectos secundarios.
Un esquema sencillo e independiente del proveedor
No se necesita ninguna plataforma de gobernanza para observar este patrón. El código en Python que se muestra a continuación es deliberadamente neutral y no está vinculado a ninguna API de producto. Su función es exponer los puntos de decisión.
from dataclasses import dataclass
from enum import Enum
class Decision(str, Enum):
ALLOW = "allow"
BLOCK = "block"
APPROVAL = "approval"
FALLBACK = "fallback"
@dataclass(frozen=True)
class PolicyContext:
user_id: str
workload: str
risk_tier: str
data_class: str
spend_usd: float
spend_limit_usd: float
policy_version: str
def before_model_call(ctx: PolicyContext, model: str) -> Decision:
if ctx.spend_usd >= ctx.spend_limit_usd:
return Decision.BLOCK
if ctx.data_class == "restricted" and model not in APPROVED_PRIVATE_MODELS:
return Decision.FALLBACK
return Decision.ALLOW
def before_tool_call(
ctx: PolicyContext,
tool: str,
amount: float = 0,
) -> Decision:
if tool not in TOOL_SCOPES[ctx.workload]:
return Decision.BLOCK
if tool == "issue_refund" and amount > 500:
return Decision.APPROVAL
return Decision.ALLOW
def before_mcp_call(
ctx: PolicyContext,
server: str,
) -> Decision:
if server not in APPROVED_MCP_SERVERS:
return Decision.BLOCK
if ctx.data_class == "restricted" and server in EXTERNAL_SERVERS:
return Decision.BLOCK
return Decision.ALLOW
La sintaxis tiene menos importancia que la lista de cosas que el modelo nunca está autorizado a aceptar. Puede razonar sobre lo que desea el cliente, pero no puede determinar que un reembolso de 2,000 dólares sea conforme a la política en este momento, ni que un servidor MCP no aprobado esté bien solo porque la solicitud parece inocente. Esos resultados son cambios de estado deterministas que corresponden al entorno de ejecución.
Una versión en producción también debe generar evidencia para cada decisión: la versión de la política, el alcance de las entradas, el resultado, la razón, el agente responsable, la marca de tiempo y el ID de seguimiento. Esa evidencia es lo que más tarde demuestra qué política se ejecutó realmente, en lugar de simplemente indicar que existía un documento de política.
Una pasarela de modelos ayuda, pero no constituye todo el diseño
Dentro de ese marco, una pasarela LLM funciona como una capa compartida para la autenticación, la selección de modelos, el recorte del contexto, las políticas de gasto, el manejo de fallos y la evidencia para tomar decisiones. Un producto actual de un proveedor de herramientas para agentes lo hace tangible: entró en beta pública en agosto de 2026 y ofrece límites de gasto y de velocidad, alternativas de modelos, enrutamiento de proveedores, protección para datos sensibles e integración de seguimiento. Se pretende que su adopción por parte de clientes con modelos comunes sea sencilla: basta con dirigir la base_url del cliente hacia la pasarela, almacenar las claves de los proveedores de forma centralizada y definir las políticas en un único lugar.
Eso es importante porque, de lo contrario, la gobernanza de los modelos tendría que copiarse en cada agente.
agent A → custom rate logic → OpenAI
agent B → custom PII logic → Anthropic
agent C → custom fallback → Gemini
agent D → no controls → self-hosted model
Una pasarela puede fusionar la pila en una sola capa compartida.
agents
↓
shared model-call policy
↓
approved providers / hosts
No caigas en una generalización excesiva aquí. El marco de gobernanza es más amplio que cualquier producto de gateway en particular. Aborda explícitamente las llamadas a herramientas, las llamadas MCP y las interacciones entre agentes, ya que el mayor riesgo para un agente suele ser la acción que puede llevar a cabo y no el texto que genera. Los controles de versión beta pública del gateway se refieren principalmente al tráfico del modelo. Sigue siendo necesario un mecanismo de cumplimiento adicional en el entorno del agente, en el tiempo de ejecución de la herramienta, en los límites de MCP o en un gateway de acciones dedicado. Esta separación es saludable, ya que un gateway de modelo no debería fingir que puede autorizar cambios en una base de datos de producción que nunca ve.
La fiabilidad también forma parte de la gobernanza
Cuando un gateway se encuentra en el camino crítico, la gobernanza puede causar sus propias interrupciones si el comportamiento ante fallos es vago. Dos ideas ayudan a resolver esto.
En primer lugar, cada carga de trabajo necesita una postura explícita de funcionamiento en caso de fallo: ya sea continuar operando o detenerse. Una solicitud de resumen de bajo riesgo que no pueda llegar al servicio de políticas podría detenerse de manera ordenada. Una solicitud que requiere datos restringidos y no pueda demostrar que se aplicaron las políticas de censura o residencia podría no permitirse continuar operando en caso de fallo.
En segundo lugar, el modelo de respaldo debe ser equivalente desde el punto de vista de las políticas y no simplemente estar disponible. Supongamos que el modelo principal fue aprobado porque almacena los datos en una región requerida según una política de retención acordada. Un cambio automático a un proveedor más económico o mejor disponible que viole dichos términos no aumenta la resiliencia; más bien, intercambia una violación de las normativas por la apariencia de seguir funcionando.
Los controles de gastos siguen la misma lógica. Los límites máximos son útiles, pero un límite sin alertas ni vías de escalada convierte la gobernanza en una interrupción arbitraria del servicio. Un diseño mejor consiste en establecer una secuencia clara de acciones.
usage approaches threshold
↓
alert
↓
route / reduce context / downgrade model if allowed
↓
hard block when policy requires it
↓
auditable exception path if business-approved
Por esta razón, la enrutación de modelos está más relacionada con la gestión de carteras que con el envío de solicitudes simples a un modelo económico. El costo es importante, al igual que la latencia, el manejo de datos, la calidad, el nivel de riesgo y la disponibilidad.
El costo de un plano de control central
Al concentrar las políticas en un único lugar, se evita que cada agente lleve su propia copia, pero también se concentra la responsabilidad en ese lugar. La capa de ejecución ahora se interpone en el tráfico de modelos y, en algunos diseños, ayuda a autorizar acciones, por lo que debe diseñarse como cualquier otro servicio crítico.
- Las verificaciones de políticas deben realizarse lo suficientemente rápido como para no afectar negativamente la latencia de las solicitudes, y el servicio de políticas necesita tener redundancia propia.
- Los datos de precios de cada proveedor deben estar actualizados y almacenados en caché; además, los tokens de procesamiento por lotes y de razonamiento deben contabilizarse con precisión para que los límites de gasto sean fiables.
Otro costo es de tipo organizacional. Un equipo centralizado en plataformas puede establecer valores por defecto seguros sin esfuerzo, pero un control excesivamente amplio puede ralentizar a los equipos de producto. Un enfoque que vaya desde la visibilidad, pasando por el control, hasta la garantía, suaviza esta situación: primero observar, ejecutar la nueva política en modo de advertencia o sombra, medir lo que ocurre y bloquearla por completo solo cuando el riesgo lo justifique. Esta capa debería eliminar el trabajo repetitivo sin convertirse en una dependencia opaca que nadie pueda sortear, depurar o modificar de forma segura.
Las medidas de control no deben asumir acciones con consecuencias graves
Existen dos tipos de medidas de protección. Las reglas basadas en patrones son adecuadas para secretos e identificadores estructurados. Los detectores basados en modelos se encargan de categorías más complejas como los datos personales no estructurados, los intentos de evasión o las situaciones de falta de fiabilidad. Ninguno de ellos es perfecto, y las verificaciones basadas en modelos son probabilísticas, por lo que pueden generar tanto falsos positivos como falsos negativos.
Una regla de producción sólida establece lo siguiente: la detección de contenido puede reducir el riesgo, pero nunca debe ser el único control entre un agente y un efecto secundario grave.
- Un límite de reembolso es mejor definirlo mediante código que mediante un clasificador.
- La implementación de una producción debe incluir una verificación de autorización.
- Una acción de alto riesgo puede requerir aprobación humana.
- Las credenciales deben tener un alcance definido de modo que un agente no pueda exceder lo necesario para su tarea, incluso si una medida de protección falla en detectar algo.
El marco establece los límites de la misma manera: las acciones con consecuencias dependen de límites deterministas o de la aprobación humana, y no únicamente de la detección de contenido. Se trata de la brecha entre identificar intenciones inseguras y contener capacidades peligrosas. La guía de OWASP sobre un grado excesivo de autonomía llega a la misma conclusión por separado, recomendando una funcionalidad y permisos mínimos en las herramientas, con la autorización implementada en los sistemas posteriores y no dejada al juicio del propio modelo. Ambos niveles son necesarios.
Observación y garantía
El rastreo se vuelve mucho más útil una vez que las decisiones de política forman parte del rastro.
- Una solicitud de modelo bloqueada muestra qué política de gasto se activó.
- Un evento de censura indica qué versión de la política se aplicó sin revelar el valor sensible.
- La aprobación de una herramienta está vinculada a la acción que controló.
Las evaluaciones pueden preguntar más allá de si el modelo es preciso. Pueden comprobar si un modelo más pequeño mantiene la calidad tras un cambio en la ruta, si reducir el contexto disminuye los costos sin afectar los resultados, si una política de censura genera demasiados falsos positivos, y si un nuevo registro de respaldo sigue siendo equivalente a la política original.
Juntos, estos elementos completan el ciclo de cinco partes. Govern establece la propiedad, los riesgos y las políticas; Decide gestiona las rutas, realiza escaladas y procede a la recuperación ante fallos; Protect aplica las medidas en cada límite; Observe mide el comportamiento y los resultados de las políticas; Assure preserva la trayectoria histórica y prueba los cambios. Implementar una regla no concluye el trabajo. El trabajo se considera finalizado cuando se puede demostrar qué regla se ejecutó, cuál fue su decisión, qué ocurrió a continuación, y si el control sigue funcionando tras los cambios en el sistema.
Qué significa esto para la arquitectura de los agentes
Lo que necesitan los agentes en producción es una arquitectura de control en tiempo de ejecución, independientemente del gateway elegido. Un gateway de modelo centralizado es un lugar adecuado para gestionar los costos, la elección de proveedores, la redacción de datos, los límites de velocidad y las soluciones alternativas, además de permitir la opción de utilizar diferentes modelos sin afectar cada aplicación. Un agente regulado sigue necesitando las capas circundantes:
- autorización y límites fijos para las acciones de las herramientas,
- decisiones de confianza respecto a los servidores MCP junto con reglas sobre qué datos pueden ser transferidos,
- contexto minimizado e identidad verificada entre los agentes que colaboran,
- aprobación o contención para cualquier acción con consecuencias graves,
- un historial trazable de las políticas detrás de cada decisión.
En cuanto a la solicitud de reembolso, el modelo sigue pudiendo razonar y el agente sigue pudiendo actuar. La arquitectura simplemente deja de pedirle al modelo que incluya todo el programa de gobernanza en su prompt. Cada límite importante recibe respuesta a su pregunta antes de ser cruzado:
- ¿Quién está haciendo la solicitud?
- ¿Qué datos se están transfiriendo y a dónde?
- ¿Cuál es la cantidad de trabajo permitida?
- ¿Qué modelos y herramientas están autorizados?
- ¿Cuál es el plan si el camino preferido falla?
- ¿Se necesita la aprobación de un humano?
- ¿Qué versión de la política emitió la orden?
Eso es lo que diferencia tener políticas de IA de tener agentes gobernados.
Lecturas relacionadas
- WebMCP, MCP a nivel de servicio o uso habitual en el navegador: dónde encajan las herramientas de agente — Un análisis crítico de WebMCP: herramientas de página frente a MCP a nivel de servicio y agentes de navegador comunes, abordando sesiones, OAuth CIMD, descubrimiento, estado local y propiedad.
- Una plataforma mínima viable para el experimento con agentes de IA: pruebas A/B y ejecuciones en sombra — Cómo decidir si la versión B del agente debe reemplazar a la A, utilizando definiciones de pipelines, asignación local, eventos de exposición, trazas, evaluación en entorno aislado, ejecuciones en sombra y medidas de control.