Con el avance de la Inteligencia Artificial y la creación de agentes gracias a Copilot cada vez resulta más sencillo crear nuevos agentes dentro de una empresa. De hecho, cuando se realiza un agente sencillo desde Copilot Teams no necesitas ni conocimientos técnicos.
Cuando vemos que nuestro agente funciona, nos creamos otro y poco a poco nos vamos engachando hasta que nos metemos de cabeza en copilot studio en busca de agentes mucho más grandes. Luego cada departamento quiere su agente, Comercial quiere conectarlo con Dynamics, alguien añade Power Automate, otro necesita consultar información interna… Y casi sin darnos cuenta tenemos agentes y automatizaciones formando parte de procesos reales de negocio sin control.
La creación de agentes es maravillosa, pero ojo. Este descontrol aparece cuando cada departamento empieza a trabajar de una manera diferente. Un agente se desarrolla en un entorno controlado y otro directamente en Default. Uno utiliza una cuenta de servicio y otro las credenciales de la persona que lo creó. Algunos están perfectamente documentados y otros llevan meses publicados cuando únicamente su creador sabe cómo funcionan. Y aquí, es cuando aparece el caos.
Gobernar no significa prohibir
Cuando escuchamos gobernanza podemos pensar en restricciones, procesos, aprobaciones y alguien diciéndonos lo que no podemos hacer. Sin embargo, una buena gobernanza debería conseguir lo contrario: permitir que una empresa pueda utilizar cada vez más IA sin perder el control por el camino visto lo rápido que está avanzando.
Cuando tenemos dos agentes es fácil saber quién los ha creado, dónde están y qué información utilizan. Cuando tenemos cincuenta, la cosa cambia. Además, los agentes ya no solamente responden preguntas: pueden consultar información corporativa conectándose a Dataverse o Sharepoint, pueden ejecutar flujos como hacíamos con power automate, conectarse con otros sistemas o realizar acciones. Por eso ya no tenemos que preocuparnos únicamente de qué sabe nuestro agente, sino también de qué le estamos permitiendo hacer.
Entonces, ¿Qué tenemos que gobernar?
Desde mi punto de vista, la forma más práctica de entenderlo es pensar en todo el ciclo de vida de una solución: desde que alguien dice “ya sé que agente puedo crear” hasta que ese agente deja de utilizarse y pasa al olvido.
Antes de empezar deberíamos saber qué queremos construir, quién va a ser responsable/maker, qué información va a utilizar, qué herramientas necesita conectar y qué nivel de riesgo puede tener. Después necesitamos definir dónde vamos a desarrollar ese agente. Desde Raona, llevamos a cabo un framework para ayudar a un cliente donde planteamos una separación clara entre Desarrollo, Test y Producción, dejando el entorno Default, el cual crea Copilot por defecto y causa mucho ruido, fuera de las soluciones de negocio en producción.
También es esencial establecer reglas sobre los datos que se van a tratar. No es lo mismo trabajar con información pública que con documentación interna o confidencial. Aquí entra un principio fundamental: mínimo privilegio. Cada agente, flujo o aplicación debería acceder únicamente a aquello que realmente necesita respetando los permisos en cada caso.
Y cuidado con las acciones que realizan los agentes. Consultar un contrato no tiene el mismo riesgo que modificarlo. Saber cuántos días de vacaciones me quedan no es lo mismo que solicitarlas o aprobarlas. Cuanto mayor sea el impacto de una acción, mayor debería ser también el control, la trazabilidad y, cuando sea necesario, la supervisión humana. No queremos que el agente se conecte a nuestro escritorio y nos borre esa carpeta que pone “Documentos importantes NO BORRAR”.
Un ciclo de vida real
Este proceso tampoco debería depender únicamente de un maker que se encargue del agente. No se trata solamente de exportar, importar, cambiar una conexión y cruzar los dedos a la hora de trabajar con las soluciones de los agentes. Va más allá y por eso planteamos un flujo Dev → Test → Prod, utilizando pipelines, aprobaciones, variables de entorno, referencias de conexión y trazabilidad de los despliegues. De esta forma nos aseguramos un mayor control de todo el proceso.
Además, publicar no es el final. Tenemos que saber qué soluciones existen, quién responde por ellas, si se siguen utilizando, cuánto consumen y cuándo deberían retirarse. Por eso el framework que hemos realizado a nuestros clientes, incluye un inventario centralizado de agentes, aplicaciones y automatizaciones, además de mecanismos de monitorización y control de consumo.
Nuestro Framework: unas reglas del juego comunes
En Raona trabajamos continuamente en la evolución de nuestro Framework de Gobernanza de IA y Power Platform, incorporando las últimas novedades y los aprendizajes obtenidos en nuestros proyectos.
Nuestro enfoque comienza con un análisis inicial del estado de cada organización, identificando las soluciones existentes, su nivel de madurez, los controles actuales y las necesidades de mejora. Porque no todas las empresas parten del mismo punto ni necesitan las mismas reglas.
La idea no es entregar un documento enorme lleno de normas que termine olvidado en una biblioteca de SharePoint, sino ayudar a cada organización a definir sus propias reglas del juego: cómo se propone una iniciativa, quién es responsable, cómo se clasifica según su criticidad, qué información puede utilizar, qué controles necesita y cómo se gestiona durante todo su ciclo de vida.
Nuestro objetivo es convertir esas reglas en procesos y herramientas reales: inventarios, estrategias de entornos, políticas de seguridad y DLP, procesos de aprobación, monitorización y checklists que permitan evaluar cada iniciativa según su nivel de riesgo.
Y no nos olvidamos de algo fundamental: acompañar a quienes desarrollan las soluciones. Además de establecer normas, proporcionamos buenas prácticas y recomendaciones basadas en nuestra experiencia para que los makers sepan cómo hacer las cosas bien y puedan anticiparse a problemas habituales.
Porque gobernar la IA no significa frenar la innovación, sino darle una estructura que le permita crecer de forma segura y sostenible.
Regalo práctico: 10 tips para no pelearte con el grounding de Copilot Studio
Y precisamente porque creemos que la gobernanza también consiste en ayudar a hacer las cosas bien, queremos compartir uno de esos aprendizajes prácticos. Un problema con el que nos hemos encontrado trabajando con Copilot Studio y que demuestra que, a veces, la solución no está en seguir modificando el agente, sino en entender cómo funciona.
Y es aquí cuando ocurre una de las escenas más típicas cuando montas un agente en Copilot Studio: Empiezas creando tu agente, conectas SharePoint como fuente de conocimiento, empiezas a hacer pruebas y llega ese momento en el que preguntas algo que sabes perfectamente que está documentado. Y Copilot te dice que no encuentra la información. Vas a SharePoint. Buscas el documento. Está ahí. Lo abres y, efectivamente, la respuesta también está ahí.
Mi primera reacción fue tocar el prompt. Cambiar las instrucciones, añadir más contexto, decirle dónde buscar, especificar que utilice la documentación de SharePoint… Hasta que empecé a darme cuenta de que, aunque siguiese modificando el prompt, el resultado no cambiaba. Porque a veces el problema no está ahí, sino en qué información está recuperando realmente el agente y con qué información está construyendo la respuesta: el grounding.
Después de pelearme unas cuantas veces con este tema, investigar la documentación de Microsoft y ver que son problemas bastante habituales, he recopilado algunos de los errores que más merece la pena revisar cuando utilizamos SharePoint como conocimiento en Copilot Studio. Algunos parecen bastante obvios peor ocurren más veces de las que pensamos.
- Versiones. Evita tener cinco versiones activas de un mismo documento y esperar que Copilot adivine cuál es la buena.
- Información obsoleta. Si no quieres que responda con un documento de 2009, revisa por qué sigue disponible dentro de tus fuentes de información y porque no ha sido actualizado.
- Permisos Si a ti te funciona y a tu compañero no, antes de cambiar el prompt comprueba qué puede ver realmente ese usuario.
- Nombres con sentido. Politica_Vacaciones_España_2026.docx aporta bastante más contexto que Documento1_FINAL_v2.docx.
- Metadatos. País, departamento, categoría, estado o vigencia siguen siendo importantes, aunque ahora tengamos IA.
- Buena estructura. Usa títulos claros, apartados coherentes y contenido que pueda entenderse sin tener al autor sentado al lado.
- Los “por si acaso”. Más información no significa automáticamente mejores respuestas. Al contrario, dale al agente el conocimiento que realmente necesita.
- Preguntas reales. No utilices solamente esas cinco preguntas que ya sabes que funcionan. Tienes que ir más allá y meterte en la piel de los usuarios reales.
- Copilot no es Marie Kondo. Cuanto mejor esté organizada y clasificada la documentación, mejor filtro y respuesta recibirás por parte del agente. Tener el cajón desastre bien organizado es básico para obtener lo que andamos buscando.
- Actualización. SharePoint cambia, las políticas cambian y aparecen nuevas versiones. El mantenimiento del conocimiento también forma parte del mantenimiento del agente.
En definitiva
Al final necesitamos las dos cosas. La gobernanza nos ayuda a definir las reglas: qué podemos hacer, quién es responsable, qué información utilizamos, cómo llegamos a producción y cómo mantenemos el control. Las buenas prácticas ayudan a nuestros equipos a trabajar bien dentro de esas reglas.
Porque conseguir que funcione nuestro primer agente es maravillo. Pero conseguir que podamos tener muchos agentes sin perder el control por el camino es donde empieza realmente la gobernanza.
