Air-gapped sovereign AI for a UK central government department

A delivered engagement. The client is not named and operational detail is left out. We publish the architecture and the assurance pattern: the part that transfers to anyone facing the same constraint.

The constraint

The department had clear use cases, and a clear reason none had reached production. The material could not go to a commercial API, and its users’ network has no route to the internet.

That rules out most of the market. The products are not poor; they assume connectivity: a licence server, an image registry, a telemetry endpoint, a vendor pushing model updates.

So the brief was never "which AI tool should we buy". It was "build a platform that runs entirely inside the boundary, that our own people can operate, and that will stand up in a GovAssure assessment".

Why on-premise, and why this hardware

The network position decided on-premise. On a segregated network with no egress, cloud data residency stops being the question: there is no route to the region, whichever country it is in.

Sizing followed concurrency and context length as well as parameter count, the calculation most procurements get backwards. Per-GPU memory on Blackwell Ultra lets large open-weight models serve long context without splitting across nodes, where most of the complexity and fragility live.

DGX B300 fitted because it arrives as a validated system with a defined firmware, driver and software baseline. Air-gapped, a reproducible known-good baseline beats the last few percent of price-performance: you cannot download your way out of a version mismatch.

Building for no egress

Air-gapped engineering means removing every assumption of connectivity. There are far more than anyone expects.

• Container registry mirrored inside the boundary, images pinned by digest, not tag
• Operating system and language package repositories mirrored and version-pinned
• GPU driver, CUDA and firmware staged as versioned artefacts with a tested rollback
• NVIDIA AI Enterprise entitlement served locally, so licensing never needs a route out
• Model weights imported as hashed artefacts through the approved transfer path
• Vulnerability and CVE feeds imported on a defined cadence, like any other artefact

Hardening, in code

Hosts were built from a DISA STIG baseline, reconciled against CIS Benchmarks Level 2 and written as code. The build is reproducible, not a machine somebody once configured well.

The container runtime and Kubernetes layer, routinely skipped on AI platforms, were hardened against their own STIGs and benchmarks. A hardened host running a permissive runtime is not a hardened system.

MIG partitioning gives separate consumers hardware-level isolation, not a scheduler’s promise not to interfere.

A short list of deviations was unavoidable: some Level 2 controls conflict with GPU driver and scheduler operation. Each carries the finding ID, the technical reason and the compensating control. Assessors want that document, and nobody produces it.

Assurance built alongside the platform

The department is assessed against the NCSC Cyber Assessment Framework under GovAssure, so the platform was mapped onto the CAF during the build, while the designers were there to explain it.

The NCSC Guidelines for Secure AI System Development were applied the same way, across their four lifecycle stages. The CAF was not written with model artefacts in mind; the AI guidelines were. Together they cover what neither does alone.

Controls were traced in parallel to NIST SP 800-53 Rev 5 families and the NIST AI Risk Management Framework. That keeps assurance conversations with non-UK partners short.