Serie: Gobernando Agentes de IA en Microsoft 365 — Parte 4 de 5. Este artículo cubre la capa de gobernanza de proceso — las decisiones humanas que las herramientas por sí solas no resuelven. La Parte 5 cubre la gobernabilidad por diseño — las decisiones de diseño y ALM que determinan lo gobernable que es un agente antes de llegar al proceso de aprobación.
Los tres artículos anteriores de esta serie han cubierto los controles técnicos de gobernanza disponibles para los agentes de Copilot Studio: las políticas DLP de Power Platform, Microsoft Purview y Microsoft Agent 365. En conjunto representan un conjunto sustancial de herramientas — controles de conectores, aplicación de etiquetas de sensibilidad, un registro centralizado, integración de seguridad con Entra, Purview y Defender.
Lo que no cubren es la capa que determina si esas herramientas se usan con eficacia: quién es propietario de un agente, quién es responsable cuando se comporta de forma inesperada, quién decide cuándo debe retirarse y quién lo aprobó en primer lugar.
Esta es la brecha de gobernanza de proceso. No existe porque las herramientas estén ausentes, sino porque las herramientas todavía no pueden tomar plenamente las decisiones organizativas sobre propiedad, responsabilidad y riesgo aceptable. Eso requiere un marco — y la mayoría de las organizaciones todavía no lo han construido.
El Problema de la Proliferación
Copilot Studio hace que construir agentes sea genuinamente accesible. Un analista de negocio, un gestor de proyectos, un coordinador de departamento — muchos usuarios con las licencias y permisos adecuados pueden construir un agente funcional con rapidez. Esa accesibilidad es el objetivo, y es lo que hace que los agentes sean valiosos a escala.
Pero crea un desafío de gobernanza que no existía cuando el desarrollo de agentes requería un desarrollador y un ciclo de vida formal de proyecto. Sin un marco en vigor, los agentes se construyen para tareas específicas, funcionan bien inicialmente y luego se degradan silenciosamente. El sitio de SharePoint del que extraen el conocimiento se reorganiza. El proceso para el que fueron construidos cambia. La persona que los construyó se traslada a otro departamento. Nadie más sabe que el agente existe, y mucho menos cómo está configurado o si sigue siendo apto para su propósito.
Microsoft Agent 365 proporciona el inventario técnico — un registro centralizado de agentes en todo el tenant. Pero el registro no te dice por qué existe un agente, quién lo patrocina, si fue formalmente aprobado alguna vez o cuándo puede retirarse de forma segura. Ese contexto empresarial tiene que venir de la organización, no de la plataforma.
Las organizaciones también deben decidir si todos los usuarios con licencia pueden crear agentes o si la creación de agentes debe restringirse a grupos de creadores definidos. El problema de la proliferación es significativamente más fácil de gestionar cuando el grupo de creadores es intencional en lugar de abierto por defecto.
El Catálogo Organizativo como Mecanismo Forzador
La capacidad de enviar agentes directamente al catálogo organizativo desde Copilot Agent Builder es un punto de control de gobernanza significativo en el flujo de aprobación, no sólo una funcionalidad. Cuando se envía un agente para disponibilidad en toda la organización, alguien tiene que decidir si debe aprobarse. Esa decisión crea responsabilidad que el uso compartido informal de agentes no genera.
La pregunta que la mayoría de las organizaciones no han respondido es quién ocupa ese rol de aprobador. En muchas organizaciones, los equipos de TI u operaciones se convertirán probablemente en los aprobadores predeterminados porque controlan la configuración de gobernanza y riesgos. Pero lo predeterminado no es lo mismo que lo decidido. El rol de aprobador debe definirse explícitamente, y las personas en él deben entender qué están aprobando exactamente.
Aprobar un agente para el catálogo organizativo debería significar algo más que confirmar que funciona. Debería significar confirmar que alguien es su propietario, que sus fuentes de conocimiento son apropiadas y están actualizadas, que su alcance está comprendido y que existe un plan para cuando necesite actualizarse o retirarse.
Definir la Propiedad Desde el Principio
La propiedad es mucho más fácil de establecer en el momento de la creación que de asignar retroactivamente. Una vez que un agente está en producción y en uso, nadie quiere levantar la mano por algo que no construyó y no entiende completamente.
Un propietario de agente debería ser:
- La persona responsable de la precisión y el comportamiento del agente
- El punto de contacto si los usuarios reportan problemas o salidas inesperadas
- Responsable de revisar el agente cuando cambie su contenido o proceso subyacente
- Responsable de confirmar que el agente sigue sirviendo a un propósito empresarial válido
- Nombrado en el registro de agentes y en el campo de patrocinador de Entra Agent ID cuando corresponda
En la práctica, el propietario suele ser la persona que construyó el agente o el responsable empresarial del proceso que respalda. La clave es que la propiedad sea explícita — registrada, no asumida — y que se transfiera formalmente si el propietario original se traslada. La propiedad es continua; la revisión es la validación periódica de esa propiedad.
Cuando la posibilidad de patrocinio de Entra Agent ID esté disponible, el marco de gobernanza debería exigir que se complete como parte del proceso de aprobación, conectando el registro de identidad técnica con el registro de responsabilidad empresarial.
Cómo Es un Registro de Agentes
Un registro de agentes no tiene por qué ser complejo. Una lista de SharePoint funciona bien. Agent 365 proporciona el inventario técnico; el registro proporciona la capa de contexto empresarial que se sitúa por encima.
Los campos mínimos útiles:
| Campo | Notas |
|---|---|
| Nombre del agente | Tal como aparece en el catálogo |
| Descripción | Qué hace y por qué, en lenguaje sencillo |
| Propietario | Persona con nombre — no un equipo o departamento |
| Entorno | Qué entorno de Power Platform |
| Fuentes de conocimiento | Qué sitios de SharePoint, documentos o fuentes externas |
| Canales publicados | Teams, SharePoint, web, otros |
| Perfil de riesgo de datos | Sólo interno / Datos externos / Entre sistemas / Proceso sensible |
| Criticidad empresarial | Baja / Media / Alta — distinta del riesgo; refleja la importancia para las operaciones |
| Fecha de aprobación | Cuándo se aprobó para el catálogo |
| Fecha de revisión | Cuándo es la próxima revisión |
| Estado | Activo / En revisión / Deprecado |
Dos campos merecen una mención especial. El perfil de riesgo de datos clasifica los agentes por su exposición a datos — un agente que sólo accede a contenido web público es una propuesta de gobernanza diferente a la de un agente que accede a sistemas de RRHH o finanzas. La criticidad empresarial es distinta: un agente de bajo riesgo puede ser de alta criticidad para el negocio, y un agente de alto riesgo puede tener una importancia operativa limitada. Ambas dimensiones juntas proporcionan una base proporcional para la frecuencia de revisión y el nivel de escrutinio.
El registro cumple dos propósitos. Primero, proporciona a los equipos de gobernanza y cumplimiento el contexto empresarial que el inventario técnico por sí solo no ofrece. Segundo, crea el rastro de auditoría que los equipos de protección de datos acabarán solicitando — quién aprobó este agente, cuándo y con qué base.
Mantenimiento y Ciclos de Revisión
Un agente aprobado hoy no es necesariamente apto para su propósito en seis meses. Las fuentes de conocimiento cambian. Los procesos evolucionan. Las estructuras organizativas se transforman. Un agente construido en torno a una estructura específica de biblioteca de SharePoint puede empezar a devolver resultados deficientes silenciosamente si esa biblioteca se reorganiza sin que nadie notifique al propietario del agente.
Un ciclo de revisión vinculado al registro de agentes te proporciona una forma sistemática de detectar esto antes de que los usuarios pierdan la confianza. La frecuencia apropiada depende de lo dinámicos que sean el contenido y el proceso subyacentes. Trimestral es un valor predeterminado razonable para la mayoría de los agentes. Los agentes que extraen conocimiento de contenido que cambia regularmente, o los que operan en áreas de proceso sensibles, requieren un ciclo más frecuente. Los agentes de mayor riesgo o alta criticidad empresarial deben seguir ciclos de revisión más cortos que los agentes estándar — los campos de perfil de riesgo de datos y criticidad empresarial del registro proporcionan la base para esa clasificación.
La revisión en sí no tiene por qué ser extensa. Las preguntas clave son: ¿se sigue usando el agente, están actualizadas y con el alcance correcto sus fuentes de conocimiento, ha cambiado de alguna manera el proceso que respalda que afecte a su comportamiento, sigue sirviendo a un propósito empresarial válido y sigue siendo el propietario la persona adecuada?
Los datos de consumo de los informes de uso de Copilot Studio y de Agent 365 proporcionan una entrada útil al proceso de revisión. Un agente con un uso decreciente a lo largo de varios ciclos de revisión puede ser candidato a la deprecación en lugar de al mantenimiento continuo.
Retirada y Deprecación
Retirar un agente es tan importante como aprobar uno. Los agentes que ya no son aptos para su propósito pero siguen disponibles en el catálogo — o peor, siguen desplegados en Teams o SharePoint — crean riesgo. Los usuarios pueden seguir confiando en ellos, recibiendo salidas basadas en contenido obsoleto o reorganizado sin ninguna indicación de que el agente ha sido abandonado.
Un proceso de deprecación debería formar parte del marco de gobernanza desde el principio. Cuando se retira un agente:
- Deberían notificarse a los usuarios que han interactuado con él recientemente
- La entrada del catálogo debería desactivarse, retirarse del uso activo o marcarse como deprecada según los requisitos de gobernanza
- El agente debería desactivarse o despublicarse, no simplemente ignorarse
- La entrada del registro de agentes debería actualizarse a Deprecado con la fecha de retirada y el motivo
La supervisión disponible a través de las señales de Agent 365, SharePoint Agent Insights y los informes de uso de Copilot proporciona los datos para identificar los agentes que han quedado inactivos o cuyo uso ha caído significativamente — un desencadenante práctico para la conversación sobre deprecación antes de que se convierta en un pasivo de gobernanza.
Construyendo el Marco
Los controles técnicos de los tres artículos anteriores proporcionan la capa de aplicación y visibilidad. Esta capa de proceso se sitúa por encima de ellos. Juntas cubren el panorama completo de gobernanza.
El punto de partida práctico para la mayoría de las organizaciones:
- Decidir quién puede crear agentes — abierto a todos los usuarios con licencia o restringido a grupos de creadores definidos
- Definir el rol de aprobador — ¿quién revisa los agentes antes del envío al catálogo organizativo y qué significa la aprobación?
- Exigir la propiedad en la aprobación — la propiedad debe registrarse antes de que un agente entre en producción, no asignarse después
- Crear el registro de agentes — una lista de SharePoint es suficiente para empezar; alinearlo con los identificadores de Agent 365 en lugar de duplicar los datos del inventario
- Establecer un ciclo de revisión predeterminado — trimestral para la mayoría de los agentes; hacer que el propietario sea responsable de iniciarlo
- Definir la deprecación — qué la desencadena, cuál es el proceso, quién la sanciona
- Clasificar por riesgo de datos y criticidad empresarial — usar ambas dimensiones para calibrar el escrutinio y la frecuencia de revisión de forma proporcional
Nada de esto requiere una inversión significativa. Requiere una conversación — idealmente antes de que el número de agentes llegue al punto en que una auditoría retrospectiva sea la única opción.
El proceso de envío al catálogo organizativo proporciona un punto de control de gobernanza natural para introducir estos controles antes de que la escala los haga más difíciles de aplicar.
La Parte 5 de esta serie cubre la gobernabilidad por diseño — las decisiones de diseño y ALM que determinan lo fácil que es gobernar, auditar y retirar un agente antes de que llegue al proceso de aprobación.