LLM On-Premise contro API cloud europee: pianificazione VRAM, sovranità dei dati, GDPR ed EU AI Act

Aggiornato a novembre 2026 · CODLAB Team

Risposta diretta: La scelta tra modelli linguistici on-premise e API cloud europee dipende da riservatezza dei dati, profilo di carico e capacità operativa interna. La vera sovranità dei dati richiede la verifica dell'intero flusso dagli embedding ai backup, il dimensionamento della memoria GPU per il KV-cache e interfacce portabili conformi a GDPR ed EU AI Act.

1. Perché i soli «pesi aperti» non bastano a garantire la sovranità dei dati

Nella pianificazione infrastrutturale per le PMI occorre evitare due semplificazioni opposte: pensare che scaricare un modello a pesi aperti (open weights, come le famiglie Llama o Mistral) risolva automaticamente ogni profilo di riservatezza, oppure liquidare qualsiasi API esterna come una perdita totale di controllo. Entrambe le scorciatoie trascurano il funzionamento concreto di un'architettura in produzione.

La sovranità digitale non è un attributo del file dei pesi neurali, ma una proprietà dell'intero percorso tecnico e organizzativo dei dati. Nella ricerca applicata di CODLAB su sistemi IA sovrani analizziamo sempre sette passaggi distinti prima di consigliare una topologia infrastrutturale:

1. Ingresso di rete e terminazione TLS: il traffico cifrato termina direttamente nella rete controllata dall'azienda o attraversa proxy e CDN esterni?
2. Estrazione documentale e calcolo degli embedding: i PDF aziendali vengono segmentati e vettorializzati localmente oppure inviati a un servizio di embedding esterno pur avendo il modello generativo in casa?
3. Indice vettoriale e metadati dei permessi: vettori e filtri di autorizzazione risiedono su database PostgreSQL controllati in Germania o nell'Unione Europea (cfr. pgvector con Django)?
4. Inferenza del modello linguistico (serving): la generazione dei token avviene nel data center aziendale, su nodi GPU dedicati in Europa o tramite un'API multi-tenant europea — verificando separatamente sia l'esclusione contrattuale dell'uso per addestramento (no-training) sia l'effettiva zero-data-retention (assenza di conservazione temporanea di prompt e risposte presso il fornitore)?
5. Log applicativi e telemetria: prompt, estratti documentali o tracce d'errore finiscono in piattaforme esterne di monitoraggio?
6. Copie di sicurezza (backup): dove vengono replicati gli snapshot cifrati dell'indice vettoriale e dei registri conversazionali, e chi detiene le chiavi?
7. Accessi di manutenzione e supporto: quali amministratori o sub-fornitori dispongono di accesso remoto all'host e da quali giurisdizioni operano?

Solo dopo aver mappato tutte e sette le stazioni è possibile compiere una scelta fondata, evitando slogan assoluti privi di riscontro ingegneristico.

2. Pianificare la memoria GPU oltre le stime ingenue: pesi, quantizzazione e KV-Cache

Quando un'organizzazione decide di gestire l'inferenza su proprie schede GPU in sede o su server dedicati europei, occorre passare dalle regole empiriche approssimative a una pianificazione rigorosa della memoria. Nelle nostre Engineering Notes, e in particolare nella nota Llama su GPU: pianificare la memoria prima di misurare, mostriamo perché la dimensione su disco di un checkpoint quantizzato non basta a garantire la tenuta sotto carico.

Il limite inferiore teorico occupato dai soli pesi si calcola moltiplicando il numero di parametri per i bit di precisione e dividendo per otto: per un modello da 70 miliardi di parametri a 4 bit equivale a circa 32,6 GiB (evitando accuratamente di confondere gigabyte decimali GB e gibibyte binari GiB nei fogli tecnici). Durante l'esercizio reale quattro ulteriori componenti assorbono memoria video (VRAM):

• Metadati di quantizzazione e differenze tra formati: schemi come AWQ e GPTQ conservano fattori di scala e punti di zero aggiuntivi. Inoltre GGUF, AWQ e GPTQ rispondono a motori d'esecuzione diversi: una sigla pensata per prove locali con llama.cpp non corrisponde automaticamente a una configurazione ottimale per vLLM.
• Buffer di runtime e grafi CUDA: il motore di serving pre-alloca spazio per le attivazioni intermedie già in fase di avvio del processo.
• Crescita dinamica del Key-Value Cache (KV-Cache): nella generazione autoregressiva il modello mantiene in memoria i vettori di attenzione (chiavi e valori) di ogni livello per tutti i token del contesto e della risposta. Contesti documentali estesi nel RAG moltiplicati per più richieste simultanee fanno crescere il consumo linearmente con lunghezza e concorrenza.
• Frammentazione della memoria sotto richieste parallele: i primi server di inferenza prenotavano blocchi contigui dimensionati sulla lunghezza massima teorica, sprecando gran parte della VRAM. L'allocazione paginata introdotta con PagedAttention in vLLM suddivide il KV-Cache in blocchi non contigui, abbatte la frammentazione e abilita il continuous batching ad alto rendimento (Kwon et al., SOSP 2023, arXiv:2309.06180).

Un ulteriore aspetto operativo essenziale (cfr. Esercizio, manutenzione ed evoluzione): installare una seconda GPU nello stesso telaio amplia la memoria complessiva per il parallelismo tensoriale, ma non crea alta affidabilità — un guasto all'alimentatore, alla scheda madre o un riavvio dell'unico host ferma comunque l'intero servizio.

3. Architettura senza lock-in: cosa serve davvero per rendere intercambiabili gli endpoint

Legare la logica applicativa, l'estrazione delle citazioni e i controlli sui permessi all'SDK proprietario di un singolo fornitore cloud crea una dipendenza inutile. Nei progetti RAG in Django di CODLAB separiamo perciò l'archivio locale in PostgreSQL dalle chiamate disaccoppiate al modello — distinguendo in modo trasparente il nostro assistente di riferimento (ragbot) nel codice di codlab.de (demo pubblica di chat spenta da ottobre 2026; codice e dati conservati) da una configurazione aziendale completamente commutabile.

Nel codice dell'assistente di riferimento (ragbot) la ricerca vettoriale coseno utilizza PostgreSQL con pgvector, i confini sulle fonti (cfr. confini delle fonti nel RAG) risiedono nel codice applicativo e ragbot/services.py predispone già la lettura di getattr(settings, "RAG_OPENAI_BASE_URL", ""). Nella configurazione consegnata di codlab.de, tuttavia, codlab_site/settings.py non collega ancora di default quella variabile d'ambiente e il medesimo client serve sia la generazione chat sia gli embedding. Per rendere davvero intercambiabili gli endpoint in un sistema aziendale servono quindi tre passaggi espliciti: collegare le variabili in settings.py, verificare la compatibilità dei parametri API OpenAI e separare il client di generazione da quello di embedding pianificando la re-indicizzazione completa qualora cambino modello di embedding o dimensioni del vettore (1536):

# Schema aziendale (estende l'aggancio predisposto in ragbot/services.py):
# 1. Collegare in settings.py: RAG_CHAT_BASE_URL = os.environ.get("RAG_CHAT_BASE_URL", "")
# 2. Separare client chat ed embedding; cambiare modello di embedding richiede re-indicizzazione!
from django.conf import settings
from openai import OpenAI

def build_chat_client():
    base_url = getattr(settings, "RAG_CHAT_BASE_URL", "") or None
    api_key = getattr(settings, "RAG_CHAT_API_KEY", "")
    kwargs = {"api_key": api_key}
    if base_url:
        # Esempio on-premise: "https://llm-interno.azienda.lan/v1" (vLLM)
        kwargs["base_url"] = base_url
    return OpenAI(**kwargs)

Con queste tre condizioni verificate si ottengono due vantaggi concreti: un pilota validato su un'API europea contrattualizzata può spostare la generazione delle risposte su nodi vLLM interni senza riscrivere la logica applicativa — mantenendo lo spazio di embedding esistente oppure eseguendo una re-indicizzazione controllata — e i nuovi modelli open-weights possono essere confrontati sullo stesso identico set di test.

4. Matrice decisionale concreta per PMI e studi soggetti a segreto professionale

Né il dogma «tutto in locale» né «tutto via API» regge a una verifica tecnica ed economica seria. Per progetti destinati alle PMI manifatturiere e di servizi e ad ambiti riservati come gli studi legali valutiamo quattro variabili insieme ai responsabili IT e ai consulenti legali:

• Grado di segretezza e vincoli deontologici: quando entrano in gioco disegni tecnici non brevettati, formule industriali, fascicoli del personale o pratiche coperte da segreto professionale, un ambiente on-premise isolato — oppure un nodo single-tenant europeo in cui l'accesso amministrativo di terzi e sub-fornitori sia escluso tecnicamente e contrattualmente — evita l'esposizione a infrastrutture condivise, sempre accompagnato dal vaglio formale dei consulenti legali e privacy competenti.
• Andamento del carico nella settimana lavorativa: un flusso costante di analisi documentale su molte postazioni ammortizza bene una GPU dedicata; al contrario, pochi picchi isolati lasciano l'hardware inattivo per gran parte del tempo pur generando costi fissi di energia, raffreddamento e manutenzione.
• Maturità operativa interna: un nodo vLLM locale richiede aggiornamenti regolari di sistema operativo, container e driver, monitoraggio di VRAM e latenze e procedure collaudate di ripristino.
• Complessità linguistica e sintesi: i modelli aperti compatti o medi lavorano molto bene su contesti RAG ben delimitati, mentre sintesi multi-documento complesse tra tedesco, italiano e inglese richiedono verifiche puntuali. Se un modello aperto quantizzato a 4 o 8 bit sia adeguato al compito viene stabilito tramite prove comparative multi-giro sullo stesso set di test.

5. GDPR ed EU AI Act a novembre 2026: cosa documentare sul piano tecnico

Collocare il server nella propria sala macchine non sottrae il sistema alle norme europee. A novembre 2026 la documentazione tecnica deve raccordarsi con due pilastri normativi:

1. Regolamento generale sulla protezione dei dati (GDPR): ogni trattamento di dati personali in prompt, documenti indicizzati o log deve rispettare gli articoli 5 e 6 GDPR tanto in locale quanto in cloud (Regolamento (UE) 2016/679). Il ricorso a fornitori API o hosting comporta accordi ex articolo 28, misure di sicurezza ex articolo 32, verifica degli eventuali accessi da Paesi terzi (Capo V) e, nei casi di rischio elevato, valutazione d'impatto preventiva (articolo 35 GDPR).
2. Scadenze graduali dell'EU AI Act (testo consolidato del 27.07.2026): il regolamento europeo sull'IA (Regolamento (UE) 2024/1689, versione consolidata del 27.07.2026 comprensiva del regolamento di modifica (UE) 2026/1744 dell'08.07.2026) lega gli obblighi alla finalità d'uso e al ruolo (fornitore o deployer), non alla sola ubicazione fisica del server. Ai sensi dell'articolo 113, i capi I e II (divieti e misure per l'alfabetizzazione IA ex articolo 4) si applicano dal 2 febbraio 2025 — ad eccezione dei nuovi divieti di cui all'articolo 5, paragrafo 1, primo comma, lettere ba) e bb), e all'articolo 5, paragrafi 1 bis e 1 ter, applicabili dal 2 dicembre 2026. Dal 2 agosto 2026 si applicano le disposizioni generali inclusi gli obblighi dell'articolo 50 (fatte salve le norme transitorie specifiche dell'articolo 111). Il rinvio al 2 dicembre 2027 (articolo 6, paragrafo 2, e Allegato III) e al 2 agosto 2028 (articolo 6, paragrafo 1, e Allegato I) introdotto nell'articolo 113, lettera c), dal Regolamento (UE) 2026/1744 riguarda specificamente il capo III, sezioni 1, 2 e 3, ad eccezione dell'articolo 6, paragrafo 5 — non indistintamente qualsiasi norma sui sistemi ad alto rischio.

L'Ufficio federale tedesco per la sicurezza informatica (BSI) descrive come rischio specifico il flusso o l'accesso a input e output verso il gestore di servizi online (R2); rischi quali l'Indirect Prompt Injection (R28) o le reazioni errate agli input (R3) restano indipendenti dal luogo di esercizio e richiedono presidi dedicati (BSI, Versione 2.0, 2025). Come traccia operativa per preparare il confronto con i vostri referenti legali e privacy mettiamo a disposizione la Guida all'EU AI Act (strumento di lavoro tecnico, non consulenza legale né certificazione di conformità).

6. Protocollo sintetico di valutazione prima dell'acquisto di GPU o contratti API

Nota metodologica: i quattro passaggi seguenti descrivono il nostro metodo decisionale riproducibile; non riportano numeri inventati su clienti, promesse di costo né benchmark hardware generici.

Prima di acquistare schede GPU o sottoscrivere contratti API pluriennali seguiamo quattro passi verificabili:

1. Mappatura delle sette stazioni del dato: inventario completo dall'ingresso di rete a embedding, pgvector, inferenza, log, backup e teleassistenza.
2. Calcolo dei margini VRAM e KV-Cache: stima della soglia inferiore dei pesi, della finestra di contesto e della concorrenza massima secondo la nostra nota di pianificazione GPU.
3. Collaudo comparativo multi-giro: esecuzione della stessa batteria di domande di dominio e di rifiuto sia sul modello quantizzato candidato sia su un'API europea di riferimento tramite l'interfaccia unificata.
4. Piano di esercizio e continuità: definizione prima del rilascio di cicli di aggiornamento, soglie di allarme e comportamento in caso di guasto.

Per valutare in modo indipendente se per la vostra azienda sia più adatta un'infrastruttura GPU locale, un hosting europeo dedicato o un'architettura ibrida potete approfondire IA Sovrana e Dati o scriverci tramite Contatto e primo colloquio.

Approfondimenti nella serie di ricerca: per il disegno dell'indice e del ranking ibrido su PostgreSQL e pgvector rimandiamo allo studio su architettura RAG ibrida, chunking e reranking; per i presidi applicativi contro rischi indipendenti dalla sede di esercizio come R28 si veda l'analisi su sicurezza dei sistemi RAG e Indirect Prompt Injection.

Fonti primarie verificate

• Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L. et al. (2023): Efficient Memory Management for Large Language Model Serving with PagedAttention (SOSP 2023, arXiv:2309.06180).
• Ufficio delle pubblicazioni dell'UE (Cellar): Regolamento (UE) 2024/1689 (AI Act), versione consolidata del 27.07.2026, in particolare articoli 4, 50, 111 e 113.
• Ufficio delle pubblicazioni dell'UE (Cellar): Regolamento (UE) 2026/1744 dell’08.07.2026 (Regolamento Omnibus Digitale sull’IA).
• Ufficio delle pubblicazioni dell'UE (Cellar): Regolamento (UE) 2016/679 (GDPR / DSGVO), in particolare articoli 5, 6, 9, 28, 32, 35 e Capo V.
• Bundesamt für Sicherheit in der Informationstechnik / BSI (2025): Generative KI-Modelle — Chancen und Risiken für Industrie und Behörden, Versione 2.0 del 17.01.2025.

Guida operativa correlata (in tedesco): KI im Unternehmen einführen: Vom Arbeitsauftrag zur überprüfbaren Freigabe.