Air-Gapped AI: Kako AI sistemi funkcionišu bez interneta ili pristupa oblaku

Air-gapped AI je AI sistem koji se koristi unutar bezbednosnog domena koji nema fizičku mrežnu vezu sa spoljnim sistemima od kojih je odvojen, pri čemu se svaki prenos preko te granice obavlja kroz namerno kontrolisane, neautomatizovane procedure. AI model, runtime, podaci, indeksi za pretragu, alati i operativne zavisnosti potrebne za inferenciju stoga moraju biti dostupni unutar izolovanog okruženja. Air-gapped AI nije jednostavno „lokalni model“ ili „on-premise server“: definišuće svojstvo je mrežna i transferna granica oko kompletnog sistema.

Šta air-gapped AI zaista znači

Reč AI ne menja osnovni bezbednosni koncept. Air gap je granica između bezbednosnih domena. AI samo čini izolovanu stranu operativno zahtevnijom jer moderni AI stack-ovi obično podrazumevaju modele koji se preuzimaju, registre paketa, telemetriju, API-je, model hub-ove i česta ažuriranja softvera.

Izolovano okruženje i dalje može da sadrži mnogo povezanih mašina. Interni klaster može imati GPU-ove, aplikacione servere, skladište, baze podataka, servise identiteta i monitoring međusobno povezane. Air gap postoji između tog enklava i spoljnog domena.

Relevantno pitanje stoga nije „Da li ovaj GPU ima Wi-Fi?“ već „Može li ovo AI okruženje da razmenjuje informacije sa spoljnim domenom kroz automatizovanu fizičku ili logičku putanju?“

Najjednostavniji primer

Zamislite da kompanija želi internog asistenta za poverljive tehničke dokumente, ali okruženju nije dozvoljeno da te dokumente šalje na internet.

Kompanija preuzima odobreni LLM, model za embedding, kontejnerske slike i softverske pakete u povezanom staging okruženju. Nakon validacije, odobreni artefakti se prenose u izolovano okruženje.

Unutar enklava, model server, parser dokumenata, vektorska baza podataka, aplikacija i servisi identiteta rade lokalno. Korisnici mogu da postavljaju pitanja i koriste RAG nad internim dokumentima bez cloud modela ili javnog model registry-ja.

Kada je potrebno ažuriranje, ono ponovo prolazi kroz kontrolisani proces uvoza umesto da ga produkcijski AI server preuzima direktno.

Gde se jednostavan primer zaustavlja

Produkcijsko air-gapped okruženje može biti mnogo veće od jedne radne stanice. Može uključivati Kubernetes/OpenShift, interne registry-je, object storage, provajdere identiteta, vektorske baze podataka, observability, infrastrukturu za backup i nekoliko čvorova za serviranje modela.

Što više servisa postoji unutar enklave, organizacija mora više da reprodukuje sposobnosti koje povezana okruženja obično konzumiraju sa interneta.

Vazdušno izolovanje stoga premešta složenost. Ono smanjuje direktnu spoljnu povezanost, ali povećava upravljanje artefaktima, zakrpe, zavisnosti, lanac snabdevanja i operativnu odgovornost unutar izolovanog domena.

Vazdušno izolovana vs oflajn vs lokalna vs na lokaciji vs privatna vs suverena AI

Ovi termini se mogu preklapati, ali nisu sinonimi. Lokalni Ollama server povezan na internet je lokalna AI, a ne vazdušno izolovana AI. RAG platforma na lokaciji koja poziva cloud model je aplikaciona infrastruktura na lokaciji sa cloud inferencijom, a ne vazdušno izolovana AI.

Vazdušno izolovan sistem je često privatan po dizajnu jer podaci ostaju unutar enklave, ali privatnost takođe zavisi od autorizacije, evidentiranja, rukovanja podacima, fizičke bezbednosti i operativne politike.

Strogi vazdušni jaz vs praktična diskonektovana implementacija

Praktična vazdušno izolovana AI arhitektura

Kompletna arhitektura treba da može da se pokrene i radi bez DNS upita, provera licence, preuzimanja paketa ili API poziva ka javnim servisima, osim ako te zavisnosti imaju odobrene interne zamene.

Koristan test dizajna je da diskonektujete implementaciju od svakog spoljnog servisa i hladno pokrenete stack. Skrivene zavisnosti obično se pojavljuju tokom pokretanja, učitavanja modela, autentifikacije, razrešavanja paketa ili inicijalizacije telemetrije.

Modeli moraju biti unapred pripremljeni

Cloud API-ji modela su po definiciji nedostupni ako izolovano radno opterećenje nema putanju do njih. Enklava stoga zahteva lokalno pokretljive artefakte modela ili interno hostovan servis za inferenciju.

NVIDIA-ina trenutna NIM dokumentacija za vazdušni jaz eksplicitno koristi dvofazni obrazac: preuzmite i pripremite resurse modela na povezanoj mašini, prenesite ih, zatim pokrenite izolovani NIM iz lokalnog skladišta bez odlaznog pristupa registry-ju ili cloud API ključeva.

Težine modela su samo deo skupa zavisnosti. Tokenizeri, konfiguracione datoteke, adapteri, metapodaci kvantizacije i bilo koji potreban runtime kod takođe moraju biti prisutni.

Modeli sa zavisnostima udaljenog koda su opasnost za vazdušni jaz

Neki repozitorijumi modela sadrže prilagođeni Python kod ili runtime hook-ove koji obično preuzimaju dodatni kod ili resurse.

Trenutna Red Hat AI Inference dokumentacija eksplicitno upozorava da neki Hugging Face modeli koji zahtevaju udaljeni kod ne mogu normalno da rade u diskonektovanim okruženjima jer biblioteka pokušava pristup mreži čak i kada je režim rada bez mreže konfigurisan.

Praktična lekcija je da testirate ceo put učitavanja modela bez mreže pre nego što ga odobrite za izolovano postavljanje. „Preuzeo sam težine“ nije dokaz da je model samostalan.

Kontejneri, paketi i drajveri postaju lokalni artefakti lanca snabdevanja

Povezana okruženja rutinski preuzimaju kontejnerske slike, Python pakete, ažuriranja OS-a i GPU komponente iz javnih registara. Vazdušno izolovano okruženje ne može da računa na nijednu od tih usluga.

Red Hat-ov model za diskonektovano AI postavljanje koristi interne mirror registre za kontejnerske slike i kataloge operatora. Modeli mogu biti preslikani kao OCI artefakti ili preneti na trajno skladište.

Za šire stack-ove, isti obrazac se često primenjuje na jezičke pakete, Linux repozitorijume, JavaScript pakete i interne binarne datoteke: odobreni artefakti ulaze jednom kroz proces prenosa i zatim se serviraju iz pouzdanih internih repozitorijuma.

Poznajte kompletan račun zavisnosti

Interni mirrori su infrastruktura, a ne pogodnost

Diskonektovano postavljanje postaje održivo kada izolovani domen ima poznate interne izvore za odobrene artefakte.

Red Hat-ov dokumentovani pristup koristi mirror registar dostupan diskonektovanom klasteru tako da radna opterećenja ne zahtevaju javne registre.

Ista arhitektonska ideja može se primeniti na skladišta modela i repozitorijume paketa. Cilj je da poreklo artefakta, verzija i odobrenje budu eksplicitni, umesto da se nasumične datoteke ručno kopiraju na svaki server.

RAG može da radi potpuno vazdušno izolovano

RAG ne zahteva javni internet. Zahteva korpus koji se može pretraživati, pipeline za ingestiju/indeksiranje i model koji može da koristi preuzeti kontekst.

Unutar vazdušno izolovanog okruženja, skladište dokumenata, parser/OCR, model za embedding, vektorski ili leksički indeks, reranker i model za generisanje mogu svi da rade lokalno.

Ono što se menja je nabavka izvora. Pretraga weba uživo i cloud konektori za dokumente nisu dostupni osim ako se ekvivalentni podaci ne uvezu kroz kontrolisanu granicu.

Korpus stoga postaje upravljani artefakt. Svaki uvoz treba da sačuva identitet izvora, datum/verziju i poreklo kako bi korisnici znali koje znanje izolovani sistem zapravo sadrži.

Agenti mogu da rade air-gapped — ali samo sa dostupnim alatima

Petlja agenta može u potpunosti da se izvršava unutar izolovane enklave ako su model/runtime i potrebni alati lokalni ili dostupni na internoj mreži.

Alat koji zavisi od GitHub-a, javnog web pretraživanja, cloud email-a ili eksternog SaaS API-ja neće raditi osim ako arhitektura ne obezbeđuje odobreni interni ekvivalent ili kontrolisani asinhroni proces razmene.

Zbog toga dizajn air-gapped agenta treba da počne inventarom sposobnosti: svaka tačka pristupa alata mora biti klasifikovana kao interna, uvezena, nedostupna ili namerno isključena.

MCP ne zaobilazi air gap

MCP može da izloži lokalne alate i resurse unutar izolovanog AI okruženja, ali protokol ne stvara povezanost kroz bezbednosnu granicu.

Lokalni MCP server koji čita interne dokumente može savršeno da radi offline. Udaljeni MCP server na javnom internetu ne može se dosegnuti iz strogo air-gapped enklave.

Isti princip važi za bilo koji protokol konektora: interoperabilnost je odvojena od mrežnog ovlašćenja.

Identitet i autentifikacija takođe moraju da rade offline

AI aplikacija može biti lokalno hostovana dok i dalje zavisi od cloud provajdera identiteta. Ta skrivena zavisnost prekida istinski diskonektovan rad.

Air-gapped dizajni stoga zahtevaju arhitekturu identiteta koja funkcioniše unutar enklave: lokalni direktorijum, interni provajder identiteta, interna PKI, lokalni servisni akreditivi ili drugi odobreni mehanizam.

Autorizacija ostaje neophodna iako internet nije prisutan. Air gap-ovi ne zamenjuju RBAC, izolaciju zakupaca ili najmanje privilegije.

Vreme, sertifikati i trust store-ovi postaju lokalne zavisnosti

Mnogi sistemi za autentifikaciju i logovanje zavise od pouzdanog vremena. Sertifikati ističu. Trust store-ovi se menjaju. Potpisani artefakti zahtevaju validaciju.

Diskonektovana enklava stoga treba da ima internu vremensku sinhronizaciju i životni ciklus sertifikata/poverenja koji ne zavisi od pristupa javnim servisima tokom redovnog rada.

To su obične infrastrukturne brige koje postaju vidljive samo kada se arhitektura testira bez pristupa internetu.

Telemetrija i izveštavanje o padovima zahtevaju eksplicitnu politiku

Mnoge moderne biblioteke podrazumevano pokušavaju analitiku, provere ažuriranja ili prijavljivanje grešaka.

U izolovanom okruženju ti pozivi bi trebalo ili da budu onemogućeni ili preusmereni na internu observabilnost. Ponovljeni neuspešni pokušaji telemetrije mogu da izazovu kašnjenja, bučne logove i neočekivano ponašanje pri pokretanju.

Air-gapped implementacija treba da zna koji komponenti pokušavaju izlazni saobraćaj čak i ako bi ih firewall blokirao.

Air-gapped sistemi i dalje zahtevaju zakrpe

Mrežna izolacija ne sprečava softver da razvije ranjivosti. Ona samo menja način na koji zakrpe stižu do sistema.

NIST definiše upravljanje zakrpama kao preventivno održavanje: organizacije i dalje moraju da identifikuju, nabave, prioritizuju, instaliraju i verifikuju zakrpe i ažuriranja.

Air-gapped operacije stoga zahtevaju ponovljiv ritam uvoza za OS pakete, kontejnerske slike, drajvere, AI runtime-ove i bezbednosna ažuriranja. Kompromis je između stabilnosti izolacije i izloženosti ranjivostima zbog zastarelog softvera.

Kontrolisana putanja ažuriranja

Granica prenosa je najosetljiviji operativni interfejs

Ako eksterne informacije moraju da uđu u air-gapped sistem, kanal za uvoz postaje glavna tačka bezbednosne kontrole.

NSA Cybersecurity Technical Cyber Threat Framework eksplicitno prepoznaje replikaciju putem prenosivih medija kao putanju koju protivnici mogu da koriste da pređu u diskonektovane ili air-gapped mreže.

Zato kontrolisano rukovanje medijima, inspekcija, poreklo, enkripcija gde je potrebno, skeniranje na malware i razdvajanje uloga mogu biti jednako važni kao i sam AI stack.

Prenosivi mediji nisu neutralna cev

USB drajvovi i drugi prenosivi mediji mogu da nose i legitimne artefakte modela/podataka i zlonamerni sadržaj.

NIST smernice za sanitizaciju medija tretiraju storage medije kao objekat životnog ciklusa poverljivosti koji može zahtevati brisanje, čišćenje ili uništenje u skladu sa osetljivošću i potrebama ponovne upotrebe.

Tačan postupak prenosa je specifičan za organizaciju, ali arhitektonski princip je stabilan: mediji koji prelaze granice treba da budu vođeni kao bezbednosno sredstvo, a ne tretirani kao neformalna pogodnost.

Air-gapping povećava važnost lanca snabdevanja

Izolovani sistem prima manje živih spoljnih ulaza, ali svaki uvezeni binarni fajl, model, kontejner i paket postaje značajniji jer enklava može da mu veruje dugo vremena.

NIST smernice za lanac snabdevanja softverom naglašavaju poreklo, rizik dobavljača, upravljanje ranjivostima, verifikaciju softvera i prakse zasnovane na SBOM-u. Ovi problemi postaju direktno relevantni za offline uvoz AI artefakata.

Lanac snabdevanja modela zaslužuje istu pažnju kao lanac snabdevanja aplikacija: poreklo modela, licenca, heš, format, potreban kod, tokenizator, adapteri i status evaluacije treba da budu poznati pre uvoza.

Spremnost za vazdušni zid treba testirati, a ne pretpostavljati

Keširano jednom nije isto kao spremno za vazdušni zid

Sistem može izgledati offline jer su model i paketi već keširani od ranijeg pristupa internetu.

Brisanje keša ili implementacija na čistom čvoru može otkriti nedostajuće datoteke tokenizatora, Python pakete, manifeste modela ili zavisnosti udaljenog koda.

Spremnost za vazdušni zid stoga treba validirati iz čistih internih artefakata, a ne samo sa razvojne radne stanice koja je prethodno bila povezana.

Koje pretnje ostaju unutar vazdušnog zida?

Šta vazdušni zid zapravo poboljšava

Pravi vazdušni zid može materijalno smanjiti napadačke putanje koje zavise od direktne udaljene povezanosti: spoljno komandovanje i kontrola, zloupotreba cloud akreditiva, iskorišćavanje servisa okrenutih internetu i slučajno iznošenje podataka kroz obične odlazne API-je.

Takođe čini rezidentnost podataka jednostavnom u jednom uskom smislu: podaci zaključivanja ne mogu se poslati spoljnom cloud servisu ako putanja ne postoji.

Te prednosti su najjače kada su granica prenosa i interne kontrole pristupa jednako disciplinovane. Loše vođen USB proces može potkopati predviđenu izolaciju.

Šta vazdušni zid otežava

Vazdušno izolovana AI vs privatna AI

Privatna AI se prvenstveno odnosi na kontrolu osetljivih podataka i AI obrade. Privatna AI platforma može biti na lokaciji i dalje pristupati odobrenim cloud modelima ili eksternim servisima.

Vazdušno izolovana AI je stroža po pitanju povezanosti. Sistem može biti privatan bez vazdušne izolacije, a vazdušno izolovan sistem može i dalje imati slabu privatnost ako svaki interni korisnik ima neograničen pristup.

Bezbednosni cilj treba da odredi arhitekturu: poverljivost, suverenitet, otpornost i izolacija su povezani ali različiti zahtevi.

Vazdušno izolovana AI vs suverena AI

Suverena AI se tiče kontrole nad širim lancem zavisnosti: podaci, modeli, infrastruktura, operatori, jurisdikcija i strateške zavisnosti.

Vazdušna izolacija može podržati suverenitet smanjenjem eksterne zavisnosti u vreme izvršavanja, ali ne garantuje suverenu kontrolu. Enklava može i dalje zavisiti od strane hardvera, vlasničkih licenci modela ili eksternih dobavljača ažuriranja.

Sledeći kanonski članak eksplicitno razdvaja te dimenzije kontrole.

Dokazi iz originalne implementacije: šta Aaasaasa AI Client dokazuje — a šta ne

AI Hub razdvaja agent/klijent, provajdera, model i lokaciju veze. Podržava lokalno Ollama izvršavanje i rad Codex-a sa lokalnim provajderom kao različite izbore, umesto da pretpostavlja da svaki AI zahtev ide ka cloud modelu.

Repozitorijum eksplicitno napominje da lokalno izvršavanje i dalje može koristiti cloud model, dok je Direct Ollama chat lokalno izvršavanje. Ova razlika je direktno relevantna za arhitekturu vazdušne izolacije: lokalno izvršavanje ne dokazuje da su model ili okolne zavisnosti isključene.

Apstrakcija provajdera, otkrivanje lokalnih modela i lokalno izvršavanje su stoga gradivni blokovi za arhitekturu proizvoda sposobnog za vazdušnu izolaciju, ali mrežna granica, offline ogledalo zavisnosti, kontrolisani proces prenosa i offline identitet/operacije moraju se i dalje posebno projektovati.

Kada je vazdušno izolovana AI opravdana?

Vazdušna izolacija treba da bude zahtev izveden iz modela pretnji ili politike, a ne prestižna funkcija. Ima stvarnu bezbednosnu vrednost kada je eliminisana putanja povezivanja sama po sebi neprihvatljiva.

Za mnoge enterprise slučajeve upotrebe, strogo kontrolisana privatna mreža sa ograničenjima izlaznog saobraćaja, lokalnim izvršavanjem i odobrenim kanalima ažuriranja može pružiti bolji balans bezbednosti i održivosti od stroge fizičke vazdušne izolacije.

Praktičan redosled projektovanja vazdušno izolovanih AI sistema

Kontrolna lista arhitekture vazdušno izolovanog AI sistema

Česti načini neuspeha vazdušno izolovanog AI sistema

Česte zablude

Ograničenja

Strogi vazdušni jazovi čine svežinu eksternog znanja sporijom jer svaki novi izvor mora da prođe kroz proces prenosa.

Oni mogu da ograniče izbor modela kada licence, zahtevi za udaljenim kodom, hardverske potrebe ili API-ji samo kod provajdera ne mogu da se zadovolje bez mreže.

Oni povećavaju operativne troškove jer infrastruktura koja se obično troši kao cloud servisi mora da se poseduje i održava interno.

Oni takođe mogu da stvore kašnjenje zakrpa: jača kontrola promena može da održi sisteme stabilnim dok odlaže hitno otklanjanje ranjivosti.

Vazdušno izolovani AI bi stoga trebalo procenjivati kao jednu bezbednosnu arhitekturu među nekoliko, a ne pretpostavljati da je univerzalno superiorna.

Šta bi promenilo ovaj odgovor?

Podrška dobavljača za rad bez mreže menja se brzo. Novi formati modela, potpisani OCI artefakti, mehanizmi licenciranja bez mreže i integrisani registri modela mogu da smanje operativno trenje.

Razlika između strogog vazdušnog jaza i nepovezane implementacije ostaće važna čak i ako dobavljači nastave labavo da koriste te termine.

Stabilan princip je da istinske tvrdnje o vazdušnom jazu zavise od granice sistema i mehanizma prenosa, a ne od toga da li LLM slučajno radi lokalno.

Povezano kanonsko znanje

Air-Gapped AI je čvor arhitekture za bezbednost i implementaciju. Privatna AI, suverena AI i apstrakcija provajdera odgovaraju na različita pitanja o poverljivosti, kontroli i zavisnosti.

MLOps/LLMOps postaje zahtevniji u nepovezanom okruženju jer životni ciklusi modela, paketa i ažuriranja moraju da funkcionišu kroz interne repozitorijume i kontrolisani prenos.

RAG i agentna AI ostaju validni obrasci unutar enklave sve dok su njihovi podaci i alati dostupni interno.

Često postavljana pitanja

Pojmovnik

Zaključak

Air-gapped AI nije posebna vrsta modela. To je AI arhitektura koja radi unutar namerno izolovanog bezbednosnog domena.

Model može biti lakši deo. Spremnost za produkciju zavisi od toga da li svaka okolna zavisnost — sredstva modela, paketi, registri, identitet, RAG, alati, nadzor, ažuriranja i oporavak — može da funkcioniše bez automatizovane eksterne putanje.

Najkraće pouzdano pravilo je: lokalno izvršavanje dokazuje gde se model izvršava; air-gap dokaz dokazuje kako je kompletan sistem razdvojen i kako svaki dozvoljeni prenos prelazi tu granicu.

Primarni izvori i reference trenutne implementacije

Izvori u nastavku uspostavljaju bezbednosnu definiciju, trenutne obrasce implementacije nepovezane AI i rizike životnog ciklusa. Korišćenje termina „air-gapped“ od strane dobavljača namerno se razlikuje od strože NIST definicije.