Kennisbank

Monitoraggio che viene effettivamente utilizzato

Il problema non è l'assenza di monitoraggio

La maggior parte delle organizzazioni ha già qualcosa che viene chiamato monitoraggio. Una dashboard, un formato di reportistica, una riunione periodica in cui vengono discussi i rischi. Il problema non è che questo manchi. Il problema è che il monitoraggio dell'IA viene collocato come elemento separato, con un proprio ritmo, un proprio responsabile e un proprio modello. Chi ha già tre processi per monitorare il rischio, non compilerà fedelmente un quarto processo. Diventa un obbligo che viene sbrigato una volta al trimestre, o non viene svolto affatto.

Ecco perché il monitoraggio dell'uso dell'IA così spesso non produce nulla. Non perché le domande siano sbagliate, ma perché il processo stesso resta un corpo estraneo all'interno di un'organizzazione che ha già processi per il rischio, la compliance e il controllo interno.

Cosa deve contenere un monitoraggio efficace

Un monitoraggio che produce risultati non inizia con un modello ma con una domanda: cosa cambia, e chi se ne accorge per primo? Per i sistemi di IA questo significa tre livelli.

Il primo livello è l'uso: un sistema viene ancora utilizzato come previsto, o l'applicazione è cambiata senza che nessuno lo abbia segnalato? Uno strumento che è iniziato come controllo testuale e ora viene utilizzato per formulare bozze di decisioni, comporta un rischio diverso da quello stabilito all'avvio.

Il secondo livello è la provenienza: il sistema è ancora lo stesso di quando è stato classificato? I modelli sottostanti vengono sostituiti, i fornitori modificano le loro condizioni, uno strumento isolato viene integrato in una piattaforma più ampia. Ogni modifica può rendere non valida la valutazione del rischio effettuata a suo tempo, senza che nessuno la riconsideri.

Il terzo livello è il segnale: ci sono reclami, messaggi di errore o anomalie che indicano che qualcosa non funziona come si presumeva? Questo è il livello che manca più spesso, perché nessuno ha interesse a segnalare un problema con un sistema che ufficialmente non esiste.

Perché un secondo processo viene ignorato

Un'organizzazione che ha già un ciclo di rischio per i rischi operativi, finanziari o per la protezione dei dati, non avvierà un nuovo ciclo per l'IA. Non è mancanza di volontà; è una questione di capacità. Chi ci provi, vede accadere due cose. O il nuovo monitoraggio si esaurisce, perché nessuno trova il tempo di alimentare un sistema che nessuno richiede. Oppure il nuovo monitoraggio viene assorbito dalle stesse persone che già gestiscono il ciclo esistente, e allora la distinzione svanisce da sé.

La domanda quindi non è se ci debba essere un processo separato di monitoraggio dell'IA. La domanda è come i segnali relativi all'IA entrino nel ciclo esistente, in modo che vengano discussi nella stessa riunione, con lo stesso responsabile e con lo stesso ritmo degli altri rischi. Come questo venga concretamente organizzato, dipende da come funziona già oggi quel ciclo esistente: alcune organizzazioni hanno una rendicontazione trimestrale al comitato di audit, altre una riunione mensile sul rischio a livello di direzione, altre ancora un registro continuo aggiornato per ogni incidente. Maggiori informazioni su come integrare il monitoraggio che produce risultati in ciò che già funziona invece di aggiungerlo come elemento separato si trovano in una pagina separata, poiché questo meccanismo viene declinato diversamente da organizzazione a organizzazione.

Il documento che è pronto quando qualcuno lo richiede

Ciò che invece si adatta universalmente è una forma fissa in cui viene registrato lo stato dei sistemi di IA: cosa è in funzione, in quale ruolo, con quale livello di rischio, e quando è stato confermato per l'ultima volta. Non come documento IA separato, ma come allegato o elemento fisso della reportistica già esistente. Questo può collegarsi a una rendicontazione al board di una pagina che riassume i rischi senza occultarli, in modo che il monitoraggio non diventi un flusso di informazioni separato, ma una riga in una tabella che il dirigente già legge.

Questa forma funziona solo se la classificazione sottostante rimane essa stessa aggiornata, e quella classificazione deve a sua volta collegarsi alla struttura di rischio già esistente. Senza questo collegamento, il monitoraggio resta una seconda lingua accanto alla prima, e quella seconda lingua viene dimenticata non appena la pressione aumenta. L'aspetto che assume questo collegamento dipende da come struttura di rischio e classificazione dell'IA si combinano in ciò che un'organizzazione già utilizza, e non può essere descritto in termini generali senza conoscere la struttura esistente.

Ciò che il monitoraggio rileva va oltre un documento

Un monitoraggio efficace segnala non solo il rischio ma anche lo spostamento: sistemi utilizzati diversamente da come previsto, o compiti che sono stati silenziosamente rilevati senza che nessuno lo abbia registrato. Questi stessi segnali sono anche informazioni su dove le persone dedicano effettivamente il proprio tempo, e dove l'IA sta di fatto già sostituendo il lavoro senza che ciò sia stato annotato da nessuna parte. Chi vuole rendere questa domanda più concreta di quanto consenta una classificazione del rischio, può consultare la scansione del lavoro di FTE TO AI per vedere quale parte del lavoro, per compito, si presta all'IA, indipendentemente dal fatto che ciò avvenga già o debba ancora essere deciso. Quella scansione non calcola in termini di rischio, ma in termini di compiti e ore, e per questo si collega a ciò che il monitoraggio segnala senza spiegarlo.