Un team voleva provare qualcosa. Un chatbot per le domande dei clienti, uno script che riassume i rapporti, un collegamento con un modello linguistico per ordinare le e-mail. Non era necessaria una grande decisione: qualcuno aveva un account, una chiave API o un periodo di prova gratuito, e nel giro di un pomeriggio qualcosa era già in funzione. Il pilot funzionava, o funzionava a sufficienza, e nessuno aveva più un motivo per spegnerlo.
Questo non è un'eccezione. È il modo normale in cui l'IA entra in un'organizzazione. Non tramite un appalto o un budget approvato, ma tramite un impianto pilota che sopravvive al proprio status di prova. La fase di test non è mai stata formalmente chiusa, perché non c'è mai stato nemmeno un inizio formale da chiudere.
Un pilot che funziona, viene utilizzato. E ciò che viene utilizzato, diventa dipendenza. Il team che ha costruito il riassuntore di rapporti se ne è forse andato, ma il riassunto arriva ancora ogni settimana. Nessuno ha l'incarico di spegnerlo, e nessuno vuole correre il rischio che qualcosa smetta di funzionare senza sapere cosa lo sostituirà.
A ciò si aggiunge che un impianto pilota di solito non ha un proprietario nel senso che una struttura di governance si aspetterebbe. Non è stata effettuata una classificazione del rischio, non è stata svolta un'analisi dei dati, non è stata presa alcuna decisione su chi sia responsabile in caso di problemi. Il pilot esiste in uno spazio intermedio: troppo utilizzato per essere ignorato, troppo informale per essere gestito. Questo è esattamente il modello che porta a dipendenti che usano uno strumento che nessuno ha approvato — solo che qui accade a livello di team invece che a livello individuale.
La reazione istintiva quando si scopre un impianto pilota non autorizzato è spesso: chi ha permesso questo, e perché non lo sapevamo. Questa domanda è comprensibile, ma ha l'effetto contrario. Chi sente già durante la prima conversazione che sta arrivando una richiesta di responsabilità, la prossima volta non racconterà più nulla. E il prossimo impianto pilota — che senza dubbio arriverà — sparirà dalla vista esattamente come questo.
Un inventario costruito sulla fiducia porta a risultati migliori di un audit costruito sul controllo. Non perché le persone non vorrebbero avere nulla da nascondere, ma perché le informazioni che si cercano si trovano dall'utente, e quell'utente parla solo se non viene giudicato per quello che ha fatto.
Una volta che un impianto pilota è emerso, la prima domanda non è se possa continuare a esistere, ma cosa faccia esattamente. Quali dati vi entrano, chi usa il risultato, e cosa succede se il risultato è sbagliato. Sono le stesse domande valide per ogni altra applicazione di IA, e la risposta determina se qualcosa è uno strumento informale o un rischio che merita attenzione.
Segue poi la classificazione: l'applicazione rientra in una categoria di rischio già esistente, o richiede una nuova valutazione. Poi: cosa deve essere documentato per dimostrare che l'organizzazione sa cosa è in funzione e perché. È esattamente questo il tema di cosa deve essere documentato per ogni applicazione — non come burocrazia aggiuntiva, ma come la documentazione minima necessaria per distinguere un pilot da un rischio.
Un impianto pilota che supera questa verifica può continuare a esistere, ora con un proprietario e una classificazione. Un impianto pilota che non supera la verifica deve essere smantellato — ma si tratta di un processo controllato, non di un licenziamento della persona che lo ha avviato in origine.
L'impianto pilota che non è mai stato spento è una forma di un modello più ampio. Si pensi all'estensione del browser con accesso alla posta che qualcuno ha installato per risparmiare tempo, o ai dati aziendali che finiscono in una finestra di chat gratuita perché era più veloce dello strumento ufficiale. Tutte queste situazioni condividono una caratteristica: sono nate da un'esigenza pratica, non da una scelta politica, e continuano a esistere finché nessuno se ne accorge.
L'elenco IT del software approvato non è quindi il punto di partenza di un inventario — è il punto di partenza di una ricerca di ciò che rimane fuori da quell'elenco. Chi vuole sapere come si svolge questa ricerca, trova un approccio in come costruire un inventario dell'IA.
Un impianto pilota che viene alla luce solleva di solito una domanda successiva che va oltre la governance: perché in realtà funzionava così bene che nessuno osava fermarlo? Questa è una domanda sul lavoro stesso, non solo sul rischio. Lo scan del lavoro di FTE TO AI calcola, per ogni compito, quale parte del lavoro può essere assunta dall'IA, rendendo così visibile ciò che un impianto pilota già mostrava implicitamente: che una parte del lavoro può essere organizzata diversamente. Mentre la Responsible AI Scan mappa cosa è in funzione e sotto quale rischio, lo scan del lavoro mostra da dove proviene quell'uso e cosa significa strutturalmente per la ripartizione dei compiti.
La Responsible AI Scan, con l'inventario, la classificazione e il set di governance descritti sopra, è in fase di sviluppo. Chi ha già a che fare con questo tema e desidera essere informato non appena lo strumento 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.