Costruire o comprare non è una domanda binaria. Le strade sono cinque: l’API di un modello di frontiera, un modello a pesi aperti su un endpoint gestito, un modello a pesi aperti messo a punto, un modello addestrato da zero e l’opzione che quasi tutti dimenticano — non risolverlo affatto con un LLM. A decidere fra queste sono solo tre lenti: il costo al volume previsto, il tetto di capacità che la mansione richiede e l’esposizione normativa. Per la maggior parte delle organizzazioni la risposta pratica è iniziare comprando, costruire uno strato di astrazione dal primo giorno e riaprire la questione del build soltanto quando esistono dati d’uso reali.
Cinque strade, non due
L’impostazione consueta del dibattito produce decisioni scadenti perché nasconde tre opzioni intermedie, ed è proprio lì che si concentra il valore.
| Strada | Che cosa significa in pratica | Quando è quella giusta |
|---|---|---|
| API di modello di frontiera | Chiamate a un fornitore commerciale, nessuna infrastruttura propria | Mansione ampia, volume moderato, team senza competenze ML |
| Modello a pesi aperti gestito | Pesi aperti sull’endpoint di un fornitore di infrastruttura | Necessità di controllo delle versioni e di costo prevedibile |
| Modello aperto messo a punto | Addestramento aggiuntivo sui vostri dati per una mansione ristretta | Mansione ristretta e ripetitiva, ben oltre i diecimila esempi etichettati |
| Modello addestrato da zero | Addestramento completo, team di ricerca dedicato | Quasi mai. Solo se il modello è esso stesso il prodotto |
| Nessun LLM | Regole, ricerca, un modello statistico classico | Quando la mansione è deterministica e interamente specificabile |
Le tre lenti che decidono
Il costo al volume previsto. Non il volume di oggi, ma quello che state pianificando fra un anno. Il calcolo rapido: unità di lavoro al mese moltiplicate per il costo unitario sulla strada del comprare, contro il costo fisso di ingegneria e infrastruttura sulla strada del costruire. Il metodo lo esponiamo nel nostro articolo sul costo totale di possesso di una funzionalità LLM.
Il tetto di capacità. Se la mansione richiede ragionamento a più passaggi, una lingua rara o conoscenza generale del mondo, un piccolo modello messo a punto non ci arriverà, per quanto lo si addestri. Se la mansione è una classificazione in sette categorie, un modello di frontiera è spreco.
L’esposizione normativa. Quando i dati devono restare dentro una giurisdizione o una rete chiusa, le strade del comprare si restringono immediatamente. È l’unica lente capace di eliminare del tutto una strada, ed è per questo che va verificata per prima e non per ultima. Il rapporto fra tipi di dati e permessi è esposto nel nostro articolo sulla classificazione dei dati aziendali prima che raggiungano un LLM.
Quando la messa a punto conviene davvero
La messa a punto è la strada che quasi tutti i team scelgono troppo presto. Diventa conveniente quando tutte le condizioni seguenti valgono insieme, non alcune di esse:
- La mansione è ristretta, ripetitiva e ben definita, e non cambia ogni trimestre.
- Disponete di molte migliaia di esempi etichettati di buona qualità, provenienti dalla vostra produzione e non da un corpus generico.
- Il costo o la latenza dell’API è realmente diventato il vincolo stringente, non una preoccupazione teorica.
- Qualcuno nel team manterrà il modello, misurerà la deriva e riaddestrerà quando la distribuzione si sposta.
Se manca anche una sola condizione, la messa a punto aggiunge un costo di manutenzione permanente senza restituirlo. Lo schema che funziona è l’opposto: restare su un’API, raccogliere sistematicamente i dati di produzione e tornare alla domanda dopo circa novanta giorni di uso reale, quando si hanno numeri invece di stime.
Lo strato di astrazione: l’unica decisione da prendere subito
Non dovete scegliere una strada il primo giorno, ma dovete decidere di non vincolarvi. Un sottile strato di astrazione fra il vostro codice e il fornitore del modello è l’assicurazione più economica del progetto:
| Che cosa contiene lo strato | Perché conta |
|---|---|
| Un’interfaccia unica per le chiamate al modello | Cambiare fornitore diventa la modifica di un file, non una riscrittura |
| Instradamento per tipo di mansione | Permette di mandare le mansioni economiche a un modello economico senza toccare la logica |
| Logging uniforme di input, output e costo | Senza di esso non ci sono dati su cui decidere fra tre mesi |
| Validazione dell’output | Permette di sostituire il modello senza cambiare il contratto di output |
I costi che non stanno nel foglio di calcolo
Un confronto costruire/comprare fatto in un foglio di calcolo tende a pesare il prezzo di licenza contro il costo di calcolo e a perdere tre costi che decidono davvero l’esito: il tempo di arrivo sul mercato, il costo opportunità di un team che costruisce invece di vendere e la manutenzione lungo gli anni. Le pubblicazioni fino al 2026 riferiscono che le organizzazioni che hanno costruito capacità IA su misura senza prima validarla contro un’opzione pronta all’uso hanno perso tempo considerevole prima di scoprire che la direzione era sbagliata.
Dall’altro lato, comprare per sempre crea dipendenza da un unico fornitore e toglie all’organizzazione la capacità di migliorare ciò che la rende distintiva. L’equilibrio pratico è quasi sempre ibrido: comprare la base, costruire sopra lo strato in cui vive il vantaggio competitivo — i dati, il recupero, le regole di business e l’interfaccia — e non il modello stesso.
La sequenza consigliata
- Definire l’unità di lavoro e il criterio di successo prima di scegliere qualsiasi tecnologia.
- Verificare la lente normativa. Se elimina delle strade, tutto il resto è irrilevante.
- Fare una prova di concetto su un’opzione pronta all’uso anche se siete convinti che costruirete. Costa poco e crea un riferimento.
- Costruire lo strato di astrazione e il logging il primo giorno.
- Tornare alla decisione dopo novanta giorni con costo unitario reale, tasso di successo e distribuzione delle mansioni.
Questo accompagnamento, dalla definizione dell’unità di lavoro fino alla scelta della strada, rientra esattamente nelle nostre aree di competenza.
Domande frequenti
Qual è la differenza pratica fra messa a punto e recupero da una base di conoscenza?
Il recupero aggiunge informazione aggiornata nel prompt al momento dell’esecuzione; la messa a punto cambia il comportamento del modello stesso. Per una conoscenza aziendale che cambia, il recupero è quasi sempre la scelta corretta. La messa a punto è adatta a cambiamenti di stile, di formato o a una mansione ristretta, non all’iniezione di fatti.
Quanti esempi etichettati richiede davvero la messa a punto?
L’ordine di grandezza accettato è di molte migliaia di esempi di qualità per una mansione ristretta. Il fattore determinante non è la quantità ma la qualità e la rappresentatività: mille esempi puliti dalla vostra produzione valgono più di decine di migliaia di esempi sintetici.
Uno strato di astrazione non aggiunge complessità inutile?
Uno strato sottile che si limita a unificare la chiamata, il logging e la validazione costa pochi giorni di sviluppo. Il costo di non averlo si presenta il giorno in cui dovete cambiare fornitore, instradare le mansioni economiche a un modello economico o spiegare da dove viene una fattura.
Quando ha senso addestrare un modello da zero?
Quasi mai, a meno che il modello stesso non sia il prodotto che vendete, o che deteniate dati proprietari di dimensione unica in un dominio che i modelli generali non coprono. Per la maggior parte delle organizzazioni il costo supera il beneficio di ordini di grandezza.
Come si capisce che è ora di passare dal comprare al costruire?
Quando valgono insieme tre condizioni: il costo mensile del comprare ha superato il costo annuo di ingegneria e manutenzione dell’alternativa, la mansione si è stabilizzata e ha smesso di cambiare, e avete dati di produzione sufficienti per addestrare e misurare. Due su tre non bastano.