Un compliance officer non perde alla prima domanda sull'AI. Perde alla seconda: quando emerge che la risposta alla prima domanda era incompleta. "Quali sistemi AI utilizza la vostra organizzazione" si può rispondere con un elenco tratto dal portafoglio IT. La domanda che segue — "è questo l'elenco completo" — è la domanda su cui la maggior parte dei fascicoli di compliance si arena.
Non: quali strumenti AI ha acquistato l'organizzazione. Ma: quali sistemi AI vengono effettivamente utilizzati, da chi, per quali decisioni, e sulla base di quale valutazione del rischio. Sono quattro domande, non una. La prima è un elenco d'acquisto. Le altre tre richiedono che le persone raccontino cosa fanno, compreso ciò che non hanno fatto approvare. Un compliance officer che dispone solo dell'elenco d'acquisto ha una falsa sensazione di copertura — ed è più rischioso che non avere copertura, perché viene riportato come completo.
I collaboratori che utilizzano uno strumento linguistico o di analisi senza acquistarlo tramite l'IT non lasciano traccia di ciò in un registro degli asset. Ne lasciano invece traccia in ciò che producono: report, comunicazioni con i clienti, consulenze. Il divario tra ciò che è registrato e ciò che viene utilizzato non è di solito una violazione deliberata. È il risultato di un'organizzazione che trova più rapidamente uno strumento che non un processo di approvazione. La compliance non può colmare questo divario con un divieto più severo — ciò sposterebbe l'uso solo più fuori dalla vista. Il divario si colma facendo domande senza che sulla risposta gravi una sanzione. Chi teme un'annotazione nel proprio fascicolo non racconta cosa usa; racconta ciò che pensa che lei voglia sentire.
Un risk manager vuole sapere quanto sia grande l'esposizione. Un compliance officer vuole questo, più qualcosa in più: posso dimostrare che abbiamo seguito il processo, anche se il risultato si rivela in seguito discutibile. È un tipo di onere probatorio diverso. Non si tratta solo della classificazione di un sistema, ma della traccia: chi ha valutato questo, in quale momento, con quali informazioni, e se tale valutazione è stata ripetuta quando il sistema è cambiato. I sistemi AI vengono aggiornati senza preavviso; una classificazione di sei mesi fa dice poco sul sistema di oggi. La compliance deve quindi poter mostrare non solo un risultato, ma un processo che continua a funzionare.
"Abbiamo una politica sull'AI" non è una risposta alla domanda se quella politica copra qualcosa. Un documento di policy che non è mai stato confrontato con ciò che effettivamente viene usato è una dichiarazione di intenti, non una dichiarazione dello stato attuale. Ciò di cui un compliance officer ha bisogno è un inventario che si allinei alle categorie di rischio esistenti — la stessa classificazione già utilizzata per altri rischi operativi — affinché l'AI non venga collocata come argomento separato ed esotico accanto al resto del quadro di rischio, ma al suo interno.
Il compliance officer raramente elabora questo aspetto da solo. La domanda su quali sistemi siano considerati ad alto rischio e quale onere probatorio comportino riguarda ciò che un General Counsel deve sapere sul rischio AI dal punto di vista della responsabilità e degli obblighi contrattuali. La domanda se l'organizzazione sia in grado, dal punto di vista tecnico, di tracciare quali sistemi sono in funzione riguarda cosa deve sapere un CIO sul rischio AI. E la domanda se questo tema raggiunga il tavolo del consiglio prima di degenerare riguarda cosa deve sapere un amministratore sul rischio AI. La compliance è spesso la parte che deve far convergere queste tre linee senza essere essa stessa proprietaria della tecnologia o del contratto.
Il contenuto normativo — quali obblighi vigono esattamente, per categoria di rischio, con quali scadenze — si trova altrove e cambia. Questa pagina descrive il meccanismo: come sapere cosa è in funzione, come classificarlo, e come dimostrare che il processo è stato seguito. Un compliance officer in cerca del testo normativo attuale non lo troverà qui.
Quanto shadow AI abbia un'organizzazione dipende dal settore, dalla cultura e da quanto rigorosamente sono stati applicati i divieti precedenti. Un divieto più severo correla spesso con un uso più occulto, non con meno uso. Questo schema non è uguale ovunque: in il settore delle costruzioni il fulcro sta nel calcolo dei progetti e nella pianificazione, mentre nel settore degli impianti si tratta più spesso di diagnostica di manutenzione e analisi dei guasti. L'inventario deve quindi essere svolto per ogni singola organizzazione; una media nazionale dice poco sulla propria esposizione specifica.
La Responsible AI Scan mappa ciò che viene effettivamente utilizzato, lo classifica per ruolo e livello di rischio, e fornisce un set di governance che si allinea alla struttura di rischio esistente — senza anticipare ciò che è già stato stabilito altrove. Questa scan è in fase di sviluppo. Chi è interessato può iscriversi alla lista d'attesa; non viene offerto nulla che non sia ancora pronto.
Chi sa quali sistemi AI sono in funzione, si scontra spesso con la domanda successiva: cosa significa questo per l'organico e la distribuzione dei compiti. È un calcolo diverso dalla classificazione del rischio, e lo effettua FTE TO AI con la werkscan, che calcola per ogni mansione quale parte del lavoro può essere assunta dall'AI.
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.