GPT-4o è andato in pensione il 13 febbraio. Claude 3.5 Sonnet v2 è offline su Vertex AI dal 19 febbraio. Due eventi in una settimana che rendono urgente una domanda finora rimasta sullo sfondo: come si governa un sistema AI quando il modello sotto cambia?
Il 13 febbraio 2026 OpenAI ha ritirato GPT-4o, il modello lanciato in maggio 2024 che in meno di due anni era diventato il punto di riferimento per migliaia di integrazioni enterprise. Sei giorni dopo, il 19 febbraio, Google Vertex AI ha portato offline Claude 3.5 Sonnet v2, il modello di Anthropic che fino a quella data era ancora uno dei più usati in ambito aziendale sulle piattaforme cloud. Due ritiri in una settimana, due fornitori diversi, stesso risultato: sistemi costruiti su quei modelli hanno smesso di funzionare come previsto, o hanno smesso del tutto di funzionare.
Non è una novità assoluta. I modelli AI hanno un ciclo di vita, esattamente come qualsiasi componente software. Anthropic aveva notificato la deprecazione di Claude 3.5 Sonnet v2 già ad agosto 2025, con più di sei mesi di preavviso su alcuni canali. OpenAI aveva annunciato il ritiro di GPT-4o a dicembre 2025. Le informazioni erano disponibili. Eppure, per molte organizzazioni, il momento del ritiro è arrivato come un evento imprevisto, o comunque gestito in fretta e sotto pressione.
La domanda che vale la pena porsi non riguarda i modelli specifici che sono stati ritirati. Riguarda la struttura dei sistemi che li usavano. Quante organizzazioni avevano progettato un piano di risposta al cambio modello? Quante avevano un layer di astrazione tra l'applicazione e il modello? Quante sapevano esattamente quali comportamenti sarebbero cambiati e quali no, nel passaggio al successore?
La narrazione ufficiale dei provider è sempre la stessa: il modello successore è migliore, più capace, più sicuro. Basta aggiornare l'identificatore nel codice e il sistema funzionerà meglio di prima. Nella pratica, le cose vanno in modo diverso.
Un agente AI in produzione non interagisce solo con un modello linguistico. È una pipeline composta da più elementi: i prompt di sistema che definiscono il comportamento, la knowledge base da cui il modello recupera informazioni, gli strumenti esterni a cui è collegato (CRM, ERP, sistemi di ticketing, API aziendali), le policy che stabiliscono cosa può e non può dire, la logica di orchestrazione che gestisce flussi complessi e passaggi all'operatore umano. Quando il modello cambia, cambia il modo in cui tutti questi elementi interagiscono tra loro. Alcune risposte migliorano. Altre diventano diverse — non necessariamente peggiori, ma diverse rispetto a quanto il sistema era stato progettato e validato per produrre.
Il team di Userbot ha analizzato questo fenomeno con precisione in un articolo recente: il problema non è solo il drift del modello, ma il drift del contesto. Un golden dataset — l'insieme di domande e risposte attese usato per validare il comportamento del sistema — non misura più un modello quando il modello cambia. Misura un'implementazione storica di un sistema che non esiste più nella stessa forma.
In pratica: la stessa domanda posta al sistema il giorno prima e il giorno dopo il cambio modello può produrre risposte diverse. Non perché il sistema sia rotto, ma perché il contratto di comportamento implicito su cui era stato costruito non è stato esplicitato, testato e reso resiliente al cambiamento.
Nel software tradizionale, la dipendenza da un componente esterno viene gestita attraverso contratti espliciti: interfacce stabili, semantic versioning, backward compatibility. Se una libreria cambia in modo incompatibile, il sistema lo sa perché il numero di versione lo segnala. Con i modelli AI generativi, questo meccanismo non esiste allo stesso modo. I provider aggiornano i modelli in modo continuo, e le variazioni nel comportamento possono essere sottili, distribuite su migliaia di possibili input, difficili da rilevare con test spot.
La risposta non è fare più test nel senso classico del termine. È cambiare il tipo di test. Come sottolinea l'analisi di Userbot, un golden dataset tradizionale — domanda, risposta attesa — funziona bene quando la risposta è quasi deterministica. Con i modelli generativi, la risposta corretta non è una stringa precisa, ma una famiglia di risposte accettabili che rispettano certi vincoli: coerenza fattuale rispetto alla knowledge base, tono appropriato, assenza di allucinazioni, corretto utilizzo degli strumenti collegati. Validare questo richiede rubriche qualitative, metriche su tool-use e fallimenti, evals continui che girino in produzione — non solo prima del lancio.
Questo è il passaggio che molte organizzazioni hanno ancora davanti: rendere esplicito il contratto di comportamento che oggi è implicito. Definire cosa l'agente deve fare, su quali fonti deve basarsi, quando deve passare all'umano, quali errori sono accettabili e quali no. E poi costruire l'infrastruttura per verificare che questo contratto venga rispettato nel tempo, indipendentemente da quale modello lo esegue.
Il principio operativo che emerge dall'esperienza di chi gestisce agenti AI in produzione su processi reali è semplice da enunciare e meno semplice da implementare: separare ciò che deve essere stabile da ciò che può cambiare. Il contratto di comportamento deve essere stabile. Il motore che lo esegue può e deve poter cambiare, senza che l'applicazione si rompa.
In architettura, questo si traduce nell'astrazione del modello dietro un layer di orchestrazione. L'applicazione non dipende da GPT-4o o da Claude 3.5 Sonnet v2 come dipendenza diretta. Dipende da un'interfaccia comportamentale che viene governata, osservata e testata separatamente. Quando il provider ritira un modello e ne introduce un altro, il cambio avviene a quel livello, con rollout controllati: prima in shadow mode — valutazioni parallele senza impatto sugli utenti reali — poi su una percentuale limitata di traffico, poi in espansione progressiva.
Questo approccio ha un vantaggio che non è visibile nelle demo ma è decisivo in produzione: trasforma il ritiro di un modello da evento critico a operazione di manutenzione pianificata. Non elimina il lavoro di validazione, ma lo rende gestibile, tracciabile, reversibile. Se il nuovo modello si comporta in modo inatteso su un sottoinsieme di casi, il sistema può tornare al precedente mentre si investigano le cause.
Nei progetti complessi che seguiamo, utilizziamo Userbot precisamente per questo: non solo come piattaforma per costruire agenti, ma come strato di governo che mantiene il sistema affidabile mentre l'infrastruttura sotto evolve. La piattaforma gestisce orchestrazione, osservabilità, integrazioni con sistemi aziendali, sicurezza e conformità GDPR, e permette di affrontare il cambio di modello come un'operazione ingegneristica con guardrail — non come un salto nel buio.
I ritiri di GPT-4o e Claude 3.5 Sonnet v2 in questa settimana sono un test pratico per le organizzazioni che hanno costruito sistemi AI negli ultimi due anni. Non un test catastrofico — i preavvisi erano stati dati, le alternative esistono — ma un test significativo: rivela quanto le scelte architetturali fatte durante la fase sperimentale reggono quando l'AI entra davvero nella continuità operativa.
Chi aveva progettato il sistema con un layer di astrazione tra applicazione e modello ha gestito il passaggio come una migrazione pianificata. Chi aveva accoppiato strettamente il proprio sistema a un modello specifico si è trovato a operare in emergenza, con il rischio concreto di regressioni nei comportamenti validati e di interruzioni nei processi che dipendevano dall'agente.
La differenza non riguarda la complessità tecnologica. Riguarda il modo in cui si è pensato al problema. Un sistema AI in produzione non è un componente statico: è una dipendenza viva, soggetta a evoluzione continua. Progettarlo significa accettare questa natura e costruire di conseguenza — con osservabilità, evals continui, rollout controllati, policy chiare e la capacità di tornare indietro quando qualcosa non va.
In febbraio 2026, secondo le stime disponibili, più di sette modelli rilevanti sono stati lanciati o aggiornati in contemporanea. Il ritmo non rallenterà. La vera domanda per chi governa sistemi AI in azienda non è quale modello scegliere oggi. È quanto il sistema è attrezzato per gestire il cambiamento quando arriva — e arriverà, con una frequenza che non ha precedenti nella storia dello sviluppo software.
Cosa significa concretamente "cambio di comportamento" quando si aggiorna un modello AI? Significa che risposte precedentemente validate possono variare: tono diverso, dettagli omessi o aggiunti, diversa gestione dei casi limite. Non è necessariamente un peggioramento, ma è un cambiamento rispetto a quanto il sistema era stato progettato per produrre.
Quali segnali indicano che un sistema AI non è pronto per il cambio di modello?Assenza di evals automatici in produzione, dipendenza diretta dall'ID del modello nel codice applicativo, nessun piano di rollout progressivo, golden dataset non aggiornato dall'ultimo rilascio: sono tutti indicatori di un sistema fragile al cambiamento.
Con quanto anticipo i provider notificano il ritiro di un modello? Anthropic garantisce almeno 60 giorni di preavviso per i modelli rilasciati pubblicamente via API. OpenAI segue policy simili. I ritiri di GPT-4o e Claude 3.5 Sonnet v2 erano stati annunciati con mesi di anticipo, rispettivamente a dicembre 2025 e agosto 2025.
Cos'è un layer di orchestrazione e perché è rilevante per la gestione dei modelli? È uno strato software che si interpone tra l'applicazione e il modello AI, gestendo routing, fallback, test paralleli e monitoraggio. Permette di cambiare il modello sottostante senza modificare l'applicazione e rende il processo di aggiornamento controllabile e reversibile.
Userbot è adatto solo a grandi aziende o anche a realtà di dimensioni medie? La piattaforma è progettata per organizzazioni che gestiscono processi reali con agenti AI in produzione. La complessità che affronta — orchestrazione, osservabilità, integrazioni enterprise — diventa rilevante non appena l'AI esce dalla fase sperimentale e inizia a supportare flussi operativi continuativi.