Gobernanza de agentes en Microsoft 365 Copilot: quién puede crear, compartir y usar qué

El problema ha cambiado

Con Copilot desplegabas usuarios. Con agentes empiezas a gobernar un ecosistema.

Cuando Microsoft 365 Copilot llegó a las empresas, la conversación de gobierno era relativamente reconocible: licencias, permisos de SharePoint, información sensible, adopción, seguridad y medición. Los agentes amplían esa superficie. Un usuario puede crear un agente con Microsoft 365 Copilot Agent Builder, un equipo puede construir uno con Copilot Studio, un site de SharePoint puede tener agentes especializados y Microsoft puede incorporar agentes propios dentro de la experiencia de Copilot.

Cada uno puede tener un propietario distinto, fuentes de conocimiento diferentes, usuarios diferentes y un ciclo de vida diferente. Algunos solo responden preguntas. Otros pueden conectarse a acciones y procesos. Algunos se comparten entre unas pocas personas. Otros pueden publicarse para toda la organización. Si no existe una política clara, la proliferación llega antes que la gobernanza.

Microsoft está agrupando cada vez más estas capacidades bajo Copilot Control System. El planteamiento incluye tres grandes pilares: seguridad y gobierno, controles de administración y medición/reporting. La idea es importante porque evita tratar los agentes como una simple extensión de una app. Son activos que deben inventariarse, aprobarse, distribuirse, monitorizarse y retirarse igual que otras capacidades empresariales.

Copilot Control System

Gobernar agentes no es una única configuración: es combinar seguridad, administración y medición

Microsoft estructura Copilot Control System en tres pilares. El primero se ocupa de seguridad y gobierno: datos, IA, cumplimiento, privacidad y Zero Trust. El segundo agrupa controles de administración: licencias, capacidad, lifecycle, conectores, personalización y distribución. El tercero intenta responder una pregunta que muchas organizaciones olvidan: ¿estos agentes aportan valor o solo aumentan consumo y complejidad?

La gobernanza madura necesita los tres. Una empresa puede bloquear correctamente datos sensibles y aun así tener cincuenta agentes duplicados. Puede controlar quién crea agentes y no saber si nadie los utiliza. Puede medir adopción, pero permitir sharing demasiado amplio. La utilidad aparece cuando las políticas se conectan entre sí.

También es importante asumir que los controles viven en más de un centro de administración. Microsoft 365 Admin Center centraliza cada vez más inventario y políticas, pero Copilot Studio y Power Platform Admin Center siguen participando en determinados escenarios. SharePoint Admin Center y Microsoft Purview completan la capa cuando el problema es contenido, permisos y cumplimiento.

Primera pregunta de gobierno

¿Quién puede utilizar agentes dentro de la organización?

Microsoft 365 Admin Center permite controlar el acceso a agentes a nivel de organización. Los administradores pueden permitir acceso a todos los usuarios, bloquearlo o limitarlo a grupos específicos. Este control es especialmente útil cuando una empresa quiere comenzar con una población acotada mientras define seguridad, soporte y modelo de coste.

La política no debería definirse únicamente desde IT. Puede existir una diferencia razonable entre usuarios que necesitan consumir agentes y usuarios que deberían crear o compartir. Un empleado puede beneficiarse de un agente corporativo de RR. HH. sin necesidad de crear uno para toda la organización. Del mismo modo, un equipo experto puede necesitar capacidades de construcción que no deberían abrirse al tenant completo durante una fase inicial.

La segmentación por grupos permite introducir madurez progresiva. Un modelo frecuente es empezar con makers controlados, usuarios piloto y agentes corporativos aprobados; medir; después ampliar. Lo contrario —abrir creación y sharing a todo el mundo desde el primer día— puede acelerar adopción, pero también hace mucho más difícil construir inventario y lifecycle después.

Sharing de agentes

Crear un agente para ti es una cosa. Compartirlo con toda la organización es otra.

Los agentes creados mediante Microsoft 365 Copilot pueden empezar como recursos privados y después compartirse. Microsoft permite compartir enlaces de uso y edición y, según la política del tenant, habilitar acceso para toda la organización. Esto introduce un punto de gobierno muy importante: crear no debería implicar automáticamente publicar.

Microsoft 365 Admin Center incorpora políticas para limitar quién puede compartir agentes con la organización. En entornos más controlados, el administrador puede exigir un proceso de aprobación y despliegue antes de que el agente quede disponible a usuarios amplios. Esto ayuda a separar experimentación individual de activos corporativos.

También conviene distinguir acceso de chat y edición. Un agente puede ser útil para cientos de usuarios y necesitar solo dos propietarios. Dar derechos de edición a demasiadas personas aumenta el riesgo de cambios no controlados, fuentes nuevas, prompts modificados o una evolución que nadie pueda atribuir a un responsable.

La política debería responder cuatro preguntas: quién puede crear, quién puede compartir, quién puede editar y quién puede publicar para toda la organización. Si las cuatro respuestas son “todo el mundo”, la gobernanza dependerá únicamente de que nunca aparezca un problema.

Agent Inventory

No puedes gobernar agentes que no sabes que existen

Microsoft está centralizando el inventario de agentes dentro del Microsoft 365 Admin Center. El objetivo es proporcionar visibilidad sobre agentes utilizados en la organización y permitir acciones administrativas como bloquear, aprobar o controlar acceso. Esto empieza a resolver uno de los riesgos típicos de cualquier movimiento low-code: la proliferación invisible.

El inventario no debería utilizarse únicamente cuando existe una incidencia. Es una herramienta de gobierno. Permite identificar agentes duplicados, aplicaciones que nadie usa, recursos sin propietario claro o experiencias que están creciendo y merecen convertirse en activos oficialmente soportados.

Una organización madura puede clasificar agentes por nivel. Por ejemplo: personal, equipo, departamental, corporativo y crítico. Cada nivel puede tener requisitos diferentes de propietario, documentación, soporte, seguridad, revisión y medición. No tiene sentido aplicar el mismo proceso de aprobación a un agente experimental para tres usuarios y a uno que consulta políticas para 10.000 empleados.

SharePoint Agents

El agente respeta permisos. Pero un SharePoint mal gobernado sigue siendo un SharePoint mal gobernado.

Los agentes de SharePoint utilizan sitios, páginas y bibliotecas como fuentes de conocimiento. Microsoft indica que responden según los permisos de acceso que ya tiene el usuario. Esto es una base correcta, pero no elimina el riesgo de oversharing. Si un empleado ya tenía acceso innecesario a una biblioteca, el agente puede hacer que descubra esa información de forma mucho más sencilla.

Por eso Microsoft insiste en preparar SharePoint y OneDrive antes de escalar Copilot y agentes. SharePoint Advanced Management incorpora controles para reducir exposición, limitar descubrimiento de contenido y gestionar acceso. El SharePoint Admin Agent añade además una interfaz para ayudar a los administradores a analizar problemas de gobernanza de contenido.

Hay otro matiz importante: compartir un agente no concede automáticamente acceso completo al sitio que utiliza como conocimiento. Los usuarios siguen necesitando permiso sobre la información subyacente. Microsoft permite compartir determinados archivos o carpetas junto con el agente cuando el owner tiene capacidad para hacerlo, pero eso debe utilizarse con criterio porque modifica realmente los permisos del contenido.

La pregunta correcta no es “¿el agente puede ver SharePoint?”. Es “¿qué SharePoint estamos poniendo detrás del agente y quién debería poder descubrir ese conocimiento?”. Ahí se cruzan IA, colaboración y gobierno documental.

Copilot Studio y conectores

Un agente que solo responde tiene un riesgo. Un agente que además actúa tiene otro.

Cuando Copilot Studio entra en la arquitectura, los agentes pueden conectarse con acciones, flujos, conectores y procesos empresariales. Esto amplía muchísimo el valor, pero también cambia el nivel de gobierno necesario. Responder incorrectamente es un problema; ejecutar incorrectamente una acción puede tener impacto operativo o financiero.

Power Platform Admin Center y las políticas DLP permiten controlar conectores y combinaciones de datos. Microsoft 365 Admin Center añade gestión de agentes y conectores desde la perspectiva de Copilot. Ambos planos deben coordinarse. Un agente puede estar aprobado para uso y, sin embargo, una acción concreta necesitar restricciones adicionales.

También conviene definir qué conectores se permiten por defecto y cuáles requieren aprobación. No todo maker necesita acceso a todos los sistemas corporativos. Un agente de consulta de políticas puede trabajar únicamente con SharePoint; un agente de compras que consulta ERP y lanza una solicitud requiere otra arquitectura, otra prueba y otro propietario.

La regla debería ser proporcionalidad: cuanto más capacidad de actuar tiene el agente, más formal debe ser el proceso de diseño, aprobación, prueba, monitorización y rollback.

Lifecycle

Un agente corporativo necesita una fecha de nacimiento. Y también una forma de morir.

Uno de los mayores riesgos del low-code es que resulta mucho más fácil crear que retirar. Un agente se construye para una campaña, una política o un proceso temporal y sigue visible meses después. El owner cambia de puesto. La fuente se actualiza. Nadie revisa prompts, conectores ni audiencia. El activo sigue existiendo porque no ha fallado lo suficiente como para llamar la atención.

Microsoft incorpora cada vez más controles de lifecycle y reglas de administración precisamente para responder a este problema. Una política empresarial debería exigir propietario, propósito, audiencia, fuentes, nivel de criticidad y fecha de revisión. Los agentes con uso sostenido pueden convertirse en productos internos; los que dejan de aportar valor deben archivarse o retirarse.

También conviene gestionar cambios. Si un agente corporativo modifica la fuente de conocimiento o incorpora una acción nueva, puede haber cambiado su riesgo aunque el nombre siga siendo el mismo. El lifecycle no debe mirar solo “activo/inactivo”, sino evolución de capacidades.

Coste y capacidad

La gobernanza también tiene que responder quién paga cada agente

Los agentes pueden estar cubiertos por licenciamiento de Microsoft 365 Copilot, utilizar capacidad de Copilot Studio o emplear modelos de pago por uso según el escenario. Esto significa que el crecimiento de agentes no debe analizarse únicamente desde seguridad. También puede generar consumo y costes que nadie atribuye a un departamento o caso de uso concreto.

Copilot Control System incorpora controles relacionados con licenciamiento, metering y capacidad. Para una organización que empieza con pocos agentes puede parecer innecesario. Cuando decenas de equipos comienzan a experimentar, se vuelve relevante saber qué agente está generando uso, quién es su owner y qué valor entrega.

La mejor política no es bloquear por miedo al coste. Es hacer visible el coste y conectarlo con el valor. Un agente que ahorra cientos de horas puede justificar un consumo relevante. Uno que nadie utiliza debería retirarse aunque sea barato.

Modelo operativo

Un Centro de Excelencia de agentes no debería convertirse en una ventanilla que bloquea cada idea

A medida que crece el número de agentes, muchas organizaciones necesitan una función de gobierno transversal. Puede ser un CoE formal o una responsabilidad distribuida entre Microsoft 365, Power Platform, seguridad, datos y negocio. Lo importante es que exista un modelo que ayude a crear mejor, no únicamente a poner controles.

Un buen CoE debería ofrecer plantillas, patrones, fuentes aprobadas, conectores autorizados, criterios de publicación y métricas. Cuanto más fácil sea construir de forma segura, menos necesidad habrá de excepciones. Si la única función del gobierno es decir “no”, los equipos buscarán atajos.

El objetivo es crear carriles. Un agente personal de bajo riesgo puede seguir un camino rápido. Un agente corporativo que ejecuta acciones puede necesitar seguridad, arquitectura, pruebas y aprobación. Ambos deben poder avanzar, pero no con el mismo proceso.

Errores frecuentes

Ocho formas de perder el control de los agentes sin darte cuenta

Checklist de preparación

Doce decisiones que cerraría antes de escalar agentes a toda la organización

Políticas de agentes en el Admin Center

Microsoft ya permite definir qué tipos de agentes aceptas antes de discutir agente por agente

Una de las evoluciones más relevantes del Microsoft 365 Admin Center es que la administración empieza a desplazarse desde controles puramente individuales hacia políticas de tenant. Microsoft permite definir categorías de agentes permitidas, acceso de usuarios, sharing y otras configuraciones que ayudan a crear una postura de gobierno predeterminada.

Esto cambia la forma de escalar. En lugar de revisar manualmente cada nuevo agente desde cero, la organización puede establecer una base: determinados tipos están permitidos; otros necesitan aprobación; ciertos grupos pueden utilizar agentes; ciertos grupos pueden crearlos; el sharing organizativo está limitado; y los agentes corporativos deben ajustarse a una plantilla de seguridad. El administrador interviene sobre excepciones, no sobre cada experimento.

Las security templates son especialmente interesantes porque permiten acercarse a un modelo de “secure by default”. La intención es que un agente nuevo nazca ya dentro de una serie de reglas, políticas y allow lists en lugar de depender de que el maker recuerde cada requisito. Esta forma de trabajar será cada vez más importante si los agentes se convierten en una capacidad normal de Microsoft 365 y no en proyectos aislados.

También aparecen mecanismos de clasificación como tags. A primera vista puede parecer una función administrativa menor, pero en organizaciones grandes puede ayudar a distinguir agentes de RR. HH., Finanzas, IT, Comercial, producción o experimentación, y combinar esa clasificación con ownership, criticidad y lifecycle.

Agentes de Microsoft, propios y de terceros

El inventario no solo contendrá agentes que haya construido tu empresa

Microsoft puede incorporar agentes y capacidades propias dentro de Copilot. En 2026, Researcher y Analyst son ejemplos de agentes Microsoft desplegados para usuarios con licencia. Los administradores pueden gobernar agentes dentro del Microsoft 365 Admin Center y bloquear determinados recursos cuando la política corporativa lo requiere.

A esto se suman agentes instalados por administradores, agentes de partners o marketplace, agentes creados con Microsoft 365 Copilot, SharePoint Agents y agentes construidos con Copilot Studio. La consecuencia es clara: “inventario de agentes” no significa “lista de desarrollos de nuestro equipo de IA”. Incluye un ecosistema con orígenes y modelos de distribución diferentes.

Esto obliga a introducir criterios de procedencia. Un agente creado por Microsoft puede tener un modelo de actualización distinto a uno corporativo. Un agente de marketplace necesita evaluación de proveedor y condiciones. Un agente de SharePoint depende del contenido del site. Uno de Copilot Studio puede ejecutar acciones. La gobernanza debe conocer el origen porque condiciona soporte, seguridad y lifecycle.

La empresa no necesita prohibir esa diversidad. Necesita saber qué ha autorizado y cómo reaccionará si un agente deja de encajar con su política. La capacidad de bloquear, retirar o limitar acceso debe formar parte del modelo operativo desde el principio.

Una política simple para empezar

Si mañana tuvieras que gobernar agentes con solo cinco reglas, empezaría por estas

Primero, ningún agente corporativo sin owner funcional. Segundo, ningún agente compartido ampliamente sin fuentes y audiencia documentadas. Tercero, ninguna acción crítica sin revisión de conectores, DLP y autorización. Cuarto, ningún agente que consulte SharePoint sin revisar el riesgo de oversharing del contenido. Quinto, ningún agente permanece indefinidamente sin métricas ni fecha de revisión.

Estas cinco reglas no sustituyen una arquitectura completa, pero crean una disciplina suficiente para empezar a experimentar sin perder trazabilidad, reducir duplicidades, proteger conocimiento corporativo y mantener una responsabilidad clara sobre cada agente empresarial. Después pueden añadirse clasificación, security templates, reporting, procesos de aprobación y lifecycle más sofisticados a medida que el número de agentes y su impacto crecen.

Preguntas frecuentes

Gobernanza de agentes en Microsoft 365 Copilot

Para seguir profundizando

Microsoft 365, Copilot, agentes y conocimiento corporativo

Fuentes Microsoft

Documentación oficial sobre gobierno de Copilot y agentes