Il CAB incontra l’AI: dal giudizio sul change a una decisione verificabile

Il segnale: l’AI entra nella decisione di change

Ad agosto 2026 due piattaforme ITSM hanno reso più concreto lo stesso passaggio. Le release note di ServiceNow Otto for ITSM indicano che l’AI può compilare automaticamente le domande di Change Risk Assessment e Dynamic Schema usando il contesto del change, mostrando il ragionamento per ogni risposta e valorizzando campi collegati a esposizioni di compliance. Atlassian, nell’aggiornamento Cloud del 10 agosto, ha introdotto un comando Rovo per richiamare su richiesta la valutazione AI del rischio in Jira Service Management, oltre al pannello già disponibile nel prodotto.

Non è ancora un “CAB autonomo”. È però un cambiamento rilevante: l’AI non si limita a riassumere il ticket o suggerire una risposta, ma contribuisce a una decisione che può influire su disponibilità, sicurezza, compliance e continuità operativa. La qualità della valutazione diventa quindi parte del sistema di controllo del servizio.

Il punto manageriale non è scegliere quale prodotto abbia l’algoritmo migliore. È progettare come una valutazione generata dall’AI entra nel processo: quali dati usa, chi può correggerla, quali change richiedono revisione, quale evidenza resta disponibile dopo l’approvazione e come si misura se la previsione era utile.

Una probabilità non è un’approvazione

Il rischio di un change combina almeno probabilità e impatto, ma i dati storici raccontano solo una parte. Incidenti collegati, esiti di change simili, servizi coinvolti, finestra temporale, dipendenze e qualità del piano sono segnali utili. Restano però elementi difficili da inferire automaticamente: pressione commerciale, eventi aziendali, capacità reale del presidio, trasformazioni appena introdotte o dipendenze non censite.

Per questo una classificazione “basso, medio, alto” non deve trasformarsi in un consenso implicito. L’AI può preparare la decisione, evidenziare lacune e rendere coerente l’analisi. L’autorità resta assegnata secondo policy, segregazione dei compiti e responsabilità del servizio. Nei change standard e ripetitivi la supervisione può essere più leggera; nei change ad alto impatto, urgenti o regolamentati servono soglie e approvazioni esplicite.

Anche la spiegazione va trattata con prudenza. Un testo fluido può sembrare convincente senza dimostrare che i dati siano completi. Una spiegazione utile deve indicare le evidenze: change analoghi, incidenti, CI, dipendenze, controlli mancanti e motivi della mitigazione. Deve permettere al change manager di verificare e correggere, non limitarsi a rassicurarlo.

Il dato storico può consolidare vecchi errori

Un motore di risk assessment apprende o ragiona sul materiale disponibile. Se il CMDB è incompleto, gli incidenti non vengono collegati ai change o i post implementation review sono formali, l’AI eredita quelle debolezze. Il rischio più sottile è rendere sistematico un giudizio storicamente povero: change riusciti per fortuna diventano esempi positivi; impatti non registrati scompaiono dalla memoria operativa.

Prima di aumentare l’autonomia occorre quindi una baseline di qualità. Vanno misurati completezza dei record, collegamento tra change e incident, accuratezza delle relazioni tra CI, presenza di test, rollback e criteri di successo. I dati mancanti non dovrebbero essere riempiti con sicurezza artificiale: devono emergere come incertezza o condizione che impedisce l’approvazione automatica.

ISO/IEC 20000-1 inquadra il miglioramento continuo nel sistema di gestione dei servizi e richiama il controllo del ciclo di vita. Applicato qui, significa che l’AI non è un componente isolato: dipende da configurazioni, conoscenza, fornitori, processi e misurazioni. Migliorare il modello senza migliorare il sistema di record produce soltanto una previsione più elegante.

Governance: rendere visibile la configurazione uomo–AI

Il NIST AI RMF distingue configurazioni in cui il sistema decide autonomamente, rinvia a un esperto o fornisce un’opinione aggiuntiva. Nel Change Enablement questa distinzione deve essere esplicita per classe di change. L’interfaccia dovrebbe mostrare se l’AI informa, raccomanda, precompila o attiva un passaggio; l’utente deve sapere quale responsabilità sta esercitando.

Servono inoltre versionamento e audit. Il record dovrebbe conservare versione del modello o della funzione, fonti consultate, output, correzioni umane, approvatore ed esito. Se un aggiornamento cambia il modo in cui viene stimato il rischio, l’organizzazione deve poter confrontare il comportamento prima e dopo, soprattutto nei servizi critici.

Anche il fornitore entra nel perimetro. Contratti e governance devono chiarire disponibilità della funzione, dati utilizzati, log accessibili, retention, limiti dichiarati, cambi di versione e gestione degli incidenti AI. Una funzionalità SaaS aggiornata silenziosamente può cambiare il controllo operativo; il supplier management deve quindi includere l’evoluzione del componente intelligente.

Metriche: verificare se il rischio previsto corrisponde a quello reale

Il successo non si misura contando quante schede sono state compilate dall’AI. Occorre confrontare previsione e outcome: change failure rate per classe di rischio, incidenti post-change, rollback, degradi, falsi positivi, falsi negativi e correzioni del change manager. Se molti change classificati a basso rischio generano impatti, il sistema non sta proteggendo il servizio.

Va misurato anche il valore operativo. Tempo risparmiato nella preparazione, qualità delle informazioni prima del CAB, riduzione dei rinvii per dati mancanti e coerenza tra team sono benefici concreti. Ma una riunione più breve non è un risultato se aumentano errori o approvazioni passive.

Una metrica particolarmente utile è il disaccordo qualificato: quante volte l’operatore modifica la valutazione e con quale motivazione. Non deve diventare un KPI punitivo. È un sensore per individuare dati mancanti, contesti non rappresentati e aree in cui l’AI necessita di limiti diversi.

• Confrontare rischio previsto, incidenti post-change e rollback.
• Separare falsi positivi e falsi negativi per servizio e classe di change.
• Misurare completezza del record e riduzione dei rinvii, non solo il tempo del CAB.
• Analizzare le correzioni umane come feedback sul sistema.

Una roadmap prudente: prima copilot, poi controllo adattivo

Il punto di partenza migliore è un insieme circoscritto di change con storico sufficiente e impatto reversibile. L’AI opera inizialmente in shadow mode: produce la valutazione senza influire sull’approvazione. Si confrontano risultati e decisioni umane, si correggono dati e soglie, poi si abilita la precompilazione con revisione obbligatoria.

Solo dopo evidenze stabili si possono alleggerire i controlli sui casi standard. I change critici, urgenti, con dati incompleti o compliance coinvolta devono mantenere percorsi rafforzati. Ogni classe richiede criterio di escalation, possibilità di override motivato e rollback del processo, non soltanto del change tecnico.

La direzione del mercato è chiara: il CAB riceverà analisi sempre più rapide e contestuali. Il vantaggio non sarà eliminare il giudizio umano, ma liberarlo dalla raccolta meccanica e renderlo più verificabile. Un change approvato perché “l’AI ha detto basso rischio” è governance debole. Un change approvato con evidenze, incertezza esplicita, responsabilità e feedback sull’esito è un processo che sta imparando.