Un responsabile di programma AI riceve solitamente un mandato: garantire che l'AI venga adottata, che i team ne beneficino in velocità, che il programma mostri risultati. Raramente si aggiunge un secondo mandato: garantire che tutto ciò che nel frattempo emerge sia responsabile. Eppure viene giudicato su entrambi nel momento in cui qualcosa va storto. Questo è il nucleo del suo rischio: è responsabile di un programma di cui non conosce i confini.
Ciò che guadagna con l'adozione — processi più rapidi, team soddisfatti, una storia di innovazione visibile — si contrappone a ciò che perde se le cose vanno male: un incidente con uno strumento che non era sulla sua lista, un audit che pone domande a cui non ha risposta, un consiglio di amministrazione che chiede perché il programma non ha visto ciò che già era in funzione. Questa asimmetria rende la sua posizione vulnerabile, anche quando il programma stesso funziona bene.
La sua domanda non è "quali strumenti AI abbiamo approvato". Quella lista la possiede già, ed è spesso più corta della realtà. La sua domanda è: cosa usano i team che non figurano nella mia lista, e come faccio a renderlo visibile senza che le persone lo nascondano. Un responsabile di programma che vuole stimolare l'adozione non può permettersi che gli utenti nascondano i loro strumenti per paura di una correzione. Chi chiede cosa viene utilizzato e poi ne fa un problema, alla domanda successiva non riceverà più risposta. Governance e adozione qui lavorano l'una contro l'altra se l'approccio è sbagliato.
Una risposta che non accetta è un blocco secco: "L'uso dell'AI non è consentito senza approvazione." Quella risposta soddisfa un revisore per un momento, ma sposta l'uso verso luoghi che nessuno vede. È l'opposto di ciò che un responsabile di programma vuole ottenere: vuole che l'uso dell'AI sia visibile e accompagnato, non che scenda nel sommerso. Un divieto senza un meccanismo per segnalare e imparare rappresenta per lui una perdita, anche se sulla carta suona conforme.
Non accetta nemmeno una risposta che tratta tutto allo stesso modo. Uno strumento che riassume testi per uso interno non comporta lo stesso rischio di uno strumento che prende decisioni automatiche su clienti o dipendenti. Senza una distinzione per ruolo e livello di rischio, un programma non può stabilire priorità, e un responsabile di programma che non può stabilire priorità non può svolgere il proprio mandato.
Quello che funziona è un inventario che parte da ciò che esiste, non da ciò che è stato approvato. Ciò significa porre domande ai team su cosa usano effettivamente, e farlo in un modo che non comporti sanzioni. Solo così emerge l'AI ombra — i sistemi introdotti senza un percorso formale, spesso perché alleggerivano il lavoro e nessuno ha visto una ragione per attendere l'approvazione.
Segue poi la classificazione: quale applicazione riguarda i clienti, quale riguarda solo il processo interno, quale prende decisioni senza un essere umano nel mezzo. Questa suddivisione determina dove il controllo deve essere rigoroso e dove può rimanere leggero. Senza questa suddivisione, un programma tratta tutto con lo stesso rigore o la stessa leggerezza, ed entrambi sono un problema: il primo frena l'adozione, il secondo lascia i rischi non gestiti.
La struttura di governance che ne segue deve collegarsi a ciò che già esiste all'interno dell'organizzazione — i comitati di rischio esistenti, le linee di reporting esistenti — non un nuovo circuito parallelo. È anche qui che un responsabile di programma si distingue da altri ruoli nell'organizzazione: un amministratore vuole sapere cosa deve sapere un amministratore sul rischio AI al livello della responsabilità ultima, un CIO lo affronta dal punto di vista dei sistemi e degli accessi come descritto in cosa deve sapere un CIO sul rischio AI, e un General Counsel guarda alla responsabilità legale e all'obbligo di documentazione tramite cosa deve sapere un General Counsel sul rischio AI. Un responsabile di programma deve essere in grado di servire queste tre prospettive senza perdere il proprio compito — l'adozione.
Quali obblighi concreti valgono per quale categoria di rischio, e entro quali termini, non è l'argomento di questa pagina. Quel testo cambia, viene inasprito e riceve spiegazioni altrove. Qui si tratta del meccanismo: come un programma ottiene visibilità su ciò che accade, come lo traduce in livelli di rischio, e come lo dimostra al consiglio e agli organi di controllo, indipendentemente da ciò che il testo normativo esatto prescrive in un dato momento.
Non appena è chiaro cosa è in funzione e chi ne è responsabile, emerge un'altra domanda: cosa rende in termini di risultato se quel lavoro viene organizzato bene. È una domanda che deve trovare risposta per singola attività, non per organizzazione. La werkscan di FTE TO AI calcola a quel livello quale parte del lavoro può essere assunta dall'AI, in modo che un responsabile di programma non sappia solo cosa sta accadendo, ma anche dove l'aggiunta di capacità fa davvero la differenza.
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.