Agentes de Microsoft 365 Copilot: ¿quién responde si fallan?

📋 En resumen

Para quién: arquitectos y responsables de extensibilidad de Microsoft 365 Copilot que deciden entre conector, agente declarativo, plugin de API o Copilot Studio
Tiempo de lectura: ~7 minutos
Qué vas a sacar: qué hereda Microsoft y qué asumes tú en cada capa de extensibilidad de M365 Copilot, y cuándo compensa cada una

Cuando un cliente me pide "un agente para Copilot", casi nunca sabe cuál de las cuatro cosas está pidiendo. Y la diferencia no es de funcionalidad — es de quién firma cuando algo va mal.

Esa es la pregunta que abro en cualquier conversación sobre extensibilidad de Microsoft 365 Copilot, antes de hablar de modelos, de plugins o de Copilot Studio: si este agente comete un error delante de un cliente o expone un dato que no debía, ¿quién responde? Microsoft, o tu organización. La arquitectura que elijas determina la respuesta, y pocos equipos de TI en España la deciden a propósito — la heredan por accidente, normalmente porque alguien empezó por arriba de la escalera.

¿Qué significa "crear un agente" en Microsoft 365 Copilot?

Depende del peldaño. Hay cuatro capas: un conector que solo indexa contenido, un agente declarativo que acota Copilot con instrucciones propias, un plugin de API que permite a ese agente actuar sobre un sistema externo, y un agente personalizado construido en Copilot Studio con tu propio modelo y orquestación. Microsoft documenta las cuatro como capacidades independientes, no como versiones de lo mismo.

La confusión habitual es tratar "agente" como una palabra única, cuando en realidad describe cuatro contratos de responsabilidad distintos. Antes de escribir el primer manifiesto conviene saber en cuál de los cuatro estás.

En la práctica, esto se resuelve con una sola pregunta de descubrimiento, no con un taller de arquitectura: ¿el problema es que Copilot no ve cierta información, o que alguien necesita pedirle que actúe sobre un sistema externo? Lo primero casi siempre se resuelve con un conector. Lo segundo obliga a subir, como mínimo, hasta el agente declarativo con un plugin. Saltarse ese diagnóstico es la razón por la que tantos proyectos de agentes empiezan sobredimensionados desde el primer sprint.

¿Quién responde si un agente declarativo se equivoca?

Microsoft, en gran parte. Un agente declarativo reutiliza el orquestador y los modelos de Copilot, y hereda automáticamente sus controles de seguridad, cumplimiento e IA responsable. Tú configuras el alcance — instrucciones, fuentes de conocimiento, acciones —; Microsoft sostiene la infraestructura debajo.

Es la frase que casi nadie termina de leer en la documentación de agentes: los agentes declarativos heredan los estándares de Microsoft 365; los personalizados deben garantizar los suyos propios. Esa única línea separa un despliegue de dos semanas de uno de dos trimestres. Si ya tienes agentes en producción, el Copilot Control System es donde se ve, de forma centralizada, quién hereda qué.

¿Y si necesito un agente personalizado en Copilot Studio?

Entonces la responsabilidad se traslada por completo a ti: el modelo, la orquestación, la protección de datos, la seguridad del contenido. Copilot Studio es la vía correcta cuando hace falta un modelo distinto, disparadores proactivos — el agente actúa sin que nadie se lo pida —, canales fuera de Microsoft 365, o una orquestación que el Copilot nativo no puede expresar.

Fuera de esos casos, elegir agente personalizado suele significar reconstruir desde cero identidad, protección de datos y seguridad de contenido que, un peldaño más abajo, ya venían incluidos. El coste oculto de estos agentes casi nunca aparece en la estimación inicial — aparece en la factura tres meses después.

¿Los plugins de Copilot ya están activos en mi tenant sin que nadie lo sepa?

Sí. La capacidad de plugins viene activada por defecto en cualquier tenant con licencia Copilot. Los administradores pueden desactivarla por usuario o grupo, y aprobar plugins concretos desde Aplicaciones integradas, en el centro de administración de Microsoft 365 — así lo confirman el ecosistema de extensibilidad y las preguntas frecuentes sobre agentes.

La pregunta correcta no es "¿cómo lo activamos?". Es "¿sabemos ya qué puede hacer, y lo hemos acotado?". Si nadie del equipo ha revisado esa pantalla, hay capacidad de actuar sobre sistemas externos encendida ahora mismo, sin que nadie la haya aprobado a propósito.

¿Cuántas acciones puede ejecutar un agente antes de que la calidad se degrade?

Hasta cinco plugins se inyectan siempre en el prompt del modelo; a partir del sexto, la selección depende de una coincidencia semántica sobre la descripción de cada plugin, no sobre sus funciones individuales. Y aunque un plugin puede exponer funciones sin límite formal, la documentación de plugins es clara: pasadas unas diez funciones, la calidad de respuesta empieza a caer por la ventana de contexto del modelo. Los detalles de generación de manifiestos están en la guía para construir plugins de API.

La consecuencia práctica es doble. Si tienes más de cinco plugins, la descripción deja de ser un metadato decorativo — es lo que decide si tu plugin se selecciona o no. Y si un equipo expone treinta operaciones de una API "porque ya estaban construidas", no le está dando más potencia al agente. Le está dando un pajar y pidiéndole que encuentre la aguja. La checklist de gobernanza de agentes recoge este límite como uno de los seis que hay que fijar antes de producción.

¿Cuándo compensa pasar por Copilot Studio en vez de quedarte en un agente declarativo?

Cuando necesitas gestión de ciclo de vida estructurada entre desarrollo, pruebas y producción, gobernanza de conectores, publicación en varios canales, o aprobación administrativa antes de que el agente llegue al catálogo de la organización. La guía de planificación lo resume con ejemplos claros: un asistente de soporte de TI es un conector; un asistente de cumplimiento sanitario que combina políticas de SharePoint con normativa en tiempo real es un agente declarativo con un plugin de API; un agente de mantenimiento predictivo que ingiere telemetría IoT y avisa por Teams es, ya sí, un agente personalizado.

Mi recomendación para equipos en España: empieza un peldaño más abajo del que te apetece

La mayoría de organizaciones que veo evaluando agentes para Copilot todavía no tienen mapeado quién aprueba plugins en su tenant, y ya están diseñando un agente personalizado. Es el orden equivocado. El primer proyecto de agentes no debería ser el más ambicioso técnicamente — debería ser el que deja el mapa de gobernanza claro para el segundo.

Con el Reglamento europeo de IA marcando obligaciones crecientes para sistemas en producción, esa secuencia importa más en 2026 que hace un año: cuanto más peldaños subas sin necesidad, más superficie de cumplimiento propia estás creando, y menos puedes apoyarte en los controles que Microsoft ya certifica por ti. No es una opinión conservadora por prudencia. Es aritmética de horas de ingeniería: cada peldaño que subes de más son semanas que no vuelven.

Preguntas frecuentes

¿Necesito Copilot Studio para crear cualquier agente de Copilot?
No. Un agente declarativo se construye y se publica sin pasar por Copilot Studio; Copilot Studio entra en juego cuando necesitas su gobernanza de ciclo de vida o un agente personalizado.

¿Puedo usar un plugin de API sin un agente declarativo?
No. Los plugins de API solo funcionan como acciones dentro de un agente declarativo; no se activan por sí solos en Microsoft 365 Copilot.

¿Cuál es la diferencia entre un conector y un plugin en una frase?
El conector aporta conocimiento — Copilot puede leerlo y responder desde ahí. El plugin aporta acción — el agente puede crear, modificar o cerrar algo en un sistema externo.

¿Quién aprueba qué plugins puede usar mi organización?
Los administradores, desde Aplicaciones integradas en el centro de administración de Microsoft 365. Ahí se activa o desactiva por usuario o grupo, y se aprueban plugins concretos.

¿Un agente declarativo puede convertirse más adelante en un agente personalizado?
No hay una migración automática, pero sí un camino ordenado: si el agente declarativo empieza a necesitar disparadores proactivos, canales fuera de Microsoft 365 o un modelo distinto, esos requisitos se documentan como los que justifican el salto a Copilot Studio, y se reconstruye desde ahí en lugar de forzar el agente original más allá de sus límites.