Ogni organizzazione di una certa dimensione ha già una struttura di rischio. Un comitato rischi, una funzione di audit, una linea di reporting verso il consiglio di amministrazione, un formato in cui i rischi vengono classificati e monitorati. Chi affianca a questa un nuovo processo, specifico per l'IA, con un proprio comitato, un proprio calendario e un proprio linguaggio, ottiene entro un anno un processo che nessuno compila più. Non perché l'IA non venga considerata importante, ma perché una seconda struttura entra in concorrenza con la prima per tempo, attenzione e mandato. La struttura esistente vince quasi sempre, perché è radicata nelle valutazioni, nei cicli di performance e nelle agende del consiglio. La nuova struttura resta fuori.
La domanda quindi non è come costruire una struttura di governance dell'IA. La domanda è come dare all'IA un posto nella struttura che già esiste.
La maggior parte delle strutture di rischio conosce già alcuni elementi fissi: un inventario dei rischi aggiornato periodicamente, una classificazione per gravità e probabilità, un responsabile per ogni rischio, una linea di escalation verso un livello superiore quando viene superata una soglia, e un reporting al consiglio a scadenze fisse. È questa la struttura in cui l'IA deve inserirsi, non affiancarsi.
Ciò significa che un'applicazione di IA non deve figurare in un registro AI separato, ma come voce di rischio nel registro esistente, con gli stessi campi di ogni altro rischio: responsabile, gravità, probabilità, mitigazione, data di stato. La classificazione per livello di rischio che accompagna un inventario dell'uso dell'IA deve collegarsi alla scala già in uso per il rischio operativo, non a una nuova scala inventata solo per l'IA. Chi legge cosa deve sapere un cio sul rischio ai vede che è proprio in questo collegamento che spesso le cose vanno male: un punteggio di rischio AI tecnicamente corretto che nessuno può confrontare con il resto del registro dei rischi.
Due elementi rendono difficile l'integrazione. Il primo è il linguaggio. I risk manager lavorano con concetti come impatto, probabilità e misura di mitigazione. I fornitori di IA e i team tecnici lavorano con versioni dei modelli, dati di addestramento e metriche di prestazione. Un set di governance scritto solo nel linguaggio tecnico non viene letto dal comitato rischi. Un set di governance scritto solo nel linguaggio del rischio non viene compilato dal responsabile tecnico. Il set deve essere leggibile in entrambe le direzioni: tecnico a sufficienza per essere corretto, comprensibile a livello di governance a sufficienza per essere accolto. Questo principio ritorna in una policy ai che viene letta: un documento che si collega a come le persone già leggono e decidono, invece di richiedere un nuovo modo di leggere.
Il secondo è il ritmo. Un comitato rischi si riunisce con un ciclo fisso, spesso trimestrale o mensile. L'uso dell'IA cambia più rapidamente: un team inizia questa settimana a usare un nuovo strumento, senza che questo sia precedeuto da una riunione. Il set di governance non deve quindi dipendere dal ciclo delle riunioni per funzionare. Deve esserci un meccanismo più leggero che assorba le deviazioni tra un momento fisso e l'altro, e che venga confermato formalmente solo al ciclo successivo. Come funziona questo meccanismo nella pratica è descritto in percorsi di escalation che funzionano: un percorso sufficientemente breve da poter essere usato prima che si riunisca il comitato trimestrale successivo.
Un set di governance che si collega a una struttura di rischio esistente contiene, nelle sue linee principali: una voce di inventario per ogni applicazione di IA con responsabile e classe di rischio, un collegamento al percorso di escalation esistente affinché una deviazione non finisca in un canale separato, e un posto fisso nel reporting periodico al consiglio. Non come capitolo separato sull'IA, ma come riga nella tabella che il consiglio già conosce. Come può presentarsi questo reporting senza introdurre un nuovo formato è descritto in come ottenere un reporting al consiglio di una pagina integrato in ciò che già circola.
Il contenuto delle regole stesse, cosa rientra esattamente in quale livello di rischio e quali termini vi si associano, è definito altrove e cambia; questa pagina riguarda il meccanismo che dà a quel contenuto un posto nella struttura esistente, non il testo di tali regole.
L'integrazione riesce solo se l'inventario è corretto fin dall'inizio. E questo è corretto solo se le persone osano dire cosa usano. Chi, compilando la voce di rischio, sente che una risposta onesta porterà a un'annotazione in una valutazione, non la compila onestamente. Il set di governance deve quindi rendere chiaro fin dalla prima versione che l'obiettivo è la visione d'insieme, non la sanzione. Senza questo impegno, parte dell'uso resta fuori dalla vista, e il collegamento alla struttura di rischio è costruito su un elenco incompleto. Ciò che un amministratore deve sapere in merito prima che inizi il primo inventario è descritto in cosa deve sapere un amministratore sul rischio ai.
Questa integrazione riguarda rischio, responsabilità e reporting: garantisce che ciò che fa l'IA sia visibile e gestibile all'interno della struttura già esistente. Un'altra domanda, che segue logicamente non appena si ha questa visione d'insieme, è cosa l'IA possa effettivamente assumere all'interno di quel lavoro. La scansione del lavoro di FTE TO AI calcola per ogni compito quale parte del lavoro può essere trasferita all'IA, come passo successivo una volta che il lato della governance è a posto.
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.