Serie: Gobernando Agentes de IA en Microsoft 365 — Parte 1 de 5. Este artículo cubre la capa de gobernanza de Power Platform — políticas DLP, controles de conectores y estrategia de entornos. La Parte 2 cubre Microsoft Purview.
Gobernar los agentes de IA en Microsoft 365 significa responder cinco preguntas en cinco capas distintas:
- ¿Está este agente bien construido antes de existir en producción? (Gobernanza de diseño)
- ¿Es este agente seguro y correcto para ser promovido? (Gobernanza de entrega)
- ¿Quién es responsable de este agente a lo largo del tiempo? (Gobernanza de proceso)
- ¿A qué tiene acceso técnico este agente? (Gobernanza de políticas y controles)
- ¿Qué está haciendo realmente este agente en la práctica? (Observabilidad e inteligencia del ciclo de vida)
Esta serie de cinco artículos trabaja cada capa en orden. Los artículos 1 y 2 cubren la capa de políticas y controles — los límites técnicos que determinan a qué pueden conectarse, publicar y acceder los agentes. El artículo 3 cubre Microsoft Agent 365, la capa central de gobernanza y gestión. El artículo 4 cubre la capa de gobernanza de proceso — propiedad, aprobación y responsabilidad. El artículo 5 cubre la gobernanza de diseño y entrega — las decisiones tomadas antes de que un agente llegue a producción que determinan lo gobernable que será una vez que lo haga.
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. Copilot Studio, Microsoft Agent 365 y Entra Agent ID son capacidades distintas dentro de ese ecosistema.
Este artículo cubre la arquitectura de gobernanza de Power Platform para agentes: políticas de Prevención de Pérdida de Datos, controles a nivel de conector, estrategia de entornos y las capacidades de Managed Environments que hacen aplicable la gobernanza a escala. A medida que los agentes de Copilot Studio se incorporan a los flujos de trabajo de producción, esta es la capa donde ocurre la mayor parte de la gobernanza del día a día — donde los administradores controlan a qué pueden conectarse los agentes, qué pueden publicar, a qué fuentes de conocimiento pueden acceder y en qué entornos operan. Establecer correctamente esta capa es el fundamento sobre el que se construye todo lo demás.
Las Políticas DLP como Mecanismo Principal de Gobernanza
Las políticas de Prevención de Pérdida de Datos de Power Platform son el mecanismo principal para controlar la conectividad de los agentes y el movimiento de datos a nivel de conector. Se aplican a los agentes de Copilot Studio y a las capacidades relacionadas de Power Platform utilizadas por esos agentes, incluyendo flujos y acciones basadas en conectores, y se extienden a los Agent Flows — los flujos de trabajo automatizados que los agentes pueden desencadenar como parte de sus acciones.
Si tu organización ya tiene políticas DLP en vigor para Power Platform, esas políticas ya se aplican a los agentes. La pregunta importante es si fueron diseñadas teniendo en cuenta los agentes, o si son anteriores a la adopción de agentes y necesitan revisarse en ese contexto.
Las políticas DLP funcionan clasificando los conectores en grupos — Business, Non-Business y Blocked — y controlando qué grupos pueden usarse juntos. Un agente que utiliza tanto un conector de SharePoint como un conector HTTP externo, por ejemplo, estaría sujeto a las reglas que rigen esa combinación en las políticas activas.
La implicación práctica: un agente sólo es tan fiable como los conectores que tiene permitido usar. Revisar las políticas DLP desde la perspectiva de los casos de uso de los agentes — en lugar de sólo los flujos tradicionales de Power Apps y Power Automate — es un paso de gobernanza significativo antes de que los agentes lleguen a producción.
Conectores de Copilot Studio y Lo que Controlan
Copilot Studio introduce un conjunto de conectores y controles específicos dentro del marco DLP, distintos del catálogo general de conectores de Power Platform. Estos conectores se corresponden con capacidades específicas de Copilot Studio, lo que significa que las políticas DLP pueden gobernar el comportamiento de los agentes a nivel de funcionalidad y no solo a nivel de conexión de datos.
Las capacidades que puedes controlar a través de estos conectores incluyen:
Canales de publicación
El conector Microsoft Teams + M365 Channel in Copilot Studio y el conector SharePoint Channel in Copilot Studio pueden bloquearse para impedir que los agentes se publiquen en esos canales. Este es un control de etapas útil: los agentes pueden construirse y probarse en un entorno de desarrollo sin poder ser desplegados para los usuarios finales hasta que se tome una decisión deliberada de permitir la publicación.
Controles de Autenticación y Exposición
Publicar un agente es solo parte de la decisión de gobernanza — quién puede acceder a él importa igual. La configuración de autenticación cambia significativamente el perfil de exposición de un agente; un agente autenticado internamente presenta un riesgo de gobernanza diferente a uno accesible de forma anónima.
Los controles de gobernanza de Copilot Studio — incluidos los controles respaldados por DLP para las capacidades compatibles — pueden usarse para restringir configuraciones que permiten escenarios de acceso anónimo, lo que permite a las organizaciones aplicar modelos de acceso autenticado donde sea necesario. Esto cobra especial importancia para los agentes conectados a fuentes de conocimiento internas o sistemas de negocio, donde una exposición externa amplia puede crear riesgos innecesarios.
Desde la perspectiva de la gobernanza, los controles de autenticación deben considerarse junto con los canales de publicación: controlar dónde puede desplegarse un agente es solo parte de la pregunta — controlar quién puede interactuar con él es igualmente importante.
Fuentes de conocimiento
Cuatro conectores se corresponden con tipos específicos de fuentes de conocimiento:
- Knowledge source with SharePoint and OneDrive
- Knowledge source with public websites and data
- Knowledge source with documents in Copilot
- Knowledge source with Dataverse
Cada uno puede bloquearse de forma independiente. Esto significa que puedes permitir que los agentes consulten contenido interno de SharePoint mientras se impide la navegación web pública, o restringir completamente la carga de documentos, según los requisitos de gestión de datos de tu organización.
Las fuentes de conocimiento de Dataverse siguen los mismos controles a nivel de conector, aunque la gobernanza de acceso también se extiende a los roles de seguridad de Dataverse y la seguridad a nivel de fila — una capa adicional que los agentes basados en SharePoint no tienen.
Controles de URL de endpoint
Ciertos conectores de fuentes de conocimiento admiten configuración y restricciones basadas en URL, lo que permite a los administradores delimitar los endpoints permitidos en lugar de aplicar decisiones globales de permitir/bloquear.
Este nivel de granularidad importa. Bloquear todo el acceso web es un instrumento demasiado general; la capacidad de limitar el acceso por URL da a los administradores un conjunto de opciones más proporcionado.
Estrategia de Entornos — La Capa que se Pasa por Alto
Las políticas DLP se aplican a nivel de entorno, lo que significa que tu estrategia de entornos determina directamente tu postura de gobernanza. Esta es la capa que la mayoría de las organizaciones no planifica sistemáticamente hasta que los agentes ya están en producción y las brechas de gobernanza se hacen evidentes.
Un enfoque de entornos estructurado para el desarrollo de agentes normalmente implica al menos tres niveles:
Desarrollo — donde los agentes son creados y probados por los makers. Las políticas DLP aquí pueden ser más permisivas para permitir la experimentación, pero aun así deben restringir la publicación en los canales de producción. Los agentes en este entorno no deben ser accesibles para los usuarios finales.
Test/UAT — donde los agentes se revisan antes de la promoción. Las políticas DLP deben reflejar las de producción. Aquí es donde ocurren las comprobaciones de gobernanza: se confirma la propiedad, se revisan las fuentes de conocimiento y se valida el comportamiento del agente según su propósito declarado.
Producción — el entorno con el que interactúan los usuarios finales. Los entornos de producción deben tener las políticas más estrictamente gobernadas. Las organizaciones deben procurar que los agentes lleguen a este entorno únicamente a través de un proceso de promoción definido y no mediante el despliegue directo por parte de los makers.
El valor de gobernanza de esta estructura es que crea puntos de control naturales. Un modelo de entornos estructurado hace posible la promoción controlada y facilita su aplicación.
La estrategia de entornos también importa para la herencia de políticas. Las políticas aplicadas al entorno predeterminado no se aplican automáticamente a los entornos personalizados. Las organizaciones que han creado entornos para departamentos o proyectos específicos sin revisar las políticas DLP de esos entornos pueden tener brechas de gobernanza de las que no son conscientes.
Managed Environments
Los entornos estándar te proporcionan la estructura — Managed Environments te da los controles para aplicarla. Managed Environments es una funcionalidad de Power Platform que desbloquea un conjunto de capacidades de gobernanza no disponibles en los entornos estándar, y se está convirtiendo progresivamente en una base práctica para los despliegues de agentes a escala de producción.
Las capacidades de gobernanza que añade Managed Environments incluyen controles de makers — restringiendo quién puede crear y compartir canvas apps, flujos y agentes dentro del entorno; aplicación del comprobador de soluciones — con comprobaciones automáticas de calidad y buenas prácticas que pueden integrarse en los procesos de despliegue; integración de pipelines — habilitando la promoción estructurada y gobernada de soluciones entre entornos en lugar de despliegues ad hoc; e información de uso — proporcionando visibilidad sobre qué se usa, quién lo usa y con qué frecuencia. Managed Environments también introduce controles de enrutamiento de entornos, para orientar a los makers hacia los entornos de desarrollo aprobados en lugar de ubicaciones predeterminadas o no gestionadas. Para las organizaciones que desarrollan agentes a escala, habilitar Managed Environments en los entornos de producción (e idealmente de test) es un paso significativo hacia un conjunto de agentes gobernable y no solo gobernado.
Aplicar Políticas a los Entornos Correctos
Una brecha habitual en la gobernanza de Power Platform son las políticas que existen a nivel de tenant pero no se han aplicado a los entornos que las necesitan. Las políticas DLP pueden aplicarse a:
- Todos los entornos del tenant
- Todos los entornos excepto exclusiones específicas
- Únicamente entornos con nombre concretos
Para la gobernanza de agentes, el enfoque recomendado es tener una política base aplicada a todo el tenant que establezca estándares mínimos — bloqueando las combinaciones de conectores de mayor riesgo — y luego políticas específicas por entorno que apliquen restricciones adicionales apropiadas para el propósito de ese entorno.
Por ejemplo: un entorno de producción que aloja agentes con acceso a datos de RRHH podría tener una política más restrictiva que el entorno de producción general, bloqueando completamente las fuentes de conocimiento web pública y restringiendo el acceso a SharePoint a sitios específicos. Esa restricción vive a nivel de entorno sin afectar a los agentes en otros entornos.
Lo que Esta Capa No Cubre
Los controles de gobernanza de Power Platform en la capa de entornos y DLP determinan a qué pueden conectarse los agentes, dónde pueden desplegarse y cómo se gobierna la exposición a los usuarios. No controlan cómo los agentes utilizan los datos a los que acceden, cómo se gestiona el contenido sensible en las respuestas, ni cómo se monitoriza la actividad de los agentes para el cumplimiento normativo. Esa es la capa de Purview — cubierta en la Parte 2 de esta serie.
Tampoco abordan la capa de proceso: quién aprueba un agente antes de que llegue a producción, quién es su propietario, qué ocurre cuando se degrada. Esa es la brecha de gobernanza cubierta en la Parte 4.
La capa de Power Platform es necesaria pero no suficiente. Establece los límites. El resto del marco determina lo que ocurre dentro de ellos.
Por Dónde Empezar
Si estás revisando tu postura de gobernanza de Power Platform teniendo en cuenta los agentes, los puntos de partida de mayor impacto son:
- Auditar las políticas DLP existentes y comprobar a qué entornos se aplican — ¿hay brechas?
- Revisar los conectores específicos de Copilot Studio en tus políticas — ¿están configurados deliberadamente los controles de fuentes de conocimiento, canales de publicación y autenticación?
- Comprobar si la estructura de entornos admite una separación dev/test/producción para el desarrollo de agentes
- Confirmar que los entornos de producción tienen restricciones de canales de publicación para que los agentes no puedan ponerse en marcha sin un proceso de promoción
- Revisar si Managed Environments está habilitado en tu entorno de producción — y si no, si las capacidades de gobernanza que desbloquea merecen habilitarlo
Nada de esto requiere construir desde cero. La mayoría de las organizaciones ya tienen políticas DLP y entornos. El trabajo consiste en revisarlos desde la perspectiva de la gobernanza de agentes y cubrir las brechas que no eran relevantes antes de que existieran los agentes.
La Parte 2 de esta serie cubre Microsoft Purview — etiquetas de sensibilidad, DLP para respuestas de IA, Gestión de la Postura de Seguridad de Datos y Observabilidad de IA.