Local LLMs in an air-gapped network: AI for your most sensitive data
The documents that would profit most from AI are exactly the ones nobody may upload anywhere: contracts, HR files, patient records, source code, engineering drawings. With an open-weight model inside an isolated network you get the benefits without a single byte leaving the building. Here is how I set it up, how models get in without internet, how to test them offline, and what to realistically expect.
10 min read
1. Why air-gapped AI, and for whom
Most companies start with a cloud AI service and quickly hit a wall: legal won't allow contracts in it, HR can't use it for personnel files, the hospital can't touch patient data, and engineering doesn't want proprietary code in someone else's logs. In my article on local LLMs for sensitive data I described a private setup with a firewall that blocks public AI APIs. An air gap goes one step further: there is no route to the internet at all, so even a misconfigured tool, a curious plugin or a compromised dependency has nowhere to send data. That is the level regulated industries, the public sector, defence suppliers and anyone with serious trade secrets often need, and it is entirely achievable with today's open-weight models.
2. The architecture in one picture
The setup has two halves. Outside, in a connected zone, someone picks an open-weight model, checks its licence, downloads it and records its fingerprints. Inside the enclave, everything else happens: an offline model registry holds verified versions, GPU nodes serve the approved model, an internal AI gateway handles sign-in, quotas, PII masking and the audit log, and a small search index over your internal documents gives the model the context it needs to answer about your business. Users never talk to the model directly, only to the gateway, which is where your rules live. And there is exactly one way in for new models and no way out for anything.
3. Getting a model in without internet
Pick the model by licence and fit, not by leaderboard hype, and pin it to an exact commit, because 'latest' doesn't exist in an air gap. Download the weights in safetensors format: Hugging Face warns that the older pickle format can execute arbitrary code when loaded, and safetensors was built to avoid exactly that. Then write a SHA-256 checksum for every file, sign the manifest, and move the folder across the same one-way path you use for software, as described in my article on air-gapped systems. Inside, a quarantine host verifies signature and checksums again before the model lands in the offline registry, which can be as simple as versioned object storage. Never enable options that load custom code shipped with a model; inside an enclave you want weights, tokenizer and config, nothing executable.
# Connected zone: fetch an open-weight model pinned to one commit, no pickle files
set -euo pipefail
MODEL=Qwen/Qwen2.5-14B-Instruct # example, pick yours by licence and fit
REV=<commit-sha-from-the-model-page>
hf download "$MODEL" --revision "$REV" --exclude "*.bin" --local-dir models/qwen2.5-14b-instruct
cd models
find qwen2.5-14b-instruct -type f -exec sha256sum {} + > qwen2.5-14b-instruct.SHA256SUMS
cosign sign-blob --key cosign.key --bundle qwen2.5-14b-instruct.bundle qwen2.5-14b-instruct.SHA256SUMSTip from practice
Keep a one-line model card next to every version in the registry: source, commit, licence, checksum, who approved it and when.
4. Serving it: vLLM or Ollama on your own GPUs
For a department or a whole company I use vLLM: it is built for throughput, batches many users efficiently and exposes an OpenAI-compatible API, so internal tools can talk to it without special code. For a small team or a single powerful workstation, Ollama is simpler and can import local GGUF or safetensors weights through a Modelfile. Either way, serve from a local path and switch off every attempt to reach the internet; for anything built on the Hugging Face libraries the environment variable HF_HUB_OFFLINE makes sure no HTTP calls to the Hub are made at all. How much hardware you need depends on model size and precision; the GPU calculator in my article on local LLMs for sensitive data gives you a quick, honest estimate before you order anything.
# Enclave: serve the approved model from the offline registry
export HF_HUB_OFFLINE=1 # never try to reach the Hub
vllm serve /models/qwen2.5-14b-instruct \
--served-model-name internal-14b \
--api-key "$INTERNAL_API_KEY" \
--max-model-len 16384
# Small team alternative: Ollama with a local Modelfile
# FROM /models/qwen2.5-14b-instruct
# ollama create internal-14b -f Modelfile5. The gateway: sign-in, PII masking, audit
The gateway is what turns a model into a service you can defend in front of a data protection officer. People sign in with the identity provider you already run inside, such as Active Directory or Keycloak, so access follows existing roles. Before a prompt reaches the model, personal data that the use case doesn't need is detected and masked; Microsoft Presidio is a solid open-source starting point for that and runs fully offline. Every request is written to an audit log inside the enclave: who asked, which documents were used, which model version answered, with a retention period you agreed on. Quotas per team keep one heavy user from slowing everyone else down, and the same gateway is where you later add new models without changing a single client.
Tip from practice
Mask before logging, too. An audit log full of unmasked personal data quietly becomes your most sensitive database.
Interactive
Which GPU does your model need?
Pick a model size and precision. Weights take parameters × bytes per parameter; about 20% on top covers the KV cache for normal context lengths.
Model size (billion parameters)
Precision
≈ 19 GB
GPU memory needed
1×
fits on 24 GB (RTX 4090)
- 1× 24 GB (RTX 4090)
- 1× 32 GB (RTX 5090)
- 1× 48 GB (L40S)
- 1× 80 GB (H100)
- 1× 96 GB (RTX PRO 6000 Blackwell)
- 1× 141 GB (H200)
Rule of thumb for planning, not a benchmark. Long contexts and many parallel users need more KV cache; 4-bit costs a little quality.
All calculators and checklists6. Answers from your own documents, with permissions
A model on its own knows nothing about your contracts or your machines. Retrieval-augmented generation fixes that: documents are split into passages, turned into vectors by a local embedding model, stored in PostgreSQL with the pgvector extension, and the most relevant passages are handed to the model together with the question. The part people forget is permissions. Store who may see each passage next to the vector and filter on it in the query, so the assistant never quotes an HR file to someone who couldn't open it. Show the sources with every answer; it builds trust and lets people check. And re-index automatically when documents change, otherwise the assistant confidently cites last year's policy.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
id bigserial PRIMARY KEY,
doc_id text NOT NULL,
allowed_groups text[] NOT NULL, -- who may see this passage
content text NOT NULL,
embedding vector(1024) NOT NULL -- size of your local embedding model
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);
-- Only search what the asking user is allowed to read
SELECT doc_id, content
FROM chunks
WHERE allowed_groups && $1::text[]
ORDER BY embedding <=> $2
LIMIT 8;7. Test offline before every update
Inside an air gap you can't glance at public benchmarks and hope they apply to you, and you shouldn't anyway. Build a golden set of 50 to 200 real questions from your own domain with the answers your experts expect, plus a handful of tricky prompts: requests for data the user shouldn't get, attempts to override the instructions, questions with no good answer. The OWASP Top 10 for LLM applications is a useful checklist for those, especially prompt injection and sensitive information disclosure. Run the current and the candidate model side by side, compare accuracy, refusals and response time, and only promote the new version after a named person signs off. Keep the previous version in the registry so rollback is one configuration change. The NIST AI Risk Management Framework gives you a vocabulary to document all of this for auditors.
Tip from practice
Let the people who will use the assistant write half of the golden questions. They know which answers would embarrass you in a real meeting.
8. What it unlocks, and the honest limits
Once it runs, teams use it for things they could never send to a cloud service: reviewing contracts against your own templates, answering HR policy questions, drafting clinical or technical documentation, searching decades of engineering reports, and helping developers on proprietary code. The limits are real too. Open-weight models still trail the best frontier models on the hardest reasoning tasks, they know nothing that happened after their training, and updates are slower by design. You need GPU capacity planning and somebody who owns the platform. In practice, a well-chosen open model with good retrieval over your own documents answers the everyday questions that matter most, and it does so on hardware you control. The same principle scales down: my small ESP32 robot runs speech recognition and a language model locally and works with no network at all.
9. Rolling it out in three phases
I roll these platforms out in three phases. First a pilot with one department and one document collection, for example the legal team and its contract templates, with the golden question set agreed upfront and a clear go or no-go after a few weeks. Second, more collections and more teams on the same gateway, with permissions mapped from the existing groups instead of inventing new ones. Third, operations: a monthly model review, a fixed update window, capacity checks on the GPUs and a short report on usage and hours saved. Starting small keeps the hardware order honest, gives your data protection officer something concrete to review, and produces the first internal success story that makes the next department ask for access.
Takeaway
With an open-weight model behind your own gateway, your most sensitive data finally gets AI help, and none of it ever leaves the building.
Real projects behind this
Try it yourself
Sources and official guides
- Hugging Face: environment variables (HF_HUB_OFFLINE)
- Hugging Face: pickle scanning and security
- Hugging Face: safetensors
- Hugging Face CLI: hf download
- vLLM documentation
- Ollama: importing a model
- pgvector
- Microsoft Presidio: PII detection and anonymization
- OWASP Top 10 for LLM applications
- NIST AI Risk Management Framework
- Sigstore cosign: verify-blob
- NIST SP 800-53 Rev. 5: Security and Privacy Controls
More articles
- 3,025 pull requests in ten months: an AI-assisted delivery process, from the inside
- The EU AI Act for mid-sized companies: what applies to you, and when
- FinOps for AI spend: tokens, caching, routing and budgets that hold
- Making a restaurant network visible in AI answers: a GEO project, step by step
- How this site is built: static where it can be, streaming where it must
- Kubernetes cost on EKS and GKE: the same playbook, different levers
- A landing zone for mid-sized companies, in Terraform or Bicep: the parts that matter
- The legacy migration playbook: waves, parallel runs, and identical row counts and checksums
- MCP security in depth: how to let AI assistants into your product without opening the doors
- Monitoring on business outcomes: green dashboards, empty checkout
- Phone AI agents: the architecture, and the pitfalls nobody shows in the demo
- Restore tests: a backup you have never restored is only a hope
- Streaming AI answers on Azure Static Web Apps: the one header that buffered everything
- Building an AI assistant for WhatsApp, end to end: what it takes beyond the demo
- Air-gapped systems: running critical software with no internet
- Production AI on AWS: Amazon Bedrock and AgentCore in a private setup
- Production AI on Microsoft Foundry: a private reference setup for agents
- /goal, /loop or routines: stop babysitting your coding agent
- Claude's new plans: Max, Ultra and what they mean for teams
- OpenAI Codex at the end of 2026: goal mode, dots and how to lock it down
- GitHub Copilot, Claude Code or Codex? How I'd choose for a company
- GEO basics: how to show up in AI answers
- Production AI on Google Cloud: from Vertex AI to Gemini Enterprise Agent Platform
- I want to run a local LLM: which server should I buy?
- MiniMax M3: an open frontier model you can run yourself?
- Prompt research at scale with an open model
- SEO and GEO together: a practical audit in 6 steps
- Right-size Kubernetes: the playbook that took a cluster from 7 to 4 nodes
- Private AI for sensitive data: a local LLM setup that passes the security review
- From AI prototype to production: the eight layers I add, in order
