Private AI Deployment: Governance for Controlled Environments
Written by Jakub Rusinowski · Last updated 2026-09-13 · Assessment logic is deterministic and runs in your browser
This section is practitioner guidance on deployment and governance mechanics, not legal advice. Regulatory classification turns on facts about intended purpose and real-world use that a questionnaire cannot establish — involve your counsel or DPO for decisions about your specific obligations.
Hosting mode does not change your regulatory classification, but it changes almost everything about which controls you can implement and what evidence you can produce. An air-gapped enclave makes network isolation trivial and model updates painful; a managed API makes updates trivial and log retention someone else's decision. This page walks the six hosting modes the assessment recognises and what each one gives you and costs you.
Six hosting modes, and what each one actually changes
The assessment asks which of these describes your deployment, because each makes a different set of controls cheap or impossible.
| Mode | What it makes easy | What it makes hard | Typical fit |
|---|---|---|---|
| Local — a workstation | Data path, isolation, cost | Availability, access control, backup, anything operational | Individuals, evaluation, small teams |
| On-premise — a server you own | Log control, version pinning, network placement, access control | Capacity planning, hardware lifecycle, on-call | Departments and companies with IT |
| Air-gapped — no network path | Network isolation, data residency, exfiltration risk | Model updates, patching, monitoring, anything requiring egress | Defence, some healthcare and legal work |
| Private cloud — dedicated tenancy | Elasticity with a defined boundary, operational maturity | Residency proof, subprocessor analysis | Regulated industries at scale |
| Public cloud — shared, your software | Elasticity, managed infrastructure | Data residency, tenancy isolation evidence | General enterprise |
| Managed API — someone else's model | Speed to deploy, no infrastructure | Version stability, log retention, data path, vendor dependency | Prototyping, non-sensitive workloads |
Note what is not in that table: risk classification. It is identical across all six rows for the same intended purpose, which is the point.
The air-gap trade, honestly
Air-gapping is the most over-recommended control in this space and the most under-examined. It is genuinely the right answer for some work, and it is expensive in ways that are not obvious until you are living with it.
What it actually buys you. Exfiltration through the network becomes a non-problem rather than a monitoring problem. Data residency becomes a statement about a room. A whole class of subprocessor and transfer analysis disappears. For work where the threat model includes a capable adversary with network access, this is worth a great deal.
What it costs. Model updates become a physical process with a change window. Security patching becomes the same. Monitoring that assumes egress — most of it — has to be rebuilt. Nobody can see the logs remotely, which means the oversight procedure you wrote needs a person in the building. And the thing nobody warns you about: the update friction means air-gapped deployments run older model versions than their operators believe, because each update is a project rather than a command.
The honest recommendation. LLMs air-gap unusually well compared to most software, because inference has no inherent need for egress. If your work genuinely requires it, it is more achievable here than elsewhere. If it does not, an on-premise deployment with a properly placed gateway gets you most of the data-path benefit at a fraction of the operational cost. The air-gapped deployment guide covers who actually needs it.
Controls that only exist in a controlled environment
Some of what the assessment recommends is simply unavailable on a managed API, and it is worth knowing which before you choose:
Deterministic version pinning. You can pin a model revision only if you hold the artefact. API version guarantees are contractual rather than physical, and deprecation schedules are the vendor's.
Log completeness on your terms. Article 26(6) asks deployers to keep the automatically generated logs. On your own gateway you decide what is captured and for how long. On an API you get the export feature that exists.
Inference-path data minimisation you can verify. You can read the code that constructs the prompt. On an API you can read the documentation about the code that constructs the prompt.
Corpus-level access control. If retrieval happens inside your boundary, the index can enforce the same access rules as the documents in it. If retrieval happens at a vendor, that enforcement is theirs to implement and yours to take on trust.
None of this argues that managed APIs are the wrong choice — for many workloads they plainly are not. It argues that hosting mode is a control-availability decision, and worth making before the compliance conversation rather than during it.
Sovereignty is a separate question from compliance
These two get conflated and they are different. Compliance asks whether you meet the obligations that apply to you. Sovereignty asks whose jurisdiction, whose supply chain and whose commercial decisions you depend on. A deployment can be fully compliant and entirely dependent on a single foreign vendor; it can be sovereign and non-compliant.
They interact in one direction that matters: sovereignty choices change the evidence you can produce, which changes how expensive compliance is to demonstrate. That is the real argument for a controlled environment, and it is a better argument than the exemption one because it is true.
The sovereign AI guide covers the four layers — data, models, compute and operational control — and where the practical spectrum sits.
Assess a private deployment
Automated assessment based on the information you provide. Not legal advice, certification or an audit.