L’intelligenza artificiale è entrata stabilmente nel lessico strategico dell’IT Service Management. E con ottime ragioni. Le sue promesse sono molto concrete: accelerare i processi, migliorare la qualità del supporto, aumentare l’efficienza operativa, alleggerire il carico dei team IT, innescare un miglioramento continuo.
Tutto vero…a patto di non sottovalutare il punto decisivo: l’AI non produce valore in automatico, quasi per magia, per il fatto stesso di venire introdotta.
Quando viene adottata in contesti in cui i processi sono poco chiari, i dati sono incoerenti e la governance è fragile, l’intelligenza artificiale può trasformarsi in un pericolosissimo moltiplicatore di vulnerabilità.
Quindi, che fare?
Il punto di partenza imprescinidbile è identificare con precisione i rischi, in modo da tenerli sotto controllo, evitando di imboccare strade a fondo chiuso o, peggio, percorsi che portano dritti verso un precipizio.
È quello che faremo in questo articolo, in cui abbiamo isolato intorno a quattro nuclei i principali Risk of AI in ITSM.
Procediamo con ordine, concludendo con un approccio più realistico; l’unico che permette davvero di sfruttare le opportunità di questa rivoluzione tecnologica senza precedenti.
Il primo rischio: automatizzare il disordine
L’Intelligenza Artificiale, tra le varie cose, è un acceleratore potentissimo. Ma un acceleratore, da solo, non distingue ciò che funziona da ciò che non funziona.
Che cosa significa, questo, nella pratica dell’ITSM?
Significa che, ad esempio, se il processo di gestione degli incidenti è poco standardizzato, se la categorizzazione dei ticket cambia da team a team, se le priorità vengono assegnate in modo discontinuo, allora l’AI non corregge il sistema, ma amplifica gli errori.
Questo è uno dei rischi più intuitivi ma anche sottovalutati.
Un’organizzazione può introdurre un assistente virtuale, una classificazione automatica dei ticket o un motore di suggerimento per la knowledge base e ottenere, almeno in apparenza, maggiore rapidità. Ma se a monte i workflow non sono chiari, i risultati saranno inevitabilmente incoerenti. Due richieste simili possono ricevere trattamenti diversi. Un ticket critico può essere instradato male. Una raccomandazione può sembrare plausibile e tuttavia basarsi su dati sporchi o su documentazione obsoleta.
L’effetto finale è paradossale: più automazione, ma meno affidabilità.
In altre parole, prima ancora di chiedersi dove introdurre l’AI, bisognerebbe chiedersi quanto sono maturi i processi ITSM dell’organizzazione. Perché l’intelligenza artificiale lavora bene quando incontra strutture leggibili: workflow ben progettati, tassonomie coerenti, SLA definiti, knowledge base curate, ownership chiare. Senza queste fondamenta, il rischio non è solo sbagliare, ma sbagliare più in fretta e in maniera più ampia.
Il secondo rischio: le conseguenze di dati di scarsa qualità
Veniamo a uno snodo decisivo, a cui abbiamo già fatto cenno: la qualità dei dati.
Nell’ITSM contemporaneo, i dati arrivano da molte fonti diverse: ticket, CMDB, strumenti di monitoraggio, knowledge article, richieste di servizio, asset, log, survey, escalation. Se queste fonti non sono affidabili, aggiornate e coerenti, anche l’AI più sofisticata lavorerà su basi instabili.
È un tema meno appariscente dell’automazione, ma ancora più importante. Perché un modello – perlomeno, per ora – non interpreta il contesto come farebbe un professionista esperto: identifica pattern nei dati disponibili. E se i pattern sono distorti, incompleti o contraddittori, anche l’output tenderà a esserlo. È questo il motivo per cui molte iniziative AI appaiono convincenti in fase dimostrativa e molto meno nella realtà quotidiana del service desk.
Attenzione! Il problema non è solo tecnico, ma anche culturale. Quando utenti e operatori iniziano a ricevere suggerimenti incoerenti, classificazioni poco comprensibili o risposte imprecise, la fiducia si erode rapidamente. E una volta persa, recuperarla è molto più difficile che introdurre una nuova funzionalità.
L’AI, insomma, non fallisce soltanto quando produce errori macroscopici; fallisce anche quando genera un rumore costante, sottile, che rende il sistema meno credibile. Questo è uno dei volti più concreti del Risk of AI in ITSM.
Il terzo rischio: dov’è la prova del valore?
Il terzo rischio è una trappola molto concreta, soprattutto a livello manageriale.
Molte organizzazioni introducono l’AI perché percepiscono che sia una priorità inevitabile, perché tutti intorno lo stanno facendo. Ma non definiscono in anticipo che cosa debba migliorare davvero, per loro, nel loro preciso contesto. Il tempo medio di risoluzione? Il first contact resolution? La riduzione del volume ticket? La qualità della knowledge base? L’esperienza utente? La produttività degli agenti?
Senza una baseline e senza metriche condivise, i benefici restano sfocati. Si vede movimento, si notano nuovi strumenti, si genera entusiasmo. Ma quando arriva il momento di giustificare investimenti, roadmap e priorità, manca la prova del valore. È uno dei paradossi tipici dell’hype: più si parla di una tecnologia, più diventa difficile dimostrarne l’impatto reale, se il progetto non è stato ancorato fin dall’inizio a risultati misurabili.
Per questo, in una strategia matura, l’AI non dovrebbe mai essere un fine in sé. Dovrebbe essere una leva al servizio di obiettivi chiari di miglioramento del servizio.
Per dirla in altro modo: il focus va spostato dalla tecnologia alla governance.
Il quarto rischio: una proliferazione incontrollata degli strumenti
Chiudiamo infine con un rischio meno operativo, ma più ampio e sempre più attuale: la frammentazione.
Quando l’AI entra in azienda senza policy chiare, senza ownership definita e senza criteri condivisi di utilizzo, il risultato può essere una nuova forma di shadow IT: più veloce, più accessibile e più difficile da monitorare.
È sufficiente che singoli team usino strumenti diversi per classificare ticket, generare risposte, costruire workflow o produrre contenuti di knowledge management, e in poco tempo si creano divergenze, duplicazioni e nuove superfici di rischio. A quel punto il problema non è più solo la qualità delle singole risposte dell’AI, ma la perdita di coerenza complessiva del sistema ITSM.
Questo scenario è particolarmente delicato perché si sviluppa in modo graduale e subdolo. All’inizio sembra un fenomeno innocuo, persino positivo: più sperimentazione, più iniziativa, più velocità. Poi però emergono le conseguenze operative. Linguaggi diversi, regole diverse, automazioni diverse, livelli di qualità diversi. E quello che doveva semplificare finisce per aumentare irrimediabilmente la complessità.
Prima di scalare l’AI, bisogna mettere in ordine l’ITSM
I rischi principali li abbiamo visti.
A questo punto la domanda giusta non è se adottare o meno l’AI nell’ITSM. Ma: su quali basi? Con quali accortezze?
Le organizzazioni che vogliono davvero ridurre il Risk of AI in ITSM dovrebbero concentrarsi prima di tutto su alcuni elementi strutturali: processi standardizzati, dati affidabili, ruoli chiari, governance, metriche, qualità della documentazione, manutenzione della knowledge base, integrazione tra service desk, incident management, request management e monitoraggio.
Non è la parte più “spettacolare” del percorso, ma è quella che rende l’AI realmente scalabile.
Diciamolo in maniera molto netta: l’intelligenza artificiale funziona bene quando trova un ecosistema ordinato. Quando può leggere segnali coerenti. Quando la CMDB non è un archivio dimenticato. Quando i ticket non sono una giungla di categorie improvvisate. Quando i team condividono un linguaggio operativo comune. Solo allora l’automazione intelligente smette di essere una promessa piuttosto vaga e “miracolosa” e inizia a diventare un asset concreto.
Un approccio più realistico, quindi più strategico
Dunque, come uscire dall’hype sull’intelligenza artificiale e sfruttarne davvero le enormi potenzialità?
Il primo passo è smettere di pensare all’AI come a una scorciatoia. Nell’ITSM non lo è. Piuttosto, è un moltiplicatore. E i moltiplicatori, per definizione, amplificano ciò che trovano: se trovano solidità, aumentano il valore; se trovano caos, aumentano il rumore.
L’AI nell’ITSM non va rallentata per paura, né accelerata per moda. Va collocata dentro una strategia seria, su misura della propria azienda e del contesto in cui è inserita. Perché il vero rischio nascosto non è che l’AI non funzioni. È che sembri funzionare abbastanza da convincerci che le fondamenta non contino più…e invece contano ancora più di prima.
Per approfondire ulteriormente questi versanti, vi rimandiamo alle registrazioni del webinar EasyVista “AI in ITSM: What’s Real. What’s Hype. What’s Next”, che affronta proprio il confine tra possibilità concrete, aspettative gonfiate e scenari di adozione più maturi.
FAQ
Perché un approccio troppo rapido all’AI può essere problematico?
Perché spinge spesso i team a usare l’intelligenza artificiale senza partire da problemi concreti da risolvere. Questo genera sperimentazioni scollegate, progetti ridondanti e risultati difficili da scalare o misurare.
Quali sono i principali Risk of AI in ITSM?
I rischi principali sono quattro: automatizzare processi disordinati, ottenere risultati poco affidabili per via di dati scarsi, non riuscire a dimostrare il valore reale dell’AI e creare frammentazione tra strumenti e workflow in assenza di una governance chiara.
Come si riducono i Risk of AI in ITSM?
Mettendo prima in sicurezza le fondamenta: standardizzazione dei processi, governance, qualità dei dati, metriche chiare, documentazione aggiornata e una knowledge base ben mantenuta. Solo dopo ha senso scalare l’AI.