Serie: Gobernando Agentes de IA en Microsoft 365 — Parte 5 de 5. Este artículo final cubre la gobernabilidad por diseño — las decisiones de diseño y ALM que determinan cuánto esfuerzo de gobernanza será necesario una vez que un agente esté desplegado. La Parte 4 cubre la capa de gobernanza de proceso.
Esta parte final pasa de la gobernanza operativa a la gobernanza en tiempo de diseño — las decisiones tomadas antes de desplegar un agente que determinan cuánto esfuerzo de gobernanza será necesario después.
Los cuatro artículos anteriores han cubierto las capas de gobernanza que se aplican a los agentes una vez que existen: DLP de Power Platform, Purview, Agent 365 y el marco de proceso para la propiedad y la responsabilidad. Esas capas gobiernan los agentes en operación. Este artículo trabaja en una etapa anterior — las decisiones de diseño y entorno que determinan lo gobernable que será un agente antes de que llegue al proceso de aprobación.
A lo largo de esta serie, 'agente' se refiere a los agentes de IA construidos en Microsoft Copilot Studio o a través de las capacidades de agentes de Microsoft 365, con una gobernanza que abarca Power Platform, Entra, Purview y las superficies de administración de Microsoft 365. Las herramientas referenciadas — Copilot Studio, Agent 365, Entra Agent ID — son capacidades distintas dentro del ecosistema, no términos intercambiables.
La gobernanza es considerablemente más fácil cuando está integrada en cómo se desarrollan y estructuran los agentes. Un agente construido sin pensar en la gestión del ciclo de vida, el empaquetado de soluciones o el diseño de las fuentes de conocimiento será más difícil de revisar, más difícil de mantener y más difícil de retirar. Un agente construido con la gobernanza en mente es más fácil de aprobar, más fácil de auditar y más fácil de traspasar.
Estrategia de Entornos para el Desarrollo de Agentes
La estrategia de entornos se introdujo en la Parte 1 en el contexto del alcance de las políticas DLP. Aquí el foco está en las implicaciones del ciclo de vida y ALM — cómo los entornos estructuran el desarrollo, la revisión y la promoción de los agentes hasta producción, y cómo esa estructura reduce el riesgo de gobernanza antes de que se acumule.
Un enfoque de entornos estructurado proporciona puntos de control de gobernanza que no existen en un modelo de entorno único. La estructura básica:
Entorno de desarrollo
Donde los creadores construyen y prueban los agentes. Las políticas DLP pueden permitir un acceso a conectores más permisivo para apoyar el desarrollo, pero deben restringir la publicación en los canales de producción. Los agentes en este entorno no son accesibles para los usuarios finales. El entorno de desarrollo es donde ocurre la experimentación sin riesgo de gobernanza.
Entorno de test/UAT
Donde se revisan los agentes antes de la promoción. Las políticas DLP deben reflejar las de producción. Este es el punto de control de gobernanza: se asigna la propiedad, se revisan las fuentes de conocimiento, se valida el comportamiento del agente según su propósito declarado y se crea la entrada en el registro de agentes. Ningún agente debería promoverse a producción sin pasar por esta etapa.
Entorno de producción
Donde los usuarios finales interactúan con los agentes. Se aplican las políticas DLP más restrictivas. Los agentes llegan a este entorno sólo a través del proceso de promoción definido — no mediante el despliegue directo por parte de los creadores.
El valor de esta estructura desde una perspectiva de gobernanza es que convierte el proceso de aprobación en una parte natural del flujo de trabajo de desarrollo en lugar de una ocurrencia de último momento. El entorno de pruebas es donde ocurre la revisión de gobernanza, y la promoción a producción es la señal técnica de que se ha completado la aprobación.
Gestión de Soluciones y ALM
Los agentes deberían empaquetarse en soluciones de Power Platform en lugar de desplegarse como componentes no gestionados. Esto tiene implicaciones directas de gobernanza.
Soluciones gestionadas vs. no gestionadas
Las soluciones no gestionadas en entornos de producción permiten la modificación directa de los componentes, lo que dificulta el seguimiento de cambios y crea un riesgo de gobernanza. Las soluciones gestionadas en producción restringen la modificación directa, asegurando que los cambios pasen por el pipeline de desarrollo → test → producción. Este es el patrón de ALM (Application Lifecycle Management) que recomienda la documentación de gobernanza de Power Platform, y se aplica igualmente a los agentes.
Control de versiones
Las soluciones deberían almacenarse en control de versiones (Azure DevOps o GitHub). Esto crea un historial de versiones de la configuración del agente — sus instrucciones, conexiones de fuentes de conocimiento y configuración de acciones — que respalda los requisitos de rastro de auditoría del marco de gobernanza.
Variables de entorno
Los agentes que se conectan a sitios de SharePoint o endpoints externos deberían usar variables de entorno para esas conexiones en lugar de URLs codificadas. Esto facilita la promoción de un agente de test a producción sin modificar el agente en sí — la variable de entorno cambia, la configuración del agente se mantiene igual. También hace que las conexiones de fuentes de conocimiento sean visibles y auditables a nivel de solución.
Referencias de conexión
Del mismo modo, las conexiones de conectores deberían usar referencias de conexión en lugar de credenciales incrustadas. Esto garantiza que la gobernanza de las conexiones (quién tiene acceso a qué) se gestione de forma coherente en lugar de quedar incrustada de forma invisible en configuraciones individuales de agentes.
Diseño de Fuentes de Conocimiento y Gobernanza
Cómo se diseñan las fuentes de conocimiento de un agente tiene un impacto significativo en lo gobernable que es. Las fuentes de conocimiento con un alcance deficiente son una de las causas más comunes de problemas de gobernanza — agentes que muestran contenido que no deberían, devuelven resultados inconsistentes cuando cambia el contenido, o se vuelven poco fiables cuando se reorganiza la estructura del sitio.
Definir el alcance de las fuentes de conocimiento explícitamente
Los agentes deberían conectarse a los sitios de SharePoint, bibliotecas o conjuntos de documentos específicos que necesitan, no a colecciones de sitios amplias o a todo el tenant. Un alcance amplio significa que el comportamiento del agente es más difícil de predecir y más difícil de revisar.
Documentar las fuentes de conocimiento en el registro de agentes
La entrada del registro debería listar las URLs específicas de SharePoint y cualquier fuente externa de la que el agente extrae conocimiento. Esto permite revisar la actualidad de las fuentes de conocimiento durante el ciclo de revisión sin tener que abrir la configuración del agente.
Considerar la cobertura de etiquetas de sensibilidad
Como se cubrió en la Parte 2, las políticas DLP de Purview pueden restringir cómo se procesa el contenido etiquetado en las respuestas de IA. Para los agentes que acceden a áreas de contenido con clasificación de sensibilidad mixta, vale la pena confirmar que la cobertura de etiquetas es suficientemente coherente como para funcionar como un control de gobernanza fiable. Las brechas en el etiquetado son brechas en la gobernanza del contenido de IA.
Planificar para los cambios estructurales
Las estructuras de los sitios de SharePoint cambian. Las bibliotecas se reorganizan. Los tipos de contenido se actualizan. Los propietarios de los agentes deberían ser notificados cuando los cambios afecten a los sitios o bibliotecas de los que dependen sus agentes. Es un punto del proceso de gobernanza, pero merece atención en el nivel del diseño de las fuentes de conocimiento — usar columnas de sitio y tipos de contenido como base para el alcance de las fuentes de conocimiento es más resiliente que el acceso basado en rutas de carpetas.
Las Instrucciones del Agente y el Archivo SharePoint.md
Para los agentes desplegados en SharePoint, el archivo SharePoint.md puede actuar como un control de gobernanza ligero tanto como una herramienta de configuración. Como se cubrió en el artículo sobre gobernanza de Copilot en SharePoint de esta serie, el archivo SharePoint.md se carga automáticamente en cada chat de Copilot del sitio y le indica al agente qué reglas aplicar.
En la mayoría de las organizaciones comenzará como un patrón de configuración más que como un artefacto formalmente gobernado — pero con el tiempo, a medida que los agentes se integran más en los procesos de negocio, las instrucciones que contiene se convierten en la práctica en decisiones de gobernanza.
Desde una perspectiva de gobernanza de diseño:
- Las instrucciones del agente en el SharePoint.md deberían tratarse como documentos de política del sitio — con propietario, versión y revisión periódica
- Sólo los propietarios del sitio deberían tener permiso para editar el SharePoint.md, no los miembros generales del sitio
- Los cambios en el SharePoint.md deberían tratarse como cambios de configuración del agente y estar sujetos al mismo proceso de gestión de cambios
- El contenido del SharePoint.md debería documentarse en el registro de agentes como parte de la especificación del agente
Un SharePoint.md que se escribió una vez en el despliegue y nunca se revisó es una brecha de gobernanza. Las instrucciones que contiene definen cómo se comporta el agente para cada usuario del sitio — merecen la misma atención que la configuración formal del agente.
Pruebas Antes de la Aprobación
El entorno de pruebas es el punto de control de gobernanza, y las pruebas son lo que hace que la decisión de aprobación sea significativa. Un agente que no ha sido probado sistemáticamente no puede aprobarse con confianza.
El mínimo de pruebas antes de que un agente llegue a la etapa de aprobación:
Pruebas funcionales
¿El agente hace lo que se describe que hace? Probar los casos de uso principales para los que fue construido, incluidos los casos límite y las entradas inusuales.
Pruebas de fuentes de conocimiento
¿El agente devuelve resultados precisos de sus fuentes de conocimiento? ¿Hay áreas de contenido a las que no debería acceder que aparecen en las respuestas?
Pruebas de sensibilidad
Para los agentes que acceden a contenido con etiquetas de sensibilidad, probar que los controles DLP de Purview funcionan como se espera — el contenido etiquetado restringido de las respuestas donde la política lo requiere.
Pruebas del límite del alcance
¿Qué ocurre cuando un usuario hace al agente algo fuera de su alcance previsto? ¿Maneja las preguntas fuera del alcance de forma adecuada, o intenta responder usando contenido que no debería?
Pruebas de regresión
Las pruebas no son una actividad puntual. Cuando cambian las fuentes de conocimiento, las instrucciones del agente o los conectores, las pruebas de referencia deben repetirse para confirmar que el agente sigue comportándose como se espera. Los problemas de gobernanza suelen surgir después de los cambios, no en el despliegue inicial.
Para las organizaciones que necesitan una validación más estructurada a escala, el Power CAT Copilot Studio Kit — un conjunto de herramientas del equipo de asesoramiento al cliente de Microsoft para Power Platform — puede proporcionar capacidades adicionales de prueba y evaluación de prompts que pueden incorporarse a la etapa de revisión del entorno de pruebas.
La Gobernanza de Diseño como Reducción del Riesgo
El marco de gobernanza descrito a lo largo de esta serie tiene dos modos: preventivo y reactivo. Los controles técnicos (DLP, Purview, Agent 365) son en parte preventivos y en parte reactivos — establecen límites y detectan cuando las cosas van mal. La capa de gobernanza de proceso (propiedad, registro, ciclos de revisión) es en parte preventiva y en parte correctiva — detecta la degradación antes de que se convierta en un problema para el usuario.
La gobernanza de diseño es principalmente preventiva. Un agente diseñado con un alcance explícito de fuentes de conocimiento, empaquetado de soluciones gestionadas, conexiones con variables de entorno y una especificación documentada tiene significativamente menos probabilidades de crear problemas de gobernanza en producción que uno construido rápidamente y desplegado directamente.
La inversión en gobernanza de diseño da sus frutos a lo largo de todo el ciclo de vida. Un agente bien diseñado es más fácil de aprobar, más fácil de mantener, más fácil de auditar y más fácil de retirar. El esfuerzo de gobernanza se traslada a una etapa anterior del ciclo de vida en lugar de acumularse como esfuerzo de corrección posterior.
Poniendo la Serie en Perspectiva
Estas capas forman una cadena de dependencias, no una lista de verificación. La gobernanza de diseño reduce el riesgo antes del despliegue. La gobernanza de proceso gobierna el comportamiento durante la operación. Los controles técnicos aplican los límites y proporcionan visibilidad en ambas etapas.
Eliminar cualquier capa crea una brecha: los controles técnicos sin gobernanza de proceso dejan abierta la pregunta sobre la responsabilidad; la gobernanza de proceso sin controles técnicos deja la aplicación de las normas a la buena voluntad; la gobernanza de diseño sin las demás capas produce agentes bien estructurados sin un marco que los respalde una vez desplegados.
Lo que la serie ha descrito es una postura de gobernanza que refleja cómo las organizaciones maduras gobiernan otros activos empresariales — con controles en la capa de aplicación, responsabilidad en la capa de propiedad, y decisiones de diseño que reducen la carga de gobernanza antes de que se acumule. Los mismos principios que se aplican a la gobernanza de datos, la gobernanza de aplicaciones y la gobernanza de accesos se aplican aquí. Los agentes no son un caso especial. Son la próxima clase de activos que necesita someterse al mismo rigor.
El marco puede implementarse de forma incremental, comenzando con los controles de mayor impacto y ampliándose con el tiempo. El punto de partida es siempre el mismo: decidir quién es responsable, hacer explícita esa decisión, y diseñar todo lo demás a partir de ahí.