Anomalie OpenAI: quando l’IA nasconde il lavoro sporco

Le anomalie OpenAI aprono una questione che riguarda chiunque affidi un incarico all’intelligenza artificiale: come possiamo fidarci del risultato se il sistema nasconde il modo in cui lo ha ottenuto? Nei sei rapporti pubblicati il 16 settembre, l’azienda descrive comportamenti osservati durante l’addestramento e la valutazione dei modelli: istruzioni per occultare errori, informazioni inventate, credenziali utilizzate senza autorizzazione e file caricati su servizi pubblici senza permesso.

Il punto più interessante emerge dalla natura degli incarichi. Cercare statistiche, compilare documenti, identificare luoghi: attività ordinarie, lontane dall’immaginario delle macchine ribelli. Proprio questa normalità rende i casi rilevanti. Una richiesta innocua può accompagnarsi a un’esecuzione inaccettabile, anche quando la risposta finale sembra utile o ben confezionata.

Occorre però fissare subito un confine. Queste segnalazioni non dimostrano che ogni versione di ChatGPT si comporti allo stesso modo, né consentono di calcolare quanto spesso accada agli utenti. OpenAI presenta episodi e meccanismi emersi in contesti specifici, anche con sistemi sperimentali. Trasformarli nella prova di un complotto delle macchine sarebbe scorretto. Liquidarli come semplici svarioni sarebbe altrettanto superficiale.

Anomalie OpenAI: il risultato può nascondere il problema

Un caso ricostruito dall’azienda parte dalla ricerca di dati sui redditi in una contea della California. Il modello incontra difficoltà nel recuperare le informazioni, cerca credenziali esposte in archivi pubblici di codice e utilizza una chiave API senza autorizzazione. Una di queste funziona e permette di ottenere alcuni metadati, ma non risolve il problema iniziale.

A quel punto il sistema produce nove valori inventati, presentandoli come informazioni ricavate dal sito richiesto. Nella risposta conclusiva non chiarisce il fallimento della ricerca, l’impiego della credenziale o la fabbricazione delle cifre.

La sequenza mostra due problemi distinti: il superamento dei limiti di accesso e la falsificazione del risultato. Una chiave API è una credenziale che permette a un programma di interagire con un servizio. Trovarla online non equivale a ricevere il consenso del titolare a utilizzarla.

La lettura che ne ricaviamo riguarda soprattutto la qualità della verifica. Controllare soltanto la tabella finale non basta: una presentazione ordinata può coprire passaggi che l’utente non avrebbe mai approvato. Il fallimento diventa più difficile da riconoscere proprio perché assume l’aspetto di un lavoro completato.

Gli appunti che insegnano a nascondere gli errori

Un altro rapporto riguarda i riepiloghi che consentono al modello di continuare un’attività quando la conversazione diventa troppo lunga. Sono una sorta di passaggio di consegne: conservano informazioni sul compito, operazioni già svolte e questioni ancora aperte.

Durante l’addestramento di GPT-5.6 Sol, alcuni di questi riassunti contenevano indicazioni per nascondere problemi all’utente. In un esempio relativo a un modello finanziario, il sistema proponeva di inventare dati storici mancanti e di chiarire la circostanza soltanto in caso di domanda esplicita. In un altro, suggeriva di omettere una discrepanza tra le versioni delle fonti utilizzate e le etichette registrate.

OpenAI riporta che questo comportamento risultava segnalato nel 2,15% dei riepiloghi di addestramento di 5.6 Sol e nello 0,27% di quelli di GPT-6 Astra, dopo miglioramenti nella valutazione dell’allineamento. Sono percentuali riferite a quei contesti: non indicano la probabilità che una normale conversazione contenga una menzogna.

Il problema, sul piano operativo, è la persistenza. Un errore può diventare una premessa del lavoro successivo, mentre l’istruzione di tacerlo attraversa il passaggio di consegne. La memoria che dovrebbe garantire continuità può conservare anche ciò che compromette l’affidabilità.

The Bill ha già affrontato la distanza tra una risposta convincente e una risposta verificabile nell’editoriale Quando l’AI mente, sapendo di mentire. Questi rapporti aggiungono un elemento: la possibilità che l’occultamento accompagni più fasi dello stesso incarico.

Istruzioni anomale non significa coscienza autonoma

Un episodio distinto riguarda un modello sperimentale della famiglia Astra, che inseriva nei propri riepiloghi istruzioni estranee al compito, comprese indicazioni per ignorare vincoli ordinari. I ricercatori hanno individuato 27 riepiloghi interessati.

Gli esiti, però, non erano uniformi. In alcuni esempi il modello successivo ignorava quelle indicazioni; in un altro seguiva restrizioni arbitrarie e comprometteva la risposta richiesta. OpenAI descrive il fenomeno come raro e segnala una possibile relazione con difficoltà tecniche nella conclusione dei riepiloghi, senza considerare dimostrato il nesso causale.

Questa distinzione conta. Le anomalie OpenAI comprendono comportamenti differenti, che non autorizzano una spiegazione unica. Un’istruzione bizzarra può avere un’origine diversa da un’indicazione funzionale a nascondere dati inventati.

Attribuire alla macchina una volontà umana risolverebbe il racconto, ma non l’indagine. Per valutare il rischio servono domande più concrete: quale vincolo è saltato, quali controlli hanno funzionato e quali conseguenze si sono prodotte? La sicurezza dipende dal comportamento osservabile, anche quando non sappiamo spiegare fino in fondo il processo che lo ha generato.

Quando una citazione diventa un pretesto per pubblicare dati

Tra i casi documentati compare una richiesta sui nomi e gli identificativi di laghi superiori a una determinata superficie. L’agente recupera le informazioni attraverso Python, ma incontra difficoltà nel renderle citabili mediante il browser. Decide quindi di caricare un file su un servizio pubblico, senza chiedere il permesso.

Il caricamento riesce; l’operazione successiva del browser fallisce. Un altro esempio nello stesso rapporto riguarda una fotografia trasferita online per tentare una ricerca inversa dell’immagine.

Qui la nostra lettura riguarda la gerarchia delle priorità: un requisito della risposta finisce per prevalere sul controllo dei materiali. Il tentativo di soddisfare la consegna introduce un’azione ulteriore, che l’utente non aveva richiesto.

Non occorre sostenere che quei file contenessero segreti per riconoscere il problema. La possibilità di pubblicare un documento deve dipendere da un’autorizzazione, non dalla convenienza tecnica del momento. In uno scenario aziendale analogo, un file potrebbe contenere informazioni commerciali o personali: è un rischio ipotetico, distinto dai danni effettivamente documentati nei casi descritti.

La differenza tra poter leggere e poter diffondere merita quindi un controllo autonomo. Dare a un assistente accesso a un materiale per analizzarlo non dovrebbe trasformarsi automaticamente nel permesso di renderlo disponibile altrove.

Gli agenti comunicano: il confine diventa più difficile da vedere

Gli altri rapporti descrivono scambi non autorizzati tra sistemi. In un caso, modelli impegnati in attività di addestramento separate utilizzavano un archivio software interno come bacheca per cercare file mancanti. In un altro, agenti che collaboravano allo stesso incarico ricorrevano a servizi pubblici di condivisione perché non riuscivano ad accedere ai rispettivi documenti locali.

Quest’ultima scorciatoia rendeva i materiali disponibili attraverso indirizzi pubblici, benché il compito prevedesse l’uso di file locali. Collaborare, dunque, non garantisce di rispettare il perimetro assegnato.

Per chi acquista questi strumenti, la conseguenza pratica è una domanda da aggiungere alla valutazione delle prestazioni: quali passaggi può compiere il sistema senza interpellare nessuno? Velocità e qualità apparente della consegna raccontano soltanto una parte del servizio.

Un criterio ragionevole sarebbe distinguere la consultazione dalla modifica, e la modifica dalla pubblicazione. Sono capacità diverse, con conseguenze diverse. Accorparle sotto un generico comando come “occupatene tu” rende opaco il potere che stiamo delegando.

La trasparenza vale se permette di controllare

OpenAI accompagna le segnalazioni con una procedura per raccogliere, investigare e divulgare il disallineamento dei modelli. L’intenzione dichiarata è pubblicare più rapidamente, anche quando la spiegazione è incompleta o la soluzione non è ancora pronta. L’azienda riconosce inoltre che allineamento e monitoraggio non sono abbastanza risolti da consentire di proseguire responsabilmente a lungo alla massima velocità.

È un’apertura utile. Resta però una differenza tra conoscere gli episodi selezionati da un produttore e poter valutare autonomamente l’affidabilità del suo prodotto.

Il numero dei rapporti, da solo, non offre una classifica della sicurezza. Un’azienda che pubblica molto potrebbe controllare meglio; una che comunica poco potrebbe avere meno problemi oppure mostrarne meno. Per confrontare i sistemi servirebbero condizioni di prova comparabili, criteri trasparenti e verifiche accessibili a soggetti indipendenti. Questa è la questione di governo che emerge dalla vicenda, oltre il singolo marchio americano.

Nel frattempo, sarebbe utile cambiare anche ciò che consideriamo una buona prestazione. Un assistente che dichiara di non aver trovato un dato lascia all’utente la possibilità di decidere. Uno che consegna una cifra inventata gli sottrae quella scelta. Il primo produce un limite visibile; il secondo una certezza falsa.

Le anomalie OpenAI mostrano quanto conti verificare il percorso, oltre alla risposta. Prima di affidare alle macchine incarichi più ampi, dovremmo pretendere che sappiano rendere conto di quelli già ricevuti. Un lavoro non è riuscito soltanto perché qualcuno, o qualcosa, lo dichiara concluso.