Soluzione · AI Operations
Il modello che hai scelto sparirà. La domanda è se te ne accorgerai prima o dopo il tuo cliente.
Scegliere il modello non è una decisione che si prende una volta sola: i fornitori ritirano versioni con preavviso, le aggiornano sotto di te e muovono i prezzi — e il tuo sistema intanto resta in produzione. Costruiamo la funzione che trasforma il cambio di modello in un'operazione noiosa: banco di prova tuo, confronto reale e ritorno indietro, invece di un salto nel vuoto.
Il problema
Il tuo fornitore di modello è un fornitore. Tu lo tratti come una costante.
- Il modello che usate è stato scelto un pomeriggio, un anno e mezzo fa, perché era quello buono in quel momento. Nessuno ha più rivisto la decisione e nessuno sa se sia ancora giusta.
- È arrivata una mail di ritiro con una data. Nessuno sa quanti vostri sistemi dipendono da quella versione precisa, quindi nessuno sa quanto lavoro c'è dietro quella data.
- Qualcuno ha provato un modello nuovo su cinque esempi scritti a mano, gli è sembrato migliore e l'ha messo in produzione. Il confronto è stato un'impressione, non una misura.
- Una mattina la qualità è cambiata senza che nessuno toccasse nulla. Si è discusso se fosse il modello, il prompt o il dato, si è deciso a sensazione e si è andati avanti.
- Lo stesso modello costoso serve l'attività che richiede criterio e quella che smista una mail in tre caselle, perché decidere cosa va dove non è mai stato il lavoro di nessuno.
- Se il fornitore cade per mezz'ora, cadete per mezz'ora. Non c'è un secondo percorso e nessuno ha mai verificato se potrebbe esserci.
- Cambiare modello sembra un progetto da sei settimane, quindi non si fa — e la decisione di un anno e mezzo fa resta congelata per paura, non per criterio.
Il costo di lasciare tutto com’è
Hai un fornitore critico il cui prodotto cambia sotto i tuoi piedi e nessun modo di misurarne l'effetto. Si paga in tre modi. Primo, la sorpresa: arriva una data di ritiro e la migrazione si fa di corsa, senza banco di prova, con il rischio distribuito sui clienti. Secondo, la deriva silenziosa, che è peggio: il sistema non dà errore, semplicemente inizia a rispondere un po' diverso — più lungo, con un altro formato, rifiutando cose che prima accettava — e siccome nessuno misura, lo si scopre da un reclamo. Terzo, il costo opportunità: siccome cambiare fa paura, non si cambia, e si continua a pagare un modello caro per attività a basso valore e a tenersi un modello peggiore di quello già disponibile.
La soluzione
Trasformiamo il cambio di modello in un'operazione misurata, reversibile e noiosa
- 1Prima l'inventario, che quasi nessuno ha: quali vostri sistemi chiamano quale modello e in quale versione esatta, che attività fa ogni chiamata e cosa si romperebbe se quella versione sparisse domani. Senza questo, ogni preavviso di ritiro è un'emergenza invece di un'attività pianificata.
- 2Costruiamo il tuo banco di casi d'oro: un insieme congelato di casi reali della tua operatività — quelli normali, quelli strani e quelli andati male — con il risultato che consideri corretto. È l'asset che fa passare il confronto tra modelli dall'impressione alla misura, ed è tuo anche se domani ci licenzi.
- 3Definiamo l'instradamento per attività: quali chiamate hanno davvero bisogno del modello buono e quali si risolvono con uno più economico o più veloce senza peggiorare il risultato. La decisione si prende con il banco davanti, non con l'intuizione di chi parla più forte.
- 4Montiamo la procedura di migrazione: candidato contro il banco, confronto affiancato sul vostro lavoro reale, rilascio graduale su una parte del traffico, confronto delle uscite in diretta e solo dopo il cambio completo. Con il ritorno indietro preparato e provato prima di iniziare, non improvvisato nel giorno storto.
- 5Installiamo il rilevamento della deriva. I fornitori aggiornano anche senza cambiare il nome della versione, e questo non dà errore: cambia il formato, cambia la lunghezza, si allenta l'aderenza al JSON e si sposta la linea in cui il modello dice di no. Il banco gira periodicamente perché quella deriva la rilevi un avviso e non un cliente.
- 6E lo mettiamo a calendario. Le date di ritiro dei tuoi fornitori arrivano come avvisi con margine — non come una mail che qualcuno ha archiviato — e la decisione di modello si rivede con una cadenza concordata, con il costo per attività e la qualità misurata sul tavolo.
Cosa cambia
Quello che smetti di perdere
Anthropic si impegna a un preavviso minimo di 60 giorni per ritirare i modelli pubblici e OpenAI a un minimo di sei mesi per i modelli in disponibilità generale. Quel preavviso serve solo se qualcuno sa quali vostri sistemi dipendono dalla versione interessata: l'inventario trasforma una data in un piano.
Politiche pubbliche di deprecazione dei fornitori (Anthropic, OpenAI), consultate 2026-08
Cambiare modello smette di essere un salto nel vuoto: il candidato si misura sui tuoi casi, con la tua definizione di corretto, prima di toccare un solo cliente.
Meccanismo
La deriva silenziosa smette di scoprirsi da un reclamo. Quando il fornitore aggiorna sotto di te, le uscite cambiano senza dare errore — formato, lunghezza, aderenza al JSON, soglia di rifiuto — e il banco periodico ne fa un avviso.
Meccanismo
Il costo scende per progetto e non per taglio: quando ogni attività va al modello che le serve, il risparmio viene dal non pagare più criterio dove bastava smistare — non dall'usare IA peggiore.
Meccanismo
Cosa misuriamo: sistemi con versione di modello inventariata, qualità del candidato contro il banco di casi d'oro, scostamenti rilevati dalle esecuzioni periodiche, costo per attività prima e dopo l'instradamento, tempo di ritorno indietro provato e giorni di margine su ogni data di ritiro annunciata.
Cosa misuriamo
Scheda tecnica
- Lavoro che elimina
- che la decisione su quale modello usa la tua azienda si congeli per paura e che ogni ritiro, aggiornamento o cambio di prezzo del fornitore si risolva di corsa, senza misurare e con i clienti in mezzo
- Implementazione tipica
- 4–8 settimane
- Ingresso
- i tuoi sistemi di IA in produzione, le versioni di modello che chiamano oggi e casi reali della tua operatività — compresi quelli andati male
- Uscita
- un inventario vivo di cosa dipende da quale versione, un banco di casi d'oro tuo, instradamento per attività, una procedura di migrazione con ritorno indietro provato e avvisi di deriva e di date di ritiro
- Compatibile con
- OpenAIAnthropicGoogle Vertex AIAzure OpenAIAmazon BedrockMistralLangSmithLangfuseBraintrust
- Può collegarsi con
- I tuoi log di produzione, da cui vengono i casi del bancoIl tuo livello di valutazione e la gestione dei prompt, se già esistonoIl tuo gateway o router di modelli, perché cambiare sia configurazioneIl tuo cruscotto dei costi per modello e per attivitàIl tuo processo di change e il calendario di reperibilità
- Cosa misuriamo
- % di sistemi con versione di modello inventariata e responsabile assegnatoqualità del candidato contro il banco di casi d'oroscostamenti di comportamento rilevati dalle esecuzioni periodichecosto per attività prima e dopo l'instradamentotempo di ritorno indietro provato in simulazionegiorni di margine su ogni data di ritiro annunciata
- Adatto per
- aziende con IA già in produzione e dipendenza reale da uno o più fornitori di modello — CIO, CTO o responsabile IA — che hanno bisogno che la decisione di modello sia rivedibile, misurabile e reversibile invece che un impegno alla cieca
- Non adatto per
- chi è ancora in pilota e non ha traffico reale — lì non c'è banco da costruire, prima bisogna arrivare in produzione — né chi vuole che gli diciamo qual è il modello migliore sul mercato: dipende dal tuo lavoro, ed è proprio per questo che si misura invece di opinare
Domande frequenti
E continuiamo a dirlo: cambiare modello perché qualcosa non rende è quasi sempre spostare il problema, perché il collo di bottiglia di solito è un processo mal definito o un dato sporco. Questo è l'opposto. Qui non si cambia modello per aggiustare qualcosa: si cambia perché il fornitore ritira la versione che usi, perché l'ha aggiornata sotto di te, perché esce un'opzione che fa lo stesso a una frazione del costo, o perché la decisione presa un anno e mezzo fa non è quella che prenderesti oggi. Sono cambiamenti che arriveranno che tu lo voglia o no. Quello che montiamo è la capacità di assorbirli senza drammi e con evidenze — e, per inciso, ciò che ti dice quando il modello non è il problema, che è esattamente il caso in cui conviene non toccarlo.
È un insieme congelato di casi reali della tua operatività con il risultato che tu consideri corretto: i casi normali, quelli strani, quelli ambigui e soprattutto quelli che a suo tempo sono andati male. Di solito bastano decine o poche centinaia di casi ben scelti, non servono migliaia. Conta più di tutto perché è l'unica cosa che trasforma «questo modello sembra migliore» in un numero confrontabile: passi il candidato sullo stesso insieme del modello attuale e vedi esattamente dove migliora e dove peggiora, sul tuo lavoro e non su un esame generico. Ed è la cosa più preziosa che ti porti via dal progetto, perché non dipende da nessun fornitore: varrà uguale l'anno prossimo con modelli che oggi non esistono. Per questo lo costruiamo con te e resta a casa tua.
Perché misurano un'altra cosa. Un benchmark pubblico ti dice come si comporta un modello in un esame standardizzato che non assomiglia alla tua operatività: né i tuoi documenti, né il tuo lessico, né i tuoi casi limite, né la tua definizione di corretto. È informazione utile per scartare candidati palesemente più deboli e per capire dove va il mercato, e per questo li usiamo. Ma la decisione non può prenderla una classifica: un modello può segnare meglio in pubblico e rendere peggio su un'attività concreta con documenti concreti, e capita anche il contrario. Il fornitore, per giunta, ha un interesse evidente nel confronto. Il tuo banco di casi no.
Eseguendo il banco periodicamente sullo stesso endpoint e confrontando con la linea base. È l'unico metodo affidabile, perché un aggiornamento silenzioso non produce un errore: produce una deriva. Il formato delle chiamate agli strumenti si sposta un po', l'aderenza al JSON si allenta, le risposte si allungano o si accorciano, e la frontiera di ciò che il modello rifiuta si muove. Niente di tutto questo rompe l'integrazione, quindi il monitoraggio classico — disponibilità, latenza, tasso di errore — dà tutto verde mentre la qualità scivola. Con l'esecuzione periodica del banco quella deriva esce come un avviso con casi concreti davanti, e allora la conversazione è «questo è cambiato martedì e sono questi i casi» invece di «mi pare che ultimamente risponda strano».
Meno di qualunque alternativa, ed è facile da verificare: i deliverable sono tuoi e non dipendono da noi. L'inventario delle versioni, il banco di casi d'oro, le regole di instradamento, la procedura di migrazione e il calendario dei ritiri restano documentati e nei tuoi sistemi. Montiamo sul tuo stack e sugli strumenti di valutazione che già hai; se non ne hai, scegliamo con voi e vi spieghiamo il perché, senza uno strato proprietario da cui poi bisogna uscire. Il modo normale di finire è che il tuo team lo operi — questo è formare il team, che è un servizio diverso — oppure che lo operiamo noi mentre quella capacità matura. Entrambe le uscite sono scritte dall'inizio.
Lo montiamo nella tua azienda?
Hai individuato il problema. Noi consegniamo la soluzione e la lasciamo misurata.