La respuesta corta
Antes de compartir un agente interno, revisa el trabajo que debe resolver, las fuentes que necesita, las acciones que puede ejecutar y la persona que responde por el resultado. Después, publícalo primero para un grupo delimitado y recoge incidencias antes de abrirlo a toda la organización.
Microsoft documenta un flujo de solicitud y aprobación para agentes disponibles en el catálogo interno de Microsoft 365 Copilot. Esa capacidad no sustituye la revisión operativa de la empresa: solo crea un punto claro para decidir qué agentes pueden distribuirse y bajo qué condiciones.
- Objetivo y usuarios definidos.
- Fuentes, acciones y permisos revisados.
- Propietario funcional y propietario técnico identificados.
- Prueba limitada y criterio de retirada preparados.
Qué ha cambiado y por qué importa
Las notas de versión de Microsoft 365 Copilot publicadas el 15 de julio de 2026 incluyen la posibilidad de enviar al Agent Store de la organización un agente creado con Agent Builder, sujeto a revisión y aprobación en el centro de administración. La documentación del Agent Store explica que un agente solicitado no es visible para los usuarios hasta que un administrador lo revisa y publica.
Para una empresa, este paso es valioso si se convierte en una decisión repetible. Cuando alguien crea un agente para resumir expedientes, preparar respuestas o consultar una biblioteca interna, el equipo necesita saber si el alcance real coincide con el caso de uso aprobado. Compartir sin ese control puede convertir una prueba individual en una dependencia de muchas personas sin propietario claro.
- La novedad es una vía de distribución gobernada, no una garantía de que todo agente sea seguro o adecuado.
- Las pantallas y permisos pueden variar según licencia, tenant y configuración; compruébalos en el entorno propio.
- La revisión debe concentrarse en el comportamiento y los accesos, no solo en el nombre o la descripción.
Paso 1: convertir la idea en un encargo verificable
No envíes a aprobación un agente cuyo propósito sea simplemente “ayudar al equipo”. Describe una tarea reconocible, una entrada habitual y una salida que una persona pueda comprobar. Por ejemplo, preparar un borrador de respuesta a un ticket a partir de una base de conocimiento autorizada. Evita mezclar en el primer despliegue búsqueda, decisión, envío y actualización de sistemas.
El encargo también debe indicar lo que el agente no hace. Si no decide descuentos, no envía comunicaciones externas o no consulta datos de recursos humanos, escríbelo. Esos límites permiten que quien revisa detecte si las instrucciones, el conocimiento o las acciones configuradas se apartan del uso previsto.
- Usuario y equipo destinatario.
- Problema concreto y resultado esperado.
- Entradas permitidas y fuentes autorizadas.
- Decisiones que siguen siendo humanas.
- Situaciones en las que debe escalar o detenerse.
Paso 2: revisar datos, conocimiento y acciones
La documentación de Microsoft para el Agent Store indica que la revisión administrativa puede incluir capacidades, conocimiento, acciones y acceso a datos. Usa esa información como una lista mínima de preguntas. No basta con que el agente responda bien a una demostración: hay que entender de dónde procede el contenido y qué puede hacer cuando una respuesta parece suficiente.
Separa lectura y escritura. Un agente que consulta una biblioteca de procedimientos no necesita, por defecto, crear registros, enviar correos o modificar un CRM. Si una acción de escritura es necesaria, define el evento que la autoriza, el resultado esperado y cómo se revierte un error.
- Confirmar que cada fuente tiene propietario y es adecuada para el equipo destinatario.
- Eliminar fuentes históricas, duplicadas o demasiado amplias que no aportan al caso de uso.
- Enumerar las acciones que el agente puede invocar y las que tiene prohibidas.
- Comprobar qué identidad y permisos usa cada conector.
- Definir una forma rápida de retirar el acceso si aparece una incidencia.
Paso 3: decidir quién aprueba y quién mantiene
Microsoft señala que los administradores pueden publicar, desplegar, bloquear o retirar agentes en el centro de administración. Esa capacidad técnica debe acompañarse de responsabilidades de negocio. El administrador puede comprobar configuración y acceso, pero la persona responsable del proceso debe validar si la salida es útil, si las excepciones están bien tratadas y si el agente sigue teniendo sentido cuando cambian las reglas de trabajo.
Para una pyme, dos nombres suelen ser suficientes al principio: un responsable funcional que acepta el caso de uso y un responsable técnico que mantiene fuentes, permisos y configuración. Si la tarea afecta a clientes, contratos, personal o decisiones económicas, añade la revisión de la función que asume ese riesgo.
- Creador: explica el objetivo, límites y ejemplos de prueba.
- Responsable funcional: valida calidad, excepciones y utilidad en el proceso.
- Responsable técnico o administrador: revisa acceso, conectores y ciclo de vida.
- Aprobador adicional cuando el caso de uso afecta a datos o decisiones sensibles.
Paso 4: probar con un grupo pequeño antes de abrir el catálogo
Una aprobación no debería ser el final de la validación. Empieza con personas que conozcan el proceso y puedan identificar errores de contexto. Pídeles casos reales permitidos, no solo preguntas ideales. Registra cuándo el agente no encuentra una fuente, propone una respuesta incompleta o intenta salir del alcance acordado.
La prueba también ayuda a decidir el acceso. Puede ser más prudente asignar el agente a un grupo concreto que hacerlo visible para toda la organización. Microsoft permite gestionar disponibilidad y asignación; aprovecha esa capacidad para convertir el despliegue inicial en una etapa reversible.
- Grupo inicial con experiencia en el proceso.
- Muestra de casos normales y excepciones conocidas.
- Registro sencillo de salidas aceptadas, corregidas y rechazadas.
- Canal para comunicar fallos y responsable de responderlos.
- Fecha de revisión antes de ampliar el acceso.
La decisión de publicación
Publica el agente solo si la tarea, los datos y las acciones siguen alineados con la solicitud aprobada. Si el piloto revela que necesita demasiadas excepciones, una fuente no está preparada o nadie puede mantenerlo, aplaza la distribución y corrige el diseño. Rechazar o retirar un agente no es un fracaso: evita que una automatización inmadura se convierta en una regla de trabajo no documentada.
Cuando el agente se publique, conserva una ficha breve con propósito, usuarios, fuentes, acciones, responsables, fecha de revisión y forma de retirada. Esa ficha hace que el catálogo interno sea un inventario gestionable y no una colección de herramientas difíciles de explicar.
- Publicar: utilidad comprobada, acceso proporcionado y responsables claros.
- Ajustar: el caso tiene valor, pero faltan datos, instrucciones o formación.
- Limitar: funciona solo para un equipo o una categoría concreta de tareas.
- Retirar o rechazar: el riesgo, el mantenimiento o la falta de evidencia no justifican su distribución.
