Molto monitoraggio dell'uso dell'AI nasce come iniziativa separata: un nuovo modulo, una nuova riunione, un nuovo dashboard. Al momento del lancio sembra completo. Un anno dopo si è dissolto. Non perché il contenuto fosse scarso, ma perché stava accanto alla struttura esistente invece che dentro di essa.
La domanda quindi non è solo cosa va monitorato, ma dove quel monitoraggio va a collocarsi. Un processo che nessuno deve ricordare perché fa già parte di una routine che funziona comunque, sopravvive. Un processo che richiede un passo in più da persone già sovraccariche, dopo un certo tempo viene saltato. Non è mancanza di volontà. È una conseguenza prevedibile di come le organizzazioni gestiscono tempo e attenzione.
Ogni organizzazione ha già un ritmo: rendicontazioni trimestrali, comitati di rischio, cicli di audit, riunioni di team. Se il monitoraggio dell'uso dell'AI introduce un nuovo ritmo, entra in competizione con tutto ciò che già esiste — e di norma perde. Non c'è un punto all'ordine del giorno dedicato, nessun responsabile che lo vede come parte fondamentale della propria funzione, nessun momento in cui emerge spontaneamente.
Se invece il monitoraggio diventa una domanda che viene già posta — nel comitato di rischio esistente, nel controllo interno esistente, nella linea di rendicontazione esistente verso il consiglio di amministrazione — allora nessuno deve ricordare qualcosa di nuovo. La domanda "quali applicazioni di AI si sono aggiunte o sono cambiate" diventa allora altrettanto naturale quanto "ci sono nuovi fornitori" o "ci sono stati incidenti". Come si concretizza esattamente questo collegamento dipende da come è già organizzato da voi il collegamento alla struttura di rischio esistente — quella struttura è il punto di aggancio, non qualcosa a parte.
Un documento di monitoraggio funzionante è sufficientemente breve da poter essere usato ripetutamente e sufficientemente specifico da segnalare qualcosa quando cambia qualcosa. Contiene almeno:
Il valore del documento non sta nella completezza al primo giorno. Quella è raramente raggiungibile e nemmeno necessaria. Il valore sta nel fatto che viene mantenuto aggiornato, e che questo mantenimento non richiede uno sforzo separato oltre a ciò che già accade.
Il monitoraggio dipende da ciò che le persone sono disposte a segnalare. Nel momento in cui segnalare equivale a correre il rischio di essere sanzionati per qualcosa, l'informazione si blocca. Chi consegna un compito più velocemente del previsto usando uno strumento di AI, non lo segnala se la conseguenza è la revoca del budget o una conversazione difficile. L'elenco resta allora formalmente completo e vuoto nei contenuti — esattamente il problema che alimenta l'AI ombra.
La conseguenza è che il monitoraggio funziona solo se le domande vengono poste senza sanzioni. Non perché l'uso debba restare senza conseguenze, ma perché il primo passo — sapere cosa sta accadendo — richiede un atteggiamento diverso dal secondo passo — valutare se è appropriato. Chi fa coincidere questi due passi, non ottiene una risposta onesta per nessuno dei due.
Questa distinzione è anche il punto in cui governance e rendicontazione si incontrano. La visibilità per il consiglio di amministrazione non deve necessariamente significare che ogni singola applicazione venga portata sul tavolo; si tratta di un livello di rendicontazione che consente un giudizio senza perdersi nei dettagli, come descritto in una rendicontazione al consiglio che si adatta a una pagina. Ciò che sta sotto — la registrazione delle decisioni su applicazioni concrete — appartiene più a un elenco delle decisioni di oversight che al documento che sale in alto.
Se un documento di policy viene effettivamente letto è una domanda analoga: un testo che nessuno consulta non offre più appiglio di un processo di monitoraggio che nessuno compila. Si veda a questo proposito una policy sull'AI che viene letta. E per chi si chiede quale parte di questa responsabilità spetti al tavolo del consiglio di amministrazione e quale parte alla governance IT, c'è una distinzione tra cosa deve sapere un amministratore sul rischio AI e cosa deve sapere un CIO sul rischio AI — entrambe le domande richiedono livelli di dettaglio diversi all'interno dello stesso processo di monitoraggio.
Una struttura di monitoraggio che si collega a ciò che già esiste, a un certo punto fornisce un quadro affidabile di quali applicazioni di AI sono in uso e per cosa. Quell'inventario è una domanda diversa da quanto del lavoro sottostante viene effettivamente svolto dall'AI, e con quale effetto. Chi vuole farlo calcolare per singolo compito — quale parte di una funzione o di un processo può essere trasferita all'AI, sulla base dei compiti come vengono svolti ora — lo trova nella scansione del lavoro di FTE TO 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.