Un collaboratore incolla un pezzo di testo in una finestra di chat gratuita perché funziona più velocemente del sistema interno. Un team si abbona a uno strumento di IA perché la richiesta per qualcosa di ufficiale richiederebbe settimane. Un fornitore aggiunge funzionalità di IA a un software già in uso da anni, senza che ne sia stata discussa la questione. Nessuna di queste persone sta cercando di nascondere qualcosa. Stanno solo cercando di svolgere il proprio lavoro.
Questo è il nocciolo dell'IA ombra: non nasce dalla cattiva volontà, ma da un divario tra ciò di cui le persone hanno bisogno e ciò che il processo formale offre. Finché questo divario esiste, l'IA ombra continuerà a manifestarsi, indipendentemente da quante politiche vengano scritte.
La maggior parte delle organizzazioni dispone di un elenco di software approvati. Questo elenco è un punto di partenza, non un riflesso della realtà. Ciò che le persone effettivamente utilizzano è quasi sempre in anticipo su di esso: la domanda su come evitare che i dati aziendali finiscano in una finestra di chat gratuita illustra quanto facilmente uno strumento possa finire fuori da ogni controllo. Lo stesso vale per un reparto che sottoscrive di propria iniziativa un abbonamento perché la via ufficiale sembra troppo lenta, o per un'estensione del browser che ottiene accesso alla posta senza che esista un'approvazione separata per questo. Nessuna di queste situazioni compare in un elenco IT. Eppure esistono.
Esiste la tendenza a trattare l'IA ombra come un problema di applicazione delle regole: vietare, bloccare, sanzionare. Questo produce l'effetto contrario. Chi sa che una risposta sincera porta a un problema, smette di darla. Lo strumento non scompare, diventa solo più invisibile. Esattamente il contrario di ciò di cui un'organizzazione ha bisogno.
Una seconda ragione per cui il problema non si risolve da solo: la governance esistente è spesso costruita per software che si acquista e si installa, non per un servizio che qualcuno apre in un browser e abbandona il giorno dopo. Una configurazione di prova che in origine era pensata come temporanea mostra come qualcosa di piccolo, senza un momento chiaro di valutazione, possa proseguire per anni senza che nessuno se ne senta responsabile. Senza un processo che rilevi in modo strutturale questo tipo di utilizzo, esso resta sotto il radar, per quanto buone siano le intenzioni.
Il solo modo per sapere cosa sta effettivamente accadendo è chiederlo. Non come controllo, ma come inventario. I collaboratori che sanno che una risposta sincera non porterà a un colloquio con le Risorse Umane, quella risposta la danno davvero. Questo richiede un tono e un processo che chiariscano fin dall'inizio: si tratta di ottenere visibilità, non di colpire qualcuno.
A ciò si aggiunge anche l'attenzione al modo in cui i nuovi processi vengono affiancati a quelli esistenti. Un secondo processo che viene affiancato a quello esistente senza che il primo venga modificato o ritirato, viene spesso ignorato, semplicemente perché le persone continuano con le proprie abitudini. Un inventario che si presenta come un obbligo aggiuntivo sopra il lavoro già esistente riceve lo stesso trattamento.
Una volta chiarito ciò che viene effettivamente utilizzato, segue la domanda successiva: cosa fa quello strumento e quale rischio comporta? Uno strumento che riassume testi per uso interno richiede un approccio diverso da uno strumento che partecipa alle decisioni sull'accettazione dei clienti o sulla valutazione del personale. Questa classificazione per ruolo e livello di rischio è ciò che trasforma un inventario in qualcosa di utilizzabile: una base su cui il consiglio di amministrazione, il CIO o il General Counsel possono spiegare cosa sta accadendo e perché ciò è giustificabile.
Questo livello di governance si integra con la struttura di rischio che un'organizzazione già possiede, non con un nuovo quadro separato. Il contenuto delle regole a cui le applicazioni di IA devono conformarsi cambia e viene aggiornato altrove; ciò che conta qui è che l'organizzazione disponga di un metodo funzionante per sapere cosa è in uso, chi ne è responsabile e come ciò venga dimostrato al consiglio di amministrazione o all'autorità di controllo.
Una volta chiarito quale IA viene effettivamente utilizzata e con quale livello di rischio, emerge naturalmente un'altra domanda: quale parte del lavoro potrebbe effettivamente essere svolta da un'applicazione di IA, e quale parte no. È una domanda diversa da quella dell'approvazione e del controllo, ma che ne segue logicamente. La scansione del lavoro di FTE TO AI calcola, per ogni compito, quale parte del lavoro può essere assunta dall'IA, sulla base di ciò che una funzione effettivamente comporta. Mentre la Responsible AI Scan porta ordine in ciò che è già in uso, la scansione del lavoro mostra ciò che ancora si può guadagnare.
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.