Recall del 53%: por qué el AIOps de la propia Microsoft confirma que el ingeniero sigue siendo imprescindible
Microsoft acaba de publicar un paper de ingeniería sobre ActionNex, un "Virtual Outage Manager" desplegado en piloto en Azure que ingiere señales operativas multimodales, las comprime en eventos críticos y recomienda acciones de mitigación. Es exactamente el tipo de sistema que la industria lleva años vendiendo como el fin de la guardia humana: un agente que ve el incidente, recuerda los incidentes pasados y te dice qué hacer.
Lo interesante del paper no es la arquitectura — la capa de percepción, la memoria jerárquica y el agente de razonamiento son, en esencia, el estado del arte de cualquier sistema agéntico serio. Lo que importa son los números reportados sobre ocho outages reales de Azure, 8M de tokens y 4.000 eventos críticos:
- Precisión: 71,4%
- Recall: 52,8–54,8%
Y aquí es donde, como CTO y como alguien que ha llevado la guardia en producción a escala enterprise, me paro y digo: esta es la prueba empírica más clara que se puede dar en 2026 de que la IA en operaciones es implementable, pero no sustitutiva.
Qué significan estos números en la trinchera
Traduzco los números al idioma de la guardia:
Una precisión del 71,4% significa que, de cada 10 acciones que ActionNex recomienda, unas 3 están equivocadas. No marginalmente subóptimas: equivocadas. En un outage real, donde cada acción muta el estado del sistema, ejecutar 3 de cada 10 recomendaciones sin filtro humano es como tener un ingeniero de guardia recién incorporado al que todavía no le darías permisos de producción en su primer mes.
El recall del 53% es el número de más calado. Significa que casi la mitad de las acciones correctas que un equipo humano ejecutó durante esos outages el sistema no llegó a proponerlas. No son errores: son cosas que no vio. La mitad del criterio de mitigación necesario para resolver un incidente de Azure queda fuera de la salida del modelo.
Si eres el CTO y la postura del proveedor es "deja que la IA lleve la guardia", la lectura inmediata es esta: la IA llevará la primera mitad. La segunda — la que distingue una mitigación parcial de una restauración completa del servicio — la sigue llevando el ingeniero.
Por qué estos números no escalan con más tiempo
El contraargumento optimista es "ya, pero son números de piloto, mejorarán". Soy escéptico por tres razones concretas que veo cada semana haciendo DevOps en una empresa con infraestructura no trivial.
Primero: la cola larga de incidentes no se repite. ActionNex tiene una memoria episódica de incidentes previos. Todo lo que cae en patrones conocidos tiene una probabilidad alta de acierto. Pero en sistemas complejos, una fracción importante de los outages que importan son combinaciones nuevas: el incidente que tu infraestructura nunca había visto en esa combinación concreta de regiones, dependencias y estado de despliegue. Los números agregados ocultan que la precisión y el recall sobre incidentes nuevos son sistemáticamente peores que sobre patrones recurrentes. Los SRE senior no cuestan lo que cuestan porque recuerden runbooks; cuestan lo que cuestan porque reconocen patrones que no estaban en el runbook.
Segundo: los incentivos del modelo no se alinean con el coste asimétrico de una acción errónea. En producción, una acción equivocada durante un outage no es una predicción fallida: es una mitigación que potencialmente amplía el blast radius. El coste de un falso positivo (ejecutar una acción innecesaria o dañina) y el de un falso negativo (no ver la acción correcta) no son simétricos, y los objetivos de entrenamiento de la mayoría de modelos de razonamiento no los distinguen bien. Puedes subir la precisión elevando el umbral, pero entonces el recall cae todavía más. Solo con más datos no hay salida fácil.
Tercero: la verificación en runtime no es gratis. Uno de los hallazgos implícitos del paper es que las "human-executed actions" son el feedback que mejora el sistema. Dicho llanamente: el sistema mejora porque el ingeniero sigue juzgando cada recomendación. Si sacas al ingeniero del bucle, eliminas también la señal de aprendizaje. La IA en operaciones necesita al ingeniero no solo como red de seguridad, sino como fuente de gradiente.
Un recall del 53% no es un sistema «self-managing»
He estado leyendo en paralelo un paper de visión del IEEE de finales de 2025, AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), que describe el futuro de la disciplina así:
"...emerging technologies such as generative AI enable fully automated pipeline capable of code generation, error detection, deployment, and performance monitoring with minimal human intervention. ... a future where software systems evolve into self managing, self improving ecosystems."
Es el lenguaje que oigo cada trimestre en los comités de seguimiento con proveedores. Minimal human intervention. Self-managing. Self-improving. Y, como CTO, hay que saber traducirlo.
Pon el paper de ActionNex y el paper del IEEE uno al lado del otro y la asimetría es ineludible: uno es la realidad empírica del mejor sistema en piloto de una de las nubes más grandes del mundo; el otro, la visión aspiracional. La distancia entre ambos es exactamente el espacio donde viven tus ingenieros. Y es ancha. Un recall del 53% no es un sistema «self-managing»; es un sistema que necesita a un humano para el 47% restante de cualquier decisión no trivial.
Qué cambia (y qué no) en una práctica DevOps madura
Que quede claro: ActionNex y los sistemas similares son útiles. Yo los implementaría. Pero con las salvaguardas que exige la madurez operativa.
Lo que cambia:
- El primer triaje se puede acelerar de forma significativa. Las recomendaciones correctas son correctas; en un outage el reloj sale caro, y tener un agente que te pone delante las hipótesis más probables antes de que abras el dashboard es valor real.
- El descubrimiento de patrones históricos deja de depender de la memoria humana. La memoria episódica es justo lo que peor hacemos los humanos: recordar qué incidente parecido ocurrió hace dieciséis meses y qué mitigación funcionó. Aquí la IA gana al humano con claridad.
- La documentación del post-mortem se puede producir con mucha menos fricción. Lo que antes eran tres días de redacción puede convertirse en un borrador que se revisa en una hora.
Lo que no cambia:
- La autoridad para ejecutar la acción sigue siendo humana. Ningún mecanismo de gobernanza serio en 2026 debería autorizar a un agente a ejecutar acciones de gran blast radius sin aprobación humana explícita en el 100% de los casos con confianza < 99%, y una confianza calibrada al 99% sobre incidentes nuevos es una fantasía.
- El ownership del incidente sigue siendo humano. Alguien tiene que responder del postmortem. La IA no responde de postmortems. Esa es la línea que no se mueve con un upgrade de modelo.
- El criterio sobre qué es aceptable degradar sigue siendo humano. La pregunta "qué dejamos caer para que el resto sobreviva" depende del contexto de negocio, del cliente, del contrato. La IA puede proponer candidatos; decide el humano.
La pregunta que hay que hacer cuando alguien te vende un AIOps «autónomo»
Cuando un proveedor o un consultor te presenta un sistema AIOps con el marco de "self-healing", la pregunta no es "¿qué precisión tienes?". La pregunta es:
"En tu conjunto de validación, de los casos en los que el sistema decidió no actuar, ¿en cuántos la decisión correcta era no actuar?"
Eso es el recall sobre el complemento. La mayoría de proveedores no te darán el número, porque no es bonito. ActionNex — y hay que reconocérselo a Microsoft — lo publica indirectamente: en el 47% de los casos en los que existía una acción correcta, el sistema no la propuso. No es que decidiera no actuar: es que no la vio. Es un número honesto. La mayoría de demos comerciales te enseñan el subconjunto donde el sistema brilla.
Esa es la pregunta diagnóstica: si el proveedor no sabe respondértela, no estás comprando un sistema de operaciones; estás comprando una demo.
Qué recomendaría este trimestre
Tres acciones concretas para un CTO o un responsable de DevOps bajo presión para "automatizar la guardia con IA":
- Implementa AIOps como copiloto, no como operador. El agente sugiere; el ingeniero aprueba y ejecuta. Ninguna acción con un blast radius mayor que un cambio reversible se delega de forma autónoma. Esa línea se escribe en la política, no en el runbook.
- Mide el recall sobre incidentes nuevos, no sobre el conjunto agregado. Si tu proveedor solo reporta números agregados, exige la separación entre patrones recurrentes y casos nuevos. La brecha suele ser dramática.
- Invierte en el ingeniero como fuente de gradiente. Trata cada decisión humana de mitigación como dato de entrenamiento. El valor de tu equipo de SRE no es solo resolver incidentes; es generar el corpus que hace mejorar al copiloto. Si lo tratas como sustituible, pierdes también el bucle de mejora.
La línea que defiendo es simple y ahora tiene respaldo empírico: la IA en DevOps es implementable y tiene un ROI claro como potenciador. No es sustitutiva. El paper de ActionNex no es la prueba del fracaso de la IA; es la prueba de que los proveedores de AIOps más capaces del mundo, con los mejores datos y los mejores ingenieros, siguen construyendo sistemas que necesitan al ingeniero para el 47% restante. Si eso es cierto para Microsoft sobre Azure, lo es para tu infraestructura, casi seguro con números más modestos.
Al ingeniero no lo están sustituyendo. Lo están potenciando. Los equipos y los CTO que entienden la diferencia son los que pondrán sistemas fiables en producción esta década.
Fuentes:
- Lin, Z., Hu, H., Hao, M., et al. ActionNex: A Virtual Outage Manager for Cloud Computing. arXiv:2604.03512 (2026). arxiv.org/abs/2604.03512
- Kiran Raj K M, Karthik K Poojary, Abhay, Aishwarya R S, Lathesh Kumar S R. AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines. ICECMSN 2025. DOI:10.1109/ICECMSN68058.2025.11382867
¿Estás construyendo capacidad DevOps/SRE y necesitas ingenieros senior que sepan dónde la IA potencia y dónde no? Habla con un CTO sobre desplegar un squad nearshore con madurez operativa real, no solo certificaciones de proveedor.
