Gobernanza de Agentes de IA en Múltiples Plataformas

La mayoría de las empresas no decidieron adoptar agentes de IA en cinco plataformas. Simplemente les sucedió. Microsoft Copilot llegó con la suite de productividad. ServiceNow implementó Now Assist en la cola de tickets. Salesforce activó Agentforce dentro del CRM. Otras plataformas de datos y SaaS comenzaron a ejecutar agentes junto a los sistemas de registro. Cada plataforma trajo su propio entorno de ejecución de IA — y, discretamente, su propia historia de gobernanza que se detiene en el límite de la plataforma.

El resultado es una brecha de gobernanza que es difícil de cerrar para cualquier proveedor de plataforma de aplicaciones por sí solo. Cuando un agente dentro de una plataforma llama a una API, ¿quién lo autorizó? Cuando un agente en otra plataforma resume un documento sensible, ¿qué política rigió la respuesta? Y cuando un agente se comporta mal en producción, ¿quién puede contenerlo rápidamente — sin coordinar a través de múltiples consolas de proveedores o colas de soporte?

Esto no es un riesgo a futuro. Es la realidad operativa para cualquier organización que haya adoptado más de una plataforma de IA de forma independiente — lo cual es cada vez más común en grandes empresas.

La naturaleza del problema

Antes de hablar de una solución, vale la pena ser precisos sobre por qué esto es realmente difícil. La dificultad es estructural y se manifiesta en cuatro puntos a la vez.

Y hay un quinto problema que solo se hace visible en el momento en que un usuario intenta realmente hacer algo con un agente de terceros: el impuesto de credenciales.

El impuesto oculto de credenciales

Considere una solicitud rutinaria enviada a un agente oficial de terceros instalado dentro de un asistente tipo Copilot. La primera vez que un usuario lo utiliza, el agente no puede responder hasta que el usuario inicie sesión directamente en ese servicio de terceros.

Esto no es un error. Es la única arquitectura segura cuando cada agente es un producto vendido por separado. Pero apilado en todo el inventario de herramientas de una empresa, tiene consecuencias operativas reales:

• Fricción por usuario, por herramienta. Cada empleado vuelve a autorizar cada agente la primera vez que lo utiliza. Multiplique por la fuerza laboral, luego por el inventario de herramientas.
• Proliferación de tokens. Los tokens OAuth para cada servicio conectado terminan dispersos en los almacenes de identidad de los usuarios. El cumplimiento se convierte en una cuestión por proveedor en lugar de una única pista de auditoría.
• Sin revocación centralizada. Cuando un contrato cambia o un incidente requiere cortar el acceso, la organización lo persigue a través de cada relación con el proveedor en lugar de en un único punto de estrangulamiento.

Cómo puede funcionar un plano de control multiplataforma

Un patrón arquitectónico que aborda directamente esta brecha es gobernar en la capa que todas estas plataformas tienen en común. Cada agente, independientemente de la plataforma que lo aloje, eventualmente realiza una llamada a un LLM o una llamada a una herramienta. Interceptar y gobernar allí, y gobernarás la actividad del agente que se enruta a través de esa capa de ejecución compartida, sin pedir a cada plataforma de aplicación que se reconstruya.

Esta es la premisa detrás del Agent Gateway de TrueFoundry: una capa de control dedicada para agentes de IA en producción, situada delante de los modelos y herramientas de los que depende cada agente. TrueFoundry traza una línea clara entre un gateway de IA, que gestiona prompts y tokens sin estado, y un agent gateway, que es el plano de datos para la IA agéntica: sesiones con estado, ejecución multi-paso y los datos que se mueven entre los agentes y sus herramientas. Se comporta como una malla de servicios construida específicamente para sistemas agénticos.

Por encima de los gateways se encuentra una cuarta capa: el Agent Harness. Un harness es el entorno de ejecución alrededor de un LLM: el bucle de orquestación que planifica, llama a herramientas, gestiona el contexto, controla acciones sensibles mediante aprobaciones y registra cada paso en un rastro. Es lo que convierte una llamada a un modelo en un agente fiable y de larga duración.

TrueFoundry lo ofrece como un servicio gestionado en lugar de un framework. Un entorno de ejecución en sandbox ejecuta código y tareas de larga duración. Las puertas de aprobación con intervención humana pausan las llamadas a herramientas sensibles hasta que un usuario las aprueba. Un Registro de Habilidades versionado contiene instrucciones reutilizables con RBAC. Y, lo que es crucial, ninguna clave API o credencial reside nunca en las definiciones de los agentes; residen en los gateways, donde los equipos de plataforma configuran el acceso una vez y los constructores de agentes nunca tocan los secretos.

Fundamentalmente, el descubrimiento no se limita a los agentes que construiste en la plataforma. Los agentes que se ejecutan en otros lugares —en Bedrock, LangGraph, un servicio HTTP personalizado o la plataforma de otro proveedor— se registran en el mismo inventario que los agentes remotos, con los mismos metadatos y los mismos controles. La flota fragmentada se convierte en un único mapa.

04Cinco capacidades que vale la pena buscar

Para los equipos que evalúan cómo cerrar esta brecha, las siguientes cinco capacidades merecen un examen detenido, con una nota sobre lo que cada una tiende a requerir internamente.

‍