LLM on-premise o in cloud? Guida alla scelta per le imprese

Risposta breve

La scelta tra un LLM (Large Language Model) on-premise e uno in cloud dipende da tre fattori: quanto sono sensibili i dati, quanto sono alti e stabili i volumi, quali competenze ha l’IT interno. Il cloud riduce investimenti e manutenzione ma fa uscire i dati dal perimetro; l’on-premise dà controllo ma richiede hardware e persone. Per molte imprese la soluzione più solida è ibrida.

LLM on-premise e in cloud: di cosa parliamo

Un LLM (modello linguistico di grandi dimensioni) è il motore che legge testo, lo interpreta e ne produce di nuovo. Gli agenti AI lo usano per capire una richiesta, decidere un’azione e scrivere una risposta.

Le opzioni concrete sono tre.

• Modello in cloud via API (Application Programming Interface). Il fornitore ospita il modello e l’azienda lo interroga attraverso un’interfaccia di programmazione. Si paga in base all’uso, non si gestisce hardware.
• Modello in cloud su infrastruttura dedicata o regionale. Lo stesso approccio, ma con vincoli contrattuali e tecnici su dove avviene l’elaborazione. Microsoft, per esempio, distingue per Azure OpenAI tra distribuzioni “Global”, in cui l’inferenza può avvenire in qualunque regione Azure, e distribuzioni “Data Zone”, in cui resta all’interno di una zona come l’UE (documentazione Microsoft Learn, consultata il 10/10/2026).
• Modello on-premise. On-premise significa “nei locali dell’azienda”: il modello gira su server di proprietà o in un data center sotto il controllo diretto dell’impresa. Si usano modelli open-weight, cioè modelli di cui il produttore pubblica i pesi, scaricabili e installabili.

I modelli open-weight si eseguono con server di inferenza, il software che carica il modello in memoria e risponde alle richieste. Tra i più diffusi ci sono vLLM, pensato per carichi di produzione su GPU, e Ollama, più semplice da installare. Entrambi espongono interfacce compatibili con quelle dei principali fornitori cloud, secondo la loro documentazione ufficiale (vLLM; Ollama). Il dettaglio conta: un’applicazione ben progettata può passare da un modello in cloud a uno locale cambiando un indirizzo e poche impostazioni.

I sette criteri di scelta

1. Riservatezza

È il criterio che di solito apre la discussione. Con un modello in cloud, i testi inviati escono dal perimetro aziendale e sono trattati da un fornitore, che ai fini del GDPR (General Data Protection Regulation) diventa responsabile del trattamento (art. 28, GDPR). Servono quindi un contratto adeguato, chiarezza su conservazione e uso dei dati, attenzione ai trasferimenti fuori dallo Spazio economico europeo.

I grandi fornitori offrono garanzie contrattuali. OpenAI, ad esempio, dichiara che i dati inviati tramite API non vengono usati per addestrare i modelli salvo adesione esplicita, e che possono essere conservati fino a 30 giorni per il monitoraggio degli abusi (pagina “Enterprise privacy”, consultata il 10/10/2026). Sono impegni utili, ma restano impegni di un terzo.

Con un modello on-premise i dati non lasciano l’azienda. La riservatezza dipende però dalla sicurezza dell’infrastruttura interna: un server mal configurato non è più sicuro di un buon servizio cloud.

2. Costi

I due modelli hanno strutture di costo opposte. Il cloud è una spesa variabile: si paga per volume di testo elaborato, con costi iniziali quasi nulli. L’on-premise è soprattutto un investimento: hardware, energia, spazio, licenze di supporto, ore di personale.

Non esiste una soglia valida per tutti, anche perché i listini cambiano spesso. Il confronto va fatto sui propri volumi reali, stimati su almeno un trimestre, e sull’intero ciclo di vita dell’hardware, incluso il costo delle persone che manterranno il sistema.

3. Prestazioni e qualità

I modelli più capaci, detti “di frontiera”, sono disponibili quasi sempre solo in cloud. I modelli open-weight hanno fatto passi avanti rilevanti, ma la qualità effettiva dipende dal compito.

Per classificare email, estrarre campi da un documento o riassumere un testo, un modello di dimensioni medie può bastare. Per ragionamenti lunghi, pianificazione in più passi o testi complessi, la differenza può farsi sentire. L’unico modo serio per saperlo è misurare sui propri casi, come vedremo più avanti.

4. Hardware

Un modello locale richiede memoria adeguata, di solito su GPU (processori grafici usati per il calcolo). Più il modello è grande, più memoria serve. Un esempio documentato: OpenAI ha pubblicato ad agosto 2025 due modelli open-weight con licenza Apache 2.0, gpt-oss-120b e gpt-oss-20b. Secondo il produttore, il primo gira con 80 GB di memoria, quindi su una singola GPU di quella classe; il secondo con 16 GB (OpenAI, 2025).

Questi numeri descrivono il minimo per far girare il modello, non la capacità di servire molti utenti in parallelo. Per un uso aziendale vanno dimensionati concorrenza, contesto (la quantità di testo letta in una volta) e ridondanza.

5. Manutenzione

Il cloud sposta la manutenzione sul fornitore. In cambio, l’azienda subisce le sue scelte: modelli ritirati, versioni aggiornate che cambiano il comportamento, condizioni modificate.

L’on-premise dà controllo pieno sulle versioni, ma richiede competenze: aggiornamenti di sicurezza, monitoraggio, gestione dei guasti, valutazione periodica di nuovi modelli. Senza almeno una persona che se ne occupa con continuità, il sistema invecchia in fretta.

6. Latenza

La latenza è il tempo che passa tra la richiesta e la risposta. In cloud dipende dalla rete e dal carico del fornitore. In locale dipende dall’hardware e dal numero di richieste simultanee.

Nei processi di back office, come lo smistamento della posta o la preparazione di documenti, qualche secondo in più raramente pesa. Per un assistente vocale o un help desk in tempo reale la latenza diventa un requisito, e va misurata nelle ore di punta.

7. Conformità

Alcuni settori hanno vincoli espliciti su dove possono stare i dati: sanità, finanza, pubblica amministrazione, difesa. Altre volte il vincolo è contrattuale, imposto da un cliente. In questi casi l’on-premise, o un cloud con garanzie di localizzazione documentate, è spesso l’unica strada.

La conformità non riguarda solo il luogo. Il GDPR chiede protezione dei dati fin dalla progettazione (art. 25), misure di sicurezza adeguate (art. 32) e, nei trattamenti a rischio elevato, una valutazione d’impatto (art. 35) (GDPR). Valgono in entrambi gli scenari.

Tabella decisionale

La tabella riassume quando ciascuna opzione tende a essere preferibile. Non sostituisce l’analisi, ma aiuta a impostare la discussione tra IT, DPO (Data Protection Officer) e direzione.

Se la maggior parte delle risposte cade in una colonna, la scelta è quasi fatta. Se si dividono, la risposta è probabilmente ibrida.

Il modello ibrido: instradare per categoria di dato

Il modello ibrido usa entrambe le opzioni. Un componente di instradamento (in inglese router) decide a quale modello inviare ogni richiesta in base al tipo di dato che contiene. Funziona in quattro passi.

1. Classificare i dati. Si definiscono poche categorie chiare, per esempio: pubblico, interno, personale, particolare o riservato.
2. Assegnare una destinazione. Dati pubblici e interni possono andare al modello in cloud più capace. Dati personali possono andare in cloud solo dopo la pseudonimizzazione, cioè la sostituzione degli identificativi con codici reversibili soltanto da chi possiede la chiave. Dati particolari o riservati restano sul modello locale.
3. Riconoscere la categoria in modo automatico. Il router usa regole, metadati del sistema di origine (per esempio la casella o il fascicolo di provenienza) e, se serve, un piccolo modello locale che segnala i contenuti sensibili. In caso di dubbio, la richiesta va al modello locale.
4. Registrare la decisione. Ogni instradamento finisce in un registro: quale dato, quale categoria, quale modello, quando. Serve per i controlli e per dimostrare la conformità.

La pseudonimizzazione non è anonimizzazione: i dati pseudonimizzati restano dati personali secondo il considerando 26 del GDPR, perché la reidentificazione è possibile. Riduce il rischio, non lo elimina. Approfondiamo il tema in Pseudonimizzazione e modelli linguistici, mentre l’importanza del registro è trattata in Un registro di audit per l’AI.

Il vantaggio è la flessibilità: se un modello locale migliora o un fornitore cambia condizioni, si ridistribuisce il carico senza riscrivere l’applicazione. Una visione d’insieme di come questi componenti si collegano è nella pagina Architettura.

Come impostare una prova comparativa

Prima di decidere conviene una prova breve e misurabile.

1. Scegliere un processo reale, con un indicatore chiaro: tempo di lavorazione, percentuale di risposte corrette, numero di correzioni umane.
2. Raccogliere un campione rappresentativo, da 100 a 300 casi, pseudonimizzati se serve, con la risposta attesa definita da chi conosce il processo.
3. Mettere a confronto due o tre modelli: almeno uno in cloud e uno open-weight eseguito localmente o su un’infrastruttura di prova.
4. Misurare qualità, latenza e costo per caso, nelle stesse condizioni. Far valutare le risposte da persone che non sanno quale modello le ha prodotte.
5. Proiettare i risultati sui volumi annui e sul costo totale, incluse le ore di manutenzione.
6. Decidere per categoria di dato, non in blocco. Spesso il risultato è una ripartizione, non un vincitore unico.

Una prova così evita sia l’hardware sovradimensionato sia la dipendenza da un fornitore scelto per abitudine. Il metodo con cui partire dal processo e dall’indicatore è descritto nella pagina Metodo.

Da ricordare

• Non esiste una scelta giusta in assoluto: decidono dati, volumi, qualità richiesta e competenze interne.
• Il cloud riduce investimenti e manutenzione, ma i dati escono dal perimetro e serve un contratto da responsabile del trattamento.
• L’on-premise dà controllo sui dati e sulle versioni, ma richiede hardware dimensionato e persone dedicate.
• Il modello ibrido instrada ogni richiesta in base alla categoria del dato, con il modello locale come scelta prudente in caso di dubbio.
• La pseudonimizzazione riduce il rischio ma non rende anonimi i dati.
• Una prova comparativa su casi reali vale più di qualunque scheda tecnica.

Domande frequenti

Che cosa significa LLM on-premise?

Un LLM on-premise è un modello linguistico di grandi dimensioni installato su server di proprietà dell’azienda o in un data center sotto il suo controllo diretto, invece di essere interrogato via internet presso un fornitore cloud. Di solito si tratta di modelli open-weight, di cui il produttore pubblica i pesi, eseguiti con un server di inferenza. I testi elaborati non escono dal perimetro aziendale, ma hardware, sicurezza e manutenzione restano a carico dell’impresa.

Quanta memoria serve per far girare un LLM in locale?

Dipende dalla dimensione del modello: più è grande, più memoria serve, di solito su GPU. Un esempio documentato è quello dei modelli open-weight pubblicati da OpenAI ad agosto 2025: secondo il produttore gpt-oss-120b gira con 80 GB di memoria e gpt-oss-20b con 16 GB. Sono valori minimi per avviare il modello. Per servire molti utenti in parallelo, con testi lunghi e ridondanza, l’hardware va dimensionato in base al carico reale.

I dati inviati a un LLM in cloud vengono usati per addestrare il modello?

Dipende dal fornitore e dal contratto. OpenAI, per esempio, dichiara che i dati inviati tramite API non vengono usati per addestrare i modelli salvo adesione esplicita del cliente, e che possono essere conservati fino a 30 giorni per individuare abusi. Altri fornitori hanno condizioni diverse. Prima di inviare dati aziendali conviene verificare per iscritto uso, conservazione e luogo di elaborazione dei dati.

Usare un LLM in cloud è compatibile con il GDPR?

Può esserlo, se il trattamento è impostato correttamente. Il fornitore del modello diventa responsabile del trattamento e serve un contratto conforme all’art. 28 del GDPR, con chiarezza su conservazione e uso dei dati e attenzione ai trasferimenti fuori dallo Spazio economico europeo. Valgono inoltre la protezione dei dati fin dalla progettazione (art. 25), misure di sicurezza adeguate (art. 32) e, per i trattamenti a rischio elevato, una valutazione d’impatto (art. 35).

Costa di più un LLM on-premise o un LLM in cloud?

Non esiste una soglia valida per tutti. Il cloud è una spesa variabile, pagata in base al volume di testo elaborato, con costi iniziali quasi nulli. L’on-premise è soprattutto un investimento: hardware, energia, spazio, supporto e ore del personale che mantiene il sistema. Il confronto va fatto sui propri volumi reali, stimati su almeno un trimestre, e sull’intero ciclo di vita dell’hardware, perché anche i listini dei fornitori cambiano spesso.

Quali software servono per eseguire un LLM in locale?

Serve un server di inferenza, cioè il software che carica il modello in memoria e risponde alle richieste. Tra i più diffusi ci sono vLLM, pensato per carichi di produzione su GPU, e Ollama, più semplice da installare. Entrambi offrono interfacce compatibili con quelle di OpenAI, secondo la loro documentazione: un’applicazione ben progettata può quindi passare da un modello in cloud a uno locale cambiando un indirizzo e poche impostazioni.

I dati pseudonimizzati si possono inviare a un LLM in cloud?

La pseudonimizzazione, cioè la sostituzione degli identificativi con codici reversibili solo da chi ha la chiave, riduce l’esposizione ed è una misura usata in molte architetture ibride prima dell’invio a un modello esterno. Per il considerando 26 del GDPR, però, i dati pseudonimizzati restano dati personali, perché la reidentificazione è possibile. Servono quindi comunque base giuridica, contratto con il fornitore e le altre garanzie richieste dal regolamento.

Bibliografia e fonti

1. Microsoft, Deployment types for Microsoft Foundry Models (già “Deployment types for Azure OpenAI”: tipi di distribuzione Global, Data Zone, Regional), Microsoft Learn, ultimo aggiornamento 12/08/2026. https://learn.microsoft.com/en-us/azure/ai-services/openai/how-to/deployment-types, consultato il 10/10/2026.
2. OpenAI, Enterprise privacy at OpenAI (uso dei dati API per l’addestramento, conservazione fino a 30 giorni), openai.com, pagina senza data. https://openai.com/enterprise-privacy/, consultato il 10/10/2026.
3. OpenAI, Introducing gpt-oss (licenza Apache 2.0, requisiti di memoria di gpt-oss-120b e gpt-oss-20b), openai.com, 05/08/2025. https://openai.com/index/introducing-gpt-oss/, consultato il 10/10/2026.
4. vLLM, Online Serving (server compatibile con le API OpenAI), documentazione ufficiale vLLM, pagina senza data. https://docs.vllm.ai/en/latest/serving/online_serving/, consultato il 10/10/2026.
5. Ollama, OpenAI compatibility, documentazione ufficiale Ollama, pagina senza data. https://docs.ollama.com/api/openai-compatibility, consultato il 10/10/2026.
6. Parlamento europeo e Consiglio dell’Unione europea, Regolamento (UE) 2016/679 (GDPR), considerando 26, artt. 25, 28, 32 e 35, Gazzetta ufficiale dell’Unione europea, 04/05/2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj, consultato il 10/10/2026.

Approfondisci

• Pseudonimizzazione e modelli linguistici: usare l’AI senza esporre dati personali: come ridurre i dati personali che arrivano a un modello esterno e quali rischi restano.
• Un registro di audit per l’AI: perché la tracciabilità è un requisito di prodotto: cosa registrare quando un agente AI instrada e usa i modelli.
• Integrare gli agenti AI con ERP, CRM e help desk: API, eventi e permessi: come collegare gli agenti ai sistemi aziendali in modo sicuro.
• Model Context Protocol: il protocollo che collega l’AI ai sistemi aziendali: lo standard aperto con cui modelli e agenti si collegano a dati e strumenti esterni, e i suoi rischi.
• L’architettura di un sistema di agenti AI: come si collegano modelli in cloud, modelli locali, registro e integrazioni.
• Privacy by design negli agenti AI: come la protezione dei dati entra nella scelta di dove far girare i modelli.