Price AI Cloud Lock-In Before Your Workloads Become Expensive to Move

The Sovereign Cloud

10 October 2026 | By Ashley Marshall

The cheapest AI platform in a pilot can become the most expensive one to leave. UK buyers need to price switching before usage, data and workflow dependencies compound.

Cloud lock-in is a price you can estimate

Cloud lock-in is often discussed as if it were a binary state: either a system is portable or it is trapped. That framing is too crude for an AI buying decision. Every useful production system has dependencies. The practical question is whether the value gained from those dependencies is greater than the cost and risk of changing them later.

Updated UK government guidance on managing technical lock-in in the cloud makes this point directly. It says technical lock-in cannot be avoided completely and distinguishes it from commercial lock-in. Commercial lock-in comes from contracts and terms. Technical lock-in comes from architecture, unavailable equivalents and a lack of skills. AI workloads can accumulate both at once: a long commitment for discounted compute, proprietary model interfaces, vendor-specific retrieval services, evaluation tooling and staff who only know one platform.

That does not make managed AI services a bad choice. A hosted model, managed vector store or cloud security service may shorten delivery time and remove operational work. The mistake is accepting the dependency without pricing it. A switching-cost estimate should include data export, egress charges, replacement engineering, model and prompt revalidation, security review, staff retraining, contract overlap and the business impact of a slower or interrupted service.

What this means in practice is simple. Put a monetary range and a time range beside every material dependency. If moving a customer support assistant would require eight weeks of engineering, two rounds of compliance testing and a month of parallel supplier fees, record that while the design is still changeable. The estimate will be imperfect, but an imperfect measured exposure is more useful than a portability promise nobody has tested.

AI workloads create more switching layers than ordinary software

A conventional application might depend on compute, storage, networking and a database. An AI service adds layers that are easy to overlook: model behaviour, token economics, safety filters, embeddings, retrieval indexes, prompt templates, evaluation datasets, observability traces and human review procedures. Moving the application code does not prove that the service has moved successfully.

Consider an internal knowledge assistant. One provider may supply the model, document parsing, embeddings, access control integration and monitoring. A rival can offer similar product names, yet produce different retrieval results, refusal behaviour, latency and costs. Even where APIs look compatible, the business must rerun evaluation cases and verify that permissions still prevent inappropriate disclosure. The switching unit is therefore not a container or database. It is an end-to-end business outcome with evidence.

This is why a useful register separates at least five exposure types. First is data exposure: formats, export speed and egress cost. Second is model exposure: behaviour that prompts and workflows assume. Third is platform exposure: proprietary orchestration, identity and monitoring. Fourth is commercial exposure: minimum spend, discounts and notice periods. Fifth is capability exposure: whether the team has enough knowledge to operate an alternative.

The common misconception is that open source automatically removes lock-in. Open models and open formats can improve your options, but the deployment may still depend on a specific accelerator, serving framework, fine-tuning pipeline or specialist supplier. Conversely, a proprietary managed service can be a sensible choice if it creates enough value and the exit path is understood. Openness is an input to the assessment, not a substitute for one.

For leaders, the practical test is whether a second team could reconstruct the service from exported assets and documented acceptance criteria. If the answer depends on undocumented prompts, one employee's platform knowledge or evaluation data stored inside the supplier account, the switching cost is already rising.

Competition policy has turned portability into a board issue

This is no longer only a concern for architects. In a September 2026 speech on the UK's digital markets regime, the Competition and Markets Authority said that multi-cloud issues and egress fees affect billions of pounds of private and public sector expenditure. It also described cloud and AI-enabled business software as areas where competition and sovereignty intersect because concentration and lock-in create strategic dependencies.

The CMA's update said Amazon and Microsoft had made concrete changes to improve interoperability and multi-cloud through a voluntary process. It also noted that cloud licensing remained part of a wider investigation into Microsoft's business software ecosystem. The signal for buyers is clear: regulators may improve market conditions, but each organisation still needs evidence about its own ability to switch.

A related CMA policy paper on procurement, published on 8 September 2026, covers cloud services alongside growth, innovation and economic security. That combination matters. Procurement teams should not treat an exit clause as legal boilerplate while technology teams quietly create dependencies that make the clause unusable.

What this means in practice is that the board should see switching exposure in the same way it sees supplier concentration or business continuity. The report does not need a technical inventory of every API. It needs the critical workload, current supplier, estimated time to switch, estimated cost range, largest dependency, last test date and accountable owner. A red rating should mean that the cost is unknown or the exit cannot be demonstrated, not merely that the organisation uses a large cloud provider.

The counterargument is that regulators will eventually force portability and reduce fees. That may help, but a future market remedy will not rewrite your prompts, rebuild your indexes, reproduce model behaviour or restore skills you allowed to disappear. Regulatory action can widen the door. Your organisation still has to be capable of walking through it.

Use a switching-cost test before approving scale

A switching-cost test should be a short, repeatable gate, not a six-month multi-cloud programme. Start with a defined workload and an exit trigger. Triggers might include a 30 per cent price increase, withdrawal of a model, failure to meet a service level, an unacceptable data-processing change or a strategic decision to place sensitive work in a UK-controlled environment.

Next, identify the minimum viable alternative. Do not pretend the organisation could move every feature without compromise. Choose the alternative supplier, open model or local deployment that could maintain the most important business outcome. Then estimate the work across six headings: export, rebuild, revalidate, secure, retrain and run in parallel. Give each heading a low and high cost, an elapsed time and an owner.

The UK government guidance recommends monitoring a cloud portfolio for situations where switching costs grow disproportionately. It also says hosting business cases should include estimated costs after discounts lapse, plus the time and cost needed to exit. For some critical components, it points to periodic rebuilding or testing in another provider's environment. Applied to AI, that means rerunning a representative evaluation pack against the alternative rather than merely proving that an API call works.

A useful quarterly test could take one anonymised workflow, export its prompts and configuration, rebuild its retrieval index using an alternative service, run 50 to 100 agreed evaluation cases and compare quality, latency and unit cost. The goal is not production parity. It is to discover which assumptions are false while there is still time to act. If the team cannot locate the evaluation set, export source documents with permissions intact or reproduce a critical integration, the test has found real risk.

Set a decision threshold. For example, a workload may be allowed to use deeply proprietary services if the estimated exit is below three months and 20 per cent of annual service value. A regulated or customer-facing workload may require a tighter threshold. The exact number is yours. The discipline is making it explicit before scale increases the bill.

Sovereignty is control over decisions, not just data location

Many AI procurement conversations reduce sovereignty to a question about where data is stored. Location matters, particularly for personal, regulated or commercially sensitive information, but it is only one control. An organisation can keep data in a UK region and still depend completely on a foreign provider's pricing, licensing, model roadmap, identity layer and support process.

The UK government's July 2026 Data flows you can trust call for evidence asked for practical experience of whether the data regime enables trusted flows. The emphasis on practical evidence is useful for buyers. A contract stating that data is exportable should be tested against format, completeness, permissions, deletion evidence and the time required to receive it.

Domestic capability is also expanding. In August 2026, the government said Sovereign AI had invested in British AI chip company OLIX as part of a nine-figure fundraise. The announcement described OLIX as valued above $1 billion, cited a $220 million Series A earlier in the year and said five startups had received Sovereign AI equity investment, with 11 receiving backing when compute support was included. It also projected that the global AI chip market could reach $1 trillion in the early 2030s.

Those figures show why sovereignty is broader than a hosting badge. It includes access to compute, supply-chain options, skills, intellectual property, operational authority and the ability to change course. A UK supplier is not automatically portable, and a global supplier is not automatically unsuitable. The buyer test is whether the organisation retains meaningful choices under pressure.

In practice, ask four questions. Can we retrieve our data and configuration in usable formats? Can we operate the workload through another route within an agreed period? Do we have contractual rights that match the technical reality? Can leaders make the change without one supplier controlling the evidence, skills or timing? If any answer is unknown, the system may have UK residency without operational sovereignty.

Accept useful lock-in, but make it an explicit investment

The sensible objective is not zero lock-in. Trying to make every AI component interchangeable can create a costly lowest-common-denominator platform. Teams may reject managed security, monitoring or serverless services that would improve reliability simply because those services are not perfectly portable. They can spend more engineering time building abstractions than delivering value.

The better approach is deliberate lock-in. Record what the dependency buys, what it costs to unwind and which signal would trigger action. A proprietary document intelligence service might be justified because it halves processing time and removes months of development. That decision is sound if source documents remain accessible, outputs use documented formats, performance is measured against a portable benchmark and the organisation knows how long replacement would take.

Make the switching-cost register part of normal financial and operational reviews. Unit cost should be tracked beside exit cost because the two interact. A discounted commitment may reduce today's token price while increasing the penalty for moving. Rapid adoption may improve productivity while making a future revalidation project larger. A model upgrade may improve quality while introducing behaviour that is harder to reproduce elsewhere.

Assign one senior owner to each critical AI workload, but require evidence from technology, procurement, finance, security and the business team. Review the estimate after major architecture changes, contract renewals, model migrations and large increases in data or users. Retest the highest-risk path at least annually, and more often where customer service, regulated decisions or essential operations are involved.

The leadership decision then becomes clearer. You can accept a £100,000 switching exposure if the platform creates substantially more value and the risk is within appetite. You should not accept an unknown exposure because the pilot was quick or the supplier described its API as standard. Price the dependency while you still have negotiating leverage. That is how organisations gain the speed of managed AI without confusing convenience with control.

Frequently Asked Questions

Is all AI cloud lock-in bad?

No. Managed services can reduce delivery time, security work and operational burden. Lock-in becomes dangerous when the dependency is unmeasured, exceeds the organisation's risk appetite or cannot be unwound within an acceptable time.

What should an AI switching-cost estimate include?

Include data export and egress, replacement engineering, model and prompt revalidation, security and compliance review, staff retraining, overlapping supplier charges and the impact of disruption or reduced performance.

How often should we test an AI cloud exit plan?

Review estimates after major changes and test the highest-risk path at least annually. Customer-facing, regulated or operationally essential workloads may justify more frequent tests.

Does using open source remove vendor lock-in?

Not by itself. An open model can still depend on a particular accelerator, serving stack, fine-tuning pipeline or specialist team. Open formats and software improve options, but the end-to-end service still needs testing.

Is multi-cloud the best answer to AI portability?

Not always. Running everything across several clouds can add cost and complexity. A tested alternative for critical workloads is often more valuable than duplicating every component in advance.

Who should own the switching-cost register?

A senior owner should be accountable for each critical workload, with evidence supplied by technology, procurement, finance, security and the business team that depends on the outcome.

Does UK data residency make an AI service sovereign?

No. Residency addresses data location, while operational sovereignty also depends on pricing power, licensing, model access, skills, exportability and the ability to change supplier under pressure.

What is a practical first portability test?

Take one anonymised workflow, export its configuration and data, rebuild it using a credible alternative, then run 50 to 100 agreed evaluation cases to compare quality, latency, control and unit cost.