Un elenco delle decisioni di oversight registra chi ha preso quale decisione su quale sistema di AI, sulla base di quali informazioni, e con quale riserva. Sembra semplice. In pratica, la prima versione fallisce spesso perché viene presentata come un nuovo processo accanto agli incontri già esistenti. Un secondo processo accanto a quello esistente viene ignorato, non perché le persone non siano disposte, ma perché nessuno riserva tempo per qualcosa che non si inserisce in un'agenda già piena.
L'elenco non è un registro delle attività né un registro dei rischi. Contiene decisioni: momenti in cui qualcuno con autorità ha approvato, respinto, rinviato o fatto proseguire qualcosa a determinate condizioni. Per ogni riga sono necessari almeno quattro elementi: il sistema o l'applicazione a cui si riferisce la decisione, il nome e il ruolo di chi ha deciso, la data, e la motivazione o la riserva. Senza motivazione, un elenco delle decisioni è un elenco di presenze. Con la motivazione, diventa la prova che si è riflettuto, non solo che si è spuntata una casella.
L'elenco deve inoltre offrire spazio per la revisione. Una decisione presa sei mesi fa sulla base delle informazioni allora disponibili può essere superata. Un buon elenco delle decisioni mostra quando una decisione è stata riconfermata o revocata, non solo quando è stata presa originariamente.
I consigli di amministrazione e le direzioni hanno già un ritmo: riunioni trimestrali, comitati rischi, comitati di audit. Chi crea una nuova struttura di oversight separata da quel ritmo chiede alle persone di trovare tempo extra per qualcosa che non ha un posto definito. Ciò accade raramente in modo strutturale. Le prime volte può funzionare, con impegno. Poi scompare dall'agenda non appena arriva qualcosa di più urgente, e qualcosa di più urgente arriva sempre.
La soluzione non è costruire un nuovo processo, ma far sì che l'elenco delle decisioni si integri in ciò che già avviene. Se esiste già un comitato rischi che si riunisce ogni trimestre, l'elenco delle decisioni AI deve essere una parte fissa di quell'agenda, non una sessione separata. Se esiste già un percorso di audit per le decisioni finanziarie, la logica di quel percorso — chi firma, chi controlla, dove viene archiviato — deve essere riutilizzata per le decisioni AI. È anche per questo che collegarsi alla struttura di rischio esistente è un argomento separato: un elenco delle decisioni che non si collega a come il rischio viene già discusso altrove resta un documento isolato che nessuno consulta.
Un elenco delle decisioni non funziona da solo. Alimenta la rendicontazione di cui un consiglio di amministrazione ha bisogno per poter affermare di avere visibilità sul rischio AI, e presuppone che esista un percorso per quando una decisione risulta non più sostenibile. Senza un rapporto al consiglio di una pagina che riassuma l'elenco delle decisioni, l'informazione finisce in un archivio che nessuno sfoglia. Senza percorsi di escalation funzionanti, una decisione superata rimane semplicemente in vigore, perché nessuno sa a chi segnalarla.
I tre elementi sono collegati: l'elenco delle decisioni registra ciò che è stato deciso, la rendicontazione lo rende visibile al livello dove ha peso, e l'escalation garantisce che una decisione possa essere riaperta se la situazione cambia. Costruirne uno senza gli altri due crea un'apparenza di controllo che, alla prima verifica — un incidente, una domanda di un'autorità di controllo, un giornalista — si rivela non coprire ciò che effettivamente accade.
Un elenco delle decisioni vale quanto le informazioni che vi vengono inserite. Se nessuno sa quali sistemi di AI siano effettivamente in uso — incluso ciò che è stato acquistato o avviato al di fuori dell'IT — l'elenco registra solo le decisioni relative alle applicazioni visibili e formalmente approvate. Il resto rimane senza decisione, non perché non fosse necessaria una decisione, ma perché nessuno sapeva che ci fosse qualcosa su cui decidere. Ecco perché un inventario precede sempre un elenco delle decisioni, non lo segue. Ciò che un amministratore deve sapere in merito è descritto in cosa deve sapere un amministratore sul rischio AI; ciò che un CIO deve riconoscere in quell'inventario è descritto in cosa deve sapere un CIO sul rischio AI.
Ciò che è certo: un elenco delle decisioni non collegato a un incontro esistente non viene mantenuto, e un elenco delle decisioni senza un quadro completo di ciò che è in uso registra solo una parte della realtà. Ciò che dipende dall'organizzazione: quale incontro sia il punto di riferimento indicato, con quale frequenza si riunisca, e chi abbia l'autorità di prendere una decisione che finisce nell'elenco. Ciò varia per settore, per struttura di governo societario e per cultura del rischio, e per questo non esiste un modello fisso valido ovunque senza adattamenti.
Lo Responsible AI Scan è in fase di sviluppo. Chi ha attualmente bisogno di un elenco delle decisioni che si integri nella struttura esistente può iscriversi alla lista d'attesa; non viene ancora offerto nulla che non esista già.
Un elenco delle decisioni indica chi ha deciso, non quanto lavoro un sistema effettivamente sostituisce o potrebbe sostituire. Per quella domanda — quale parte di un compito si può trasferire all'AI, e quale parte no — è necessaria una prospettiva diversa da quella che offre solo la governance. La werkscan di FTE TO AI calcola per ciascun compito quale parte del lavoro può essere trasferita, come complemento al quadro offerto da un elenco delle decisioni e dalla relativa struttura di oversight.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.