Una rilevazione condotta da VentureBeat Intelligence nell’ottobre 2026 sulle organizzazioni con almeno 100 dipendenti evidenzia le difficoltà tecniche associate alla sostituzione dei modelli di intelligenza artificiale all’interno delle applicazioni aziendali già operative. Il 47% degli intervistati ha dichiarato che la propria organizzazione aveva sostituito almeno un modello utilizzato in un sistema AI di produzione nei dodici mesi precedenti, mantenendo sostanzialmente invariata l’applicazione circostante. Tra coloro che avevano effettuato una sostituzione, il 70% ha riferito che l’operazione aveva richiesto alcune settimane o più di lavoro ingegneristico aggiuntivo rispetto alla semplice modifica del modello, mentre il 36% ha indicato una durata superiore a un mese. Soltanto il 13% ha descritto il cambiamento come un intervento quasi esclusivamente configurativo. I risultati operativi sono stati altrettanto differenziati: il 55% delle organizzazioni che avevano effettuato la migrazione ha ottenuto prestazioni equivalenti o superiori rispetto alla soluzione precedente, mentre il restante 45% ha registrato un peggioramento che ha richiesto interventi sull’applicazione oppure il ritorno al modello originario. Questa ultima percentuale non presenta una variazione statisticamente significativa rispetto alla rilevazione di settembre. Il campione comprende rispondenti che lavorano su sistemi AI o li seguono dal punto di vista aziendale e include una quota del 28% di consulenti che hanno risposto facendo riferimento al cliente presso il quale trascorrevano la maggior parte del tempo. Il confronto tra settembre e ottobre richiede cautela: applicando criteri di ammissibilità comparabili, a settembre il 49% aveva segnalato migrazioni di almeno alcune settimane e il 12% interventi superiori a un mese, ma la composizione differente dei rispondenti non consente di attribuire con certezza gli aumenti a un effettivo peggioramento delle condizioni tecniche. Escludendo gli intervistati orientati maggiormente alla prospettiva aziendale, nell’indagine di ottobre le due percentuali risultano rispettivamente del 66% e del 29%.
La disponibilità di gateway e sistemi di routing consente di modificare rapidamente il modello destinatario di una richiesta API, ma non elimina le dipendenze applicative costruite intorno al modello precedente. Un gateway costituisce il livello di intermediazione tra le applicazioni e i provider di inferenza, mentre un router determina quale modello debba elaborare una richiesta. Adobe, ad esempio, utilizza un modello meno costoso per selezionare il contesto pertinente nelle attività del proprio agente di marketing, trasferendo successivamente il prompt a un modello di dimensioni maggiori. Tetrate propone invece Auto Mode, una soluzione che seleziona automaticamente il modello per ciascuna richiesta. Secondo il cofondatore e CTO Varun Talwar, alcune aziende utilizzatrici hanno progressivamente ridotto la necessità di specificare manualmente il modello, ma l’adozione automatica richiede comunque verifiche sulla qualità delle risposte e sui costi effettivi. I clienti iniziano generalmente da un singolo team, estendendo il routing automatico soltanto quando i risultati risultano almeno equivalenti a quelli precedenti e la spesa diminuisce. Anche Upwork distingue gli impieghi sperimentali dalle applicazioni in produzione: attività ripetitive e ben definite, come l’abbinamento tra professionisti e opportunità lavorative, possono essere affidate a modelli più piccoli e specializzati, mentre i compiti aperti vengono indirizzati verso modelli più grandi. Nel frattempo, la riduzione dei prezzi dei modelli continua a incentivare la valutazione di alternative: il 9 novembre Anthropic ha introdotto Claude Fable 5.2 con tariffe di 8 dollari per milione di token in ingresso e 40 dollari per milione di token in uscita, inferiori del 20% rispetto alla versione sostituita. L’indagine di ottobre si era tuttavia conclusa prima di questo aggiornamento e non aveva rilevato le motivazioni specifiche delle migrazioni né gli eventuali risparmi ottenuti.
Una delle principali difficoltà riguarda la relazione tra il modello e l’infrastruttura applicativa che ne controlla l’esecuzione. I sistemi aziendali possono contenere prompt, strumenti, procedure di verifica e configurazioni sviluppati specificamente per le caratteristiche del modello iniziale. La sostituzione può modificare il modo in cui vengono interpretate le istruzioni, selezionati gli strumenti o prodotti i risultati, richiedendo adattamenti anche quando le interfacce API rimangono compatibili. PayPal ha affrontato questo problema nello sviluppo del proprio agente per il commercio elettronico, utilizzato per assistere gli utenti nella ricerca e nell’acquisto di prodotti. Durante le attività interne di ricerca e testing, prima dell’esposizione ai clienti, l’azienda ha provato un modello più piccolo e rapido, sottoponendolo a fine-tuning per migliorare l’accuratezza. L’addestramento aggiuntivo ha prodotto miglioramenti, ma non sufficienti rispetto agli obiettivi prefissati. PayPal ha quindi ridimensionato il ricorso al fine-tuning, considerando la necessità di ripetere l’addestramento specializzato ogni volta che viene introdotto un modello differente, e ha iniziato a bilanciare modelli utilizzabili senza personalizzazione, interventi di fine-tuning e allocazione delle risorse di calcolo per ottimizzare accuratezza, velocità, costo e controllo. Box ha riscontrato una problematica collegata alla configurazione dell’harness, ossia l’insieme di codice che circonda il modello, gli fornisce istruzioni e stabilisce quali strumenti possa richiamare. Secondo il CTO Ben Kus, un modello più recente può produrre risultati inferiori semplicemente perché il software circostante è stato ottimizzato per il comportamento di quello precedente. Per questo motivo Box valuta il modello e il relativo harness come una combinazione operativa, anziché considerare le prestazioni del modello isolatamente.
L’influenza dell’harness emerge anche dai benchmark sugli agenti di programmazione. Nella valutazione FrontierHarness Eval di Runta, il modello Kimi K3 di Moonshot AI ha completato correttamente il 63,3% delle attività sia nella configurazione Claude Code sia in una configurazione DeepSeek Harness, ma con costi mediani per attività completata rispettivamente di 18,34 e 3,28 dollari. La differenza supera un fattore cinque pur mantenendo la stessa percentuale di successo. Un’altra configurazione, Exo Harness, ha raggiunto un costo mediano di 1,05 dollari per attività completata, secondo i risultati pubblicati. La sperimentazione ha utilizzato nove harness di programmazione, distribuiti in dodici configurazioni, su un insieme di trenta attività: si tratta quindi di una base di test limitata, utile per osservare differenze tra ambienti esecutivi ma non sufficiente per stabilire una graduatoria generale delle soluzioni. Micah Hill-Smith, cofondatore di Artificial Analysis, ha inoltre osservato che l’influenza dell’harness tende a essere meno marcata nei modelli di maggiori dimensioni, mentre i modelli più piccoli possono registrare variazioni di 20, 30 o 40 punti nei benchmark di coding agent in funzione della compatibilità con lo stile dell’ambiente di esecuzione. L’utilizzo di un modello più economico può quindi richiedere un maggiore investimento nella configurazione e nell’ottimizzazione dell’infrastruttura software che lo accompagna.
La valutazione economica richiede inoltre di distinguere il costo della singola esecuzione da quello necessario per ottenere un risultato corretto. Sudhanshu Bist, vicepresidente dell’ingegneria delle infrastrutture di piattaforma di Upwork, ha illustrato un esempio ipotetico nel quale un modello di piccole dimensioni costa 0,10 dollari per esecuzione ma completa correttamente soltanto il 20% delle attività. Supponendo di ripetere ogni tentativo fallito fino al successo, il costo medio per risultato utile raggiunge circa 0,50 dollari. Un modello più grande, con costo di 0,30 dollari per esecuzione e probabilità di successo del 90%, richiede invece circa 0,33 dollari per risultato corretto. Il secondo modello, pur costando tre volte di più per singola chiamata, risulta economicamente più conveniente a parità di risultato finale. Il gateway di Upwork rileva le spese sostenute dai diversi team per le chiamate ai modelli, ma non comprende necessariamente i costi delle GPU utilizzate per addestramento e fine-tuning, il tempo impiegato dal personale per correggere gli errori o le risorse di elaborazione consumate dagli strumenti richiamati dagli agenti. Anche Tetrate e WEKA hanno richiamato l’attenzione sulla necessità di misurare il costo per risultato effettivamente ottenuto anziché considerare soltanto la tariffazione per token. T-Mobile applica un criterio differente per gli agenti destinati all’assistenza clienti, privilegiando modelli avanzati in grado di produrre risposte rapide e accurate anche a fronte di un costo superiore, senza assumere la minimizzazione della spesa come obiettivo principale.
Le organizzazioni che hanno sviluppato sistemi di valutazione specifici riescono a ridurre parte del lavoro richiesto dalle migrazioni. Uber, ad esempio, utilizza benchmark costruiti sulle modifiche storiche del codice per valutare i modelli impiegati nella revisione automatizzata del software e ha successivamente realizzato un insieme di test basato su sessioni reali di programmazione per il proprio agente di coding in background. La disponibilità di risultati confrontabili permette di verificare rapidamente modelli alternativi e, secondo l’ingegnere Uday Kiran Medisetty, può consentire di sostituire in pochi giorni il modello utilizzato da un agente gestito centralmente. Uber ha ottenuto una riduzione del 90% del costo per operazione di pulizia automatizzata del codice, relativa alla rimozione di feature flag obsolete, selezionando il modello attraverso prove comparative. L’azienda monitora inoltre la quota di richieste AI trasferibili da un modello all’altro, distinguendo gli agenti gestiti centralmente dalle sessioni avviate manualmente dagli sviluppatori mediante strumenti come Claude Code, per le quali una migrazione può richiedere cambiamenti nelle modalità di lavoro degli utenti.
PayPal ha adottato un approccio basato sulla separazione tra conoscenza aziendale e modello linguistico. Il suo assistente interno per l’analisi dei dati utilizza un livello informativo indipendente che contiene definizioni aziendali, query approvate e procedure operative per lo svolgimento delle analisi. L’introduzione di questo livello ha portato l’accuratezza delle risposte relative alle informazioni aziendali dal 43% al 95% mantenendo invariato il modello utilizzato. La separazione consente di aggiornare il modello senza dover ricostruire le definizioni e le regole aziendali ogni volta che viene sostituito. Un’impostazione analoga viene utilizzata da clienti Databricks, che sviluppano inizialmente applicazioni con modelli frontier e indici testuali semplici, salvano le risposte ottenute come insieme di valutazione e successivamente provano modelli open-weight meno costosi, integrando funzioni di ricerca vettoriale per compensarne le differenze prestazionali. Box valuta le modifiche considerando tre indicatori, accuratezza, costo e velocità, misurati su richieste rappresentative delle attività effettivamente svolte dagli utenti. In questo processo, la costruzione di dataset di valutazione affidabili costituisce spesso una delle operazioni più impegnative.
T-Mobile esegue verifiche comparative su chiamate reali, facendo funzionare temporaneamente la versione precedente e quella modificata dei propri agenti di assistenza clienti prima di estendere la nuova configurazione. La società analizza inoltre tutte le sessioni vocali e testuali attraverso un modello più piccolo incaricato di individuare risposte potenzialmente scorrette, mantenendo un controllo successivo all’introduzione in produzione per rilevare situazioni non rappresentate nei test preliminari. Alle verifiche tecniche si aggiungono le procedure di governo interno: JPMorgan Chase, ad esempio, richiede che ogni nuova versione di Claude superi un processo di approvazione aziendale prima di essere resa disponibile ai dipendenti. Anche la disponibilità di modelli tecnicamente compatibili non elimina quindi i passaggi necessari per la validazione organizzativa e la conformità alle regole interne. William Allen, responsabile di prodotto Snowflake per gli agenti CoCo e CoWork, ha inoltre evidenziato la necessità di rivalutare periodicamente le scelte architetturali, evitando che gli investimenti già sostenuti impediscano di prendere in considerazione soluzioni tecnologiche più recenti. I risultati raccolti nell’ottobre 2026 mostrano che la sostituzione di un modello AI in produzione dipende dall’interazione tra qualità delle risposte, harness, conoscenza aziendale, procedure di testing, costi operativi e processi autorizzativi. La possibilità di cambiare rapidamente il destinatario di una chiamata API rappresenta soltanto una componente della migrazione, mentre la continuità delle prestazioni richiede una verifica dell’intero sistema applicativo nel quale il modello viene utilizzato.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)