53% di Recall: Perché l'AIOps di Microsoft Stesso Conferma che l'Ingegnere Resta Indispensabile

Microsoft ha appena pubblicato un paper di ingegneria su ActionNex, un "Virtual Outage Manager" dispiegato in pilot su Azure che ingerisce segnali operazionali multimodali, li comprime in eventi critici e raccomanda azioni di mitigazione. È esattamente il tipo di sistema che l'industria vende da anni come la fine del reperibilità umana: un agente che vede l'incidente, ricorda incidenti passati, e ti dice cosa fare.

L'aspetto interessante del paper non è l'architettura — la perception layer, l'hierarchical memory, il reasoning agent sono essenzialmente già lo stato dell'arte per sistemi agentici seri. Ciò che importa sono i numeri riportati su otto outage reali di Azure, 8M di token, 4.000 eventi critici:

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

Ed è qui dove, come CTO e come qualcuno che ha portato la reperibilità in produzione su scala enterprise, mi fermo e dico: questa è la prova empirica più chiara che si può dare nel 2026 che l'IA in operations è implementabile, ma non è sostitutiva.

Cosa significano questi numeri in trincea

Traduco i numeri nel linguaggio dell'on-call:

Precision del 71,4% significa che di ogni 10 azioni che ActionNex raccomanda, circa 3 sono sbagliate. Non marginalmente sub-ottimali — sbagliate. In un outage reale, dove ogni azione modifica lo stato del sistema, eseguire 3 di 10 raccomandazioni senza filtro umano è come avere un ingegnere di reperibilità appena entrato a cui non daresti ancora i permessi di production nel suo primo mese.

Recall del 53% è il numero più conseguente. Significa che quasi metà delle azioni corrette che un team umano ha eseguito durante quegli outage, il sistema non le ha proposte. Non si tratta di errori — si tratta di non vederle. Metà del judgment di mitigazione necessario per risolvere un incidente Azure rimane fuori dall'output del modello.

Se sei il CTO e la posizione del fornitore è "lascia che l'IA porti la reperibilità", la lettura immediata è: l'IA porterà la prima metà. La seconda metà — quella che distingue una mitigazione parziale da un service restoration completo — la continua a portare l'ingegnere.

Perché questi numeri non scalano col tempo

L'argomento ottimista è "sì, ma sono numeri di un sistema in pilot, miglioreranno". Sono scettico per tre ragioni concrete che vedo ogni settimana facendo DevOps in un'azienda con infrastruttura non triviale.

Primo: la coda lunga di incidenti non si ripete. ActionNex ha un episodic memory di prior incidents. Tutto ciò che cade in pattern conosciuti ha alta probabilità di azzeccare. Ma in sistemi complessi, una parte importante degli outage che importano sono combinazioni nuove — l'incidente che la tua infrastruttura non aveva mai visto in questa combinazione di regioni, dipendenze, e stato di deploy. I numeri aggregati nascondono che la precision e il recall su incidenti nuovi sono sistematicamente peggiori che su pattern ricorrenti. I SRE senior non costano quanto costano perché ricordano runbook; costano quanto costano perché riconoscono pattern che non erano nel runbook.

Secondo: gli incentivi del modello non si allineano col costo asimmetrico di un'azione errata. In produzione, un'azione sbagliata durante un outage non è una predizione sbagliata — è una mitigazione che potenzialmente peggiora il blast radius. Il costo di un falso positivo (eseguire un'azione non necessaria o dannosa) e il costo di un falso negativo (non vedere l'azione corretta) non sono simmetrici, e gli obiettivi di training della maggior parte dei modelli reasoning non li distinguono bene. Puoi ottimizzare la precision alzando il threshold, ma allora il recall scende ancora di più. Non c'è uscita facile solo con più dati.

Terzo: la verifica in runtime non è gratis. Una delle scoperte implicite del paper è che le "human-executed actions" sono il feedback che migliora il sistema. In modo semplice: il sistema migliora perché l'ingegnere continua a giudicare ogni raccomandazione. Se togli l'ingegnere dal loop, togli anche il segnale di apprendimento. L'IA in operations ha bisogno dell'ingegnere non solo come safety net, ma come fonte di gradiente.

Il contrasto col paper di visione "self-managing"

Ho letto in parallelo un paper di visione dell'IEEE di fine 2025, AI-Driven DevOps for Intelligent Automation in Continuous Software Delivery Pipelines (Kiran Raj K M et al., ICECMSN 2025), che descrive il futuro della disciplina così:

"...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."

È il linguaggio che sento ogni trimestre nei comitati dei fornitori. Minimal human intervention. Self-managing. Self-improving. E, come CTO, lo devi saper tradurre.

Quando metti il paper di ActionNex e il paper dell'IEEE uno accanto all'altro, l'asimmetria è inevitabile: uno è la realtà empirica del miglior sistema in pilot in uno dei cloud più grandi del mondo, l'altro è la visione aspirazionale. La distanza tra i due è esattamente lo spazio dove vivono i tuoi ingegneri. Ed è grande. Un recall del 53% non è un sistema "self-managing"; è un sistema che ha bisogno di un umano per il 47% restante di qualsiasi decisione non triviale.

Cosa cambia (e cosa no) in una pratica DevOps matura

Sono chiaro: ActionNex e sistemi simili sono utili. Li implementerei. Ma con le giunture che la maturità operazionale richiede.

Cosa cambia:

• Il primo triage si può accelerare significativamente. Le raccomandazioni corrette sono corrette; in un outage l'orologio è caro, e avere un agente che ti offre le ipotesi più probabili prima che apri il dashboard è valore reale.
• La scoperta di pattern storici smette di dipendere dalla memoria umana. L'episodic memory è esattamente la cosa che gli umani facciamo peggio — ricordare quale incidente simile è successo sedici mesi fa e quale mitigazione ha funzionato. Qui l'IA batte l'umano chiaramente.
• La documentazione post-mortem si può generare con molta meno frizione. Quel che prima erano tre giorni di redazione può diventare una bozza rivista in un'ora.

Cosa non cambia:

• L'autorità di prendere l'azione resta umana. Nessun meccanismo di governance serio nel 2026 dovrebbe autorizzare un agente a eseguire azioni con grande blast radius senza approvazione umana esplicita per il 100% dei casi con confidence < 99%, e la confidence calibrata al 99% su incidenti nuovi è una fantasia.
• L'ownership dell'incidente resta umano. Qualcuno deve rispondere al postmortem. L'IA non risponde ai postmortem. Quella è la frontiera che non si attraversa con un upgrade di modello.
• Il judgment su cosa è accettabile degradare resta umano. La domanda "cosa lasciamo cadere perché il resto sopravviva" dipende dal contesto di business, dal cliente, dal contratto. L'IA può proporre candidati; l'umano decide.

La domanda da fare quando qualcuno ti vende un AIOps "autonomo"

Quando un fornitore o un consulente ti presenta un sistema AIOps col discorso del "self-healing", la domanda non è "che precision hai?". La domanda è:

"Nel tuo campione di validazione, dei casi dove il sistema ha deciso di non agire, in quanti l'azione corretta era non agire?"

Questo è il recall sul complemento. La maggior parte dei fornitori non ti darà il numero, perché non è bello. ActionNex, merito a Microsoft, lo pubblica indirettamente: 47% dei casi dove c'era un'azione corretta, il sistema non l'ha proposta. Non "non agire" — non vederla. È un numero onesto. La maggior parte delle demo commerciali ti mostrano il subset dove il sistema brilla.

Quella è la domanda diagnostica: se il fornitore non ti può rispondere, non stai comprando un sistema di operations, stai comprando una demo.

Cosa raccomanderei questo trimestre

Tre azioni concrete per un CTO o head di DevOps che riceve pressione per "automatizzare la reperibilità con l'IA":

1. Implementa AIOps come copilot, non come operator. L'agente suggerisce; l'ingegnere approva ed esegue. Nessuna azione con blast radius più grande di un cambio reversibile si delega autonomamente. Quella linea si scrive nella politica, non nel runbook.
2. Misura il recall su incidenti nuovi, non sull'insieme aggregato. Se il tuo fornitore riporta solo numeri aggregati, esigi la separazione tra pattern ricorrenti e casi nuovi. La differenza è solitamente drammatica.
3. Investi nell'ingegnere come fonte di gradiente. Tratta ogni decisione umana di mitigazione come dato di training. Il valore del tuo team SRE non è solo risolvere incidenti; è generare il corpus che rende il copilot migliore. Se lo tratti come sostituibile, perdi anche il flusso di miglioramento.

La linea che difendo è semplice e, mi sembra, ora è empiricamente supportata: l'IA in DevOps è implementabile e ha ROI chiaro come augmentazione. Non è sostitutiva. Il paper di ActionNex non è la prova del fallimento dell'IA — è la prova che i fornitori di AIOps più capaci del mondo, con i migliori dati e i migliori ingegneri, costruiscono ancora sistemi che hanno bisogno dell'ingegnere per il 47% restante. Se questo è vero per Microsoft su Azure, è vero per la tua infrastruttura, quasi certamente con numeri più modesti.

L'ingegnere non si sta sostituendo. Si sta facendo leva. I team e i CTO che capiscono la differenza sono quelli che spediranno sistemi affidabili in questo decennio.

---

Fonti:

• 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

Stai costruendo capacità DevOps/SRE e hai bisogno di ingegneri senior che sanno dove l'IA aumenta e dove no? Parla con un CTO sul dispiegamento di uno squad nearshore con vera maturità operazionale, non solo certificazioni del fornitore.