What determines the cost of sovereign AI? A TCO framework with no sticker price
A total cost of ownership framework for sovereign AI that models the drivers of the bill instead of quoting a single price.
Sovereign AI cost is set by drivers you can model: hardware, utilisation, operations, model maintenance and risk avoided, because owned capacity reshapes the bill.
The question matters more in 2026 because regulation now decides where data is allowed to go. DORA has been in force since January 2025, NIS2 covers essential and important entities, and the US CLOUD Act can compel a US-based provider to hand over data regardless of where its servers sit. Meanwhile the EU AI Act high-risk Annex III obligations, once due 2 August 2026, were deferred by the Digital Omnibus to 2 December 2027, with embedded Annex I high-risk moving to 2 August 2028 and Article 50 transparency largely unchanged. Buyers who once asked for a token price now ask what the whole thing costs to own and run under rules like these.
Why is there no single price for sovereign AI?
There is no single price because cost depends on how much capacity you own, how hard you use it and which risks you remove.
A sticker price would answer a different question. Sovereign AI is capacity you own and operate, so its cost behaves like an owned asset rather than a metered service. Two buyers running the same workload can see very different bills depending on how much hardware they buy, how fully they use it, and how much breach and regulatory risk they take off the table. That is why we model drivers rather than quote a number: the number only exists once your workload, your utilisation and your risk are on the page.
What are the real cost drivers, and how do they scale?
Five drivers determine the bill: hardware capacity, utilisation, operations, model maintenance and risk avoided, and each scales differently from a metered cloud line.
These five drivers are the whole of the model. The first looks like a cloud line item, but the rest behave differently, and one of them, avoided risk, never appears on a cloud invoice at all.
| Cost driver | What it includes | How it scales | Cloud equivalent |
|---|---|---|---|
| Hardware and capacity | Owned compute, memory, storage, power and space to run offline | Steps up in blocks as you add nodes; flat between upgrades | Metered instance and token charges billed per request |
| Utilisation | Share of owned capacity actually doing useful work | Inversely: higher utilisation lowers effective cost per task | No equivalent lever; idle time is simply unbilled |
| Operations | Running, patching, monitoring and securing the substrate | Roughly with fleet size, not with query volume | Bundled into a provider margin you cannot see or tune |
| Model maintenance | Evaluating, updating and retiring the models you run | With the number of capabilities in use | Vendor managed; model versions change on the provider schedule |
| Risk avoided | Penalties, remediation and downtime a sealed design prevents | With data sensitivity and regulatory exposure | Shared responsibility gap the buyer ultimately owns |
How does owned capacity change the shape of the bill over five years?
Owned capacity front loads cost into fixed hardware, then flattens: marginal work approaches the cost of electricity, while metered cloud keeps billing linearly with usage.
A metered service bills roughly in proportion to use: double the requests and you roughly double the bill. Owned capacity behaves differently. You pay for the hardware block up front, then each additional unit of work costs little more than the power to run it, until you reach the next capacity step. Over a three to five year horizon this changes the shape of the bill, not just its size: the metered line keeps climbing with usage, while the owned line steps up occasionally and stays flat in between. Which curve wins depends entirely on how much work you push through the capacity you have bought.
“Sovereign AI is not priced, it is modelled: over a multi-year horizon, owned capacity changes the shape of the bill rather than the size of a single invoice.”
How does utilisation change the cost per unit of work?
Utilisation is the strongest lever: owned hardware serving twice the work halves the effective cost per task, whereas metered billing never rewards higher usage.
Idle owned hardware is the most expensive hardware you can buy. Because the capital cost is fixed, the effective cost per task falls as you route more useful work through the same nodes. Running Mickai across many functions rather than one raises utilisation without raising the hardware bill: the substrate hosts 50 brains, 25 domain and 25 operational, so a single owned fleet can serve legal, finance and operations from the same capacity. Cross-model consensus and a shared audit chain mean work spreads across the estate rather than sitting in silos, which is exactly what pushes the effective cost per task down.
What is the cost of a breach or regulatory finding you avoid?
Avoided cost is real cost: a breach, a DORA failure or a regulatory finding carries penalties and remediation that a sealed, offline architecture prevents.
Public cloud AI services such as ChatGPT, Copilot and Gemini are the right choice for open, non-sensitive work where speed to value matters most. For the most sensitive data, regulated buyers frequently cannot send it off premises at all, and a breach or a regulatory finding carries penalties, remediation and downtime that dwarf any token saving. Mickai, a Sovereign Intelligence Operating System, is built and live to remove that exposure by design: it runs offline on operator-owned hardware behind a zero-egress inbound perimeter, with hardware-attested identity bound to the audit chain and every action written to a post-quantum signed audit ledger. That ledger is sealed with FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA); FIPS 203 (ML-KEM) handles key encapsulation and never signs. The substrate is covered by 104 filed UK patent applications and 2,340 claims, owned by Mickai LTD (Companies House 17166618), filed and patent pending. The cost you avoid here is real, even though it never shows up as a line on a cloud invoice.
How should we model this for our own numbers?
Model it yourself: size the workload, cost owned capacity against utilisation, add operations and maintenance, subtract avoided risk, then compare against metered cloud.
You can run this model yourself before any conversation with us. Work through the steps below with your own figures, then compare the owned total against the same workload metered on cloud over the horizon you care about.
- 1. Size the annual workload: the tasks, tokens or documents your teams actually process.
- 2. Set a target utilisation for owned capacity, then hold it honest across the year.
- 3. Cost the hardware block that meets peak demand, spread across its useful life.
- 4. Add operations: the people and tooling to run, patch and secure the substrate.
- 5. Add model maintenance: evaluating, updating and retiring the capabilities you keep.
- 6. Estimate risk avoided: the breach, downtime or regulatory finding a sealed design removes.
- 7. Compare the owned total against the same workload metered on cloud over three to five years.
Frequently asked questions
Does Mickai publish prices?
Prices are not published. Cost depends on your workload, the capacity you own and the risk you remove, so we model it with you against your own numbers rather than quoting a figure that would not fit your estate.
Is owning capacity always cheaper than metered cloud?
No. Owned capacity wins when utilisation is high and the horizon is long enough to spread the hardware block across a lot of work. For thin, spiky or short-lived workloads, metered cloud can be the more efficient choice. The framework above is designed to tell you which case you are in.
How do I compare sovereign AI to ChatGPT or Copilot on cost?
Compare like for like on the work each can lawfully do. Public services are excellent and fast for open, non-sensitive tasks, so cost them there. For regulated or sensitive data that cannot leave your control, the honest comparison is against the breach and compliance risk you remove, not against a per-token rate.
What regulations change the cost calculation in 2026?
DORA has been in force since January 2025 and NIS2 covers essential and important entities, both of which raise the cost of getting data handling wrong. The US CLOUD Act can reach a US-based provider wherever its servers sit. The EU AI Act high-risk Annex III duties were deferred by the Digital Omnibus to 2 December 2027, so the timeline eased while the direction did not.
Can I model this without sharing our data with you?
Yes. Every input in the worksheet is your own operational figure, so you can build the full comparison offline and in private. Mickai itself runs the same way, offline on your hardware with every action cryptographically sealed, which is the point of modelling cost this way in the first place.