Tiempo estimado de lectura: 16 minutos
Los agentes de IA empiezan a cambiar de categoría dentro de las empresas. Mientras los asistentes generativos reciben una solicitud y devuelven una respuesta, los agentes pueden acceder a sistemas, consultar datos, llamar herramientas y ejecutar acciones que antes dependían de personas o de flujos determinísticos.
Ese cambio amplía el potencial de la IA, pero también altera la arquitectura necesaria para operarla con seguridad. Cuando un agente deja de solo recomendar una acción y pasa a ejecutarla, ya no basta con controlar al usuario que inició el proceso. La organización necesita saber qué agente está actuando, en nombre de quién, con qué permisos, sobre qué sistemas y bajo qué límites.
Esta es una de las ideas centrales del concepto de Agentic Enterprise presentado por WSO2: las APIs, la integración, la identidad y la observabilidad siguen siendo fundamentales, pero necesitan extenderse para que los agentes operen como participantes identificables y gobernables de la arquitectura empresarial.
Para quien decide arquitectura e inversión en tecnología, la pregunta que define el proyecto viene antes de la adopción:
¿Qué controles necesitan existir antes de que esos agentes reciban autonomía para actuar?
Por qué los agentes de IA cambian la arquitectura empresarial
Las arquitecturas corporativas se construyeron durante décadas alrededor de dos categorías relativamente previsibles.
De un lado, personas autenticadas por sistemas de identidad. Del otro, aplicaciones y servicios ejecutando integraciones, APIs y procesos previamente definidos.
Figure 1: Non-agentic enterprise architecture em WSO2.com
Los agentes introducen una tercera categoría. En 2025, WSO2 estructuraba su visión de modernización en torno al concepto de Platformless Modernization. En 2026, esa arquitectura pasó a incorporar infraestructura específica para agentes, incluyendo identidad, ciclo de vida y gobernanza.
Son software, pero pueden recibir objetivos de personas, decidir qué herramientas utilizar durante la ejecución, trabajar en nombre de distintos usuarios y modificar su comportamiento según el contexto recibido.
Eso vuelve insuficiente tratar a un agente solo como una cuenta de servicio o reutilizar las credenciales de quien inició la tarea.
La arquitectura necesita poder distinguir:
- la identidad del usuario;
- la identidad del agente;
- la autoridad que fue delegada;
- el alcance de esa autorización;
- los recursos accedidos;
- los demás agentes y herramientas activados durante la ejecución;
- la secuencia de decisiones que llevó a la acción final.
En la arquitectura que WSO2 propone para la empresa agéntica, este problema aparece como una combinación de caminos controlados de entrada y salida, identidad y políticas, conectividad con herramientas, integración entre sistemas, observabilidad, evaluaciones y guardrails. El cambio importante está en crear nuevos puntos de control para workloads que ahora pueden decidir y actuar de forma autónoma, preservando la infraestructura que ya funciona.
Figure 2: WSO2 agentic fabric em WSO2.com
Identidad de agentes de IA: “¿quién eres, agente?”
Imagine un agente de atención de un banco autorizado a consultar la situación de un cliente y, en determinadas condiciones, solicitar un cambio en el registro.
Cuando esa llamada llega a la API, saber únicamente que existe un token válido resuelve muy poco.
El sistema necesita poder responder:
- ¿Qué agente hizo la solicitud?
- ¿En nombre de qué cliente o empleado?
- ¿Qué autoridad le fue delegada?
- ¿Esa autorización vale para consultar datos o también para modificarlos?
- ¿Por cuánto tiempo permanece válida?
- ¿Se activó otro agente durante el proceso?
Esta distinción importa porque identidad y autorización responden a problemas diferentes.
Reconocer al agente prueba quién está ejecutando la acción. La delegación establece de dónde vino la autoridad para ejecutarla. El alcance determina hasta dónde llega esa autoridad.
WSO2 pasó a tratar a los agentes como identidades de primera clase en su capa de identidad. Agent ID permite registrar, autenticar, autorizar y auditar agentes por separado, incluyendo escenarios en los que actúan de forma autónoma y situaciones en las que ejecutan tareas en nombre de un usuario.
Esa separación tiene una consecuencia importante para entornos regulados: la traza deja de registrar solo que determinada credencial accedió a un sistema y pasa a poder preservar la relación entre el agente que ejecutó la acción y la autoridad que la originó.
Delegar autoridad sin entregar la credencial del usuario
Uno de los riesgos de adaptar modelos tradicionales de autenticación a los agentes es hacer que operen usando credenciales prestadas o permisos excesivamente amplios.
En ese modelo, el sistema consigue reconocer la cuenta, pero pierde parte de la información necesaria para distinguir al ejecutor de la acción de quien la autorizó.
Los flujos de delegación On-Behalf-Of buscan resolver este problema manteniendo al agente identificado durante la ejecución y vinculando a él la autoridad concedida por el usuario. La documentación actual de WSO2 demuestra justamente los dos escenarios: agentes que operan con identidad propia y agentes que reciben autorización para actuar en nombre de otra identidad.
El principio es más relevante que la implementación específica.
En cualquier arquitectura con agentes, la organización debería poder demostrar:
Quién inició la delegación, qué agente recibió la autoridad, qué permisos fueron concedidos, qué recursos fueron accedidos y qué acción fue ejecutada.
Cuanto más larga sea la cadena entre humanos, agentes, subagentes y herramientas, más importante se vuelve preservar esa relación de punta a punta.
Agent Manager: gobernanza del ciclo de vida de los agentes
La identidad resuelve parte del problema. El ciclo operativo completo pide otra capa.
A medida que distintas áreas empiezan a desarrollar agentes con frameworks, modelos y runtimes diferentes, surge otra pregunta: ¿quién sabe cuántos agentes existen, dónde están corriendo y a qué recursos pueden acceder?
Esa es la capa que productos como WSO2 Agent Manager intentan abordar.
La plataforma funciona como un plano de control para registrar, ejecutar, observar, evaluar, proteger y gobernar agentes a lo largo de su ciclo de vida, incluso agentes construidos o ejecutados en diferentes frameworks y entornos.
En la práctica, esto agrega controles que empiezan a volverse necesarios cuando los experimentos aislados llegan a producción:
- inventario de los agentes existentes;
- ownership y gestión de ciclo de vida;
- identidad propia para cada agente;
- políticas de acceso;
- observabilidad de las interacciones con modelos y herramientas;
- evaluaciones continuas de comportamiento;
- guardrails;
- control de consumo y costo;
- revocación y retiro controlado de agentes.
La analogía con API Management ayuda, pero tiene un límite. Un API Manager gobierna principalmente la exposición y el consumo de interfaces. El agente agrega otra dimensión: él mismo necesita ser tratado como un componente gobernado, porque puede elegir qué interfaces utilizar y en qué secuencia.
Por eso, la discusión deja de ser solo “¿esta API está protegida?” y pasa a incluir “¿este agente debería tener permiso para llamarla en este contexto?”
Integración y MCP: sistemas expuestos como herramientas de agentes
El segundo cambio ocurre en la capa de integración.
Durante años, integrar significó conectar aplicaciones, datos, eventos y APIs dentro de flujos relativamente conocidos. Con agentes, esas mismas capacidades pasan a consumirse dinámicamente como herramientas.
El Model Context Protocol (MCP) surgió como uno de los estándares para crear una interfaz común entre agentes y recursos externos. En este modelo, los sistemas corporativos pueden exponer capacidades que un agente descubre y utiliza durante la ejecución de una tarea.
WSO2 Integrator combina actualmente este modelo con más de 600 conectores y soporte para MCP servers, permitiendo que los agentes participen en flujos junto con aplicaciones y servicios tradicionales.
El número de conectores es menos importante que el cambio arquitectónico detrás de él.
La integración deja de servir solo para mover datos entre sistemas y pasa también a definir qué capacidades de la empresa pueden ser consumidas por agentes.
Eso aumenta el valor estratégico de la capa de integración, pero también aumenta su responsabilidad.
Exponer una función interna como herramienta accesible por MCP involucra más que conectividad. La decisión cubre:
- contrato;
- identidad;
- autorización;
- contexto;
- clasificación de datos;
- límites de uso;
- observabilidad;
- consecuencias de la ejecución.
Un agente es tan útil como las acciones que consigue ejecutar. Por la misma razón, su riesgo crece a medida que aumenta su alcance.
Gobernanza de egress: el nuevo perímetro está en la salida
Gran parte de la seguridad empresarial tradicional se construyó para controlar quién entra a un sistema. Los agentes vuelven igualmente importante controlar hacia dónde pueden salir.
Durante una ejecución, un agente puede enviar contexto a un modelo externo, consultar una API, acceder a una base de datos, llamar a un MCP server o activar a otro agente.
Cada una de esas interacciones puede mover datos, transmitir instrucciones o provocar efectos fuera del sistema que inició el flujo.
Por eso, gobernar agentes exige observar el egress con el mismo rigor aplicado al ingress: qué agente está haciendo la llamada, hacia qué destino, en nombre de quién, con qué datos y bajo qué política.
La propia WSO2 viene tratando la gobernanza de egress como un componente de la arquitectura agéntica, defendiendo credenciales con alcance limitado, enforcement durante la llamada y preservación de la cadena de delegación en la auditoría.
Para sectores como servicios financieros y seguros, esta distinción es particularmente relevante. Una política aplicada después de la ejecución consigue explicar un incidente. Una política aplicada en el camino de la ejecución puede impedir que ocurra.
Guardrails para agentes de IA: de la respuesta del modelo a la acción
El mismo razonamiento vale para la gobernanza de IA.
Filtrar una respuesta inadecuada de un LLM es necesario, pero insuficiente cuando el modelo está conectado a herramientas capaces de producir efectos reales.
La capa de control necesita considerar también:
- exposición de información personal o confidencial;
- manipulación de prompts;
- acceso a herramientas;
- destinos autorizados;
- alcances de ejecución;
- consumo de modelos;
- volumen de llamadas;
- costos;
- acciones que exigen aprobación adicional.
En la WSO2Con 2026, WSO2 presentó un Policy Hub con más de 40 políticas y guardrails para tráfico de IA, incluyendo mecanismos relacionados con PII, seguridad de prompts y otras verificaciones aplicadas a las interacciones con modelos.
El valor de esta capa está en la capacidad de convertir reglas que antes dependían de cada aplicación en políticas aplicadas de forma consistente en el camino entre agentes, modelos y herramientas. El número absoluto de controles importa menos.
Qué cambia para una empresa que ya tiene APIs, IAM e integración
La adopción de agentes no significa necesariamente reconstruir la arquitectura empresarial.
Las instituciones que ya operan API Management, integración corporativa, IAM, observabilidad y controles de seguridad tienen una parte importante de la base necesaria.
La cuestión es verificar si esos componentes consiguen responder a las nuevas características del workload.
Por ejemplo:
- Identidad: ¿el agente tiene identidad propia o utiliza una cuenta genérica?
- Delegación: ¿es posible probar de dónde vino la autoridad utilizada en cada acción?
- Autorización: ¿los permisos son específicos para el agente, el usuario, el contexto y la herramienta?
- Integración: ¿las capacidades expuestas a agentes tienen contratos y controles adecuados?
- Egress: ¿las llamadas a modelos, APIs y herramientas externas pasan por enforcement?
- Observabilidad: ¿es posible reconstruir una ejecución que involucre modelo, agente, API, integración y sistema de registro?
- Gobernanza: ¿existe un inventario de los agentes en producción, un owner definido y un proceso para revocar accesos o retirar un agente?
Estas preguntas son más útiles que empezar la discusión eligiendo una nueva plataforma.
En algunos entornos, las capacidades existentes pueden extenderse. En otros, una capa específica de gestión e identidad para agentes reduce la cantidad de controles que tendrían que construirse internamente.
En el ecosistema WSO2, Agent Manager y Agent ID pasan a ocupar justamente esa función: uno controla el ciclo operativo y la gobernanza de los agentes; el otro trata su identidad, autenticación, autorización, delegación y auditoría. La documentación actual de WSO2 mantiene Agent ID también dentro de la Identity Platform, junto a Identity Server y Security Token Service.
ThunderID forma parte de esa evolución tecnológica, pero debe entenderse por separado. WSO2 lo presentó en 2026 como un nuevo runtime de IAM open source, desarrollado en Go y preparado para escenarios como identidad de agentes, identidad descentralizada y criptografía poscuántica. Eso no significa, sin embargo, que las organizaciones necesiten sustituir automáticamente el Identity Server para adoptar identidad de agentes.
La base de datos y operación que sostiene estos workloads a escala es el tema de Cómo escalar agentes de IA en la banca.
Qué decidir ahora antes de poner agentes en producción
Pocas organizaciones necesitan implantar de inmediato una arquitectura completa para miles de agentes.
Pero algunas decisiones se vuelven progresivamente más caras de corregir después de que los agentes llegan a producción.
- La primera es identidad. Los agentes no deberían nacer compartiendo cuentas técnicas genéricas si después la empresa necesitará atribuir acciones individualmente.
- La segunda es delegación. La autoridad transferida entre usuario, agente, subagente y herramienta necesita permanecer trazable.
- La tercera es alcance. Un agente debería recibir únicamente el acceso necesario para ejecutar la tarea. Heredar toda la capacidad de la persona o del sistema que lo inició amplía el riesgo sin necesidad.
- La cuarta es observabilidad. Los logs necesitan acompañar la ejecución de punta a punta, atravesando la frontera de cada API en el camino.
- La quinta es gobernanza de integración. Exponer APIs, sistemas y datos como herramientas disponibles para agentes amplía la superficie operativa y exige controles antes de la exposición.
- La sexta es egress. La empresa necesita saber qué datos e instrucciones están saliendo de su perímetro durante las llamadas que hacen los agentes.
La elección entre WSO2, hyperscalers u otras plataformas viene después de estas definiciones.
Una arquitectura duradera empieza determinando qué autonomía pretende conceder la organización y qué evidencias necesita mantener sobre cada decisión ejecutada. La pregunta sobre qué herramienta gestiona agentes viene en la secuencia.
Preguntas frecuentes
La gobernanza de APIs define contratos, autenticación, autorización, políticas de tráfico y condiciones de consumo de una interfaz. La gobernanza de agentes agrega controles sobre el actor que utiliza esas interfaces: identidad, ownership, delegación, herramientas autorizadas, comportamiento, ciclo de vida y trazabilidad de las acciones.
Las dos capas son complementarias. Los agentes bien gobernados todavía necesitan consumir APIs gobernadas.
No necesariamente. El punto de partida debe ser evaluar si la infraestructura actual consigue reconocer agentes por separado, emitir credenciales adecuadas, aplicar autorización granular, preservar la delegación y producir una traza de auditoría suficiente. La necesidad de extensión o sustitución depende de ese análisis.
En el ecosistema WSO2, por ejemplo, Agent ID aparece actualmente integrado a la propia Identity Platform y al Identity Server.
Las cuentas de servicio pueden autenticar una llamada, pero tienden a ser insuficientes cuando varios agentes, usuarios y cadenas de delegación comparten la misma identidad técnica. En ese escenario, probar exactamente qué agente ejecutó una acción y de dónde vino su autoridad se vuelve más difícil.
No. MCP estandariza la forma en que los agentes encuentran y utilizan herramientas, pero no elimina la necesidad de identidad, autorización, políticas, clasificación de los datos, observabilidad y gobernanza de las capacidades expuestas. Justamente porque MCP facilita el acceso a las herramientas, esos controles se vuelven más importantes
Por el caso de uso y por la decisión que el agente deberá ejecutar.
Antes de ampliar su autonomía, mapee quién autoriza la acción, qué sistemas serán accedidos, qué datos atraviesan el flujo, qué permisos son necesarios, qué acciones son reversibles y qué evidencias necesitan permanecer disponibles después de la ejecución.
Antes de escalar agentes de IA, pruebe quién está actuando
La utilidad de un agente crece con el número de sistemas a los que consigue acceder y con las acciones que consigue ejecutar. El riesgo crece por las mismas dos dimensiones.
Por eso, la discusión sobre Agentic Enterprise debería empezar por la capacidad de la arquitectura de identificar, limitar, observar e interrumpir a cada agente cuando deja de solo recomendar y pasa a actuar. La cantidad de agentes que la organización pretende construir viene después.
Para bancos y otras operaciones críticas, hay una pregunta aún más objetiva: si un agente ejecuta hoy una acción relevante sobre un cliente, un dato o un sistema, ¿la organización consigue probar qué agente actuó, en nombre de quién, con qué autorización y dentro de qué política?
Si esa cadena todavía no puede demostrarse de punta a punta, la próxima decisión es fortalecer la base que deberá sostener esa autonomía, antes de ampliarla.
Su desafío merece una conversación estratégica
La práctica de Integración y API de TreeID actúa justamente en esa capa de decisión: evaluando identidad, integraciones, APIs, observabilidad y controles existentes para determinar qué puede reaprovecharse, qué necesita evolucionar y qué componentes tienen sentido para poner agentes en producción sin que la autonomía se convierta en pérdida de control.