Private, self-hosted & air-gapped AI

The problem this solves

You have a use case where the value is obvious and the data is the reason it has not happened. Patient records, privileged material, unpublished financials, case files, citizen data: the kind of material that makes "we send it to an API" a sentence nobody wants to say in front of the information governance board.

The usual response is to wait, or to build something deliberately crippled on synthetic data that never goes live. The alternative is to move the model to the data instead of the data to the model.

What we deploy

Open-weight models, on your infrastructure

Current open-weight models, deployed to your own hardware or to dedicated capacity in a UK region on a contract you hold. Served through a proper inference stack: batching, quantisation where it does not cost you accuracy, and capacity sized against measured demand rather than optimism.

An interface you own

Applications talk to an internal interface, not directly to a model. That single decision is what keeps you able to change model, change tier, or run different backends for different data classifications later, without rewriting anything above it.

Evaluation before belief

We build a test set from your real material, with reviewed correct answers, and measure the deployment against it. You get a number, not an impression. That number is also what makes every subsequent change (new model, new configuration) a decision with evidence behind it.

The evidence pack

A written statement of where processing occurs, what is retained and for how long, who can access it, and what the failure and exit paths are. This is the artefact that unblocks procurement and assurance, and it is genuinely half the value of the engagement.

Air-gapped and on-premise accelerated compute

For defence and for segregated government networks the deployment tier is decided before anybody discusses models: there is no route to the internet, so there is no route to a cloud region either, and cloud residency stops being the relevant question. We have delivered air-gapped platforms on NVIDIA DGX B300 for a central government department and on NVIDIA HGX B300 for a defence organisation, both running NVIDIA AI Enterprise.

The engineering work in an air-gapped deployment is not the inference. It is removing every assumption of connectivity, and there are more of those than anyone expects:

• Container registry mirrored inside the boundary, images pinned by digest rather than tag
• Operating system and language package repositories mirrored and version-pinned
• GPU driver, CUDA and firmware bundles staged as versioned artefacts with a tested rollback
• Licensing served locally, so entitlement never needs a route out
• Model weights imported as hashed artefacts, in formats that do not execute code on load
• Vulnerability and CVE feeds imported on a defined cadence, like everything else

Every one of those becomes a standing sustainment obligation, so each gets a named owner and an update cadence before go-live rather than after. That is the part that decides whether the platform is still safe to run in year three, and it is the conversation we would rather have during procurement.

Hardened to a named baseline

Hosts, container runtime and orchestration are built from DISA STIG baselines reconciled against CIS Benchmarks Level 2, in code, and scanned before handover. The runtime and orchestration layer is the one most AI platform deployments skip, and a carefully hardened host running a permissive container runtime is not a hardened system.

Platforms are mapped onto the NCSC Cyber Assessment Framework and the NCSC Guidelines for Secure AI System Development, and traced to NIST SP 800-53 and the NIST AI Risk Management Framework where your supply chain expects that vocabulary. There is more detail, including what "aligned to" honestly does and does not mean, on the security standards page.

Choosing the tier honestly

We use three tiers with clients, and we will recommend the cheapest one your data classification permits:

• Air-gapped and self-hosted: your hardware, your network, and in the strictest case no egress path at all. Nothing crosses the perimeter. The strongest position and the highest operational burden.
• Private UK deployment: dedicated instances in a UK region on your contract. Where most regulated production workloads belong.
• Contracted hosted: a frontier model under enterprise terms with zero retention. Correct for low-classification work, and we will say so when it is.

A consultancy whose recommendation is always the most expensive tier is not advising you. Most engagements end up with a mix, routed by classification.

The operational question you should ask yourself first

Private deployment fails most often for a non-technical reason: nobody internally owns the infrastructure after handover. Before committing, be honest about whether you have, or will hire, someone who can own capacity, updates and incidents.

If the answer is no, say so early. There are good intermediate options, including managed private capacity, and choosing one deliberately is far better than discovering the gap six months after go-live.

Handover is the deliverable

Everything lands in your repository: infrastructure as code, deployment pipeline, evaluation harness, runbook, architecture decision records. We run handover sessions with your engineers and expect to be unnecessary afterwards.

If you want us on a retainer for escalation and periodic model review, that is available. It is not required for the thing to keep working, which is the distinction that matters.