Imagina una organización global en la que varios agentes de IA ya pueden consultar contratos, lanzar flujos de integración, actualizar pedidos o actuar sobre un ERP.
El problema aparece cuando IT descubre que no puede responder con precisión a preguntas básicas:
- qué agente ejecutó una acción,
- en nombre de quién,
- con qué permisos,
- bajo qué política,
- y cuál fue el resultado real en el sistema destino.
No es una preocupación marginal. El 82% de las organizaciones declara tener agentes desconocidos en su infraestructura y solo el 21% tiene un proceso formal de retirada (Cloud Security Alliance, enero de 2026). Para Gartner, el 74% de los responsables de aplicaciones considera los agentes de IA un nuevo vector de ataque (mayo-junio de 2025).
La Agentic Enterprise Architecture o arquitectura empresarial agéntica aborda precisamente ese problema, cómo integrar agentes capaces de tomar decisiones y ejecutar acciones dentro de la arquitectura corporativa sin renunciar a identidad, autorización, trazabilidad y control.
El elemento central es un Agent Control Plane, una capa de gobierno situada entre la decisión del agente y la ejecución sobre APIs, aplicaciones y sistemas core.
¿Qué cambia con la Agentic Enterprise Architecture?
El cambio fundamental es que la integración deja de estar gobernada únicamente por flujos predeterminados.
En una arquitectura tradicional, una aplicación llama a una API porque un desarrollador ha definido previamente qué operación ejecutar, contra qué sistema y con qué condiciones.
Un agente puede decidir en tiempo de ejecución:
- qué herramienta necesita,
- qué API o sistema consultar,
- qué información utilizar,
- qué secuencia de acciones realizar,
- si delega parte de la tarea en otro agente.
Eso introduce una diferencia arquitectónica importante, el sistema que decide qué hacer y el sistema que autoriza y ejecuta la acción ya no deberían ser el mismo.
Forrester describe el Agent Control Plane como un tercer plano funcional junto al plano de construcción y el de orquestación, precisamente porque el gobierno necesita operar fuera de ambos.
A marzo de 2026 Leslie Joseph, Principal Analyst de Forrester, señalaba además que la arquitectura avanza más rápido que los estándares necesarios para implementarla de forma completamente portable entre fabricantes.
Un framework de cinco capas para gobernar agentes autónomos
Para que una AI Control Tower sea efectiva no debe ser solo una consola que recopila información, sino un Agent Control Plane basado en un conjunto de cinco capacidades arquitectónicas.
| Capa | Qué debe resolver | Pregunta que debe poder contestar |
| 1. Identidad y delegación | Identificar al agente y limitar su autoridad | ¿Quién está actuando y en nombre de quién? |
| 2. Política y autonomía | Decidir si una acción está permitida | ¿Puede hacer exactamente esto en este contexto? |
| 3. Ejecución gobernada | Interceptar la acción antes del sistema destino | ¿La decisión ha pasado realmente por el control? |
| 4. Evidencia y observabilidad | Registrar decisión y resultado | ¿Qué se autorizó y qué terminó ocurriendo? |
| 5. Ciclo de vida y propiedad | Gestionar cambios, versiones y responsables | ¿Quién mantiene este control cuando cambia el agente o proveedor? |
1. Identidad y delegación: el agente necesita una identidad propia
Un agente no debería convertirse simplemente en una extensión de la cuenta del usuario que inició la tarea.
Si el empleado tiene permisos para consultar contratos, modificar proveedores y aprobar compras, eso no significa que cualquier agente que actúe en su nombre deba heredar esas tres capacidades.
El modelo debería distinguir, al menos: usuario o sistema originador → agente → autoridad delegada → herramienta → operación → recurso
Por ejemplo, un agente de compras podría disponer de autorización para:
- consultar contratos,
- consultar disponibilidad,
- crear un borrador de solicitud de compra hasta un determinado umbral.
Pero no necesariamente para:
- modificar datos bancarios de un proveedor,
- aprobar su propia solicitud,
- iniciar un pago.
Esto requiere una Non-Human Identity (NHI) verificable para el agente y credenciales de corta duración acotadas a la tarea, herramienta, operación y recurso que necesita. Si un agente delega en otro, la cadena de delegación viaja en el token y la autoridad solo puede estrecharse, nunca ampliarse.
Las cuentas técnicas compartidas dificultan precisamente lo contrario, atribuir cada acción a un actor concreto y aplicar privilegio mínimo de forma granular.
El reto es que todavía no existe un estándar empresarial maduro y universal para transportar esa identidad agéntica entre plataformas.
NCCoE está estudiando cómo aplicar estándares y buenas prácticas de identidad y autorización a agentes, pero el trabajo publicado en febrero de 2026 sigue siendo un concept paper, aunque ya está en fase posterior de consulta desde abril de 2026.
2. Política y autonomía: el prompt no es una frontera de seguridad
Una instrucción como: “No modifiques órdenes superiores a 10.000 € sin autorización humana” puede formar parte del comportamiento esperado del agente, pero no debería ser el mecanismo que protege el ERP.
La política que decide si la acción está permitida debe existir fuera del modelo y evaluarse antes de ejecutar la llamada.
Una política en el Agent Control Plane puede valorar:
- La identidad del agente y el usuario que originó la tarea.
- La operación solicitada y el recurso destino.
- El nivel de riesgo y la clasificación de los datos involucrados.
- El importe de la transacción o el impacto en el sistema.
- La existencia de una aprobación humana válida, entre otros factores contextuales.
El resultado tampoco tiene que reducirse a permitir o denegar. Dependiendo del riesgo puede ser: permitir → permitir con límites → simular → solicitar aprobación → poner en cuarentena → denegar
OWASP recomienda precisamente no confiar únicamente en la salida del modelo para decisiones de autorización y separar el componente que decide del encargado de validar permisos y ejecutar acciones de alto impacto.
¿Cómo decidir cuánta autonomía dar a cada agente?
No todas las acciones necesitan human-in-the-loop.
Una organización puede clasificar la autonomía según el impacto y la reversibilidad:
| Nivel | Ejemplo | Gobierno |
| 0. Asesor | Recomienda una acción | No ejecuta |
| 1. Lectura | Consulta inventario | Acceso read-only |
| 2. Reversible | Crea un borrador | Ejecución automática + auditoría |
| 3. Acotado | Reprograma una entrega dentro de límites | Política y umbrales |
| 4. Alto impacto | Modifica datos maestros o una operación crítica | Aprobación ligada a la acción concreta |
| 5. Prohibido | Ejecuta una operación expresamente no delegable | Denegación |
El criterio debería ser qué daño puede producir la acción, si puede revertirse y qué autoridad se está delegando. Es decir, va mucho más allá de si confiamos o no en el modelo. La aprobación debe ser efectiva: vinculada a la acción concreta, de un solo uso y con caducidad. Si se concede por rutina, no es supervisión.
3. Ejecución gobernada: separar quién decide de quién ejecuta
Aquí está el núcleo de la arquitectura.
- El agente propone o decide una acción.
- El control plane determina si puede ejecutarse.
- El execution plane la realiza.
En la nomenclatura clásica de autorización, el gateway o tool broker es el PEP y el motor de políticas es el PDP.
Esta separación coincide con patrones que OWASP recomienda para operaciones financieras, administrativas, destructivas o de alto impacto y con la separación entre control plane y execution plane descrita en arquitecturas recientes de agentic orchestration.
Ejemplo: Policy-as-Code aplicado a un agente de compras
Para llevar esta separación entre decisión y ejecución a un control concreto, pensemos en un agente de compras que solicita crear una operación en el ERP.
El agente puede proponer la acción, pero no decide si está autorizado a ejecutarla. Antes de llegar al sistema corporativo, el Agent Control Plane evalúa:
- la identidad del agente,
- la autoridad que tiene delegada,
- el tipo de operación,
- el importe,
- el nivel de riesgo y,
- cuando sea necesario, la existencia de una aprobación válida.
La política parte de un principio deny-by-default: cualquier acción permanece denegada salvo que exista una regla que la permita explícitamente.
Antes de leer la política conviene fijar de dónde salen los atributos que evalúa, porque de eso depende que el control sirva para algo.
Ninguno de ellos lo declara el agente. La identidad (agent_id) y la autoridad delegada (delegated_subject, delegation_depth, token_expiry) se derivan de un token verificado —firma, emisor, audiencia y vigencia comprobadas en el punto de aplicación— o del certificado mTLS de la carga de trabajo.
Los atributos de negocio (amount, currency, resource), el contexto de ejecución (environment, data_classification, attempt_count) y el hash canónico de la acción (request_hash) los calcula el gateway sobre el cuerpo real de la llamada que se va a ejecutar, no sobre un campo que el agente afirma.
Una política que evalúa datos aportados por el mismo sujeto al que regula no es un control: es una sugerencia.
THRESHOLD = { amount: 2000, currency: «EUR» }
WRITE_OPERATIONS = [«create», «update», «patch», «delete», «approve», «execute»]
READ_OPERATIONS = [«read», «get», «list», «search»]
PROHIBITED_OPERATIONS = [«execute_payment»]
MAX_ATTEMPTS_PER_ACTION = 2
MAX_DELEGATION_DEPTH = 2
FUNCTION evaluate_policy(request):
# 1 · Identidad y autoridad delegada
IF agent_id IS EMPTY OR delegated_subject IS EMPTY:
RETURN DENY(«agent_identity_missing»)
IF current_time >= token_expiry:
RETURN DENY(«delegated_token_expired»)
IF delegation_depth > MAX_DELEGATION_DEPTH:
RETURN DENY(«delegation_chain_too_deep»)
# 2 · La denegación repetida es una señal de seguridad, no un estado neutro
IF attempt_count >= MAX_ATTEMPTS_PER_ACTION:
RETURN QUARANTINE(«policy_probing_suspected»)
# 3 · Idempotencia: distinguir un reintento legítimo de un replay
IF operation IN WRITE_OPERATIONS:
IF idempotency_key IS EMPTY:
RETURN DENY(«idempotency_key_required»)
IF idempotency_key HAS BEEN USED:
IF request_hash == stored_request_hash(idempotency_key):
RETURN stored_decision(idempotency_key) # reintento legítimo
ELSE:
RETURN DENY(«idempotency_key_conflict») # misma clave, otra petición
# 4 · Operaciones expresamente no delegables
IF operation IN PROHIBITED_OPERATIONS:
RETURN DENY(«operation_explicitly_prohibited»)
IF resource == «supplier_bank_details» AND operation IN WRITE_OPERATIONS:
RETURN DENY(«operation_explicitly_prohibited»)
# 5 · Consultas de solo lectura, acotadas por clasificación del dato
IF operation IN READ_OPERATIONS:
IF data_classification == «restricted»:
RETURN ALLOW_WITH_CONSTRAINTS(«read_restricted_data»,
[«mask_sensitive_fields», «write_audit_event»])
RETURN ALLOW(«read_only_operation»)
# 6 · Borrador de compra dentro del límite delegado
IF tool == «erp» AND operation == «create_purchase_draft»:
IF currency != THRESHOLD.currency:
RETURN DENY(«currency_mismatch_with_threshold»)
IF amount <= THRESHOLD.amount:
IF environment != «production»:
RETURN SIMULATE(«dry_run_outside_production»)
RETURN ALLOW_WITH_CONSTRAINTS(
«purchase_draft_within_delegated_limit»,
[«enforce_draft_only», «record_amount_and_currency», «write_audit_event»])
# 7 · Sobre umbral: aprobación humana ligada a ESTA acción
IF approval IS EMPTY:
RETURN REQUIRE_APPROVAL(«human_approval_required»)
IF approval IS EXPIRED:
RETURN DENY(«approval_expired»)
IF approval HAS ALREADY BEEN USED:
RETURN DENY(«approval_replay_detected»)
IF approval.action_hash != request_hash:
RETURN DENY(«approval_does_not_match_action»)
# Segregación de funciones: nadie aprueba lo que él mismo originó
IF approval.approver_id == delegated_subject:
RETURN DENY(«segregation_of_duties_violation»)
IF approval.approver_id == agent_id:
RETURN DENY(«self_approval_not_permitted»)
RETURN ALLOW(«exact_action_approved»)
# 8 · Deny-by-default
RETURN DENY(«no_policy_explicitly_allows_action»)
Nota sobre request_hash. El PEP calcula el hash canónico sobre un conjunto fijo y ordenado de campos —agent_id, delegated_subject, tool, operation, resource, environment, amount, currency, idempotency_key— de modo que una reordenación de campos o una codificación equivalente del payload no permita reutilizar una aprobación concedida para otra acción.
La política devuelve una respuesta estructurada que el gateway o tool broker debe aplicar antes de ejecutar la llamada:
Respuesta de la política: permitido con límites
{
«decision»: «allow_with_constraints»,
«decision_id»: «dec_01J8K3QF7M2A»,
«reason»: «purchase_draft_within_delegated_limit»,
«policy_version»: «purchasing-agent-v1.4.0»,
«request_hash»: «sha256:9f2c…a71e»,
«expires_at»: «2026-10-01T09:41:37Z»,
«obligations»: [
«enforce_draft_only»,
«record_amount_and_currency»,
«write_audit_event»
]
}
Este ejemplo muestra la separación que debe existir entre solicitud, autorización y ejecución.
El agente propone create_purchase_draft; el Agent Control Plane evalúa si puede hacerlo y bajo qué condiciones; y solo entonces el gateway o tool broker ejecuta la llamada contra el ERP.
Quedan registrados como hechos independientes que el agente solicitó una acción, que la política la permitió y que el sistema destino la ejecutó, sin depender de que el propio modelo determine sus permisos.
Dos reglas cierran el diseño:
- La primera es que las obligaciones son exigibles: si el punto de aplicación no puede cumplir una de las que devuelve la política —no puede reservar la clave de idempotencia, no puede forzar el modo borrador, no puede enmascarar un campo—, la decisión se convierte en denegación.
Un permiso cuyas condiciones no se pueden imponer no es un permiso.
- La segunda es que el control plane opera fail-closed: si el motor de políticas no responde dentro del presupuesto de latencia acordado, la acción se deniega.
Las decisiones pueden cachearse con un TTL corto e invalidación inmediata al cambiar policy_version, pero la indisponibilidad del control nunca puede traducirse en autonomía ilimitada.
¿Puede utilizarse el API Management existente como Agent Control Plane?
Puede ser una parte importante del Agent Control Plane, pero no necesariamente lo resuelve por completo.
Una plataforma de API Management ya puede aportar capacidades muy útiles:
- autenticación,
- autorización,
- aplicación de políticas,
- rate limiting,
- routing,
- registro de llamadas,
- protección de backends,
- contratos de API.
En una organización que ya ha gobernado sus APIs, tiene sentido reutilizar ese punto de control en lugar de permitir que cada framework agéntico establezca conexiones directas con los sistemas corporativos.
Pero gobernar agentes añade necesidades nuevas, como identidad agéntica, autoridad delegada, catálogo de herramientas, autonomía por riesgo, aprobación vinculada a una acción y correlación entre decisión y resultado.
Por eso, según la arquitectura, el API Gateway puede necesitar complementarse con:
- un policy engine (OPA, Cedar u OpenFGA),
- un tool broker,
- un registro de identidades/capacidades (Keycloak, WSO2 Identity Server),
- y una capa de observabilidad agéntica (OpenTelemetry).
La oportunidad es extender el API Management para que las acciones iniciadas por agentes atraviesen los mismos principios de gobierno que cualquier otra integración crítica.
Conoce nuestro nuevo artículo: API Management: Qué es, componentes clave y cómo acelera tu negocio
4. Evidencia y observabilidad: registrar la acción, no reconstruir el razonamiento
¿Cómo auditas una compra realizada hace seis meses si el agente trabaja ahora con otra versión del modelo?
La respuesta no sería intentar reproducir exactamente lo que “pensó” el modelo. La evidencia de auditoría debería anclarse a lo que ocurrió en el punto de ejecución.
Para cada invocación gobernada conviene relacionar:
- identificador de tarea,
- actor originador,
- identidad del agente,
- versión del agente y del modelo,
- herramienta y operación solicitadas,
- recurso objetivo,
- política y versión evaluadas,
- decisión de la política,
- aprobación asociada, cuando exista,
- parámetros relevantes, protegidos o anonimizados cuando sea necesario,
- resultado devuelto por el sistema destino,
- identificador de correlación,
- timestamp.
Hay una distinción especialmente importante que conviene señalar: “la política permitió la operación” ≠ “el sistema destino la ejecutó correctamente”, porque la auditoría necesita ambos eventos.
Esto permite conservar evidencia operacional incluso cuando cambia el prompt, el modelo o el proveedor. La finalidad es construir una traza verificable de identidad, autorización, invocación y resultado.
Exportar esa traza con OpenTelemetry evita reinventar la observabilidad y la conecta con el SIEM existente.
5. Ciclo de vida y propiedad: que el gobierno sobreviva al cambio de proveedor
Un Agent Control Plane no estará terminado cuando funcione el primer agente.
Debe asumir desde el diseño que cambiarán:
- modelos,
- proveedores,
- agentes,
- prompts,
- herramientas,
- MCP servers,
- APIs,
- políticas,
- propietarios.
Por eso las integraciones disponibles para agentes deberían tratarse como capacidades gobernadas, con contratos explícitos.
Cada herramienta integrada debe contar con un contrato explícito que defina, al menos:
- esquema de entrada/salida y operaciones disponibles,
- permisos específicos requeridos y propietario técnico/de negocio asignado,
- llímites de uso y presupuesto de coste por agente,
- estrategias de idempotencia para acciones de alto impacto,
- mecanismos de compensación o rollback frente a fallos, entre otros.
Los circuit breakers, contratos versionados y estrategias de compatibilidad reducen el riesgo de que un cambio en una herramienta provoque fallos en cascada.
OWASP también recomienda idempotencia en acciones de alto impacto cuando sea posible y mecanismos explícitos frente a errores y reintentos.
La propiedad del gobierno también debe quedar documentada fuera de una consola concreta. Una solución propietaria puede implementar parte de estos controles, pero el problema aparece cuando políticas, contratos, responsables y evidencia solo existen dentro de ella.
¿Qué papel tiene MCP en esta arquitectura?
El Model Context Protocol (MCP) ayuda a estandarizar cómo un agente descubre y utiliza herramientas, pero no sustituye al Agent Control Plane.
MCP facilita la conectividad agente → herramienta y permite evitar integraciones completamente ad hoc. Sin embargo, no resuelve por sí mismo:
- identidad empresarial portable,
- autoridad delegada,
- políticas corporativas,
- segregación de funciones,
- gobierno del dato,
- auditoría de extremo a extremo,
- decisión de autonomía.
Forrester identifica este punto de forma expresa, MCP aborda la conectividad agente-herramienta mientras que todavía no existe un descriptor de identidad agéntica con suficiente madurez para propagarse de forma portable por los diferentes planos de la arquitectura.
Por eso una arquitectura preparada para evolucionar debería aprovechar protocolos emergentes sin convertirlos en el lugar donde reside el gobierno.
Cómo llevar el modelo a producción sin transformar todo de golpe
La implantación puede evolucionar por fases, por lo que no se recomienda empezar desplegando una AI Control Tower corporativa completa.
| Fase | Qué se hace | Qué deja listo |
| 1 · Descubrir | Inventariar agentes, cuentas técnicas, tool calls, APIs, servidores MCP y sistemas destino. Importa lo que realmente se ejecuta, no lo que figura en la CMDB | El alcance real, con los agentes que nadie había registrado |
| 2 · Priorizar por riesgo | Llevar al camino gobernado las escrituras contra ERP, IAM, pagos, producción, datos maestros e información sensible | Que las acciones de mayor impacto no puedan saltarse el control |
| 3 · Identidad delegada y Policy-as-Code | Sustituir permisos genéricos por identidad propia del agente, credenciales de corta duración, scopes por herramienta y operación, y aprobación para lo de mayor riesgo | La autorización fuera del modelo y cada acción atribuible a un actor |
| 4 · Correlacionar autorización y ejecución | Construir una traza común —tarea, agente, política, tool call, sistema destino, resultado— y enviarla a la observabilidad, el SIEM o el SOC existentes | Evidencia auditable de qué se autorizó y qué ocurrió |
| 5 · Escalar y transferir propiedad | Extender el patrón a nuevos agentes, automatizar altas y bajas, asignar propietarios, añadir pruebas de políticas y formalizar el gobierno de contratos | Un modelo que sobrevive al cambio de agente, de modelo y de proveedor |
Te podría interesar: Cómo se integra la IA en plataformas de API Management
¿Cómo encaja este modelo con NIST, OWASP y el AI Act?
Estos marcos no sustituyen el diseño de Enterprise Architecture, pero fijan los límites dentro de los que tiene que moverse.
- NIST AI RMF aporta la estructura de gestión del riesgo mediante Govern, Map, Measure y Manage.
- OWASP aporta controles específicos frente a riesgos agénticos: privilegio excesivo, abuso de herramientas, manipulación de aprobaciones o fallos en cascada.
En la Unión Europea, el Reglamento (UE) 2024/1689 exige a los sistemas de alto riesgo registro de eventos y supervisión humana proporcional al riesgo y a la autonomía. El Digital Omnibus aplazó esas obligaciones a diciembre de 2027 (Anexo III) y agosto de 2028 (Anexo I). No todos los agentes serán de alto riesgo, pero la arquitectura que lo demuestra tarda más en construirse que el plazo restante.
¿Está preparada tu arquitectura para agentes con capacidad de ejecución?
Antes de ampliar la autonomía, un Enterprise Architect debería poder responder afirmativamente a estas preguntas:
- ¿Tenemos un inventario de los agentes que pueden actuar sobre sistemas corporativos?
- ¿Cada agente dispone de identidad y permisos propios?
- ¿Podemos impedir una acción antes de que alcance el sistema destino?
- ¿Las operaciones críticas necesitan autorización específica y contextual?
- ¿Podemos demostrar por separado qué acción fue autorizada y cuál fue realmente ejecutada?
- ¿Podemos sustituir un modelo, agente o proveedor sin reconstruir todo el modelo de gobierno?
Si la respuesta a varias de ellas es negativa, el problema está en la arquitectura que conecta la autonomía con la ejecución, no necesariamente en el modelo de IA.
El 25 de junio de 2025 Gartner previó que más del 40% de los proyectos agénticos se cancelarán antes de finalizar 2027 por costes crecientes, valor de negocio poco claro o controles de riesgo insuficientes.
En Chakray trabajamos sobre esa frontera entre arquitectura de integración, API Management y sistemas agénticos.
Si tu organización ya está conectando agentes con APIs, ERP, datos o sistemas core, podemos ayudarte a definir qué controles deben permanecer en la arquitectura corporativa y cómo evolucionar el modelo sin convertir el gobierno en una dependencia de una única plataforma.
Preguntas frecuentes sobre Agentic Enterprise Architecture
¿Qué es Agentic Enterprise Architecture?
Es el diseño de la arquitectura empresarial necesario para integrar agentes de IA capaces de tomar decisiones y ejecutar acciones de forma autónoma manteniendo identidad, autorización, gobierno, observabilidad y trazabilidad sobre los sistemas corporativos.
¿Necesito una nueva plataforma para crear un Agent Control Plane?
No necesariamente. El API Management y la infraestructura de identidad existentes pueden aportar una parte importante del control, aunque normalmente será necesario incorporar o extender capacidades como identidad agéntica, autorización contextual, tool brokering y observabilidad.
¿Las políticas de un agente deben definirse en el prompt o en el gateway?
El prompt puede contener reglas de comportamiento, pero las políticas que protegen sistemas y datos deberían aplicarse fuera del modelo, en un componente capaz de autorizar o bloquear la acción antes de su ejecución.
¿Cómo puedo auditar una acción si cambia la versión del modelo?
Registrando la evidencia en el punto de invocación (identidad del agente, operación, recurso, política aplicada, aprobación, versión y resultado del sistema destino). Así la auditoría no depende de reproducir posteriormente el razonamiento del modelo.
¿Cómo se decide qué acciones puede ejecutar autónomamente un agente?
Clasificando las acciones según su riesgo, impacto, reversibilidad y autoridad necesaria. Las operaciones de bajo impacto pueden automatizarse, mientras que las sensibles pueden limitarse o requerir una aprobación vinculada a la acción concreta.
¿MCP resuelve el gobierno de agentes de IA?
No. MCP ayuda a estandarizar la conexión entre agentes y herramientas, pero no resuelve por sí mismo identidad portable, autoridad delegada, políticas corporativas, supervisión humana o auditoría de extremo a extremo.
