Agentes de Copilot Studio

Lanzas tu primer agente de Copilot Studio y, en lugar de impresionar, responde con un «creo que la política dice, tal vez…». Es un error típico de principiante, y tiene arreglo: con instrucciones claras y una fuente de conocimiento real, el mismo bot puede citar el documento de políticas auténtico. Este artículo explica cómo reproducir una mala respuesta en el panel de prueba, corregirla y publicar un piloto funcional.

Repasamos cuatro frentes: por qué un bot que brilla en pruebas falla con usuarios reales, cómo fundamentarlo (grounding), cómo darle personalidad y cómo depurarlo y publicarlo sin sorpresas.

Por qué un bot perfecto en el panel de prueba falla en el mundo real

El panel de prueba de Copilot Studio es un entorno protegido y educado. Las preguntas son cortas, están bien redactadas y suelen parecerse a los ejemplos que preparaste. Al pasar a producción, la gente escribe como gente: un directivo pregunta cuánto puede reclamar, otro escribe «límite de gastos de hotel» con una errata y un tercero pide que le recuerden «lo del dinero para viajes». Todo significa lo mismo, pero si solo probaste «¿cuál es el límite de gastos?», el bot no siempre conectará los puntos.

Prueba tres variaciones

Para ver esa brecha ahora mismo, lanza tres versiones de la misma pregunta en el panel de prueba:

• la versión limpia,
• una reescritura informal,
• una versión con error tipográfico.

A veces el bot acierta las tres y a veces solo funciona la limpia. Esa es la primera pista de que unos resultados de prueba bonitos no garantizan que el bot funcione en la realidad.

Cobertura de intenciones y diferencias entre canales

La causa técnica es la cobertura de intenciones. Los bots dependen de frases de activación y definiciones de temas; si todos tus ejemplos se parecen, el modelo se vuelve frágil y un simple sinónimo puede desorientarlo. La solución es poco glamurosa, pero eficaz: añade frases de activación más amplias, no solo la redacción formal de tus documentos de política. Incluye frases informales, abreviaturas y formulaciones algo desordenadas. No hacen falta docenas, solo las suficientes para cubrir las variaciones obvias, y después hay que probar.

Los canales complican aún más las cosas. El panel de prueba es una simulación; al publicar en Teams, SharePoint o un sitio web de demostración, la plataforma puede cambiar cómo se maneja el texto o cómo se muestran las respuestas. Teams puede dividir las líneas de otra manera, una página web puede eliminar el formato y hasta mover una frase clave a otra línea puede alterar cómo la pondera el modelo. Por eso conviene probar de forma iterativa en cada canal.

Un ejemplo: en Studio preguntas «¿cuál es el límite de gastos?» y el bot responde que la política fija 200 dólares por día de alojamiento. Después preguntas «oye, ¿cuánto puedo recuperar por un hotel?» y, en vez de citar la política, sugiere consultar con recursos humanos o hace una suposición imprecisa. Misma intención, resultado distinto. Trata Studio como un entrenamiento: sirve para aprender, pero no demuestra que el bot esté listo.

Grounding en Copilot Studio: no dejes a tu agente sin fundamento

El primer error de novato es tratar a Copilot Studio como una bola de cristal en lugar de un manual de reglas. Un agente sin conocimiento real detrás es como un becario enviado a la sala de juntas sin preparación: habla rápido, suena seguro y la mitad de lo que dice se desmorona en cuanto alguien lo verifica. Un bot sin fundamento sigue patrones de texto, no hechos.

El riesgo de las alucinaciones

Lo peor no son las respuestas débiles, sino las alucinaciones: el bot inventa algo que parece correcto pero no tiene base real. Preguntas por reembolsos de viaje y, en lugar de declinar con cortesía, inventa una cifra verosímil. Un empleado reserva un hotel basándose en ella y acaba metido en disputas de gastos. La frase parecía profesional, pero el contenido era humo.

En el ejercicio práctico oficial se sube un archivo llamado expensespolicy.docx, que indica con claridad un límite de alojamiento de 200 dólares por noche. Sin ese fundamento, el bot puede responder con total seguridad «100 dólares por noche», una cifra fabricada. Con el archivo adjunto, deja de improvisar y cita la política: el alojamiento está limitado a 200 dólares por día.

Cómo añadir conocimiento paso a paso

1. Abre tu agente en Copilot Studio y, en la pantalla de información general, ve a la sección de conocimiento.
2. Selecciona «Añadir conocimiento» y elige subir un archivo.
3. Apunta al documento de políticas u otra fuente de confianza. También puedes conectar un sitio web público o una ubicación de SharePoint, pero los archivos son más limpios.
4. Espera a que termine la indexación, que puede tardar 10 minutos o más. No te alarmes si las primeras consultas no extraen la información.
5. Repite la prueba. Si todo está bien, verás la respuesta real junto con una pequeña cita que indica que procede de tu documento.

Esa cita es la señal de que el grounding funciona.

Una idea errónea habitual

Muchos creen que el refuerzo conversacional cubrirá las lagunas por arte de magia. No es así: solo amplifica patrones de texto y, sin una fuente que lo ancle, rellena con generalidades. Además, si no encuentra coincidencias en tu base de conocimiento, puede recurrir al conocimiento general del modelo y dar respuestas vagas o inexactas. Por eso conviene configurar los temas críticos para que busquen solo en las fuentes añadidas cuando la precisión sea fundamental, sobre todo en cumplimiento, finanzas o recursos humanos.

Persona del agente: nombre, descripción, instrucciones y tono

Una vez que el bot dice la verdad, toca darle voz. En Copilot Studio la personalidad no viene incluida: se define en los campos de nombre, descripción e instrucciones de la página de descripción general. Si los dejas en blanco, obtienes un saludo insípido, sin autoridad ni contexto, y en áreas como recursos humanos o finanzas un tono genérico hace pensar a la gente que está probando un prototipo y no una herramienta fiable. Si pierdes a los usuarios en el primer contacto, rara vez vuelven.

Límites y contenido de cada campo

• Nombre: hasta 30 caracteres. Mantenlo corto y directo, por ejemplo «Experto en políticas de gastos» o «Guía de viajes».
• Descripción: unos mil caracteres, suficientes para un par de frases claras. Por ejemplo: el agente ofrece a los empleados respuestas actualizadas de la política oficial de viajes, cita los pasajes pertinentes y evita especulaciones.
• Instrucciones: hasta 8.000 caracteres. Aquí van las reglas de trabajo: citar siempre la línea de política cuando exista, evitar respuestas especulativas, resumir en una frase clara para los ejecutivos y luego aportar la cita.

Una lista de comprobación sencilla: pon nombre al rol, escribe una descripción breve de su especialidad, define el tono (formal, casual o simple para personas sin conocimientos técnicos) y llena las instrucciones con reglas de comportamiento sobre qué incluir, qué evitar y cómo dar formato. Puedes guiar el tono con expresiones como «formal y profesional» o «casual y fácil de entender», e incluso añadir ejemplos directamente en las instrucciones.

Dos ajustes rápidos

Ambos llevan menos de cinco minutos. El primero es editar el tema de inicio de conversación: sustituye la bienvenida prefabricada por una introducción propia de tu rol, como «Estoy aquí para ayudarte a entender la política de viajes y citar el documento oficial cuando sea posible». El segundo es cambiar el icono: se admite un PNG de hasta 192 por 192 píxeles y menos de 30 kilobytes. Un logotipo sencillo evita la sensación de demo desde la primera respuesta.

No son un acabado opcional, sino una armadura básica. Una bienvenida que menciona la función orienta al usuario hacia preguntas relevantes, las reglas de tono evitan explicaciones demasiado largas y unas instrucciones precisas alejan a la IA del relleno. El resultado son menos tickets del tipo «no entiendo», sin necesidad de nuevos conectores ni plugins.

Depurar errores en tiempo real: reproducir, corregir y repetir

La prueba real empieza cuando el bot falla o acierta en situaciones reales. En ese momento hay que leer lo que ocurrió en lugar de rendirse tras la primera mala respuesta. La rutina de depuración tiene cinco pasos:

1. Reproduce en el panel de prueba la consulta exacta que falló, con las mismas palabras del usuario.
2. Reinicia la conversación con el icono de actualizar o nuevo chat; empezar de cero es fundamental.
3. Abre los temas y comprueba cuál se activó. Si no fue uno tuyo sino el tema de refuerzo conversacional del sistema, el bot dependió del modelo y no de tu conocimiento.
4. En ese caso, verifica que tu archivo o sitio esté cargado e indexado. Sin índice no hay base de conocimiento.
5. Edita las instrucciones o el contenido del tema, guarda y vuelve a ejecutar exactamente la misma consulta.

Crear un tema desde una descripción

A veces el problema no es el tono sino la falta de estructura. En la página de temas existe la opción de añadir desde una descripción con Copilot: describes lo que necesitas, por ejemplo responder directamente cuando pregunten por límites de gastos, y el sistema redacta un árbol de nodos. Es útil cuando el bot sigue ignorando la misma pregunta básica.

Pruebas A/B de tono y comprobaciones de conocimiento

Puedes hacer experimentos de unos 10 minutos. Escribe una variante A de las instrucciones con lenguaje formal de políticas corporativas y pregunta por el límite de gastos de viaje; anota la respuesta. Cambia después a una variante B, una guía de RR. HH. amable que explica de forma sencilla y cita las normas, y repite la pregunta. Con ambos registros decides el tono según la evidencia y no por intuición.

Si un evaluador pregunta qué puede declarar como gasto de hotel y el bot responde con vaguedades, no es un fracaso total: quizá el documento aún no está indexado o tus frases de activación no incluyen «hotel». Revisa en la pestaña de conocimiento que el archivo esté activo, añade «gastos de hotel» como frase de activación en tu tema de viaje y vuelve a ejecutar. Si ahora responde que, según la política, el alojamiento tiene un límite de 200 dólares por noche, el error está corregido.

Un último truco: los iniciadores de conversación. Un cuadro de texto vacío paraliza a los usuarios, así que puedes preconfigurar de 3 a 5 sugerencias en la página de descripción general, como «¿Cuál es el límite de hotel?», «¿Cómo presento una reclamación de viaje?» o «¿Qué comidas se reembolsan?». Así pruebas rutas reales más rápido y el usuario percibe que el bot conoce su función antes de escribir.

Publicar en Teams, SharePoint o web: sorpresas de canal y piloto cerrado

Publicar no es solo un clic: decide quién accede a tu agente, cómo entra y cómo se ven las respuestas. Cada canal tiene sus peculiaridades. Una respuesta clara en Studio puede verse distinta o fallar en Teams, porque este ajusta el texto y gestiona los metadatos a su manera. SharePoint hace lo propio con el interlineado, y el sitio web de demostración, aun siendo el más simple, puede mostrar el formato de otro modo. Cada destino es una arena distinta y se prueba por separado.

Lista de comprobación antes de publicar

1. Confirma que los archivos de conocimiento estén totalmente indexados; si acabas de subirlos, quizá aún no estén listos para respuestas en vivo.
2. Configura la autenticación. Para una demostración amplia, elige «sin autenticación» para que cualquiera con el enlace pueda probarlo.
3. Pulsa publicar y comprueba el banner de confirmación verde o la actualización de estado en la página de canales.
4. Abre la configuración del canal del sitio web de demostración y actualiza el mensaje de bienvenida y los iniciadores de conversación.
5. Realiza una prueba piloto cerrada; no difundas el bot a todo el inquilino todavía.

El piloto cerrado y la telemetría

Un grupo pequeño con instrucciones claras es más inteligente que un lanzamiento total. Pide a esas personas que usen lenguaje informal, escriban con erratas e incluso suban archivos cuando tenga sentido: sus errores revelan los puntos débiles. Repite en cada canal de destino los escenarios que probaste en Studio (consultas formales, frases informales, erratas y citas fundamentadas) y comprueba si Teams los procesa bien, cómo queda el espaciado en SharePoint y si la demo web sigue mostrando la cita de la fuente.

Tras publicar, los datos de uso empiezan a fluir. El centro de administración de Power Platform y sus análisis integrados muestran cifras de adopción, recuento de errores y las conversaciones que no lograron activar un tema. No se publica una vez y se olvida: se vigilan esos registros para asegurar que el bot se usa bien y no genera tickets de soporte.

Errores frecuentes y trampas de principiante

• Confiar en una prueba impecable en Studio: las entradas ordenadas dan una falsa seguridad que la primera consulta casual de un usuario rompe.
• Probar solo una formulación: sin sinónimos, frases informales y erratas, el bot se vuelve frágil.
• Omitir el grounding: sin fuente de conocimiento, el bot farolea e inventa límites y reglas.
• Esperar que el refuerzo conversacional lo arregle todo: no aporta conocimiento de política; solo amplifica patrones de texto.
• Dejar nombre, descripción e instrucciones por defecto: el resultado es un tono genérico que resta confianza.
• Ignorar los resultados fallidos: asumir que la próxima ejecución saldrá bien genera tickets y desconfianza.
• Publicar y dar el trabajo por terminado: sin pruebas por canal, piloto y telemetría, los problemas los descubren los usuarios.

Claves prácticas y conclusión

• Prueba cada pregunta clave en tres versiones: limpia, informal y con errata.
• Amplía las frases de activación con sinónimos, abreviaturas y lenguaje cotidiano.
• Sube documentos reales o conecta fuentes fiables y espera a que termine la indexación antes de probar.
• Comprueba que las respuestas incluyan la cita del documento y limita los temas críticos a tus fuentes.
• Define nombre (hasta 30 caracteres), descripción, tono e instrucciones (hasta 8.000 caracteres), y personaliza la bienvenida y el icono.
• Depura en ciclo: reproduce, reinicia, revisa el tema activado, verifica el índice, corrige y repite.
• Añade de 3 a 5 iniciadores de conversación.
• Antes de publicar, confirma indexación, autenticación y estado de publicación, y haz un piloto cerrado.
• Repite las pruebas en cada canal y vigila los análisis tras el lanzamiento.

Conclusión

Tres cosas convierten un agente de Copilot Studio inestable en uno fiable: fundamentarlo con documentos reales para que deje de adivinar, darle una personalidad definida con nombre, descripción, tono e instrucciones, y no fiarse de una prueba impecable, sino probar en el panel, hacer un piloto cerrado, publicar y monitorizar. Publicar no es el final del trabajo, sino el comienzo de un ciclo de ajuste continuo. Así tu bot se gana la confianza de los usuarios en lugar de generar tickets.