AI air-gapped: eseguire LLM completamente offline con Ollama
Un'architettura pratica per l'AI senza connettività in uscita: Ollama come LLM locale, LanceDB per i vettori, redazione DLP su ogni prompt, tutto in un contenitore offline.
Perché l'air-gap è una forma di deployment, non un flag di funzionalità
La maggior parte dei prodotti AI "self-hosted" perde comunque dati. Una chiamata a un'API di modello qui, una richiesta di embedding là, un ping di telemetria, un controllo di licenza che richiama casa - ognuno difendibile singolarmente, e insieme significano che i vostri documenti interni, prompt e risposte attraversano un confine di rete che non controllate. Per gli appaltatori della difesa, gli ospedali, le banche e qualsiasi organizzazione con un mandato di residenza dei dati, questo è causa di esclusione. Il requisito non è "quasi offline" - è un sistema AI che funziona con il cavo di rete staccato.
Simmetric Chat è costruito attorno a quel requisito. Il funzionamento air-gap non è una modalità da sbloccare né un plugin da comprare: la configurazione predefinita della piattaforma comunitaria è già quella offline - un LLM locale, embedding locali, uno store vettoriale locale file-based e una pipeline documentale che non ha mai bisogno di internet. Questo articolo attraversa ogni strato che rende funzionante la connettività zero-outbound, e cosa rinunciate - pochissimo - chiudendo il perimetro.
Lo stack locale: ogni strato ha un default offline
Una chat AI ha quattro dipendenze esterne in una tipica architettura SaaS: il modello linguistico, il modello di embedding, lo store vettoriale e la pipeline documentale. I default di Simmetric Chat sostituiscono tutti e quattro con componenti locali:
- L'LLM gira in Ollama. Il provider predefinito della piattaforma è Ollama sulla rete locale, e il modello predefinito (
gemma4:latest) viene scaricato in fase di setup così che la chat funzioni prima di qualsiasi download di modello a runtime. Ollama parla HTTP compatibile OpenAI sulla vostra rete, e la configurazione del provider lo indica con un URL - non un endpoint cloud. - Gli embedding girano in locale. Il provider di embedding predefinito è un modello trasformatori locale (384 dimensioni, in-process nel collector), non un'API di embedding ospitata. Gli embedding locali sono compatibili con l'air-gap per costruzione, e la guardia di mismatch sugli embedding significa che passare da provider locali a remoti è sicuro - il retrieval degrada a ricerca per parole chiave finché la re-indicizzazione non è completa anziché servire punteggi da spazi misti.
- I vettori vivono in LanceDB. Lo store vettoriale predefinito è file-based, conservato nella directory di storage del deployment, con una collezione per workspace. Nessun server di database vettoriale, nessun hop di rete. Qdrant, pgvector e Chroma restano disponibili per i team la cui scala richiede un indice in rete, ma nulla li richiede.
- Il parsing dei documenti avviene nella vostra rete. Il collector - il servizio che analizza, spezza e incorpora gli upload - fa parte del vostro deployment. PDF, file Word ed Excel, presentazioni e trascrizioni di YouTube sono elaborati dentro il perimetro, compresi i documenti scansionati instradati attraverso la pipeline OCR a modello vision server-side, che usa un modello vision locale.
Nulla in questa lista è trattato in modo speciale o aggiunto a posteriori. Il pattern strategico a ogni confine fa sì che l'opzione locale sia semplicemente il provider predefinito, selezionato per configurazione come qualsiasi altro.
DLP: redazione prima che qualcosa esca - o prima ancora che si muova
Chiudere la connettività in uscita non chiude ogni percorso di esfiltrazione, perché i contenuti si muovono anche dentro la vostra rete: i prompt entrano nella piattaforma, le risposte fluiscono verso gli utenti, ed entrambi attraversano interfacce di chat da cui le persone copiano. Il filtro di data-loss-prevention di Simmetric Chat scansiona in entrambe le direzioni - il prompt in entrata e la risposta in uscita, comprese le emissioni in streaming token per token - e redige le corrispondenze prima che il contenuto sia conservato o mostrato.
Lo scanner riconosce le classi di PII che contano in un contesto di chat: indirizzi email, numeri di carta di credito, chiavi API e chiavi private e - aggiunti nella v0.22 - identificatori europei strutturati: Partita IVA italiana, codice fiscale e IBAN, seminati come pattern integrati idempotenti e ancorati all'etichetta così che i numeri ordinari non li attivino mai. La configurazione dei pattern è gestita dall'amministrazione e basata su database: attivate o disattivate qualsiasi pattern, aggiungete fino a cinquanta pattern personalizzati con validazione di compilazione in tempo reale e anteprima di prova, ed esaminate un pannello di cronologia delle corrispondenze filtrato per sorgente.
L'intento di progettazione è che il DLP sia l'ultima linea, non la prima. La prima linea è l'architettura: con modelli locali, embedding locali e vettori locali, non esiste alcun endpoint di terze parti verso cui i contenuti sensibili possano arrivare in primo luogo. Il DLP copre poi i percorsi che restano - contenuti che escono dalla piattaforma verso i vostri stessi utenti, o che un dipendente di buona fede incolla in un prompt. Copre anche la superficie del widget, così le conversazioni rivolte ai visitatori sul vostro sito sono redatte dalla stessa catena di filtri, con la traccia di audit che distingue il traffico chat da quello widget.
Il deployment a contenitore singolo: tutto su un host
Chiudere il perimetro è una cosa; far entrare il software in un perimetro è un'altra. Gli ambienti air-gap in genere non possono eseguire comodamente uno stack compose a cinque servizi - eseguono un host con una sola immagine, e meno sono le parti mobili, meno sono gli artefatti da verificare e trasferire.
Simmetric Chat spedisce un'immagine all-in-one a contenitore singolo esattamente per questo caso. Un contenitore, supervisionato da un gestore di processi, esegue tutto: PostgreSQL 16 (con l'estensione pgvector compilata dal sorgente alla compilazione dell'immagine, così è installata offline), il server API, il collector documentale e il servizio widget. Il contenitore espone tre porte - 3000 per l'API, 3210 per il collector, 3211 per il widget - e controlla la propria salute sull'endpoint /api/health, che riporta lo stato di database, collector e disco.
Far entrare l'immagine è la stessa disciplina di qualunque altro artefatto: trasferite la tarball dell'immagine (o il mirror del registry che avete verificato), caricate ed eseguite. I default di environment nell'immagine sono segnaposto di impalcatura - la produzione sostituisce JWT_SECRET, COLLECTOR_SECRET e la chiave di cifratura tramite la configurazione d'ambiente, e il server fallisce sonoramente all'avvio se i segreti di produzione mancano, così un deployment air-gap configurato a metà non si avvia mai in silenzio. Dopo l'avvio, gli aggiornamenti software sono nuove versioni dell'immagine, non installazioni di pacchetti - nessun accesso a internet richiesto in nessun punto del ciclo di vita.
# Trasferite dentro il perimetro, poi:
docker load -i simmetric-chat-all-in-one.tar
docker run -d \
-p 3000:3000 -p 3210:3210 -p 3211:3211 \
-v simmetric-storage:/app/storage \
-e JWT_SECRET=$(openssl rand -hex 32) \
-e COLLECTOR_SECRET=$(openssl rand -hex 32) \
simmetric-chat:all-in-oneI pesi dei modelli seguono lo stesso percorso. I modelli Ollama vengono scaricati su una macchina connessa, salvati come blob e importati dentro il perimetro - la piattaforma li tratta poi come qualsiasi altro modello locale. Nulla nello stack richiama casa per verificare un modello, una licenza o se stesso: la telemetria è disattivata per default, non c'è dipendenza esterna di segnalazione errori, e la validazione della licenza è un controllo locale della firma RS256 contro una chiave pubblica incorporata.
Cosa funziona ancora offline - e cosa manca davvero
Un deployment air-gap dovrebbe essere onesto sui propri margini. Cosa funziona con connettività zero-outbound:
- Chat con LLM locali attraverso Ollama, in streaming token per token via SSE
- Upload e ingestione di documenti - parsing, chunking, embedding locali, vettori LanceDB
- Retrieval ibrido con citazioni, filtraggio per metadati e pipeline di sintesi
- RBAC, workspace, progetti, tracce di audit e tutta la superficie di amministrazione
- Webhook (consegnati ai vostri stessi ricevitori), Web Push (VAPID dal vostro server) e chiavi API
- Il widget incorporabile, in esecuzione sul vostro stesso servizio widget
Cosa manca davvero: provider LLM cloud, embedding ospitati, ricerca web esterna e qualsiasi altra cosa che richieda una chiamata in uscita. La progettazione di graceful degradation significa che ognuna di quelle integrazioni è un'aggiunta di configurazione, non una modifica al codice - ma il default offline spedisce semplicemente senza di esse. La piattaforma si avvia, serve le richieste ed elabora i documenti in modo identico che il perimetro sia aperto o chiuso.
Il risultato è un workspace AI il cui assetto di sicurezza non dipende dalla fiducia nella gestione dei dati di un fornitore, perché non c'è alcun fornitore nel percorso dei dati. Tutto ciò che tocca i vostri documenti - il modello, gli embedding, l'indice vettoriale, il parser - gira su hardware che possedete, dentro una rete che controllate, in un'immagine di contenitore che potete audire.
