Il governance lag: una nuova metrica per il registro dei rischi

Le discussioni sulla shadow AI spesso si limitano a descrivere un divario tra l’adozione dell’IA e la sua governance. Per un registro dei rischi, una descrizione non basta. Il divario diventa rilevante solo quando può essere misurato, confrontato e assegnato a una priorità come periodo di tempo. Il governance lag fa esattamente questo: registra quanti giorni trascorrono tra il primo utilizzo di un’applicazione di IA e la sua completa integrazione nella struttura di governance.

Cosa misura esattamente il governance lag?

Il governance lag misura l’intervallo di tempo tra il primo utilizzo produttivo di un’applicazione di IA e il momento in cui essa viene pienamente inclusa nella struttura di governance: censita, valutata sotto il profilo del rischio, assegnata a un responsabile e coperta da controlli.

Questa definizione trasforma una descrizione qualitativa in una cifra concreta. Invece di affermare che un’applicazione di IA non è ancora pienamente governata, diventa possibile indicare da quanti giorni è già in uso senza supervisione. Questa precisione è importante perché il rischio può materializzarsi proprio durante quell’intervallo di tempo.

L’IBM Cost of a Data Breach Report 2026 mostra che il costo medio globale di una violazione dei dati è salito a 4,99 milioni di USD, il 12 per cento in più rispetto all’anno precedente. Un quarto degli attacchi malevoli era già basato sull’IA, con un costo medio di circa 6 milioni di USD per incidente. Questi dati mostrano che la durata del divario di governance è direttamente collegata al potenziale danno.

Come si calcola il governance lag?

Il governance lag è la differenza tra la data del primo utilizzo di un’applicazione di IA e la data della sua completa integrazione nella governance, misurata in giorni per ciascuna applicazione.

La data di inizio può essere ricavata dai documenti di procurement, dai log di attivazione delle funzionalità SaaS, dai log di accesso alle API o dalle segnalazioni delle unità di business. La data di fine viene raggiunta quando sono soddisfatte quattro condizioni: una registrazione nell’inventario delle IA, una valutazione del rischio completata, un responsabile designato e controlli implementati.

Come per la costruzione di un registro fornitori, governare il rischio legato all’IA comincia con un inventario completo, non con la valutazione di singoli casi uno alla volta. Senza questo inventario, il governance lag resta invisibile, pur esistendo nella pratica.

• Data di inizio: primo utilizzo dimostrabile dell’applicazione di IA
• Data di fine: integrazione nella governance completata, con responsabile e controlli
• Metrica: differenza in giorni, calcolata per ciascuna applicazione di IA
• Aggregazione: mediana e valori anomali sull’intero inventario delle IA

Come aiuta il governance lag a stabilire le priorità dei rischi?

Il governance lag agisce come dimensione aggiuntiva accanto a probabilità e impatto: più lungo è il divario, più alta è la priorità, indipendentemente dalla probabilità inizialmente stimata.

In una matrice del rischio classica, la priorità deriva da probabilità e impatto. Il governance lag aggiunge a questa matrice la durata del divario di controllo. Un’applicazione di IA con un potenziale di impatto medio, che opera al di fuori della governance da lungo tempo, può quindi essere prioritizzata rispetto a un’applicazione appena introdotta con un profilo di rischio simile.

È consigliabile un approccio graduato in base alla criticità dei dati e dei sistemi coinvolti. Alle applicazioni di IA con accesso a dati particolarmente sensibili dovrebbe essere assegnato un lag ammissibile più breve prima che venga attivata un’escalation, rispetto alle applicazioni con un profilo di rischio basso.

Quali soglie e livelli di escalation hanno senso?

Le organizzazioni definiscono soglie proprie in base alla criticità della rispettiva applicazione di IA, con livelli di escalation chiaramente definiti una volta che il governance lag supera tale soglia.

Una struttura funzionale distingue tre livelli. Le applicazioni entro il periodo ammissibile sono considerate in corso. Il superamento comporta l’escalation al responsabile del rischio; un superamento significativo comporta l’escalation al management esecutivo, insieme a una decisione se limitare l’applicazione fino alla sua completa integrazione nella governance.

La valutazione della FINMA sull’intelligenza artificiale descrive le applicazioni di IA come diffuse, mentre la relativa governance viene descritta, in molti casi, come ancora migliorabile.

Come diventa il governance lag parte dei processi GRC esistenti?

Il governance lag può essere mantenuto come campo aggiuntivo nel registro dei rischi e integrato nei cicli di reporting regolari del risk management, invece di restare una metrica isolata e separata sull’IA.

A tal fine è sufficiente un campo di dati aggiuntivo per ciascuna applicazione di IA: la data del primo utilizzo, la data di integrazione nella governance, il lag risultante in giorni e il relativo stato di escalation. Questi campi si inseriscono in una logica in cui il risk management è al servizio del raggiungimento degli obiettivi, non del mantenimento di un registro fine a sé stesso.

Il third-party risk management, la sicurezza delle informazioni e la compliance attingono allo stesso campo ogni volta che un’applicazione di IA è stata introdotta tramite un fornitore o un’applicazione già esistente. Come primo passo, i responsabili dei rischi dovrebbero ricostruire retroattivamente la data del primo utilizzo per ogni applicazione registrata nell’inventario delle IA e confrontarla con la data di integrazione nella governance. Questa differenza può essere introdotta come nuova metrica alla prossima riunione periodica sui rischi, prima che vengano aggiunte inosservate ulteriori applicazioni di IA.