53% de Recall: Per Què el Mateix AIOps de Microsoft Confirma que l'Enginyer Segueix 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 el final de la guàrdia humana: un agent que veu l'incident, recorda incidents passats, i et diu què fer.
L'aspecte interessant del paper no és l'arquitectura — la perception layer, el hierarchical memory, el reasoning agent són essencialment ja l'estat de l'art per a sistemes agentic seriosos. El que importa són els números reportats sobre vuit outages reals d'Azure, 8M de tokens, 4.000 esdeveniments crítics:
- Precision: 71,4%
- Recall: 52,8–54,8%
I aquí és on, com a CTO i com a algú que ha portat guàrdia a 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 és substitutiva.
Què signifiquen aquests números a la trinxera
Tradueixo els números al llenguatge de l'on-call:
Precision del 71,4% vol dir que d'entre cada 10 accions que ActionNex recomana, aproximadament 3 són equivocades. No marginalment subòptimes — equivocades. En un outage real, on cada acció modifica l'estat del sistema, executar 3 de cada 10 recomanacions sense filtre humà és com tenir un nou enginyer de guàrdia al qual encara no donaries permisos de production al primer mes.
Recall del 53% és el número més consequent. Vol dir que quasi la meitat de les accions correctes que un equip humà va executar durant aquells outages, el sistema no les va proposar. No es tracta d'errors — es tracta de no veure-les. La meitat del judgment de mitigació necessari per resoldre un incident d'Azure es queda fora de la sortida del model.
Si tu ets el CTO i la postura del proveïdor és "deixa que la IA porti la guàrdia", la lectura immediata és: la IA portarà la primera meitat. La segona meitat — la que distingeix una mitigació parcial d'un service restoration complet — la segueix portant l'enginyer.
Per què aquests números no escalen amb més temps
L'argument optimista és "ja, però són números d'un sistema en pilot, milloraran". Soc escèptic per tres raons concretes que veig cada setmana fent DevOps a una empresa amb infraestructura no trivial.
Primer: la cua llarga d'incidents no es repeteix. ActionNex té un episodic memory de prior incidents. Tot el que cau en patrons coneguts té molta probabilitat d'encertar. Però en sistemes complexos, una part important dels outages que importen són combinacions noves — l'incident que la teva infraestructura mai havia vist en aquesta combinació de regions, dependències, i estat de deploy. Els números agregats amaguen que la precision i recall sobre incidents nous són sistemàticament pitjors que sobre patrons recurrents. Els SREs senior no costen el que costen perquè recordin runbooks; costen el que costen perquè reconeixen patrons que no existien al runbook.
Segon: els incentius del model no s'alineen amb el cost asimètric d'una acció errònia. A producció, una acció equivocada durant un outage no és una predicció equivocada — és una mitigació que potencialment empitjora el blast radius. El cost d'un fals positiu (executar una acció innecessària o danyosa) i el cost d'un fals negatiu (no veure l'acció correcta) no són simètrics, i els objectius d'entrenament de la majoria de models reasoning no els distingeixen bé. Pots optimitzar la precision pujant el threshold, però llavors la recall baixa encara més. No hi ha sortida fàcil només amb més dades.
Tercer: la verificació en runtime no és gratis. Una de les troballes implícites del paper és que les "human-executed actions" són el feedback que millora el sistema. Vol dir, en pla simple: el sistema millora perquè l'enginyer continua jutjant cada recomanació. Si treus l'enginyer del loop, també treus el senyal d'aprenentatge. La IA en operacions necessita l'enginyer no només com a safety net, sinó com a font de gradient.
El contrast amb el paper de visió "self-managing"
He estat llegint en paral·lel un paper de visió de l'IEEE de finals de 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 escolto cada trimestre als comitès de proveïdors. Minimal human intervention. Self-managing. Self-improving. I, com a CTO, l'has de saber traduir.
Quan poses el paper d'ActionNex i el paper de l'IEEE l'un al costat de l'altre, l'asimetria és inevitable: l'un és la realitat empírica del millor sistema en pilot a un dels núvols més grans del món, l'altre és la visió aspiracional. La distància entre els dos és exactament l'espai on viuen els teus enginyers. I és gran. 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
Soc clar: ActionNex i sistemes similars són útils. Els implementaria. Però amb les juntes que la maduresa operacional demana.
El que canvia:
- El primer triage es pot accelerar significativament. Les recomanacions correctes són correctes; en un outage el rellotge és car, i tenir un agent que t'ofereix les hipòtesis més probables abans que tu obris el dashboard és valor real.
- El descobriment de patrons històrics deixa de dependre de la memòria humana. L'episodic memory és exactament la cosa que els humans fem pitjor — recordar quin incident similar va passar fa setze mesos i quina mitigació va funcionar. Aquí la IA bat l'humà clarament.
- La documentació post-mortem es pot generar amb molt menys fricció. El que abans eren tres dies de redacció pot ser un draft revisat en una hora.
El que no canvia:
- L'autoritat de prendre l'acció continua sent humana. Cap mecanisme de governança seriós el 2026 hauria d'autoritzar un agent a executar accions amb blast radius gran sense aprovació humana explícita per al 100% de casos amb confidence < 99%, i la confidence calibrada al 99% sobre incidents nous és una fantasia.
- L'ownership de l'incident continua sent humana. Algú ha de respondre al postmortem. La IA no respon a postmortems. Aquesta és la frontera que no es travessa amb un upgrade de model.
- El judgment 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 candidates; l'humà decideix.
La pregunta que fes-te quan algú et ven un AIOps "autònom"
Quan un proveïdor o un consultor et presenta un sistema AIOps amb el discurs de "self-healing", la pregunta no és "quina precision tens?". La pregunta és:
"En la teva mostra de validació, quants dels casos on el sistema va decidir no actuar, l'acció correcta era no actuar?"
Això és el recall sobre el complement. La majoria de proveïdors no et donaran el número, perquè no és bonic. ActionNex, mèrit per Microsoft, el publica indirectament: 47% dels casos on hi havia una acció correcta, el sistema no la va proposar. No "no actuar" — no veure-la. És un número honest. La majoria de demos comercials t'ensenyen el subset 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 head de DevOps que està rebent pressió per "automatitzar la guàrdia amb IA":
- Implementa AIOps com a copilot, no com a operator. L'agent suggereix; l'enginyer aprova i executa. Cap acció amb blast radius més gran que un canvi reversible es delega autonomament. Aquesta línia s'escriu a la política, no al runbook.
- Mesura recall sobre incidents nous, no sobre el conjunt agregat. Si el teu proveïdor només et reporta números agregats, exigeix la separació entre patrons recurrents i casos nous. La diferència sol ser dramàtica.
- Inverteix en l'enginyer com a font de gradient. Tracta cada decisió humana de mitigació com a dada d'entrenament. El valor del teu equip de SRE no només és resoldre incidents; és generar el corpus que fa que el copilot millori. Si el tractes com a substituible, perds també el flux de millora.
La línia que defenso és simple i, em sembla, ara està empíricament suportada: la IA en DevOps és implementable i té 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ò és cert per a Microsoft sobre Azure, és cert per a la teva infraestructura, gairebé segur amb números més modestos.
L'enginyer no s'està substituint. S'està apalancant. Els equips i els CTOs que entenen la diferència són els que enviaran 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 senior que sàpiguen on la IA augmenta i on no? Parla amb un CTO sobre desplegar un squad nearshore amb maduresa operacional real, no només certificacions de proveïdor.
