ARTICOLO / 28 LUGLIO 2026
Il mercato AIOps sta crescendo a ritmi che raramente si vedono in un segmento tecnologico maturo. Le stime variano a seconda della fonte e della definizione adottata, ma la direzione è univoca: da 11 miliardi di dollari nel 2025 a cifre tra i 32 e i 42 miliardi entro il 2030, con tassi di crescita annui superiori al 25% (fonte: Research and Markets, 2026; DevOps.com/Catchpoint, 2026). L'adozione nelle aziende enterprise è passata dal 42% al 54% in un solo anno, tra il 2024 e il 2025 (Mordor Intelligence, 2026).
Numeri che sembrano confermare una narrazione ormai consolidata: l'AI applicata alle IT Operations è la soluzione ai problemi di complessità infrastrutturale delle aziende moderne. Ambienti ibridi, architetture multi-cloud, team sovraccarichi di alert: tutto risolto da modelli di machine learning che correlano gli eventi, predicono i guasti e avviano la remediation in autonomia.
Purtroppo, per quanto attraente - è una narrazione, almeno in parte, sbagliata.
A confermarlo, con una certa autorevolezza, è Gartner: a marzo 2025 ha ritirato la categoria AIOps Platforms e pubblicato il Market Guide for Event Intelligence Solutions, scrivendo nero su bianco che il termine era diventato un contenitore troppo vago per essere operativamente utile. È il riconoscimento istituzionale che l'AI applicata genericamente alle IT Operations non regge all'esame della produzione e che il valore non sta nel rilevamento delle anomalie, ma nella catena che porta dall'evento alla causa e poi all'azione.
Il paradosso dell'alert fatigue: avere più strumenti significa davvero organizzazione più efficiente?
Per inquadrare correttamente il problema il punto di partenza più corretto non è l’ordine di grandezza del mercato AIOps, ma una coppia di dati diversi: il 70% dei Site Reliability Engineer dichiara che lo stress da reperibilità ha già causato burnout e turnover nei propri team (Catchpoint SRE Report 2025), mentre il costo medio di un'interruzione non pianificata è stimato intorno ai 5.600 dollari al minuto.
Il mercato nel frattempo ha proposto più monitoraggio, più AI, più alert. Il risultato è spesso soltanto più “rumore”.
I team IT ricevono migliaia di alert al giorno: organizzazioni di medie dimensioni riportano volumi tra i 500 e gli 800 alert giornalieri, con picchi ben oltre i 5.000 per infrastrutture enterprise complesse. Aggiungere strumenti di correlazione sarebbe la risposta tecnica più istintiva ma è una soluzione che sposta il problema strutturale senza risolverlo. Un sistema AI che riceve in input dati rumorosi, non normalizzati, prodotti da sorgenti eterogenee senza modello di dati comune, genera output rumorosi. I team continuano a non fidarsi degli alert e tornano al monitoraggio manuale nei casi critici.
Si tratta di una dinamica documentata, non di un’ipotesi. I problemi più comuni nelle implementazioni AIOps fallite non riguardano la qualità del modello di machine learning ma la qualità dell'input:
- correlazione degli eventi insufficiente senza tagging manuale intensivo
- baselines instabili
- assenza di contesto applicativo nei dati infrastrutturali
Il problema del “giorno due”
In un articolo pubblicato su The New Stack, Latha Vishnubhotla, Chief Platform Officer di HPE, afferma che il vero problema non è rendere operativa l'infrastruttura, ma farla funzionare: "Where they spend most of their time is after the infrastructure becomes functional. Day 2 to Day N is where they spend a lot of time."
Il “giorno due” è la gestione ordinaria dopo il provisioning iniziale. Ed è esattamente qui che la complessità ibrida moderna diventa insostenibile: ambienti che mescolano bare metal, VM, container e piattaforme AI-native; infrastrutture di computing, storage e networking da vendor diversi; workload distribuiti tra data center on-prem, cloud pubblici, edge e siti disconnessi. Ogni layer ha i propri strumenti, la propria telemetria, il proprio linguaggio operativo.
Quando qualcosa va storto, il sintomo raramente appare nello stesso posto della causa. I team Operations setacciano layer su layer per trovare dove si è rotto qualcosa, mentre il downtime si accumula.
L'AIOps applicato a questa complessità senza una struttura di base può fare due cose: o non funziona, perché i dati non sono abbastanza strutturati per alimentare i modelli; o funziona male, amplificando la confusione invece di ridurla.
Cosa succede prima dell’AIOps?
Esiste quindi un assunto che vale la pena esaminare con attenzione e che spesso viene frainteso in due modi: un progetto AIOps efficace ha come prerequisito una piattaforma IT Operations solida.
Il primo fraintendimento è usarlo come alibi: "prima dobbiamo sistemare le Operations, poi pensiamo all'implementazione dell’AI". In questo caso il prerequisito porta spesso a rimandare all’infinito. Le IT Operations non sono mai abbastanza "sistemate" per cominciare, perché la complessità cresce sempre più velocemente della capacità di gestirla. Se si aspetta la perfezione, non si inizia mai. Un buon principio regolatore in questi casi può essere “Progress over Perfection”.
Il secondo fraintendimento è ignorare del tutto il prerequisito: si acquista una piattaforma AIOps, si connette alle sorgenti dati esistenti e ci si aspetta che l'AI faccia il lavoro e risolva da sola la complessità. Questa è la trappola più comune, ed è quella che produce più frequentemente le implementazioni fallite descritte prima.
L'AIOps è un paradigma che funziona solo quando è integrato in un ciclo operativo ridisegnato, in cui i dati hanno una struttura, la configurazione ha una singola fonte di verità, e l'observability è un asset gestito consapevolmente, non una raccolta casuale di metriche.
Il ciclo abilitante ha dei prerequisiti tecnici che lo rendono possibile: osservabilità strutturata, mappatura delle dipendenze applicative, CMDB (configuration management database) curato, governance dell'automazione. Qui ci interessa la domanda precedente: come rendere efficace un progetto AIOps?
Il “closed-loop” che rente un progetto AIOps efficace
Con le fondamenta operative in ordine, si può costruire il ciclo che rende l'AIOps uno strumento genuinamente trasformativo: lo stato dell'infrastruttura viene definito tramite codice (GitOps); le metriche e i log vengono centralizzati e analizzati in tempo reale (Observability); i modelli ML applicano anomaly detection e correlazione con dati storici per identificare cause probabili (AIOps); il sistema genera automaticamente azioni correttive (tramite playbook Ansible o Terraform) completando il ciclo in modo autonomo o con supervisione umana secondo la soglia definita.
In questo modo il lavoro operativo da reattivo diventa predittivo: anziché rispondere a incidenti già accaduti, si interviene sulle anomalie prima che abbiano impatti sul business.
I risultati documentati nelle organizzazioni che hanno costruito questo ciclo in modo corretto sono consistenti:
- riduzione del MTTR (mean time to resolution) tra il 40% e il 58%
- riduzione dei volumi di alert fino al 95% (da migliaia di notifiche al giorno a poche decine di segnali realmente azionabili)
- un aumento misurabile della disponibilità delle applicazioni critiche per il business
Perché il servizio AIOps di Var Group si inserisce in questa logica
Il servizio AIOps di Var Group adotta esattamente l’approccio appena descritto. Parte dall'integrazione di tre paradigmi operativi in un unico ecosistema coerente e gestito: automazione GitOps, Observability continua e intelligenza predittiva.
L'AI nelle IT Operations funziona come amplificatore di un metodo, non come sostituto. La differenza tra un progetto AIOps che porta valore e uno che produce confusione più velocemente sta nella corretta impostazione delle IT Operations stesse.
Fonti: Catchpoint SRE Report 2025, Mordor Intelligence AIOps Market Report 2026, Research and Markets AIOps Report 2026, Coherent Market Insights AIOps Platform Analysis, The New Stack / HPE GreenLake Intelligence (articolo sponsorizzato, giugno 2026), Gartner Market Guide for Event Intelligence Solutions (Crossley, Siegfried, marzo 2025, doc. 6250551).
Autore: Francesco Altavilla - Digital & Product Marketing Lead, Var Group