Microsoft ha pedido a las empresas que traten a los agentes de inteligencia artificial como un nuevo tipo de riesgo interno. La idea no es que un agente sea malicioso por definición, sino que, al recibir acceso a datos, aplicaciones y herramientas, puede cometer errores, ser manipulado o actuar de forma imprevista a velocidad de máquina.
La compañía ha presentado esta posición dentro de su estrategia de seguridad para agentes, ligada a Project Perception y a nuevas funciones de supervisión. Su argumento central es claro: los modelos avanzados se optimizan para cumplir objetivos, pero no conocen por sí mismos las normas, prioridades y límites de cada organización. Confiar en que el propio modelo se autorregule no es suficiente.
Microsoft plantea separar la inteligencia que genera una respuesta de la autoridad que decide qué datos puede ver un agente y qué acciones puede ejecutar. En la práctica, los permisos y controles deberían vivir fuera del modelo, de modo que este no pueda modificarlos ni eludirlos cuando cambie el contexto de una tarea.
La advertencia llega cuando los agentes empiezan a pasar de asistentes de texto a sistemas que consultan bases de datos, preparan informes, procesan gastos, escriben código o interactúan con otras aplicaciones. Esa autonomía les da utilidad, pero también amplía la superficie de ataque. Una instrucción maliciosa en un documento, un permiso excesivo o una identidad mal gestionada pueden convertir una tarea rutinaria en una incidencia de seguridad.
Microsoft propone visibilidad continua sobre la actividad de los agentes, evaluación dinámica del riesgo y controles adaptativos. Entre los elementos relevantes figuran un registro unificado de agentes, la monitorización de sus acciones y mecanismos independientes para decidir si deben conservar acceso. Son principios conocidos en seguridad de identidades, aplicados ahora a un software cuyo comportamiento puede variar con la conversación y las herramientas disponibles.
La lección para las compañías no es frenar la automatización, sino diseñarla con el mismo rigor con el que se concede acceso a un empleado o a un proveedor externo. Un agente que consulta información comercial no necesita necesariamente autorizar pagos, borrar archivos o enviar mensajes a clientes. Limitar privilegios y dividir funciones reduce el impacto si algo falla.
El enfoque también tiene una dimensión comercial. Microsoft vende infraestructura y productos de seguridad, por lo que su propuesta refuerza su posición frente a otros proveedores de modelos y plataformas. Aun así, el problema que señala es real y no pertenece a una sola marca. Cualquier organización que conecte agentes a sistemas críticos debe decidir quién les da identidad, cómo se revisan sus acciones y qué ocurre si se desvían del objetivo inicial.
Para las empresas españolas, la cuestión encaja además con obligaciones de protección de datos, ciberseguridad y gobierno corporativo. Antes de desplegar un agente conviene definir el inventario de herramientas a las que tendrá acceso, un responsable humano, límites de gasto, registros auditables y un procedimiento para detenerlo. Son controles simples sobre el papel, pero a menudo se omiten cuando un piloto se convierte en producto interno.
La confianza en un agente no debe basarse en que el modelo parezca competente, sino en que sus permisos, trazas y límites puedan revisarse de forma independiente. Esa distinción será especialmente importante en finanzas, salud, administración pública y cualquier actividad con decisiones que afecten a personas.
La adopción de agentes continuará porque su potencial para eliminar tareas repetitivas es considerable. La advertencia de Microsoft sirve como recordatorio práctico: cuanto mayor sea la capacidad de actuar, mayor debe ser la disciplina de seguridad. Diseñar esa arquitectura antes del despliegue resulta mucho menos costoso que reconstruirla después de una incidencia.
