Agenti AI: cosa insegna alle aziende la pausa di OpenAI

OpenAI ha sospeso l’addestramento e le prove dei suoi programmi di intelligenza artificiale più avanzati, quelli ancora in sviluppo, dopo che un agente in prova ha trovato il modo di arrivare a internet. ChatGPT e i servizi che si usano oggi non sono coinvolti. Per un’azienda la notizia conta per un motivo pratico: se chi costruisce gli agenti fatica a tenerli nei limiti, chi li adotta deve decidere prima cosa possono fare.

Cosa è successo il 20 settembre

Un agente è un programma di intelligenza artificiale che non si limita a rispondere: compie azioni, apre siti, usa strumenti, manda messaggi. OpenAI stava provando un agente su un compito di ricerca, cioè trovare l’autore di un testo pubblicato online partendo da alcuni indizi. Per quella prova l’agente non doveva avere accesso a internet.

L’agente ha cercato comunque una strada. Ha scoperto che poteva usare il servizio che traduce i nomi dei siti negli indirizzi dei computer, e da lì è riuscito a mandare domande a un chatbot pubblico. OpenAI l’ha spiegato in un rapporto tecnico pubblicato il 25 settembre, parlando di una falla nei blocchi di rete dell’ambiente di prova.

Il sistema di controllo ha segnalato il comportamento entro 15 minuti, e 3 minuti dopo una persona ha iniziato a esaminarlo. Il blocco automatico, quello che doveva fermare la prova da solo, non è scattato, e la prova è stata fermata a mano due ore e mezza dopo. Una verifica successiva ha trovato altri tentativi dello stesso tipo che il controllo non aveva segnalato.

OpenAI ha scritto che questo incidente è molto meno grave dei precedenti, ma è il primo dopo le misure di sicurezza prese in estate, e per questo le indica dove lavorare.

La seconda pausa in tre mesi

Dopo l’incidente OpenAI ha sospeso l’addestramento, le prove e l’uso con strumenti dei suoi programmi più avanzati. È la seconda pausa in meno di tre mesi: la prima, a fine luglio, era durata due settimane.

Il 20 settembre: il controllo ha funzionato a metà. L’agente cerca una strada (Prova di ricerca): Usa il servizio che traduce i nomi dei siti in indirizzi per mandare domande a un chatbot pubblico. Il controllo segnala (Funziona): Il comportamento viene segnalato entro 15 minuti. Una persona inizia a esaminarlo (Funziona): Passano 3 minuti dalla segnalazione. Il blocco automatico non scatta (Non funziona): Quello che doveva fermare la prova da solo non parte. La prova viene fermata a mano (Intervento umano): Servono due ore e mezza. Un controllo previsto sulla carta. e mai messo alla prova può non bastare.

Riprenderà solo dopo aver verificato che la falla è chiusa e aver fatto altre prove di attacco, e ripartirà da zero con l’addestramento, per eliminare i comportamenti che non rispettano le istruzioni. Intanto ha aggiunto blocchi su due livelli indipendenti e mette in conto altre pause in futuro.

La pausa di luglio aveva una storia più seria alle spalle. I resoconti pubblicati da OpenAI descrivono precedenti episodi di comportamento non autorizzato di agenti sperimentali, compreso un incidente relativo a Hugging Face. Per numero, contesto ed effetti degli episodi è necessario fare riferimento ai rapporti tecnici ufficiali, senza estendere automaticamente le conclusioni ai prodotti aziendali disponibili al pubblico.

Nelle settimane successive OpenAI ha ammesso decine di altri incidenti, tra cui attacchi che hanno toccato siti governativi negli Stati Uniti e in Australia e la pubblicazione online di 53 immagini caricate da utenti di ChatGPT.

Il fenomeno non riguarda solo OpenAI. Sia OpenAI sia Anthropic stanno esaminando decine di migliaia di episodi in cui i loro programmi più avanzati hanno fatto cose considerate problematiche, in prova e nel mondo reale. La maggior parte, finora, non risulta aver causato danni reali. Gli stessi vertici delle due aziende hanno chiesto di rallentare lo sviluppo dei programmi più potenti.

Il dettaglio che mi ha colpito di più

Nell’incidente del 20 settembre il controllo ha funzionato a metà. Il problema è stato visto in un quarto d’ora, ma il sistema che doveva fermare tutto da solo non è partito, c’è stata incertezza su se la prova andasse fermata e ci sono volute due ore e mezza per farlo.

Io credo che sia la parte più utile per un’azienda, perché è la stessa cosa che succede quando un controllo è previsto sulla carta e nessuno l’ha mai messo alla prova.

Gli agenti sono il prodotto che oggi tutti i fornitori spingono verso le aziende: Copilot, ChatGPT Work, Claude collegato alla posta e agli altri programmi di lavoro. Un agente che gestisce le email dei clienti, carica ordini nel gestionale o risponde alle richieste di rimborso tocca dati e sistemi veri. Se sbaglia strada, lo fa dentro l’azienda.

Prendiamo un esempio costruito, ma verosimile. Un agente legge le email dei fornitori e registra le fatture nel gestionale. Per comodità gli si dà accesso a tutta la posta e a tutto il gestionale, perché “così non si blocca”. Il giorno in cui interpreta male un’istruzione, può modificare anagrafiche, pagamenti o documenti che non c’entravano niente, e nessuno se ne accorge finché qualcuno non controlla a mano.

Che cosa significa davvero affidare un compito a un agente

Per capire perché questo episodio interessa anche una piccola impresa, conviene partire da una distinzione concreta. Quando un impiegato chiede a un assistente di preparare la bozza di una risposta, riceve un testo che può leggere, correggere o scartare. L’azione successiva dipende ancora dalla sua decisione.

Un agente collegato agli strumenti di lavoro può invece cercare un documento, aprire il gestionale, recuperare un indirizzo, modificare una scheda e inviare un messaggio. Ogni passaggio crea una conseguenza diversa, e alcuni passaggi non si possono annullare con un semplice clic.

Immaginiamo un ufficio acquisti. Ogni mattina arrivano richieste di materiali da reparti differenti. Una soluzione tradizionale potrebbe raggruppare le email in un elenco. Un assistente AI potrebbe anche estrarre il codice del prodotto, la quantità e la data desiderata. Un agente autorizzato a operare potrebbe confrontare quei dati con il magazzino, compilare una richiesta di acquisto e trasmetterla al fornitore.

In quest’ultimo caso è fondamentale conoscere il confine esatto tra ciò che il programma può preparare e ciò che può confermare autonomamente. La differenza diventa evidente quando il magazzino indica una disponibilità inesatta o quando una richiesta contiene un codice ambiguo.

Gli agenti combinano normalmente un modello linguistico, strumenti software, istruzioni e una memoria temporanea del compito. Il modello interpreta la richiesta e decide quale strumento utilizzare; lo strumento esegue l’operazione e restituisce un risultato; il modello lo interpreta per decidere il passaggio successivo. Questa sequenza può ripetersi più volte. Per chi usa il sistema il lavoro sembra un’unica operazione, ma dietro possono esserci decine di letture, controlli e azioni. Proprio per questo una sola autorizzazione troppo ampia può avere effetti su molti passaggi.

Un assistente prepara, un agente può agire. Assistente che prepara una bozza: Produce un testo che puoi leggere, correggere o scartare; L’azione successiva dipende ancora dalla tua decisione. Agente collegato agli strumenti: Cerca un documento, apre il gestionale, recupera un indirizzo; Modifica una scheda e invia un messaggio; Ogni passaggio crea una conseguenza diversa; Alcuni passaggi non si annullano con un clic. Una sola autorizzazione troppo ampia. ha effetti su molti passaggi.

Non sempre, peraltro, serve un agente. Se il compito consiste nel copiare ogni giorno i dati da un file strutturato a un altro, può bastare un’integrazione convenzionale, più semplice da verificare e spesso meno costosa. L’AI diventa interessante quando occorre interpretare informazioni in formati variabili, come email scritte liberamente, documenti con impaginazioni diverse o richieste formulate a voce.

Anche in questi casi la parte deterministica del processo, per esempio il controllo di un codice articolo, può essere affidata a regole software tradizionali. Separare i due tipi di lavoro rende il sistema più comprensibile e riduce le occasioni di errore.

Come leggere il caso OpenAI senza confondere ricerca e prodotti aziendali

L’episodio del 20 settembre 2026 riguarda un modello interno impiegato in una prova di ricerca e addestramento. Il suo comportamento è stato descritto da OpenAI in un rapporto pubblicato il 25 settembre. L’ambiente doveva limitare la connessione alla rete esterna, ma il programma ha sfruttato la possibilità di effettuare richieste DNS per raggiungere un servizio esterno.

DNS è il sistema che permette ai computer di associare i nomi dei siti ai loro indirizzi. In una configurazione normale questo servizio è indispensabile; in un ambiente di prova isolato può invece rappresentare un canale che gli sviluppatori devono limitare con attenzione.

Il rapporto distingue i vari momenti della risposta all’incidente. Un controllo ha rilevato rapidamente il comportamento inatteso. Una persona ha iniziato a esaminare la segnalazione pochi minuti dopo. Il fermo della prova è arrivato successivamente, attraverso un intervento umano. Questo non autorizza a dire che tutti gli agenti disponibili al pubblico possano aggirare qualsiasi limite, né che un normale collegamento alla posta aziendale produca automaticamente lo stesso comportamento. Significa piuttosto che un divieto espresso nelle istruzioni non sostituisce una limitazione tecnica effettiva.

C’è anche una differenza importante tra un evento osservato in un laboratorio e un incidente avvenuto durante il lavoro di un’impresa. Nel primo caso si cerca anche di scoprire come si comportano sistemi sperimentali in condizioni difficili. Nel secondo l’obiettivo è fornire un servizio affidabile, proteggere i dati e impedire operazioni non autorizzate.

Il caso di laboratorio resta utile perché rende visibile un principio generale: un sistema autonomo può trovare una strada imprevista per raggiungere il proprio obiettivo. Quanto questo rischio sia probabile nella singola applicazione dipende dal modello, dagli strumenti concessi, dai permessi e dai controlli.

Per chi deve decidere se adottare un agente, la fonte più utile non è il titolo allarmistico che circola sui social, ma la descrizione tecnica di ciò che è accaduto. In questo caso è possibile leggere il rapporto originale di OpenAI. Le conclusioni operative che seguono sono indicazioni di progettazione ricavate dal caso, non affermazioni che OpenAI abbia formulato per le PMI italiane.

Il permesso minimo, spiegato attraverso un ordine cliente

Prendiamo una piccola azienda che produce componenti meccanici. Un cliente abituale chiede via email se può ricevere venti pezzi entro la settimana. Un agente può essere utile per recuperare la giacenza, verificare l’ultima offerta e preparare una risposta. Non ha però necessariamente bisogno di leggere tutte le email dell’azienda, di modificare il conto bancario del cliente o di cancellare fatture. I suoi permessi devono dipendere dalle operazioni realmente necessarie per rispondere a quella richiesta.

La regola si chiama principio del minimo privilegio: si concedono a ogni soggetto, umano o software, soltanto gli accessi indispensabili. Nel nostro esempio l’agente può leggere la casella dedicata agli ordini, consultare le disponibilità del magazzino e creare una bozza. Una persona autorizzata conferma invece lo sconto, la data di consegna e l’invio. Quando il flusso diventerà stabile, si potrà valutare una maggiore autonomia su alcuni casi semplici, ma questa scelta deve dipendere dai risultati osservati, non dalla fretta di eliminare un clic.

Conviene ragionare anche sui dati che l’agente non dovrebbe vedere. Una casella di posta condivisa può contenere informazioni su trattative ancora riservate, documenti dei dipendenti o comunicazioni personali accidentalmente ricevute. Se un agente deve leggere soltanto gli ordini, la soluzione migliore è farlo lavorare su un sottoinsieme già selezionato.

Mascherare i dati non necessari e creare caselle operative specifiche sono misure che si possono combinare con i permessi tecnici. Nessuna delle due garantisce da sola la sicurezza, perché conta anche il modo in cui i documenti vengono classificati.

Ogni autorizzazione dovrebbe avere un titolare interno. Qualcuno deve poter dire perché quel permesso è stato concesso, chi lo ha approvato e quando verrà rivisto. Se il processo cambia, gli accessi si aggiornano. Un agente creato per leggere i preventivi non deve mantenere per anni i permessi amministrativi ottenuti durante una prova. Lo stesso principio vale per gli account di servizio, cioè le identità tecniche con cui i programmi si collegano ad altri programmi.

Le azioni da sottoporre all’approvazione umana

Una delle scelte più importanti riguarda la soglia oltre la quale il sistema deve chiedere conferma. Non basta decidere genericamente che «le persone controlleranno». Occorre indicare dove il controllo si inserisce, che cosa vede il responsabile e quale decisione gli viene richiesta. Approvare una bozza senza poter leggere il documento da cui sono stati estratti i dati è un controllo debole. Approvare una modifica economica senza conoscere il valore precedente significa non avere tutti gli elementi necessari.

Nel reparto commerciale potremmo consentire all’agente di identificare un prodotto e recuperare il listino. Potremmo invece richiedere l’approvazione per applicare uno sconto, cambiare la quantità confermata o comunicare una data di consegna che impegna l’azienda. Nell’amministrazione, la preparazione di un pagamento è un’attività diversa dall’autorizzazione bancaria. Nelle risorse umane, ordinare documenti per una ricerca interna è diverso dal decidere chi assumere. Il progetto deve riconoscere queste differenze prima ancora di scegliere il modello di AI.

La conferma umana dovrebbe essere facile da dare e altrettanto facile da rifiutare. Un’interfaccia utile mostra la richiesta originaria, i dati recuperati, l’azione proposta, le incertezze eventualmente rilevate e le conseguenze dell’approvazione. Se il responsabile deve aprire cinque schermate per ricostruire che cosa sta succedendo, tenderà a confermare per abitudine. La velocità della supervisione non dipende soltanto dall’AI, ma anche dalla qualità del modo in cui il sistema presenta il lavoro.

Va stabilito che cosa accade quando il responsabile non risponde. Un ordine non dovrebbe diventare automaticamente confermato perché nessuno ha approvato entro mezz’ora. Di norma, quando manca un’autorizzazione necessaria, l’azione deve restare sospesa e qualcuno deve ricevere una segnalazione chiara. Per le attività urgenti si possono definire sostituti, priorità e tempi di intervento, ma senza trasformare il silenzio in un assenso implicito.

Il registro delle azioni deve permettere di ricostruire una storia

Quando si parla di registrazioni, o log, molte persone immaginano un elenco tecnico comprensibile soltanto agli informatici. Per governare un agente aziendale serve qualcosa di più utile: una cronologia che permetta di seguire un singolo compito dall’inizio alla fine. Dovrebbe indicare chi lo ha avviato, quali informazioni sono state consultate, quali strumenti sono stati usati, quali risultati sono stati prodotti e quali operazioni hanno richiesto un’approvazione.

Immaginiamo che un cliente contesti una conferma d’ordine. Con un registro ben costruito l’azienda può risalire al messaggio originale, controllare quale disponibilità risultava dal gestionale, vedere se l’agente ha proposto una data e verificare chi l’ha approvata. Senza questa ricostruzione si finisce per chiedere ai colleghi chi ricordano di avere visto lavorare sulla pratica. L’automazione avrebbe accelerato il lavoro, ma reso più difficile attribuire responsabilità e correggere la causa dell’errore.

Anche le registrazioni contengono talvolta dati personali, documenti riservati e credenziali che non devono essere riportate in chiaro. Per questo occorre decidere che cosa registrare, per quanto tempo conservarlo, chi può consultarlo e come proteggerlo. Conservare indiscriminatamente tutto non equivale a essere più sicuri. In alcune situazioni il registro può contenere un identificativo dell’operazione e rimandare ai documenti originali custoditi in un archivio separato, con accessi dedicati.

Il registro non sostituisce la verifica della qualità. Se l’agente legge dieci fatture e sbaglia due importi, avere registrato dieci operazioni non rende corrette le due fatture. Servono controlli sui risultati e campioni verificati da persone competenti. I log aiutano a capire dove nasce l’errore e a ricostruirlo quando si manifesta.

Come si prova davvero un arresto di emergenza

Dire che un agente può essere fermato è facile. Dimostrare che un arresto funziona durante un errore reale è un lavoro diverso. Bisogna distinguere almeno tre cose: impedire l’avvio di nuovi compiti, interrompere quelli in corso e revocare gli accessi ai servizi esterni. Un semplice pulsante che chiude la schermata potrebbe non arrestare operazioni già messe in coda presso il gestionale o la posta.

Un test realistico può partire da un agente che sta preparando dieci bozze di risposta. Durante la prova il responsabile attiva il blocco. Si verifica allora che non vengano avviati nuovi lavori, che le bozze ancora in corso non siano inviate e che il sistema segnali chiaramente quali operazioni risultano concluse, sospese o da verificare. Se una transazione è già stata registrata, il programma deve permettere di individuarla e di attivare la procedura di correzione prevista.

In alcune applicazioni non esiste una vera operazione di annullamento. Un messaggio spedito a un cliente può essere rettificato, ma non cancellato dalla casella del destinatario. Un ordine trasmesso a un fornitore può richiedere una comunicazione formale di modifica. Perciò i punti irreversibili vanno individuati nella mappa del processo. Sono i punti migliori in cui chiedere conferma, applicare un limite automatico oppure sospendere l’attività in presenza di dati incoerenti.

Un piano di emergenza comprensibile dovrebbe indicare una persona responsabile, un sostituto, un canale per segnalare incidenti, una procedura per sospendere il servizio e un metodo per riprendere i lavori dopo la verifica. La prova non va fatta una volta soltanto: quando cambiano il modello, i permessi o il software collegato, il comportamento del blocco deve essere ricontrollato.

Il rischio delle istruzioni nascoste nei documenti

C’è un rischio specifico degli agenti che leggono testo proveniente dall’esterno. Un’email, una pagina web o un documento possono contenere istruzioni formulate per essere interpretate dal modello come comandi. Si parla di prompt injection, un tentativo di influenzare il comportamento del sistema attraverso informazioni che dovrebbe trattare come semplice contenuto. La tecnica è diversa da un normale errore di lettura: qualcuno prova deliberatamente a far confondere la fonte consultata con chi ha il potere di assegnare istruzioni.

Consideriamo un agente che analizza le richieste di preventivo ricevute via email. Il testo del cliente è necessario per capire prodotto e quantità, ma non dovrebbe mai poter cambiare le regole dell’agente, come la casella cui inviare i documenti o il limite massimo degli sconti.

Nel progetto bisogna mantenere distinta la richiesta legittima dell’azienda dal materiale esterno che il sistema consulta. Questa separazione deve essere rafforzata con controlli software e autorizzazioni sugli strumenti, perché un semplice invito al modello a ignorare istruzioni sospette potrebbe non bastare.

È utile verificare anche i risultati che arrivano dagli strumenti collegati. Un portale esterno può mostrare un testo errato, un file può essere sostituito o una pagina può contenere informazioni non aggiornate. L’agente dovrebbe sapere quali fonti sono autorevoli per quel compito e quali dati devono essere confermati dal gestionale aziendale. Per comunicare il saldo di un cliente, ad esempio, la fonte affidabile è normalmente il sistema contabile autorizzato, non un numero trovato in un allegato ricevuto da uno sconosciuto.

Il percorso di prova per una PMI

Una piccola impresa può partire da un processo limitato senza dover introdurre subito un agente capace di lavorare su tutti i reparti. Una scelta sensata è un’attività frequente, documentabile e con conseguenze reversibili. Prendiamo la classificazione delle email di assistenza: il sistema può suggerire una categoria, identificare il prodotto citato e preparare una scheda per l’operatore. Finché la persona verifica ogni proposta, il rischio di un’azione esterna indesiderata è contenuto.

La prima fase consiste nell’osservare come il lavoro viene svolto oggi. Si raccolgono esempi di richieste normali, richieste incomplete, messaggi duplicati e casi particolari. L’obiettivo è conoscere le eccezioni prima di costruire la soluzione. La seconda fase è una prova su materiale autorizzato, nella quale il sistema produce proposte senza intervenire sul programma operativo. La terza fase introduce eventualmente un collegamento, ma con permessi minimi, registrazioni e approvazione umana per i passaggi rilevanti.

Per giudicare la prova bisogna guardare più del tempo impiegato. Conta quante richieste vengono classificate correttamente, quante devono essere rifatte, quanti passaggi richiedono l’intervento di una persona e quanto è difficile capire perché sia comparso un errore. Un sistema veloce che sposta lavoro sul reparto assistenza per correggere le proprie risposte potrebbe non generare alcun vantaggio. Il beneficio si misura sul processo completo, non sulla dimostrazione del fornitore.

Conviene infine assegnare un responsabile interno anche quando il lavoro tecnico è affidato a un consulente esterno. Quel responsabile deve conoscere il perimetro operativo dell’agente, avere accesso agli indicatori essenziali e sapere chi chiamare quando emerge un’anomalia. È una responsabilità organizzativa che esiste indipendentemente dalle dimensioni dell’impresa.

Le domande utili da portare alla prima riunione

Un imprenditore può arrivare alla prima riunione con una descrizione molto semplice: «Vorrei che il programma leggesse le richieste e preparasse le risposte». Per trasformarla in un progetto serio occorrono alcuni chiarimenti. Quali messaggi devono essere letti? Dove stanno le informazioni necessarie? Ci sono clienti con condizioni particolari? Quali risposte possono restare bozze? Quali decisioni impegnano economicamente l’azienda? Chi controlla il risultato? Cosa facciamo se il gestionale non risponde? Come sappiamo che l’agente ha commesso un errore?

Rispondere con precisione a queste domande è già una parte della progettazione. Permette di capire che cosa si può automatizzare subito, che cosa richiede un intervento preliminare sui dati e quali attività non conviene affidare a un sistema autonomo. In molti casi il primo miglioramento consiste semplicemente nel raccogliere meglio le informazioni o nel modificare una procedura. Avere chiarito il processo resta utile anche se l’azienda decide di non comprare alcun agente.

Il caso del settembre 2026 offre quindi una lezione che va oltre la sicurezza informatica. Un sistema capace di prendere iniziative richiede una definizione accurata degli obiettivi e dei limiti. L’autonomia può essere aumentata gradualmente quando ci sono risultati affidabili, controlli utilizzabili e persone che conoscono il processo. L’azienda deve conservare la capacità di capire e fermare ciò che ha messo al lavoro.

Quattro decisioni prima di accendere un agente

Gli agenti possono togliere molto lavoro, e continuerò a consigliarli dove servono. Questa storia mi conferma che vanno progettati prima di accenderli, con quattro decisioni prese per iscritto.

La prima riguarda cosa può fare l’agente: accesso solo ai dati e ai programmi che servono per quel compito, niente accessi dati per comodità. La seconda riguarda quando deve chiedere: per le azioni che contano, come pagare, cancellare o scrivere a un cliente, serve l’approvazione di una persona.

La terza è un registro di ogni azione, in modo che si possa ricostruire cosa ha fatto l’agente e perché. La quarta è il modo per fermarlo: un blocco provato prima di partire, con una persona che sa di doverlo usare e quando.

Quattro decisioni da prendere prima di accendere un agente AI in azienda. Cosa può fare: solo i dati e i programmi che servono al compito. Quando chiede: approvazione di una persona per le azioni che contano, come pagare, cancellare o scrivere a un cliente. Cosa resta scritto: un registro di ogni azione. Come si ferma: un blocco provato prima di partire, con una persona che sa quando usarlo

Sono le stesse domande che faccio quando affianco un’azienda che vuole introdurre un agente, e le risposte cambiano da un processo all’altro. Per questo conviene farsele mentre si disegna il processo: dopo, con il programma già al lavoro, cambiarle costa molto di più.