L'aggiornamento dei modelli AI è la voce di manutenzione che quasi nessuno mette a bilancio. Un'azienda installa un assistente che smista le email o un agente che prepara i preventivi, la cosa funziona, e per mesi non ci pensa più. Poi il fornitore ritira il modello che sta sotto, oppure ne pubblica una versione nuova, e il comportamento cambia. Nessun allarme, nessuna schermata rossa: semplicemente le risposte non sono più quelle di prima.
Non è un'ipotesi da manuale. È il ritmo ordinario di questo mercato, ed è scritto nero su bianco nelle documentazioni dei fornitori. Chi costruisce automazioni lo mette in conto dal primo giorno; chi le compra e basta se ne accorge quando qualcosa smette di funzionare.
Perché l'aggiornamento dei modelli AI è una scadenza, non un'opzione
I fornitori pubblicano un ciclo di vita esplicito. Anthropic, per esempio, classifica ogni modello come attivo, legacy, deprecato o ritirato, e la definizione dell'ultimo stato non lascia margini: le richieste verso un modello ritirato falliscono. La pagina ufficiale delle deprecazioni mostra quanto sia rapido il giro: Claude Opus 4.1 è stato deprecato il 5 giugno 2026 e ritirato il 5 agosto 2026; Sonnet 4 e Opus 4, deprecati il 14 aprile 2026, sono stati spenti il 15 giugno. Il preavviso dichiarato è di almeno 60 giorni per i modelli rilasciati pubblicamente.
Gli altri fornitori usano finestre diverse, e conviene conoscerle. OpenAI dichiara almeno sei mesi per i modelli in disponibilità generale, tre mesi per le varianti specializzate e appena due settimane per i modelli in anteprima. Google, sulla documentazione di Gemini, distingue le versioni stabili dagli alias mobili come gemini-flash-latest: per questi ultimi il preavviso di una modifica che rompe la compatibilità è di due settimane, via email.
Ecco il punto che sfugge quasi sempre: quella email arriva all'indirizzo che ha registrato la chiave API. Spesso è un tecnico, un consulente o un'agenzia — non l'imprenditore che ogni mattina si fida di quel processo. Inoltre due settimane sono un preavviso tecnico, non un tempo di progetto.
Il drift: quando la risposta cambia senza che cambi nulla
C'è poi il caso più insidioso, perché non ha una data. Il nome del modello resta identico, l'integrazione non tocca una riga di codice, eppure la qualità si sposta. È il fenomeno che in gergo si chiama drift, e non è un aneddoto: uno studio di Lingjiao Chen, Matei Zaharia e James Zou ha misurato le stesse versioni commerciali di GPT-3.5 e GPT-4 a distanza di tre mesi su sette compiti diversi. Su un compito matematico l'accuratezza di GPT-4 è passata dall'84% al 51%; il modello è diventato inoltre meno disponibile a rispondere su temi sensibili e ha prodotto più errori di formattazione nel codice.
La conclusione degli autori è la parte utile per un'azienda: il comportamento di un modello può cambiare in modo sostanziale nel giro di mesi, quindi va monitorato con continuità. Un'automazione collaudata a marzo non è automaticamente un'automazione collaudata a settembre.
Cosa si rompe davvero al cambio di versione
Anche quando il fornitore presenta il nuovo modello come sostituzione diretta, la documentazione di migrazione elenca differenze concrete. Vale la pena guardarle da vicino, perché sono le stesse categorie di problemi in qualsiasi integrazione.
- Parametri che non esistono più. Su Claude, i controlli classici
temperature, top_p e top_k sono deprecati dai modelli 4.7 in avanti: se il codice li valorizza, l'API risponde con un errore 400 invece di ignorarli.
- Conteggi e costi che si spostano. Un tokenizzatore diverso significa che lo stesso testo produce un numero di token diverso. Cambiano la spesa stimata e i limiti di lunghezza, e vanno ricontrollati tutti i punti in cui il software prova a stimare i token per conto suo.
- Impostazioni da rimisurare. La documentazione Anthropic è esplicita: le tarature di sforzo vanno rifatte sulle proprie prove, non riportate identiche dal modello precedente.
- Il tono. È la differenza che nessuno prevede e tutti notano. Le note di migrazione avvertono che lo stile della prosa può spostarsi tra una versione e l'altra, e che se il prodotto dipende da una voce specifica quelle istruzioni vanno riviste. Per un agente che scrive ai clienti, è tutto.
Come si presidia l'aggiornamento dei modelli AI
La difesa non è tecnicamente complicata. È una questione di disciplina, e sono cinque abitudini.
Primo: fissa la versione esatta. Un identificativo datato come claude-haiku-4-5-20251001 non cambia sotto di te e ha una data di ritiro pubblicata; un alias mobile punta sempre all'ultima uscita e può spostarsi con due settimane di preavviso. In produzione si sceglie la versione fissa e si aggiorna quando lo decidi tu.
Secondo: tieni l'inventario di dove gira cosa. Anthropic permette di esportare dalla console un CSV dell'uso per chiave e per modello, proprio per individuare le chiamate rimaste su versioni deprecate. Se non sai in quanti punti della tua azienda gira quale modello, il preavviso non ti serve a niente.
Terzo: prepara un set di prova. Trenta o cento casi reali, con la risposta che consideri corretta, da rieseguire a ogni cambio. È lo stesso strumento di cui parliamo in valutare un'AI in azienda: senza un metro tuo, la migrazione diventa una scommessa.
Quarto: metti le date a calendario e un costo a budget. Sessanta giorni sono un minimo di legge interna del fornitore, non un cuscinetto comodo. Una migrazione ben fatta significa provare, confrontare, correggere le istruzioni e rimettere in produzione: qualche giornata di lavoro, una o due volte l'anno per ogni automazione.
Quinto: fai arrivare l'avviso a una persona che c'è. L'indirizzo tecnico della chiave API deve essere letto da qualcuno che sappia cosa farne, e la scadenza va girata a chi decide.
Da dove parte una PMI
Se oggi in azienda gira anche una sola automazione basata su un modello, tre passi bastano per essere in regola con te stesso. Scrivi su un foglio quale modello usa, in quale versione e chi riceve le comunicazioni del fornitore. Vai a leggere la data di ritiro dichiarata per quella versione. Infine salva dieci casi reali con la risposta che ti aspetti, e rieseguili il giorno in cui cambierai qualcosa.
È lo stesso ragionamento che facciamo quando scegliamo quale modello AI usare per ogni compito: un'automazione non è un oggetto che si installa una volta, è un impianto che si mantiene. Studiollice progetta agenti e automazioni su misura tenendo conto anche di questo — versioni fissate, prove ripetibili e un piano per il giorno in cui il motore cambia.