53% de Recall: Por Qué el Propio AIOps de 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 operacionales 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 final de la guardia humana: un agente que ve el incidente, recuerda incidentes pasados, y te dice qué hacer.

Lo interesante del paper no es la arquitectura — la perception layer, el hierarchical memory, el reasoning agent son esencialmente ya el estado del arte para sistemas agentic serios. Lo que importa son los números reportados sobre ocho outages reales de Azure, 8M de tokens, 4.000 eventos críticos:

• Precision: 71,4%
• Recall: 52,8–54,8%

Y aquí es donde, como CTO y como alguien que ha llevado guardia a 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 es sustitutiva.

Qué significan estos números en la trinchera

Traduzco los números al lenguaje del on-call:

Precision del 71,4% quiere decir que de cada 10 acciones que ActionNex recomienda, aproximadamente 3 son equivocadas. No marginalmente subóptimas — equivocadas. En un outage real, donde cada acción modifica el estado del sistema, ejecutar 3 de cada 10 recomendaciones sin filtro humano es como tener un ingeniero de guardia recién entrado al que aún no le darías permisos de production en su primer mes.

Recall del 53% es el número más consecuente. Quiere decir que casi la mitad de las acciones correctas que un equipo humano ejecutó durante esos outages, el sistema no las propuso. No se trata de errores — se trata de no verlas. La mitad del judgment de mitigación necesario para resolver un incidente de Azure se queda fuera de la salida del modelo.

Si tú eres el CTO y la postura del proveedor es "deja que la IA lleve la guardia", la lectura inmediata es: la IA llevará la primera mitad. La segunda mitad — la que distingue una mitigación parcial de un service restoration completo — la sigue llevando el ingeniero.

Por qué estos números no escalan con más tiempo

El argumento optimista es "ya, pero son números de un sistema en 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 un episodic memory de prior incidents. Todo lo que cae en patrones conocidos tiene mucha probabilidad de acertar. Pero en sistemas complejos, una parte importante de los outages que importan son combinaciones nuevas — el incidente que tu infraestructura nunca había visto en esta combinación de regiones, dependencias, y estado de deploy. Los números agregados ocultan que la precision y recall sobre incidentes nuevos son sistemáticamente peores que sobre patrones recurrentes. Los SREs 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 equivocada — es una mitigación que potencialmente empeora el blast radius. El coste de un falso positivo (ejecutar una acción innecesaria o dañina) y el coste 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 reasoning no los distinguen bien. Puedes optimizar la precision subiendo el threshold, pero entonces la recall baja aún más. No hay salida fácil sólo con más datos.

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. Quiere decir, en plan simple: el sistema mejora porque el ingeniero sigue juzgando cada recomendación. Si quitas al ingeniero del loop, también quitas la señal de aprendizaje. La IA en operaciones necesita al ingeniero no sólo como safety net, sino como fuente de gradiente.

El contraste con el paper de visión "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 escucho cada trimestre en los comités de proveedores. Minimal human intervention. Self-managing. Self-improving. Y, como CTO, lo tienes que saber traducir.

Cuando pones el paper de ActionNex y el paper del IEEE el uno al lado del otro, la asimetría es inevitable: uno es la realidad empírica del mejor sistema en piloto en una de las nubes más grandes del mundo, el otro es la visión aspiracional. La distancia entre los dos es exactamente el espacio donde viven tus ingenieros. Y es grande. Un recall del 53% no es un sistema "self-managing"; es un sistema que necesita un humano para el 47% restante de cualquier decisión no trivial.

Qué cambia (y qué no) en una práctica DevOps madura

Soy claro: ActionNex y sistemas similares son útiles. Los implementaría. Pero con las juntas que la madurez operacional exige.

Lo que cambia:

• El primer triage se puede acelerar significativamente. Las recomendaciones correctas son correctas; en un outage el reloj es caro, y tener un agente que te ofrezca 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. El episodic memory es exactamente la cosa que los humanos hacemos peor — recordar qué incidente similar pasó hace dieciséis meses y qué mitigación funcionó. Aquí la IA bate al humano claramente.
• La documentación post-mortem se puede generar con mucha menos fricción. Lo que antes eran tres días de redacción puede ser un draft revisado en una hora.

Lo que no cambia:

• La autoridad de tomar la acción sigue siendo humana. Ningún mecanismo de gobernanza serio en 2026 debería autorizar a un agente a ejecutar acciones con blast radius grande sin aprobación humana explícita para el 100% de casos con confidence < 99%, y la confidence calibrada al 99% sobre incidentes nuevos es una fantasía.
• El ownership del incidente sigue siendo humano. Alguien tiene que responder al postmortem. La IA no responde a postmortems. Esa es la frontera que no se cruza con un upgrade de modelo.
• El judgment 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; el humano decide.

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 discurso de "self-healing", la pregunta no es "¿qué precision tienes?". La pregunta es:

"En tu muestra de validación, de los casos donde el sistema decidió no actuar, ¿en cuántos la acció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, mérito a Microsoft, lo publica indirectamente: 47% de los casos donde había una acción correcta, el sistema no la propuso. No "no actuar" — no verla. Es un número honesto. La mayoría de demos comerciales te enseñan el subset donde el sistema brilla.

Esa es la pregunta diagnóstica: si el proveedor no te la puede responder, 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 head de DevOps que está recibiendo presión para "automatizar la guardia con IA":

1. Implementa AIOps como copilot, no como operator. El agente sugiere; el ingeniero aprueba y ejecuta. Ninguna acción con blast radius mayor que un cambio reversible se delega autónomamente. Esa línea se escribe en la política, no en el runbook.
2. Mide recall sobre incidentes nuevos, no sobre el conjunto agregado. Si tu proveedor sólo te reporta números agregados, exige la separación entre patrones recurrentes y casos nuevos. La diferencia suele ser dramática.
3. 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 sólo resolver incidentes; es generar el corpus que hace que el copilot mejore. Si lo tratas como sustituible, pierdes también el flujo de mejora.

La línea que defiendo es simple y, me parece, ahora está empíricamente apoyada: la IA en DevOps es implementable y tiene ROI claro como augmentación. 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, todavía construyen sistemas que necesitan al ingeniero para el 47% restante. Si esto es cierto para Microsoft sobre Azure, es cierto para tu infraestructura, casi seguro con números más modestos.

El ingeniero no se está sustituyendo. Se está apalancando. Los equipos y los CTOs que entienden la diferencia son los que enviarán sistemas fiables 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 augmenta y dónde no? Habla con un CTO sobre desplegar un squad nearshore con madurez operacional real, no sólo certificaciones de proveedor.