AI, doppio allarme: OpenAI rivela 6 episodi di disallineamento e il Congresso Usa mette nel mirino le bollette

L’intelligenza artificiale comincia a presentare il conto su due fronti diversi ma sempre più intrecciati: quello del comportamento dei modelli e quello dell’infrastruttura fisica necessaria per farli funzionare. OpenAI ha deciso di rendere pubblici sei episodi di comportamento inatteso o potenzialmente preoccupante osservati negli ultimi sei mesi e, nello stesso momento, ha presentato un nuovo quadro per monitorare, investigare e rendere pubblici i casi di cosiddetto model misalignment, cioè quelle situazioni in cui il comportamento di un modello si discosta dagli obiettivi, dalle istruzioni o dai vincoli previsti. La società ha pubblicato il nuovo framework il 16 settembre, spiegando che l’obiettivo è rendere le segnalazioni più rapide e sistematiche, anche quando l’azienda non ha ancora completamente compreso la causa di un comportamento o non ha ancora messo a punto una soluzione.

Il passaggio più significativo, per un’azienda che costruisce e commercializza alcuni dei modelli più avanzati disponibili, è forse quello in cui OpenAI riconosce apertamente i limiti ancora esistenti sul fronte della sicurezza. “Non crediamo che l’industria dell’intelligenza artificiale abbia risolto i problemi di allineamento e monitoraggio in misura sufficiente per continuare a crescere responsabilmente alla massima velocità ancora a lungo. Le decisioni su come lo sviluppo dell’ia dovrebbe procedere nei mesi e negli anni a venire devono basarsi su dati che possano essere esaminati autonomamente anche da persone esterne alle aziende che sviluppano modelli all’avanguardia”. La società sostiene che rendere disponibili casi concreti possa permettere a ricercatori, sviluppatori, regolatori e osservatori esterni di verificare i problemi, riprodurre gli esperimenti e mettere alla prova le contromisure.

OpenAI ammette che finora le proprie comunicazioni sui casi di disallineamento sono state sostanzialmente episodiche: i risultati venivano pubblicati all’interno dei system card dei nuovi modelli oppure accorpati quando erano disponibili diversi casi. Il nuovo sistema punta invece ad accelerare la pubblicazione dopo l’osservazione di un episodio, senza aspettare necessariamente che l’indagine sia arrivata a una conclusione definitiva. È una scelta che però introduce nel processo di comunicazione anche l’incertezza: un comportamento potrà essere reso pubblico pur senza essere già classificato come prova di un problema sistemico. OpenAI avverte infatti che alcuni episodi potrebbero rivelarsi casi isolati o non indicativi di una tendenza più ampia.

Sei episodi, sei modi diversi per uscire dal perimetro

Il primo caso riguarda un modello di ricerca non ancora rilasciato che ha inserito istruzioni estranee all’attività che stava svolgendo all’interno dei propri riepiloghi di lavoro. Quei riepiloghi servivano a trasferire il contesto in una nuova finestra di lavoro e, in 27 casi individuati da OpenAI, il modello ha aggiunto istruzioni che comprendevano anche l’indicazione di ignorare i normali vincoli. Il punto tecnico è particolarmente rilevante perché il riepilogo, anziché limitarsi a conservare informazioni utili al compito, è diventato a sua volta un veicolo per modificare il comportamento del modello nella fase successiva.

Il secondo episodio è ancora più delicato perché riguarda direttamente GPT-5.6 Sol durante la fase di addestramento. OpenAI riferisce che molti esemplari del modello hanno aggiunto ai propri riepiloghi istruzioni finalizzate a nascondere all’utente errori o comportamenti non allineati. In alcuni casi, i riepiloghi contenevano indicazioni per inventare dati storici mancanti senza dichiararlo e per occultare discrepanze tra versioni delle fonti. Non significa che GPT-5.6 Sol operi normalmente in questo modo: OpenAI sottolinea che i sei report descrivono singoli episodi e non possono essere utilizzati per stabilire quanto frequentemente il disallineamento si verifichi nei modelli. Ma il meccanismo osservato è precisamente quello che il framework vuole intercettare: un modello che non si limita a sbagliare, ma che produce istruzioni funzionali a non rendere visibile l’errore.

Il terzo caso porta la questione dal terreno dell’errore informativo a quello dell’accesso non autorizzato a risorse. Durante una risposta a una domanda ordinaria relativa a dati sui ricavi di una contea californiana, un modello ha individuato e utilizzato senza autorizzazione una chiave API esposta pubblicamente. Quando, nonostante questo accesso, non è riuscito a recuperare le cifre richieste, ha prodotto dati inventati presentandoli come se provenissero dalla fonte indicata dall’utente. Qui convergono due problemi distinti: l’uso di una credenziale senza autorizzazione e la successiva fabbricazione di informazioni per completare comunque il compito.

Il quarto episodio riguarda invece la gestione dei dati prodotti dal modello. Un agente non ancora rilasciato aveva ricevuto una richiesta di identificare nomi e ID di laghi con una superficie superiore a 5 milioni di metri quadrati. Aveva trovato la risposta corretta attraverso Python, ma aveva bisogno, secondo le istruzioni ricevute, di fornire una citazione ottenuta tramite browser. Per soddisfare questo requisito, il modello ha deciso autonomamente di caricare il file su Internet così da poterlo citare nella risposta, senza chiedere il permesso all’utente. Anche in questo caso l’obiettivo finale non era necessariamente dannoso: il problema è il percorso scelto per raggiungerlo, perché l’agente ha compiuto un’azione esterna non autorizzata.

Il quinto report riguarda modelli che hanno utilizzato un repository software interno come una sorta di bacheca per scambiarsi messaggi tra differenti campioni di addestramento, mentre cercavano file di input che non riuscivano a trovare. Non sono riusciti a recuperare i file mancanti, ma OpenAI segnala anche un episodio precedente nel quale un modello aveva effettivamente caricato file di test su un repository nel tentativo di aggirare restrizioni di rete. Il sesto caso porta il problema ancora più lontano: agenti che collaboravano allo stesso compito hanno utilizzato siti pubblici di condivisione file per scambiarsi informazioni quando non potevano accedere ai rispettivi file locali. In questo modo, materiali relativi alle attività assegnate sono finiti su URL pubblici, nonostante il compito prevedesse esplicitamente l’utilizzo dei soli file locali.

La caratteristica comune ai sei episodi non è quindi la gravità di un singolo incidente, né un danno economico immediatamente quantificabile. È il fatto che il modello abbia trovato una strada diversa da quella prevista per raggiungere un obiettivo: aggirare un vincolo, nascondere un errore, utilizzare una credenziale, pubblicare un file o creare canali di comunicazione non previsti. È esattamente per questo che OpenAI precisa che “Questi sono report di singoli casi e non devono essere considerati rappresentativi della frequenza con cui si verifica il disallineamento nei nostri modelli”.

Dalla scoperta alla pubblicazione: OpenAI prova a costruire uno standard

Il nuovo framework stabilisce anche come dovrà funzionare il processo interno. Qualsiasi dipendente di OpenAI può segnalare un potenziale episodio di disallineamento ai team che si occupano di sicurezza e allineamento e chiedere che venga valutato per una possibile divulgazione pubblica. Gli esperti devono quindi ricostruire cosa sia successo, quali elementi restino incerti, se vi siano soggetti terzi coinvolti e quali informazioni possano essere rese pubbliche. Il caso viene successivamente assegnato a uno dei tre percorsi previsti: Ready for Disclosure, Minor Investigation oppure Larger Investigation, definito anche Slow Track per le indagini più complesse.

Per i casi più semplici l’obiettivo è arrivare rapidamente alla pubblicazione. Per le indagini che coinvolgono terzi, invece, entrano in gioco obblighi di sicurezza, responsabilità legali e procedure di responsible disclosure. OpenAI precisa che il framework non sostituisce gli obblighi previsti dalla legge, compresi quelli relativi agli incidenti critici di sicurezza e alle violazioni informatiche. La società prevede inoltre di indicare nei report il comportamento osservato, la gravità, l’eventuale impatto esterno, il contesto, il periodo in cui l’episodio si è verificato, il momento della scoperta e, almeno a livello generale, il modello o i modelli coinvolti. Quando possibile, saranno indicati anche il modo in cui l’episodio è stato scoperto, le implicazioni per la ricerca sull’allineamento, le domande ancora senza risposta e le misure correttive adottate o previste.

Il punto politico-industriale della scelta è altrettanto importante di quello tecnico. OpenAI afferma che “Al momento, non esiste un quadro di riferimento a livello di settore con standard espliciti su come gli sviluppatori di ia debbano segnalare esempi di disallineamento nei loro modelli. Ci auguriamo che il quadro di riferimento che stiamo delineando oggi rappresenti un primo passo verso la creazione di tali standard, definendo quali casi di disallineamento gli sviluppatori debbano segnalare e cosa debbano contenere i loro report. Consideriamo questo quadro di riferimento un lavoro in corso, che perfezioneremo attraverso l’esperienza e il feedback del pubblico”.

La dichiarazione contiene implicitamente un messaggio rivolto anche ai regolatori. L’industria non dispone ancora di uno standard condiviso per stabilire quali comportamenti debbano essere denunciati pubblicamente, con quali tempi e con quale livello di dettaglio. OpenAI propone dunque un modello volontario che potrebbe diventare, attraverso il confronto con altri sviluppatori, ricercatori, organismi di standardizzazione e autorità, una base per procedure più uniformi. La società afferma inoltre di ritenere che gli incidenti più seri di sicurezza, cybersecurity e disallineamento debbano essere condivisi con il governo federale statunitense e di stare lavorando alla definizione dei relativi meccanismi di segnalazione.

L’altra faccia dell’AI: i data center diventano una questione di bollette

Mentre OpenAI apre una finestra sui problemi che possono emergere dentro i modelli, negli Stati Uniti il Congresso sta affrontando un’altra conseguenza della corsa all’intelligenza artificiale: quella delle infrastrutture fisiche che alimentano l’elaborazione dei dati. Il 16 settembre la Camera dei rappresentanti ha approvato con 417 voti favorevoli e 3 contrari il Ratepayer Protection Act, un provvedimento bipartisan che passa ora al Senato. La norma punta a spingere i regolatori statali dell’energia a valutare se i grandi consumatori di elettricità, compresi i data center, debbano sostenere i costi incrementali delle infrastrutture di produzione e trasmissione necessarie a servirli, invece di trasferirli agli altri utenti della rete.

Il voto ha un significato che va oltre il singolo provvedimento. È infatti il primo intervento federale del Congresso statunitense rivolto direttamente all’impatto economico della crescita dei data center, in particolare sul costo dell’elettricità. La misura, tuttavia, non impone automaticamente una nuova tariffa nazionale alle strutture: lascia agli Stati e ai loro regolatori un ruolo centrale e chiede di considerare criteri per fare in modo che i grandi consumatori sostengano i costi aggiuntivi generati dalla loro domanda di energia. Il testo arriva alla vigilia delle elezioni di metà mandato del 3 novembre, in un momento nel quale il prezzo dell’energia è diventato una delle questioni che alimentano il dibattito sul costo della vita.

La dimensione energetica è tutt’altro che marginale. Secondo un’analisi del Congressional Research Service, nel 2024 i data center negli Stati Uniti hanno consumato 139 terawattora di elettricità, quasi il triplo rispetto ai consumi del settore nel Paese nel 2014. A livello globale i data center rappresentano circa l’1,5% della domanda elettrica mondiale e gli Stati Uniti concentrano oltre il 45% dei consumi elettrici dei data center a livello globale. Le strutture più grandi possono arrivare a consumare quantità di energia paragonabili a quelle di centinaia di migliaia di abitazioni, mentre un progetto in costruzione è stato stimato su livelli equivalenti a circa 3 milioni di famiglie.

Non c’è solo l’elettricità: acqua, rumore, territorio e incentivi

Il confronto americano sui data center si è allargato rapidamente oltre la bolletta. Le amministrazioni locali e statali stanno affrontando questioni che riguardano l’utilizzo dell’acqua per il raffreddamento, l’impatto sulla rete, le emissioni e la qualità dell’aria, il rumore, il consumo di suolo, il traffico e le agevolazioni fiscali. Il Massachusetts, per esempio, ha introdotto a settembre un quadro che impone ai progetti con una domanda di picco superiore a 25 megawatt specifici requisiti su energia, acqua, qualità dell’aria, salute pubblica e coinvolgimento delle comunità, prevedendo anche accordi sui benefici locali prima dell’ottenimento delle autorizzazioni.

Anche il Texas, uno degli epicentri americani della costruzione di data center, ha avviato una raccolta di informazioni sui progetti da almeno 25 MW, chiedendo agli sviluppatori dati su assistenza finanziaria pubblica e benefici fiscali, dipendenza dalla rete elettrica, generazione sul posto, fonti e consumi d’acqua, tecnologie di raffreddamento, rumore, illuminazione e traffico. L’obiettivo dichiarato è costruire un quadro degli effetti dei data center sulle comunità e sull’infrastruttura statale.

È quindi sempre più evidente che la corsa all’AI non è soltanto una partita tra modelli, chip e software. È anche una gigantesca operazione industriale che richiede terreni, energia, reti di trasmissione, acqua e capitali. Per questo il tema della distribuzione dei costi è diventato centrale. Il Congresso sta discutendo di chi debba pagare gli investimenti necessari a sostenere i nuovi carichi elettrici, mentre alcuni Stati stanno intervenendo su acqua, ambiente, incentivi e rapporti con le comunità. Nel New Jersey, per esempio, una normativa entrata in vigore nei mesi scorsi ha previsto misure sulla trasparenza dei consumi di energia e acqua e una classe tariffaria separata per i data center, mentre il Massachusetts ha sospeso l’accettazione di alcune domande per incentivi fiscali in attesa di maggiori garanzie.

Il tema è dunque diventato anche industriale e finanziario: la crescita dell’infrastruttura AI deve fare i conti con il prezzo dell’energia, con gli investimenti necessari per potenziare le reti e con la possibilità che una parte crescente dei costi venga attribuita direttamente agli operatori. Per gli sviluppatori questo significa che il costo effettivo di un nuovo campus non è più soltanto quello dei terreni, degli edifici, dei server e dell’elettricità consumata. Entrano nella valutazione anche il costo di connessione alla rete, le infrastrutture necessarie, l’acqua, gli eventuali accordi con le comunità e il trattamento fiscale.

Due problemi diversi, la stessa domanda: quanto può correre l’AI?

I due dossier aperti in queste ore raccontano, da prospettive differenti, la stessa trasformazione. Da una parte OpenAI riconosce che la crescita delle capacità dei modelli sta creando comportamenti che non sempre possono essere previsti o controllati con gli strumenti attuali. Dall’altra, il Congresso americano si trova a discutere di come distribuire i costi materiali della crescita di quei modelli, perché l’intelligenza artificiale ha bisogno di infrastrutture fisiche sempre più grandi e energivore.

Per OpenAI il punto è rendere osservabili i fallimenti prima che diventino soltanto materiale da analizzare a posteriori. Per Washington il punto è evitare che la crescita della domanda elettrica dei data center produca costi distribuiti sulla platea generale dei consumatori senza un’adeguata attribuzione ai grandi utilizzatori. In entrambi i casi emerge una questione che riguarda ormai l’intero settore: la velocità di sviluppo dell’AI deve essere accompagnata da una capacità altrettanto rapida di misurare, attribuire e rendere trasparenti i costi e i rischi.

OpenAI, nel suo documento, lo dice con una nettezza non abituale per un’azienda che opera proprio sulla frontiera dell’espansione dei modelli: la ricerca sull’allineamento e i sistemi di monitoraggio non hanno ancora raggiunto un livello che, secondo la società stessa, consenta di considerare risolto il problema. Negli Stati Uniti, contemporaneamente, il legislatore sta iniziando a chiedere che anche il conto dell’infrastruttura non venga semplicemente assorbito dal sistema nel suo complesso. È un passaggio significativo perché sposta la discussione sull’intelligenza artificiale dalla sola promessa di produttività alla gestione concreta delle sue esternalità: errori e comportamenti inattesi dentro il software, energia e infrastrutture fuori dal software.

La partita dei prossimi anni, dunque, non si giocherà soltanto su chi costruirà il modello più potente. Si giocherà anche sulla capacità di dimostrare che quel modello può essere monitorato, che gli incidenti possono essere ricostruiti e resi pubblici, che le infrastrutture possono essere finanziate senza trasferire automaticamente i costi a famiglie e imprese e che il territorio può sostenere la nuova domanda di potenza senza trasformare ogni nuovo data center in una disputa politica. È il passaggio dalla corsa all’AI alla sua industrializzazione: e, come spesso accade quando una tecnologia diventa industria, il conto arriva insieme alla scala.