Michael JohnsonUn agente de IA puede determinar por qué falla una conexión de red y luego proponer una solución que afecte a la infraestructura en funcionamiento. En un artículo de ingeniería del 13 de octubre, Microsoft describió una arquitectura por capas en la que reglas de software independientes limitan el acceso del agente y verifican sus acciones.
El autor del artículo, Arun Malik, ingeniero principal de Azure Networking en Microsoft, analiza un escenario de conexión inestable en un centro de datos. El agente recopila el estado de los dispositivos y la telemetría, compara los cambios recientes, clasifica el fallo y prepara un resumen. Después, el sistema puede pasar a la corrección —por ejemplo, desactivar una sesión BGP en un dispositivo que transporta tráfico de usuarios— mediante los mecanismos de control previstos en la arquitectura.
Microsoft describe cuatro límites: identidad, herramientas, cambios y tiempo. El agente opera dentro de los permisos de la persona que lo invocó, accede a los sistemas mediante una interfaz controlada, se detiene antes de modificar el estado de producción para pedir aprobación humana y, con el tiempo, los procedimientos repetitivos que hayan dado buenos resultados pueden fijarse como flujos deterministas.
Los permisos del agente se ajustan a los del usuario
El primer límite son las credenciales. En el esquema propuesto, el agente actúa en nombre del usuario y no obtiene más permisos que él. Si se necesita una cuenta de servicio, sus permisos deben ser aún más restringidos. Esto limita las consecuencias de un error o de texto malicioso en los registros y las respuestas de las herramientas: el modelo no puede obtener privilegios que no tenga el usuario o la cuenta específica.
El segundo límite son las herramientas. Cada operación se implementa mediante una interfaz tipada, pasa por una autorización independiente, acepta datos estructurados y deja un registro de auditoría. Malik aclara que lo que se restringe no es la línea de comandos en sí, sino el acceso no controlado a la shell: un comando específico puede ofrecerse como herramienta controlada, mientras que una shell abierta dificulta la separación de permisos y la auditoría.
La lectura y los cambios requieren reglas distintas
En la arquitectura descrita, el diagnóstico puede realizarse automáticamente. Una acción que cambie el estado de un sistema de producción se detiene hasta que una persona la apruebe. Según el autor, esta restricción debe aplicarse mediante el código del entorno de ejecución, y no solo mediante instrucciones al modelo. El modelo puede interpretar la salida no estructurada de un dispositivo, pero la lógica del software se encarga de decidir qué acción tomar y comprobar los permisos.
El artículo presenta un ejemplo con una interfaz de red: el modelo convierte la salida de un comando en campos estructurados, un validador los compara con un esquema y una condición determinista selecciona el siguiente paso. Si ese paso cambia la configuración, la ejecución espera a que alguien lo apruebe. Así, el texto de la tarea queda separado de los permisos para modificar la red.
El cuarto límite tiene que ver con la repetibilidad. Microsoft propone fijar las rutas de diagnóstico ya validadas como flujos deterministas que, en casos conocidos, pueden ejecutarse sin volver a invocar el modelo. Según la empresa, esto reduce el coste de repetir el razonamiento, mejora la reproducibilidad y disminuye la superficie de error y ataque. La publicación no presenta resultados cuantitativos de implementaciones en producción.
Qué conviene comprobar al implementar este enfoque
El artículo de Microsoft es una descripción de ingeniería de una arquitectura y un escenario, no una evaluación independiente de la fiabilidad de un producto terminado. Para los equipos que diseñan sus propios agentes, el orden práctico es vincular las acciones a la identidad del usuario, enumerar las operaciones permitidas, tipar y registrar las llamadas, separar lectura y escritura y exigir confirmación explícita para los cambios. Los casos repetitivos pueden convertirse en flujos convencionales después de verificar las condiciones de ejecución y el resultado.
La conclusión principal es la separación de funciones: el modelo ayuda a analizar un incidente desconocido y a generar una salida estructurada, mientras que el sistema de ejecución determina qué operaciones están permitidas y cuándo se necesita aprobación. Microsoft propone esta separación para pasar de las sugerencias al operador a una automatización limitada de la infraestructura de red.