Microsoft publicó el 13 de octubre de 2026 una explicación técnica de un agente de IA para gestionar incidencias de red, con límites de identidad, permisos, herramientas y aprobación humana. Arun Malik, ingeniero principal de Azure Networking, describe el paso de ayudar al diagnóstico a ejecutar acciones en un entorno operativo. Su mensaje central es que ninguna salvaguarda aislada garantiza una autonomía segura.
Se trata de experiencia de ingeniería, no del anuncio de disponibilidad general de un producto nuevo. Su importancia reside en una pregunta para cualquier organización que conecte IA a sus sistemas: ¿saber explicar una solución también autoriza al agente a aplicarla? La respuesta debe estar en el sistema de permisos, no depender de lo convincente que resulte el texto del modelo.
La diferencia entre recomendar y modificar
Un agente que reúne información puede ahorrar al empleado los saltos entre pantallas. Pero, si puede cambiar configuraciones, borrar datos o activar procesos, una respuesta equivocada puede convertirse en un error operativo. Esto importa incluso ante una avería corriente, sin atacante: interpretar mal el contexto puede bastar para actuar donde no corresponde.
Pensemos en un ejemplo hipotético: un agente de soporte identifica varias consultas similares y propone modificar una configuración compartida. La recomendación puede ser razonable, aunque algunos clientes trabajen en entornos distintos. Antes de ejecutarla hay que comprobar el destino exacto y el alcance. Una solución correcta en principio no es necesariamente la acción adecuada para todos.
La decisión práctica consiste en separar la tarea en operaciones. Leer, preparar una propuesta, crear un borrador y aplicar un cambio son permisos diferentes. El agente puede avanzar deprisa en las primeras fases, mientras que el paso que modifica la realidad queda sujeto a otra comprobación. Así se obtiene utilidad sin conceder un control amplio desde el principio.
Los permisos deben estar fuera de la conversación
OWASP considera que la autonomía excesiva de las aplicaciones con modelos de lenguaje puede derivarse de demasiadas capacidades, permisos o independencia. Recomienda reducir las facultades y exigir aprobación humana para acciones de gran impacto. Esto ayuda a distinguir entre pedir prudencia al agente y establecer un límite que el sistema haga cumplir.
Por ejemplo, una instrucción interna de no tocar otras carpetas no basta si la conexión permite acceder a todas. Conviene asignar una cuenta específica y un acceso adecuado a la función, y comprobar que se bloquean las operaciones fuera de ese ámbito. La prueba debe funcionar aunque la petición parezca normal y razonable.
También hay que distinguir entre quien inicia la tarea y la identidad que la ejecuta. Un empleado puede solicitar un análisis sin estar autorizado a aprobar un borrado. Si el agente recibe automáticamente permisos de administrador para completar cualquier solicitud, desaparece el límite organizativo justo donde hace falta supervisión. Una responsabilidad clara facilita decidir quién puede modificar sus permisos.
La aprobación humana debe plantear una decisión real
Un botón de aprobación no garantiza que la persona haya entendido lo que sucederá. La pantalla debería mostrar qué cambiará, dónde, con qué alcance y qué se sabe sobre la posibilidad de restaurar el estado anterior. Una explicación genérica, como mejorar el servicio, dificulta detectar acciones que se apartan de la intención original.
La aprobación debe entenderse como el consentimiento para un cambio concreto, no como permiso abierto para terminar la tarea de cualquier manera. Si después el agente cambia el destino o la operación, hay que revisar la decisión. En una organización pequeña puede comprobarlo otra persona; en una grande puede integrarse en el procedimiento habitual.
La frecuencia también importa. Si cada consulta sencilla exige pulsar un botón, los empleados pueden acostumbrarse a aprobar sin leer. Es preferible definir qué operaciones pueden continuar dentro de ciertos límites y cuáles requieren una pausa. El objetivo es concentrar la atención humana donde equivocarse tiene consecuencias, sin convertir la aprobación en un trámite automático.
Qué comprobar antes de conectar un sistema operativo
Un buen comienzo es un entorno de pruebas con información no sensible y permisos limitados. No basta con comprobar si el agente resuelve una tarea válida: hay que observar cómo responde a datos incompletos, instrucciones contradictorias o una herramienta no disponible. Un sistema que se detiene para pedir aclaraciones puede ser más útil que otro que sigue adivinando hasta terminar.
Después conviene revisar la secuencia de operaciones, no solo el resultado. Dos recorridos pueden producir el mismo documento, pero uno puede haber leído información innecesaria o intentado un cambio no autorizado. Un registro adecuado permite distinguirlos sin convertir el historial de actividad en otro almacén de datos sensibles.
Antes de ampliar el uso, hay que establecer quién puede detener al agente, cómo retirar su acceso y quién se encargará de corregir un cambio erróneo. No siempre es posible volver atrás: un mensaje enviado quizá ya se haya leído y los datos exportados no siempre se recuperan. Las pruebas de recuperación deben influir en los permisos iniciales.
Qué significa para los equipos en Israel
Un equipo de TI, una empresa con una plataforma de atención o una organización que prueba automatizaciones no necesita copiar la infraestructura de una compañía de nube. Puede empezar por una tarea acotada, definir el resultado y escribir con claridad lo que el agente no debe hacer. Después debe verificar que la conexión técnica respeta esa definición. Conviene revisar los límites cada vez que se añada una conexión o cambie la tarea. Aprobar un flujo limitado no implica que uno ampliado sea adecuado para los mismos permisos, responsable de aprobación o mecanismo de parada.
Al hablar con un proveedor, conviene pedir una demostración de bloqueo, además de una de éxito. ¿Qué ocurre si la tarea exige una operación no autorizada? ¿Quién ve el rechazo? ¿Se puede retirar el acceso sin eliminar todo el flujo? Las respuestas concretas son más útiles que una promesa genérica de contar con una capa de seguridad.
La publicación de Microsoft no demuestra que todos sus agentes, ni los de otros proveedores, estén protegidos contra cualquier fallo. Destaca una decisión de diseño de alcance general: la autonomía también se mide por lo que el sistema impide. El avance relevante no consiste solo en automatizar otra tarea, sino en poder explicar y limitar cómo se ha realizado.