AI Air-Gapped: Come funzionano i sistemi di IA senza Internet o accesso al cloud

L'IA air-gapped è un sistema di IA distribuito all'interno di un dominio di sicurezza che non ha alcuna connessione di rete fisica con i sistemi esterni da cui è separato, con qualsiasi trasferimento attraverso quel confine eseguito tramite procedure deliberatamente controllate e non automatizzate. Il modello di IA, il runtime, i dati, gli indici di retrieval, gli strumenti e le dipendenze operative necessarie per l'inferenza devono quindi essere disponibili all'interno dell'ambiente isolato. L'IA air-gapped non è semplicemente "un modello locale" o "un server on-premise": la proprietà che la definisce è il confine di rete e di trasferimento attorno all'intero sistema.

Cosa significa realmente IA air-gapped

La parola IA non cambia il concetto di sicurezza di base. Un air gap è un confine tra domini di sicurezza. L'IA rende semplicemente il lato isolato più impegnativo dal punto di vista operativo perché gli stack di IA moderni normalmente presuppongono modelli scaricabili, registry di pacchetti, telemetria, API, hub di modelli e aggiornamenti software frequenti.

L'ambiente isolato può comunque contenere molte macchine connesse. Un cluster interno può avere GPU, server applicativi, storage, database, servizi di identità e monitoraggio connessi tra loro. L'air gap esiste tra quell'enclave e il dominio esterno.

La domanda rilevante quindi non è "Questa GPU ha il Wi-Fi?" ma "Questo ambiente di IA può scambiare informazioni con il dominio esterno attraverso un percorso fisico o logico automatizzato?"

L'esempio più semplice

Immagina che un'azienda voglia un assistente interno per documenti tecnici riservati, ma all'ambiente non è consentito inviare quei documenti su internet.

L'azienda scarica un LLM approvato, un modello di embedding, immagini container e pacchetti software in un ambiente di staging connesso. Dopo la validazione, gli artefatti approvati vengono trasferiti nell'ambiente isolato.

All'interno dell'enclave, il server del modello, il parser di documenti, il database vettoriale, l'applicazione e i servizi di identità vengono eseguiti localmente. Gli utenti possono porre domande e utilizzare il RAG sui documenti interni senza un modello cloud o un registry pubblico di modelli.

Quando è necessario un aggiornamento, l'aggiornamento passa di nuovo attraverso il processo di importazione controllata invece di essere scaricato direttamente dal server di IA di produzione.

Dove si ferma l'esempio semplice

Un ambiente air-gapped di produzione può essere molto più grande di una singola workstation. Può includere Kubernetes/OpenShift, registry interni, object storage, provider di identità, database vettoriali, osservabilità, infrastruttura di backup e diversi nodi di serving dei modelli.

Più servizi esistono all'interno dell'enclave, più l'organizzazione deve riprodurre capacità che gli ambienti connessi normalmente consumano da Internet.

L'air-gapping quindi sposta la complessità. Riduce la connettività esterna diretta ma aumenta la gestione degli artefatti, il patching, le dipendenze, la supply chain e la responsabilità operativa all'interno del dominio isolato.

AI air-gapped vs offline vs locale vs on-premises vs privata vs sovrana

Questi termini possono sovrapporsi ma non sono sinonimi. Un server Ollama locale connesso a Internet è AI locale, non AI air-gapped. Una piattaforma RAG on-premises che chiama un modello cloud è infrastruttura applicativa on-premises con inferenza cloud, non AI air-gapped.

Un sistema air-gapped è spesso privato per progettazione perché i dati rimangono all'interno dell'enclave, ma la privacy dipende anche da autorizzazione, logging, gestione dei dati, sicurezza fisica e policy operativa.

Air gap rigoroso vs deployment disconnesso pratico

Un'architettura AI air-gapped pratica

Un'architettura completa dovrebbe essere in grado di avviarsi e operare senza ricerche DNS, controlli di licenza, download di pacchetti o chiamate API a servizi pubblici, a meno che tali dipendenze non abbiano sostituti interni approvati.

Un utile test di progettazione è disconnettere il deployment da ogni servizio esterno e avviare a freddo lo stack. Le dipendenze nascoste tendono a comparire durante l'avvio, il caricamento del modello, l'autenticazione, la risoluzione dei pacchetti o l'inizializzazione della telemetria.

I modelli devono essere pre-staged

Le API dei modelli cloud sono indisponibili per definizione se il workload isolato non ha un percorso verso di esse. L'enclave necessita quindi di artefatti modello eseguibili localmente o di un servizio di inferenza ospitato internamente.

L'attuale documentazione air-gap di NVIDIA NIM utilizza esplicitamente un pattern a due fasi: scaricare e preparare gli asset del modello su una macchina connessa, trasferirli, quindi eseguire il NIM isolato da storage locale senza accesso in uscita al registry o chiavi API cloud.

I pesi del modello sono solo una parte dell'insieme delle dipendenze. Anche tokenizer, file di configurazione, adapter, metadati di quantizzazione e qualsiasi codice runtime richiesto devono essere presenti.

I modelli con dipendenze remote-code sono un rischio per l'air-gap

Alcuni repository di modelli contengono codice Python personalizzato o hook di runtime che normalmente recuperano codice o asset aggiuntivi.

L'attuale documentazione di Red Hat AI Inference avverte esplicitamente che alcuni modelli Hugging Face che richiedono codice remoto non possono funzionare normalmente in ambienti disconnessi perché la libreria tenta l'accesso alla rete anche quando è configurata la modalità offline.

La lezione pratica è testare l'intero percorso di caricamento di un modello offline prima di approvarlo per un deployment isolato. "Ho scaricato i pesi" non è prova che il modello sia autosufficiente.

Container, pacchetti e driver diventano artefatti locali della supply chain

Gli ambienti connessi prelevano abitualmente immagini container, pacchetti Python, aggiornamenti del sistema operativo e componenti GPU da registry pubblici. Un ambiente air-gapped non può presupporre nessuno di questi servizi.

Il modello di deployment AI disconnesso di Red Hat utilizza registry mirror interni per immagini container e cataloghi di operator. I modelli possono essere replicati come artefatti OCI o trasferiti su storage persistente.

Per stack più ampi, lo stesso schema si applica spesso a pacchetti linguistici, repository Linux, pacchetti JavaScript e binari interni: gli artefatti approvati entrano una volta attraverso il processo di trasferimento e vengono poi serviti da repository interni attendibili.

Conoscere il conto completo delle dipendenze

I mirror interni sono infrastruttura, non una comodità

Un deployment disconnesso diventa mantenibile quando il dominio isolato dispone di fonti interne note per gli artefatti approvati.

L'approccio documentato di Red Hat utilizza un registry mirror disponibile al cluster disconnesso, così i workload non necessitano di registry pubblici.

La stessa idea architetturale può essere applicata a model store e repository di pacchetti. L'obiettivo è rendere espliciti origine, versione e approvazione degli artefatti, invece di copiare manualmente file casuali su ogni server.

RAG può funzionare completamente air-gapped

RAG non richiede Internet pubblico. Richiede un corpus recuperabile, una pipeline di ingestion/indexing e un modello in grado di usare il contesto recuperato.

All'interno di un ambiente air-gapped, il document store, il parser/OCR, il modello di embedding, l'indice vettoriale o lessicale, il reranker e il modello di generazione possono tutti essere eseguiti localmente.

Ciò che cambia è l'acquisizione delle fonti. La ricerca web live e i connettori cloud per documenti non sono disponibili a meno che dati equivalenti vengano importati attraverso il confine controllato.

Il corpus diventa quindi un artefatto governato. Ogni importazione dovrebbe preservare identità della fonte, data/versione e provenienza, così gli utenti sanno quali conoscenze contiene effettivamente il sistema isolato.

Gli agenti possono funzionare in modalità air-gapped, ma solo con strumenti raggiungibili

Un ciclo di agente può funzionare interamente all'interno di un enclave isolato se il modello/runtime e gli strumenti necessari sono locali o raggiungibili sulla rete interna.

Uno strumento che dipende da GitHub, dalla ricerca web pubblica, dalla posta elettronica cloud o da un'API SaaS esterna fallirà a meno che l'architettura non fornisca un equivalente interno approvato o un processo di scambio asincrono controllato.

Ecco perché la progettazione di agenti air-gapped dovrebbe iniziare con un inventario delle capacità: ogni endpoint di strumento deve essere classificato come interno, importato, non disponibile o deliberatamente escluso.

MCP non aggira l'air gap

MCP può esporre strumenti e risorse locali all'interno di un ambiente AI isolato, ma il protocollo non crea connettività attraverso il confine di sicurezza.

Un server MCP locale che legge documenti interni può funzionare perfettamente offline. Un server MCP remoto su Internet pubblico non può essere raggiunto da un enclave air-gapped rigoroso.

Lo stesso principio si applica a qualsiasi protocollo di connessione: l'interoperabilità è separata dall'autorità di rete.

Anche l'identità e l'autenticazione devono funzionare offline

Un'applicazione AI può essere ospitata localmente pur dipendendo da un provider di identità cloud. Questa dipendenza nascosta interrompe il funzionamento veramente disconnesso.

I progetti air-gapped necessitano quindi di un'architettura di identità che funzioni all'interno dell'enclave: directory locale, provider di identità interno, PKI interna, credenziali di servizio locali o un altro meccanismo approvato.

L'autorizzazione rimane necessaria anche se Internet è assente. Gli air gap non sostituiscono RBAC, isolamento tenant o privilegio minimo.

Tempo, certificati e trust store diventano dipendenze locali

Molti sistemi di autenticazione e registrazione dipendono da un tempo affidabile. I certificati scadono. I trust store cambiano. Gli artefatti firmati necessitano di convalida.

Un enclave disconnesso dovrebbe quindi avere una sincronizzazione temporale interna e un ciclo di vita di certificati/trust che non dipenda dal raggiungimento di servizi pubblici durante il normale funzionamento.

Queste sono normali preoccupazioni infrastrutturali che diventano visibili solo quando un'architettura viene testata senza accesso a Internet.

Telemetria e segnalazione di crash richiedono una politica esplicita

Molte librerie moderne tentano analisi, controlli di aggiornamento o segnalazione di errori per impostazione predefinita.

In un ambiente isolato quelle chiamate dovrebbero essere disabilitate o reindirizzate all'osservabilità interna. Ripetuti tentativi di telemetria falliti possono creare ritardi, log rumorosi e comportamenti di avvio imprevisti.

Un deployment air-gapped dovrebbe sapere quali componenti tentano l'egress anche se il firewall li bloccherebbe.

I sistemi air-gapped necessitano comunque di patch

L'isolamento di rete non impedisce al software di sviluppare vulnerabilità. Cambia solo il modo in cui le patch raggiungono il sistema.

NIST inquadra la gestione delle patch come manutenzione preventiva: le organizzazioni devono comunque identificare, acquisire, prioritizzare, installare e verificare patch e aggiornamenti.

Le operazioni air-gapped necessitano quindi di una cadenza di importazione ripetibile per pacchetti OS, immagini container, driver, runtime AI e aggiornamenti di sicurezza. Il compromesso è tra stabilità dell'isolamento ed esposizione alle vulnerabilità dovuta a software obsoleto.

Un percorso di aggiornamento controllato

Il confine di trasferimento è l'interfaccia operativa più sensibile

Se informazioni esterne devono entrare in un sistema air-gapped, il canale di importazione diventa un punto di controllo di sicurezza importante.

Il Cybersecurity Technical Cyber Threat Framework della NSA riconosce esplicitamente la replica tramite supporti rimovibili come un percorso che gli avversari possono usare per attraversare reti disconnesse o air-gapped.

Ecco perché la gestione controllata dei supporti, l'ispezione, la provenienza, la crittografia ove richiesta, la scansione malware e la separazione dei ruoli possono essere importanti quanto lo stack AI stesso.

I supporti rimovibili non sono un canale neutro

Le unità USB e altri supporti portatili possono trasportare sia artefatti legittimi di modelli/dati sia contenuti malevoli.

Le linee guida NIST sulla sanificazione dei supporti trattano i supporti di archiviazione come un oggetto del ciclo di vita della riservatezza che può richiedere cancellazione, purga o distruzione in base alla sensibilità e alle esigenze di riutilizzo.

La procedura di trasferimento esatta è specifica dell'organizzazione, ma il principio architetturale è stabile: i supporti che attraversano i confini dovrebbero essere governati come un asset di sicurezza, non trattati come una comodità informale.

L'air-gapping aumenta l'importanza della supply-chain

Un sistema isolato riceve meno input esterni attivi, ma ogni binario, modello, container e pacchetto importato diventa più rilevante perché l'enclave potrebbe fidarsi di esso per molto tempo.

Le linee guida NIST sulla supply chain del software enfatizzano la provenienza, il rischio del fornitore, la gestione delle vulnerabilità, la verifica del software e le pratiche orientate agli SBOM. Queste preoccupazioni diventano direttamente rilevanti per l'importazione offline di artefatti AI.

La supply chain dei modelli merita la stessa attenzione della supply chain delle applicazioni: origine del modello, licenza, hash, formato, codice richiesto, tokenizer, adapter e stato di valutazione dovrebbero essere noti prima dell'importazione.

La preparazione all'air-gap dovrebbe essere testata, non presunta

Memorizzato una volta non è lo stesso che pronto per l'air-gap

Un sistema può apparire offline perché il modello e i pacchetti sono già memorizzati nella cache da un precedente accesso a Internet.

L'eliminazione delle cache o la distribuzione su un nodo pulito può rivelare file tokenizer mancanti, pacchetti Python, manifest dei modelli o dipendenze da codice remoto.

La preparazione all'air-gap dovrebbe quindi essere validata da artefatti interni puliti, non solo da una workstation di sviluppo precedentemente connessa.

Quali minacce rimangono all'interno di un air gap?

Cosa migliora effettivamente un air gap

Un vero air gap può ridurre materialmente i percorsi di attacco che dipendono dalla connettività remota diretta: command-and-control esterno, uso improprio di credenziali cloud, sfruttamento di servizi esposti a Internet ed esfiltrazione accidentale di dati attraverso normali API in uscita.

Rende anche semplice la residenza dei dati in un senso ristretto: i dati di inferenza non possono essere inviati a un servizio cloud esterno se non esiste un percorso.

Questi benefici sono più forti quando il confine di trasferimento e i controlli di accesso interni sono ugualmente disciplinati. Un processo USB gestito male può compromettere l'isolamento previsto.

Cosa rende più difficile un air gap

IA air-gapped vs IA privata

L'IA privata riguarda principalmente il controllo dei dati sensibili e dell'elaborazione AI. Una piattaforma di IA privata può essere on-premises e comunque accedere a modelli cloud approvati o servizi esterni.

L'IA air-gapped è più restrittiva sulla connettività. Un sistema può essere privato senza essere air-gapped, e un sistema air-gapped può comunque avere una scarsa privacy se ogni utente interno ha accesso senza restrizioni.

L'obiettivo di sicurezza dovrebbe determinare l'architettura: riservatezza, sovranità, resilienza e isolamento sono requisiti correlati ma distinti.

IA air-gapped vs IA sovrana

L'IA sovrana riguarda il controllo sulla più ampia catena di dipendenze: dati, modelli, infrastruttura, operatori, giurisdizione e dipendenze strategiche.

Un air gap può supportare la sovranità riducendo la dipendenza esterna a runtime, ma non garantisce il controllo sovrano. L'enclave può comunque dipendere da hardware straniero, licenze di modelli proprietari o fornitori esterni di aggiornamenti.

Il prossimo articolo canonico separa esplicitamente queste dimensioni di controllo.

Evidenza dell'implementazione originale: cosa dimostra l'Aaasaasa AI Client — e cosa non dimostra

L'AI Hub separa agente/client, provider, modello e posizione della connessione. Supporta l'inferenza locale Ollama e l'operazione Codex con provider locale come scelte distinte, invece di presumere che ogni richiesta AI vada a un modello cloud.

Il repository nota esplicitamente che un runtime locale può comunque usare un modello cloud, mentre la chat Direct Ollama è inferenza locale. Questa distinzione è direttamente rilevante per l'architettura air-gap: l'esecuzione locale non dimostra che il modello o le dipendenze circostanti siano disconnessi.

L'astrazione del provider, la scoperta di modelli locali e l'inferenza locale sono quindi elementi costitutivi per un'architettura di prodotto air-gap-capable, ma il confine di rete, il mirror delle dipendenze offline, il processo di trasferimento controllato e l'identità/operazioni offline devono ancora essere progettati separatamente.

Quando è giustificata l'IA air-gapped?

L'air-gapping dovrebbe essere un requisito derivato da un modello di minaccia o da una politica, non una funzionalità di prestigio. Ha un reale valore di sicurezza quando il percorso di connettività eliminato è esso stesso inaccettabile.

Per molti casi d'uso aziendali, una rete privata strettamente controllata con restrizioni in uscita, inferenza locale e canali di aggiornamento approvati può offrire un miglior equilibrio tra sicurezza e manutenibilità rispetto a un rigoroso air gap fisico.

Una sequenza pratica di progettazione AI air-gapped

Checklist per l'architettura AI air-gapped

Modalità di fallimento comuni dell'AI air-gapped

Idee sbagliate comuni

Limitazioni

Gli air gap rigorosi rendono più lenta l'aggiornamento della conoscenza esterna perché ogni nuova fonte deve passare attraverso un processo di trasferimento.

Possono limitare la scelta del modello quando licenze, requisiti di codice remoto, esigenze hardware o API solo del fornitore non possono essere soddisfatti offline.

Aumentano il costo operativo perché l'infrastruttura normalmente consumata come servizi cloud deve essere posseduta e mantenuta internamente.

Possono anche creare latenza nelle patch: un controllo delle modifiche più forte può mantenere i sistemi stabili mentre ritarda la remedizione urgente delle vulnerabilità.

L'AI air-gapped dovrebbe quindi essere valutata come una tra diverse architetture di sicurezza, non presunta universalmente superiore.

Cosa cambierebbe questa risposta?

Il supporto dei fornitori per l'operatività disconnessa cambia rapidamente. Nuovi formati di modello, artefatti OCI firmati, meccanismi di licenza offline e registry di modelli integrati possono ridurre l'attrito operativo.

La distinzione tra air gap rigoroso e deployment disconnesso rimarrà importante anche se i fornitori continuano a usare i termini in modo approssimativo.

Il principio stabile è che le affermazioni genuine di air gap dipendono dal confine del sistema e dal meccanismo di trasferimento, non dal fatto che l'LLM venga eseguito localmente.

Conoscenza canonica correlata

L'AI air-gapped è un nodo di architettura di deployment/sicurezza. L'AI privata, l'AI sovrana e l'astrazione del provider rispondono a domande diverse su riservatezza, controllo e dipendenza.

MLOps/LLMOps diventa più impegnativo all'interno di un ambiente disconnesso perché i cicli di vita di modelli, pacchetti e aggiornamenti devono operare attraverso repository interni e trasferimenti controllati.

RAG e AI agentica rimangono pattern validi all'interno dell'enclave purché i loro dati e strumenti siano disponibili internamente.

Domande frequenti

Glossario

Conclusione

L'AI air-gapped non è un tipo speciale di modello. È un'architettura AI che opera all'interno di un dominio di sicurezza deliberatamente isolato.

Il modello può essere la parte facile. La prontezza per la produzione dipende dalla capacità di ogni dipendenza circostante — asset del modello, pacchetti, registry, identità, RAG, strumenti, monitoraggio, aggiornamenti e ripristino — di funzionare senza un percorso esterno automatizzato.

La regola affidabile più breve è: l'inferenza locale dimostra dove viene eseguito il modello; l'evidenza dell'air gap dimostra come l'intero sistema è separato e come ogni trasferimento consentito attraversa quel confine.

Fonti primarie e riferimenti attuali sull'implementazione

Le fonti seguenti stabiliscono la definizione di sicurezza, i pattern attuali di deployment AI disconnessa e i rischi del ciclo di vita. L'uso del termine “air-gapped” da parte dei fornitori è intenzionalmente distinto dalla definizione più rigorosa del NIST.