Lei gestisce un registro dei rischi costruito attorno a rischi che si possono identificare, pesare e assegnare. Rischio operativo, rischio di credito, rischio di compliance: ognuno ha un proprietario, una misura di controllo, una linea di reporting. Il rischio AI non si inserisce automaticamente in questo schema, perché il primo problema non è la pesatura. Il primo problema è che non sa cosa sta pesando. Un team che usa un modello linguistico per scrivere bozze di consulenza, un reparto che ha attivato un abbonamento AI esterno fuori dal processo di acquisto IT, una macro in un foglio di calcolo che nel frattempo è diventata un modello predittivo: non sono casi marginali, è lì che si trova il rischio, e non figura da nessuna parte.
La sua domanda non è "l'AI è rischiosa". La sua domanda è: cosa è operativo, chi ne è responsabile, e su quale base informativa posso renderne conto al consiglio di amministrazione e all'autorità di vigilanza. La risposta che non accetta è la rassicurazione senza fondamento. "Non c'è nulla di particolare in corso" non è una risposta a una domanda di rischio, è l'assenza di una risposta. Un risk manager che trasmette questo al consiglio di amministrazione, trasmette che non si è guardato, non che non c'è nulla.
La seconda risposta che non accetta è l'elenco proveniente dalla gestione dei sistemi IT come quadro completo. Quell'elenco mostra ciò che è stato richiesto e approvato. L'uso dell'AI nasce in gran parte proprio fuori da quella richiesta, perché un abbonamento isolato, un'estensione del browser o una funzione integrata in software esistente non viene riconosciuta come "nuovo sistema". Chi vuole conoscere il rischio deve quindi consultare non solo il panorama dei sistemi, ma le persone che svolgono il lavoro, e questo richiede un approccio diverso da un audit IT.
Come risk manager conosce lo schema della sotto-segnalazione in ogni tema di rischio in cui un collaboratore ha qualcosa da perdere se risponde onestamente. L'uso dell'AI ne è un esempio lampante: se segnalare uno strumento utilizzato comporta la revoca dell'accesso, nessuno lo segnalerà più. L'inventario che produce risultati è quello che chiede senza collegare conseguenze alla risposta. È una competenza diversa da quella richiesta normalmente dal controllo dei rischi, ed è per questo che un inventario dell'AI ombra non viene impostato come controllo, ma come rilevazione.
Una volta mappato l'uso, il passo successivo non è valutare il fornitore o il modello. È valutare il ruolo che il sistema svolge in un processo. Un'applicazione AI che riformula testi comporta un rischio diverso rispetto a un'applicazione che influisce su una decisione riguardante un cliente, un collaboratore o un investimento. La stessa tecnologia, impiegata in un ruolo diverso, rientra in una classe di rischio diversa. Questa distinzione è esattamente ciò di cui un registro dei rischi ha bisogno per collocare il rischio AI accanto ai rischi già presenti, senza creare un capitolo AI separato e isolato che nessuno consulta.
Un risk manager non ha interesse in un nuovo framework accanto a quello esistente. L'interesse sta in un insieme di governance che si collega alla struttura del rischio già presente: la stessa logica di proprietà, i medesimi percorsi di escalation, lo stesso ciclo di reporting verso il consiglio di amministrazione. Il rischio AI trattato come tema separato scompare tra le rendicontazioni ordinarie. Il rischio AI incorporato nella tassonomia dei rischi esistente resta visibile nel punto in cui il consiglio di amministrazione già guarda.
A un certo punto le verrà chiesto cosa sa dell'uso dell'AI nell'organizzazione, da un'autorità di vigilanza, da un revisore o dal consiglio di amministrazione stesso. La risposta che tiene non è "tutto è mappato", perché per un modello di utilizzo dinamico questo è raramente dimostrabile. La risposta che tiene è un processo dimostrabile: come è stato effettuato l'inventario, quale classificazione è stata applicata, quali accordi di governance ne derivano, e con quale frequenza questo viene ripetuto. È un livello diverso dalla completezza, ed è il livello sul quale la gestione del rischio viene normalmente già valutata.
Questa domanda non si presenta in modo identico per ogni ruolo nell'organizzazione. Ciò di cui ha bisogno un compliance officer da questo inventario, lo trova in cosa deve sapere un compliance officer sul rischio AI, la questione di governo di chi guida il programma è descritta in cosa deve sapere un responsabile del programma AI sul rischio AI, e come questo tema si colloca a livello del consiglio di amministrazione stesso è descritto in cosa deve sapere un amministratore sul rischio AI. Per la gestione del rischio in settori specifici, con catene e forme di vigilanza proprie, il quadro è ulteriormente approfondito in come si presenta la governance AI nel settore delle costruzioni e in come si presenta la governance AI nel settore degli impianti.
Il testo delle norme vigenti, con le loro definizioni precise e le relative scadenze, non si trova in questa pagina e viene mantenuto aggiornato altrove. Ciò che qui è descritto è il meccanismo: come passare da un modello di utilizzo ignoto a un rischio classificabile e rendicontabile.
Un inventario del rischio AI inevitabilmente porta alla luce anche qualcos'altro: quale parte del lavoro viene già effettivamente svolta dall'AI, e quale parte potrebbe esserlo. È una domanda diversa dal controllo dei rischi, ma condivide la stessa fonte. La scansione del lavoro di FTE TO AI calcola per ogni mansione quale parte del lavoro può essere ripresa dall'AI, e si collega quindi esattamente all'inventario di cui la gestione del rischio ha già bisogno oggi.
Lo Responsible AI Scan è attualmente in fase di sviluppo. Chi desidera utilizzarlo non appena sarà disponibile può iscriversi alla lista d'attesa.
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.