---
title: "Arquitectura de agentes de IA: piezas, orquestación multiagente, eventos y gobierno"
description: "Qué piezas forman un agente de IA, cómo se orquestan varios agentes especializados, por qué la arquitectura orientada a eventos da autonomía real y qué controles hacen falta antes de llevarlos a producción."
url: https://bidatia.com/ideas/arquitectura-de-agentes-de-ia-multiagente-eventos-y-gobierno
lang: es
date: 2026-03-10
updated: 2026-11-11
author: "José Luis García"
keywords: ["agentes de ia", "sistemas multiagente", "arquitectura orientada a eventos", "orquestación de agentes", "model context protocol", "a2a", "copilot studio", "gobierno de la ia"]
publisher: Bidatia
---

# Arquitectura de agentes de IA: piezas, orquestación multiagente, eventos y gobierno

> Qué piezas forman un agente de IA, cómo se orquestan varios agentes especializados, por qué la arquitectura orientada a eventos da autonomía real y qué controles hacen falta antes de llevarlos a producción.

## Resumen ejecutivo

- Un agente de IA no es un modelo de lenguaje aislado: combina modelo de razonamiento, instrucciones, conocimiento propio y herramientas que actúan sobre los sistemas de la empresa.
- La potencia aparece al repartir el trabajo entre agentes especializados coordinados por un orquestador, con flujos secuenciales para lo regulado y flujos dinámicos para lo demás.
- La arquitectura orientada a eventos permite que los agentes reaccionen a lo que pasa en el negocio, no solo a lo que se les pregunta, y aísla los fallos.
- MCP y A2A estandarizan cómo un agente recibe herramientas y cómo se comunica con otros, y reducen la dependencia de un proveedor.
- En producción, cada agente necesita identidad propia, aprobación humana en decisiones de riesgo, trazabilidad completa y evaluación continua.
- Incluye una comparativa de plataformas (low-code y pro-code) y una lista de comprobación de seis puntos antes de escalar.

Los primeros proyectos de IA generativa en empresa fueron, casi todos, asistentes que responden preguntas. Son útiles, pero tienen dos límites claros: solo actúan cuando alguien les escribe y su memoria se reduce a lo que cabe en la conversación. Un **agente de IA** va un paso más allá: razona sobre un objetivo, planifica los pasos, consulta información de la organización y ejecuta acciones en otros sistemas. Y cuando hay varios agentes trabajando juntos, la arquitectura importa tanto como el modelo.

Este artículo repasa las decisiones de diseño que determinan si un sistema de agentes será mantenible y escalable o si se convertirá en un prototipo imposible de llevar a producción.

## Las cuatro piezas de un agente

Un agente es la orquestación de cuatro elementos:

| Pieza | Qué aporta | Ejemplo |
|---|---|---|
| Modelo de razonamiento | Interpreta la intención, decide y planifica la secuencia de acciones | Un modelo de lenguaje de propósito general |
| Instrucciones | Definen la especialidad, el tono, los límites y qué hacer ante la duda | «Agente de nómina», «agente de cumplimiento normativo» |
| Conocimiento | Memoria de la conversación y acceso a documentación propia mediante búsqueda semántica (RAG) | Políticas internas, procedimientos, convenios |
| Herramientas | Conectores que permiten consultar y modificar sistemas reales | ERP, CRM, sistema de recursos humanos |

La pieza que más riesgo introduce es la última: en cuanto un agente puede **cambiar el estado** de un sistema (crear un pedido, modificar un contrato, enviar un correo), deja de ser un experimento y pasa a ser una aplicación con consecuencias. Por eso conviene que cada agente tenga pocas herramientas y bien acotadas.

## Sistemas multiagente: especializar y coordinar

Un único agente que lo sabe todo y lo puede todo es difícil de probar y de corregir. La alternativa es **descomponer por dominio**: en recursos humanos, por ejemplo, un agente de vacaciones, otro de nómina y otro de incorporación, cada uno con sus instrucciones, su conocimiento y sus permisos.

Por encima, un **agente orquestador** recibe la petición, identifica qué agentes deben intervenir, en qué orden y con qué dependencias, y compone la respuesta final. Hay dos formas de orquestar:

- **Secuencial**: el flujo está definido de antemano. Es la opción adecuada para procesos con pasos obligatorios y requisitos de cumplimiento, como una incorporación en un sector regulado o una revisión financiera.
- **Autónoma**: el modelo decide el flujo sobre la marcha según el contexto y los resultados parciales de cada agente. Da más flexibilidad, pero es menos predecible y exige más trazabilidad y más pruebas.

En la práctica, muchos sistemas combinan ambas: un esqueleto secuencial para lo que tiene que cumplirse siempre y tramos autónomos donde la variabilidad es aceptable.

## Arquitectura orientada a eventos: autonomía de verdad

Si un agente solo actúa cuando alguien le escribe, sigue siendo reactivo. La autonomía real llega cuando reacciona a **lo que ocurre en el negocio**: se emite una factura, llega un correo a un buzón, baja el inventario de un artículo o vence un plazo. La arquitectura orientada a eventos (EDA) proporciona esa capacidad.

Tres ventajas la hacen casi imprescindible en sistemas de agentes:

1. **Disparadores automáticos.** Los agentes se suscriben a eventos y actúan sin intervención humana: preparar una reclamación de cobro, abrir una incidencia o lanzar una alerta.
2. **Respuesta en tiempo real.** El agente actúa cuando el evento se produce, no cuando alguien revisa una bandeja.
3. **Resiliencia.** Al estar desacoplados, el fallo de un agente no tumba el sistema: el evento queda en cola y se procesa cuando el componente se recupera.

## Protocolos de interoperabilidad: MCP y A2A

Dos estándares están ordenando un ecosistema que hasta hace poco era una colección de integraciones a medida:

- **MCP (Model Context Protocol)**: una capa común para ofrecer herramientas y contexto a cualquier agente. Una herramienta publicada por MCP se puede reutilizar en agentes construidos con plataformas distintas.
- **A2A (Agent-to-Agent)**: un estándar emergente para que agentes de plataformas y lenguajes diferentes se comuniquen de forma segura.

Apostar por ellos desde el principio reduce la dependencia de un proveedor y evita rehacer integraciones cada vez que cambia el modelo o la plataforma.

## Gobierno, seguridad y monitorización

Un agente en producción necesita el mismo rigor que cualquier aplicación crítica, y algunos controles específicos:

- **Identidad propia por agente.** Cada agente se da de alta en el proveedor de identidad con permisos mínimos sobre datos y API, y sus acciones quedan registradas a su nombre. Los principales proveedores, como Microsoft Entra, ya ofrecen identidades específicas para agentes.
- **Persona en el bucle.** Las decisiones no estándar o de alto riesgo (una concesión de crédito, un cambio contractual, cualquier acción irreversible) requieren aprobación humana explícita.
- **Cumplimiento aplicado en la plataforma.** Las políticas de protección de la información y las obligaciones del RGPD y del Reglamento europeo de IA se aplican de forma centralizada, no agente a agente.
- **Trazabilidad completa.** Cada paso (orquestador, agente, herramienta, respuesta) se registra con herramientas de observabilidad como OpenTelemetry o Azure Monitor. Sin ese rastro, depurar un error o responder a una auditoría es casi imposible.
- **Evaluación continua.** Como las respuestas no son deterministas, se prueban de forma automática y periódica la fidelidad a las fuentes y la seguridad del contenido, no solo en el momento de la entrega.

## Qué plataforma elegir

No hay una solución única. La elección equilibra velocidad de desarrollo, control técnico e integración con lo que ya existe:

| Plataforma | Desarrollo | Integración | Despliegue | Encaja en |
|---|---|---|---|---|
| Copilot Studio | Low-code, visual | Microsoft 365 y Power Platform | Nube gestionada | Prototipos rápidos y flujos creados por usuarios de negocio |
| Microsoft Foundry (antes Azure AI Foundry) | Pro-code (Python, C#) | Ecosistema Azure | Contenedores, Kubernetes | Sistemas críticos con requisitos de cumplimiento |
| n8n | Low-code, visual | Agnóstico, con soporte de MCP | Nube o instalación propia | Integraciones complejas y portabilidad |
| LangChain, LlamaIndex | Bibliotecas de Python | API genéricas | Contenedores, Kubernetes | Experimentación y modelos abiertos |

### Una arquitectura dual en entornos Microsoft

En organizaciones que ya trabajan con Microsoft, una combinación que funciona bien es:

1. **Delante, Copilot Studio**, como cara conversacional y orquestación de alto nivel. Los usuarios de negocio pueden crear y ajustar flujos sin programar.
2. **Detrás, Microsoft Foundry**, como motor para lo complejo: RAG avanzado, modelos ajustados, evaluación y despliegue controlado.
3. **Para los agentes desarrollados a medida, un SDK como Semantic Kernel** (hoy integrado en Microsoft Agent Framework), independiente del modelo y con soporte de los protocolos abiertos.

El principio es sencillo: la capa delantera gestiona la experiencia de usuario; la trasera garantiza seguridad, escalabilidad y cumplimiento en las operaciones críticas.

## Seis comprobaciones antes de producción

Si un sistema falla en alguna, su mantenimiento a medio plazo está en riesgo:

1. **Modularidad**: ¿cada agente tiene un rol único y un conjunto limitado de herramientas?
2. **Infraestructura desacoplada**: ¿usa eventos y puede escalar horizontalmente con contenedores cuando crecen los disparadores y la demanda?
3. **Protocolos estándar**: ¿la comunicación entre agentes y herramientas usa MCP o A2A?
4. **Identidad y acceso**: ¿cada agente tiene identidad propia con permisos mínimos sobre datos y API?
5. **Trazabilidad**: ¿se registra cada paso del orquestador y de los agentes?
6. **Evaluación automatizada**: ¿hay pruebas periódicas de fidelidad y de seguridad del contenido?

## Por dónde empezar

El éxito depende menos de la tecnología que de aplicar con disciplina unos pocos principios: modularidad, gobierno, observabilidad y cumplimiento. Un camino razonable:

1. Elegir uno o dos casos de uso con valor claro y riesgo controlado.
2. Definir desde el principio las identidades, los permisos y los puntos de aprobación humana.
3. Construir una prueba de concepto en un entorno controlado, con trazabilidad desde el primer día.
4. Escalar de forma gradual, con métricas de calidad que se revisan de forma continua.

En Bidatia ayudamos a diseñar este tipo de arquitecturas y a llevarlas a producción con los controles adecuados.

## Preguntas frecuentes

### ¿Qué diferencia hay entre un asistente basado en un modelo de lenguaje y un agente de IA?
El asistente responde a lo que se le pide y su capacidad depende de lo que cabe en la conversación. El agente, además de razonar, planifica, consulta conocimiento propio de la organización y usa herramientas para ejecutar acciones en otros sistemas, como registrar una solicitud en el ERP o actualizar el CRM.

### ¿Cuándo conviene un sistema multiagente en lugar de un único agente?
Cuando el proceso abarca tareas distintas con reglas, datos y permisos diferentes. Un agente por tarea, con pocas herramientas, es más fácil de probar, corregir y auditar que un agente generalista que lo hace todo.

### ¿Qué aportan MCP y A2A?
MCP (Model Context Protocol) estandariza cómo se ponen herramientas y contexto a disposición de un agente. A2A (Agent-to-Agent) estandariza la comunicación entre agentes construidos en plataformas distintas. Con ambos, cambiar de plataforma o de modelo no obliga a rehacer las integraciones.

### ¿Hay que empezar con low-code o con pro-code?
Depende del caso. El low-code permite validar rápido un flujo conversacional; el pro-code da más control para lógica crítica, pruebas y despliegue. Muchas arquitecturas combinan ambos: una capa conversacional ágil delante y servicios desarrollados detrás.