La governance dell'IA non può rimanere confinata al livello delle politiche.

Ai leader non mancava la responsabilità. Mancava invece una visione chiara e fruibile della situazione. Ogni giorno, i leader in prima linea dovevano dedicare tempo a verificare, raccogliere, confrontare e preparare le informazioni necessarie prima di poter guidare efficacemente. Non potevano fornire un supporto concreto partendo da una visione chiara del lavoro. Prima dovevano ricostruire la situazione, controllare i dati, monitorare i progressi, individuare i rischi e dare seguito alle azioni, prima ancora di capire dove fosse effettivamente necessaria la loro attenzione. Il lavoro di leadership iniziava con la contabilità, e questa contabilità consumava il tempo che avrebbe dovuto essere impiegato per il coaching, la correzione e decisioni migliori.

Ecco come si manifesta spesso una governance debole nella pratica. Non si tratta sempre di una politica mancante, di un comitato inesistente o di un percorso di escalation assente. A volte la politica esiste, il processo esiste e le aspettative di reporting esistono, ma la governance dipende ancora da sforzi manuali, dati frammentati, visibilità ritardata e leader che devono ricostruire la verità prima di poter agire di conseguenza. Il risultato è un sistema in cui la governance è presente a parole ma fragile nell'attuazione. Tutti sanno pronunciare le parole giuste in materia di responsabilità, ma le persone più vicine al lavoro impiegano ancora troppo tempo a cercare di capire cosa sta succedendo.

In un caso, la sostituzione del monitoraggio manuale con un sistema di governance automatizzato ha permesso a 40 leader in prima linea di risparmiare circa un'ora al giorno. Non si è trattato solo di un miglioramento della produttività, ma ha anche cambiato la natura del lavoro di leadership, trasformando i leader da semplici raccoglitori di dati a coach. Potevano dedicare meno tempo alla raccolta di informazioni e più tempo ad aiutare i team ad agire in base al significato di tali informazioni. Il valore aggiunto non risiedeva semplicemente nell'esistenza di una dashboard, ma nel fatto che la governance si avvicinava al lavoro, era più facile da gestire e più utile per le decisioni quotidiane.

Questo è il punto che molte discussioni sulla governance dell'IA continuano a trascurare. Spesso si parla di governance come se la sfida principale fosse quella di redigere la politica giusta, approvare gli strumenti giusti, definire i principi giusti e creare il comitato di revisione giusto. Questi aspetti sono importanti, ma non sono sufficienti quando l'IA inizia a integrarsi direttamente nel flusso di lavoro. L'IA non è più solo qualcosa a cui i dipendenti chiedono aiuto dall'esterno. Sta iniziando a redigere, riassumere, classificare, instradare, dare priorità, raccomandare, convalidare, attivare e agire all'interno dei processi aziendali. Più l'IA si insinua nel flusso di lavoro, meno utile diventa governarla solo attraverso principi di alto livello e protocolli di approvazione.

Politiche, principi, valutazioni dei rischi, controlli di sicurezza, standard di privacy, verifiche degli appalti e requisiti di conformità hanno tutti la loro utilità. Il punto non è se siano necessari, ma se siano sufficientemente integrati nel lavoro per controllare ciò che effettivamente accade. Una politica può stabilire che la responsabilità rimanga in capo agli esseri umani, ma il flusso di lavoro deve comunque indicare a chi spetta tale responsabilità. Una politica può stabilire che gli output dell'IA debbano essere esaminati, ma il processo deve comunque definire chi li esamina, in base a quale standard, con quale autorità e cosa accade se l'output è errato. Una politica può stabilire che i dati sensibili debbano essere protetti, ma il modello operativo deve comunque definire quali dati vengono utilizzati, dove fluiscono, chi può visualizzarli e quali prove vengono conservate.

È qui che la governance diventa reale o di facciata. La governance di facciata offre all'organizzazione una sorta di rassicurazione dall'alto, perché prevede un quadro di riferimento, un comitato, un elenco di strumenti approvati, una diapositiva sull'IA responsabile, un modulo di formazione e una pagina con le politiche. Tutto ciò può essere utile, ma nulla dimostra che l'IA sia effettivamente governata dove il lavoro si svolge realmente. La governance reale si manifesta all'interno del flusso di lavoro. Indica chi è responsabile del risultato, dove si colloca il punto di giudizio umano, quali eccezioni devono essere segnalate, quali prove vengono raccolte, quando il sistema è autorizzato a procedere, quando deve fermarsi e come le correzioni vengono utilizzate per migliorare il lavoro.

Il vecchio modello di governance è spesso troppo distante dalla pratica. Presuppone che, se le regole sono definite e lo strumento è approvato, l'organizzazione sia governata. Questo può essere sufficiente per casi d'uso semplici, ma si rivela inadeguato quando l'intelligenza artificiale inizia a influenzare i processi operativi. Redigere una nota interna a basso rischio rappresenta un certo livello di rischio. Classificare un caso cliente, estrarre i dati di un ordine, gestire un'eccezione finanziaria, aggiornare un record o attivare una fase del flusso di lavoro sono attività ben diverse. Più l'intelligenza artificiale influenza il flusso di lavoro, più la governance deve passare dalla mera dichiarazione all'implementazione a livello di sistema.

Non si tratta di una preoccupazione teorica. Le organizzazioni hanno già imparato questa lezione nelle trasformazioni non basate sull'IA. Quando la governance si basa sulla raccolta manuale di informazioni, sul monitoraggio degli aggiornamenti, sul confronto dei file e sulla preparazione di report da parte di persone, i leader non dispongono di un ambiente di controllo in tempo reale. Ottengono una versione ritardata della realtà. Nel momento in cui un problema diventa evidente, il lavoro potrebbe essere già stato spostato, l'eccezione potrebbe essere già stata segnalata e il team potrebbe aver già trovato una soluzione alternativa. Questo tipo di governance è meglio di niente, ma non è sufficiente per il lavoro abilitato dall'IA.

L'intelligenza artificiale alza gli standard perché la velocità aumenta il costo di un controllo inadeguato. Un processo manuale lento con una governance debole è inefficiente. Un processo veloce basato sull'IA con una governance debole può diventare pericoloso perché può indirizzare il lavoro sbagliato più rapidamente, produrre risultati incompleti più rapidamente, generare confusione più rapidamente e creare correzioni a valle prima che qualcuno si accorga chiaramente dello schema. Il problema non è che l'IA si muova velocemente. Il problema è che molti modelli di governance sono stati creati per processi più lenti, dove il ritardo dava alle persone il tempo di accorgersi, intervenire e compensare manualmente.

I leader devono quindi smettere di chiedersi solo se un caso d'uso dell'IA sia stato approvato. Devono chiedersi come tale caso d'uso venga gestito durante il suo svolgimento. In quale punto del processo lavorativo interviene l'IA? Cosa influenza? Redige, raccomanda, classifica, instrada, aggiorna o esegue? Qual è il livello di revisione umana previsto? Questa revisione è significativa o si limita a una mera formalità? Cosa succede quando il livello di fiducia è basso? Quali eccezioni sono note? Quali vengono ancora gestite a memoria? Chi ha accesso alle prove? Chi può intervenire sul sistema? Chi è responsabile della correzione?

Queste domande non sono burocrazia. Rappresentano la disciplina minima richiesta quando un sistema inizia a influenzare il lavoro. L'espressione "human-in-the-loop" (coinvolgimento umano nel processo) è un buon esempio di linguaggio che può apparire responsabile pur nascondendo una progettazione debole. Molte organizzazioni usano questa frase come se risolvesse il rischio. Non è così. Le vere domande sono: chi è coinvolto nel processo, in quale fase, con quale competenza, cosa sta esaminando esattamente, in base a quale standard, con quanto tempo e con quale autorità può interrompere il flusso di lavoro? Senza queste risposte, "human-in-the-loop" diventa una frase che trasferisce la responsabilità a una persona senza attribuirle un ruolo di controllo effettivo.

Lo stesso vale per la revisione. La revisione non è governance se chi la effettua non ha il contesto necessario. La revisione non è governance se la persona si limita a controllare lo stile mentre il rischio risiede nella logica decisionale. La revisione non è governance se chi la effettua è sotto pressione per approvare rapidamente perché la coda di lavoro è lunga. La revisione non è governance se la correzione non viene mai registrata e il sistema non impara mai. La revisione diventa governance solo quando ha uno scopo, una tempistica, l'autorità, le prove e un ciclo di feedback.

Ecco perché l'esempio di leader che passano dal ruolo di semplici contabili a quello di coach è significativo. Il miglioramento non si è limitato a una maggiore facilità di visualizzazione delle informazioni, ma ha trasformato la governance in un processo operativo. I leader non sono più costretti a ricostruire manualmente il quadro operativo, ma possono utilizzarlo per intervenire, fornire coaching, correggere e guidare. La governance è diventata parte integrante della gestione del lavoro, non un rituale di reporting separato a posteriori. Anche la governance dell'IA necessita di questo cambiamento, perché non può rimanere un livello di reporting a posteriori. Deve diventare parte integrante del processo di selezione, progettazione, rilascio, monitoraggio, correzione e miglioramento del lavoro.

Il livello delle policy solitamente risponde a domande di carattere generale. Cosa è consentito? Cosa è proibito? Quali strumenti sono approvati? Quali dati sono sensibili? Quali sono i livelli di rischio? Chi deve esaminare i casi d'uso ad alto rischio? Queste domande sono necessarie, ma non rispondono ai quesiti operativi che determinano l'efficacia della governance. Cosa succede quando l'output dell'IA è errato? Come viene rilevata un'eccezione ricorrente? Come vengono tracciate le modifiche? Come fa il flusso di lavoro a sapere quando fermarsi? Come fa il responsabile a individuare i modelli di correzione? Come fa l'organizzazione a sapere se il rischio sta diminuendo o se si sta semplicemente spostando verso una revisione manuale?

Il divario tra questi due livelli è il punto in cui la governance dell'IA spesso fallisce. Fallisce quando la politica stabilisce che la responsabilità è degli esseri umani, ma i manager non riescono a capire come l'IA abbia influenzato il lavoro. Fallisce quando la politica prevede che gli output debbano essere validati, ma ai dipendenti non vengono forniti il tempo, gli standard o l'autorità necessari per una validazione adeguata. Fallisce quando la politica prevede che i dati debbano essere protetti, ma il flusso di lavoro attinge informazioni da fonti sparse che nessuno gestisce in modo coerente. Fallisce quando il comitato approva un caso d'uso, ma nessuno si assume la responsabilità delle eccezioni dopo l'implementazione.

Ecco perché la governance dell'IA deve seguire il lavoro. Se il lavoro coinvolge più funzioni, anche la governance deve farlo. Se il lavoro include eccezioni specifiche per il cliente, la governance deve includere la logica delle eccezioni. Se il lavoro dipende dal giudizio umano, la governance deve indicare dove il giudizio rimane umano. Se il lavoro ha un impatto su clienti, dipendenti, risultati finanziari, responsabilità legali o obblighi normativi, la governance deve essere sufficientemente solida da tracciare tali conseguenze dall'input al risultato.

Un flusso di lavoro non è governato in modo uniforme perché molte funzioni hanno esaminato solo una parte di esso. L'ufficio legale potrebbe esaminare le policy, l'ufficio sicurezza potrebbe esaminare gli accessi, l'ufficio tecnologico potrebbe esaminare l'architettura, l'ufficio acquisti potrebbe esaminare il fornitore, l'ufficio commerciale potrebbe approvare il caso d'uso, l'ufficio gestione rischi potrebbe esaminare il linguaggio di controllo. Tutto ciò può accadere, eppure il flusso di lavoro può risultare debole se nessuno è responsabile dell'intero percorso, dall'input al risultato. La vera prova consiste nel capire se l'organizzazione è in grado di spiegare come si svolge il lavoro, dove l'IA lo influenza, dove interviene l'intervento umano, dove vengono gestite le eccezioni, quali prove vengono conservate e come il sistema migliora quando qualcosa va storto.

Le eccezioni sono il punto in cui questo diventa evidente. Il percorso ideale è facile da gestire sulla carta perché l'input è pulito, la regola è chiara, il cliente rientra nel caso standard, il sistema si comporta come previsto e il revisore sa cosa controllare. Il lavoro aziendale reale, tuttavia, non si limita al percorso ideale. Un cliente ha una clausola contrattuale di deroga. Una regione ha requisiti diversi. Manca un campo nel sistema. Un'approvazione precedente ha creato un percorso di gestione speciale. Un caso sembra normale finché un dettaglio non cambia tutto. Se le eccezioni rimangono solo nella mente delle persone, la governance dell'IA sarà debole perché il modello potrebbe gestire il percorso standard fallendo laddove normalmente intervengono dipendenti esperti.

Non si tratta solo di una questione di rischio, ma anche di valore. Le eccezioni non gestite creano rilavorazioni, ritardi, incoerenze, escalation e sfiducia. Inoltre, indeboliscono l'economia dell'IA perché l'organizzazione inizia a sostenere costi nascosti per le correzioni umane. Se gli output dell'IA richiedono una revisione costante perché il flusso di lavoro non comprende le eccezioni, il business case risulta sovrastimato. Lo strumento può sembrare efficiente, ma il lavoro rimane costoso perché la mancanza di governance viene pagata con il tempo delle persone.

La tracciabilità è un altro ambito in cui la governance deve andare oltre le semplici politiche. Se l'IA influenza un flusso di lavoro, l'organizzazione deve sapere cosa è successo. Quali input sono stati utilizzati? Quali output sono stati generati? Quale sistema o modello li ha prodotti? Quale persona li ha esaminati? L'output è stato accettato, modificato, inoltrato o rifiutato? Quale eccezione si è verificata? Quale decisione è seguita? Cosa è successo a valle? Questo non significa raccogliere tutto all'infinito. Significa conservare le prove appropriate per il livello di rischio del lavoro, perché senza tracciabilità, la governance si basa sulla fiducia fondata sulle intenzioni, e le intenzioni non sono sufficienti per l'IA aziendale.

C'è anche un problema di fiducia dei dipendenti che non può essere ignorato. Man mano che le organizzazioni cercano di gestire l'IA più vicino al lavoro, raccoglieranno più segnali su flussi di lavoro, correzioni, eccezioni e comportamento del sistema. Questo può essere utile, ma può anche diventare pericoloso se l'organizzazione confonde il confine tra visibilità del lavoro e sorveglianza dei dipendenti. Comprendere il lavoro non è la stessa cosa che classificare le persone. Rilevare gli attriti non è la stessa cosa che monitorare il valore. Misurare le correzioni non è la stessa cosa che incolpare i dipendenti per aver protetto il flusso di lavoro. Se i dipendenti credono che la governance dell'IA venga utilizzata per valutarli segretamente, nasconderanno le correzioni, eviteranno di registrare i problemi e creeranno soluzioni alternative informali. L'organizzazione perderà le prove necessarie per migliorare.

La governance deve tutelare la fiducia e al contempo controllare il rischio. Ciò significa essere chiari su cosa viene raccolto, perché viene raccolto, chi può visualizzarlo, come viene utilizzato, cosa viene escluso e per quanto tempo viene conservato. Significa anche assicurarsi che le prove relative ai flussi di lavoro vengano utilizzate per migliorare il sistema, non per punire chi lo gestisce. Questa distinzione è importante ovunque, ma diventa ancora più cruciale nelle organizzazioni globali, dove normative, aspettative dei dipendenti, strutture sindacali, lingua, impegni con i clienti, maturità dei sistemi e prassi locali variano.

La soluzione non è permettere a ogni regione di creare un proprio modello di governance dell'IA, perché ciò genera frammentazione. La soluzione risiede in standard comuni supportati da dati locali: regole condivise per la responsabilità, la privacy, la tracciabilità, la gestione delle criticità e la misurazione del valore, unite alla visibilità locale su come il lavoro si svolge effettivamente, quali eccezioni sono rilevanti e dove il giudizio umano non può essere eliminato in sicurezza. Uno standard di governance centrale è necessario, ma deve essere basato sulla realtà operativa locale. Altrimenti, il centro crede di avere il controllo mentre le eccezioni rimangono in mano alla periferia.

È qui che un linguaggio operativo standardizzato diventa importante. In un altro caso, la standardizzazione dei dati, del linguaggio del flusso di lavoro e della governance a livello operativo ha contribuito a creare un ritmo operativo unico anziché molteplici interpretazioni locali. Questo tipo di standardizzazione non è puramente estetica. Fornisce alla governance un punto di riferimento solido. Se ogni team utilizza definizioni, segnali e logiche di eccezione diversi, la governance dell'IA diventa molto più complessa. Prima che l'IA possa essere governata efficacemente, il lavoro deve diventare sufficientemente leggibile da consentirne la governance.

In questo contesto, la leggibilità è un requisito fondamentale. Un flusso di lavoro è leggibile quando è possibile comprenderne il funzionamento, le dipendenze, i punti critici, la responsabilità, le eccezioni e i criteri di misurazione del valore. Senza questi elementi, la governance dell'IA si riduce a un insieme di intenzioni che fluttuano al di sopra di un lavoro poco chiaro. La mentalità da architetto si rifiuta di considerare la governance come un mero esercizio burocratico. L'operatore operativo continua a inseguire aggiornamenti, risolvere problemi e correggere gli output affinché il sistema continui a funzionare. L'architetto, invece, si chiede perché la governance dipenda così tanto da interventi manuali, perché i leader debbano ricostruire la verità ogni giorno, perché le eccezioni siano ancora informali, perché la revisione non sia stata pianificata e perché la politica affermi una cosa mentre il flusso di lavoro si comporta in modo diverso.

L'obiettivo non è rallentare l'IA, bensì evitare una falsa velocità. Per falsa velocità si intende quando un'organizzazione implementa rapidamente le soluzioni e impiega mesi a colmare lacune che avrebbero dovuto essere individuate in fase di progettazione. La vera velocità si raggiunge quando il flusso di lavoro è sufficientemente chiaro, ben governato e misurabile da consentire la scalabilità senza generare rilavorazioni inutili. Una governance debole rallenta l'organizzazione in un secondo momento, perché errori, sfiducia, rilavorazioni e rischi normativi impongono correzioni a posteriori. Una governance solida può sembrare più lenta all'inizio, ma crea condizioni migliori per la scalabilità.

I leader dovrebbero quindi porsi domande più precise prima di approvare, implementare su larga scala o celebrare l'intelligenza artificiale. Dove esattamente l'IA si inserisce nel flusso di lavoro? Cosa influenza? Chi è responsabile del risultato? Quali decisioni rimangono di competenza umana? Quali prove vengono conservate? Quali eccezioni sono state identificate? Cosa succede quando l'output dell'IA è errato? Come viene gestita la correzione? Come possiamo sapere se il flusso di lavoro è più sicuro, più veloce o più affidabile dopo l'introduzione dell'IA? Queste domande non bloccano l'IA, bensì la rendono più scalabile.

Il futuro della governance dell'IA non sarà definito unicamente da una migliore formulazione delle politiche. Sarà definito dalla capacità delle organizzazioni di collegare le politiche al lavoro. Ciò significa responsabilità a livello di flusso di lavoro, revisione umana strutturata, tracciabilità, gestione delle eccezioni, disciplina nell'escalation, protezione della privacy, cicli di correzione e misurazione del valore. Significa anche rendere la governance utile per le persone che guidano il lavoro ogni giorno, e non solo rassicurante per coloro che approvano il programma a distanza.

I leader che sono passati dal ruolo di semplici contabili a quello di coach non sono diventati leader migliori solo perché esisteva un report. Sono diventati più preparati perché la governance è diventata utilizzabile. Potevano visualizzare il lavoro, capire dove era necessario intervenire e agire con più tempo e chiarezza. Questo è lo stesso standard che la governance dell'IA deve soddisfare. Se la governance non aiuta l'organizzazione a vedere, decidere, correggere e migliorare, non è abbastanza solida per la prossima fase dell'IA.

La governance dell'IA non può rimanere confinata al livello delle politiche, perché l'IA non è più estranea al lavoro. Sta entrando a far parte del flusso di decisioni, azioni, eccezioni e responsabilità. I principi contano ancora. Le politiche contano ancora. I comitati contano ancora. Gli aspetti legali, di rischio, di sicurezza e di conformità contano ancora. Ma non sono sufficienti se non si connettono alla realtà operativa. Un'IA responsabile diventa reale solo quando la governance è visibile nel flusso di lavoro stesso: chi è responsabile della decisione, quali prove esistono, dove vanno le eccezioni, come intervengono gli esseri umani, quali dati vengono protetti, quali controlli si applicano e come viene misurato il valore.

Domande e risposte

D: Perché la governance dell'IA a livello di politiche non è sufficiente?

A: La governance a livello di policy definisce principi, limiti e utilizzo accettabile. Non dimostra che l'IA sia controllata all'interno dei flussi di lavoro reali. Le organizzazioni necessitano di una governance a livello di flusso di lavoro che definisca la responsabilità, la revisione, la tracciabilità, l'escalation, la gestione delle eccezioni e la correzione.

D: Cosa si intende per governance dell'IA a livello di flusso di lavoro?

A: La governance a livello di flusso di lavoro significa che i controlli sono integrati nel modo in cui il lavoro si svolge effettivamente. Mostra dove l'IA entra nel processo, cosa influenza, chi esamina i risultati, quali prove vengono conservate, come vengono gestite le eccezioni e chi è responsabile del risultato.

D: Perché la governance dell'IA diventa più importante con gli agenti?

A: Gli agenti possono influenzare o innescare azioni, non solo generare contenuti. Ciò significa che gli errori possono influire su percorsi, record, risposte dei clienti, fasi del flusso di lavoro e decisioni successive. Maggiore è l'intervento dell'IA nel lavoro, maggiore è la necessità di una governance operativa.

D: È sufficiente l'intervento umano?

A: Non da solo. Il metodo "human-in-the-loop" funziona solo quando il ruolo umano è chiaramente definito. L'organizzazione deve stabilire chi esamina l'output, quando lo esamina, quale standard utilizza, quale autorità ha e cosa succede quando viene riscontrato un problema.

D: Come possono le organizzazioni evitare che la governance si trasformi in sorveglianza?

A: È necessario un confine chiaro tra la visibilità del flusso di lavoro e il monitoraggio dei dipendenti. La governance dovrebbe definire cosa viene registrato, perché viene registrato, chi può accedervi, come viene utilizzato, cosa viene escluso e in che modo i dati di correzione migliorano il sistema anziché punire le persone.

D: Quali domande dovrebbero porsi i leader prima di implementare l'IA su larga scala?

A: I leader dovrebbero chiedersi dove l'IA entra nel flusso di lavoro, cosa influenza, chi è responsabile del risultato, quali eccezioni si ripetono, come funziona la revisione umana, quali prove vengono conservate, come vengono registrate le correzioni e se il flusso di lavoro diventa più sicuro, più veloce o più affidabile.