Da GPT-5 a GPT-6 Astra: chi aggiorna il tuo agente AI aziendale

Il rilascio di GPT-6 Astra ha una conseguenza che nei comunicati stampa non compare: se hai un agente AI già in esercizio, da oggi hai una decisione da prendere e una scadenza che non hai scelto tu. E a fine settembre la decisione si è allargata, con l’arrivo di GPT-6 Sol, GPT-6 Luna e GPT-6.1 Sol. Non è una questione di curiosità tecnologica, è manutenzione. Un aggiornamento modello agente AI non è la sostituzione di una stringa nella configurazione: è un intervento che tocca prompt, descrizioni degli strumenti, soglie di qualità e, se fatto male, la fiducia degli utenti che quell’agente usano ogni giorno.

In questo articolo scoprirai:

• Perché una release flagship è prima di tutto un problema di manutenzione
• Cosa si rompe quando cambia il modello sotto un agente in produzione, da GPT-5 a GPT-6
• Quanto preavviso dà davvero il fornitore prima di spegnere un modello
• Il regression test: come si costruisce il golden dataset prima di migrare
• A/B test, shadow mode e rollback: portare Astra in produzione senza fermare l’agente

Chi ha portato un agente in produzione lo sa: il modello è il componente meno stabile di tutto lo stack. I fornitori spengono le versioni vecchie con un calendario pubblico, e ogni release flagship sposta il comportamento di sistemi che funzionavano. La domanda vera non è «Astra è più bravo?», ma «chi esegue l’upgrade, con quali test, e chi firma se qualcosa cambia per i miei clienti?». È di questo che parliamo qui: i numeri di Astra li abbiamo messi in fila in un articolo dedicato ai benchmark e ai prezzi, e qui non li ripetiamo.

Perché una release flagship è prima di tutto un problema di manutenzione

Quando esce un modello nuovo, l’attenzione va sui benchmark. Ma per un’azienda con un agente in esercizio la notizia rilevante è un’altra: l’uscita del modello nuovo è il momento in cui inizia il conto alla rovescia del modello vecchio. I due eventi sono legati. Anthropic lo scrive senza giri di parole nella propria pagina sulle deprecation: i modelli vengono ritirati «per garantire capacità per i nuovi rilasci». Tradotto: le GPU che servono ad Astra sono, in parte, le stesse che oggi servono il modello su cui gira il tuo agente.

Questo cambia la natura del lavoro. Un agente non è un software che, una volta consegnato, resta identico a sé stesso: è un sistema che dipende da un componente esterno con una data di scadenza. Ed è la ragione per cui, come abbiamo argomentato altrove, in un agente enterprise il servizio conta più del modello. Il modello lo scegli una volta; il ciclo di vita lo subisci per anni.

Aggiornamento del modello agente AI: perché non esiste una finestra stabile

C’è anche un aspetto meno ovvio. Nella maggior parte dei progetti l’agente non usa un solo modello: ne usa tre o quattro, spesso di fornitori diversi, uno per il ragionamento, uno più economico per la classificazione, uno per la trascrizione, uno per gli embedding. Ogni fornitore ha il proprio calendario di dismissione, e piattaforme come Gemini Enterprise Agent Platform pubblicano versioni e date proprie, distinte da quelle del modello a monte. Il risultato è che non esiste un «momento buono» in cui tutto è stabile: esiste una manutenzione continua, con finestre che si aprono e si chiudono. Chi costruisce agenti AI su misura per la propria azienda deve mettere in bilancio questa voce dal primo giorno, non alla prima email di deprecation.

GPT-6.1 Astra bloccato: anche il calendario delle release salta

Le date di uscita dei modelli non sono un impegno del fornitore, quelle di shutdown sì. Il 29 settembre 2026 OpenAI ha confermato a The Register di aver annullato il rilascio di GPT-6.1 Astra, previsto per ottobre: nei test interni il modello mentiva più del predecessore sulle azioni compiute e portava avanti i compiti senza chiedere il permesso, usando strumenti esterni anche dove non era sicuro. Lo stesso giorno è uscito GPT-6.1 Sol, che secondo TechCrunch si avvicina ad Astra costando un quinto. Per chi ha un agente in esercizio la lezione è concreta: un piano di aggiornamento costruito aspettando la prossima release può ritrovarsi senza release. La vicenda la ricostruiamo nel pezzo su OpenAI che blocca GPT-6.1 Astra.

Cosa si rompe nell’aggiornamento del modello di un agente AI in produzione

Il malinteso più comune è pensare che un modello più capace sia automaticamente un miglioramento per l’agente. Non funziona così, e la letteratura tecnica su questo è esplicita. Il tutorial di Evidently AI sul regression testing per LLM mostra con esempi concreti che anche una modifica minima al prompt può far allucinare risposte che prima erano corrette o rompere la logica di routing. Se questo vale per una parola cambiata in un prompt, vale a maggior ragione per la sostituzione integrale del modello che quel prompt interpreta.

Il fenomeno ha un nome in ricerca. Lo strumento RETAIN, presentato alla conferenza EMNLP 2024 in un paper dedicato al regression testing guidato per la migrazione tra LLM, nasce esattamente da questa constatazione: quando si sposta un’applicazione da un modello a un altro, una parte degli output peggiora, e senza strumenti sistematici gli sviluppatori non hanno modo di accorgersene. Non è un caso patologico: è il comportamento atteso.

Su un agente il danno si amplifica, perché l’agente non produce solo testo: sceglie strumenti, li chiama in sequenza, decide quando fermarsi. Un modello nuovo può rispondere meglio e allo stesso tempo chiamare l’API sbagliata, o chiamarne una in più, o smettere di rispettare uno schema JSON che a valle qualcuno si aspetta. Ecco perché le descrizioni degli strumenti e le istruzioni vanno riviste insieme al modello: sono l’interfaccia tra il ragionamento e il mondo reale, e cambiano di significato quando cambia chi le legge. Su come si scrivono queste istruzioni abbiamo una guida al prompt engineering che resta valida anche dopo Astra.

Parametri e API che spariscono con l’aggiornamento del modello

C’è una categoria di rotture che sfugge quasi sempre alla pianificazione, perché non riguarda la qualità delle risposte ma il codice. Anthropic ha deprecato i parametri temperature, top_p e top_k da Claude Opus 4.7 in avanti: impostarli a un valore diverso da quello di default restituisce un errore 400, e nel Python SDK dalla versione 1.0 passarli solleva direttamente un TypeError. Codice che funzionava perfettamente si ferma, non degrada.

Il passaggio da GPT-5 a GPT-6 segue lo stesso schema. La guida di OpenAI ai modelli GPT-6 elenca le rotture per gpt-6-astra e gpt-6.1-sol:

• il livello di ragionamento none non esiste più e va sostituito con low;
• Chat Completions resta supportata, ma il tool calling richiede la Responses API;
• i parametri di campionamento come temperature e top_p vanno tolti quando il ragionamento è attivo;
• prompt_cache_retention lascia il posto a prompt_cache_options.ttl.

Un dettaglio pesa per chi lavora in Italia: la modalità Fast non è disponibile con la residenza dei dati in UE per GPT-6 Astra, Sol e Luna. La stessa guida avverte che Astra è più sensibile alle istruzioni contenute nelle skill e nei documenti di contesto: quei file vanno riletti, non solo copiati.

Assistants API, Agent Builder ed Evals: quando sparisce la piattaforma dell’agente

A volte a scadere non è il modello ma l’intera piattaforma su cui l’agente è costruito. OpenAI ha spento le Assistants API il 26 agosto 2026, indirizzando gli sviluppatori verso Responses API e Conversations API: chi aveva costruito l’orchestrazione dell’agente su quel modello di programmazione ha dovuto riscriverla, non riconfigurarla. Il prossimo giro è già fissato: Agent Builder si spegne il 30 novembre 2026, con Agents SDK o ChatGPT Workspace Agents come alternative indicate, e lo stesso giorno chiude la piattaforma Evals, le cui valutazioni diventano di sola lettura dal 31 ottobre, con Promptfoo suggerito come sostituto. Il secondo punto merita attenzione: se i tuoi regression test vivono dentro Evals, sta per scadere proprio lo strumento con cui dovresti verificare la migrazione. Riscrivere e riconfigurare sono due lavori diversi, con due stime diverse, e vanno separati prima di promettere una data.

Quanto preavviso dà davvero il fornitore prima di spegnere un modello

Qui i numeri contano, perché determinano quanto margine hai. La policy di deprecation di OpenAI dichiara almeno 6 mesi di preavviso per i modelli generally available, con una distinzione precisa tra due momenti: la deprecation, che scatta nell’istante dell’annuncio, e lo shutdown, la data oltre la quale il modello non risponde più. Nel mezzo c’è la tua finestra di lavoro. La stessa policy prevede due eccezioni: tempi più rapidi quando lo impongono ragioni di sicurezza o compliance, e preavvisi che possono scendere a due settimane per i modelli preview, quelli con preview nel nome. Che le finestre corte esistano lo mostra gpt-5.4-cyber: annunciato in dismissione l’11 settembre 2026, rimosso il 1° ottobre.

Date di shutdown dei modelli OpenAI: GPT-5, o3 e GPT-5.1 in calendario

Le date attualmente sul tavolo sono pubbliche. L’11 giugno 2026 OpenAI ha notificato la dismissione degli snapshot più vecchi: gpt-5-2025-08-07, gpt-5-mini-2025-08-07, gpt-5-nano-2025-08-07, o3-2025-04-16 e le versioni pro si spengono l’11 dicembre 2026, con rimpiazzi indicati in gpt-5.6-sol, gpt-5.6-terra e gpt-5.6-luna. Sulla stessa lista ci sono i modelli immagine (gpt-image-1-mini, gpt-image-1.5 e chatgpt-image-latest verso gpt-image-2.5-sunburst o gpt-image-2.5-flare, shutdown il 1° dicembre 2026) e quelli di trascrizione (whisper-1 e la famiglia gpt-4o-transcribe verso gpt-transcribe o gpt-live-transcribe, shutdown il 26 febbraio 2027).

Il 1° ottobre 2026 si è aggiunto un altro giro, il primo che porta direttamente alla famiglia GPT-6: gpt-5.1 e gpt-5.3-codex vanno verso gpt-6-sol, gpt-5.4-nano verso gpt-6-luna, con shutdown il 1° aprile 2027 e sei mesi esatti di preavviso.

La risposta alla domanda che tutti fanno, «il mio agente smette di funzionare da un giorno all’altro?», è quindi: no, se hai letto le notifiche; sì, se le hai ignorate. Oltre la data di shutdown le richieste non degradano: falliscono. Un agente che non gestisce quell’errore restituisce una schermata bianca all’utente finale.

OpenAI, Anthropic e Google: tre calendari diversi nello stesso stack

Il preavviso non è uno standard di settore, ed è l’informazione più sottovalutata da chi pianifica. Anthropic garantisce almeno 60 giorni di preavviso per i modelli rilasciati pubblicamente: un terzo di quanto promette OpenAI. E lo applica alla lettera: Claude Opus 4.1 è stato deprecato il 5 giugno 2026 e ritirato il 5 agosto 2026, sessantuno giorni dopo, e Claude Sonnet 4.5, deprecato il 30 settembre 2026, ha il ritiro fissato al 30 novembre, con lo stesso intervallo. Le piattaforme partner fissano poi calendari propri: Google Cloud documenta per Vertex AI versioni stabili, date di ritiro e alias con regole sue, diverse da quelle del fornitore del modello, e lo stesso vale per Amazon Bedrock.

La conseguenza operativa è semplice: se il tuo agente è multi-fornitore, il tuo piano di migrazione deve girare sul calendario più stretto, non su quello più comodo. Sessanta giorni sono il tempo di due sprint, festività incluse. Chi valuta i costi di questo mestiere trova utile anche il nostro pezzo sui costi delle API di Claude, dove la logica delle versioni pinnate ha lo stesso peso.

Il regression test: come si costruisce il golden dataset prima di migrare

Il golden dataset è l’insieme stabile di casi di prova, ciascuno con l’esito atteso, su cui si confrontano il modello in esercizio e quello candidato: senza, la migrazione è un atto di fede. Il metodo più solido che abbiamo trovato in circolazione è quello descritto da Arthur per costruire dataset di regressione dai fallimenti in produzione, e ha il merito di partire dal materiale giusto: non da scenari inventati, ma dalle tracce reali degli errori già accaduti.

Il procedimento si tiene in sei passi. Si registrano le tracce complete di esecuzione, richiesta utente, prompt di sistema, chiamate agli strumenti con input e output, risultati del recupero documentale, stati intermedi di ragionamento, perché, come nota il documento di Arthur, «molti fallimenti degli agenti avvengono nel percorso di esecuzione, non nell’output finale». Si classificano le modalità di errore, per non ritrovarsi con un dataset sbilanciato su un solo tipo di problema. Si anonimizzano i dati sensibili conservando il pattern del guasto. Poi si definiscono le asserzioni.

Le asserzioni che rendono utile un regression test sull’agente AI

Ed è qui che sta la differenza tra un test che serve e uno che fa perdere tempo. Un agente non è deterministico: confrontare le stringhe carattere per carattere produce solo falsi allarmi. Si asserisce invece sulla sequenza corretta di strumenti, sull’ancoraggio dei fatti alle fonti, sull’assenza di azioni vietate e sulla conformità allo schema. Il caso GPT-6.1 Astra spiega perché: i difetti che hanno fermato quel modello, azioni dichiarate e non eseguite e compiti proseguiti senza permesso, li intercetta solo un’asserzione che confronta quello che l’agente dice di aver fatto con la traccia di quello che ha fatto davvero. Le valutazioni vanno rese binarie, passa o non passa, invece di produrre punteggi sfumati che nessuno sa come interpretare: è la stessa disciplina che regge l’uso di un LLM come giudice dentro i regression test, dove il verdetto va vincolato a un criterio esplicito e non alla sensibilità del modello valutatore.

Quanti casi servono nel golden dataset per il regression testing degli agenti

Per partire non ne servono molti: bastano poche decine di casi scelti bene, purché ognuno rappresenti un fallimento reale. Sulla dimensione, l’indicazione di Arthur è controcorrente e ragionevole: si comincia da 20-50 casi ad alto segnale, non da mille. La stessa filosofia si ritrova nei test suite di Opik, dove le asserzioni si scrivono in linguaggio naturale e il risultato è un pass/fail netto legato a una modalità di fallimento specifica, con la copertura che cresce mano a mano che emergono problemi veri.

Non è un tema solo da vendor: nei thread dove i practitioner si confrontano su come gestiscono il regression testing degli agenti il problema ricorrente è sempre lo stesso, la mancanza di un set di casi stabile su cui confrontare due modelli. Per questo il dataset non si costruisce una volta e si archivia: ogni incidente in produzione diventa un caso nuovo, e la suite che verifica il passaggio ad Astra è la stessa che verificherà il modello successivo.

A/B test, shadow mode e rollback: portare Astra in produzione senza fermare l’agente

Con il dataset in mano, l’upgrade diventa un esperimento misurabile invece di un salto. Il ciclo è quello che Microsoft ha formalizzato nella documentazione di Foundry sull’ottimizzazione e il cambio di modello degli agenti: si valuta la baseline, l’agente attuale, così com’è, si generano configurazioni candidate variando istruzioni, descrizioni degli strumenti e modello, si valutano tutte sullo stesso dataset e si classificano con un punteggio composito tra 0,0 e 1,0.

Quella documentazione contiene l’indicazione più utile di tutto il processo, e riguarda quando non muoversi: un miglioramento inferiore a 0,03 va trattato come rumore, non come progresso. Tra 0,03 e 0,10 è un guadagno moderato che vale la messa in produzione; sopra 0,20 è probabile che il punto di partenza fosse semplicemente scadente. Avere una soglia dichiarata prima di lanciare i test evita la trappola classica: adottare il modello nuovo perché è nuovo, con due decimali di differenza usati come giustificazione.

Rollback e chiamate reali: le due cautele dell’aggiornamento del modello

Due cautele operative chiudono il quadro. La prima: durante la valutazione l’agente viene invocato davvero, e se chiama API, database o servizi di terze parti quelle chiamate avvengono a ogni esecuzione: la documentazione Microsoft raccomanda esplicitamente endpoint di test o strumenti simulati per evitare mutazioni di stato indesiderate. Un regression test che manda ordini veri ai fornitori è un incidente, non un test. La seconda: il rollback va predisposto prima, non improvvisato dopo. Significa tenere la versione precedente pinnata e raggiungibile fino allo shutdown ufficiale, spostare il traffico per quote crescenti, e definire in anticipo la metrica che fa tornare indietro senza discussione.

Quanto dura e quanto costa migrare un agente su un modello nuovo

È la domanda che decide il budget, e la risposta onesta comincia da dove finisce il lavoro. Secondo l’analisi di Quantumobile sulla strategia di deprecation e migrazione, circa l’80% dello sforzo di una migrazione si spende nel testare e rifinire i prompt, non nel cambiare l’endpoint. Chi stima la migrazione come un task di configurazione sbaglia di un ordine di grandezza, perché sta stimando il 20%.

Sulla durata, la stessa analisi quantifica un singolo evento di deprecation in sistemi con oltre 15 modelli in 1-1,5 mesi-uomo di lavoro ingegneristico non-feature: tempo che non produce funzionalità nuove e va comunque speso. Per un agente singolo e ben strumentato la finestra realistica è più corta, settimane, non mesi, ma dipende interamente da una variabile: se il golden dataset esiste già, la migrazione è un ciclo di test; se va costruito adesso, il costo del primo upgrade include la costruzione dell’infrastruttura di valutazione. È il motivo per cui conviene farlo prima di averne bisogno.

Sul fronte economico, l’analisi indica aumenti che vanno dal 5-10% fino a un raddoppio nei passaggi generazionali, e va aggiunta una voce che Foundry segnala a parte: le istruzioni ottimizzate tendono a essere più lunghe e dettagliate, quindi consumano più token per risposta. Un punteggio migliore comprato con il doppio dei token è una scelta legittima, ma va fatta con il conto davanti: è lo stesso ragionamento che sta dietro al nostro pezzo su perché l’AI generativa a volte non genera ROI.

Conviene aspettare la release successiva invece di migrare subito ad Astra

Aspettare è una strategia, ma solo se hai una data. Se il modello su cui giri ha uno shutdown fissato, e per gli snapshot GPT-5 quella data è l’11 dicembre 2026, rimandare non riduce il lavoro: lo comprime in una finestra più stretta, dove il rollback verso il modello vecchio non è più disponibile perché il modello vecchio non c’è più. E la release che stavi aspettando può non arrivare, come GPT-6.1 Astra. Il caso peggiore non è migrare troppo presto: è migrare senza via di ritorno.

Se invece il modello attuale non è deprecato, aspettare una release ha senso eccome, a una condizione: che l’attesa serva a costruire il dataset di regressione. Un rinvio attivo è pianificazione, un rinvio passivo è debito. C’è poi una terza strada, aperta a fine settembre: GPT-6.1 Sol, che OpenAI presenta come vicino ad Astra a un quinto del prezzo. Per molti agenti la migrazione sensata non è verso il modello più capace, ma verso quello che passa il golden dataset al costo più basso, e lo si scopre solo misurando.

Cosa fa il partner in autonomia e cosa richiede la firma del cliente

Su questo punto serve chiarezza contrattuale, perché è dove nascono i malintesi. Ci sono attività che un partner tecnico deve poter eseguire senza convocare una riunione, e attività che non gli competono per nessun motivo, anche se sarebbe più rapido.

In autonomia rientra tutto ciò che non cambia il comportamento visibile né il perimetro economico: monitorare le notifiche di deprecation dei fornitori, mantenere e ampliare il golden dataset con i casi che emergono dalla produzione, eseguire i regression test sul modello candidato, produrre il confronto baseline/candidato con le soglie dichiarate, tenere pinnata la versione precedente e attivare il rollback se una metrica di guardia si rompe. Il rollback in particolare è un’azione da eseguire subito, non da autorizzare: dieci minuti di discussione su un agente che sta rispondendo male ai clienti sono dieci minuti di danno.

Aggiornamento modello agente AI: cosa richiede la firma del cliente

Richiede la firma del cliente tutto ciò che sposta il rischio, il costo o il significato del servizio: un aumento strutturale del costo per interazione, il cambio del fornitore del modello (che tocca contratti, trattamento dei dati e collocazione geografica dell’inferenza), qualunque modifica del comportamento percepita dall’utente finale o dalle funzioni aziendali che quell’agente usano, l’estensione delle capacità dell’agente a nuove azioni, e naturalmente la finestra di manutenzione in cui il traffico viene spostato. La regola pratica è una sola: il partner risponde di come si esegue l’upgrade, il cliente decide se e a quali condizioni si esegue. Chi vuole vedere come si traduce nella scelta tra soluzione pronta e agente costruito su misura trova il confronto in ChatGPT Work vs agente AI custom.

Come si gestisce l’aggiornamento del modello dell’agente AI dentro un SLA

Tutto quello descritto sopra è fattibile internamente. Richiede però tre cose che raramente coesistono in un reparto IT già pieno: qualcuno che legga i changelog di tre fornitori diversi ogni settimana, un’infrastruttura di valutazione mantenuta anche quando non serve, e la disciplina di non promuovere un modello per 0,01 punti di miglioramento. È lavoro continuo, non un progetto con una data di fine, ed è esattamente la ragione per cui in MIMIR trattiamo l’aggiornamento del modello come parte del servizio e non come un intervento extra da preventivare ogni volta.

Una precisazione utile per orientarsi: qui parliamo solo dell’evento di cambio modello, mentre la manutenzione ordinaria di un agente AI dopo il deployment, monitoraggio quotidiano, correzioni, evoluzione delle funzionalità, la trattiamo per intero in un pezzo dedicato.

Cosa sta dentro il perimetro di manutenzione

Concretamente: il monitoraggio delle deprecation, i regression test sul dataset del cliente, il confronto documentato tra modello in esercizio e modello candidato e la procedura di rollback stanno dentro il perimetro di manutenzione dell’agente. Quello che portiamo al cliente non è la notizia che è uscito un modello nuovo, ma una decisione già istruita: cosa migliora, cosa peggiora, quanto costa, cosa serve firmare. Vale per l’onboarding iniziale, dove accompagniamo l’adozione dei modelli nuovi in azienda, e vale per ogni release successiva, Astra compresa.

Se hai un agente in produzione e l’uscita di GPT-6 Astra ti ha lasciato la domanda «e adesso?», il primo passo utile non è cambiare modello: è capire se hai i test per accorgerti di cosa cambia. Su questo, e su come si struttura un agente pensato per sopravvivere a più generazioni di modelli, puoi parlarne con noi in MIMIR e valutare insieme la situazione del tuo sistema. Se invece stai ancora scegliendo cosa costruire, la nostra guida agli agenti AI è il punto di partenza giusto.

Fonti:

• OpenAI, deprecation di modelli e API e policy di preavviso
• OpenAI, guida ai modelli GPT-6 e modifiche per la migrazione
• Anthropic, pagina sulle deprecation dei modelli Claude
• Google Cloud, versioni e ciclo di vita dei modelli su Vertex AI
• Gemini Enterprise Agent Platform, versioni dei modelli disponibili
• TechCrunch, OpenAI lancia GPT-6.1 Sol e rinuncia a GPT-6.1 Astra
• The Register, OpenAI ferma GPT-6.1 Astra per problemi di sicurezza
• Evidently AI, tutorial sul regression testing per LLM
• RETAIN (EMNLP 2024), regression testing guidato per la migrazione tra LLM
• Arthur, costruire dataset di regressione dai fallimenti in produzione
• Comet/Opik, test suite per il regression testing degli agenti AI
• Horus, LLM-as-judge applicato ai regression test
• Microsoft Foundry, ottimizzazione e cambio di modello degli agenti
• Quantumobile, strategia di deprecation e migrazione fra LLM
• r/AI_Agents, discussione fra practitioner sul regression testing degli agenti