Prima, precisione: tre "cloud" e tre "on-prem"
Il dibattito gira in tondo perché "cloud AI" indica tre cose diverse: (a) API a token gestite (OpenAI/Anthropic/Google — noleggi il modello stesso, zero infrastruttura, qualità di frontiera, minimo controllo); (b) infrastruttura GPU a noleggio (hyperscaler o marketplace come RunPod/Vast — esegui il tuo modello aperto sul ferro di qualcun altro: più controllo di una API, comunque fuori sede); e (c) cloud sovrano/in regione UE (garanzie contrattuali + giurisdizionali sopra la b). Allo stesso modo "on-premise" copre il tuo datacenter, la colocation e un box edge in fabbrica. La maggior parte delle decisioni sbagliate nasce dal confrontare la coppia sbagliata — una API a token e un rack in colo risolvono problemi diversi. Il framework di questa guida si applica a qualunque coppia tu stia davvero pesando.
Dimensioni decisionali
| On-premise | Cloud | |
|---|---|---|
| Controllo dati | Totale, interno | Gestito dal provider |
| Forma del costo | CapEx iniziale, marginale basso | OpEx, scala con l'uso |
| Costo a uso alto | Più basso per token | Più alto per token |
| Accesso ai modelli | Solo open-weight | Anche modelli chiusi di frontiera |
| Scalabilità | Capacità fissa | Elastica, on-demand |
| Compliance / residenza | Più facile da dimostrare | Dipende da regione/provider |
| Latenza | Locale, prevedibile, funziona offline | Dipende dalla rete |
| Lock-in | Basso (stack aperto) | Lock-in API/ecosistema reale |
| Tempo di avvio | Settimane (acquisto, rack) | Minuti |
| Carico operativo | Tuo (e anche lo SLA è tuo) | Per lo più del provider (con SLA) |
Costo: CapEx vs OpEx, e dove sta davvero il break-even
L'on-premise è un acquisto capitale con basso costo marginale per token; il cloud è consumo a contatore. I due si incrociano a una soglia di utilizzo — sotto conviene il cloud, sopra vince l'hardware di proprietà e il divario cresce con la scala (la matematica completa, con esempi svolti a tre scale, è nella nostra guida ai costi). Due correzioni enterprise al confronto ingenuo: il CapEx on-prem porta anche personale ops, strutture, ridondanza e un ciclo di refresh di 3–4 anni, spingendo il break-even reale più in alto; ma il batching multi-utente moltiplica l'output dell'hardware di proprietà 10–20×, tirandolo giù per i carichi davvero condivisi. Il verdetto ha la forma del carico: carico interno costante favorisce il possesso; carico a picchi, sperimentale o stagionale favorisce il noleggio.
La dimensione che si sottovaluta: l'accesso ai modelli
Le API cloud offrono modelli chiusi di frontiera; l'on-premise significa modelli open-weight. Quel divario si è ristretto drammaticamente — per Q&A sui documenti, riassunti, estrazione, redazione e assistenti fondati su RAG, i modelli aperti moderni sono semplicemente sufficienti — ma non si è chiuso sulla frontiera del ragionamento più duro. La conseguenza pragmatica non è "scegli una parte": è il routing. Servi il grosso delle richieste sul tuo modello aperto; fai escalation di quelle davvero difficili a una API cloud sotto una regola di classificazione dei dati (niente di sensibile nel percorso di escalation). Molti deployment "on-prem" sono in realtà 95%-on-prem-con-valvola-di-sfogo, ed è il design giusto.
Gravità dei dati e lock-in
Due forze strutturali plasmano la decisione più di qualsiasi lista di funzioni. Gravità dei dati: l'inferenza vuole vivere dove vivono i dati — se documenti, MES o ERP sono on-prem, spedire il contesto di ogni query a una API cloud costa latenza, egress e revisioni di compliance; se tutto è già in un tenant cloud, l'AI on-prem significa spostare i dati all'indietro. Lock-in: quello a forma di API (funzioni proprietarie, fine-tune che non puoi esportare, framework agentici legati a un vendor) si accumula in silenzio. L'antidoto costa poco: sviluppa contro il formato API compatibile OpenAI (ogni motore locale lo parla), tieni prompt ed eval nel tuo repo, e una volta a trimestre fai girare il tuo eval set su un modello aperto corrente — quel numero è la tua opzione di uscita, e rafforza ogni negoziazione sul prezzo.
Compliance e sovranità (l'angolo UE)
Per le organizzazioni europee è spesso il fattore decisivo. GDPR, regole di settore (sanità, finanza, PA) e preoccupazioni di sovranità possono richiedere che dati personali o sensibili non lascino mai una giurisdizione controllata — e l'esposizione geopolitica dei provider cloud esteri è ormai un tema da consiglio d'amministrazione. L'on-premise (o cloud sovrano/UE) rende la garanzia semplice da dimostrare. L'EU AI Act non impone l'on-premise — si applica per livello di rischio — ma il self-hosting rende molto più facili i suoi obblighi probatori (logging, governance dei dati, versioning del modello); vedi la nostra guida all'AI Act.
Sicurezza: sfatare un mito
"L'on-premise è più sicuro" è vero solo a metà. I grandi cloud investono enormemente in sicurezza e sono spesso più solidi di un piccolo server gestito in proprio. Ciò che l'on-premise ti dà è controllo e giurisdizione — i dati restano fisicamente sotto la tua governance — non automaticamente più sicurezza. Una macchina on-prem mal mantenuta è meno sicura di un tenant cloud ben configurato. E ricorda l'immagine speculare sull'affidabilità: il cloud ti dà uno SLA; on-prem, lo SLA sei tu — ridondanza, ricambi e il guasto alle 2 di notte sono tuoi. Scegli l'on-prem per controllo e compliance, e poi finanzia come si deve la sua sicurezza e le sue operazioni.
Pattern ibridi che funzionano davvero
- Base + burst: possiedi il cluster di inferenza per il carico stazionario; noleggia GPU cloud per picchi e training una tantum.
- Routing per sensibilità: le classi di dati classificate non escono mai; i carichi su dati pubblici possono usare le API. Applicato nel gateway, non nei documenti di policy.
- Routing per difficoltà: prima il modello aperto, API di frontiera per le richieste segnalate difficili (con la regola di sensibilità applicata prima).
- Training nel cloud, inferenza on-prem: fine-tuning su GPU 80GB a noleggio per un weekend, deploy dell'adapter sul tuo hardware per sempre.
- Dev nel cloud, prod on-prem: sperimenta alla velocità del cloud; promuovi i carichi stabili sul ferro di proprietà dove economia e governance sono migliori.
Tre scenari, passo passo
- Banca regionale, assistente sui documenti clienti → on-prem (o cloud sovrano): classi di dati e aspettative del regolatore decidono prima ancora che parta la matematica dei costi; il batching tra reparti fa comunque tornare i conti.
- Azienda manifatturiera, copilot di stabilimento → edge on-prem: latenza di fabbrica, isolamento di rete e protezione dell'IP puntano tutti al locale; un modello piccolo fine-tuned su un box a singola GPU per sito.
- Startup SaaS, funzioni AI → prima API cloud: la velocità di mercato domina; adotta l'igiene di portabilità qui sopra, e rivaluta il rimpatrio quando la bolletta API ha tre zeri al mese e il carico si è stabilizzato.
Checklist decisionale
- Classifica i carichi per sensibilità dei dati — dati vincolati alla residenza → on-prem/sovrano per quei dati, non negoziabile.
- Stima l'utilizzo per carico — alto e costante → possedere migliora; a picchi → noleggiare vince.
- Verifica i requisiti di modello — serve ragionamento di frontiera → tieni un percorso cloud; lavoro di routine fondato su RAG → i modelli aperti bastano.
- Individua la gravità dei dati — metti l'inferenza dove i dati già vivono.
- Audita onestamente la capacità ops — nessun team per l'hardware → cloud o gestito, qualunque cosa dica il foglio di calcolo.
- Risposte miste (lo saranno) → progetta lo split ibrido per carico, e costruisci il livello di portabilità dal giorno uno.