Kennisbank

Una rapportazione al board che si allinea a ciò che il consiglio già legge

Un consiglio di amministrazione riceve periodicamente rapportazioni: finanziarie, operative, su rischi che hanno già un posto nella struttura esistente. Una rapportazione sull'AI che sta a parte, con un proprio ritmo e un proprio formato, viene nella pratica saltata. Non perché l'argomento sia irrilevante, ma perché un secondo processo accanto a un processo esistente richiede uno sforzo separato che compete con tutto ciò che è già all'ordine del giorno. Ciò che viene effettivamente letto è quello che rientra nella linea di rendicontazione esistente: lo stesso ritmo, la stessa lunghezza, lo stesso posto nella riunione.

Cosa dovrebbe contenere quell'unica pagina

Una rapportazione al board sull'AI non ha bisogno di un inventario tecnico completo. Il consiglio ha bisogno di una risposta a un numero limitato di domande: quali applicazioni di AI esistono, in quale categoria di rischio rientrano, cosa è cambiato dalla rapportazione precedente e ci sono state escalation. Quest'ultimo punto è dove la maggior parte delle rapportazioni rimane vuota — non perché non succeda nulla, ma perché non esiste un percorso attraverso il quale un segnale raggiunga il consiglio. Senza percorsi di escalation che funzionano funzionanti, una rapportazione è una fotografia senza storia: mostra cosa c'è ora, non cosa è andato storto o è quasi andato storto nel frattempo.

La rapportazione si basa su ciò che è già stato stabilito. Un elenco delle decisioni di oversight con chi ha approvato cosa è la fonte da cui viene sintetizzata la pagina, non un documento separato che esiste a parte. Ciò che compare sulla pagina è una sintesi di decisioni già prese; non è una nuova valutazione che il consiglio deve fare da sé sulla base di dati grezzi.

Perché un secondo processo viene ignorato

Le organizzazioni hanno già una struttura di rischio: un comitato di audit, un comitato rischi, un posto fisso all'ordine del giorno del consiglio per i rischi operativi. Una rapportazione sull'AI che introduce un proprio comitato, un proprio calendario o un proprio modello richiede a tutti coloro che già vi partecipano di fare qualcosa in più oltre a quello che già fanno. Questo lavoro extra viene rinviato non appena l'agenda si riempie, e l'agenda si riempie sempre. Il risultato è che la rapportazione scompare dopo qualche volta, non perché qualcuno abbia deciso che il rischio AI non è importante, ma perché nessuno ha deciso che fosse più importante di ciò che c'era già.

La soluzione non sta in un maggiore accento sull'argomento, ma in meno frizione nell'inserirlo. Una pagina che appare con lo stesso ritmo trimestrale delle altre rapportazioni di rischio, che usa lo stesso layout e occupa lo stesso posto nel fascicolo, viene letta perché leggerla non richiede un'azione separata. Ciò che non funziona è un ciclo di governance dell'AI separato che gira indipendentemente dal ciclo esistente — quello viene ignorato non appena arriva il primo mese impegnativo.

Cosa presuppone la pagina che esista già

Una rapportazione di una pagina può essere breve solo se la struttura sottostante è completa. Presuppone una panoramica del tipo cosa deve sapere un amministratore sul rischio AI su ruoli e responsabilità, in modo che la pagina non debba spiegare ogni volta di nuovo chi è responsabile di cosa. Presuppone un inventario che non contenga solo ciò che l'IT ha approvato, ma anche ciò che i reparti hanno iniziato a usare autonomamente senza segnalarlo — l'AI ombra, che diventa visibile solo quando le persone possono raccontare senza conseguenze cosa usano realmente. Una rapportazione che mostra solo l'elenco approvato rapporta una finzione.

La pagina presuppone anche che accada qualcosa tra una rapportazione e l'altra: un monitoraggio che produce risultati invece di un registro che nessuno consulta. Senza questo strato intermedio, la pagina trimestrale è una sorpresa a ogni edizione, invece di una sintesi di qualcosa che è stato seguito per tutto il trimestre. E presuppone che la policy sottostante non sia documentazione di facciata, ma una policy AI che viene letta dalle persone che usano i sistemi ogni giorno — perché una rapportazione sulla conformità a una policy che nessuno conosce rapporta soprattutto su se stessa.

Cosa aggiunge un CIO alla rapportazione

La pagina per il consiglio è una sintesi; la base è un livello più in profondità, presso chi conosce i sistemi. Ciò che un CIO contribuisce a questo è descritto in cosa deve sapere un CIO sul rischio AI, e questi due livelli — panoramica di governance e conoscenza operativa — devono allinearsi prima che la pagina da un quarto d'ora di lettura dica effettivamente qualcosa su ciò che accade nell'organizzazione.

Questa struttura si sta costruendo, non viene offerta come prodotto finito. Chi desidera lo scan che produce questo inventario, classificazione e struttura di rapportazione entra in una lista d'attesa; è in fase di costruzione e non viene venduto come strumento pronto all'uso prima che lo sia effettivamente.

La domanda che segue dopo la rapportazione

Una volta chiarito quale AI è in uso e in quale categoria di rischio rientra, segue un'altra domanda, che non riguarda il rischio ma l'organizzazione del lavoro stesso: quale parte dei compiti attualmente svolti si presta a essere ripresa dall'AI. È un calcolo separato, costruito non sul rischio ma sui compiti. Lo scan del lavoro di FTE TO AI calcola per ciascun compito quale parte del lavoro è idonea per essere ripresa, come passo successivo una volta chiarito cosa è già presente di AI nell'organizzazione.