Perché la governance dell’era dei parametri fallisce nei test di stress basati su IA

Nel panorama bancario inglese i test di stress sono stati per decenni basati su modelli “parameter‑driven”, i cui parametri potevano essere elencati, ispezionati e analizzati singolarmente. Questo approccio ha consentito una governance ben definita: documentazione leggibile, analisi di sensitività a livello di parametro e approvazione da parte del comitato modello di ogni modifica di specifica. Tuttavia, l’avvento dell’intelligenza artificiale (IA) ha introdotto modelli la cui struttura interna è opaca, rendendo obsoleti i meccanismi di controllo tradizionali.

Il contesto: da modelli leggibili a “black‑box” IA

Le banche stanno sempre più inserendo sistemi IA nei workflow di stress testing e di adeguatezza patrimoniale senza aggiornare la governance sottostante. La discrepanza è invisibile sui dashboard di audit interno, ma diventerà la classe specifica di fallimento che la Prudential Regulation Authority (PRA) identificherà nelle prossime revisioni di modello.

Questo articolo espone dove avviene la rottura, perché avviene e quale risposta architetturale è necessaria quando la disciplina deterministica‑governance incontra un workflow di stress‑testing regolamentato.

Scopo e trasparenza del quadro deterministico

Il quadro deterministico‑governance è stato sviluppato in due ambiti:

• Ricerca indipendente sotto il marchio PinkMate;
• Consegna applicata della ricerca Q‑MDP e dell’architettura di rischio climatico nel progetto DCarbon per SustainGRC.

Questa metodologia è stata validata nell’ambito ESG (environmental, social and governance). Lo si estende al settore finanziario per analogia strutturale, non per implementazione diretta. Ho consultato le dichiarazioni supervisory della PRA, i paper della Bank of England sull’IA nei servizi finanziari e la SR 11‑7 della Federal Reserve, considerata l’equivalente statunitense matura. Quando il ragionamento si basa su analogie ESG‑FS, viene esplicitamente segnalato, in linea con la disciplina del framework.

Perché la governance dell’era dei parametri era sufficiente

I tradizionali test di stress bancari si basavano su modelli la cui struttura intellettuale era progettata per essere ispezionabile. Un modello di credito “parameter‑driven”, utilizzato nelle sottomissioni ICAAP e nei test di stress della PRA negli ultimi vent’anni, è leggibile su tre livelli:

• Specificazione formale del modello, documento leggibile da una funzione di revisione;
• Parametri enumerabili e i loro valori esaminabili;
• Sensitività analitica dei risultati rispetto a variazioni dei parametri, ottenibile con tecniche standard.

Quando il comitato modello approva un modello di stress, esamina un oggetto il cui comportamento può essere caratterizzato con le stesse tecniche con cui i membri sono stati formati.

Architettura di governance tradizionale

L’architettura costruita intorno a questo modello comprende:

• Documentazione del modello conforme a standard di specifica;
• Modifiche proposte come variazioni di specifica e revisionate come tali;
• Analisi di sensitività a livello di parametro riportata al comitato;
• Validazione indipendente da team che leggono la specifica, riproducono l’analisi di sensitività e rilasciano un’opinione di idoneità.

Le aspettative della PRA in materia di gestione del rischio modello (SS1/23) codificano una “superficie di governance” che parte da questa leggibilità di base: inventario dei modelli, tiering, validazione continua e revisione indipendente presuppongono un oggetto architetturalmente trattabile.

Per i modelli veramente parametrici, governance e oggetto sono ben allineati. Il punto di rottura compare quando l’oggetto stesso muta sotto l’architettura.

Le nuove richieste della PRA per i modelli IA

Negli ultimi due anni la PRA ha introdotto un pattern di esame per i modelli IA che supera quello tradizionale. Prima si verificava:

• Idoneità del modello per l’uso previsto;
• Aggiornamento della documentazione;
• Rigorosità della validazione continua;
• Adempimento dei compiti di supervisione da parte del comitato.

Gli artefatti erano la specifica del modello, il report di validazione e i verbali del comitato.

Il nuovo pattern aggiunge una classe di query incentrata sulle proprietà comportamentali specifiche dell’IA sotto condizioni di stress, che la tradizionale documentazione non può rispondere. Esempi di richieste PRA:

• “Nel contesto dello scenario ICAAP, produrre gli output del modello, lo stato del modello, lo stato degli input e la traccia di ragionamento che li collega.”
• “Dimostrare che la versione del modello usata per i risultati patrimoniali attuali è la stessa in produzione al momento dell’esecuzione dello scenario, e che la transizione da versioni precedenti è stata governata.”
• “Fornire evidenza che il comportamento del modello sotto stress è realmente caratterizzato – non solo che gli output rientrano nelle tolleranze, ma che il meccanismo di generazione è compreso, documentato e adeguato.”
• “Spiegare come si rileverebbe una divergenza del comportamento sotto stress rispetto alla caratterizzazione governata e quale protocollo di risposta verrebbe attivato.”

Queste richieste richiedono artefatti che la governance tradizionale non produce: la specifica non fornisce tracce di ragionamento, i verbali non mostrano la governance delle versioni, l’analisi di sensitività non descrive il meccanismo interno e i dashboard non includono protocolli di risposta.

Di conseguenza, la maggior parte delle banche non possiede tali artefatti perché l’infrastruttura necessaria non è stata progettata.

Il divario e la risposta: quattro proprietà architettoniche

Il framework proposto per una banca britannica che implementa test di stress IA secondo le aspettative della PRA comprende quattro proprietà, ciascuna mirata a una dimensione delle nuove query:

1. Tracciabilità completa dello stato e della ragionamento

Ogni esecuzione di scenario deve generare un log immutabile che includa:

• Versione del modello IA;
• Parametri di configurazione e iper‑parametri;
• Stato degli input (dati macroeconomici, fattori di rischio, ecc.);
• Sequenza di operazioni interne (layer di rete, funzioni di attivazione, decision tree, ecc.) con riferimento a un “reasoning trace” leggibile da revisori.

Questa traccia è archiviata in un repository certificato (es. blockchain privata) per garantirne l’integrità.

2. Governance delle versioni del modello

È necessario introdurre un ciclo di vita del modello basato su:

• Controllo di versione semantico (es. MAJOR.MINOR.PATCH) collegato a ticket di cambiamento;
• Processi di approvazione formale per ogni upgrade, con documentazione delle motivazioni e dell’impatto previsto;
• Meccanismo di “freeze” dei modelli in produzione durante l’esecuzione di scenari di stress, garantendo che la versione utilizzata sia identificabile e immutabile.

Il comitato modello deve ricevere report di “version drift” che mostrino eventuali differenze tra la versione usata nello scenario e quella in produzione.

3. Caratterizzazione del meccanismo interno

Oltre alle metriche di performance, la governance deve richiedere:

• Modelli “explainable AI” (XAI) integrati, con mappe di attributi di importanza e contropesi per ogni output critico;
• Validazione della robustezza del modello sotto stress mediante tecniche di “adversarial testing” e “stress‑testing specifico per IA”;
• Documentazione formale che spieghi come le architetture (es. reti neurali, gradient boosting) tradurrebbero gli input in output, includendo diagrammi di flusso e formule di trasformazione.

Questa caratterizzazione consente di dimostrare che il modello non è solo “black‑box” ma che il suo comportamento è compreso e verificabile.

4. Protocollo di monitoraggio e risposta

Infine, deve essere implementato un sistema di monitoraggio in tempo reale che:

• Rilevi deviazioni statistico‑significative tra i risultati attesi (basati su caratterizzazioni XAI) e quelli osservati;
• Attivi allarmi automatici verso il comitato modello e i team di risk management;
• Preveda piani di mitigazione (es. rollback a versione precedente, attivazione di modelli di fallback “parametrici”, revisione manuale dei risultati).

Il protocollo deve essere documentato, testato periodicamente e integrato nei processi di governance esistenti.

Implementazione pratica e considerazioni finali

L’applicazione di queste quattro proprietà richiede un cambiamento culturale e tecnologico. Le banche devono:

• Investire in piattaforme di gestione del ciclo di vita del modello (MLflow, DVC, ecc.) con funzioni di audit certificato;
• Adottare soluzioni XAI mature (SHAP, LIME, DeepLIFT) integrate nei flussi di produzione;
• Rivedere i ruoli del comitato modello, includendo esperti di IA, data‑governance e compliance;
• Allineare i contratti di fornitura di tecnologia IA a requisiti di tracciabilità e versionamento richiesti dalla PRA.

Solo così la governance dell’era dei parametri potrà evolvere per sostenere i test di stress basati su IA, garantendo trasparenza, responsabilità e conformità alle nuove aspettative regolamentari.