Cosa c'è scritto nella pagina che il board legge

La domanda che precede un rapporto

Un board che metta l'AI all'ordine del giorno riceve di solito due tipi di documenti: un dossier voluminoso che nessuno legge prima della riunione, oppure una sintesi che dice così poco da non permettere alcuna decisione. Un rapporto al board di una pagina non è una sintesi del dossier. È un'altra domanda: cosa deve sapere un amministratore per poter assumere responsabilità, e cosa è rumore di fondo.

Questa distinzione non è banale. La maggior parte dei rapporti sull'AI che vediamo si limita a contare i sistemi. Una pagina che si limita a contare quante applicazioni di AI esistono non dice nulla al board su dove si trovi il rischio. Il conteggio è una questione IT. La governance è un'altra questione: quali applicazioni riguardano decisioni su persone, quali sono state messe in uso senza supervisione, e quali rientrano in una classe di rischio che richiede una firma.

Cosa deve invece contenere

Una pagina efficace contiene un numero limitato di elementi, ognuno con una ragione precisa per essere incluso:

Lo stato dell'inventario. Non un elenco di sistemi, ma un'affermazione sulla copertura: cosa è mappato, cosa si presume presente ma non è confermato, e cosa è stato deliberatamente escluso dall'ambito.
La classificazione del rischio a grandi linee. Quante applicazioni rientrano in una categoria che richiede l'attenzione del board, senza descrivere ogni singolo sistema.
Le decisioni in sospeso. Non la gestione operativa, ma la domanda che spetta al board: un investimento, un'accettazione del rischio, una scelta tra continuare e fermarsi.
Cosa è cambiato dall'ultimo rapporto. A un board serve poco una fotografia; serve una differenza.

Il resto — chi ha addestrato quale modello, quale fornitore applica quali condizioni, quale mitigazione tecnica è stata adottata — appartiene al livello sottostante. Quel livello esiste, viene mantenuto e può essere consultato su richiesta. Ma non appartiene alla pagina che il board legge, perché altrimenti il board non la legge.

Perché un secondo processo viene ignorato

La ragione per cui tanta governance sull'AI si arena non è l'assenza di un processo. È che si crea un secondo processo, accanto a quello esistente. Un board ha già un comitato rischi, ha già un calendario di audit, ha già un format per la rendicontazione sul rischio operativo, sulla compliance, sulla sicurezza delle informazioni. Chi vi affianca un processo AI separato — con frequenza propria, template proprio, responsabile proprio — chiede qualcosa che sarà il primo a essere saltato quando l'agenda è troppo piena. Non accade per mancanza di volontà. Accade perché un secondo processo per definizione riceve meno attenzione del primo.

Il rapporto che viene effettivamente letto è quello che segue il ritmo esistente: la stessa riunione, lo stesso format, le stesse modalità di escalation già in uso per altri rischi. Il modo in cui questo raccordo prende forma nella pratica è descritto nella pagina su raccordo con la struttura di rischio esistente, e il modo in cui le decisioni vengono successivamente registrate è trattato nella pagina su un registro decisionale di supervisione integrato nel ritmo esistente.

Cosa presuppone la pagina

Un rapporto di una pagina è utile solo se l'inventario alla sua base è corretto. È l'elemento più spesso trascurato: gli amministratori ricevono una pagina con una classificazione del rischio, senza che nessuno abbia verificato se l'elenco sottostante delle applicazioni di AI sia completo. L'AI ombra — l'uso nato al di fuori dell'elenco IT — scompare allora silenziosamente dal quadro, non perché sia irrilevante, ma perché nessuno l'ha chiesta. Un dipendente che usa uno strumento di AI senza approvazione non lo segnala spontaneamente se incombe una resa dei conti. Lo segnala solo quando vengono poste domande senza conseguenze.

La pagina, da un lato, è dunque la punta di un processo che inizia dall'inventario e si sviluppa attraverso percorsi già esistenti. Il modo in cui funziona questa escalation senza creare una nuova gerarchia è descritto nella pagina su percorsi di escalation effettivamente utilizzati. E ciò che va monitorato in modo strutturale per poter riempire la pagina ogni volta senza che diventi una ricostruzione è descritto nella pagina su un monitoraggio che produce effettivamente qualcosa per la rendicontazione.

Cosa non è ancora questo

La Responsible AI Scan fornisce l'inventario, la classificazione e la struttura di governance che si raccorda con quanto già esiste — incluso il format per un rapporto che il board legge effettivamente. La scan stessa è in fase di costruzione; chi desidera già qualcosa può iscriversi alla lista d'attesa.