The Hidden Cost of Cloud AI

Cloud AI is usually priced correctly and costed wrongly. The invoice measures consumption, the only line a board can see, sign and argue about; the other six lines of total cost of ownership are incurred today and arrive later as debt rather than expense. This is not an argument against cloud. It is an argument that most organisations compare a number they can see against a number they have never calculated, then call the result a decision.

Why is the invoice the least interesting number in the business case?

The invoice is honest: what you consumed, at a rate you agreed, auditable to the penny. The problem is not accuracy, it is scope. An invoice measures the cost of running a system. Total cost of ownership measures the cost of owning an outcome: what you pay to change your mind, what you pay to prove what happened, and what you pay when the answer comes too late.

A complete AI cost model has seven lines. One of them is metered.

• Consumption: inference, storage, egress. Visible, metered, negotiable.
• Switching: moving the workload elsewhere, denominated in months and rework, not pounds.
• Exposure: value at risk when your prompts, retrieval corpus and outputs sit in someone else's fault domain.
• Compliance labour: proving a third party's system is fit, repeated at every audit and every model version.
• Latency: decisions that degrade, or never happen, because the round trip is too slow or the link is down.
• Dependency: the capability you no longer keep in house, and the negotiating position that follows.
• Evidence: what it costs when a regulator or a court asks what happened, and the answer must be requested rather than produced.

Six of those seven are charged to headcount, risk registers, legal budgets and future negotiations. None appear next to the price per million tokens. That asymmetry, not the pricing, makes cloud AI business cases unreliable.

What does lock-in actually cost, and when does the bill arrive?

Lock-in is not a vendor conspiracy. It is the natural residue of any system that works well enough to be built upon. The cost is incurred not at signature but at the moment you want to leave, and its size tracks how deeply the system has been coupled to everything around it.

The useful distinction is between the model and the scaffold. Models are increasingly portable. The scaffold is not: the prompt estate, the evaluation harness and its accumulated evidence, the retrieval indexes, the guardrail configuration, the runbooks your team learned by doing. Organisations that find switching expensive rarely discovered it about the model. They discovered it about everything built around it while nobody costed that work.

Why do data exposure and compliance behave like debt rather than expense?

Exposure is not the same thing as breach. Assume, generously, that the provider's security is better than yours, as for many organisations it genuinely is. Exposure still has a cost, because some obligations do not transfer. A contract can allocate liability. It cannot allocate accountability. Under the GDPR the controller remains the controller regardless of how capable the processor is, and the same asymmetry runs through NIS2 for supply chain risk and DORA for oversight of critical ICT third parties, concentration risk and documented exit strategies.

Compliance labour is the cost of discharging that accountability over someone else's estate, and it recurs. Every sub-processor, region or model version change potentially resets the evidence you had assembled. Because it is paid in your people's time it rarely enters the comparison that chose the platform. It behaves like debt: defer it, and the interest accrues in audit cycles.

What is the price of an answer you cannot give?

Evidence is the largest underpriced line, and it reads as zero until the day it is the only number that matters. If the record of a consequential AI action lives in a provider's logging system, you can usually retrieve it. But you retrieve it on their retention schedule, in their format, and it records only what their system observed after the fact. That is a materially weaker artefact than a record you sealed yourself, before the action executed, in a form a third party can verify without your cooperation or the provider's. Under GDPR Article 22 the rights of a person subject to an automated decision attach to your organisation, not to your supplier's observability stack.

When is cloud simply the right answer?

Often, and the argument is weaker if it pretends otherwise. Cloud is correct for bursty demand, where paying for idle capacity is waste; for public or low consequence data; where frontier capability binds; and for experimentation. It is also correct where the realistic in-house alternative is not more control but worse security and worse operational discipline. The honest counter-claim is narrower: there is a class of workload where the consequence of an action is regulated, irreversible or adjudicable, and for that class the six invisible lines dominate the visible one. Those are the workloads that end up in front of a regulator, a court or a select committee.

How should a board actually run this comparison?

• Classify workloads by consequence, not sensitivity. Sensitivity tells you what leaks; consequence tells you what you must defend.
• Price the exit before the entry. If nobody can state the switching cost in months, the contract is signed blind.
• Ask who holds the evidence, in what form, and whether it can be verified without the vendor.
• Put assurance labour on the comparison as a line item with a named owner and an annual figure.
• Re-run the comparison at renewal, not at incident. Renewal is the only moment you have leverage.

A comparison built this way sometimes chooses cloud. That is the point. A framework that always returns the same answer is not a framework, it is a preference wearing a spreadsheet.

Frequently asked questions

Is cloud AI more expensive than running AI on owned hardware?

Not necessarily, and often not. On consumption alone cloud frequently wins, especially for variable demand where owned capacity would sit idle. The comparison changes when switching cost, assurance labour, exposure and evidentiary weakness enter the same model, and it changes most where actions are regulated or irreversible.

Can we not just put the compliance obligations in the contract?

No, not fully. Contracts allocate liability between commercial parties, which is worth doing well. They do not move accountability to the regulator, which under the GDPR stays with the controller and under DORA stays with the regulated entity. You can be fully indemnified and still be the organisation that must answer the question.

What is the single most underpriced line in a cloud AI business case?

Evidence. Most organisations can eventually reconstruct what an AI system did; very few can produce a record sealed before the action executed and verifiable by an outsider without trusting the organisation or the vendor. That cost is zero until it is the only cost that matters.

Does this mean we should move existing AI workloads off cloud?

No. Migration has its own substantial cost and should be justified per workload rather than as policy. Classify the estate by consequence, address the small number of workloads where the invisible lines dominate, and leave the rest. For those, cloud may remain the cheapest correct answer for years.

Mickai is a British Sovereign Intelligence Operating System, built and live, running offline on hardware the organisation owns, in its own jurisdiction. 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. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. Read /sovereign-ai and /oar, and /ai-readiness to establish which of your workloads belong in the sovereign class.