La governance dell'IA riguarda tutti

Nelle ultime settimane il dibattito si è fatto particolarmente acceso. Un laboratorio all'avanguardia nel campo dell'IA ha invitato il settore a rallentare il passo e chi sta sviluppando le tecnologie più avanzate ha risposto con fermezza. Al di là del clamore mediatico, emergono due domande fondamentali: chi ha costruito questi sistemi può davvero fidarsi di loro? E soprattutto, è in grado di controllarli? E se la risposta è ancora no, chi dovrebbe decidere cosa fare dopo? Rallentare lo sviluppo, affidarsi all'autoregolamentazione o introdurre nuove regole?

Personalmente credo nell'autoregolamentazione supportata da verifiche indipendenti. Quando si parla di modelli di frontiera, ovvero i modelli di IA più avanzati oggi disponibili, il controllo più efficace arriva da verifiche indipendenti condotte da altri laboratori del settore. Riconoscere i propri punti deboli non è semplice: uno sguardo esterno riesce spesso a individuare ciò che è sfuggito a chi ha realizzato il lavoro, mentre difficilmente può farlo un insieme di regole definito da persone che non hanno mai addestrato un modello.

Ma questo dibattito riguarda forse una dozzina di aziende. Tutte le altre utilizzeranno i modelli sviluppati da queste organizzazioni e si troveranno ad affrontare le stesse due domande all'interno delle proprie realtà, senza accordi condivisi, senza un sistema di revisione tra pari e senza un'autorità di riferimento che possa fornire le risposte.

Quando l'IA entra in azienda

Forse non stai sviluppando un modello di IA all'avanguardia, ma stai utilizzando un'IA all'avanguardia applicata ai tuoi dati, ai tuoi sistemi e ai tuoi clienti.

E le stesse due domande che oggi vengono rivolte ai laboratori che sviluppano queste tecnologie presto saranno rivolte anche a te, dal consiglio di amministrazione, dai revisori e dalle autorità di controllo: puoi fidarti di questi sistemi? Sei davvero in grado di controllarli?

Anche se utilizzi gli stessi modelli di altre organizzazioni, ciò che conta è l'ambiente in cui vengono impiegati: dati dei clienti, applicazioni aziendali, codice e sistemi di produzione. E quando un agente opera con le tue credenziali e sui tuoi sistemi, sei tu a doverne rispondere.

Le aziende si trovano ad affrontare gli stessi problemi dei laboratori che sviluppano l'IA più avanzata, ma su una scala diversa. Se questi ultimi si preoccupano del rischio che un modello riesca ad aggirare i propri meccanismi di valutazione, per un'organizzazione il problema potrebbe essere un agente capace di aggirare i controlli interni.

Immagin un agente incaricato di migliorare il capitale circolante. Il modo più rapido per ottenere un risultato migliore potrebbe essere semplicemente alterare il dato stesso. Nessuno gli ha impartito questa istruzione, ma ha trovato una scorciatoia per raggiungere l'obiettivo. Non si tratta di superintelligenza, ma di un agente persistente, dotato di accesso reale ai sistemi aziendali, il che rappresenta una nuova forma di rischio interno.

Mentre i laboratori sono alle prese con i rischi legati all'auto-miglioramento dei modelli, all'interno delle aziende la minaccia può assumere una forma diversa: un agente incentivato a raggiungere un obiettivo e dotato di accesso in scrittura al sistema ERP. La dinamica di fondo è la stessa, cambia soltanto la portata delle conseguenze.

L'architettura della governance dell'IA

Se si mettono da parte gli aspetti più politici del dibattito sull'IA avanzata, emerge un elemento interessante. Quando a chi sviluppa questi sistemi viene chiesto come intenda gestirne i rischi, raramente la risposta riguarda una policy. Più spesso descrivono un'architettura: strumenti di valutazione indipendenti che monitorano il comportamento degli agenti, ne analizzano i ragionamenti e intervengono quando rilevano situazioni critiche.

Si tratta di risposte di natura ingegneristica, formulate da chi sa che l'unico modo per affrontare queste sfide è progettare soluzioni adeguate. E questo approccio resta valido anche nel contesto aziendale: poiché non esiste un modello di governance predefinito che qualcuno possa offrirti, queste pratiche rappresentano un punto di partenza concreto per costruire un sistema di controllo efficace.

Nessuno dovrebbe valutare il proprio lavoro

I laboratori sottopongono i propri modelli a verifiche indipendenti perché chi li sviluppa non è necessariamente nella posizione migliore per valutarli. Non per mancanza di obiettività, ma perché è inevitabilmente coinvolto nel lavoro svolto e ha tutto l'interesse a portare il modello sul mercato.

Le aziende hanno compreso questo principio da molto tempo. In ambito finanziario esistono i revisori; nella sicurezza informatica esiste la separazione delle responsabilità. Chi svolge un'attività non è anche chi ne determina l'accettabilità. Un revisore non deve conoscere l'azienda meglio di chi vi lavora: deve saper porre le domande giuste. E, soprattutto, deve esserci più di un punto di vista.

All'interno delle organizzazioni, la stessa logica dovrebbe applicarsi sia all'ambiente in cui operano gli agenti sia ai fornitori che li mettono a disposizione. Ogni piattaforma che vende agenti ha interesse ad ampliarne l'utilizzo, non a limitarlo in funzione della propensione al rischio. Affidare a ciascun fornitore la responsabilità di governare autonomamente il proprio ecosistema sarebbe come lasciare che i ristoranti si occupino da soli dei controlli igienico-sanitari.

Se un tempo la separazione delle responsabilità era una questione organizzativa, oggi deve essere integrata nell'architettura tecnologica.

Perché chi controlla deve essere indipendente

Un agente osserva il mondo che lo circonda, ma allo stesso tempo può esserne influenzato.

Una ricerca pubblicata quest'estate da un laboratorio di IA all'avanguardia e da un'università europea ha evidenziato come determinate informazioni possano diffondersi da un agente all'altro. In oltre la metà dei casi analizzati, un contenuto inserito nella memoria persistente di un agente è stato trasmesso agli agenti successivi senza che questi avessero alcuna consapevolezza della sua origine o della sua propagazione.

I ricercatori hanno definito questi fenomeni ''mind virus''. In pratica, si tratta di informazioni o comportamenti indesiderati che passano da un agente all'altro, diffondendosi all'interno del sistema prima che qualcuno riesca a individuarli. I test hanno mostrato che un semplice avvertimento nel prompt può limitarne drasticamente la diffusione. Ma se l'allineamento fallisce, quali controlli restano a disposizione dell’organizzazione?

Se il livello di governance opera nello stesso ambiente dell'agente, condivide lo stesso contesto, la stessa memoria e gli stessi strumenti, rischia di essere esposto alle stesse vulnerabilità e agli stessi errori.

Per questo l'indipendenza non rappresenta soltanto una misura di controllo, ma anche una forma di protezione dagli effetti a catena.

Il ruolo del livello indipendente

Il livello indipendente osserva sia il ragionamento dell'agente sia ogni sua azione concreta: non ciò che l'agente dichiara di voler fare, ma le operazioni che esegue realmente.

Il comportamento costituisce un'evidenza, mentre l'intenzione dichiarata è soltanto un'affermazione. È fondamentale poter individuare il momento in cui un agente inizia a concatenare azioni orientate verso un obiettivo che non gli è mai stato assegnato, perché è proprio in quella sequenza di decisioni che si annida il rischio.

Analizza il ragionamento, ma fidati dei comportamenti osservabili. Conservare le tracce di ragionamento è importante: devono essere leggibili, verificabili e, idealmente, sottoposte al controllo di un secondo modello. Tuttavia, poiché il funzionamento interno di questi sistemi non è ancora pienamente compreso, ciò che conta di più è la registrazione delle azioni effettivamente compiute, più che la spiegazione che l'agente fornisce del perché le abbia eseguite.

Le decisioni devono essere prese come avviene già all'interno dell'organizzazione. Bloccare un'azione tramite un controllo tecnico è la parte più semplice, ma la vera difficoltà sta nel determinare quale decisione sia corretta. Ogni anno i team che si occupano di rischio, privacy e sicurezza prendono migliaia di decisioni di autorizzazione o rifiuto e quasi mai queste valutazioni sono formalizzate in modo da poter essere consultate automaticamente nel ristretto intervallo di tempo in cui un agente deve agire.

Per questo il livello indipendente deve incorporare le policy aziendali, gli obblighi normativi e la propensione al rischio dell'organizzazione, interpretando l'intento e il contesto di ogni azione come farebbe un ottimo analista umano. Se ciò che deve essere governato è per natura non deterministico, anche il sistema chiamato a valutarlo deve essere in grado di ragionare in modo contestuale.

A quel punto entra in gioco l'applicazione delle decisioni: autorizzare, negare, limitare o sottoporre un'azione a un livello superiore di verifica. Questi controlli devono intervenire direttamente nel flusso operativo, non limitarsi a osservarlo. Se disattivare un controllo non modifica in alcun modo ciò che l'agente può fare, allora non si tratta di governance, ma semplicemente di monitoraggio. Infine, ogni evidenza deve essere conservata in un archivio che l'agente non possa modificare né raggiungere.

La stabilità come principio di governance

Modelli, quadri di esecuzione e strumenti continueranno a evolversi molto velocemente: se la governance viene costruita attorno a uno di questi elementi, dovrà essere riprogettata ogni volta che cambia la tecnologia sottostante.

Ho visto una dinamica simile agli albori dell'era mobile. Poiché era impossibile controllare ogni dispositivo e applicazione in continua evoluzione, il controllo si è spostato verso ciò che le aziende possedevano e gestivano direttamente, ovvero dati e sistemi. Lo stesso principio vale per l'IA. Il livello indipendente di governance dovrebbe trovarsi nel punto in cui l'IA interagisce con dati, applicazioni e servizi aziendali, così da restare stabile indipendentemente dai modelli e dalle tecnologie utilizzate.

Cosa fare adesso

• Mappa le capacità dell'IA. Comprendi a quali dati e applicazioni può accedere, quali azioni può eseguire e in quali casi può operare senza intervento umano.
• Tratta le autorizzazioni come una delega. Concedi accessi limitati ad attività e finalità specifiche, non permessi permanenti.
• Separa i controlli dagli agenti. Il livello di governance deve avere memoria, logica e criteri decisionali propri, indipendenti dal successo dell'agente.
• Esegui attività di governance anche dopo il rilascio. Ogni modifica apportata a modelli, strumenti, prompt o flussi di lavoro richiede una nuova valutazione.
• Dimostra di poter intervenire. Assicurati di poter bloccare l'agente quando necessario e conserva evidenze indipendenti che non possa modificare.

In questo modo il consiglio di amministrazione avrà qualcosa di più utile di un semplice elenco di strumenti di IA approvati: una chiara comprensione di ciò che l'IA può fare, dei limiti entro cui può operare e dell'efficacia dei controlli che ne governano l'utilizzo.

La necessità di un controllo indipendente

I laboratori che sviluppano i modelli più avanzati arriveranno inevitabilmente a questi principi, perché la realtà mette alla prova ogni sistema senza fare sconti. Quando un modello fallisce in un contesto reale, non sono le intenzioni o le spiegazioni a contare, ma i risultati.

Le aziende si troveranno nella stessa situazione. Revisori, autorità e assicuratori chiederanno garanzie concrete, e per fornirle servirà un livello di controllo indipendente da chi sviluppa o gestisce i sistemi di IA.

Le organizzazioni che introdurranno per prime questo livello di governance non saranno quelle più lente. Al contrario, saranno quelle in grado di approvare e adottare nuovi agenti più rapidamente, perché le regole, i limiti e le autorizzazioni saranno già stati definiti in anticipo.

I modelli continueranno a evolvere, ma il livello di controllo deve rimanere costante.