La tesi in una frase: la scelta tra IA open source e API chiusa quasi mai si gioca dove la gente crede. Non è una battaglia di principi tra «libertà» e «lock-in». È una decisione di ingegneria con due orologi —costo su scala e sensibilità del dato— e per la stragrande maggioranza delle aziende la risposta giusta il primo giorno non è quella ideologica. Questo articolo parla di quando conta davvero e di quando, onestamente, non cambia niente.
IA open source vs API chiusa in azienda: i più pongono la domanda al contrario
La conversazione arriva quasi sempre viziata. Qualcuno del team ha letto che Llama, Mistral o DeepSeek sono modelli aperti, che puoi scaricarli e farli girare «a casa tua», e all’improvviso la domanda smette di essere «di cosa ha bisogno il mio business?» per diventare «siamo di quelli che dipendono da OpenAI o di quelli che si auto-ospitano?». Questa non è una decisione tecnica: è identità. E le decisioni di identità si difendono con orgoglio, non con i dati.
La domanda utile è molto più noiosa: per il problema concreto che vuoi risolvere, cosa ti dà ciascuna opzione e cosa ti costa ciascuna —in denaro, in tempo del tuo team, in rischio? Posta così, la bandiera cade da sola e appare ciò che davvero decide: il volume a cui chiamerai il modello e quanto è delicato il dato che gli darai.
Cosa ti dà davvero ciascuna opzione (senza la bandiera)
API chiusa: velocità e zero manutenzione
Un’API chiusa —OpenAI, Anthropic, Google— è una chiamata di rete. Non provisioni GPU, non fai patch ai driver, non ti preoccupi che il modello cada alle tre di notte. Paghi a token, parti in minuti, e il fornitore migliora il modello sotto senza che tu tocchi niente. In cambio, il dato esce dal tuo perimetro verso il suo (con contratto di mezzo), il costo unitario lo fissa un altro e sei legato alla sua roadmap e alla sua politica di prezzo. Compri velocità e tranquillità; affitti il controllo.
Open source: controllo e costo su scala, in cambio di idraulica
Un modello aperto che fai girare tu —nel tuo cloud o sul tuo hardware— ti dà il contrario: il dato non si muove da dove dici tu, il costo per milione di token ad alto volume può crollare, e nessuno ti deprezza il modello a sorpresa. Il prezzo di questo è che ora l’infrastruttura è tua: servire il modello, scalarlo, monitorarlo, aggiornarlo e rispondere quando si rompe è lavoro del tuo team, per sempre. Non è più «economico»: stai scambiando una fattura del fornitore con un libro paga di ingegneria. Per chi ha volume e personale, conviene; per chi non ce l’ha, è un pozzo.
| Asse | API chiusa | Open source (auto-ospitato) |
|---|---|---|
| Avvio | Minuti | Settimane di setup |
| Dove vive il dato | Presso il fornitore (con contratto) | Dove decidi tu |
| Costo | A token, lo fissa il fornitore | Fisso (infra + team), economico su scala |
| Manutenzione | Zero, migliora da solo | Tua, per sempre |
| Controllo / lock-in | Poco controllo, alto lock-in | Alto controllo, senza lock-in |
| A chi rende | Quasi tutte all’inizio | Alto volume o dato sensibile |
Perché per il 90% delle PMI la risposta è partire con un’API chiusa
Non è pigrizia né pragmatismo codardo: è aritmetica. La maggior parte dei progetti di IA di una PMI muore non per aver scelto il modello sbagliato, ma per non essere mai arrivati in produzione. E tutto ciò che allunga la strada verso la produzione alza la probabilità di morte. Auto-ospitare un modello aperto aggiunge, in partenza, un intero progetto di infrastruttura prima ancora di aver validato che l’idea funzioni. È ottimizzare il costo per token di qualcosa che non sai ancora se userai.
- Il tuo volume è basso all’inizio. Il risparmio a token dell’open source compensa solo oltre molto traffico. Con poche chiamate al giorno, la tua infrastruttura costa più dell’API, non meno.
- Non hai —né vuoi— un team MLOps. Servire un modello in produzione in alta disponibilità è un mestiere. Se non ce l’hai in casa, quello che risparmi in token lo paghi in assunzioni o in disservizi.
- Il modello aperto di oggi non è il tuo vantaggio. Il tuo differenziale non è quali pesi fai girare, è il tuo processo e il tuo dato. Partire da un’API ti lascia concentrare su quello invece che sui driver delle GPU.
- Migrare dopo è economico; sbagliare all’inizio è caro. Se progetti l’applicazione disaccoppiata dal fornitore, passare da un’API chiusa al tuo modello più avanti è un cambio di configurazione, non una riscrittura.
La mossa sensata è partire con un’API chiusa, validare che il caso funzioni nella tua operatività e lasciare la porta aperta per scendere all’open source il giorno in cui i numeri lo chiedono. Se il progetto è serio e crescerà, questa architettura —disaccoppiata, con instradamento di modelli e il dato sotto il tuo controllo— è esattamente ciò che montiamo in infrastruttura di IA aziendale: non per sposarti a un fornitore, ma per poterlo cambiare senza dolore.
Quando scendere all’open source ha senso
La regola non è «mai open source». È «open source quando un vero innesco lo giustifica», non quando lo pretende l’orgoglio. Ecco gli inneschi che spostano davvero l’ago della bilancia:
- Il dato non può uscire dal tuo perimetro. Sanità, banche, legale, segreto industriale: se per contratto o per normativa il dato non può toccare un server di terzi, l’auto-ospitare smette di essere una preferenza e diventa un requisito. Prima di dare per scontato che sia il tuo caso, metti in ordine cosa può e cosa non può uscire con una politica d’uso di ChatGPT e modelli esterni in azienda; spesso il dato sensibile è una frazione piccola e il resto passa benissimo via API.
- Il volume è grande e sostenuto. Quando chiami il modello milioni di volte al mese in modo stabile, il costo a token dell’API comincia a fare male e il tuo modello si ammortizza. Qui sì che l’aritmetica favorisce l’open source —a patto di avere già chi lo opera—.
- Devi affinare il modello con la tua conoscenza. Se il tuo caso esige un modello specializzato nel tuo dominio e nei tuoi dati, controllare i pesi aiuta. Attenzione però: prima del fine-tuning, il rimedio vero è quasi sempre il recupero sulla tua informazione, che scomponiamo in addestrare l’agente con la tua informazione.
- Latenza o offline. Se ti serve risposta locale, senza rete, o latenza minima garantita, il modello deve vivere vicino a dove si usa. Lì nessuna API chiusa regge.
Il costo che nessuno ti dice: mantenere non è gratis
L’errore classico nel confrontare è guardare solo il prezzo a token e concludere che l’open source è «gratis». Non lo è. Un modello auto-ospitato ha un costo che non appare in nessuna tariffa: qualcuno deve servirlo in alta disponibilità, vigilare che non si degradi, aggiornarlo quando esce una versione migliore ed essere di reperibilità quando cade. Quel costo è un libro paga, non una riga di fattura, ed è ricorrente. L’API chiusa nasconde quel costo dentro il prezzo a token; l’open source lo passa intero al tuo team.
Per questo il confronto onesto non è «API cara contro open source economico». È «costo variabile che non gestisci contro costo fisso che gestisci». Per volume basso o medio, il variabile vince quasi sempre. Per volume alto con team dedicato, il fisso. La stessa logica di fondo che separa comprare dal costruire per qualsiasi pezzo di IA, che abbiamo già difeso in comprare o costruire agenti IA.
Cosa fare lunedì
- Parti con un’API chiusa e valida che il caso funzioni nella tua operatività reale, non in una demo. Ottimizzare il costo a token prima di questo è ottimizzare qualcosa che non esiste.
- Disaccoppia dal primo giorno. Progetta l’applicazione perché il fornitore di modello sia configurazione, non cablaggio. Così migrare dopo costa un pomeriggio, non un trimestre.
- Segna i tuoi inneschi. Scrivi, nero su bianco, quale dato non può uscire e a quale volume la fattura comincerebbe a fare male. Il giorno in cui uno si avvera, hai il tuo segnale per scendere all’open source —e solo quel giorno—.