The Rise of Private AI Clouds
Public, private cloud, hybrid and sovereign AI compared on the two axes that never move: compulsion and proof.
The choice between public AI, private AI cloud, hybrid and sovereign deployment is not decided by performance. It is decided by two questions of law and evidence: who can be lawfully compelled to hand over your data, and who can prove afterwards what your AI actually did with it.
Every other axis moves. Latency, unit cost, model quality and developer convenience are engineering problems, and engineering problems resolve within a procurement cycle. Jurisdiction and evidence do not move. They are properties of where the machine physically sits, who holds the keys, and what record survives after the vendor, the contract and the model version have all been replaced. Boards run this decision as a capability bake-off, then discover three years later that they bought a permanent structure on the strength of a temporary fact.
What are the four deployment models, and where does each genuinely win?
| Model | Who controls the weights and keys | Who can be compelled to disclose | Where it genuinely wins |
|---|---|---|---|
| Public AI | Provider holds weights and keys, and decides when the model changes. | The provider, under its corporate jurisdiction; notice to you is not guaranteed. | Most work: reversible tasks where the newest capability arrives with no refresh project to fund. |
| Private cloud AI | Customer-managed keys; weights, runtime and update calendar stay the provider's. | Still the provider: it can be ordered to produce the key, or to change the system that uses it. | Isolation and elasticity at once, inside an assurance package auditors already know how to read. |
| Hybrid | Split by workload; the split itself becomes the thing that has to be governed. | Depends which side the workload sat on that day, which is why one reconciled record matters. | Lets consequence rather than the org chart draw the line, keeping the expensive estate small. |
| Fully sovereign | Organisation holds weights, runtime, keys, logs and the version calendar. | You, in your own courts: the order is served on you rather than around you. | Workloads that must keep running, and stay provable, after the link, the contract or the supplier is gone. |
They are not a maturity ladder, and treating them as one is the first error. They are four answers to a single question: who holds the machine.
Public AI services win most work, and we should say that plainly. For drafting, code assistance, research, summarisation and anything with spiky demand, the economics are not close: frontier capability, no capital outlay, no depreciation, no hiring. Private AI cloud means dedicated tenancy inside a provider's estate, with isolation, residency and customer-managed keys. It is serious engineering, and it suits regulated firms that need enterprise integration and elasticity together. Hybrid is where most large organisations actually live, and it is an honest position rather than a fudge. Sovereign deployment means inference on hardware the organisation owns, in its own jurisdiction, capable of running with the network cable pulled out. It is the narrow and expensive answer for the class of workload where compulsion, continuity or evidence is the binding constraint.
Why is performance the wrong axis for this decision?
Because the gap you are measuring today closes before your contract renews. Capability differences between deployment options are real, and they are also the least durable thing in the comparison. An architecture chosen on a benchmark is an architecture chosen on a number that will be obsolete before the estate has finished migrating.
There is a second reason, and it matters more. For most regulated workloads the marginal accuracy point is not the binding constraint. Admissibility is. A decision that is correct but cannot be evidenced to a supervisor is, for practical purposes, a decision you did not make lawfully. Under the EU AI Act, GDPR Article 22 and DORA, the obligation is to demonstrate rather than to assert, and where ISO 42001 is adopted as a management standard the same posture follows. Enforcement attaches to what can be evidenced, not to what scored well on a benchmark.
Who can actually be compelled to hand over your data?
Compulsion follows control, not geography. If a third party can technically reach your data, that third party can be ordered to produce it, and the order may arrive under a law your contract has no power to override. The United States CLOUD Act is the well known example, addressing production of data held by providers subject to United States jurisdiction irrespective of where the bytes physically rest. Europe reached the same structural insight from the opposite direction in Schrems II, which turned on whether contractual safeguards can survive access by foreign public authorities.
None of this is misconduct by providers. They contest orders and they publish transparency reporting. That is precisely the problem: your protection becomes contingent on somebody else's litigation posture and somebody else's legislature. Customer-managed keys narrow the exposure, they do not close it. The question simply becomes who can be compelled to produce the key, and who can be compelled to change the system that uses it.
Who can prove what your AI did after the fact?
This is the question nobody prices, and it is the one that will hurt. Conventional logs are written after the event by the system under investigation, retained at its operator's discretion, in a schema chosen for engineering convenience rather than for a tribunal. Evidence produced by the party under scrutiny, about itself, on its own terms, is the weakest class of evidence there is.
The stronger design inverts the order of operations. Seal the record of a consequential action before it executes rather than after, sign it with a post-quantum signature, and hash-chain it so that any later alteration is detectable. The record can then be verified offline, by a regulator or a court, without the vendor's cooperation. That property survives an incident, an acquisition, a vendor failure or a hostile cross-examination. It is what we built the Open Audit Record to do.
What is the honest case against going sovereign?
It is strong, and pretending otherwise is how credibility is lost. At low or spiky utilisation, owned hardware is simply more expensive and the payback maths does not work. Sovereign estates need skills most organisations do not have and cannot quickly hire. An estate that is never refreshed becomes a museum. A badly run private estate is materially less secure than a well run public one, because physical control is not security. The deepest objection is that most of an organisation's data is not that sensitive, and treating everything as sovereign is an expensive way of avoiding the work of classification.
So how should a board actually decide?
Classify workloads by compulsion and evidence rather than by sensitivity label, and ask four questions.
- If a lawful order for this data landed on our provider tomorrow, would we be told, and could we contest it? If not, this is not a public workload, whatever its label says.
- If a supervisor asked us to prove what the system did on a specific date, could we produce evidence that does not depend on a vendor's cooperation?
- Is our constraint economic or legal? Economic constraints move with the market. Legal ones do not.
- Does our hybrid boundary have a named owner, a tested control and one reconciled record spanning both sides?
Most organisations should end up hybrid, and that is not a compromise, it is the correct answer. The discipline lies in deciding which side of the line each workload sits on, using jurisdiction and evidence rather than a benchmark score or a volume discount.
Frequently asked questions
Is a private AI cloud the same thing as sovereign AI?
No. A private AI cloud gives you isolation and residency inside somebody else's estate, under somebody else's corporate jurisdiction. Sovereign deployment means the hardware is owned by your organisation, sits in your jurisdiction, and runs without an external network. Both are legitimate. Only one changes who receives the legal order.
Does data residency put our data beyond foreign legal reach?
No. Residency governs where bytes rest, not who holds the power to compel their production. Where a provider's parent entity is subject to another jurisdiction, that jurisdiction may reach data the parent can technically access, wherever it is stored. Residency remains valuable for latency, for supervisory comfort and for some data protection duties. It is not a jurisdictional firewall.
Is sovereign deployment always more expensive than public AI?
No, but it often is, and the answer depends on utilisation. At low or unpredictable load, public services win on cost and it is not close. At sustained high utilisation the economics converge and can invert, because you stop renting depreciation. More commonly, sovereign is chosen when the constraint is legal rather than economic, and legal constraints do not respond to a discount.
Which workloads genuinely belong in public AI services?
Most of them. Anything where the data is not confidential, not personal, not privileged and not subject to a duty to evidence: drafting, research, code assistance, marketing, internal prototyping, high variance workloads. Moving that work to owned hardware is a cost with no corresponding control benefit. The sovereign argument concerns a specific class of workload, not the cloud being wrong.
Mickai is a British Sovereign Intelligence Operating System, built and live today, running offline on hardware the organisation owns, in its own jurisdiction, with 50 brains and studios that map to real departments. Its Open Audit Record seals every consequential action before it executes, signs it with post-quantum FIPS 204 ML-DSA-65 and hash-chains it so a regulator or a court can verify it offline, without us. Our defensibility rests on 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. Start at /sovereign-ai, examine the evidence layer at /oar, and if you want the workload classification done properly before you commit capital, that is what /ai-readiness is for.