Scelta dei modelli IA: costi, controllo e continuità del prodotto.

Qual è il modello meno costoso che soddisfa in modo affidabile i requisiti di questo compito?

Prima chiarisco qualità minima, tempo di risposta, volumi, privacy e continuità. Il provider è una delle scelte successive. Un modello eccellente in generale può essere inadatto a un'attività specifica; uno più piccolo può bastare, se lo dimostrano prove rappresentative.

La valutazione organizzativa ed economica precede questa scelta. La qualità tecnica delle risposte richiede invece un lavoro distinto di sviluppo e verifica.

I prerequisiti: fattibilità di un progetto IA →

Open-weight significa che i pesi del modello sono disponibili. Non implica automaticamente una licenza open source, libertà d'uso senza condizioni o convenienza economica. Un modello open-weight può anche essere consumato tramite un servizio esterno.

Epoch AI, nell'analisi del maggio 2026, rileva dal gennaio dello stesso anno un ritardo medio di circa quattro mesi dei migliori modelli open-weight rispetto alla frontiera closed sul proprio indice ECI. È un risultato del periodo e della misura scelta, non equivalenza su ogni compito.

Il confronto cyber di Anthropic del settembre 2026 mostra un altro caso circoscritto: su 41 vulnerabilità V8, GLM-5.3 costruisce exploit funzionanti in circa il 12% dei tentativi, contro il 14% di Mythos Preview. Questo non confronta la qualità generale dei modelli.

La mia conclusione architetturale è rendere possibile una migrazione quando il vantaggio di un modello cambia, commisurando questo investimento al rischio del progetto.

Il prezzo dei token è una voce del conto. Vanno aggiunti preparazione dei dati, infrastruttura, tentativi ripetuti, verifiche umane, monitoraggio e manutenzione. Il self-hosting richiede GPU e competenze operative; con carichi bassi o irregolari un'API può risultare più conveniente.

Nel sondaggio McKinsey del maggio 2026, il 93% dei 75 rispondenti qualificati riportava uno sforamento del budget IA. Il campione non rappresenta tutte le aziende, ma richiama l'attenzione sui costi dell'adozione su scala.

Un flusso può instradare attività diverse verso modelli diversi: maggiore capacità dove il problema lo richiede, modelli più economici o specializzati per passaggi ben definiti. Ogni percorso deve rispettare i vincoli sui dati e superare le stesse verifiche di qualità.

Con pesi, runtime e hardware sotto controllo, una configurazione può essere mantenuta finché soddisfa i requisiti. Non occorre cambiare modello a ogni nuova uscita; restano necessari aggiornamenti di sicurezza e manutenzione dei componenti.

Un'API esterna ha un altro ciclo di vita: OpenAI e Anthropic documentano deprecazioni e ritiri. Occorre distinguere una migrazione obbligata, perché il servizio scompare, da una migrazione conveniente, perché un'alternativa migliora qualità, costi o prestazioni.

Prevedo perciò il costo di rivalutare il sistema e un piano di continuità. L'indipendenza dal modello è un investimento: il suo valore cresce con la probabilità e il costo di doverlo sostituire.

Organizzerei il sistema in parti con responsabilità distinte:

1. 01Applicazione e dominio

   Regole del prodotto, permessi e dati di cui l'applicazione resta responsabile.

2. 02Flusso e strumenti

   Passaggi, controlli, recupero delle informazioni e azioni consentite.

3. 03Adattatore del modello

   Formati, istruzioni, output strutturati e chiamate agli strumenti specifici del provider.

4. 04Modello e ambiente di esecuzione

   Il servizio esterno o il modello ospitato su risorse controllate.

È una proposta di progettazione, non un requisito universale. Gli adattatori riducono le dipendenze, ma i modelli differiscono nel comportamento: la migrazione richiede spesso modifiche a prompt, strumenti e gestione del contesto.

La possibilità di cambiare modello diventa credibile con una suite di valutazione stabile. Confronto modello attuale e candidato sulle richieste reali e sui casi limite, mantenendo criteri di accettazione espliciti.

• Correttezza, aderenza alle fonti e regressioni rispetto al comportamento richiesto.
• Successo dell'intero compito e delle chiamate agli strumenti.
• Latenza, concorrenza, costo per operazione completata e consumo di risorse.
• Errori, rifiuti, recupero dai guasti e rispetto dei vincoli di sicurezza.

Le misure vanno ripetute dopo modifiche a modello, dati o flusso. Un benchmark pubblico serve a selezionare candidati; non sostituisce la verifica dell'applicazione.

Un esempio di flusso applicativo verificabile →

Sicurezza delle applicazioni IA →

Nel mio giudizio, anche la non adozione merita una valutazione: un concorrente potrebbe automatizzare un'attività o sviluppare competenze prima di noi. Questo è uno scenario strategico da esaminare, non una previsione valida per tutte le imprese.

Propongo una prudenza attiva: sperimentare su un perimetro limitato, misurare valore e costi, mantenere competenze e decidere su evidenze proprie. Un progetto può essere rinviato o scartato se il beneficio non giustifica investimento e rischi.

Le fonti sostengono i fatti e i criteri di valutazione. La struttura architetturale e il confronto tra adozione e attesa sono mie proposte metodologiche; non sono risultati dimostrati per ogni progetto.

• Epoch AI — confronto open/closed (si apre in una nuova scheda): indice aggregato e periodo osservato; non confronto del singolo caso d’uso.
• Anthropic — capacità cyber di GLM-5.3 (si apre in una nuova scheda): test specifici di exploit, distinti dalla qualità generale del modello.
• McKinsey — costi dell’IA nelle aziende (si apre in una nuova scheda): sondaggio e criteri per scelta dei modelli e instradamento dei compiti.
• OpenAI — deprecazioni API (si apre in una nuova scheda): annunci di ritiro e migrazione dei servizi.
• Anthropic — ciclo di vita dei modelli (si apre in una nuova scheda): stati e ritiro dei modelli disponibili via API.
• Microsoft — valutazioni RAG (si apre in una nuova scheda): esempio di misure su recupero delle informazioni e qualità delle risposte.