Cloud vs On‑Prem per LLM: quando il TCO ti tradisce

Quando entro in una discussione “cloud o on‑prem?”, la prima cosa che faccio è togliere l’ideologia. La domanda vera è: quanto ti costa produrre una decisione affidabile, a un livello di rischio accettabile, con un costo prevedibile.

Il problema è che spesso la scelta nasce da una metrica sbagliata: “quanto costa 1k token”. È utile, ma è una parte piccola. Il TCO reale include latenza, qualità, retry, logging, sicurezza, incidenti, processi di approvazione, e soprattutto l’exit: quanto ti costa cambiare stack tra 12 mesi se il prezzo o il rischio cambiano.

In questo articolo condivido il modello mentale che uso con CEO, CIO e procurement: pochi concetti, ma applicabili subito. L’obiettivo è evitare il copione più comune: pilot economico, produzione cara, e poi anni a “ottimizzare” qualcosa che era nato con fondamenta sbagliate.

1) Il TCO ti tradisce quando misuri solo il prezzo del modello

Il costo che vedo più spesso sottostimato è quello che chiamo cost-to-trust: quanto spendi per arrivare a un output che un team è disposto a usare senza paura. Se la qualità è instabile, paghi in due valute: più consumo (retry, prompt più lunghi, modelli più grandi) e più tempo umano (review, correzioni, escalation).

Questo è il motivo per cui un sistema “economico” può diventare caro: non perché il modello costa tanto, ma perché l’organizzazione non si fida e quindi introduce frizione. L’AI non è un costo a token: è un costo per decisione o per caso risolto.

Prima di confrontare cloud e on‑prem, definisco sempre l’unità di valore. Alcuni esempi concreti:

• Customer support: costo per ticket risolto + p95 + escalation rate.
• Procurement / Legal: costo per contratto analizzato + error rate + audit trail.
• Operations: costo per decision memo + time‑to‑decision + rework.

Se non fai questo passo, finisci a ottimizzare i token mentre stai perdendo soldi nel punto più caro: il lavoro umano e il rischio reputazionale.

2) Variabile vs fisso: la soglia di pareggio dipende dall’utilizzo reale

Il cloud compra elasticità. L’on‑prem compra prevedibilità. Il break‑even non dipende da “quale è più moderno”, ma da quanta domanda hai, quanto è stabile, e quanto vale la latenza.

La domanda che faccio sempre è brutale: quanta parte del tempo la GPU (o l’endpoint) lavora davvero? Se la risposta è “poco”, l’on‑prem è un asset sottoutilizzato. Se la risposta è “molto”, il cloud rischia di diventare un rubinetto aperto.

Per stimare, mi basta una scheda semplice (anche in mezz’ora):

• Volume: richieste/giorno + token medi + variabilità settimanale.
• Picchi: concurrency e finestre di carico (es. 9–12, 14–18).
• SLO: p95 target e tasso massimo di degradazione accettabile.
• Dati: PII/segreti, retention, egress, audit richiesto.
• Durata: progetto “3 mesi” o capability “3 anni”.

Con questi numeri puoi già fare un confronto sensato usando un modello semplice: costo variabile (token + servizi) vs costo fisso (capex/opex + team). Se vuoi una scorciatoia pragmatica, puoi usare il mio TCO Calculator per simulare scenari e soglie di pareggio.

3) I tre costi “nascosti” del cloud che esplodono in produzione

Nel pilot il cloud vince quasi sempre: setup rapido, zero capex, time‑to‑demo. In produzione però arrivano tre voci che, se non le metti nel modello, ti fregano.

• Governance & logging: tracciare prompt/risposte (con redaction), retention, accessi, audit trail. È costo di storage + costo di processo.
• Dati & egress: duplicazioni, trasferimenti, integrazioni. Il costo non è solo “bandwidth”: è il rischio di confini non chiari.
• Qualità operativa: rate limiting, fallback, canary, monitoraggio. Se non li fai, paghi in incidenti; se li fai, paghi in engineering.

Il punto non è “il cloud è caro”: è che il cloud rende facile iniziare e quindi facile iniziare senza discipline. E quando la disciplina arriva (procurement, CISO, audit), il conto arriva insieme.

4) On‑prem non è “comprare GPU”: è trasformare l’infrastruttura in prodotto

L’on‑prem vince solo se lo tratti come un prodotto interno: SLO, runbook, ownership, capacity planning. Senza questo, diventa un costo fisso e un rischio.

Quando invece è fatto bene, l’on‑prem dà tre vantaggi che in contesti regolati sono enormi: confini chiari (dati dentro), latenza controllata, costo unitario stabile. È il motivo per cui molte aziende mature scelgono una Reference Architecture e la replicano per use case.

Il vero “segreto” per non sprecare soldi on‑prem è l’utilizzo: multi‑tenant, batching dove possibile, caching, e un modello di osservabilità che ti dica cosa costa ogni workflow. Se non misuri, stai solo sperando.

5) La scelta più razionale (spesso) è ibrida, ma con confini espliciti

Nella pratica, vedo spesso una soluzione ibrida che riduce rischio e mantiene velocità: on‑prem per inference sui dati sensibili, cloud per burst o per componenti non critiche.

Il punto chiave è definire confini che procurement e security possano “firmare”: quali dati possono uscire, quali no; quali log sono obbligatori; qual è il fallback; come gestisci incidenti e regressioni. Un ibrido senza confini è solo complessità doppia.

6) Checklist procurement‑ready: 12 domande che io faccio sempre

Se vuoi evitare sorprese (costi e governance) porta queste domande al tavolo prima di firmare. Sono semplici, ma separano chi “compra AI” da chi costruisce una capability.

• Unit economics: qual è il costo per decisione/ticket/caso, non per token?
• Peak pricing: quanto paghi nei picchi? c’è un cap o un budget guardrail?
• Logging: che log puoi salvare, con che redaction, e chi li vede?
• Retention: per quanto tempo puoi/ devi conservare le evidenze?
• Data boundary: cosa esce dal perimetro e cosa resta dentro?
• Sub‑processor: chi tocca i dati (direttamente o indirettamente)?
• Portabilità: quanto è facile spostare prompt, policy, eval, e dataset?
• Exit plan: in 30 giorni cosa puoi migrare senza perdere continuità?
• SLO: p95, disponibilità, degrado: cosa è “accettabile” e cosa no?
• Incident response: runbook e tempi: chi chiami alle 2 di notte?
• Security: SSO, ruoli, key mgmt, isolamento tenant, rate limiting.
• Change control: come gestisci cambi modello/versione senza regressioni?

Takeaway (da portare in board)

• Il costo reale è cost-to-trust: qualità e governance pagano o risparmiano molto più dei token.
• Il break‑even cloud/on‑prem dipende dall’utilizzo reale, non dal prezzo “di listino”.
• In produzione, governance e logging non sono opzionali: sono parte del TCO.
• L’ibrido funziona solo con confini espliciti e ownership chiara.

Conclusione: scegli il modello economico prima della tecnologia

Cloud e on‑prem sono strumenti. La scelta giusta è quella che ti dà: costo unitario prevedibile, rischio governabile, e velocità di iterazione. Se misuri solo “token”, stai guardando la metrica sbagliata.

Se vuoi, posso aiutarti con un Assessment Strategico rapido: in due settimane costruiamo un modello TCO procurement‑ready, definiamo confini (dati, logging, governance), e disegniamo un’architettura replicabile. Scrivimi qui.