Air-Gapped AI: Enterprise-LLM's implementeren in streng gereguleerde sectoren

De gezondheidszorg, de financiële sector en enkele andere bedrijfstakken implementeren generatieve AI zonder ooit verbinding te maken met het openbare internet. Air-gapped is geen configuratievlag — het is een architectuur waarbij elke afhankelijkheid die het systeem bij runtime nodig heeft, zich al in de enclave bevindt.

"Air-gapped" is geen marketingclaim over de vorm van de implementatie. Het is de fundamentele beperking van de implementatievorm. Al het andere vloeit voort uit "geen route naar buiten."

Wat air-gapped daadwerkelijk betekent

In een typische enterprise-implementatie betekent "geïsoleerd" een privé-VPC, een NAT-gateway, beperkte egress en een allowlist van goedgekeurde externe eindpunten — package-registries, model-API's, telemetrie-eindpunten en identiteitsproviders. Het systeem is gescheiden; het is niet geïsoleerd. Egress bestaat, gecontroleerd maar aanwezig. Een auditor die vraagt "waarmee maakt het systeem verbinding naar buiten?" krijgt een lijst met toegestane bestemmingen, geen stilte.

Air-gapped is een sterkere claim. Er is geen NAT-gateway. Er is geen DNS-server die externe hostnamen oplost. Er is geen certificate authority-keten die iets buiten de enclave vertrouwt. Er is — afhankelijk van het regime — óf helemaal geen netwerkverbinding met de buitenwereld, óf alleen een eenrichtingsdatadiode voor de export van telemetrie. Code, data en afhankelijkheden komen binnen via ondertekende fysieke media; niets komt binnen via het netwerk. De auditor die dezelfde vraag stelt, krijgt een definitief antwoord: niets verlaat de enclave, niets komt binnen, behalve via de gecontroleerde frequentie waarop de implementatie is gecertificeerd.

Dit is de implementatiestructuur voor geclassificeerde defensieworkloads (typische accreditatiekaders: DoD IL5 en IL6, FedRAMP High, soms CMMC Level 2 of Level 3 voor de defensie-industrie), voor gezondheidszorgsystemen die gecontroleerde klinische gegevens verwerken (HIPAA met HITRUST CSF-attest, soms aanvullende eisen op staat- of nationaal niveau), voor financiële systemen onder strengere regelgeving (FFIEC en SR 11-7 voor bankmodelrisico, NYDFS Part 500 voor cybersecurity) en voor industriële besturingsomgevingen waar elk uitgaand verkeer volgens het beleid is verboden. Het onderscheid is juridisch van belang, niet alleen operationeel: een "geïsoleerde" implementatie kan onder sommige regelgevende kaders nog steeds worden beschouwd als een gegevensoverdracht aan een leverancier; een air-gapped implementatie kan dat per definitie niet.

De architectuur, aan beide zijden van de muur

Het diagram toont de architectuur. Elk onderdeel dat een met het internet verbonden implementatie ergens extern zou ophalen, moet een mirror hebben binnen de enclave. De mirror is aanwezig; de consumptie is lokaal. De integriteit van de implementatie hangt ervan af dat elke byte van elke afhankelijkheid verantwoordbaar is — geversioneerd, ondertekend, gescand en bevroren op het moment van staging. De rechterzijde van het diagram is wat een op Helm gebaseerde installatie van een AI-platform zoals TrueFoundry binnen de enclave opbouwt: de gateway data plane, de model-registry, de serving workers, de vector-store, de observabiliteits-stack, de policy engine — allemaal verbonden met de on-premise IdP, de interne CA en de SIEM van de klant via Helm-waarden in plaats van leverancierseindpunten.

Alles wat zich binnen de enclave moet bevinden

Lokale model-registry

Modelgewichten worden één keer geïmporteerd via een ondertekend pakket, SHA-256 geverifieerd tegen de gepubliceerde hash van de auteur van het model, en vervolgens verzegeld binnen de enclave. Volgende inference workers putten uit de lokale registry, nooit uit HuggingFace. Updates volgen hetzelfde pad: een nieuwe modelversie komt binnen op fysieke media, wordt gecontroleerd op handtekening en wordt in de registry geplaatst onder een nieuw versielabel.

Dit klinkt bewerkelijk voor teams die gewend zijn aan pip install, en dat is het ook. De reden waarom het de moeite waard is, is dat de integriteit van de implementatie afhangt van de verantwoording van elke byte van elke gewichtenset. Het proces van geauthenticeerde import vormt de audit trail. Wanneer de auditor vraagt "waar komt dit model vandaan en hoe weet u dat er niet mee is geknoeid?", antwoordt de implementatie met een keten van handtekeningen: de auteur van het model heeft de release ondertekend, het beveiligingsteam heeft de handtekening bij de import geverifieerd en de registry heeft de versie vastgelegd volgens een beheerproces. Die keten maakt het model bruikbaar in een gereguleerde context.

Het metadataschema van de registry is net zo belangrijk als de opslag. Elke modelversie wordt vastgelegd met de bron, de hash, de importdatum, de verantwoordelijke engineer en de evaluatieresultaten waarmee het is goedgekeurd voor productie. Dit is dezelfde discipline voor geversioneerde artefacten die het team toepast op code, maar dan toegepast op modelgewichten. Bij TrueFoundry bevat de Model Registry deze velden als eersteklas metadata, zodat de vraag van de auditor een gestructureerd antwoord krijgt in het platform zelf, in plaats van in een spreadsheet dat eigendom is van één persoon. Teams die modellen behandelen als ad-hoc bestanden hebben het zwaar tijdens audits; teams die ze behandelen als artefacten van de codeklasse hebben de antwoorden direct klaar.

vLLM / TGI workers op lokale GPU's

Generatie van tokens vindt volledig plaats binnen de enclave, op het H100-, A100- of MI300-cluster van de klant (of wat het regime ook toestaat; sommige geclassificeerde omgevingen beperken de hardwarekeuze als onderdeel van de controle op de toeleveringsketen). Er verlaat nooit een API-call naar een provider de grens. De serving-stack is dezelfde vLLM, TGI of SGLang die de rest van de wereld gebruikt; wat verandert is dat deze draait in een omgeving waar hij niet naar huis kan bellen voor telemetrie, automatische model-updates of externe embedding-services.

De serving-engines zelf hebben meestal patches nodig voor air-gapped werking. vLLM controleert standaard HuggingFace voor tokenizer-bestanden als ze niet vooraf zijn klaargezet; die controle moet worden uitgeschakeld, of de tokenizer moet zich op het lokale registry-pad bevinden. Sommige engines maken bij het opstarten verbinding met telemetrieservers; die calls moeten worden opgevangen of naar een lokale sink worden geleid. Het patchwerk is eenmalig, maar het is essentieel: teams die dit overslaan ontdekken de foutmodi bij runtime, wanneer een worker-pod weigert te starten omdat hij het internet niet kan bereiken voor een metadatacontrole. De serving-stack van TrueFoundry wordt geleverd met deze air-gapped patches — tokenizer-bronnen wijzen naar lokale registry-paden, telemetrie-eindpunten wijzen naar de on-premise observabiliteits-stack en automatische updates staan standaard uit in de air-gapped Helm-waarden. Dezelfde vLLM-, TGI- en SGLang-backends die teams gebruiken in verbonden implementaties, draaien in de enclave; het verschil zit in het waardenbestand dat de implementatie laadt.

Lokale vectordatabase met lokale embedding

RAG over geclassificeerde documenten vereist dat het embedding-model ook binnen de enclave draait. Het verzenden van tekst naar een externe embedding-API, zelfs een API die wordt geleverd door een grote cloudprovider, is de actie die in de praktijk de air gap het vaakst doorbreekt. Teams ontdekken het lek wanneer netwerkmonitoring DNS-queries naar api.openai.com laat zien die afkomstig zijn uit de veronderstelde air-gapped retrieval-pipeline; de embedding-stap gebruikte een SDK die standaard naar de cloudprovider wees.

De implementatie maakt gebruik van een on-premise embedding-model — typisch een kleiner open-source model dat snel is op CPU of efficiënt draait op dezelfde GPU's als de serving workers. Veelvoorkomende keuzes: een 384- of 768-dimensionaal embedding-model zoals bge-small, nomic-embed, of een domeingetunede variant voor gespecialiseerde content. De vectorindex is at rest versleuteld met door de klant beheerde sleutels, alleen toegankelijk van binnen de enclave en geback-upt naar hetzelfde mediatype als de rest van de implementatie.

De keuze voor de vector-store — Milvus, Qdrant, pgvector — is minder belangrijk dan de hygiëne van de implementatie eromheen. De store vereist dezelfde behandeling als geversioneerd artefact als de model-registry: de corpus-snapshots worden vastgelegd, de versie van het embedding-model wordt vastgelegd en het opbouwproces van de index is reproduceerbaar. Wanneer het corpus verandert, draait de re-embedding-taak op een gecontroleerde frequentie en kan de auditor elk zoekresultaat herleiden tot een specifieke corpus-snapshot. Het deployment-manifest van TrueFoundry zet het on-premise embedding-model en de vector-store vast als onderdeel van dezelfde Helm-installatie, zodat het team ze niet afzonderlijk hoeft te verzamelen tijdens de staging — de keuze van het embedding-model en de vector-backend is een knop in het waardenbestand; de air-gap-status is dat niet.

Zelfstandige gateway data plane

TrueFoundry's AI Gateway draait in air-gapped implementaties als een gecontaineriseerde workload die via Helm wordt geïmplementeerd in het Kubernetes-cluster van de klant binnen de enclave. Er zijn geen uitgaande netwerkafhankelijkheden voor de runtime-operaties: identiteit is afkomstig van de lokale IdP (typisch Active Directory of LDAP, soms een door de klant beheerde SAML-provider), beleid staat op de lokale schijf onder versiebeheer en auditlogs gaan naar de lokale SIEM (Splunk on-premise in de meeste defensie-implementaties, soms een door de klant gebouwd equivalent). Er is geen telemetrie naar de control plane van een leverancier; geaggregeerde statusmetrieken gaan, indien ze überhaupt worden geëxporteerd, via een eenrichtingsdatadiode naar een afzonderlijk gecertificeerde bewakingsomgeving.

De functionaliteit van de gateway is in air-gapped implementaties hetzelfde als in verbonden implementaties. Dezelfde tokens-per-uur rate limiting per project, team of workflow. Dezelfde budgethandhaving per project met harde limieten die nieuwe verzoeken blokkeren wanneer een budget is bereikt. Dezelfde op prioriteit gebaseerde fallback-routing langs lokale modeldoelen. Dezelfde in- en uitvoerguardrails — PII / PHI-redactie op invoer voordat het model deze ziet, detectie van geheimen op uitvoer voordat deze de client bereikt, en detectie van prompt-injectie voor agentic workloads. De functies werken; ze sturen hun telemetrie naar de on-premise stack in plaats van naar de observabiliteitscloud van een leverancier. De configuratie die ze aanstuurt is dezelfde YAML.

Dit is belangrijk in de praktijk, omdat een platformteam dat een verbonden ontwikkelomgeving en een air-gapped productieomgeving beheert, niet twee platforms beheert — ze beheren één platform met twee waardenbestanden. De gateway-image is hetzelfde; de chart is hetzelfde; de API-structuur is hetzelfde. De investering in de gateway rendeert gelijktijdig over elke implementatievorm.

Container-registry en package-mirrors

Elke container-image die de implementatie gebruikt, moet ergens vandaan komen. In een verbonden omgeving is dat ergens Docker Hub of ECR. Binnen de enclave is het een lokale Harbor of gelijkwaardige registry, die tijdens staging wordt gevuld vanuit externe mirrors en vervolgens wordt bevroren. Hetzelfde geldt voor PyPI, npm, apt en elke andere package manager waar het systeem van afhankelijk is. Snapshots worden bij staging gescand op kwetsbaarheden en vervolgens vastgezet.

De regel is dat niets wat het systeem bij runtime nodig heeft een bewegend doel mag zijn. De wereld buiten verandert; de binnenkant van de enclave verandert niet, behalve op een gecontroleerde frequentie. Een CVE die gisteren is gepubliceerd in een Python-afhankelijkheid wordt niet automatisch doorgevoerd in de enclave; deze wordt doorgevoerd bij de volgende geplande update, nadat het beveiligingsteam deze heeft beoordeeld. Dit is soms ongemakkelijk voor teams die gewend zijn aan apt-get upgrade; het is de keuze die de implementatievorm vereist.

De air-gapped installatieworkflow van TrueFoundry publiceert alle container-images en Helm-charts naar een OCI-compatibele registry onder beheer van de klant. De klant repliceert tijdens staging vanuit de upstream-registry van TrueFoundry (tfy.jfrog.io/tfy-images voor de container-images, tfy.jfrog.io/tfy-helm voor de Helm-charts), of werkt vanuit de bestaande Harbor of Artifactory van de klant als het release-engineeringteam van de klant de upstream-mirror-discipline al beheert. De catalogus van de container-registry wordt de inventaris van afhankelijkheden — wanneer een auditor vraagt "welke software draait er in deze enclave?", is het antwoord het manifest van de registry. Teams die hun registry niet netjes houden zakken voor deze vraag; teams die de registry behandelen als een gecureerde, verantwoorde inventaris slagen.

On-premise observabiliteit

Prometheus, Grafana en Loki dekken de meeste metrieken, dashboards en logs af. Alles on-premise. Dashboards worden geëxporteerd naar een lokale SOC-console, niet naar een SaaS-leverancier. De routing van waarschuwingen verloopt via interne e-mail of lokale Slack-equivalenten, niet via Twilio of PagerDuty. De observabiliteits-stack zelf is een van de grotere workloads binnen de enclave; het is niet ongewoon dat de bewakingsinfrastructuur tijdens rustige periodes meer rekenkracht verbruikt dan de AI-workloads die het bewaakt.

TrueFoundry's gateway is OpenTelemetry-native; in air-gapped implementaties stuurt de OTEL-pipeline gegevens naar de lokale Prometheus en Loki in plaats van naar de observabiliteitscloud van een leverancier. Zelfde instrumentatie, hetzelfde trace-schema, andere bestemming. Observabiliteit per verzoek omvat de identiteit, de workload-tag, het opgeloste model, de toegepaste beleidsbeslissingen, de guardrail-oordelen en de trace-ID — alles wat de audit nodig heeft om te reconstrueren wie wat heeft gevraagd, aan welk model, onder welk beleid en hoe de gateway heeft gereageerd. De bewaartermijn van auditlogs is configureerbaar voor de lange bewaarperiodes (zeven jaar is gebruikelijk in defensie- en gereguleerde financiële omgevingen) die auditregimes vereisen.

Het routeren van waarschuwingen is de plek waar de meeste teams ontdekken dat hun on-premise veronderstellingen onjuist zijn. Het verzenden van een sms via Twilio wanneer de gateway overbelast raakt, is het juiste gedrag in een verbonden implementatie, maar een schending van de air gap in een enclave. Het incident-response draaiboek van het team moet worden herschreven voor de enclave: de piketdienst krijgt de melding via interne kanalen, het SOC krijgt een parallelle melding via interne escalatie, en de externe escalatie naar de leverancier (indien aanwezig) verloopt via een ander, gecertificeerd kanaal.

Interne certificate authority

Openbare CA's (Let's Encrypt, DigiCert) zijn niet bereikbaar. De implementatie maakt gebruik van de interne PKI van de klant, waarbij trust anchors tijdens de installatie worden geladen. mTLS tussen gateway en workers, tussen gateway en IdP, tussen elke interne dienst: alles geverifieerd tegen de interne CA. Dit klinkt als een detail; het is de reden waarom de meeste "geïsoleerde" implementaties in werkelijkheid niet air-gapped zijn, omdat iemand certbot heeft achtergelaten die verbinding zoekt met een openbaar eindpunt om een certificaat te vernieuwen.

De interne CA is de verantwoordelijkheid van de klant, niet van het platform. Het platform gebruikt de trust anchors van de CA tijdens de installatie — voor TrueFoundry via Helm-waarden die wijzen naar het trust-anchorbestand dat in de gateway-pods is gemount. Het PKI-team van de klant beheert de CA, geeft certificaten uit en roteert deze. De levenscyclus van certificaten is een van de operationele taken waar het PKI-team van de klant rekening mee moet houden. Kortlopende certificaten (90 dagen of korter) zijn de aanbevolen praktijk, maar vereisen automatisering die het team moet inrichten voordat de implementatie live gaat.

Het updatepad

Updates vormen de operationele werkelijkheid die air-gapped onderscheidt van theoretisch air-gapped. Het model wordt beter; de gateway krijgt nieuwe functies; vLLM brengt een kritieke fix uit. Geen van deze kan worden toegepast via git pull.

De vereiste werkwijze is een workflow met ondertekende bundles. De leverancier publiceert een release als een ondertekende tarball — manifesten, container-images, Helm-chart en (indien van toepassing) gewichtenartefacten, met een integriteitshash. De bundle wordt geladen op fysieke media (meestal een USB-stick of verwijderbare harde schijf, afhankelijk van het mediabeleid van het regime), door de air gap gedragen en klaargezet op een server binnen de enclave. De integriteit wordt geverifieerd, handtekeningen worden gecontroleerd aan de hand van vooraf geladen openbare sleutels van de leverancier en de bundle wordt geïnstalleerd onder een nieuw versielabel. De vorige versie blijft gedurende een configureerbare periode — doorgaans 30 dagen — beschikbaar voor een rollback, zodat een problematische update kan worden teruggedraaid zonder een nieuwe importcyclus.

De air-gapped releases van TrueFoundry worden in exact deze vorm geleverd: ondertekende bundles met de chart, de manifesten, de gateway- en worker-images, en de integriteitshashes. Verificatie vindt plaats aan de hand van vooraf geladen openbare sleutels van TrueFoundry; de bundle wordt in de registry van de klant geplaatst onder een nieuw versielabel; een rollback is een eenvoudige Helm-rollback naar de vorige chart-revisie. De accreditatiebeoordeling van de klant is van toepassing op de bundle, niet op een continue stroom van wijzigingen — elke update is een afzonderlijke accreditatiegebeurtenis met een duidelijke situatie vooraf en achteraf. Dat is precies de eigenschap waarvoor de bundle-workflow bestaat.

De frequentie hangt af van het regime. Sommige defensie-omgevingen accepteren kwartaalupdates; sommige gezondheidszorgomgevingen staan maandelijkse updates toe. Sommige omgevingen accepteren niets zonder een afzonderlijke accreditatiebeoordeling per release — elke bundle is een nieuwe accreditatiegebeurtenis. Het platform moet al deze varianten ondersteunen zonder van vorm te veranderen; de configuratie van "hoe vaak we updaten" is aan de klant, niet aan de leverancier.

Implementatievormen per regelgevingsniveau

De vier niveaus vertegenwoordigen een continuüm van vertrouwen tussen de implementatie en de buitenwereld. Het verbonden niveau (de meeste workloads, de meeste ondernemingen) accepteert connectiviteit met leveranciers als een routinematig onderdeel van de werking. Het BYOC-niveau accepteert leveranciersconnectiviteit voor de control plane, maar niet voor data — payloads blijven binnen het cloudaccount van de klant. Het niveau air-gapped + diode accepteert alleen eenrichtingsexport, typisch voor SOC-monitoring van geaggregeerde statusmetrieken. Het volledig air-gapped niveau accepteert geen enkele vorm van netwerkconnectiviteit. Het meeste geclassificeerde defensiewerk draait in de onderste twee niveaus; de meeste gezondheidszorg en financiële toepassingen draaien in BYOC; de meeste algemene enterprise-toepassingen draaien in verbonden omgevingen.

TrueFoundry ondersteunt alle vier de niveaus vanuit dezelfde codebase — dezelfde gateway-image, dezelfde Helm-chart, hetzelfde configuratieschema. De Helm-waarden veranderen per niveau; de gateway-primitieven veranderen niet. De control plane en de gateway data plane kunnen onafhankelijk van elkaar worden geïmplementeerd, wat dit mogelijk maakt: in verbonden SaaS draaien beide planes in de omgeving van TrueFoundry; in BYOC is de control plane SaaS en draait de data plane in de VPC van de klant; in air-gapped draaien beide planes binnen de enclave van de klant. Een platformteam dat SaaS draait in de ontwikkelomgeving en air-gapped in geclassificeerde productie, beheert niet twee platforms — het beheert één platform dat anders is geconfigureerd. De investering in de gateway rendeert gelijktijdig over elke implementatievorm.

Foutmodi die per ongeluk de air gap opheffen

De meeste "air-gapped" implementaties die voor hun eerste audit zakken, falen niet omdat de architectuur verkeerd was, maar omdat een specifieke afhankelijkheid een lek in de scheiding heeft veroorzaakt. Vijf patronen komen herhaaldelijk voor bij eerste pogingen van teams; deze vooraf kennen zorgt voor implementaties die de controle doorstaan.

Standaard SDK-telemetrie. Cloudprovider-SDK's (boto3, google-cloud, azure-sdk) sturen bij het initialiseren routinematig telemetrie naar eindpunten van de leverancier. De applicatiecode ziet er onschuldig uit — het importeert een bibliotheek, instantieert een client — en de bibliotheek maakt verbinding met de buitenwereld voordat de code van het team iets doet. De oplossing is het controleren van het netwerkgedrag van elke afhankelijkheid tijdens staging, het uitschakelen van telemetrie via configuratie waar de SDK dit ondersteunt, en het patchen waar dat niet het geval is. Egress-monitoring tijdens staging brengt deze calls aan het licht vóór productie.

Automatisch downloaden van tokenizers. Veel ML-bibliotheken downloaden bij het eerste gebruik standaard tokenizer-bestanden van HuggingFace. De serving-engine die het model met succes heeft geladen, faalt drie weken later wanneer een worker-pod herstart en de gecachte tokenizer verdwenen is. De oplossing is het vooraf instellen van tokenizers in de lokale registry en de engine via de configuratie naar het lokale pad te verwijzen, in plaats van te vertrouwen op het standaard downloadgedrag.

Pullen van container-images bij runtime. Een Kubernetes-implementatie die verwijst naar image: vllm/vllm:latest in plaats van image: harbor.internal.example.mil/vllm/vllm:v0.6.3 faalt bij runtime in een air-gapped omgeving. De oplossing is het beleid voor registry-mirrors: elke imageverwijzing in elk manifest wijst naar de lokale Harbor; geen enkel manifest verwijst naar een externe registry. Admission controllers kunnen dit afdwingen tijdens het implementeren.

Vernieuwing van certificaten die naar buiten reikt. De deployment werd geïnstalleerd met interne certificaten; de automatische vernieuwing staat standaard ingesteld op Let's Encrypt of een vergelijkbare openbare CA. Drie maanden later wordt de vernieuwingstaak uitgevoerd en mislukt deze — of erger nog, slaagt deze in het bereiken van het openbare eindpunt, wat de audit-posture verstoort. De oplossing is om de certificaatvernieuwing vanaf dag één aan te sluiten op de interne PKI van de klant, en niet pas achteraf.

NTP en DNS over de lijn. Tijdssynchronisatie staat standaard op openbare NTP-pools; DNS-resolutie staat standaard op openbare servers. Het netwerk van de deployment is "geïsoleerd", maar op de een of andere manier communiceren de worker pods nog steeds met pool.ntp.org. De oplossing is de interne NTP- en DNS-infrastructuur van de klant, geconfigureerd op clusterniveau, zodat geen enkele pod per ongeluk naar buiten kan reiken, zelfs als de applicatiecode dat niet van plan was.

Het bekende patroon: de fout zit in de platformlaag onder de AI workload, niet in de AI workload zelf. Het team schrijft hun RAG-pipeline correct, maar een transitieve afhankelijkheid maakt verbinding met de buitenwereld. De verdediging is gefaseerde egress-monitoring — de deployment uitvoeren in een verbonden sandbox met volledige egress-logging, elke onverwachte uitgaande verbinding behandelen als een bevinding, en pas overgaan tot de air-gapped installatie zodra de sandbox schoon is. TrueFoundry's connected-mode staging-omgeving bestaat precies hiervoor: de gateway-image en de Helm chart die in de enclave gaan draaien, worden eerst uitgevoerd in een sandbox waar elke uitgaande verbinding waarneembaar is. Zo komen mogelijke fouten aan het licht voordat ze een gereguleerde omgeving bereiken. De integriteit van de air-gapped deployment wordt grotendeels betaald tijdens de staging-fase.

Hoe dit uit te rollen zonder zaken te verstoren

Air-gapped uitrollen gaat trager dan BYOC-uitrollen, wat weer trager gaat dan SaaS-adopties. De onderstaande volgorde is het typische meermaandelijkse plan; dit overhaasten leidt tot deployments die zakken voor de accreditatiebeoordeling.

Maanden 1-2 — Accreditatie-traject. Het beveiligingsteam van de klant en de accreditatie-autoriteit beoordelen de documentatie van het platform, de datainventarisatie, de update-workflow en de cryptografische posture. Het resultaat is een accreditatiepakket dat precies definieert hoe de deployment eruit gaat zien en welke controles van toepassing zijn. Dit is het artefact waarlangs de deployment later wordt gemeten; dit in één keer goed doen bespaart weken aan herstelwerkzaamheden. Het deployment-engineeringteam van TrueFoundry neemt doorgaans deel aan deze fase en levert de architectuurdocumentatie, FIPS 140-3 cipher-posture (waarbij de deployment draait binnen AWS GovCloud of Azure Government) en het ondertekeningsproces voor de bundel dat de accreditatie-autoriteit zal beoordelen.

Maanden 3-4 — Staging-omgeving. De klant bouwt een staging-enclave die de topologie van productie weerspiegelt, maar geen geclassificeerde data bevat. Het platform wordt geïnstalleerd via Helm vanaf de lokale registry-mirror; de integraties (IdP, SIEM, interne CA, on-prem observability) worden aangesloten; de update-workflow wordt getest met een ondertekende voorbeeld-bundel. De staging-deployment draait ten minste een maand onder gesimuleerde belasting, met volledige egress-logging ingeschakeld, zodat elke onverwachte uitgaande verbinding als een bevinding aan het licht komt vóór productie.

Maanden 5-6 — Productie-installatie en accreditatie. Het platform wordt geïnstalleerd in de productie-enclave. De accreditatie-autoriteit voert de formele beoordeling uit op basis van het eerder overeengekomen pakket. Bevindingen worden verholpen; de deployment wordt geaccrediteerd onder het toepasselijke autorisatiekader (DoD IL5/IL6 voor geclassificeerde defensie, FedRAMP High voor federale overheden, sectorspecifieke kaders voor de gezondheidszorg en de financiële sector).

Maanden 7+ — Continu gebruik (steady-state). Het platform bedient gereguleerde workloads. De update-workflow draait op de gecertificeerde frequentie (driemaandelijks, maandelijks of per accreditatie-gebeurtenis). Het beveiligingsteam van de klant is eigenaar van de operationele compliance-posture; het SRE-team van de klant is verantwoordelijk voor de dagelijkse werking. TrueFoundry trekt zich terug naar het geaccrediteerde escalatiekanaal voor incidentondersteuning en de driemaandelijkse releasefrequentie — de deployment is op dit punt van de klant, niet van de leverancier.

Wat dit niet is

Air-gapped is niet hetzelfde als simpelweg on-prem draaien. Een typische on-prem deployment maakt nog steeds verbinding met package managers, haalt container images uit externe registries en stuurt telemetrie naar een SaaS-observabilityleverancier. Die deployment bevindt zich in het datacenter van de onderneming. Deze is niet air-gapped. De twee worden regelmatig verward, en die verwarring is precies waar toezichthouders naar zoeken tijdens audits.

Het is ook niet vrij van operationele kosten. Het onderhouden van gespiegelde registries, het beheren van een interne PKI, het uitvoeren van release-engineering volgens een driemaandelijkse cyclus — dit zijn reële engineeringbelastingen die niet bestaan bij verbonden deployments. De teams die air-gapped systemen beheren weten dit; de teams die er een gaan erven meestal niet, en het gat daartussen is waar de meeste mislukte deployments uit voortkomen. Inkoopevaluaties voor air-gapped platforms onderschatten de doorlopende operationele belasting voor de klant vaak met een factor twee of drie.

En het is geen vervanging voor compliance-praktijken. De architectuur neemt de via het netwerk overgedragen risico's weg; het neemt niet de door mensen veroorzaakte risico's weg. Interne dreigingen (insider threats), verkeerde configuraties, beleidsschendingen en operationele fouten blijven risico's die het beveiligingsteam van de klant moet beheren. De air gap is een sterke fysieke controle; het is geen vervanging voor de rest van een defence-in-depth posture.

En het is niet de juiste oplossing voor elk team. Organisaties wier workloads eigenlijk geen air-gapped posture vereisen, betalen de operationele kosten zonder de regelgevende voordelen te genieten; voor die workloads biedt BYOC het meeste voordeel op het gebied van datasoevereiniteit tegen een fractie van de operationele kosten, en de connected tier is aanzienlijk eenvoudiger. Organisaties die al volwassen air-gapped platforms hebben gebouwd met hun eigen accreditatie-reclevel, worden geconfronteerd met migratiekosten in een geaccrediteerde omgeving die moeilijk te rechtvaardigen zijn. Air-gapped is de deploymentvorm voor workloads waarbij het regelgevingsregime geen enkele externe connectiviteit toestaat; voor al het andere bestaan de eenvoudigere tiers met een reden.

Het is de taak van het platform om de operationele belasting hanteerbaar te maken, niet om te doen alsof deze niet bestaat.

FAQ

Hoe werkt de air-gapped installatie van TrueFoundry precies van begin tot eind?

De klant richt een OCI-compatibele registry in binnen de enclave (meestal Harbor, soms JFrog Artifactory of het cloud-equivalent). Het release-engineeringteam spiegelt de container images en Helm charts van TrueFoundry — bijvoorbeeld afkomstig van tfy.jfrog.io/tfy-images en tfy.jfrog.io/tfy-helm — naar de registry, hetzij door directe replicatie vanuit een verbonden staging-omgeving, hetzij via een ondertekende bundel die via fysieke media over de air gap wordt gebracht. De Helm-installatie draait vervolgens op de lokale registry, de lokale image-manifesten en het Kubernetes-cluster van de klant. Helm-waarden verwijzen naar de IdP, interne CA, SIEM en observability-stack van de klant. Dezelfde chart die in een verbonden dev-omgeving wordt geïnstalleerd, wordt geïnstalleerd in de air-gapped productie-omgeving; alleen het waardenbestand verschilt.

Hoe werken we het model bij als er een nieuwe release is?

Via de ondertekende bundel-workflow. De maker van het model publiceert een release; het release-engineeringteam van de klant importeert deze volgens de gecertificeerde frequentie (driemaandelijks, maandelijks of per accreditatie-gebeurtenis). De bundel wordt gecontroleerd op handtekening, klaargezet in de lokale registry, uitgerold naar een canary-subset en na observatie doorgezet naar productie. De vorige versie blijft binnen een configureerbaar tijdvak beschikbaar voor een rollback.

Kunnen we frontier models zoals Claude of GPT-4 gebruiken in een air-gapped deployment?

Nee — gehoste frontier-modellen bevinden zich per definitie buiten de enclave; deze aanroepen zou de air gap doorbreken. Air-gapped deployments maken gebruik van zelfgehoste open-source modellen (Llama, Mistral, Qwen, Phi-3) op lokale GPU's. De kwaliteit is vaak voldoende voor de klasse van de workload (extractie, samenvatting, classificatie, RAG op interne corpora); workloads die echt frontier reasoning vereisen, passen doorgaans niet binnen de air-gapped posture en moeten worden ontworpen voor een minder beperkte tier.

Hoe zit het met het patchen van CVE's — beveiligingsupdates kunnen niet wachten op een driemaandelijkse cyclus?

Kritieke beveiligingsupdates hebben een out-of-band pad: een ondertekende spoedbundel, sneller gecertificeerd dan de standaardcyclus, gedistribueerd via dezelfde gestroomlijnde fysieke media-workflow. Het beveiligingsteam van de klant beslist of een CVE als spoedgeval kwalificeert; het releaseproces van het platform ondersteunt de snellere cyclus voor de gevallen waarin dat nodig is. De afweging is dat spoedbundels delen van de normale accreditatiebeoordeling omzeilen en een validatie achteraf vereisen.

Hoe groot is het operationele team voor een air-gapped deployment?

Groter dan voor een verbonden deployment van dezelfde workload — gemiddeld ongeveer 2 tot 3 keer zo groot. De klant heeft capaciteit nodig voor PKI-beheer, registry-onderhoud, release engineering, accreditatie-afstemming en de gebruikelijke SRE-rotatie. Voor een enkele workload kan dit 3 tot 5 toegewezen engineers betekenen; voor een deployment die meerdere workloads host, zijn de marginale kosten per workload lager omdat de operationele infrastructuur wordt gedeeld.

Hebben we air-gapped GPU's nodig, of kunnen we elke GPU-hardware gebruiken?

De GPU's zelf zijn hetzelfde; wat verandert is de toeleveringsketen en het firmwarebeleid. Geclassificeerde omgevingen kunnen beperkingen opleggen aan welke hardware van leveranciers acceptabel is, specifieke firmwareversies vereisen en een gevalideerde herkomst van de toeleveringsketen eisen. Het platform draait op wat het hardwarebeleid van het regime toestaat; het inkoopteam van de klant verzorgt de inkoop van de hardware.

Kan de data diode in real-time telemetrie exporteren?

Voor de diode-tier wel — telemetrie kan continu worden geëxporteerd, maar alleen in één richting (eenrichtingsverkeer). De diode is een fysieke garantie dat er geen data via het exportkanaal de enclave kan binnendringen. Wat naar buiten stroomt, is wat de accreditatie van de klant heeft goedgekeurd: geaggregeerde metrieken, gestructureerde operationele telemetrie, eventueel geanonimiseerde prestatiegegevens. Payloads per verzoek stromen onder geen enkele voorwaarde naar buiten.

Hoe werkt de eval-pipeline in een air-gapped deployment?

Identiek aan een verbonden deployment, maar met alles lokaal. De golden set bevindt zich op lokale opslag. De replay-taak draait op de lokale serving-vloot. Het judge-model is een van de lokaal geïnstalleerde open-source modellen. De dashboards voor segmentatie bevinden zich in de lokale Grafana. De auto-rollback haakt in op het lokale prompt-versieregistry. De evaluatiediscipline is hetzelfde; alleen de bestemmingen verschillen.

‍

‍