Learning from Change: Predictive Models for Incident Prevention in a Regulated IT Environment

1. Il Problema

Nel settore finanziario e in altri ambienti IT altamente regolamentati, la gestione dei cambiamenti (Change Management) è critica per garantire affidabilità, auditabilità e tracciabilità. Una percentuale significativa di incidenti IT (fino al 70% secondo dati Google) è causata da cambiamenti nel software o nell'infrastruttura.
Le istituzioni finanziarie europee, come ING, devono rispettare normative rigorose (es. DORA, EBA) che richiedono processi di approvazione dei cambiamenti trasparenti e controllabili.
Attualmente, ING utilizza un approccio basato su regole (rule-based) per valutare il rischio di un cambiamento prima del deployment. Tuttavia, questo metodo presenta limiti:

• Dipende fortemente dall'accuratezza dei dati inseriti manualmente e dall'esperienza umana.
• Fatica a distinguere i cambiamenti a rischio in dataset sbilanciati (gli incidenti sono rari rispetto ai cambiamenti riusciti).
• Offre una scarsa capacità discriminativa (AUC vicino a 0.5), portando a un alto numero di falsi positivi o, peggio, a non rilevare rischi reali.

L'obiettivo è sviluppare un modello predittivo che sia altamente performante ma anche interpretabile (explainable) per soddisfare i requisiti di compliance e mantenere la fiducia degli operatori umani nel processo decisionale.

2. Metodologia

Gli autori hanno analizzato un dataset reale di 175.000 ticket di cambiamento chiusi in un anno (novembre 2022 - ottobre 2023) presso ING, collegati a ticket di incidente di priorità 1 e 2.

Preparazione dei Dati e Feature Engineering

• Etichettatura: Un cambiamento è etichettato come "causa di incidente" (classe positiva) se collegato a un incidente ad alta priorità. Solo il 2,4% dei cambiamenti ha causato incidenti (problema di sbilanciamento delle classi).
• Feature NLP: Le descrizioni testuali dei cambiamenti (Short/Full Description) sono state processate tramite NLP (CountVectorizer + TruncatedSVD) per estrarre caratteristiche semantiche.
• Feature Contestuali: Sono state incluse metadati sul CI (Configuration Item), gruppi di assegnazione, rating di sicurezza (CIA), e caratteristiche temporali.
• Metriche di Team Aggregato: Per la RQ3, sono state aggiunte metriche aggregate per team (es. tasso di successo dei rilasci, numero di cambiamenti, incidenti storici del team), utilizzando il "IT Product" come proxy per l'identità del team.

Modelli e Approccio

Sono stati confrontati tre classificatori basati su alberi di decisione potenziati (boosted trees), scelti per la loro capacità di gestire dati tabellari e supportare l'interpretabilità post-hoc:

1. HGBC (HistGradientBoostingClassifier di scikit-learn).
2. LightGBM.
3. XGBoost.

Il baseline è rappresentato dall'attuale sistema di scoring basato su regole di business di ING.
Per garantire la trasparenza, è stato utilizzato il framework SHAP (SHapley Additive exPlanations) per spiegare le previsioni a livello di singola feature, rendendo il modello "scatola grigia" invece che "scatola nera".

Valutazione

• Split Temporale: I dati sono stati divisi temporalmente (8 mesi training, 2 mesi validation, 2 mesi test) per simulare un ambiente reale.
• Metriche: Data la rarità degli incidenti, l'obiettivo è massimizzare il Recall (trovare tutti i cambiamenti rischiosi) anche a scapito della Precisione. Sono state utilizzate:
  • wR (Weighted Recall): Recall pesata per classe.
  • wF2 (Weighted F2-measure): Misura che dà un peso doppio al Recall rispetto alla Precisione ($\beta=2$).
  • AUC: Area sotto la curva ROC.
• Simulazione Operativa: Valutazione tramite finestra scorrevole (sliding window) con riaddestramento giornaliero.

3. Risultati Chiave

RQ1: Performance dell'Approccio Basato su Regole

L'approccio attuale (baseline) ha mostrato una bassa capacità discriminativa:

• Precisione molto bassa (0.04).
• Recall (wR) moderata (0.56).
• AUC di 0.56 (vicino al caso casuale), indicando che le regole statiche non riescono a distinguere efficacemente i cambiamenti rischiosi.

RQ2: Confronto tra Modelli ML e Baseline

Tutti i modelli ML hanno superato significativamente il baseline:

• LightGBM ha ottenuto le migliori prestazioni complessive, con un wR di 0.91 e un wF2 di 0.92.
• XGBoost ha mostrato la precisione più alta (0.05) e il miglior AUC (0.71), ma un recall leggermente inferiore a LightGBM.
• Feature Importanti: Le analisi SHAP hanno rivelato che le descrizioni testuali (Full/Short Description) e i metadati del team (Assignment Group, Support Offerings) sono le feature più influenti, superando fattori tradizionali come la complessità di deployment.

RQ3: Impatto delle Metriche di Team

L'aggiunta delle metriche aggregate del team (es. successo dei rilasci settimanali) ha portato a:

• Un miglioramento della Precisione (da 0.02 a 0.04) e del Recall (da 0.91 a 0.93).
• Un leggero calo dell'AUC (da 0.67 a 0.60), ma questo è considerato accettabile dato che l'obiettivo è massimizzare il rilevamento dei casi positivi (incidenti) e non la classificazione globale.
• Le nuove feature (es. "IT Product", "Release Percentage Successful") si sono rivelate predittori moderatamente importanti.

Stabilità

LightGBM ha mantenuto prestazioni stabili nel tempo (misurate tramite wF2), dimostrando robustezza anche in scenari con fluttuazioni nel volume dei cambiamenti.

4. Contributi Principali

1. Valutazione Comparativa: Prima analisi che confronta un approccio basato su regole con modelli ML (HGBC, LightGBM, XGBoost) in un contesto bancario reale e regolamentato.
2. Trasparenza e Compliance: Dimostrazione pratica di come utilizzare SHAP per rendere i modelli predittivi auditabili e spiegabili, soddisfacendo i requisiti normativi (DORA, AI Act) e costruendo fiducia negli ingegneri.
3. Integrazione di Metriche di Team: Evidenza che arricchire i modelli con dati aggregati sulle prestazioni del team migliora l'accuratezza, offrendo un contesto organizzativo spesso ignorato.
4. Approccio "Human-in-the-Loop": Il modello non sostituisce l'approvazione umana ma fornisce un punteggio di rischio e spiegazioni per guidare decisioni più informate, riducendo il carico cognitivo e migliorando la qualità delle revisioni.

5. Significato e Implicazioni

• Per la Pratica Industriale: L'adozione di LightGBM spiegabile permette alle banche di passare da una gestione reattiva a una proattiva del rischio. Gli ingegneri possono identificare i cambiamenti ad alto rischio nella fase di pianificazione, applicando controlli aggiuntivi (es. test più rigorosi, rollback pianificati) prima del deployment.
• Per la Ricerca: Lo studio sottolinea l'importanza di bilanciare accuratezza e interpretabilità in settori critici. Dimostra che modelli "black-box" complessi non sono necessari se si utilizzano alberi potenziati combinati con tecniche di spiegazione avanzate.
• Sfide Future: La qualità dei dati (in particolare il collegamento tra incidenti e cambiamenti) rimane un collo di bottiglia. Inoltre, la distinzione tra feature "azionabili" (es. descrizione del cambiamento) e "non azionabili" (es. team assegnato) è cruciale per fornire raccomandazioni pratiche agli ingegneri.

In sintesi, il paper dimostra che è possibile implementare con successo sistemi di intelligenza artificiale predittiva in ambienti finanziari regolamentati, migliorando l'affidabilità operativa senza compromettere la trasparenza e la conformità normativa.