AI open source o proprietaria: come scegliere davvero
Modelli AI a pesi aperti e proprietari a confronto: cosa significa davvero open source per un modello, le licenze da controllare e quando conviene ciascuno.
Il dibattito tra AI "aperta" e "chiusa" è uno dei più carichi di ideologia e povero di dettagli pratici. Da un lato chi sostiene che i modelli aperti siano l'unica via sana, dall'altro chi li considera un giocattolo. La realtà è più prosaica: sono due strumenti con vincoli diversi, e la scelta dipende da cosa devi farci. In questo articolo metto in fila i criteri concreti.
"Open source" è il termine sbagliato
Partiamo da una precisazione che non è pedanteria, perché ha conseguenze legali reali.
Nel software, open source significa poter vedere e modificare il codice sorgente. Per un modello AI, quasi nessuno pubblica l'equivalente: i dati di addestramento e il codice di training. Quello che viene rilasciato sono i pesi — il risultato dell'addestramento.
Per questo il termine corretto è open weights, pesi aperti. Puoi scaricare ed eseguire il modello, adattarlo, ma non puoi ricostruirlo né sapere esattamente su cosa è stato addestrato.
E "aperto" non significa automaticamente "libero di fare quello che vuoi". Le licenze variano parecchio:
- Alcuni modelli usano licenze permissive standard (Apache 2.0, MIT): uso commerciale libero
- Altri usano licenze proprietarie che pongono condizioni: limiti sulla dimensione dell'azienda utilizzatrice, restrizioni d'uso, obblighi di attribuzione
- Altri ancora vietano esplicitamente l'uso commerciale
Prima di costruirci sopra un prodotto, leggi la licenza di quello specifico modello. È il passaggio che salta quasi tutti, ed è quello che può costare caro. Vale lo stesso avvertimento che faccio per Stable Diffusion sul lato immagini.
Il confronto pratico
| Pesi aperti | Proprietari (API) | |
|---|---|---|
| Qualità di punta | Buona, in recupero | Generalmente superiore |
| Costo | Hardware + gestione | Per token |
| Privacy dei dati | Totale, restano da te | Passano dal fornitore |
| Personalizzazione | Piena, fino al fine-tuning | Limitata a ciò che espongono |
| Continuità | Il file resta tuo per sempre | Dipende dal fornitore |
| Manutenzione | Tua | Nessuna |
| Tempo per partire | Giorni | Minuti |
Quando conviene un modello a pesi aperti
Le ragioni valide, in ordine di forza:
I dati non possono uscire. Dati sanitari, legali, informazioni sotto accordo di riservatezza, materiale coperto da vincoli normativi. È la ragione più solida in assoluto, e spesso non ammette alternative.
Serve indipendenza da un fornitore. Un modello scaricato continua a funzionare identico anche se l'azienda che l'ha rilasciato cambia prezzi, condizioni o chiude. Con un'API, il modello che usi oggi può essere deprecato — e un modello nuovo si comporta diversamente, obbligandoti a rivedere prompt e test.
Il volume è molto alto e il compito è semplice. Classificare milioni di testi via API costa; un modello piccolo su hardware tuo ha un costo fisso.
Serve specializzazione profonda. Il fine-tuning su un dominio specifico può rendere un modello piccolo migliore di uno generalista molto più grande, su quel dominio.
Serve funzionamento offline o in ambienti senza connessione affidabile.
Vuoi capire come funziona. Ragione legittima: si impara molto di più eseguendo un modello che chiamando un'API.
Quando conviene un modello proprietario
Serve la qualità massima. Sui compiti più difficili — ragionamento complesso, codice articolato — i modelli di punta commerciali mantengono generalmente un vantaggio.
Il volume è basso o irregolare. Pagare a consumo batte comprare e gestire hardware che resta inutilizzato.
Non hai competenze o tempo per l'infrastruttura. Gestire modelli in produzione è un lavoro: aggiornamenti, scalabilità, monitoraggio.
Ti serve partire subito. Un'API si integra in un pomeriggio.
Servono funzionalità di contorno. Uso di strumenti, elaborazione di immagini, contesti molto ampi, garanzie contrattuali: l'ecosistema attorno ai servizi commerciali è più maturo.
Va detto con chiarezza: per la maggior parte dei progetti, l'API è la scelta razionale. Il locale è spesso una preferenza travestita da requisito tecnico.
Il divario si sta riducendo
Un dato che vale la pena registrare senza entusiasmi né scetticismo: la distanza tra i migliori modelli aperti e quelli chiusi si è ridotta parecchio negli ultimi anni.
I modelli aperti recenti reggono il confronto su molti compiti pratici — riassunti, estrazione dati, classificazione, conversazione, codice ordinario. Il divario resta più marcato sui compiti difficili: ragionamento in più passaggi, problemi che richiedono precisione, contesti molto lunghi.
La conseguenza pratica è che la domanda "quale è migliore" è meno utile di "quale è abbastanza buono per il mio caso". Per moltissimi compiti, un modello aperto è ampiamente sufficiente, e le altre variabili — costo, privacy, controllo — diventano decisive.
La strada intermedia
Vale la pena dirlo perché è quella che scelgono molti progetti seri: non è una scelta esclusiva.
Un'architettura comune usa un modello aperto in locale per il traffico ad alto volume e a bassa difficoltà, e chiama un'API commerciale solo per i casi complessi. È lo stesso principio dell'instradamento per difficoltà di cui parlo in quanto costano le API degli LLM.
Un'altra combinazione frequente: modello locale su dati sensibili, API su tutto il resto.
E in entrambi i casi conviene progettare per la sostituibilità: astrai la chiamata al modello dietro una tua interfaccia, così cambiare fornitore o modello è una modifica localizzata e non una riscrittura.
Come decidere, in pratica
Quattro domande in ordine:
- I miei dati possono uscire dall'azienda? Se no, il locale non è una preferenza, è un requisito.
- Che volume ho, realisticamente? Fai il conto, non la stima a occhio.
- Un modello medio basta per il mio compito? Provalo sui tuoi casi reali prima di decidere.
- Ho qualcuno che può gestire l'infrastruttura? Se la risposta è "lo faccio io nei ritagli", conta come no.
Se tutte e quattro indicano il locale, vai di locale. Se anche una sola indica il contrario, l'API è probabilmente la scelta giusta — almeno per iniziare.
In sintesi
"Open source" applicato ai modelli AI è impreciso: si rilasciano i pesi, non i dati né il codice di addestramento. E aperto non significa senza vincoli — le licenze vanno lette, perché alcune limitano l'uso commerciale.
I modelli aperti convincono quando ci sono ragioni concrete: dati che non possono uscire, indipendenza da un fornitore, volumi alti su compiti semplici, specializzazione profonda. Fuori da questi casi, un'API commerciale costa meno e rende di più.
Il divario di qualità si è ridotto sui compiti ordinari e resta sui compiti difficili. Ma la domanda utile non è quale sia migliore in assoluto: è quale sia sufficiente per quello che devi fare.
E qualunque sia la scelta, un accorgimento che ripaga sempre: astrai la chiamata al modello, così cambiare idea più avanti costa poco.