Tu agente de Copilot Studio responde correctamente en el panel de chat de prueba, pero después de publicarlo, el agente activo devuelve errores, respuestas incorrectas o ninguna respuesta. Este comportamiento dividido generalmente significa que la versión publicada no tiene los mismos permisos ni conexiones de datos que el borrador que probaste localmente. El entorno de ejecución del agente para agentes publicados aplica límites de seguridad más estrictos, y es posible que tu configuración no se haya transferido por completo. Este artículo explica la causa raíz de la discrepancia y proporciona soluciones paso a paso para alinear tu agente publicado con los resultados de tus pruebas.
Puntos clave: Solucionar fallas del agente publicado en Copilot Studio
- Copilot Studio > Temas > Autenticación del agente publicado: El agente publicado usa una identidad diferente a la del chat de prueba. Debes configurar la autenticación para el punto de conexión publicado.
- Copilot Studio > Orígenes de datos > Conexiones de datos del agente publicado: El chat de prueba puede usar tus credenciales de administrador para acceder a los datos, pero el agente publicado necesita permisos explícitos de los orígenes de datos (Microsoft Graph, Dataverse o conectores personalizados).
- Copilot Studio > Configuración > Canales > Direct Line o Teams: Cada canal tiene una configuración independiente. Un chat de prueba que funciona no garantiza que la configuración del canal sea correcta.
Por qué falla el agente publicado mientras el chat de prueba funciona
Los agentes de Copilot Studio se ejecutan en dos contextos de ejecución distintos. El panel de chat de prueba usa tu propia identidad y permisos de Microsoft 365. Cuando escribes una pregunta, el agente se ejecuta bajo tu cuenta, que tiene acceso completo a los orígenes de datos que configuraste: Microsoft Graph, sitios de SharePoint, tablas de Dataverse o API personalizadas. Sin embargo, el agente publicado se ejecuta bajo una identidad del sistema o una identidad del usuario final según el canal. Si publicas en Teams, el agente se ejecuta bajo la identidad del usuario final. Si publicas en un sitio web personalizado a través de Direct Line, el agente se ejecuta bajo una identidad anónima a menos que configures el intercambio de tokens.
La causa raíz más común es que el método de autenticación publicado del agente esté configurado como “Sin autenticación” o “Autenticación de usuario” sin el registro de aplicación de Azure AD correcto. En el chat de prueba, el agente hereda tu sesión. En producción, no tiene ninguna identidad, por lo que no puede acceder a ningún origen de datos que requiera permisos. Otra causa frecuente es que las conexiones de orígenes de datos, como un sitio de SharePoint o un entorno de Dataverse, se configuraron solo para el entorno de prueba y no se agregaron al ámbito de ejecución del agente publicado.
Una tercera causa es que los temas del agente o la configuración de IA generativa difieren entre el borrador y la versión publicada. Cuando publicas, Copilot Studio compila el agente. Si realizaste cambios en temas, variables o automatizaciones de Power Automate después de la última publicación, esos cambios faltan en el agente activo. El chat de prueba siempre ejecuta el borrador más reciente, por lo que funciona. El agente publicado ejecuta la última instantánea compilada, por lo que falla.
Pasos para alinear el agente publicado con los resultados del chat de prueba
- Verificar la configuración de autenticación del agente
Abre Copilot Studio. Selecciona tu agente. Ve a Configuración > Seguridad > Autenticación. Si la lista desplegable muestra “Sin autenticación”, cámbiala a “Autenticación de usuario” o “Autenticar con Microsoft Entra ID” según tu canal. Para agentes de Teams, selecciona “Autenticación de usuario”. Para sitios web personalizados, selecciona “Autenticar con Microsoft Entra ID” y proporciona el id. de cliente de un registro de aplicación de Azure AD que te pertenezca. Guarda el cambio y vuelve a publicar. - Verificar los permisos de los orígenes de datos para el agente publicado
Ve a Configuración > Orígenes de datos. Cada origen de datos que se enumera aquí debe conceder acceso a la identidad que usa el agente publicado. Si usas “Autenticación de usuario”, cada usuario final necesita al menos permiso de lectura en el sitio de SharePoint o la tabla de Dataverse. Si usas “Autenticar con Microsoft Entra ID”, el registro de aplicación de Azure AD debe tener permisos delegados para cada origen de datos. Prueba abriendo el portal de Azure, buscando tu registro de aplicación y comprobando los permisos de API. - Publicar explícitamente el borrador más reciente
En Copilot Studio, haz clic en el botón Publicar de la barra de herramientas superior. Un cuadro de diálogo muestra la fecha de la última publicación. Haz clic en Publicar de nuevo para confirmar. Espera el mensaje de confirmación “Publicado correctamente”. Luego prueba el agente activo abriendo la URL del canal o la aplicación de Teams. No confíes solo en el panel de chat de prueba: siempre ejecuta el borrador, no la versión publicada. - Probar cada canal por separado
Ve a Configuración > Canales. Selecciona el canal que estás usando: Teams, Direct Line o un canal personalizado. Cada canal tiene su propio panel de configuración. Para Teams, asegúrate de que el agente se agregue a la aplicación de Microsoft Teams correcta y de que la aplicación esté instalada en el inquilino de destino. Para Direct Line, regenera el token secreto si expiró. Prueba el agente publicado enviando un mensaje a través del canal real, no del panel de chat de prueba. - Revisar los desencadenadores y las condiciones de los temas
Abre Temas y selecciona el tema que falla en producción. Comprueba las frases de desencadenador y las condiciones. Si el tema usa variables que dependen del contexto del usuario, asegúrate de que el agente publicado pueda capturar ese contexto. Por ejemplo, si un tema usa “User.DisplayName”, el agente necesita la identidad del usuario. Con “Sin autenticación”, esta variable está vacía. Cambia el método de autenticación o elimina la dependencia de la variable. - Comprobar los flujos de Power Automate asociados al agente
Si tu agente llama a un flujo de Power Automate, abre el flujo en Power Automate. Ve a Configuración > Ejecutar solo el usuario. Si el flujo se ejecuta bajo tu cuenta, fallará para otros usuarios. Cambia el usuario de solo ejecución al propietario del flujo o usa una referencia de conexión que cada usuario pueda autenticar. Vuelve a publicar el agente después de actualizar los permisos del flujo.
Si el agente publicado sigue teniendo problemas después de la solución principal
El agente devuelve “Lo siento, no puedo responder eso” después de publicar
Esta respuesta genérica generalmente significa que el agente no puede encontrar ningún tema o contenido de IA generativa que coincida con la consulta del usuario. En el chat de prueba, el agente puede recurrir a tus propios datos de Microsoft Graph o a respuestas generativas que usan los permisos de tu cuenta. Después de publicar, esos orígenes de respuestas generativas pueden estar bloqueados. Ve a Configuración > IA generativa > Orígenes de datos. Asegúrate de que “Permitir que la IA use su propio conocimiento general” esté activado si deseas respuestas de reserva. Verifica también que los orígenes de datos enumerados en “Datos fundamentados” sean accesibles por la identidad del agente publicado.
El agente falla con errores HTTP 401 o 403 en los registros
Abre los análisis del agente en Copilot Studio. Ve a Análisis > Registros de sesión. Busca una sesión fallida y expande los detalles del error. Un error 401 significa que la autenticación falló. Un error 403 significa que la identidad carece de permisos. Vuelve a la configuración de autenticación y a los permisos de los orígenes de datos. Para un error 401, regenera el secreto o token del canal. Para un error 403, concede al registro de aplicación de Azure AD o al usuario final los permisos necesarios en el recurso de destino.
El agente funciona en el chat de prueba pero falla en la aplicación móvil de Teams
Teams móvil y Teams de escritorio usan flujos de autenticación diferentes. Es posible que la aplicación móvil no admita ciertos tipos de concesión de tokens. En Azure AD, ve a tu registro de aplicación > Autenticación. En “Aplicaciones móviles y de escritorio”, agrega el URI de redirección de Teams móvil: https://login.microsoftonline.com/common/oauth2/nativeclient. Habilita también “Permitir flujos de cliente público”. Vuelve a publicar el agente y prueba de nuevo en el dispositivo móvil.
| Elemento | Chat de prueba | Agente publicado |
|---|---|---|
| Autenticación | Usa tu identidad de Microsoft 365 con la que iniciaste sesión | Usa una identidad específica del canal (ninguna, usuario o aplicación) |
| Acceso a orígenes de datos | Usa tus permisos automáticamente | Requiere permisos explícitos para la identidad de ejecución |
| Versión del tema | Siempre ejecuta el borrador más reciente | Ejecuta la última instantánea compilada |
| Ejecuciones de Power Automate | Usa tu conexión de flujo | Usa el propietario del flujo o la referencia de conexión |
| Configuración del canal | No aplicable | Debe configurarse por canal |
Ahora puedes diagnosticar y solucionar la diferencia entre el chat de prueba de Copilot Studio y el agente publicado. Comienza verificando el método de autenticación y los permisos de los orígenes de datos. Luego vuelve a publicar explícitamente el borrador más reciente. Para problemas persistentes, examina los registros de sesión para ver los códigos de error HTTP y ajusta el registro de aplicación de Azure AD o la configuración del canal en consecuencia. Como paso avanzado, configura un intercambio de tokens de autenticación personalizado para los canales de Direct Line a fin de pasar la identidad del usuario final de forma segura.