Un elenco delle decisioni di oversight non è un nuovo modulo né una nuova riunione. È un luogo fisso dove viene registrato quale applicazione di AI è stata valutata, da chi, sulla base di quale valutazione del rischio, e con quale decisione. Approvata, respinta, con condizioni, o temporaneamente consentita in attesa di ulteriori verifiche. Senza quell'elenco, una decisione esiste solo nella memoria di chi era presente, e svanisce non appena qualcuno cambia funzione o la conversazione non viene messa a verbale.
L'elenco contiene, per ogni applicazione, una breve descrizione del compito, la classificazione per ruolo e livello di rischio, il nome del proprietario del processo, la data della valutazione, la decisione presa e la relativa motivazione. Nessuna specifica tecnica, nessuna documentazione del fornitore: questo appartiene al dossier dell'applicazione stessa, non all'elenco delle decisioni. L'elenco è una panoramica a un livello superiore — chi ha deciso cosa, e quando quella decisione è stata riconfermata per l'ultima volta. Un'applicazione approvata un anno fa per un compito a rischio limitato, potrebbe nel frattempo essere usata per qualcos'altro. Senza una riconferma periodica, una vecchia decisione continua a valere per una situazione che non esiste più.
La ragione per cui i registri AI separati spesso rimangono vuoti non è la riluttanza, ma l'ordine delle cose. Ogni organizzazione ha già un luogo dove i rischi vengono discussi e registrati: un comitato rischi, una commissione di audit, una riunione direttiva con un punto fisso all'ordine del giorno sul rischio operativo. Chi allestisce inoltre un registro AI separato, chiede alle persone di gestire una seconda amministrazione per qualcosa che, nel merito, appartiene alla prima. Quel secondo processo perde, strutturalmente, contro l'urgenza quotidiana. L'elenco delle decisioni di oversight funziona solo se è integrato in ciò che già esiste — come parte fissa di una riunione esistente, con un posto fisso all'ordine del giorno, invece che come nuovo obbligo a parte.
Ciò significa anche che l'elenco usa la stessa scala e lo stesso linguaggio del resto della struttura di rischio. Un'applicazione con un livello di rischio elevato riceve lo stesso tipo di attenzione di un altro dossier con un livello di rischio elevato: frequenza di rendicontazione fissa, proprietario fisso, linea di escalation fissa. Come si presenta questo collegamento nella pratica dipende dalla governance esistente dell'organizzazione ed è descritto nella pagina sul collegamento alla struttura di rischio esistente.
Un elenco delle decisioni è inutile senza un percorso per ciò che accade quando qualcuno non è d'accordo, o quando un'applicazione cambia senza che nessuno lo segnali. Quel percorso non appartiene all'elenco stesso, ma deve collegarsi ad esso: chi vuole contestare un rifiuto, chi deve rinnovare un'autorizzazione temporanea, e a chi arriva una questione quando il proprietario del processo e la funzione di rischio non sono d'accordo. Come si articolano questi percorsi senza che ogni domanda finisca in cima all'organizzazione è descritto in percorsi di escalation che funzionano.
L'elenco delle decisioni è la memoria; il consiglio ha inoltre bisogno di una sintesi che non debba essere ricomposta ogni trimestre a partire da verbali sparsi. Cosa deve contenere quella sintesi — e cosa invece no, perché già presente nell'elenco delle decisioni — è descritto nella pagina su una rendicontazione al consiglio di una pagina. Senza questo passaggio, l'elenco delle decisioni resta un documento letto solo dai proprietari dei processi, mentre il consiglio rimane giuridicamente responsabile di ciò che viene deciso.
Registrare una decisione non è la stessa cosa che sapere se la decisione viene rispettata. Un'applicazione respinta può comunque rimanere in uso se nessuno verifica che il rifiuto sia stato effettivamente applicato. Questo è il motivo per cui un elenco delle decisioni senza seguito produce poco: documenta intenzioni, non comportamenti. Ciò che serve per vedere se una decisione tiene davvero, e quali segnali vi sono associati, è descritto nella pagina sul monitoraggio che produce qualcosa.
Un elenco delle decisioni può contenere solo ciò che è stato segnalato. Chi dipende dalle segnalazioni tramite il reparto IT vede una frazione di ciò che viene effettivamente usato: la maggior parte dell'uso dell'AI in un'organizzazione nasce fuori dai percorsi formali di acquisto, in team che provano uno strumento perché funziona. Se quelle applicazioni finiscano mai nell'elenco delle decisioni dipende dal fatto che i collaboratori osino raccontare cosa usano — e ciò accade solo se le domande al riguardo non vengono percepite come l'anticamera di una sanzione.
La prima domanda che aiuta in questo non è 'quale AI è stata approvata' ma 'quale parte di questo lavoro viene già svolta, o potrebbe essere svolta, dall'AI'. È un punto di partenza diverso da un elenco delle decisioni, e più completo: la scansione del lavoro di FTE TO AI calcola, per ogni compito, quale parte del lavoro può essere assunta dall'AI, gettando così una base che non dipende da ciò che è stato casualmente segnalato. Da quel risultato diventa visibile quali applicazioni sono già effettivamente in funzione prima ancora che l'elenco delle decisioni ne sappia nulla.
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.