Guide 8 minuti

Modelli open weights: licenze, privacy e scelta per AI locale

Open weights non significa automaticamente open source. Guida pratica a licenze, privacy, hardware, sicurezza e scelta dei modelli AI locali.

Scatola con pesi di un modello AI, documento di licenza e domanda Puoi scaricarlo ma puoi davvero usarlo?

Scaricare i pesi di un modello AI dà più controllo, ma non elimina licenze, costi, rischi né responsabilità. Questa guida aiuta professionisti e PMI a capire che cosa significa davvero open weights, quali verifiche fare e quando l’esecuzione locale è una scelta sensata.

In breve: “pesi disponibili” descrive l’accesso ai parametri appresi dal modello. Non garantisce automaticamente che codice, dati di addestramento, licenza e intero processo siano open source.

Indice

  • Open weights, open source e API: le differenze
  • Che cosa si ottiene scaricando un modello
  • La checklist prima di scegliere
  • Licenze e uso commerciale
  • Hardware, quantizzazione e costi reali
  • Privacy e sicurezza
  • Un esempio pratico per una PMI
  • Come eseguire un test controllato
  • Errori da evitare
  • Domande frequenti

Open weights, open source e API non sono sinonimi

La distinzione è importante perché cambia ciò che un’azienda può fare, quanto controllo possiede e quali obblighi deve gestire.

Formula Che cosa ricevi Controllo Verifica indispensabile
Modello via API Accesso a un servizio remoto Basso o medio Termini del servizio, trattamento dei dati, costi e disponibilità
Open weights File con i parametri appresi, più gli elementi pubblicati dal fornitore Medio o alto Licenza, provenienza, formati, model card e componenti mancanti
Open source AI Un sistema rilasciato con libertà e materiali sufficienti per usarlo, studiarlo, modificarlo e condividerlo Potenzialmente alto Completezza del rilascio e conformità alla definizione adottata

Secondo la Open Source AI Definition 1.0 dell’Open Source Initiative, un sistema AI open source deve offrire le libertà di uso, studio, modifica e condivisione, insieme alla forma preferita per apportare modifiche. Per i sistemi di machine learning non basta quindi poter scaricare il file finale dei pesi: contano anche informazioni sui dati e codice impiegato per ottenere quei parametri. Consulta anche la definizione rapida di open weights nel Glossario di Basi di AI.

Questa precisione non è una disputa terminologica. Se una licenza impone soglie, limita determinati impieghi o vieta la redistribuzione, il modello può essere accessibile senza essere “libero” nel senso che molti utenti attribuiscono alla parola open source.

Che cosa ottieni davvero quando scarichi i pesi

I pesi sono i valori numerici appresi durante l’addestramento. Un runtime li carica in memoria e li combina con l’architettura, il tokenizer e la configurazione per produrre una risposta. Da soli, però, non costituiscono sempre un prodotto pronto per l’azienda.

Per una distribuzione utilizzabile servono normalmente:

  • i file dei pesi in un formato supportato;
  • l’architettura e il codice di inferenza compatibile;
  • tokenizer e template della conversazione corretti;
  • configurazione della context window;
  • documentazione su usi previsti, limiti ed eventuali valutazioni;
  • runtime, driver e librerie compatibili con l’hardware;
  • controlli applicativi su accessi, log, dati e output.

Un modello può quindi essere scaricabile ma difficile da eseguire, adattare o integrare. Può richiedere molta VRAM, dipendere da codice remoto oppure funzionare bene in inglese e male sui documenti italiani dell’azienda. La libertà di scaricare non coincide con l’adeguatezza al caso d’uso.

La checklist prima di scegliere un modello open weights

1. Parti dal risultato, non dalla classifica

Definisci il compito prima di confrontare i benchmark. “Voglio un modello potente” non è un requisito. “Voglio classificare le richieste ricevute via email in cinque categorie, in italiano, con meno del 5% di errori critici e risposta entro tre secondi” è verificabile.

Prepara almeno 30–50 esempi realistici, includendo casi ambigui e input che il modello dovrebbe rifiutare. Le classifiche pubbliche sono utili per restringere la scelta, non sostituiscono il test sui tuoi dati.

2. Verifica identità e provenienza

Annota nome del repository, organizzazione che lo pubblica, versione o commit, modello di base e data del download. Se scarichi una variante quantizzata o un fine-tuning realizzato da terzi, non stai necessariamente usando l’artefatto originale.

La model card dovrebbe indicare almeno usi previsti, limiti, dati o metodologia dichiarata, risultati di valutazione, licenza e relazione con il modello di base. La documentazione di Hugging Face descrive le model card come lo strumento per rendere più verificabili provenienza, impieghi, dataset e risultati.

3. Leggi la licenza effettiva

Non fermarti all’etichetta “open”. Apri il testo della licenza e controlla:

  • uso commerciale e settori esclusi;
  • modifica e fine-tuning;
  • redistribuzione dei pesi o di una variante;
  • obblighi di attribuzione e avvisi da conservare;
  • eventuali soglie legate a utenti, fatturato o dimensione del servizio;
  • acceptable use policy e altre condizioni richiamate;
  • compatibilità con licenze di dataset, adapter, tokenizer e codice.

Se il modello entra in un prodotto, in un’offerta al cliente o in un processo ad alto impatto, la verifica legale deve essere proporzionata al rischio. Questa guida è operativa e non sostituisce un parere legale.

4. Controlla requisiti e formati

Parametri, precisione e lunghezza del contesto determinano memoria e prestazioni. Un modello di dimensione nominalmente contenuta può superare la memoria disponibile quando si aggiungono cache del contesto, richieste simultanee e overhead del runtime.

La quantizzazione riduce l’occupazione dei pesi e rende più pratico l’uso su hardware consumer, ma può modificare qualità e velocità. Verifica sempre la variante esatta sul tuo dispositivo. Se stai progettando l’infrastruttura, usa la checklist per l’AI locale prima di acquistare una GPU.

5. Misura qualità, latenza e costo totale

Valuta insieme:

  • percentuale di risposte corrette e complete;
  • errori gravi, allucinazioni e rifiuti ingiustificati;
  • qualità nella lingua e nel dominio richiesti;
  • tempo al primo token e tempo totale;
  • richieste contemporanee sostenibili;
  • consumo di RAM, VRAM, energia e spazio disco;
  • ore necessarie per installazione, monitoraggio e aggiornamenti.

Un’API a consumo può risultare più economica per carichi piccoli e irregolari. Il self-hosting può diventare interessante quando contano controllo dei dati, continuità operativa, personalizzazione o un volume prevedibile. Non esiste una risposta universale.

Licenza e AI Act: l’apertura non è un lasciapassare

Dal punto di vista aziendale, la licenza stabilisce che cosa puoi fare con l’artefatto; la normativa stabilisce invece quali obblighi possono applicarsi al ruolo e all’uso concreto.

La Commissione europea spiega che l’AI Act prevede obblighi per i fornitori di modelli general-purpose e obblighi aggiuntivi per i modelli con rischio sistemico. Le esenzioni per modelli rilasciati con licenza libera e open source sono limitate e non cancellano automaticamente tutti gli adempimenti. Inoltre un’azienda che integra un modello in un sistema resta responsabile delle attività che le competono come deployer o fornitore del sistema risultante.

Per un percorso operativo consulta AI Act 2026: cosa devono fare le aziende. La regola pratica è semplice: non dedurre la conformità dalla modalità di distribuzione del modello.

Privacy: locale non significa automaticamente privato

Eseguire il modello nella propria infrastruttura può evitare l’invio dei prompt a un’API esterna, ma la privacy dipende dall’intera architettura.

Controlla se applicazione, interfaccia, plugin, telemetria, sistema di aggiornamento o strumenti di osservabilità comunicano con servizi esterni. Verifica inoltre dove finiscono conversazioni, documenti caricati, log, backup e cache.

Per una PMI sono fondamentali almeno:

  • autenticazione e ruoli separati;
  • cifratura delle comunicazioni e dei backup;
  • conservazione minima dei log;
  • segregazione tra reparti e clienti;
  • inventario dei documenti inseriti nel sistema;
  • procedura di cancellazione e aggiornamento;
  • controllo degli strumenti che il modello può chiamare.

Se il modello consulta documenti interni, la progettazione del RAG aziendale deve applicare i permessi prima del recupero: una risposta corretta non deve mai rivelare un documento che l’utente non era autorizzato a leggere.

Sicurezza: un modello è anche una dipendenza software

Scaricare un modello significa introdurre file e codice nella catena di fornitura. I file serializzati con Pickle possono eseguire codice arbitrario durante il caricamento; Hugging Face raccomanda di usare fonti affidabili, verificare gli scanner e preferire formati più sicuri quando disponibili. La presenza di un controllo automatico non equivale a un audit completo.

Prima della produzione:

  1. scarica da repository ufficiali o approvati;
  2. registra commit, hash e licenza;
  3. evita trust_remote_code se non hai revisionato il codice richiesto;
  4. esegui il primo test in un ambiente isolato, senza segreti e dati reali;
  5. limita rete, filesystem e privilegi del processo;
  6. esegui scansioni dei file e delle dipendenze;
  7. mantieni una versione precedente pronta per il rollback;
  8. verifica gli aggiornamenti prima di promuoverli in produzione.

Il modello non dovrebbe ricevere direttamente credenziali. Se usa strumenti o API, passa token a vita breve tramite un componente controllato, applica allowlist e richiedi approvazione umana per azioni irreversibili.

Esempio semplice: assistente interno per procedure tecniche

Immaginiamo una PMI con manuali, procedure e verbali di assistenza. L’obiettivo è permettere ai tecnici di cercare istruzioni senza inviare documenti riservati a un servizio esterno.

Il progetto può essere diviso così:

  1. Prova isolata: due modelli open weights compatibili con l’italiano, eseguiti su un server di test.
  2. Dataset di verifica: 50 domande reali, con risposta attesa e documento autorizzato.
  3. Interfaccia: Open WebUI collegata a Ollama oppure un’applicazione interna equivalente.
  4. Recupero documenti: indice RAG con permessi coerenti con il sistema documentale.
  5. Criteri di accettazione: almeno 90% di risposte utili, citazione corretta della fonte, nessuna esposizione tra reparti e tempo massimo concordato.
  6. Controlli: accesso nominativo, log minimizzati, backup, monitoraggio e pulsante per segnalare risposte errate.

Solo dopo il test si decide se acquistare hardware, usare un servizio gestito o adottare un’architettura ibrida. Per una prima installazione puoi seguire la guida a Ollama su Windows, macOS e Linux.

Un metodo di valutazione in sette giorni

Giorno 1 — Requisiti

Scrivi compito, utenti, dati ammessi, tempo di risposta e conseguenze di un errore.

Giorno 2 — Preselezione

Scegli al massimo tre modelli compatibili con licenza, lingua, runtime e memoria disponibili.

Giorno 3 — Ambiente isolato

Installa il runtime, registra versioni e impedisci al processo di accedere a segreti o reti non necessarie.

Giorni 4 e 5 — Test

Esegui lo stesso set di esempi su tutti i candidati. Non cambiare il prompt per favorire un modello senza documentarlo.

Giorno 6 — Costi e rischi

Calcola costo hardware o cloud, energia, manutenzione, aggiornamenti e tempo del personale. Registra rischi e contromisure.

Giorno 7 — Decisione

Scegli, rinvia o scarta sulla base di criteri scritti. Conserva risultati, versione, licenza e configurazione: serviranno per gli aggiornamenti successivi.

Errori da evitare

  • Confondere scaricabile con open source. I pesi sono soltanto una parte del sistema.
  • Ignorare la licenza delle varianti. Un fine-tuning o un adapter può aggiungere condizioni e dipendenze.
  • Acquistare hardware prima del test. Inizia con una prova misurabile su un ambiente disponibile o temporaneo.
  • Valutare solo il benchmark. Lingua, dominio, sicurezza e latenza reale possono cambiare il risultato.
  • Caricare file non verificati in produzione. Modelli e codice remoto fanno parte della supply chain.
  • Pensare che locale equivalga a privato. Telemetria, plugin, log e backup possono comunque far uscire dati.
  • Dimenticare aggiornamenti e rollback. Ogni nuova variante deve essere rivalutata.

FAQ

Open weights significa che posso usare il modello commercialmente?

Non necessariamente. Dipende dal testo della licenza, dalle policy richiamate e dall’uso previsto. Controlla anche i componenti derivati.

Un modello open weights è gratuito?

Il download può esserlo, ma inferenza, hardware, energia, storage, sicurezza e manutenzione hanno un costo. Confronta il costo totale con un’API.

Posso eseguirlo senza GPU?

Molti modelli quantizzati funzionano anche su CPU o memoria condivisa, con prestazioni variabili. Il test sul dispositivo reale è più affidabile delle sole specifiche.

Open weights è più sicuro di un’API?

Offre più controllo, non sicurezza automatica. Con un’API parte della responsabilità operativa è del fornitore; con il self-hosting aumenta quella dell’utilizzatore.

Posso modificare il modello?

Tecnicamente può essere possibile tramite fine-tuning o LoRA, ma licenza, dati, qualità e competenze determinano se sia lecito e utile.

Qual è il primo documento da leggere?

Apri licenza e model card, poi verifica repository ufficiale, versione, modello di base, formati e requisiti. Se uno di questi elementi manca, trattalo come un rischio da chiarire.

Conclusioni

I modelli open weights sono preziosi quando servono controllo dell’infrastruttura, personalizzazione e riduzione della dipendenza da un singolo fornitore. Il loro vantaggio, però, emerge soltanto con una selezione disciplinata.

La domanda corretta non è “posso scaricarlo?”, ma: posso usarlo legalmente, farlo funzionare sul mio hardware, proteggerlo, valutarlo e mantenerlo nel tempo?

Fonti ufficiali


Vuoi ricevere guide pratiche su AI locale, integrazioni e governance? Iscriviti gratuitamente alla newsletter di Basi di AI.

Una pillola di AI

Capire prima. Usare meglio.

Ricevi guide pratiche e notizie selezionate, senza rumore e senza sensazionalismi.

Iscriviti gratuitamente
Giuseppe D'Agata
Scritto da

Giuseppe D'Agata

Solution Engineer in Zenita Group e autore di Basi di AI. Oltre 24 anni di esperienza in infrastrutture ICT, networking, Unified Communication, software, automazione e intelligenza artificiale.