El origen de la confusión — y por qué importa aclararlo ahora
Durante 2024 y buena parte de 2025, el mercado usó "Copilot" como término genérico para cualquier cosa relacionada con IA de Microsoft. Copilot for Microsoft 365, Copilot Studio, Copilot+ PC, Azure Copilot. La marca se aplicó con tanta amplitud que dejó de significar algo preciso. Mientras tanto, Azure AI Foundry —presentado en la Microsoft Ignite 2024 como la renombración de Azure AI Studio— fue ganando peso como la plataforma de referencia para cargas de trabajo de IA enterprise de ciclo completo.
El resultado es predecible: equipos que deberían estar en Copilot Studio empiezan en Foundry porque "suena más enterprise", y equipos que necesitan Foundry arrancan en Copilot Studio porque "es más rápido". Ambos errores tienen el mismo coste: un replatforming a mitad de proyecto cuando las limitaciones de la plataforma elegida se hacen evidentes.
La pregunta correcta no es "¿cuál es mejor?" sino "¿para qué tipo de agente, en qué contexto organizativo, con qué perfil de equipo y con qué requisitos de gobernanza?". Eso es lo que resuelve esta guía.
Qué es Copilot Studio — y para qué fue diseñado
Copilot Studio es la plataforma low-code de Microsoft para construir agentes conversacionales y automatizaciones que viven dentro del ecosistema Microsoft 365. Nació como Power Virtual Agents, se renombró con el ciclo Copilot y se expandió para soportar la publicación de agentes personalizados directamente en Teams, SharePoint, Microsoft 365 Chat y Outlook.
Su propuesta de valor es clara: tiempo cero hasta el primer agente funcional para un perfil de usuario que no escribe código. Un especialista de RRHH puede construir un agente de onboarding que responda preguntas frecuentes, consulte SharePoint, abra tickets en ServiceNow y escale a un humano cuando no sepa responder, sin escribir una sola línea de Python ni tocar una API REST. El agente vive en Teams, se autentica con Entra ID heredado del tenant M365 y los permisos los gestiona el administrador de Microsoft 365 con las herramientas que ya conoce.
Las capacidades técnicas de Copilot Studio han madurado considerablemente: soporta conexiones a cientos de conectores de Power Platform, llamadas a APIs externas mediante conectores personalizados, integración con Dataverse, orquestación de flujos de Power Automate y, desde 2025, capacidades de agente autónomo con triggers proactivos. También puede invocar plugins MCP cuando se configura la integración correspondiente.
Lo que Copilot Studio no fue diseñado para hacer es relevante en igual medida. No es la plataforma adecuada para agentes que necesitan fine-tuning de modelos propios, control granular sobre la capa de inferencia, orquestación compleja multi-agente con grafos de ejecución personalizados, o despliegue en infraestructura dedicada dentro del perímetro del cliente. Tampoco es la elección correcta cuando el equipo necesita reproducibilidad de experimentos, versionado de datasets de evaluación o pipelines MLOps integrados con el ciclo de vida del agente.
Qué es Azure AI Foundry — y el cambio que representa respecto a AI Studio
Azure AI Foundry es la plataforma de Microsoft para el ciclo completo de desarrollo de aplicaciones y agentes de IA en entornos enterprise: desde la experimentación con modelos hasta el despliegue, la monitorización y el gobierno en producción. Se lanzó en Ignite 2024 absorbiendo Azure AI Studio y unificando bajo un mismo portal lo que antes estaba disperso entre Azure Machine Learning, Azure OpenAI Service, Azure AI Search y los servicios cognitivos de Azure.
La diferencia respecto a AI Studio no es solo de nombre. Foundry introduce el concepto de proyecto de IA como unidad de organización: un espacio de trabajo que agrupa modelos, datasets, evaluaciones, despliegues, métricas de seguridad y conexiones a recursos Azure bajo un mismo marco de gobierno. Los proyectos pertenecen a un hub de Foundry, que es el nivel donde se definen las políticas de seguridad, los recursos de red, las identidades gestionadas y los controles de compliance que se heredan a todos los proyectos contenidos.
El catálogo de modelos de Foundry es el más amplio del mercado cloud: modelos de OpenAI (GPT-4o, o3, o4-mini), modelos open-source de Meta, Mistral, Cohere y otros proveedores disponibles como serverless deployments o como despliegues dedicados en infraestructura Azure.
Para la construcción de agentes, Foundry ofrece el Azure AI Agent Service: un runtime gestionado para agentes con memoria persistente, ejecución de código (Code Interpreter), integración nativa con Azure AI Search para RAG, llamadas a herramientas via function calling y observabilidad integrada con Azure Monitor. Los agentes se definen en código (Python SDK o REST API), lo que permite control total sobre la lógica de orquestación, los prompts de sistema y el comportamiento ante errores.
La tabla de decisión — los ocho criterios que importan
Antes de la tabla, una advertencia: ningún criterio es absoluto. Hay organizaciones que usan Copilot Studio para casos que superficialmente "parecen" de Foundry, y lo hacen bien porque el contexto organizativo lo justifica. La tabla describe el escenario más probable, no una regla rígida.
| Criterio | Copilot Studio | Azure AI Foundry |
|---|---|---|
| Perfil del equipo | Analistas de negocio, equipos citizen developer. Conocimiento de Power Platform es una ventaja. | Ingenieros de software, arquitectos cloud, data scientists. Python o TypeScript requerido. |
| Superficie de despliegue | Microsoft 365: Teams, SharePoint, Outlook, M365 Chat. También web embebido. | Cualquier superficie: aplicaciones propias, APIs REST, canales de mensajería, flujos de negocio, otros agentes. |
| Control sobre el modelo | Modelo gestionado por Microsoft (GPT-4o por defecto). Sin fine-tuning ni selección granular de versión. | Control total: selección de modelo, versión, configuración, fine-tuning, despliegue dedicado o serverless. |
| Orquestación multi-agente | Limitada. Posible via Power Automate, pero sin grafos de ejecución personalizados. | Nativa. Patrón orquestador-subagente, handoff entre agentes, grafos de ejecución con lógica condicional compleja. |
| Integración con sistemas | Conectores Power Platform (900+) y Power Automate. Rápido para sistemas cubiertos, limitado para sistemas propietarios. | Via function calling a cualquier API o sistema. Sin límite de conectores predefinidos. |
| Gestión de identidad | Heredada del tenant M365 y Entra ID. Sin flexibilidad adicional. | Configurable: Managed Identity, RBAC de Azure, Entra ID, scopes de API específicos por agente. |
| Observabilidad y trazabilidad | Analytics integrado (conversaciones, satisfacción, escalaciones). Limitado para auditorías regulatorias detalladas. | Azure Monitor, Application Insights, trazabilidad de cada llamada al modelo, logs exportables al SIEM del cliente. |
| Tiempo al primer agente | Horas. Un agente básico en Teams puede estar operativo en una tarde. | Días. La configuración del hub, identidades y primer despliegue requieren trabajo de infraestructura. |
El patrón que repiten los proyectos que fracasan — y los que no
En los proyectos de agentes de IA que acompañamos desde GFT en banca, seguros y sector público, el error más frecuente no es elegir la plataforma equivocada desde el principio. Es elegir Copilot Studio para un caso de uso que en el piloto tiene un alcance que encaja, y descubrir en el mes cuatro que el caso de uso real —el que el negocio quiere en producción— tiene requisitos que Copilot Studio no puede satisfacer.
El patrón típico: el piloto arranca con un agente de atención a empleados en Teams. Funciona bien. El negocio lo ve y pide que el agente también consulte el core bancario para dar saldos en tiempo real, que registre operaciones en el sistema de gestión documental, que se integre con el sistema de tickets del área de riesgos y que genere un log de auditoría que el equipo de cumplimiento pueda enviar al regulador. Cada uno de esos requisitos por separado podría resolverse con esfuerzo en Copilot Studio. Los cuatro juntos, con las restricciones de seguridad de un banco bajo DORA, ya no.
Los proyectos que no caen en este patrón definen el caso de uso objetivo —no el piloto— antes de elegir la plataforma. Si el caso de uso objetivo tiene alguno de estos cinco indicadores, la respuesta es Azure AI Foundry desde el día uno:
- El agente necesita acceder a sistemas que no tienen conector en Power Platform.
- El agente toma decisiones que el regulador va a auditar con granularidad de traza individual.
- El agente orquesta tareas que implican a otros agentes o a modelos especializados distintos.
- El equipo necesita comparar el comportamiento del agente entre versiones del modelo de forma reproducible.
- El agente maneja datos que requieren residencia garantizada en infraestructura dedicada al cliente.
Si ninguno de esos cinco aplica y la superficie de despliegue es Microsoft 365, Copilot Studio es la elección correcta. El time-to-value es real y el coste de propiedad para el equipo funcional es significativamente menor.
Sectores regulados: lo que cambia respecto a una empresa no regulada
En una empresa de retail o de servicios no regulados, el criterio dominante en la elección de plataforma es la velocidad. El agente que llega primero al usuario captura el valor. En banca, seguros y administración pública, la velocidad sigue importando, pero hay tres capas adicionales que condicionan la elección:
1. Trazabilidad regulatoria
DORA, en su artículo 28, exige que las entidades financieras mantengan registros completos de las dependencias con proveedores TIC críticos y de las funciones de negocio que soportan. Cuando el agente de IA toma o influye decisiones —aprobación de operaciones, escalación de alertas, generación de comunicaciones reguladas—, la trazabilidad de cada ejecución del agente es un requisito de cumplimiento, no una buena práctica.
Copilot Studio ofrece analytics de conversación, pero no está diseñado para exportar logs estructurados con el nivel de detalle que el equipo de cumplimiento necesita para documentar una dependencia TIC bajo DORA. Azure AI Foundry, integrado con Application Insights y Azure Monitor, permite configurar la captura de cada llamada al modelo, cada tool call ejecutada y cada decisión del agente en formato exportable al SIEM o al repositorio de evidencias de cumplimiento.
2. Residencia y soberanía de datos
Los datos que el agente procesa en Copilot Studio pasan por la infraestructura de Microsoft 365, cuya región de datos la configura el administrador del tenant M365. Para la mayoría de entidades en España, eso es la región de la UE. Para entidades que necesitan garantías de residencia en región específica con controles contractuales propios —condición frecuente en licitaciones de sector público bajo ENS Categoría Alta—, Foundry permite desplegar el agente en una región Azure concreta con las condiciones contractuales que el cliente haya negociado con Microsoft.
3. Gobierno del agente como sistema TIC
La pregunta que ningún equipo técnico hace suficientemente pronto: ¿quién es el propietario del agente como sistema TIC? En Copilot Studio, el agente es un recurso del tenant M365 gestionado por la administración de Microsoft 365. En Foundry, el agente es un recurso Azure con su propio Resource Group, sus propias etiquetas de coste, su propio RBAC y su propia política de gestión de cambios. Para una entidad que necesita incorporar el agente a su inventario de activos TIC con los mismos controles que aplica al resto de sistemas críticos, Foundry ofrece el marco de gobierno nativo de Azure que el equipo de riesgos TI ya conoce.
El patrón que funciona: Copilot Studio encima de Foundry
La pregunta más frecuente que recibimos en proyectos de cierta envergadura no es "¿cuál de los dos?" sino "¿pueden coexistir?". La respuesta es sí, y hay un patrón concreto que funciona bien en organizaciones con equipos técnicos y funcionales simultáneamente.
El esquema: los agentes de capacidad especializada —los que acceden a sistemas de negocio, gestionan datos regulados, ejecutan lógica compleja— se construyen y despliegan en Azure AI Foundry. Esos agentes exponen endpoints de API con autenticación Entra ID. Copilot Studio actúa como la capa de interacción: el agente conversacional en Teams que el usuario final ve y con el que habla, que internamente llama a los agentes de Foundry a través de conectores personalizados o funciones HTTP.
El resultado: el usuario experimenta la simplicidad de un agente en Teams. El equipo técnico tiene control total sobre la lógica de negocio, la trazabilidad y la gestión del modelo en Foundry. El equipo de cumplimiento tiene los logs en Azure Monitor. El administrador de Microsoft 365 gestiona quién tiene acceso al agente de Copilot Studio sin necesidad de entender la arquitectura de Foundry.
El coste del patrón híbrido: requiere trabajo de integración entre las dos capas y disciplina en la definición de contratos de API entre el agente de Copilot Studio y los agentes de Foundry. No es la elección correcta para un piloto rápido, pero sí para un sistema que tiene que escalar y pasar auditorías regulatorias.
Pricing — la variable que los arquitectos subestiman
El modelo de costes de Copilot Studio y Azure AI Foundry es fundamentalmente diferente, y esa diferencia tiene impacto directo en el TCO del agente a escala.
Copilot Studio tiene un modelo de licenciamiento por mensaje: cada conversación con el agente consume mensajes del pool de la organización. A junio de 2026, el precio base es de 200 dólares por 25.000 mensajes adicionales cuando se supera el pool incluido en la licencia M365. Para agentes de alta frecuencia —atención al empleado en una entidad de 5.000 personas, por ejemplo—, el consumo de mensajes puede ser difícil de predecir y de controlar.
Azure AI Foundry factura por consumo de tokens en los modelos desplegados, más el coste de los recursos Azure subyacentes (compute para modelos dedicados, almacenamiento, red). El coste por interacción es potencialmente menor a escala, pero requiere dimensionamiento previo y monitorización activa del consumo. Para equipos sin experiencia en FinOps de IA, el riesgo de sorpresa en la factura de Azure es real.
La recomendación práctica: para volúmenes bajos o medios de interacción en un contexto M365 ya licenciado, Copilot Studio tiene un coste efectivo muy competitivo. Para agentes de alta frecuencia o con llamadas intensivas a modelos de razonamiento (o3, o4), el análisis de TCO a 12 meses favorece generalmente Foundry con modelos serverless bien dimensionados.
Cinco preguntas para tomar la decisión en 15 minutos
Si el equipo necesita una decisión rápida sin tiempo para el análisis completo, estas cinco preguntas cubren el 90% de los casos:
- ¿El agente va a vivir principalmente en Teams, SharePoint u Outlook? Sí → Copilot Studio es el punto de partida natural. No → evaluar Foundry.
- ¿El equipo que construye el agente sabe Python o tiene ingenieros de software dedicados? No → Copilot Studio reduce la barrera de entrada significativamente. Sí → Foundry ofrece más control y no supone una barrera.
- ¿El agente va a tomar decisiones que el regulador va a auditar a nivel de traza individual? Sí → Foundry es prácticamente obligatorio para la capa de decisión. No → cualquiera de las dos puede funcionar.
- ¿El agente necesita integrarse con sistemas que no tienen conector en Power Platform? Sí → Foundry, o el patrón Copilot Studio + Foundry descrito más arriba. No → Copilot Studio puede cubrir el caso con menos esfuerzo.
- ¿El caso de uso objetivo implica orquestar varios agentes especializados? Sí → Foundry desde el principio, o un replatforming costoso en el mes cuatro. No → Copilot Studio es suficiente para la mayoría de casos conversacionales lineales.
Lo que Microsoft no dice en sus comparativas oficiales
La documentación oficial de Microsoft presenta ambas plataformas como complementarias y evita posicionarlas en competencia directa. Eso es técnicamente correcto pero comercialmente interesado: si la organización tiene licencias M365 activas, Microsoft tiene incentivos para que el agente viva en Copilot Studio porque refuerza la plataforma M365 y facilita la renovación de licencias. Si la organización es cliente heavy de Azure, los incentivos apuntan a Foundry.
La realidad que esa documentación no explicita: Copilot Studio tiene un techo técnico real para casos de uso enterprise complejos, y ese techo se alcanza con más frecuencia de la que Microsoft reconoce en sus materiales de venta. No porque Copilot Studio sea una mala plataforma —es excelente para lo que está diseñada—, sino porque el entusiasmo inicial con los agentes lleva a los equipos a querer hacer con Copilot Studio cosas que no son su caso de uso objetivo.
El consejo que damos sistemáticamente: construid el piloto donde sea más rápido —Copilot Studio en la mayoría de casos—, pero diseñad la arquitectura objetivo pensando en Foundry si el caso de uso tiene alguno de los cinco indicadores listados más arriba. El tiempo de migrar un piloto de Copilot Studio a una arquitectura de Foundry es asumible. El tiempo de replatforming de un sistema en producción con usuarios reales no lo es.
Resumen ejecutivo
La plataforma correcta para agentes que dan servicio a empleados o clientes dentro de Microsoft 365, construidos por equipos funcionales con perfil low-code, y que no requieren control granular sobre el modelo, trazabilidad regulatoria de grado auditable ni integración con sistemas fuera del universo Power Platform. El time-to-value es alto y el coste de operación para el equipo funcional es bajo.
La plataforma correcta para agentes que toman o influyen decisiones de negocio, que el regulador va a auditar, que se integran con sistemas propietarios o heredados, que orquestan lógica compleja multi-agente, o que el equipo de riesgos TI necesita gestionar con los mismos controles que aplica al resto de sistemas críticos. El time-to-value inicial es mayor, pero la capacidad de escalar, auditar y gobernar el agente en producción no tiene equivalente en Copilot Studio.
Para organizaciones que necesitan velocidad de despliegue en Microsoft 365 y control enterprise sobre la lógica de decisión simultáneamente. Esta combinación resuelve la tensión entre ambas dimensiones con el coste de una capa de integración adicional bien definida.