Artículo
Microsoft prueba AutoNet para gestionar redes
Microsoft publicó el 22 de octubre de 2026 un caso interno sobre AutoNet, firmado por Alex Fleck. Describe un piloto limitado que reúne solicitudes en lenguaje natural, datos de red y agentes especializados. Según la empresa, la IA interpreta y coordina; la automatización existente ejecuta pasos deterministas y un ingeniero debe aprobar antes de cambiar configuraciones. Entre sus componentes, IP Helper recupera datos de red y Core WAN gestiona plantillas de configuración.
Qué hacen DHCP y un relay
DHCP es un protocolo para que un equipo obtenga una dirección IP y otros parámetros de red. El cliente es el equipo que los solicita; el servidor los proporciona. Cuando están en redes distintas, un relay, o agente de retransmisión, lleva los mensajes entre ambos: evita necesitar un servidor en cada segmento de red. No es quien decide por sí solo la dirección que recibirá el cliente.
En nuestro ejemplo, si el relay envía la petición hacia un destino equivocado, esta podría no llegar al servidor que debe atenderla y quedar sin respuesta. Por eso importa identificar el equipo y revisar el destino antes de proponer un cambio.
Referencia técnica: RFC 2131, apartados 1 y 1.5.
Una petición comprensible todavía necesita un objeto exacto
Ejercicio editorial original e hipotético. Una sucursal quiere cambiar el destino al que su relay DHCP remite las solicitudes de asignación de red. El inventario atribuye esa función a un equipo, pero la consulta de su configuración señala otro. No hemos intervenido una red ni probado AutoNet: construiremos un expediente para decidir qué falta antes de autorizar el cambio.
La petición puede expresarse con claridad y seguir incompleta. «Actualiza el relay de la sucursal» identifica una intención, pero no demuestra qué dispositivo corresponde modificar. Antes de proponer una operación, nuestro expediente necesita relacionar la sucursal, la función de red y el equipo observado.
La conversación sirve para formular preguntas. La respuesta tiene que conservar los límites de lo encontrado: qué registro se consultó, qué equipo respondió y a qué momento corresponde cada observación. Una descripción convincente no sustituye esa relación.
Resuelve la contradicción sin elegir el dato más cómodo
En nuestro caso, la ficha de inventario conserva una asignación anterior y la lectura actual apunta a un equipo distinto. Podría existir una migración sin documentar, una etiqueta reutilizada o una consulta dirigida al lugar equivocado. Son hipótesis del ejercicio; todavía no sabemos cuál explica la diferencia.
Guardaríamos ambas evidencias y pediríamos al responsable de la sucursal que confirme la identidad y el alcance. La comparación debe permitir reconocer el mismo objeto entre registros. Si sólo coinciden nombres parecidos, el expediente permanece pendiente.
El criterio para continuar sería concreto: una persona responsable puede explicar por qué el equipo observado cumple esa función en esa sucursal y respaldarlo con información revisable. Actualizar el inventario para que deje de mostrar el conflicto no basta para demostrar que lo resolvimos.
Separa lo observado del estado que deseas
Una vez aclarada la identidad, describiríamos por separado la situación actual y el resultado buscado. El estado observado incluye el destino registrado y los elementos de la configuración pertinentes al cambio. El estado deseado explica qué destino debería recibir las solicitudes y qué comportamiento necesitamos comprobar después.
También anotaríamos qué debe conservarse. Un cambio acotado puede tener como requisito que otras sucursales y funciones permanezcan fuera del alcance. Esa condición ayuda a revisar una propuesta que parece correcta por su objetivo, pero incorpora modificaciones adicionales.
Para preparar el documento podemos utilizar etiquetas como «destino actual» y «destino propuesto». Este ejercicio no necesita direcciones ni instrucciones ejecutables. Lo que debe quedar claro es la diferencia solicitada, su justificación y la evidencia que todavía falta.
Convierte la propuesta en un expediente revisable
La siguiente tabla propone un formato para nuestro caso. Cada fila debe apuntar a material verificable del expediente; sus contenidos son ejemplos editoriales, no datos de una instalación real.
| Parte del expediente | Qué debe explicar | Motivo para detenerse |
|---|---|---|
| Identidad y alcance | Qué equipo cumple la función en la sucursal y cómo se confirmó. | Inventario y observación siguen sin conciliarse. |
| Diferencia propuesta | Qué destino cambiaría y qué configuración debe conservarse. | Aparecen modificaciones ajenas a la petición. |
| Reversión | Qué estado anterior se conserva y cuándo corresponde volver a él. | No existe una referencia fiable del estado previo. |
| Aprobación | Qué versión exacta revisó la persona autorizada. | La propuesta cambió después de la revisión. |
| Comprobación | Qué observaciones permitirían aceptar o rechazar el resultado. | Sólo hay un mensaje de finalización, sin evidencia del servicio. |
Esta estructura permite revisar una decisión sin reconstruirla desde una conversación extensa. Las preguntas pendientes forman parte del expediente; no deben desaparecer al producir una versión más presentable.
Diseña la vuelta atrás antes de pedir permiso
En la propuesta conservaríamos una referencia del estado anterior y un procedimiento de reversión que el equipo responsable pueda revisar. Definiríamos qué observación justificaría detener la intervención, quién toma esa decisión y cómo comprobaría que el servicio quedó en un estado aceptable.
Volver a una configuración anterior tampoco equivale automáticamente a recuperar el servicio. Durante el intervalo podrían haber cambiado otras condiciones. Por eso el expediente necesita una comprobación posterior a la reversión, además de una descripción de cómo regresar.
Si no podemos explicar esa salida con la evidencia disponible, reduciríamos el alcance de la propuesta o la devolveríamos para completar información. Es una decisión de preparación del caso, no una demostración de que la herramienta disponga de ese control.
Aprueba una versión, no una intención general
La persona autorizada debería recibir la propuesta, sus evidencias, los pendientes y la reversión prevista. La aprobación tendría que identificar la versión revisada. Si luego cambia el equipo objetivo, el destino o el alcance, necesitamos revisar otra vez qué se está autorizando.
Conservaríamos quién decidió y en qué condiciones. Pedir ayuda para redactar un cambio y conceder permiso para aplicarlo son decisiones diferentes dentro del ejercicio. Una respuesta que aclare el objetivo todavía puede dejar pendiente la autorización operativa.
La lectura sobre cómo verificar el contexto antes de actuar sobre un incidente permite conectar este ejercicio con otra situación de operaciones. Para nuestra sucursal, la pregunta sigue siendo específica: ¿qué versión y qué objeto puede revisar quien asume la decisión?
Una ejecución predecible puede recibir una entrada equivocada
Supongamos que el cambio obtiene aprobación. En nuestro diseño, la ejecución recibiría únicamente los parámetros y la versión aceptados. Antes de actuar, debería comprobar que el estado pertinente sigue siendo compatible con esa propuesta. Si la situación cambió, el permiso anterior puede resultar insuficiente.
La expresión «ejecución determinista» no demuestra por sí sola que la decisión sea correcta. Un procedimiento repetible puede trabajar sobre el equipo equivocado si la identidad se resolvió mal. Por eso conservamos la comprobación inicial y la relación entre propuesta, aprobación y operación.
Si la solicitud queda sin una respuesta concluyente, no asumiríamos ni éxito ni fracaso. Registraríamos el estado pendiente y buscaríamos evidencia de lo que ocurrió antes de volver a solicitar una operación. Repetir por intuición podría crear un segundo efecto.
Comprueba el servicio y conserva la evidencia
La revisión posterior tendría que contrastar el estado observado con el resultado esperado. En el caso hipotético, preguntaríamos si las solicitudes llegan al destino previsto y si el servicio de la sucursal responde como se definió. También revisaríamos las condiciones que debían conservarse fuera del cambio.
Un registro que diga «terminado» acredita un estado del procedimiento, pero no responde todas esas preguntas. El expediente debe permitir vincular las observaciones con el equipo y la versión autorizados. Si falta una comprobación, el cierre mantiene ese pendiente.
La lectura sobre por qué proteger la evidencia al revisar agentes complementa esta decisión editorial: conservar el material necesario para que otra persona pueda discutir la conclusión.
Mide trabajo aceptado, incluyendo las correcciones
Para evaluar una futura prueba, registraríamos el tiempo de reunir información, resolver contradicciones, revisar la propuesta y comprobar el resultado. Contar sólo cuánto tarda en aparecer un borrador dejaría fuera tareas esenciales del cambio.
También conservaríamos propuestas devueltas, errores de identidad, diferencias no previstas y preguntas que evitaron continuar sin información suficiente. Compararíamos casos de dificultad semejante con el procedimiento habitual. No hay mediciones realizadas en este ejercicio; cualquier mejora seguiría pendiente de observación.
Practica con un expediente que otra persona entienda
Elige una petición ficticia y escribe qué evidencia necesitarías para identificar el objeto, aprobar una diferencia y aceptar el resultado. Añade una contradicción de inventario y explica qué dato permitiría resolverla. Así la conversación termina en preguntas que alguien puede comprobar.
Entra a la Comunidad de Álvaro y comparte tu expediente propuesto, su criterio de aceptación y el pendiente que todavía impide cerrarlo.
Fuente: Microsoft Inside Track, Alex Fleck.
