What Is an Air-Gapped AI Appliance? Architecture, Boundaries, and the Update Chain

An air-gapped AI appliance is a self-contained computing system that can deliver its intended AI capability without a route to external networks. For a retrieval-augmented assistant, that boundary normally contains the model runtime, embedding and reranking models, document-processing tools, vector and metadata stores, application services, identity integration, audit records, and the configuration needed to start and recover the system.

The word appliance describes packaging and operational ownership; it does not prove isolation. The deployment design must identify every interface that crosses the boundary: user access, administrator access, approved content import, software updates, time synchronization, backup export, hardware management, and support diagnostics. Each interface needs an owner, an authorization rule, and an auditable procedure.

A model server alone is not an operational AI system. A practical design keeps five connected planes inside the controlled environment:

• Serving plane: local inference, model loading, accelerator drivers, prompt controls, and capacity management.
• Knowledge plane: parsing, chunking, embeddings, indexes, source files, document metadata, version status, and citations.
• Access plane: user and administrator identities, roles, session policy, secrets, certificates, and network policy.
• Evidence plane: query and administrative audit events, health signals, retrieval diagnostics, scan results, and exportable support bundles.
• Lifecycle plane: installation media, container images, model artifacts, package repositories, backup and restore, updates, rollback, and end-of-life decisions.

These planes can run on one server or across a small cluster. The important architectural property is that normal operation does not make an unapproved outbound call. A team should be able to trace a user question through retrieval and generation to the source passages and local services involved.

An isolated network can still contain compromised media, stale software, excessive privileges, unsafe administrative practices, or malicious documents. NIST's zero trust guidance is useful even where there is no internet connection: network location alone should not establish trust, and access decisions should be explicit and limited to the resource required.

• Separate operator, knowledge-administrator, platform-administrator, and audit responsibilities where the mission requires it.
• Restrict services to documented ports and interfaces; do not expose model or database endpoints simply because the network is isolated.
• Treat imported documents and model artifacts as untrusted until they pass the approved intake process.
• Protect local backups and exported support bundles with the same rigor as the live data they contain.
• Record configuration changes and preserve enough evidence to reconstruct what was running when an answer was produced.

Air-gapped systems still need security fixes, model changes, new knowledge, certificate maintenance, and occasional platform upgrades. Red Hat's guidance for air-gapped OpenShift describes the continuing need to mirror releases, operators, and other dependencies into an internal registry through controlled processes. The same principle applies to an AI appliance: all artifacts needed after deployment should have a documented path from an approved source to the disconnected environment.

1. Acquire artifacts in a designated connected environment from approved publishers or internal build systems.
2. Record versions, licenses, cryptographic hashes, signatures, provenance, dependencies, and a software bill of materials where available.
3. Scan and test the complete bundle in a staging environment that resembles the disconnected target.
4. Approve the change, its operational impact, transfer method, maintenance window, and rollback plan.
5. Move the sealed bundle across the boundary using the site's authorized transfer procedure.
6. Verify identity, integrity, compatibility, and approval again before importing it into the production repository.
7. Deploy in a controlled order, run acceptance tests, preserve evidence, and retain or document the rollback point.

Document updates are software-like changes to a RAG system because they alter what the system can retrieve and say. A new manual revision, rescinded instruction, local SOP, or troubleshooting card should arrive as a versioned knowledge release with an owner, effective date, distribution constraints, validation status, and supersedence relationship.

Import should be staged. Parse and index the candidate content, run retrieval and citation checks, confirm access rules, and then promote it. Keep the prior pack until rollback is no longer required. This prevents a routine document import from silently replacing current guidance with an older revision or exposing material to the wrong team.

• Can a clean installation be completed using only the delivered media and internal repositories?
• Can every user workflow succeed with external DNS and routing unavailable?
• Are model, embedding, reranking, OCR, and document-conversion artifacts all present locally?
• Can the team authenticate, recover access, rotate certificates, and restore backups without vendor reach-back?
• What telemetry exists, where is it stored, and can administrators prove that it has no external destination?
• How are urgent vulnerabilities, model replacements, and revoked knowledge handled across the boundary?
• What evidence shows the running versions, configuration, imported content, and results of acceptance tests?

A credible answer is a procedure and a test result, not a badge. The best time to discover an undeclared dependency is during acceptance testing—not after the system has moved to an environment where the missing package, model, or certificate cannot be fetched.