Come strutturare un progetto pilota di AI nell’ITSM: il framework dei casi d’uso ad alto controllo

Quasi tutte le grandi organizzazioni hanno avviato almeno un progetto pilota di intelligenza artificiale destinato a incidere sulla gestione dei servizi IT. Molte lo interrompono dopo alcuni mesi, con risultati inferiori alle attese e attribuiscono l’esito negativo alla tecnologia. In buona parte dei casi la causa si trova altrove, nel modo in cui il progetto era stato impostato fin dall’inizio.

Le cause ricorrenti sono due. La prima è l’ambizione eccessiva, che spinge a partire da agenti AI capaci di operare in autonomia anche se l’organizzazione non dispone ancora della maturità necessaria per governarli. La seconda è l’assenza di struttura e di una governance stabile e condivisa: nessun responsabile designato, nessuna metrica di successo concordata prima dell’avvio, nessun criterio per decidere se proseguire.

Questo articolo propone un metodo per costruire un AI ITSM Pilot che produca risultati verificabili e che permetta di raccogliere fin dalle prime settimane evidenze utili a costruire e verificare il business case.

Partire da casi d’uso a basso rischio

La scelta corretta del caso d’uso determina in larga misura il successo del progetto pilota. Un caso d’uso a basso rischio presenta tre caratteristiche: i risultati sono verificabili da una persona in pochi secondi, l’errore produce conseguenze limitate e reversibili, il volume di richieste trattate è sufficiente a generare dati significativi in poche settimane.

Tre attività soddisfano queste condizioni.

1. Il triage dei ticket. Il sistema propone categoria, priorità e team di assegnazione di ogni richiesta in ingresso. L’operatore vede la proposta e la conferma o la modifica con un clic. Ogni interazione genera un dato utile sulla percentuale di proposte corrette.
2. La sintesi delle segnalazioni. Per gli incident con molte annotazioni, il sistema produce un riassunto dello stato e delle azioni intraprese. È particolarmente utile nei passaggi di consegne tra turni, dove ricostruire manualmente la cronologia di un incident complesso sottrae minuti preziosi alla risoluzione. 
3. Le bozze per la knowledge base. Utilizzando i ticket risolti, il sistema genera una prima stesura dell’articolo, che un redattore rivede e approva. La creazione di contenuti per la knowledge base rimane una delle attività più sacrificate dalla pressione operativa, e un contributo in questa direzione libera tempo qualificato.

Queste tre attività condividono una proprietà preziosa per un AI ITSM Pilot: la revisione umana è già parte naturale del flusso e quindi il controllo non aggiunge passaggi artificiali. I flussi di lavoro completamente autonomi, al contrario, possono essere attivati soltanto dopo che il sistema ha dimostrato un’affidabilità costante nel tempo.

Definire le metriche prima del lancio

Prima dell’avvio del progetto pilota è necessario definire per ciascun indicatore scelto tre elementi: il valore di partenza rilevato sui dati storici, l’obiettivo atteso al termine del periodo di prova e la traduzione di quel miglioramento in termini comprensibili al vertice aziendale e alla funzione finanziaria. Formule generiche come «maggiore efficienza operativa» o «supporto IT migliore» non superano neanche il primo confronto con la funzione finanziaria. 

Deve poi essere definito in anticipo il criterio decisionale: quale risultato giustifica il passaggio alla fase successiva e quale, invece, suggerisce di fermarsi. Stabilirlo prima evita che la valutazione finale si riduca a un confronto tra opinioni sul significato dei risultati ottenuti.

Quanti indicatori e su quale periodo?

Gli indicatori effettivamente utili sono specifici: riduzione delle segnalazioni non significative, tempo impiegato per assegnare un ticket al team più adatto, percentuale di assegnazioni corrette al primo tentativo, tempo medio di risoluzione, qualità della risposta agli incident di maggiore gravità, percezione dei team coinvolti.

Inoltre, ogni indicatore va collegato a una conseguenza concreta per l’azienda, riconoscibile anche fuori dall’IT. Per esempio: il tempo di assegnazione corrisponde all’attesa percepita dall’utente, la qualità delle bozze della knowledge base incide sulla capacità degli addetti del service desk di chiudere le richieste senza coinvolgere i team specialistici.

Meglio selezionare due o tre indicatori, non di più. Ogni metrica richiede una definizione condivisa, una rilevazione iniziale accurata e un’interpretazione al termine della prova. Un AI ITSM Pilot che ne monitora sei riduce la cura dedicata a ciascun indicatore, perché distribuisce l’attenzione su troppi fronti.

Poiché i volumi variano sensibilmente nel corso dell’anno, la rilevazione va estesa a un periodo abbastanza ampio da includere sia i momenti di picco sia quelli di minor carico. 

Responsabilità e governance

Un AI ITSM Pilot privo di un responsabile designato si arresta al primo ostacolo. La titolarità va assegnata a una persona, con nome e cognome, che risponda dei risultati e abbia l’autorità per decidere gli eventuali interventi correttivi.

Accanto alla titolarità servono tre strumenti di lavoro. Il primo è una mappa tecnica che descrive gli strumenti di monitoraggio coinvolti, le fonti dati utilizzate, le relazioni tra servizi ricavate dalla CMDB, i controlli di sicurezza applicati, i confini stabiliti per l’inserimento di automazione e i punti di integrazione. Il secondo è un registro dei rischi dedicato, in cui annotare le criticità individuate, la loro priorità e le azioni da effettuare. Il terzo è un modello operativo che stabilisce chi mantiene i dati, chi verifica la qualità delle raccomandazioni e la frequenza con cui il sistema viene rivisto.

La mappa tecnica, il registro dei rischi e il modello operativo funzionano soltanto se l’organizzazione dispone di regole condivise sull’uso dell’AI. In assenza di una governance definita, ogni team adotta i propri strumenti e le proprie convenzioni, con il risultato di moltiplicare le divergenze invece di ridurle.

I controlli human-in-the-loop

Il controllo umano deve necessariamente essere previsto laddove il rischio è più alto, evitando di applicarlo indistintamente a ogni decisione. Tre elementi vanno definiti e documentati prima dell’avvio del progetto: quali raccomandazioni del sistema richiedono l’approvazione di un operatore prima di diventare operative, chi ha il compito di approvarle e dove viene registrata quell’approvazione.

Deve inoltre essere definito che cosa accade quando il sistema sbaglia: chi rileva l’errore, come si ripristina la situazione precedente e in quanto tempo. Definire questa procedura durante la fase sperimentale, quando le conseguenze restano contenute, evita di doverla improvvisare in fase di produzione.

Perché il tasso di approvazione può ingannare

Un accorgimento riguarda lo sforzo richiesto per respingere una proposta. Se l’approvazione si ottiene con una singolo azione (un solo clic), mentre la correzione impone di ricompilare manualmente i campi, gli operatori sotto pressione tenderanno a confermare anche le raccomandazioni imprecise. 

Il dato sulla qualità delle proposte finisce così per misurare i carichi di lavoro del service desk più che le prestazioni del sistema: se la percentuale di proposte approvate viene usata come indicatore della accuratezza del sistema, e se approvare richiede un’azione rapida mentre correggere impone un lavoro manuale, quella percentuale salirà nei periodi di maggiore pressione sul service desk e scenderà quando il carico si alleggerisce. La soluzione consiste nel rendere la correzione altrettanto rapida dell’approvazione, per esempio proponendo alternative selezionabili al posto di un campo vuoto.

Introdurre l’autonomia per gradi

In un AI ITSM Pilot l’ampliamento dell’autonomia deve procedere per versioni successive, ciascuna subordinata ai risultati della precedente.

V1 – Suggerimenti con revisione umana

Il sistema propone, la persona addetta alla supervisione del processo decide. Ogni proposta dell’agente AI viene confrontata con la scelta effettiva dell’operatore, e da questo confronto si ricava il tasso di concordanza tra la proposta del sistema e la decisione dell’operatore. La concordanza, tuttavia, non equivale automaticamente all’accuratezza: un campione delle decisioni va verificato separatamente per accertarne la correttezza.

V2 – Automazione dei casi ad alta affidabilità

Una volta individuate le tipologie in cui il sistema raggiunge in modo costante alti livelli di affidabilità sufficientemente elevati, l’esecuzione automatica viene attivata soltanto su quelle. Il resto delle richieste continua a passare attraverso la revisione umana. La soglia va fissata separatamente per ciascun tipo di proposta: l’assegnazione di un ticket richiede garanzie diverse rispetto alla modifica di una priorità.

V3 – Autonomia estesa

L’ampliamento procede man mano che cresce l’affidabilità del sistema e di conseguenza la fiducia degli operatori umani. Il monitoraggio dei risultati è continuo ed esiste sempre la possibilità di riportare indietro l’automazione quando le prestazioni si degradano.

Un percorso di questo tipo riprende una logica di passaggio graduale dalla sperimentazione all’esercizio, per cui la fase di osservazione precede l’introduzione in un perimetro controllato e, solo dopo, l’ingresso nell’operatività quotidiana.

Dal progetto pilota alla dimostrazione del valore

Il legame tra sperimentazione e ritorno economico (ROI) si costruisce durante il progetto. In altre parole, i dati che serviranno a dimostrare il valore dell’investimento vanno raccolti mentre il progetto pilota è in corso. I dati storici raccolti prima dell’avvio costituiscono la baseline rispetto alla quale valutare i risultati del progetto. I dati prodotti durante la fase V1 servono invece a verificare e calibrare il comportamento del sistema. E i miglioramenti registrati in V2 diventano la prova da presentare per chiedere ulteriore budget per l’estensione del progetto.

Gli stessi principi ricorrono nelle raccomandazioni più diffuse sull’introduzione dell’AI nella gestione dei servizi: partire da casi d’uso a elevato valore, curare la qualità dei dati, adottare gli strumenti adeguati, formare le persone, sperimentare su scala ridotta e crescere con gradualità.

Un AI ITSM Pilot impostato in questo modo resta utile qualunque sia il risultato. Se il progetto funziona, l’organizzazione disporrà di dati verificabili per giustificarne l’estensione. Se il progetto non funziona, a fronte di una spesa contenuta, l’organizzazione saprà quali lacune colmare prima di riprovare. La riflessione che i decisori aziendali devono fare riguarda il grado di maturità della propria organizzazione più che i limiti della tecnologia.

FAQs

1. Quanto deve durare un progetto pilota di AI nell’ITSM?
Il tempo necessario a raccogliere un numero di osservazioni sufficiente sul caso d’uso scelto. Per attività ad alto volume come il triage dei ticket bastano alcune settimane: periodi più brevi non consentono di distinguere un risultato stabile da una variazione occasionale.

2. Perché conviene evitare gli agenti autonomi nella fase iniziale?
Perché sono necessari meccanismi di controllo, soglie di affidabilità e responsabilità definite che si costruiscono con l’esperienza. Partire da suggerimenti sottoposti a revisione permette di raccogliere i dati necessari a calibrare quelle soglie prima di ampliare l’autonomia.

3. Chi dovrebbe guidare il progetto?
Una singola persona, affiancata da referenti per i dati, per la governance e per i team operativi coinvolti. Una titolarità condivisa tra più funzioni rallenta i processi decisionali nel momento in cui devono dimostrarsi tempestivi.

4. Come si dimostra il ritorno dell’investimento al termine della sperimentazione?
Confrontando i valori rilevati prima dell’avvio con quelli registrati durante il progetto, sugli indicatori concordati in partenza, e convertendo i risultati in ore di lavoro liberate e in costi evitati.