Gobernar agentes de IA: seguridad y control en entornos empresariales

El mayor riesgo que vemos en organizaciones que están empezando a trabajar con agentes de IA no tiene nada que ver con la tecnología. Tiene que ver con el control: quién sabe qué están haciendo esos agentes, sobre qué datos operan, y quién responde cuando algo sale mal. 

Si no hay gobierno, el agente hace lo que puede, no lo que debería. Y ese problema lleva meses acumulándose en silencio en muchas organizaciones, porque los agentes llegaron antes que las políticas.

Durante el programa preview de Microsoft Agent 365, aparecieron decenas de millones de agentes en registros de organizaciones que ni siquiera sabían que los tenían.

No eran proyectos IT aprobados. Eran herramientas que equipos de ventas, marketing u operaciones habían instalado, configurado y conectado a datos corporativos sin ningún proceso de validación.

Ya lo vimos con el cloud, con las integraciones SaaS, con los primeros bots de automatización. Siempre el mismo ciclo: adopción rápida, gobierno tarde.

Con los agentes de IA, ese ciclo se comprime todavía más. Crear un agente en Copilot Studio lleva minutos: sin código, sin aprobación IT, con acceso directo a correos, documentos, calendarios y sistemas internos. La barrera técnica es mínima. Si no existe una barrera de gobierno, tampoco hay nada que la frene.

El problema no es que los agentes fallen. Es que actúan correctamente según las instrucciones que recibieron, sobre los datos a los que tienen acceso, sin que nadie haya decidido conscientemente si eso debía ocurrir así.

Acompañando a organizaciones en sus primeros despliegues, vemos que estas cuatro situaciones se repiten con una frecuencia que ya no sorprende:

Microsoft ha construido un conjunto de herramientas específicas para gestionar este problema dentro de su ecosistema. No resuelven todo, pero ofrecen una base sólida para organizaciones que trabajan principalmente con M365 y Azure. 

Estas herramientas resuelven el gobierno dentro del ecosistema Microsoft. No resuelven el gobierno cuando el agente usa modelos o servicios externos que procesan datos fuera de Azure.

Uno de los cambios más relevantes de 2026 es que los agentes ya no operan necesariamente dentro de un único ecosistema. Un agente de Copilot Studio puede usar Claude de Anthropic para razonamiento complejo, GPT de OpenAI para generación de contenido y modelos propios de Microsoft para tareas específicas, todo dentro del mismo flujo de trabajo. 

Esa flexibilidad es real y valiosa. Pero tiene una consecuencia directa en el gobierno: el perímetro de control ya no es el tenant de Microsoft. Es cualquier servicio externo al que el agente pueda llamar y cualquier infraestructura donde esos datos puedan procesarse. 

En el caso de los modelos de Anthropic integrados en Microsoft 365 Copilot, la situación está documentada: los datos se procesan en infraestructura de Anthropic fuera de Azure, lo que los pone fuera del EU Data Boundary. Microsoft lo ha resuelto parcialmente desactivando esos modelos por defecto para tenants europeos, pero la decisión de activarlos o no recae en el administrador del tenant, y en muchas organizaciones nadie ha tomado esa decisión de forma consciente. 

El principio general que aplica aquí no es específico de Anthropic: cualquier modelo o servicio externo que un agente utilice para procesar datos corporativos debe estar evaluado, documentado y aprobado por las personas responsables de cumplimiento en la organización. No como trámite burocrático, sino porque si algo sale mal, alguien tiene que poder responder qué decisión se tomó, cuándo y por qué. 

No hace falta un framework de cincuenta páginas. Hace falta que alguien en la organización haya pensado en estas preguntas antes de que el primer agente empiece a actuar de forma autónoma sobre datos corporativos. 

Lo primero es el inventario. Qué agentes están activos en la organización, quién los creó, para qué proceso y con qué accesos. Sin esa fotografía, cualquier política de gobierno opera sobre suposiciones. 

Lo segundo es la política de accesos. Qué datos puede consultar cada agente, en qué condiciones puede actuar sobre ellos y qué acciones requieren confirmación humana antes de ejecutarse. Los agentes heredan los permisos de quien los configura: si no se restringe explícitamente, el acceso por defecto es más amplio de lo que suele ser conveniente.  

Lo tercero es la evaluación de modelos externos. Si un agente usa un modelo que no corre sobre infraestructura Azure europea, esa decisión tiene que estar documentada y validada. Quién lo aprobó, qué datos puede procesar ese modelo y si eso es compatible con las obligaciones de cumplimiento de la organización.

Lo cuarto es la trazabilidad. Los agentes deben generar logs de actividad auditables. Qué hicieron, sobre qué datos y en qué momento. Sin trazabilidad, la gobernanza es declarativa pero no verificable, y en una auditoría eso no es suficiente. 

Lo quinto es el modelo de supervisión. Quién revisa la actividad de los agentes de forma periódica, quién decide cuándo un agente necesita ser ajustado o desactivado y quién responde ante la organización cuando algo no funciona como se esperaba.

Acompañando a organizaciones en sus primeros proyectos de IA, el patrón que más se repite no es falta de tecnología. Es falta de decisiones tomadas antes de que la tecnología estuviera activa.

En la mayoría de los casos, los agentes se despliegan porque alguien del equipo los probó, funcionaron bien en demo y se activaron en producción sin que nadie definiera formalmente qué podían hacer. Las políticas llegan después, cuando ya hay un problema que resolver o una auditoría que responder.

El segundo patrón es la ausencia de un responsable claro. Los agentes de IA no encajan del todo en ninguna estructura organizativa tradicional: no son software desarrollado por IT, no son decisiones de negocio puras, no son herramientas de usuario final estándar. Esa ambigüedad hace que nadie se sienta del todo responsable de lo que hacen. Cuando algo falla, la responsabilidad circula sin encontrar dueño.

El tercero es subestimar el cambio que implica. Un agente que automatiza un proceso manual no solo cambia cómo se hace ese proceso. Cambia quién lo supervisa, cómo se audita y qué pasa cuando el resultado es incorrecto. Son preguntas sin respuesta técnica, que requieren decisiones organizativas que muchas veces se postergan indefinidamente.

El desconocimiento no es negligencia. Es la consecuencia natural de una tecnología que avanza más rápido que la capacidad de cualquier organización para establecer marcos de control. Lo que sí es un riesgo es desplegar sin saber que ese marco no existe todavía. 

En ANCO llevamos más de 45 años ayudando a organizaciones a tomar decisiones tecnológicas con sentido, con independencia del proveedor y con criterio real sobre lo que funciona en producción. Sabemos dónde están los puntos ciegos, qué decisiones hay que tomar antes de desplegar y cómo construir un modelo de gobierno que resista tanto una auditoría como el crecimiento del ecosistema de agentes en los próximos meses. 

Si tu organización está evaluando su primer despliegue de agentes o necesita revisar el gobierno de los que ya tiene activos, podemos acompañarte en ese proceso como parte de nuestra consultoría de IA end-to-end.