AI locale o cloud: dove far girare i modelli linguistici in azienda

Per usare un modello linguistico in azienda ci sono due strade: pagarlo come servizio a un fornitore cloud, che lo esegue sui propri server, oppure eseguirlo su hardware che controlla l'azienda, in sede o in un server dedicato. Non esiste una risposta valida per tutti: la scelta dipende da quali dati entrano nelle richieste, da quanto si usa il modello e da quanta qualità serve.

In sintesi, il cloud conviene quando l'uso è saltuario o variabile e quando serve la massima capacità disponibile. Il locale conviene quando i dati non devono uscire dall'azienda, quando il carico è continuo e prevedibile e quando il compito è abbastanza circoscritto da poter essere svolto da un modello più piccolo. Per molte realtà la soluzione è mista.

Questo articolo riguarda solo dove gira il modello. Come lo si collega ai documenti aziendali, come si limitano i suoi strumenti e come lo si protegge da istruzioni malevole sono temi distinti, che trattiamo a parte.

Cosa significa davvero «cloud» e «locale»

Con il cloud l'azienda invia testo (e a volte file) tramite API a un fornitore, che restituisce la risposta. Non servono acceleratori specializzati, la scalabilità è del fornitore e si paga secondo le condizioni del servizio. In cambio ogni richiesta lascia la rete aziendale.

Con il locale il modello gira su macchine dell'azienda: una workstation con una scheda grafica adatta, un server dedicato o, per compiti leggeri, un normale PC. Si usano modelli con pesi scaricabili e programmi come llama.cpp, che supporta schede NVIDIA, AMD, Apple silicon e anche la sola CPU, e può esporre un'API compatibile con quella dei servizi cloud. Questo permette di cambiare strada in seguito senza riscrivere le applicazioni.

Privacy e conformità: il locale non basta, il cloud non è escluso

Mandare dati personali a un fornitore esterno significa affidargli un trattamento: servono un contratto di nomina a responsabile, la verifica di dove i dati vengono elaborati e conservati e la coerenza con le informative agli interessati. Se l'elaborazione avviene fuori dallo Spazio economico europeo si applicano le regole sui trasferimenti del GDPR (capo V).

I grandi fornitori offrono tutele concrete. Al novembre 2026, ad esempio, la documentazione di OpenAI indica che i dati inviati tramite API non sono usati per addestrare i modelli, salvo adesione esplicita, e che i registri per il controllo degli abusi sono conservati di norma fino a 30 giorni. Esiste anche una regione europea per elaborazione e archiviazione, con requisiti aggiuntivi. Condizioni di questo tipo cambiano: vanno rilette nel contratto che si firma, non date per acquisite.

Il locale riduce la superficie di esposizione, ma non rende il sistema automaticamente riservato. Contano gli stessi elementi di qualsiasi server aziendale:

• chi può accedere all'applicazione e con quali credenziali;
• dove finiscono i registri delle conversazioni e per quanto tempo;
• come sono protetti e salvati gli archivi che il sistema legge;
• se la macchina è aggiornata e separata dal resto della rete.

Anche l'uso dell'AI in sé ha obblighi propri: ne parliamo in AI Act europeo: obblighi per le aziende. Sul fronte dati personali, il Comitato europeo per la protezione dei dati ha chiarito nel parere 28/2024, adottato nel dicembre 2024, come valutare i modelli addestrati su dati personali. Per i casi specifici serve il consulente legale o il responsabile della protezione dei dati.

La memoria decide l'hardware

Il numero di parametri di un modello dice poco senza la precisione con cui sono memorizzati. Come ordine di grandezza, ogni parametro a 16 bit occupa 2 byte: un modello da 7 miliardi di parametri richiede circa 14 GB solo per i pesi. Con la quantizzazione, che memorizza i pesi con meno bit, lo stesso modello a 4 bit scende intorno ai 4 GB. Il prezzo è una perdita di qualità che dipende dal modello e dal compito, e che va misurata sui propri casi.

I pesi non sono tutto. Si aggiunge la memoria per il contesto, cioè il testo che il modello tiene presente mentre risponde, che cresce con la lunghezza dei documenti e con il numero di richieste simultanee. Un modello che «ci sta» su una scheda grafica con un prompt breve può non starci con venti pagine di contratto o con cinque utenti che lo usano insieme.

Costi: confrontare la stessa cosa

Il prezzo per richiesta del cloud e il costo di un server non sono confrontabili direttamente. Per un confronto corretto bisogna stimare, per un periodo di almeno tre anni:

1. quante richieste al giorno, di che lunghezza, con quali picchi;
2. per il cloud, il costo dell'utilizzo moltiplicato per il volume, più il rischio di variazioni di listino;
3. per il locale, acquisto dell'hardware, ammortamento, energia, raffreddamento, backup e rinnovo;
4. il tempo di chi installa, aggiorna e sorveglia il sistema;
5. il costo di un'interruzione: cosa succede se il servizio è fermo un giorno.

Non riportiamo cifre perché dipendono da modello, fornitore e periodo e cambiano in fretta. Il criterio generale è questo: con un uso leggero o irregolare l'hardware dedicato resta spesso fermo e il cloud costa meno; con un uso intenso e costante il locale può ripagarsi, a patto di avere chi lo gestisce.

Qualità e licenze

I modelli più capaci sono in genere disponibili solo come servizio. I modelli con pesi aperti sono più piccoli o più impegnativi da ospitare, ma per compiti definiti (classificare messaggi, riassumere, estrarre dati da documenti ricorrenti) possono bastare. Si prova su esempi reali dell'azienda, non su classifiche generiche.

Le licenze non sono uniformi: alcuni modelli usano licenze permissive come Apache 2.0, altri licenze proprie con condizioni sull'uso commerciale o sulle dimensioni dell'azienda. Si legge la licenza del modello specifico e della versione specifica prima di metterlo in produzione.

Come decidere: criteri operativi

1. Che dati entrano nelle richieste? Testo pubblico o già pubblicabile: il cloud va bene. Dati di clienti, salute, personale, segreti industriali: serve una valutazione scritta, e il locale o una regione europea con contratto adeguato.
2. Quanto si usa? Poche richieste o irregolari favoriscono il cloud; flussi continui e prevedibili avvicinano il locale.
3. Quanta qualità serve? Compiti stretti e verificabili si prestano a modelli piccoli; ragionamenti lunghi o testi complessi richiedono i modelli più grandi.
4. Chi lo gestisce? Un server AI è un server: aggiornamenti, monitoraggio e backup non spariscono.
5. Si può tornare indietro? Meglio applicazioni che parlano con un'interfaccia standard, così il modello è sostituibile.

L'architettura mista nasce da questi criteri: un modello locale per le attività su dati riservati o ripetitive, il cloud per le richieste occasionali che richiedono più capacità e non contengono dati sensibili. Va regolata da una regola chiara su cosa può uscire, non lasciata alla scelta di ogni utente.

Il passo successivo

Prima di comprare hardware o sottoscrivere un abbonamento, elenca tre casi d'uso reali, i dati che coinvolgono e il numero di richieste al giorno. Con queste informazioni si valuta la strada più adatta e si prova su un caso piccolo. Se vuoi un parere sul tuo caso, descrivilo con la richiesta guidata per i sistemi AI; i dettagli del lavoro sono nella pagina sistemi AI.