Gobernanza de Agentes de IA y Ley de IA de la UE: AGT + Agent 365

Tu agente de IA acaba de ejecutar una acción. Microsoft Agent 365 puede decirte qué agente fue, quién es su responsable y con qué identidad actuó. Lo que no te dice es si esa acción concreta, con esos parámetros concretos, en ese momento, debía ejecutarse. Esa diferencia — entre "sé quién eres" y "esto que acabas de hacer estaba permitido" — es exactamente la brecha que el Reglamento de IA de la UE obliga a cerrar con controles técnicos, y es la que el Agent Governance Toolkit cierra en código de aplicación, no en un prompt.

Microsoft publicó el Agent Governance Toolkit (AGT) en GitHub en marzo de 2026. Licencia MIT, public preview, más de 5.700 estrellas y commits diarios. No es un producto de Microsoft 365: no hay blade en el centro de administración, no hay SKU, no hay recuento de licencias. Se instala con pip install o dotnet add package y corre dentro del proceso de tu propio agente.

¿Qué es el Agent Governance Toolkit y por qué aparece justo ahora?

AGT intercepta cada llamada a una herramienta, cada envío de mensaje y cada delegación que intenta un agente, y la evalúa contra una política YAML antes de que la acción se ejecute. Si la política dice que no, la llamada nunca llega a la herramienta. El planteamiento es más estrecho de lo que parece, y lo es a propósito.

El propio proyecto es directo sobre por qué existe esto en vez de confiar en un system prompt bien escrito: la entrada LLM01 de OWASP sobre inyección de prompts afirma que no existe un método a prueba de fallos para prevenirla, y un paper de ICLR de 2025 (Andriushchenko et al.) reporta una tasa de éxito del 100% en ataques adaptativos de optimización de sufijo contra GPT-4o, GPT-3.5, Claude 3 y Llama-3 sobre el benchmark JailbreakBench. Pedirle educadamente a un modelo que se mantenga dentro de unos límites es un control probabilístico. La postura de AGT es que la gobernanza pertenece a código determinista que el modelo no puede negociar: un wrapper govern() alrededor de la función de la herramienta, no un párrafo en el mensaje de sistema.

Este matiz no es solo técnico — es exactamente el que un auditor de la Ley de IA de la UE va a exigir. El Artículo 9 pide un sistema de gestión de riesgos que sea un proceso iterativo continuo, no una política redactada una vez y archivada. El Artículo 12 exige un registro automático de eventos ("logging") durante el funcionamiento del sistema. Un párrafo de instrucciones en un prompt no genera ese registro cuando algo falla. Una excepción lanzada por código de aplicación, sí.

¿Qué hace exactamente, acción por acción?

En Python, el wrapper es así:

from agentmesh.governance import govern

safe_tool = govern(my_tool, policy="policy.yaml")   # cada llamada se revisa, registra y aplica

Y la política contra la que se evalúa:

apiVersion: governance.toolkit/v1
name: production-policy
default_action: allow
rules:
  - name: block-destructive
    condition: "action.type in ['drop', 'delete', 'truncate']"
    action: deny
    description: "Las operaciones destructivas requieren aprobación humana"

  - name: require-approval-for-send
    condition: "action.type == 'send_email'"
    action: require_approval
    approvers: ["security-team"]

Si llamas a safe_tool(action="drop", table="clientes") no obtienes una negativa alucinada del modelo: obtienes una excepción GovernanceDenied, lanzada por código de aplicación y registrada en un rastro de auditoría, antes de que el drop llegue siquiera al driver de tu base de datos. Esa es la diferencia que vende el proyecto: no "improbable", sino estructuralmente imposible.

Las cifras de rendimiento que publica Microsoft para el motor de políticas: evaluación por debajo de 0,1 ms, unas 47.000 operaciones por segundo con 1.000 agentes concurrentes. Pienses lo que pienses del enfoque conceptualmente, no va a ser el cuello de botella de latencia en tu pipeline de agentes.

¿Dónde termina Microsoft Agent 365 y dónde empieza AGT?

Por debajo, no en su lugar. Agent 365 es el plano de control de Microsoft para observar, gobernar y proteger agentes en todo un tenant: el registro, el modelo de patrocinador, la capa de identidad Entra Agent ID, la integración con Purview y Defender. Lo que gobierna A365 es el acceso: qué agente existe, quién responde por él, qué política de acceso condicional controla su inicio de sesión. AGT gobierna el comportamiento: una vez que un agente tiene ese acceso, qué puede hacer realmente con él, acción por acción.

El propio documento de arquitectura de referencia A365-AGT del proyecto lo resume sin venderse de más: el acceso condicional de A365 opera a nivel de identidad; AGT añade autorización a nivel de acción, donde los agentes declaran su intención antes de actuar, con detección de desviación cuando el comportamiento se aparta del plan. A365 decide si el agente entra en la sala. AGT decide qué puede tocar una vez dentro.

Esa distinción importa especialmente para la Ley de IA de la UE porque separa dos obligaciones distintas del Artículo 29 para los responsables del despliegue: saber quién actuó (identidad, ya cubierta por A365) y poder demostrar que cada acción de alto riesgo fue evaluada antes de ejecutarse (control de acción, que A365 no cubre por diseño).

La fila que señalaría a cualquiera que gestione más de un agente: la evaluación de políticas multiagente. A día de hoy A365 no tiene un equivalente para gobernar lo que ocurre entre agentes cuando uno delega en otro. Si estás construyendo orquestación sobre Microsoft Agent Framework o el patrón de agentes conectados de Azure AI Foundry, ese es el hueco que AGT llena — y ahora mismo es lo único de esta comparativa que lo llena.

¿Por qué esto es relevante para el cumplimiento de la Ley de IA de la UE?

Porque la mayoría de los despliegues agénticos que tocan decisiones sobre personas — acceso a un servicio, una solicitud de crédito, una recomendación de contratación — encajan en el Anexo III como sistemas de alto riesgo. Y el Artículo 14 exige medidas de supervisión humana: mecanismos que permitan a una persona monitorizar el sistema mientras funciona e intervenir o detenerlo cuando haga falta. Un govern() que bloquea una acción y la deja pendiente de aprobación humana es, literalmente, ese mecanismo implementado en código, no descrito en una política PDF.

Ya escribí sobre quién debe firmar la titularidad de la gobernanza de IA antes del 2 de agosto: un responsable con nombre y apellidos necesita algo a lo que apuntar cuando un auditor pregunte "¿cómo sabes que este agente no hizo algo que no debía?". Un documento de política no responde a esa pregunta. Un registro de auditoría con la marca de tiempo exacta en la que GovernanceDenied interceptó un intento de send_email no autorizado, sí.

Mi opinión, y es la que defendería en una llamada con un CIO español: instalar AGT en un bot interno de FAQ es malgastar una tarde; no instalarlo en un agente con send_email y delete_row en su lista de herramientas es una decisión que alguien tendrá que explicar ante el regulador, no solo ante el comité de dirección. El propio proyecto publica una escalera de adopción por riesgo, y es una buena referencia — uso una versión de ella en las llamadas de scoping:

Fíjate en lo que falta en esa tabla: el lienzo sin código de Copilot Studio. No es un olvido, es la confusión que más veo repetirse. Esos agentes se gobiernan a nivel de plataforma — Purview DLP, permisos de conector, el Copilot Control System, Entra Agent ID para la identidad. AGT envuelve código: una función Python o .NET dentro de tu propio proceso de agente. No hay govern() que insertar en un topic declarativo porque no hay función que envolver. Si tu parque es enteramente Copilot Studio, AGT no es la pieza que te falta; lo es la checklist de gobernanza de esa superficie. AGT gana su sitio cuando construyes a medida — Azure AI Foundry Agent Service, Microsoft Agent Framework, o un agente agnóstico de framework que llama a servidores MCP.

La otra advertencia honesta, y el propio proyecto la reconoce en vez de obligarte a buscarla: la gobernanza corre dentro del mismo límite de proceso que el agente. Es middleware de aplicación, no un sandbox a nivel de sistema operativo. La propia recomendación de Microsoft es ejecutar cada agente en un contenedor separado para un aislamiento real — AGT decide qué está permitido, el contenedor decide qué es físicamente alcanzable si una decisión falla de todos modos. Trátalo como una capa de defensa, no como todo el muro.

¿Qué implica adoptarlo en la práctica?

Para un agente en Python, todo el toolkit es un pip install "agent-governance-toolkit[full]" y un fichero de política. Para un agente .NET ya construido sobre Microsoft Agent Framework, es un paquete NuGet y una llamada a método:

dotnet add package Microsoft.AgentGovernance.Extensions.Microsoft.Agents

using Microsoft.AgentGovernance.Extensions.Microsoft.Agents;

var governedAgent = agent.WithGovernance(options =>
{
    options.PolicyPath = "policies/";
    options.EnableTrustScoring = true;
    options.EnableAuditLog = true;
});

Cuatro comandos de CLI merecen ejecutarse antes de que esto toque un tenant de producción:

agt doctor                                        # comprueba la instalación
agt verify --evidence ./agt-evidence.json --strict # falla en CI ante evidencia débil
agt red-team scan ./prompts/ --min-grade B         # auditoría de inyección de prompts
agt lint-policy policies/                          # valida los ficheros de política

agt red-team es el comando en el que más insistiría, porque es la pieza que ningún otro elemento de la pila de gobernanza de Microsoft ofrece hoy: un escaneo adversarial automatizado de tus propios prompts antes del despliegue, no después de un informe de incidente. Conecta agt scan a la misma GitHub Action que ya ejecuta tus pruebas unitarias y las violaciones de política se detectan en el pull request, no a las dos de la madrugada.

¿Qué comprobar antes de llevarlo a producción?

Tres cosas, en orden, antes de que esto se acerque a un tenant real:

1. Confirma que es el repositorio oficial. El propio README es inusualmente directo al respecto: las únicas fuentes oficiales son github.com/microsoft/agent-governance-toolkit, el usuario de PyPI agentgovtoolkit y el paquete npm @microsoft/agent-governance-sdk. El proyecto declara explícitamente que sus mantenedores no avalan sitios de terceros ni forks que usen el nombre. Cinco segundos de comprobación antes de que alguien del equipo ejecute un pip install desde un enlace pegado en un chat.
2. Lee docs/LIMITATIONS.md antes que el material de marketing. Un proyecto que publica sus propias limitaciones conocidas te está diciendo algo útil. AGT lo hace — tómale la palabra sobre lo que no cubre y añade capas en consecuencia.
3. Decide quién es dueño de los ficheros de política. policy.yaml es ahora un control de seguridad, no un fichero de configuración. Necesita el mismo proceso de revisión que le darías a una regla de firewall, no el que le darías a un linter.

Dónde encaja esto en tu hoja de ruta de cumplimiento

Asesoro a empresas europeas exactamente en esta costura — donde termina la gobernanza de plataforma (A365, Purview, Entra) y tiene que empezar el control a nivel de aplicación —, y AGT es el primer proyecto de código abierto que la nombra con precisión, en lugar de fingir que los controles de plataforma ya cubren todo. No sustituye el trabajo de identidad y cumplimiento que ya te vende Microsoft: cubre la parte que ese trabajo nunca estuvo diseñado para alcanzar, la acción individual, evaluada en menos de un milisegundo, antes de que se ejecute.

Si estás desplegando agentes personalizados sobre Azure AI Foundry o Microsoft Agent Framework y no tienes del todo claro dónde termina tu inventario de IA — el que exige el Artículo 29 — y dónde empieza el control de acciones que un auditor de la Ley de IA de la UE te va a pedir ver, esa es una conversación que conviene tener antes de que el primer agente con permisos de escritura llegue a producción. Ponte en contacto y mapeamos tu nivel de riesgo real contra la pila que acabas de leer.

Preguntas frecuentes

¿El Agent Governance Toolkit es un producto de Microsoft con soporte comercial?

No. Es un proyecto de código abierto con licencia MIT en public preview, mantenido en GitHub con comunidad en Discord y el triaje de issues habitual de cualquier proyecto OSS — no un producto de Microsoft con SLA. Trátalo como tratarías cualquier dependencia open source crítica: fija versiones, vigila el changelog y no des por hecho que existe soporte comercial.

¿AGT sustituye a Microsoft Entra Agent ID o a Microsoft Agent 365?

No, y el proyecto no lo pretende. Entra Agent ID y Agent 365 gestionan identidad, ciclo de vida y visibilidad a nivel de tenant. AGT gestiona lo que ocurre después de que un agente está autenticado y dentro de tu sistema: evaluación de políticas por acción, autorización basada en intención y pruebas de red-team. La mayoría de los equipos con agentes de criticidad media o alta acabarán usando ambos.

¿Funciona AGT con agentes de Copilot Studio?

No directamente. AGT envuelve llamadas a funciones en código que controlas — Python, .NET u otros SDKs soportados. El lienzo low-code de Copilot Studio no expone ese nivel de enganche, así que sus agentes se gobiernan en la capa de plataforma: Purview DLP, permisos de conector y Entra Agent ID — los límites que conviene dejar puestos antes de publicar están en la lista de verificación de gobernanza de agentes. AGT está pensado para agentes a medida sobre Azure AI Foundry Agent Service, Microsoft Agent Framework o cualquier configuración agnóstica de framework que llame a servidores MCP.

¿Qué pasa con el rendimiento al añadir AGT a un agente existente?

Las cifras publicadas sitúan la evaluación de políticas por debajo de 0,1 ms por acción, en torno a 47.000 operaciones por segundo con 1.000 agentes concurrentes, con unos 15 MB de sobrecarga de memoria por instancia de agente y sin sobrecarga de red añadida — la evaluación ocurre en local y la exportación de telemetría es asíncrona. No es la capa que va a ralentizar tu pipeline.