Nel precedente articolo abbiamo discusso dell’utilizzo dell’AI per i propri dati, mantenendoli all’interno della propria infrastruttura. Ora passiamo a considerare l’AI per le operazioni IT: non il modello di linguaggio che risponde alle domande, ma quello che mantiene in funzione l’infrastruttura mentre si lavora. Questo è il tema più discusso – e spesso esagerato – nel mondo dell’IT odierno. È importante distinguere ciò che funziona realmente da ciò che è solo una presentazione accattivante.

Il problema principale risiede nella crescente complessità degli ambienti IT moderni. Negli ultimi anni, l’adozione di microservizi per disaccoppiare i team, del cloud per la scalabilità on-demand e di Kubernetes per l’orchestrazione dei container ha portato a un ambiente distribuito la cui complessità supera le capacità cognitive umane. Questo si manifesta in modo critico quando qualcosa va storto.

Un’azienda media utilizza decine di strumenti di monitoraggio diversi, e un singolo incidente può generare cinquanta o più avvisi sparsi tra sistemi che non comunicano tra loro. L’ingegnere incaricato apre diverse schede per lo stato dei pod, le tracce applicative, i log e le modifiche recenti – mentre il servizio rimane inattivo. A causa dell’eccesso di allarmi che si rivelano falsi positivi, gli SRE (Site Reliability Engineer) smettono di fidarsi del pager e trattano gli avvisi come suggerimenti anziché come istruzioni. Questo fenomeno è noto come ‘alert fatigue’, e ha un costo elevato: per le grandi aziende globali, le stime dei disservizi raggiungono cifre nell’ordine delle centinaia di miliardi di dollari all’anno.

Qualcosa deve cambiare – e l’industria sta scommettendo sulla riduzione del lavoro manuale. La promessa, supportata da dati concreti, è che l’AIOps (Artificial Intelligence for IT Operations) possa correlare gli eventi, filtrare il rumore, identificare la causa principale e, sempre più spesso, agire in autonomia, riavviando, scalando o applicando una soluzione.

Gartner evidenzia un cambiamento di paradigma nel modo di lavorare: si passa da interfacce basate su riga di comando e script a linguaggio naturale, definizione di policy e orchestrazione di flussi. Il sistemista descrive l’obiettivo, senza dover specificare ogni singolo passaggio.

Gli studi di settore riportano riduzioni del tempo medio di risoluzione degli incidenti (MTTR) tra il 40% e il 70% nelle implementazioni più solide, una diminuzione dei volumi di alert fino al 95% e tempi di risposta agli incidenti di routine ridotti fino al 90%. Una ricerca commissionata a Forrester stima un MTTR dimezzato e una disponibilità delle applicazioni critiche superiore del 15%.

Tuttavia, è importante non fermarsi solo a questi dati positivi. Accanto ai casi di successo, esiste un altro dato meno citato: la riduzione media del MTTR nelle implementazioni reali si aggira intorno al 18%, ben inferiore al 70% spesso pubblicizzato. Questa discrepanza tra la media modesta e i risultati eccezionali non dipende dall’AI in sé, ma da ciò che sta alla base.

I due errori più comuni sono l’utilizzo di dati di scarsa qualità (la cosiddetta ‘spazzatura in ingresso’) e l’automazione basata su segnali errati. Un modello AI è valido quanto i dati che riceve: se log, metriche e tracce provengono da strumenti diversi e non sono coerenti, i risultati saranno inaffidabili. Secondo Forrester, circa il 28% dei progetti AIOps fallisce proprio a causa della mancanza di integrazione tra le fonti di osservabilità.

Come ha sintetizzato un’ex-CTO durante il Gartner IT Symposium di quest’anno, l’auto-riparazione può ridurre il MTTR del 70% e oltre, ma solo con un processo di dati puliti. La disciplina nella gestione dei dati non è un prerequisito noioso: è la base fondamentale.

Un altro rischio è che l’automazione agisca su un segnale errato. Se si configura una soluzione automatica – ad esempio, un riavvio – e questa viene attivata da un falso positivo, il sistema di monitoraggio può trasformarsi in una ‘chaos monkey’, causando danni più rapidamente di quanto farebbe qualsiasi operatore umano. I professionisti del settore parlano già di ‘alert fatigue 2.0’. Esiste anche la possibilità che un agente intelligente prenda la decisione sbagliata in una situazione ambigua, e la correzione del problema richieda più tempo rispetto a una risoluzione manuale.

La risposta onesta è quindi: realtà, ma non magia. L’infrastruttura che si gestisce da sola non è un interruttore che elimina i problemi, ma un amplificatore della maturità operativa esistente. Se si dispone di una solida osservabilità, dati puliti e policy chiare, i vantaggi sono reali e significativi. In caso contrario, l’automazione può semplicemente accelerare il caos.

Le implementazioni riuscite del 2026 hanno alcune caratteristiche in comune, nessuna delle quali è un prodotto miracoloso. Un esempio concreto: di fronte a un incidente come ‘latenza elevata sul servizio di checkout’, con cinquanta alert simultanei, un sistema ben progettato non aggiunge un cinquantunesimo avviso, ma correla i segnali in un unico incidente, li mette in relazione con l’ultimo rilascio andato in produzione e propone una diagnosi – ‘probabile regressione dell’ultimo deploy sul servizio di pagamento’ – con l’azione suggerita, il rollback. L’ingegnere non deve passare venti minuti a esaminare diverse schede: legge una ricostruzione già pronta, la valuta in trenta secondi e approva.

La differenza non è l’AI in sé, ma l’osservabilità unificata che ha permesso di vedere il quadro completo. Le implementazioni di successo partono da una base di osservabilità unificata e aperta – OpenTelemetry per la raccolta dei segnali, Prometheus e Grafana per metriche e visualizzazione – perché unificare la telemetria prima di costruire l’intelligenza artificiale non è opzionale, ma fondamentale.

L’AI viene quindi eseguita in ‘shadow mode’: viene lasciata osservare e proporre soluzioni senza agire, confrontando i risultati con la realtà. Solo quando si è guadagnata la fiducia le viene dato il permesso di intervenire. L’intervento umano rimane cruciale, con cancelli di approvazione per tutto ciò che riguarda l’ambiente di produzione, e viene richiesta una traccia verificabile di ogni azione dell’automazione: un sistema si guadagna il diritto di agire solo quando ogni sua mossa è governata e ispezionabile.

Infine, si automatizza ciò che è noto e ripetitivo – il ‘toil’, il lavoro manuale che non aggiunge valore – e si lasciano alle persone le attività nuove e complesse. L’AI non sostituisce gli SRE: elimina il rumore degli avvisi notturni per consentire loro di concentrarsi sulle sfide più impegnative.

Come per la sovranità dei dati e l’AI privata, la domanda fondamentale non è ‘automatizzare sì o no’, ma mantenere il controllo su ciò che si delega. Affidare il pager a una scatola nera che non si può ispezionare non è progresso: è una nuova forma di dipendenza, simile al vendor lock-in. L’obiettivo giusto è un’automazione verificabile, dirigibile e – quando necessario – annullabile. Autonomia con le briglie in mano, non al posto delle mani.

L’infrastruttura che si guida da sola arriverà più o meno come sono arrivate le auto a guida autonoma: reale, utilissima, ma per un bel po’ di tempo ancora migliore con qualcuno pronto a riprendere il volante. Le squadre che vincono non sono quelle che si fidano di più dell’automazione, ma quelle che la strumentano meglio. E c’è un posto, in particolare, dove tutta questa intelligenza sta silenziosamente iniziando a ripagarsi: la bolletta elettrica del data center.

* Contenuto realizzato con l’ausilio di sistemi di intelligenza artificiale.