LLM locali e privati: AI on-premise senza data egress

Ogni prompt che il tuo team invia a una API di AI ospitata è una copia dei tuoi dati che esce dalla tua rete. Per la maggior parte delle aziende è un rischio calcolato. Per una banca, un ospedale, uno studio legale o qualsiasi organizzazione che tratta dati personali ai sensi del GDPR, è una responsabilità pronta a emergere in un audit.

Eseguire i large language model localmente elimina questa responsabilità alla radice. Nessun prompt attraversa il tuo perimetro, nessun documento finisce nel log di terze parti e nessuna giurisdizione straniera può imporre l’accesso a dati che non ha mai ricevuto. Questa guida spiega come funziona l’AI on-premise, l’ecosistema aperto con cui la costruisci e i compromessi da considerare. Il filo conduttore: scegli lo strumento giusto per ogni livello, fai leva sugli standard aperti e mantieni il controllo dei tuoi modelli, delle tue chiavi e dei tuoi dati.

Perché “locale” batte “regione EU” per i dati sensibili

Scegliere la regione EU di un provider non risolve del tutto il problema della conformità. La residenza dei dati ti dice dove risiedono i byte. La sovranità dei dati ti dice quali leggi governano l’accesso ad essi. Un provider con sede negli Stati Uniti può essere obbligato dal CLOUD Act statunitense a consegnare i dati indipendentemente dal data center che li ospita.

Eseguire il modello su un’infrastruttura che controlli annulla questa distinzione. Se la GPU è nel tuo rack o su un server dedicato che gestisci, e le chiavi sono tue, non c’è alcuna terza parte da citare in giudizio né alcun egress da ispezionare.

I vantaggi pratici:

Nessun data egress. Prompt e documenti non lasciano mai la tua rete.
Nessuna fuga di dati per il training. I tuoi dati non vengono mai usati per migliorare il modello di qualcun altro.
Costo prevedibile. Nessuna fatturazione per token che cresce con l’adozione.
Allineamento con GDPR ed EU AI Act per progettazione, non per clausola contrattuale.

L’ecosistema aperto che rende tutto possibile

Non hai bisogno di addestrare un modello. L’ecosistema open-weight è abbastanza maturo da rendere la parte difficile le operazioni, non l’AI in sé. Il vantaggio più profondo è che ormai quasi ogni livello parla uno standard aperto, quindi assembli uno stack invece di acquistarne uno.

Modelli che puoi davvero eseguire

Modelli open-weight di buon livello coprono la maggior parte dei casi d’uso aziendali, con famiglie come Llama, Mistral e Mixtral, Qwen, Gemma, Phi e DeepSeek che spaziano dal ragionamento generale al lavoro multilingue fino al codice. I pesi vengono distribuiti come Safetensors tramite Hugging Face Transformers, il formato GGUF (da llama.cpp) è il packaging de facto per i modelli quantizzati e ONNX offre un percorso portabile tra i vari runtime.

Regola empirica per il dimensionamento: un modello quantizzato da 7B-8B gira su una singola GPU da 24GB; un modello della classe 70B richiede più GPU (tipicamente da 2x a 4x A100/H100 o equivalenti). La quantizzazione (GGUF, AWQ, GPTQ) scambia un po’ di accuratezza con un forte calo della VRAM e, per la maggior parte dei compiti interni, la differenza di qualità è difficile da notare.

Runtime di serving: l’ecosistema in cui operiamo

Non esiste un unico motore di inferenza “corretto”. Lavoriamo trasversalmente sull’ecosistema di serving aperto e adattiamo il runtime al tuo profilo di concorrenza, hardware e operazioni:

vLLM - un cavallo di battaglia per la produzione; PagedAttention e il continuous batching garantiscono throughput elevato e bassa latenza sotto carico concorrente.
SGLang - serving ad alte prestazioni, ottimo per l’output strutturato e le pipeline agentiche multi-chiamata.
Hugging Face Text Generation Inference (TGI) - un solido server di produzione, soprattutto negli ambienti incentrati su Hugging Face.
Ollama - il modo più rapido per far girare un modello su una workstation o un singolo server. Ideale per prototipazione e piccoli team.
llama.cpp - il motore dietro a gran parte del tooling leggero e la scelta d’elezione per hardware solo CPU o vincolato.
LocalAI - un gateway drop-in compatibile con OpenAI che fa da front-end a più backend.

Il filo conduttore è l’API compatibile con OpenAI, esposta da vLLM, SGLang, TGI, Ollama e LocalAI. Poiché quell’interfaccia è lo standard de facto per l’inferenza self-hosted, il codice della tua applicazione raramente cambia quando sostituisci il motore sottostante. Un pattern comune: prototipare con Ollama, poi spostarsi dietro vLLM o SGLang quando serve una vera concorrenza.

Retrieval, agenti e il resto della pipeline

La maggior parte del valore di business nasce dal radicare il modello nei tuoi dati tramite la Retrieval-Augmented Generation (RAG). Uno stack RAG locale abbina un modello di embedding self-hosted a un vector store, poi a un livello di orchestrazione che lega insieme retrieval, prompting e chiamate agli strumenti. L’ecosistema qui è ampio e ci adattiamo al tuo stack:

Database vettoriali - pgvector (nativo per Postgres), Qdrant, Weaviate, Milvus e Chroma. Se già usi Postgres, pgvector spesso evita di aggiungere un nuovo componente in più.
Framework di orchestrazione - LangChain e LlamaIndex per collegare retrieval, agenti e uso degli strumenti.
Connettività a strumenti e dati - il Model Context Protocol (MCP), ora gestito dalla Agentic AI Foundation della Linux Foundation, si sta affermando come lo standard aperto per connettere i modelli a strumenti e dati interni senza collante su misura.

Tutto gira all’interno del tuo perimetro, quindi nemmeno la knowledge base e l’accesso agli strumenti da parte dell’agente lo lasciano mai.

Un’architettura di riferimento

Un setup on-premise praticabile si presenta così:

Server GPU che eseguono il motore di inferenza scelto, esponendo un’API interna compatibile con OpenAI.
Database vettoriale che contiene gli embedding dei tuoi documenti interni.
Un livello di privacy / PII che rileva e maschera i dati personali prima che raggiungano il modello. Strumenti open come Microsoft Presidio gestiscono il rilevamento e l’anonimizzazione, con tokenizzazione reversibile opzionale così le risposte restano personalizzate.
Un livello applicativo - un copilot di chat, un assistente di ricerca interno o agenti che chiamano strumenti interni tramite MCP.
Observability - logging dei prompt (all’interno della tua rete), metriche di latenza e token e controlli di accesso, tracciati sempre più spesso tramite OpenTelemetry così la telemetria degli LLM resta portabile.

Per ambienti più rigorosi l’intero stack può girare air-gapped, con i pesi del modello scaricati una sola volta e nessuna connettività in uscita successiva.

Costi: quando l’on-prem ripaga davvero

L’on-prem non è automaticamente più economico; il punto di pareggio onesto dipende dal volume. Per un utilizzo basso o sporadico vincono le API cloud: paghi solo per ciò che usi, senza alcun esborso di capitale. Per un utilizzo sostenuto e ad alto volume l’on-prem di solito vince su un orizzonte di due o tre anni: un singolo server GPU ammortizzato su migliaia di richieste giornaliere costa meno della tariffazione per token, e azzeri del tutto le commissioni di egress. L’errore è comprare hardware prima di conoscere il volume reale di token. Dimensiona l’architettura sull’utilizzo misurato, non sulla scheda tecnica di un fornitore.

Errori comuni

Sottodimensionare la VRAM, per poi sorprendersi che il modello 70B non si carica. Adatta la dimensione del modello all’hardware prima di impegnarti.
Ignorare la concorrenza. Un setup a singola GPU ottimizzato per uno sviluppatore crolla con cinquanta. Pianifica il livello di serving per il carico di picco e scegli un motore costruito per il batching.
Saltare il livello PII. L’hosting on-premise blocca l’egress esterno, ma vuoi comunque mascheramento e controllo degli accessi per il privilegio minimo interno.
Considerare la RAG come un problema risolto. Qualità del retrieval, chunking e scelta dell’embedding incidono sulla qualità delle risposte molto più della dimensione del modello.
Vincolarsi a un solo strumento troppo presto. Poiché l’API compatibile con OpenAI, GGUF e ONNX sono standard aperti, puoi tenere le opzioni aperte tra motori e vector store invece di scommettere la piattaforma su un singolo fornitore.

FAQ

La versione consumer di ChatGPT in genere non è conforme al GDPR, perché le conversazioni possono essere conservate e usate per il training senza un Data Processing Agreement o una garanzia di residenza dei dati nell’EU. Un LLM self-hosted o privato evita tutto questo mantenendo ogni prompt e documento all’interno della tua infrastruttura, così nessun dato personale lascia la giurisdizione dell’EU.

Cos’è l’AI privata?

L’AI privata significa eseguire modelli linguistici e agenti AI su un’infrastruttura che controlli, on-premise o in un ambiente EU dedicato, anziché inviare i dati a API cloud esterne. I tuoi dati non vengono mai usati per addestrare modelli di terze parti, garantendoti la sovranità dei dati e l’allineamento con GDPR ed EU AI Act per progettazione.

Quale motore di inferenza dovrei usare per servire un LLM locale?

Dipende dal tuo carico di lavoro. vLLM e SGLang eccellono nel serving di produzione ad alta concorrenza, TGI è adatto ai team incentrati su Hugging Face, Ollama e llama.cpp sono i migliori per la prototipazione o l’hardware vincolato e LocalAI offre un gateway unificato. Tutti espongono un’API compatibile con OpenAI, quindi puoi iniziare in modo semplice e cambiare motore in seguito senza riscrivere l’applicazione.

Quali modelli open-source possono girare on-premise?

Modelli open di buon livello come Llama, Mistral, Mixtral, Qwen, Gemma, Phi e DeepSeek girano bene sui tuoi server GPU. I modelli quantizzati più piccoli stanno su una singola GPU da 24GB; quelli della classe 70B richiedono un setup multi-GPU. La scelta giusta bilancia accuratezza, latenza e budget.

Come si impedisce a dati sensibili e PII di finire in un LLM?

Aggiungi un livello di privacy che rileva e maschera i PII - nomi, email, dati finanziari e sanitari - prima che i prompt raggiungano il modello, usando tooling open come Microsoft Presidio con tokenizzazione reversibile opzionale così le risposte restano personalizzate. Combinato con l’hosting on-premise e una RAG locale, nessuna informazione sensibile lascia mai la tua rete.

Costruiscila con un team che realizza AI sovrana

Allestire una demo su un singolo server è questione di un pomeriggio. Gestire una piattaforma LLM privata che serve un’intera organizzazione, resta allineata al GDPR e supera una security review è lavoro di ingegneria.

Rapid Solutions progetta e gestisce AI privata per le aziende europee regolamentate: LLM self-hosted, copilot RAG, agenti AI e protezione dei PII, tutto su infrastruttura e chiavi che controlli tu. Siamo open-source-first e tool-agnostic: abbiniamo il motore di inferenza, il vector store e il framework di orchestrazione giusti per il tuo carico di lavoro invece di vincolarti a un unico stack. Operiamo dall’ingegneria di Amsterdam e Dubai e offriamo la residenza dei dati nell’EU come capacità standard.

I tuoi dati, le tue chiavi, il tuo controllo. Contatta Rapid Solutions per definire un deployment di AI privata per il tuo team.