Eseguire l'AI in un ambiente completamente isolato

Cosa significa davvero completamente isolato

Completamente isolato significa che l'istanza non ha alcun collegamento con la rete Internet pubblica. Nessuna chiamata API a un modello, nessuna telemetria, nessun controllo della licenza, nessun download di pacchetti in esecuzione, nessuna eccezione. Tutto ciò che serve al sistema viene replicato in anticipo nella tua rete: immagini dei container, pesi dei modelli, modelli di embedding e ogni dipendenza.

È un requisito molto più rigoroso di una semplice installazione nella tua infrastruttura o di un cloud privato, che di solito mantengono qualche collegamento in uscita e spesso ne dipendono. È un isolamento di rete rigido, e vale la fatica perché è dimostrabile: puoi provarlo a un auditor con una network policy invece di descriverlo con un diagramma.

La conseguenza per l'architettura è che l'isolamento deve essere il primo vincolo, non una configurazione aggiunta dopo. Quasi tutte le scelte di progetto che seguono derivano da qui.

Orchestrazione: le fondamenta

Parti da ciò che pianifica e scala i carichi di lavoro. I container impacchettano ogni componente in un'immagine portabile; Kubernetes, oppure OpenShift come sua distribuzione enterprise rafforzata, orchestra quelle immagini sui tuoi server e sulle tue GPU.

Il dettaglio critico è il registry. Esegui un registry di container privato nella tua rete e vi replichi ogni immagine, così nessun pod tenta mai un pull dall'esterno. Sembra banale ed è il punto in cui fallisce per prima la maggior parte dei tentativi di isolamento completo, di solito per colpa di un'immagine di base o di un sidecar di cui nessuno conosceva l'esistenza. OpenShift si guadagna il suo posto negli ambienti regolamentati perché parte da contesti di sicurezza restrittivi, firma delle immagini integrata e policy native, quindi l'hardening descritto più avanti parte da una posizione migliore.

Serving dei modelli: pesi aperti, nel cluster

Poiché non c'è un modello ospitato da chiamare, servi tu stesso modelli con pesi aperti. Un server di inferenza come vLLM o Text Generation Inference di Hugging Face funziona come servizio nel cluster, con scheduling delle GPU, raggruppamento delle richieste e scalabilità automatica.

I pesi vengono caricati da uno storage locale preparato in anticipo e non vengono mai scaricati in esecuzione. Dimensiona i pod GPU in base al modello e alla concorrenza che ti servono davvero, non al modello più grande disponibile, e rendi raggiungibile l'inferenza solo sulla rete interna del cluster, così nulla è accessibile dall'esterno della tua rete, nemmeno in teoria.

Un recupero che resta nella tua rete

Un modello è utile quanto il materiale su cui può basarsi, quindi anche lo stack di recupero deve stare nella tua rete: un database vettoriale, un modello di embedding servito nel cluster e una pipeline di acquisizione che indicizza i tuoi documenti.

Ogni passaggio (embedding, archiviazione, query) avviene nella tua rete, quindi il materiale di origine non viene mai trasmesso altrove, in nessun momento. È la differenza tra un generico chatbot offline, di utilità limitata, e un sistema capace di rispondere a partire da materiale classificato o regolamentato, che è il motivo per cui la distribuzione esiste.

Hardening: renderlo difendibile, non solo isolato

L'isolamento ti porta quasi fino in fondo. L'hardening è ciò che ti permette di dimostrarlo, punto per punto, a qualcuno il cui lavoro è non crederti.

• Limita il traffico est-ovest con network policy, così possono comunicare solo i componenti che devono farlo e un pod compromesso non può raggiungere né il modello né l'indice.
• Imponi la provenienza delle immagini con firma e admission control, così un'immagine non verificata non può essere eseguita anche se arriva nel registry.
• Conserva i segreti in uno store sigillato nel cluster, non in variabili d'ambiente o nei manifest, dove finiscono nei log e nei backup.
• Attiva un audit logging completo, così ogni inferenza e ogni modifica di configurazione sono attribuibili a un'identità e a un momento preciso.

Il livello prima del quale si fermano quasi tutte le guide

Eseguire il modello è il problema infrastrutturale, ed è quello più facile. Governarlo non diventa superfluo solo perché la rete è isolata. Un assistente completamente isolato può comunque rispondere con sicurezza a partire da un recupero debole, mostrare il materiale di una business unit a un'altra, scrivere una credenziale in un log e lasciarti senza modo di ricostruire cosa ha fatto lo scorso marzo.

Per questo nella tua rete valgono gli stessi controlli che valgono fuori: una soglia minima di confidenza sotto la quale il sistema rinuncia invece di rispondere, l'isolamento dei documenti tra clienti o unità, l'oscuramento dei dati e un log completo delle interazioni. NeuralSeek si distribuisce nello stesso cluster con lo stesso container e fornisce quel livello senza una sola chiamata in uscita, compresa la possibilità di confrontare i modelli con pesi aperti che hai preparato sul tuo materiale, invece che su una classifica pubblica.

L'infrastruttura rende possibile l'AI completamente isolata. La governance è ciò che la rende sicura da mettere davvero davanti a qualcuno.