Flagship Solution
Sovereign AI for Air-Gapped Platforms
A detailed architecture for building, approving, and running RAG, local LLM, ML, and agentic AI workloads in disconnected environments using controlled internal artifact supply chains.
Architecture visual
Build once. Approve once. Run offline with control.
The architecture separates untrusted external sources from the air-gapped runtime. Artifacts are imported, checked, approved, stored internally, then used by offline build and runtime layers.
Problem
Why air-gapped AI needs more than a model
Running a model offline is only one part of the problem. A real sovereign AI platform must control the complete supply chain behind the AI system.
Layer 0
Internet, outside boundary, and untrusted network
The architecture starts by drawing a hard boundary between external sources and the internal controlled environment.
Internet
External artifact sources may include public registries, package indexes, model hubs, vendor portals, and open-source repositories. These sources are useful, but they are not directly trusted by the runtime.
Outside Boundary
The outside boundary marks the point where artifacts must stop being treated as automatically trusted. Everything crossing the boundary must go through import, inspection, approval, and recording.
Untrusted Network
The external network is treated as untrusted for runtime operations. Runtime workloads should not reach out to public sources to download packages, models, prompts, or tools.
Layer 1
Connected Import Zone
The connected import zone is the only layer designed to interact with external sources. Its job is to collect candidate artifacts before approval.
Docker Images
Approved base images, service images, database images, model-serving images, and platform utility images imported from trusted external sources.
Python Packages
Pinned Python wheels and dependency sets downloaded before offline use, then made available through an internal wheelhouse.
Model Files
LLM weights, embedding models, rerankers, classifiers, and other local inference artifacts approved for internal use.
Datasets
Approved evaluation datasets, test sets, sample knowledge documents, and controlled domain datasets used for validation and runtime workflows.
Prompts
System prompts, RAG prompts, guardrail prompts, evaluation prompts, and operational templates versioned as controlled artifacts.
Agent Tools
Approved local tools that agents can call, such as document search, calculators, classifiers, workflow actions, and restricted internal APIs.
Layer 2
Security and Approval Gate
The approval gate converts raw imported artifacts into approved internal artifacts. The goal is to move from risk to approved state with evidence.
Malware Scan
Inspect imported files, images, and packages for malicious payloads before they cross into the internal environment.
SBOM Check
Generate or inspect a Software Bill of Materials so teams know which dependencies and components are inside each artifact.
Checksum Verification
Compare downloaded artifacts against expected hashes to detect corruption, tampering, or uncontrolled replacement.
Signature Verification
Verify signed artifacts when signatures are available, and record signing status as part of the approval evidence.
License Compliance
Review package, image, model, and dataset licenses before artifacts are approved for internal enterprise use.
Vulnerability Scan
Scan images and packages for known vulnerabilities and define acceptance rules before the artifact is promoted.
Human Approval
Require a named approval step before artifacts become available for offline builds or runtime workloads.
Risk to approved
The gate should not only block bad artifacts. It should also create approval records, checksums, scan evidence, and version metadata so future builds are explainable.
Layer 3
Internal Artifact Hub
The internal artifact hub is the controlled source of truth for AI builds and runtime dependencies. It should be secure, curated, and governed.
This is the layer that prevents every project team from independently pulling from the internet. Teams consume approved internal artifacts instead.
Container Registry
Stores approved container images such as Python base images, application images, model-serving images, and platform services.
Python Wheelhouse
Stores Linux-compatible Python wheels so offline builds can run pip install with --no-index and avoid public PyPI access.
Model Registry
Stores approved model metadata, model files, model versions, runtime notes, and model usage constraints.
Dataset Store
Stores approved document sets, evaluation data, sample test data, and domain datasets used for RAG, ML, and validation.
Prompt Registry
Stores versioned prompts for RAG, agents, safety checks, hallucination control, evaluation, and model routing.
Agent Tool Registry
Stores approved tool definitions, allowed actions, blocked actions, network rules, and tool-level audit requirements.
SBOM & Signatures
Stores SBOM files, checksums, signature status, scan records, and artifact approval metadata for traceability.
Hub control properties
The image calls out five lower-layer controls that make the hub enterprise-ready: immutable, versioned, traceable, auditable, and encrypted.
Immutable
Approved artifacts should not be silently overwritten. New changes should create new versions or new approval records.
Versioned
Images, packages, models, prompts, datasets, and tools should have clear versions so builds are reproducible.
Traceable
Every artifact should have a source, import date, approval status, checksum, and usage trail.
Auditable
Teams should be able to show what was approved, when it was approved, who approved it, and where it was used.
Encrypted
Artifact storage and transport should be protected where enterprise policy requires confidentiality and integrity controls.
Layer 4
Offline Build Factory
The offline build factory creates new application images without direct internet access by pulling only from the internal hub.
Pull from Internal Hub
The build factory pulls only from approved internal sources, not directly from the public internet.
Dockerfile: Build Offline
Application Dockerfiles reference internal base images and local package sources so builds can run without external dependency pulls.
Local Base Images
Base images such as localhost:5000/sovai/python:3.11-slim come from the internal registry.
Install from Local Wheelhouse
Python dependencies are installed with --no-index and --find-links pointing to the internal wheelhouse.
Build Image Offline
The final application image is built without direct public internet access and can be pushed back to the internal registry.
Example offline build rule
FROM localhost:5000/sovai/python:3.11-slim
RUN pip install --no-index \
--find-links /artifact-hub/wheelhouse \
-r requirements.txtLayer 5
Air-Gapped Sovereign AI Runtime
The runtime layer is where RAG, local LLMs, ML services, controlled agents, and monitoring operate without public internet dependency.
Private RAG
Local Retrieval + Citations
RAG workloads retrieve approved internal content, generate grounded answers, and return citations instead of relying on uncontrolled external knowledge.
Local LLM
Run Inference Locally
Local model runtimes such as Ollama or internal model-serving platforms run inference inside the controlled environment.
ML Services
Local Models & Inference
Classification, extraction, scoring, ranking, and prediction services run with local models and approved dependencies.
Controlled Agents
Restricted Tools & Policies
Agents can use only approved tools, with restricted actions, blocked internet behavior, and audit records for tool calls.
Monitoring & Audit
Logs, Metrics, Alerts
Runtime services emit logs, metrics, traces, model usage records, citation records, and operational alerts.
No Runtime Internet
Zero Egress. Zero Exceptions.
The runtime environment does not depend on public internet access. External artifact import happens through controlled processes before runtime.
Phases
Implementation roadmap
The complete platform is built in phases. The first three kits are available as working references. The full platform kit is planned as the next evolution.
Offline Runtime Demo
Prove offline execution with local artifacts.
Local LLM RAG Demo
Add local LLM for grounded answers.
Internal Artifact Hub
Build internal repositories for artifacts and models.
Offline Build Factory
Build images and apps without internet.
Enterprise Governed Platform
Governed AI platform at enterprise scale.
Available implementation kits
Downloadable kits available today
The full sovereign AI platform kit is being built in phases. These three kits are available now and prove the foundation.
SovAI Air-Gap AI Starter
Offline runtime demo for local documents, approved tools, audit logs, and no runtime internet dependency.
View kitSovAI Air-Gap AI Starter v0.2 Ollama
Local LLM RAG demo using Ollama, grounded prompts, citations, and audit logging without external LLM APIs.
View kitSovAI Air-Gap Internal Artifact Hub
Internal artifact supply chain for local registries, Python wheelhouses, approvals, checksums, and offline builds.
View kitFull Sovereign AI for Air-Gapped Platforms Kit
The complete platform kit will combine offline runtime, local LLM RAG, internal artifact hub, offline build factory, governance controls, audit dashboards, deployment guides, and enterprise operating patterns.
Use cases
Where this architecture applies
This solution is designed for teams that need AI capability while keeping runtime systems controlled, auditable, and disconnected from public dependency sources.
Operating principles
Traceable, auditable, reproducible
The core promise of the architecture is not just offline execution. It is controlled delivery.
Traceable
Teams should be able to trace every deployed app back to the images, packages, models, prompts, tools, and approvals used to build it.
Auditable
Approvals, scans, runtime behavior, model calls, citations, tool usage, and deployment history should be available for review.
Reproducible
A build should be repeatable from the same internal artifacts without silently changing dependencies or pulling from the internet.
Contact
Need this pattern adapted for your environment?
Use SovAIHub to plan a practical implementation path for private RAG, local LLMs, internal artifact hubs, controlled agents, offline builds, and AI governance.
Start with the architecture, then choose the right kit.
Share your target environment, data restrictions, runtime constraints, model strategy, and governance needs to map the right implementation path.