Un recall del 53%: per què l'AIOps de Microsoft mateix confirma que l'enginyer continua sent imprescindible
Microsoft acaba de publicar un paper d'enginyeria sobre ActionNex, un «Virtual Outage Manager» desplegat en pilot a Azure que ingereix senyals operacionals multimodals, els comprimeix en esdeveniments crítics i recomana accions de mitigació. És exactament el tipus de sistema que la indústria fa anys que ven com la fi de la guàrdia humana: un agent que veu l'incident, recorda els incidents passats i et diu què has de fer.
L'interessant del paper no és l'arquitectura — capa de percepció, memòria jeràrquica, agent de raonament: essencialment l'estat de l'art de qualsevol sistema agèntic seriós. El que importa són els números que publica sobre vuit outages reals d'Azure, 8M de tokens i 4.000 esdeveniments crítics:
- Precisió: 71,4%
- Recall: 52,8–54,8%
I aquí és on, com a CTO i com algú que ha portat guàrdies en producció a escala enterprise, m'aturo i dic: aquesta és la prova empírica més clara que es pot donar el 2026 que la IA en operacions és implementable, però no substitutiva.
Què signifiquen aquests números a la trinxera
Deixa'm traduir-te els números al llenguatge de la guàrdia:
Una precisió del 71,4% vol dir que, de cada 10 accions que ActionNex recomana, n'hi ha unes 3 d'equivocades. No marginalment subòptimes: equivocades. En un outage real, on cada acció muta l'estat del sistema, executar 3 de cada 10 recomanacions sense filtre humà és com tenir un enginyer de guàrdia acabat d'arribar a qui, el primer mes, encara no donaries permisos de producció.
Un recall del 53% és el número que pesa més. Vol dir que gairebé la meitat de les accions correctes que un equip humà va executar durant aquells outages, el sistema no les va proposar. No són errors: és no veure-les. La meitat del criteri de mitigació que cal per resoldre un incident d'Azure queda fora del que el model produeix.
Si ets el CTO i la postura del proveïdor és «que la IA porti la rotació de guàrdies», la lectura immediata és aquesta: la IA portarà la primera meitat. La segona — la que separa una mitigació parcial d'una restauració completa del servei — la continua portant l'enginyer.
Per què aquests números no escalen amb més temps
L'argument optimista és «ja, però són números de pilot; milloraran». Soc escèptic per tres raons concretes que veig cada setmana fent DevOps en una empresa amb una infraestructura no trivial.
Primera: la cua llarga d'incidents no es repeteix. ActionNex té una memòria episòdica d'incidents anteriors. Tot el que encaixa en patrons coneguts té moltes probabilitats de sortir bé. Però en sistemes complexos, una fracció important dels outages que importen són combinacions noves — l'incident que la teva infraestructura no havia vist mai amb aquesta combinació concreta de regions, dependències i estat de deploy. Els números agregats amaguen que la precisió i el recall sobre incidents nous són sistemàticament pitjors que sobre patrons recurrents. Els SRE sèniors no costen el que costen perquè recordin runbooks; costen el que costen perquè reconeixen patrons que no eren al runbook.
Segona: els incentius del model no s'alineen amb el cost asimètric d'una acció errònia. En producció, una acció equivocada durant un outage no és una predicció fallida: és una mitigació que pot empitjorar el blast radius. El cost d'un fals positiu (executar una acció innecessària o perjudicial) i el d'un fals negatiu (no veure l'acció correcta) no són simètrics, i els objectius d'entrenament de la majoria de models de raonament no els distingeixen bé. Pots apujar la precisió apujant el llindar, però llavors el recall cau encara més. Amb més dades, sense res més, no hi ha sortida fàcil.
Tercera: la verificació en runtime no és gratuïta. Una de les troballes implícites del paper és que les «human-executed actions» són el feedback que millora el sistema. Dit clar: el sistema millora perquè l'enginyer continua jutjant cada recomanació. Si treus l'enginyer del circuit, també n'elimines el senyal d'aprenentatge. La IA en operacions necessita l'enginyer no només com a xarxa de seguretat, sinó com a font de gradient.
Un recall del 53% no és un sistema «self-managing»
He estat llegint en paral·lel un paper de visió de l'IEEE de finals del 2025, AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), que descriu el futur de la disciplina així:
"...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."
És el llenguatge que sento cada trimestre als comitès de seguiment amb proveïdors. Minimal human intervention. Self-managing. Self-improving. I com a CTO l'has de saber traduir.
Posa el paper d'ActionNex i el de l'IEEE l'un al costat de l'altre i l'asimetria és inesquivable: l'un és la realitat empírica del millor sistema en pilot en un dels núvols més grans del món; l'altre, la visió aspiracional. La distància entre tots dos és exactament l'espai on viuen els teus enginyers. I és ampla. Un recall del 53% no és un sistema «self-managing»; és un sistema que necessita un humà per al 47% restant de qualsevol decisió no trivial.
Què canvia (i què no) en una pràctica DevOps madura
Que quedi clar: ActionNex i els sistemes similars són útils. Jo els implementaria. Però amb les costures que exigeix la maduresa operativa.
El que canvia:
- El primer triatge es pot accelerar de debò. Les recomanacions correctes són correctes; en un outage cada minut és car, i tenir un agent que t'ofereix les hipòtesis més probables abans d'obrir el dashboard és valor real.
- El descobriment de patrons històrics deixa de dependre de la memòria humana. La memòria episòdica és exactament allò que els humans fem pitjor: recordar quin incident semblant va passar fa setze mesos i quina mitigació va funcionar. Aquí la IA guanya l'humà amb claredat.
- La documentació del postmortem es pot produir amb molta menys fricció. El que abans eren tres dies d'escriure pot passar a ser un esborrany revisat en una hora.
El que no canvia:
- L'autoritat per actuar continua sent humana. Cap mecanisme de governança seriós, el 2026, hauria d'autoritzar que un agent executi accions amb un blast radius gran sense aprovació humana explícita en el 100% dels casos amb una confiança < 99% — i una confiança del 99% ben calibrada sobre incidents nous és una fantasia.
- La responsabilitat de l'incident continua sent humana. Algú ha de respondre del postmortem, i la IA no respon de postmortems. Aquesta és la línia que no es mou amb un upgrade de model.
- El criteri sobre què és acceptable degradar continua sent humà. La pregunta «què deixem caure perquè la resta sobrevisqui» depèn del context de negoci, del client, del contracte. La IA pot proposar candidats; l'humà decideix.
La pregunta que cal fer quan algú et ven AIOps «autònom»
Quan un proveïdor o un consultor et presenta un sistema AIOps amb el discurs del «self-healing», la pregunta no és «quina precisió teniu?». La pregunta és:
«En el vostre conjunt de validació, dels casos en què el sistema va decidir no actuar, en quants no actuar era la decisió correcta?»
Això és el recall sobre el complement. La majoria de proveïdors no et donaran el número, perquè no llueix. ActionNex — i això cal reconèixer-ho a Microsoft — el publica indirectament: en el 47% dels casos en què hi havia una acció correcta, el sistema no la va proposar. No és que «no actués»: és que no la va veure. És un número honest. La majoria de demos comercials t'ensenyen el subconjunt on el sistema brilla.
Aquesta és la pregunta diagnòstica: si el proveïdor no te la pot respondre, no estàs comprant un sistema d'operacions; estàs comprant una demo.
Què recomanaria aquest trimestre
Tres accions concretes per a un CTO o un responsable de DevOps sota pressió per «automatitzar la guàrdia amb IA»:
- Implementa AIOps com a copilot, no com a operador. L'agent suggereix; l'enginyer aprova i executa. Cap acció amb un blast radius més enllà d'un canvi reversible no es delega de manera autònoma. Aquesta línia s'escriu a la política, no al runbook.
- Mesura el recall sobre incidents nous, no sobre el conjunt agregat. Si el teu proveïdor només et dona números agregats, exigeix-li el desglossament entre patrons recurrents i casos nous. El salt acostuma a ser dramàtic.
- Inverteix en l'enginyer com a font de gradient. Tracta cada decisió humana de mitigació com a dades d'entrenament. El valor del teu equip d'SRE no és només resoldre incidents; és generar el corpus que fa millorar el copilot. Si el tractes com a substituïble, perds també el circuit de millora.
La línia que defenso és simple i ara té suport empíric: la IA en DevOps és implementable i té un ROI clar com a augmentació. No és substitutiva. El paper d'ActionNex no és la prova del fracàs de la IA — és la prova que els proveïdors d'AIOps més capaços del món, amb les millors dades i els millors enginyers, encara construeixen sistemes que necessiten l'enginyer per al 47% restant. Si això val per a Microsoft a Azure, val per a la teva infraestructura, gairebé segur amb números més modestos.
A l'enginyer no se'l substitueix; se li treu més partit que mai. Els equips i els CTO que entenen la diferència són els que posaran en producció sistemes fiables aquesta dècada.
Fonts:
- 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 construint capacitat DevOps/SRE i necessites enginyers sèniors que sàpiguen on la IA augmenta i on no? Parla amb un CTO sobre com desplegar un squad nearshore amb maduresa operativa real, no només amb certificacions de proveïdor.
