Perché l'AI on-premise non è un passo indietro

Il presupposto del cloud

A un certo punto dell'ultimo decennio, l'industria della tecnologia enterprise ha interiorizzato un'equazione semplice: cloud uguale moderno, on-premise uguale legacy. Per molti carichi di lavoro è vero. Per l'AI nei settori regolamentati è pericolosamente sbagliato.

Quando un'organizzazione mette in produzione un LLM su un hyperscaler, non sta solo noleggiando capacità di calcolo. Sta facendo passare i suoi dati più sensibili (cartelle cliniche, formulazioni farmaceutiche, transazioni finanziarie) su un'infrastruttura che non controlla, regolata da condizioni di servizio che non può negoziare, in giurisdizioni che potrebbe non conoscere fino in fondo.

Di cosa hanno davvero bisogno i settori regolamentati

Il GDPR, l'AI Act (Regolamento UE 2024/1689), la Legge 132/2025 e la NIS2 creano un quadro normativo in cui le organizzazioni devono dimostrare un controllo verificabile sui propri sistemi AI. Significa sapere, ed essere in grado di provare, dove risiedono i dati, come i modelli li trattano, chi vi ha accesso e come sono governati gli output.

Il deployment on-premise non è una preferenza filosofica. È la strada più diretta per soddisfare questi requisiti. Quando l'intero stack AI gira dentro il perimetro dell'organizzazione, la residenza dei dati è garantita dall'architettura, non da un contratto. Gli audit trail sono sotto il controllo dell'organizzazione, non del fornitore. E la superficie di attacco per l'esfiltrazione dei dati si riduce a ciò che l'organizzazione gestisce direttamente.

Il mito delle prestazioni

Un'obiezione frequente è che l'AI on-premise non possa eguagliare le prestazioni del cloud. Cinque anni fa era vero. Oggi motori di inferenza come vLLM offrono un throughput da produzione su hardware GPU di largo consumo. Vector database come Weaviate girano in modo efficiente su normali cluster Kubernetes. Per la grande maggioranza dei casi d'uso enterprise il divario di prestazioni si è chiuso.

Quello che non si è chiuso è il divario di governance. Nessuna quantità di certificazioni di conformità del cloud può sostituire la certezza che deriva dal fatto che i dati non escono mai dal tuo edificio.

L'equazione dei costi: cloud o on-premise per i carichi AI

L'idea che l'AI in cloud costi meno merita una verifica. Per i carichi dominati dall'inferenza, quelli che le organizzazioni sanitarie eseguono ogni giorno, il costo delle GPU in cloud cresce in modo lineare con l'uso. Un'organizzazione che fa girare più modelli (NLP clinico, estrazione da documenti, AI conversazionale) paga ogni ora di calcolo GPU, prima di storage e costi di egress.

L'hardware GPU on-premise, anche di classe enterprise, è un investimento che si ammortizza in più anni. Dopo l'investimento iniziale, il costo marginale di un'inferenza in più è basso. Per le organizzazioni con carichi AI prevedibili e continuativi esiste un punto di svolta del costo totale di possesso (TCO) oltre il quale l'on-premise costa meno; dove cade dipende da volumi, hardware e utilizzo, e va calcolato sul caso.

C'è poi un costo nascosto dell'AI in cloud che compare di rado nei calcoli del TCO: il lock-in sul fornitore. Spostare una pipeline AI in produzione da un hyperscaler a un altro è un progetto che si misura in mesi, non in giorni. Un'infrastruttura on-premise costruita su standard aperti (Kubernetes, container OCI, storage compatibile S3) lascia all'organizzazione libertà di scelta.

La residenza dei dati in pratica: cosa chiedono davvero le norme UE

Il GDPR richiede che i dati personali trasferiti fuori dall'UE godano di garanzie adeguate. L'AI Act (Regolamento UE 2024/1689) aggiunge requisiti specifici per i sistemi AI: i dati usati per addestramento, test e inferenza vanno gestiti con processi di governance documentati. La Legge 132/2025 non impone la residenza dei dati: l'unica norma in quella direzione è una preferenza non vincolante, per le piattaforme di e-procurement della PA, verso soluzioni che tengono i dati strategici in data center sul territorio nazionale (art. 5, comma 1, lett. d). La residenza è una scelta di progetto che rende il controllo più facile da dimostrare, non un obbligo di legge.

In pratica "residenza dei dati" significa più che tenere i dati su server nell'UE. Significa che l'intera pipeline di elaborazione (ingestion, embedding, archiviazione vettoriale, inferenza e consegna della risposta) gira in un ambiente sotto controllo giurisdizionale. Un deployment in cloud in cui i dati stanno a Francoforte ma l'inferenza gira in Virginia non rispetta questo standard, anche se lo storage tecnicamente risiede nell'UE.

Il deployment on-premise elimina del tutto questa ambiguità. Quando l'intero stack AI gira su hardware che l'organizzazione possiede e gestisce, la residenza dei dati è garantita dalla fisica, non da clausole contrattuali. Non è un argomento filosofico: è la differenza tra una postura di compliance che dipende da attestazioni di terzi e una che l'organizzazione può verificare da sola.

Pattern di implementazione: passare dal cloud all'AI on-premise

Le organizzazioni non devono migrare tutto in una volta. Le transizioni che abbiamo guidato seguono un approccio per fasi:

• Fase 1 — Assessment: mappare i carichi AI esistenti, classificare la sensibilità dei dati e individuare quali carichi devono passare on-premise per ragioni normative e quali possono restare in cloud.
• Fase 2 — Fondamenta: installare l'infrastruttura on-premise (cluster Kubernetes, nodi GPU, livello di storage).
• Fase 3 — Migrazione: spostare per primi i carichi più sensibili (AI clinica, sistemi rivolti ai pazienti). Mantenere il cloud per i carichi non sensibili durante la transizione.
• Fase 4 — Ottimizzazione: mettere a punto le prestazioni di inferenza, introdurre l'osservabilità e definire i runbook operativi per lo stack on-premise.

Il punto chiave è che AI on-premise non significa costruire da zero. Piattaforme moderne come Nexus MDS Core offrono uno stack già integrato, così il deployment non parte da zero. Buona parte della complessità operativa che storicamente rendeva proibitiva l'AI on-premise oggi la gestisce la piattaforma.

Come si presenta l'AI sovrana nella pratica

Nexus MDS Core è la nostra risposta a questa sfida: 27 servizi in container (inferenza LLM locale con llama.cpp, pipeline RAG con Weaviate, autenticazione Zero-Trust con Keycloak, motore di workflow n8n, un audit con catena di hash di ogni chiamata al modello) che girano su Docker dentro il perimetro dell'organizzazione, con la generazione su un modello locale o su un endpoint UE sostituibile. È già in produzione per Federfarma Lombarda e per due servizi in ambito sanitario, CureSicure e HumanIA Care.

Per le organizzazioni sanitarie che stanno valutando la propria strategia AI, la decisione architetturale non è cloud contro on-premise in astratto. È una domanda concreta: il tuo modello di deployment attuale può soddisfare i requisiti normativi che hai davanti oggi e quelli in arrivo nei prossimi 18 mesi? Se la risposta è incerta, l'on-premise merita una valutazione seria.

L'AI on-premise non è un passo indietro. È l'architettura che prende sul serio la compliance, la sovranità dei dati e l'autonomia dell'organizzazione. Per i settori regolamentati è l'unica architettura che abbia senso. Leggi il nostro approfondimento sull'AI on-premise per la sanità per una prospettiva dettagliata sull'implementazione, oppure esplora la piattaforma Nexus MDS Core per vedere l'architettura nel dettaglio.