Il cloud è un default così forte che proporre un'alternativa sembra sempre una stranezza. Eppure, quando smetti di ragionare per mode e guardi i numeri di un'azienda italiana da 30–300 dipendenti — con un ufficio IT minuscolo, un fornitore storico, qualche decina di TB di documenti su un NAS — la risposta "ovvia" smette di esserlo.
In un anno di installazioni di Celeris e Nexus abbiamo visto emergere uno schema: on-premise non è una scelta ideologica, è una scelta da business case. E il business case si vince o si perde su cinque variabili. Mettiamole in ordine.
1. La natura dei dati che entrano nel modello
La prima domanda non è "che modello uso", è "cosa gli do da leggere". Un RAG aziendale ingerisce tutto: contratti, email, dati clienti, procedure, a volte codice sorgente. Nel momento in cui quei testi escono dalla tua rete, hai firmato un contratto di fiducia con qualcun altro.
Per molti clienti questa fiducia è tecnicamente legittima ma operativamente insostenibile: uno studio legale che tratta cause in corso, un'azienda sanitaria, un fornitore della PA. Non è che non possano usare il cloud — è che ogni progetto diventa una negoziazione con DPO, legale interno, cliente finale, a volte un'autorità di vigilanza.
2. Il profilo di costo vero
Qui la gente si sbaglia in entrambe le direzioni. Chi vende cloud ti dice: "un server GPU costa quanto 3 anni di token". Chi vende hardware ti dice: "il cloud ti uccide a volumi seri". Tutti e due hanno torto al 50%.
La verità banale: dipende dalla densità d'uso. Un'azienda che fa 500 query al giorno su un RAG di 200 GB di documenti con cloud API spende circa 400–900 €/mese — una sciocchezza. Un service desk con 50 agenti che tutto il giorno smazzano ticket con Automata arriva a 6.000–15.000 €/mese. A quel punto, un server da 18.000 € ammortizzato su 4 anni ha già vinto.
La regola empirica
- < 50k query/mese: cloud, senza discussioni. L'hardware sta fermo.
- 50k – 500k query/mese: zona grigia. Dipende da compliance e latenza.
- > 500k query/mese: on-premise quasi sempre più economico a 24 mesi.
3. Latenza e disponibilità reale della rete
Questo è il punto che il marketing dei big cloud evita con grazia. L'AI cloud funziona bene se hai 100 Mbit simmetrici stabili. In Italia, nel 2026, ci sono ancora capannoni industriali dove il picco serale della linea ADSL manda in timeout le chiamate verso OpenAI. Per chi fa manutenzione in stabilimento, per chi ha filiali in Basilicata, per chi lavora in mobilità su reti 4G marginali — non è un problema teorico.
Un modello da 70B in 4-bit su una singola GPU risponde in 800ms in rete locale. La stessa richiesta via API cloud, da una connessione mediocre, può impiegare 4–6 secondi. Sei volte tanto. I tuoi utenti smettono di usare lo strumento dopo una settimana.
4. Il lock-in che non vedi
Ogni API cloud ha formati di input, logiche di function calling, prompt style, filtri di sicurezza leggermente diversi. Quando costruisci un agente sopra un modello, stai accoppiando la logica del tuo business al comportamento specifico di quel modello. Cambiare fornitore non è mai gratuito: devi riaggiustare i prompt, ritestare gli edge case, rifare valutazioni.
Con on-premise — soprattutto con modelli open-weight — il lock-in esiste ma è più basso. Puoi testare Llama, Mistral, Qwen sullo stesso stack. Il giorno in cui esce un modello migliore, lo scarichi e lo fai girare. Non devi rinegoziare un contratto.
"Non abbiamo comprato un servizio, abbiamo comprato un asset. È la differenza." — Un nostro cliente dopo sei mesi di Celeris in produzione.
5. La capacità IT che hai davvero
Ecco il punto dove diciamo la verità ai clienti che ci chiedono on-premise per moda. Un server GPU non è un NAS. Richiede: monitoraggio, aggiornamenti sistemistici, backup verificati, qualcuno che sappia leggere i log del driver CUDA quando qualcosa va storto alle 3 di notte.
Se la tua IT è una persona sola che fa anche il sistemista Windows e il CED telefonico, on-premise senza un fornitore che gestisca il sistema per te è una trappola. Per questo nei nostri contratti la gestione operativa è quasi sempre nostra: l'hardware è tuo, il software è tuo, ma la babysitting operativa la facciamo noi da remoto. Ibrido di proprietà e di servizio.
Quando il cloud è la risposta giusta
Per non sembrare dei bigotti dell'on-premise, elenco i casi in cui sconsigliamo esplicitamente di portarsi i modelli in casa:
- Volumi bassi e sporadici (sotto 50k query/mese): l'hardware resta spento.
- Casi d'uso esplorativi e pre-produzione: fai tutti i tuoi esperimenti sul cloud, poi se decidi di scalare valuti.
- Aziende senza vincoli di compliance e con uso orizzontale: se l'AI è per tutti e ovunque, la praticità del cloud vale il costo.
- Quando serve esattamente un modello frontier (es. GPT-5 o Claude top-tier) per una funzione critica che non funziona con un 70B locale.
Cosa facciamo noi
Ogni volta che un cliente ci chiede "on-premise sì o no", partiamo da un audit di due settimane: volumi, natura dei dati, connettività, IT disponibile, budget. Finisce con un numero: break-even in mesi. Se è sotto i 18, di solito andiamo on-prem. Se è sopra i 36, cloud. In mezzo, valutiamo caso per caso.
Non abbiamo una preferenza ideologica. Abbiamo una preferenza per le cose che restano accese anche quando la linea salta, che non obbligano a rinegoziare ogni anno, e che permettono al cliente di dormire la notte. Quando queste coincidono con il cloud, facciamo cloud. Il più delle volte, in Italia, coincidono con l'on-premise.