Superare l’idea che «l’IA sia magia»: perché imparare come funzionano i modelli di IA deve diventare una priorità aziendale

Tra gli avvertimenti sui comportamenti fuori controllo degli agenti di IA, di recente uno sviluppatore ha lasciato carta bianca a un agente di programmazione su una macchina senza backup remoto. Ha eliminato 48.000 file in meno di due minuti.

Episodi come questo ricordano con forza che l’impiego di agenti di IA comporta dei rischi: non basta inserire un revisore umano in qualche punto di un processo complesso e presumere che sia sicuro. Alcuni processi non richiedono interventi, mentre altri necessitano di controlli molto più rigorosi. Correggere un refuso ed eliminare migliaia di file comportano chiaramente livelli di rischio diversi: la supervisione deve quindi essere commisurata a ciò che è davvero in gioco.

Le organizzazioni devono imparare a individuare meglio i momenti in cui il giudizio umano è davvero importante, soprattutto quando un’azione ha conseguenze rilevanti o è difficile da annullare. E quando gli agenti commettono errori, l’ambiente deve limitarne la portata.

L’IA non è deterministica: è probabilistica

Prima di tutto, è fondamentale che ogni dipendente coinvolto, direttamente o indirettamente, nello sviluppo software acquisisca una conoscenza di base del modo in cui i modelli di IA elaborano le informazioni. Non è un compito da poco: richiede un impegno concreto nella formazione dei team e, col tempo, dovrebbe diventare un obiettivo aziendale.

Quando si inizia a interagire con l’IA, per la prima volta sembra magia. Si digita una frase e, all’improvviso, ci si ritrova a conversare. Capire almeno a grandi linee come funzionano davvero i modelli e il loro addestramento è importante per definire le politiche aziendali in materia di IA, sicurezza e produttività. La rete neurale, la tokenizzazione e l’analisi statistica che avviene dietro le quinte, così come il modo in cui da essa si arriva ai risultati, rappresentano un’importante opportunità formativa per tutti i dipendenti dell’azienda.

I modelli linguistici di grandi dimensioni non produrranno mai risultati deterministici. I risultati sono probabilistici. Con i software tradizionali, quando si inserisce un dato, ci si può aspettare un certo risultato, per esempio A, B o C. Con l’IA, invece, si potrebbe ottenere F, una & oppure la descrizione di un gatto con gli occhiali da sole.

Quando un sistema è probabilistico, non lo si può testare nel modo consueto. Serve un metodo di verifica che consenta di adattarsi, ragionare, comprendere e recuperare rapidamente il contesto, così da individuare gli elementi probabilistici e riconoscere i problemi che potrebbero causare. A seconda delle dimensioni e del livello di rischio, questi test possono essere gestiti dall’IA oppure da una persona con le competenze necessarie. La supervisione umana è più utile soprattutto all’inizio, per definire il problema da risolvere, e poi alla fine, per esaminare i risultati.

Poiché sono i più vicini alle variabili e alle prassi abituali con cui l’IA interna delle loro organizzazioni elabora gli input per formulare risposte, gli sviluppatori possono contribuire in modo significativo a definire la formazione sull’IA all’interno delle aziende e a fare in modo che tutti comprendano la differenza tra determinismo e probabilismo nell’IA, e perché sia importante. L’obiettivo è superare l’idea che usare l’IA sia come affidarsi alla magia e accettare qualsiasi risultato. Le organizzazioni dovrebbero invece impegnarsi a demistificare i modelli che utilizzano e a illustrare quali siano, come vengono impiegati, quali problemi possano insorgere, come vengono verificati e quali risultati produca questo processo.

Le misure di sicurezza appartengono all’infrastruttura, non al modello

Una volta sfatato il «mito» della magia dell’IA e avviato un progetto basato sull’IA, è fondamentale predisporre una politica di audit trasparente per assicurarsi che tutto proceda secondo le attese. In questo modo, se il progetto produce risultati «negativi» o insoddisfacenti, la persona responsabile può verificare i passaggi svolti e impedire che il problema si ripresenti. L’approccio è utile anche quando i risultati superano le aspettative, perché quei passaggi possono essere replicati e condivisi con altri progetti o gruppi.

La sistematizzazione di questo processo è particolarmente importante nelle aziende più grandi, dove ogni team può contare su decine di sviluppatori e centinaia di persone possono intervenire sul codice nel corso della giornata. L’IA può svolgere molte attività molto rapidamente e, se qualcosa va storto, serve un sistema per stabilire con precisione in quale passaggio si è verificato il problema. Si pensi agli agenti di OpenAI che quest’estate hanno violato i sistemi di Hugging Face. OpenAI stava testando la capacità dei propri modelli di sfruttare le vulnerabilità del software, usando un benchmark chiamato ExploitGym. Per il test, aveva deliberatamente allentato i rifiuti dei modelli in relazione alle attività offensive in ambito informatico. L’unica via d’uscita dall’ambiente sandbox era un proxy dei pacchetti. I modelli hanno individuato una falla sconosciuta in quel proxy, sono riusciti a evadere e hanno trascorso più di due giorni nei sistemi di produzione di Hugging Face, alla ricerca delle risposte del test.

I titoli dei giornali l’hanno definita un’IA fuori controllo. Io la definirei una configurazione deterministica attorno a un sistema probabilistico. OpenAI ha detto ai modelli di violare i sistemi e poi ha fatto affidamento sul fatto che seguissero il percorso previsto. Secondo il creatore del benchmark, in passato i modelli avevano già imbrogliato durante il test, ma sempre all’interno della sandbox. Questa volta uno di loro ne è uscito. Le misure di sicurezza standard presuppongono comportamenti standard, ma l’IA non è tenuta a rispettarli.

Ecco perché la sicurezza dell’IA dipende dagli accessi e dai controlli, applicati dall’ambiente anziché affidarsi al buon comportamento del modello. Bisogna presumere che l’agente proverà ad aprire tutte le porte e lasciargli aperte solo quelle di cui ha bisogno. All’agente che ha eliminato 48.000 file era stato detto di lavorare sulle copie e di non toccare gli originali. Eppure ha eliminato gli originali. Le istruzioni non sono controlli.

Gestire le autorizzazioni di un agente è come accogliere un nuovo sviluppatore junior. Non gli daresti accesso root all’ambiente di produzione il primo giorno. Se lo facessi e lui eliminasse il tuo database, non diresti che è stato un hacker geniale. Negli incidenti di sicurezza, di qualsiasi entità, è fondamentale individuarne la causa principale. È il modello? È l’azienda che ha creato il modello? È l’azienda che gli ha dato accesso? Qualunque sia la causa, alla fine la responsabilità è di una persona.

Infine, un problema fondamentale da affrontare oggi è ciò che accade nell’ombra sul portatile di uno sviluppatore. In passato, era più semplice ricostruire il flusso di lavoro. Gli sviluppatori scrivevano il codice, lo esaminavano e lo distribuivano, quindi era possibile risalire con chiarezza al momento in cui qualcosa era andato storto. Oggi uno sviluppatore può aver fornito a un agente il ticket e avergli detto: «Risolvilo». Se il lavoro si svolge senza essere visibile, non c’è nulla da ricostruire. Ogni passaggio deve lasciare una traccia completa: quale agente è stato eseguito, quale modello ha utilizzato, quali prompt ha ricevuto, quali strumenti ha richiamato e quali autorizzazioni aveva in quel momento. Eseguire gli agenti centralmente, invece che sui singoli portatili, è un modo per riuscirci. L’importante è che la traccia esista.

In definitiva, in caso di incidente, ogni azienda deve tutelarsi. La traccia deve contenere informazioni sufficienti per svolgere un’analisi della causa principale e individuare il passaggio e il codice che hanno provocato il problema.

L’IA ha cambiato profondamente il mondo e i processi aziendali devono adeguarsi. Per individuare le misure di sicurezza adeguate, è necessario comprendere meglio i processi legati all’IA, i test, i cicli di revisione e quelli di audit, sia all’interno dei team di sviluppo sia a livello aziendale.