Hai deciso di provare l’AI in azienda. Ottimo. Poi arriva la domanda che blocca tutto: dove gira il modello?
Cloud pubblico, API di OpenAI o Anthropic, server in casa, qualcosa di ibrido. Ognuno ha un’opinione. I vendor spingono la loro soluzione. Il consulente IT dice una cosa, il commerciale del provider ne dice un’altra.
In realtà la scelta dipende da quattro variabili concrete: che dati usi, quante query fai, che team hai e quanto sei disposto a investire oggi. Questa guida ti aiuta a capire qual è il modello giusto per te — senza promesse assolute e senza terrorismo sulla sicurezza.
In breve
Per una PMI manifatturiera con dati sensibili (disegni tecnici, listini, procedure qualità), la scelta tra cloud, API e on-premise dipende principalmente da tre fattori: il tipo di dato coinvolto, il volume di utilizzo previsto e la maturità operativa del team interno. Non esiste un’architettura universalmente migliore. Esiste quella giusta per il tuo caso d’uso, in questo momento.
Le tre architetture: cosa sono davvero
Prima di decidere, è utile capire di cosa parliamo — senza gergo.
API cloud (es. OpenAI, Anthropic, Google)
Mandi una richiesta a un server esterno, ricevi una risposta. Paghi per quello che usi, di solito a token. Setup rapido, zero infrastruttura da gestire. I dati passano fuori dalla tua rete. In un contesto manifatturiero, questa architettura va bene per un assistente su catalogo prodotti standard o per rispondere a domande su schede tecniche pubbliche — dove il dato che entra nel sistema non è riservato e il rischio di esposizione è contenuto.
Cloud privato o VPC (Virtual Private Cloud)
Il modello gira su infrastruttura cloud, ma isolata e dedicata alla tua organizzazione. Più controllo rispetto all’API pubblica, ma pur sempre infrastruttura di terzi. È la scelta che ha senso quando l’AI deve leggere ordini di produzione con riferimenti cliente, accedere a un ERP con dati di commessa o ragionare su documentazione tecnica interna: il dato è sensibile, il volume non giustifica ancora l’hardware in casa, ma servono garanzie di isolamento che l’API pubblica non offre.
On-premise (modello in casa)
Il modello gira su hardware tuo, nella tua sede o in un datacenter che controlli. I dati non escono dalla tua rete. Costo concentrato sull’investimento iniziale, nessun canone ricorrente per il modello in sé. È l’architettura che si considera quando il sistema deve elaborare disegni CAD, formule di processo, capitolati con clienti strategici o listini riservati: materiali dove il rischio non è solo normativo, ma competitivo, e dove l’azienda non vuole che nulla esca dalla propria infrastruttura per nessuna ragione.
La maggior parte delle aziende enterprise arriva a un modello ibrido: cloud per sperimentare e per carichi variabili, on-premise per i processi ad alta frequenza o con dati critici. Ma partiamo dall’inizio.
Il primo criterio: che dati stai mettendo nel sistema
Questa domanda viene prima di tutto il resto.
Se stai pensando di usare l’AI per rispondere a domande sui prodotti del catalogo pubblico, il dato è basso, il rischio è basso, una API cloud va benissimo. Se invece vuoi che l’AI legga i tuoi capitolati tecnici, i disegni CAD, i listini riservati o le procedure qualità, il discorso cambia completamente.
Il GDPR (art. 28) richiede un Data Processing Agreement con qualsiasi terza parte che elabora dati personali per tuo conto — inclusi i provider di API cloud. I modelli locali eliminano questo requisito interamente: nessun DPA, nessun meccanismo di trasferimento ex art. 46, nessun flusso transfrontaliero. È un dato normativo, non un’opinione.
In più, c’è un aspetto che nelle aziende manifatturiere viene spesso sottovalutato: il know-how industriale non è dato personale, ma è spesso più prezioso. Un disegno di produzione, una formula di processo, un capitolato con un cliente strategico — se finiscono in un sistema cloud che non controlli, il rischio non è solo normativo. È competitivo.
"55% of enterprises avoid at least some AI use cases due to data security concerns." — Deloitte survey, citata in Allganize, 2026.
Il punto non è fare terrorismo. Il punto è che la scelta dell’architettura è prima di tutto una decisione di governance, non una decisione tecnica.
Il secondo criterio: quante query fai davvero
Qui entrano i numeri — e i numeri cambiano tutto.
L’analisi TCO pubblicata da SitePoint (agosto 2026) su prezzi hardware di metà 2025 e rate card pubbliche dei provider lo mostra in modo chiaro. I costi variano in modo significativo tra i principali provider: OpenAI GPT-4.1, Anthropic Claude e Google Gemini hanno strutture di prezzo diverse, e la forchetta di mercato per modelli di fascia equivalente si muove in un range che può variare del 30-50% tra un provider e l’altro. Confrontare solo un singolo benchmark è una trappola.
| Volume giornaliero | API cloud (forchetta di mercato) | On-premise consumer | Note |
|---|---|---|---|
| 500K token/giorno | ~900–1.400$/anno | ~6.457$/anno | Cloud nettamente più economico |
| 5M token/giorno | ~9.000–14.000$/anno | ~18.387$/anno | Il divario si riduce |
| 50M token/giorno | ~90.000–140.000$/anno | TCO a 36 mesi vantaggioso | On-premise diventa competitivo |
La forchetta cloud nella tabella rappresenta la variazione reale tra i principali provider (OpenAI, Anthropic, Google) su modelli di capacità equivalente, basata sulle rate card pubbliche disponibili a metà 2026. Prima di scegliere un provider specifico, verifica sempre la tariffa aggiornata sul sito ufficiale: i prezzi cambiano con frequenza.
Attenzione: questi numeri includono hardware, elettricità, ammortamento e lavoro operativo. Confrontare solo il costo per token è una trappola, perché mancano tutti i costi nascosti.
Un avvertimento specifico: i costi dell’elettricità in Europa (0,25-0,30$/kWh) spostano il punto di pareggio del 40-60% in più rispetto ai benchmark americani. Questo significa che per un’azienda italiana, il volume necessario perché l’on-premise diventi economicamente conveniente è più alto di quanto dicano molte analisi generaliste.
La regola empirica che emerge dall’analisi Lyzr (luglio 2026) è questa: quando i costi cloud raggiungono il 60-70% di quanto costerebbe hardware equivalente on-premise nello stesso periodo, l’on-premise inizia a diventare competitivo — anche includendo capex e overhead operativo.
Per volumi bassi o medi, e soprattutto per chi sta ancora sperimentando, le API cloud restano la scelta più razionale. Il capex iniziale di un setup on-premise non si giustifica se non hai ancora validato il caso d’uso.
Il terzo criterio: che team hai e quanto puoi gestire
Un modello on-premise non si installa e dimentica.
Richiede qualcuno che lo gestisca: aggiornamenti, monitoraggio, sicurezza dell’infrastruttura locale, integrazione con i sistemi esistenti. Non è un costo enorme, ma è un impegno reale e misurabile. In un contesto manifatturiero tipico — un assistente documentale su procedure qualità o un sistema RAG su specifiche tecniche — la stima realistica è di almeno 4-8 ore a settimana di un profilo con competenze sistemistiche, più il tempo di setup iniziale che può variare da qualche giorno a qualche settimana a seconda della complessità dell’integrazione con l’ERP e i repository documentali esistenti. Sotto questa soglia di disponibilità interna, affidarsi a un fornitore esterno dedicato per la gestione operativa non è un’opzione: è una condizione.
Le API cloud, al contrario, scaricano tutta la gestione infrastrutturale sul provider. Paghi di più per token, ma non hai overhead operativo interno.
"La qualità del modello dipende dalla potenza di calcolo disponibile in locale, quindi va dimensionata sul caso d’uso reale, non sulla demo più spettacolare." — Progetto Impresa, 2026.
Questo è un punto che vediamo spesso nella pratica: l’azienda si entusiasma per una demo fatta con un modello cloud di fascia alta, poi installa on-premise qualcosa di dimensionato male e rimane delusa dai risultati. Non è un problema dell’on-premise in sé — è un problema di dimensionamento.
Se scegli on-premise, il progetto tecnico deve stimare correttamente hardware, tempi di setup e formazione. Non si improvvisa, ma non è nemmeno impossibile — soprattutto per i casi d’uso manifatturieri più comuni (assistente documentale, Q&A su procedure qualità, supporto alla redazione di offerte).
Come decidere: la matrice pratica
Questa è la sintesi operativa, basata sui criteri sopra e su quanto emerge dalle analisi disponibili. Le righe della matrice usano processi manifatturieri reali come discriminante — non categorie generiche.
| Processo / caso d’uso | Architettura consigliata |
|---|---|
| Chatbot su catalogo prodotti standard o schede tecniche pubbliche | API cloud |
| RAG su documentazione tecnica riservata (manuali, capitolati, procedure qualità) | Cloud privato/VPC o on-premise |
| Pianificazione produzione con accesso a ordini, commesse o listini cliente | Cloud privato/VPC con DPA verificato, o on-premise |
| Elaborazione di disegni CAD, formule di processo, know-how di produzione | On-premise — il dato non dovrebbe uscire dalla rete aziendale |
| Assistente operatore su linea con requisiti di latenza bassa (sub-50ms) | On-premise o edge: il cloud introduce latenza variabile non compatibile con certi cicli di produzione |
| Sperimentazione iniziale su dati non critici, volume basso | API cloud — validare il caso d’uso prima di investire in hardware |
Un chiarimento importante: scegliere on-premise non significa automaticamente essere "sicuri". Un server mal configurato in azienda è più vulnerabile di un cloud gestito bene. La sicurezza dipende da come il sistema è progettato e gestito, non solo da dove gira il modello. Per gli aspetti di sicurezza informatica e conformità normativa, coinvolgere professionisti specializzati è sempre la scelta corretta.
Il nodo degli incentivi: un fattore che molti ignorano
Per le aziende manifatturiere italiane c’è un elemento che può cambiare i conti in modo significativo: gli incentivi fiscali.
Nel 2026, Transizione 5.0 e il credito d’imposta per investimenti in beni strumentali possono abbattere il capex iniziale di un’infrastruttura on-premise in modo rilevante. I costi di infrastruttura on-premise, inoltre, possono essere capitalizzati e ammortizzati — un vantaggio fiscale non disponibile nel modello pay-as-you-go cloud.
Questo non cambia la logica della scelta, ma può spostare il punto di pareggio economico. Vale la pena verificare con il proprio consulente fiscale prima di escludere l’on-premise per ragioni di budget.
Cosa facciamo noi prima di consigliare qualcosa
In Fabrika 06 partiamo sempre dal processo e dai dati, non dall’architettura.
Prima di scegliere se usare un’API cloud, un cloud privato o un modello in casa, valutiamo quali dati entrano nel sistema, con quale frequenza, e che rischio comporta esporli. Confrontiamo le architetture disponibili su quel caso d’uso specifico. Progettiamo i controlli, i permessi e la supervisione umana. Documentiamo i test, i risultati e i limiti.
Quando possibile, partiamo da un caso d’uso circoscritto e misurabile — spesso con dati a rischio contenuto — per validare l’approccio prima di estenderlo.
Per le valutazioni legali e di sicurezza informatica, lavoriamo con professionisti specializzati. Non è un’opzione: è parte del metodo.
Prenota la tua AI Opportunity Sprint gratuita: portami un processo lento e capiamo insieme da dove partire, quale architettura ha senso e quali dati sono davvero a rischio. → https://www.fabrika06.com/ai-opportunity-sprint/
Domande frequenti
Posso usare le API cloud con i dati riservati della mia azienda?
Dipende dal provider, dal piano e dal contratto. OpenAI, Anthropic e Google dichiarano nei rispettivi piani business di non usare i dati per addestrare i modelli, ma le condizioni variano tra provider e possono cambiare nel tempo. Prima di processare dati sensibili tramite qualsiasi API cloud, verifica la data-use policy del tuo tier specifico presso ciascun fornitore e assicurati di avere un Data Processing Agreement in regola. Per i dati più critici — disegni, listini, know-how di produzione — è prudente non affidarsi solo alle dichiarazioni del provider, indipendentemente da chi sia.
L'on-premise è sempre più sicuro del cloud?
No, non necessariamente. Un server on-premise mal configurato o non aggiornato può essere più vulnerabile di un'infrastruttura cloud gestita da un provider con team di sicurezza dedicati. La sicurezza dipende da come il sistema è progettato, configurato e monitorato — non solo da dove si trova fisicamente. Prima di scegliere on-premise per ragioni di sicurezza, valuta anche la tua capacità di gestirlo correttamente.
Quanto costa davvero un setup on-premise per una PMI manifatturiera?
Dipende dal volume di utilizzo e dal caso d'uso. Per volumi leggeri (sotto i 2-3 milioni di token al giorno), le API cloud sono quasi sempre più economiche nel breve periodo. Il capex iniziale di un setup on-premise si giustifica su volumi alti e su orizzonti temporali di 2-3 anni. In Italia, gli incentivi Transizione 5.0 e il credito d'imposta possono ridurre significativamente il costo iniziale: vale la pena quantificarli prima di decidere.
Cosa succede se cambio idea sull'architettura dopo sei mesi?
È un rischio reale, soprattutto con sistemi agentici complessi. Prima di costruire qualcosa di esteso, verifica la portabilità dei tuoi dati e dei tuoi workflow. Con le API cloud il cambio è generalmente più semplice. Con on-premise, l'investimento hardware è già fatto. Per questo si consiglia di partire da un caso d'uso circoscritto e validare l'architettura prima di estenderla a tutta l'azienda.
Un modello locale è abbastanza bravo per i processi manifatturieri?
Per i casi d'uso più comuni — assistente su documentazione tecnica, Q&A su procedure qualità, supporto alla redazione di offerte — i modelli locali di fascia media (13-30 miliardi di parametri, dimensionati correttamente) sono adeguati. Per ragionamento complesso o generazione creativa, i modelli frontier cloud mantengono un vantaggio. La chiave è dimensionare il modello sul caso d'uso reale, non sulla demo più impressionante.
Da dove si inizia se non ho mai fatto nulla di questo tipo?
Si inizia da un caso d'uso specifico, preferibilmente con dati a rischio contenuto. Si valuta quale architettura è appropriata per quel caso. Si costruisce un piccolo pilota misurabile. Solo dopo, se funziona, si estende. Partire dall'architettura — decidere "facciamo on-premise" prima di sapere cosa si vuole fare — è uno degli errori più comuni e costosi.
