AI Workload Portability Tests for UK Firms Avoiding Lock-In

The Sovereign Cloud

22 July 2026 | By Ashley Marshall

AI lock-in is no longer just a procurement worry. Once a model workflow touches data, cloud services and operational decisions, the only honest answer is to test whether it can move.

Portability is now a board risk, not an architecture preference

AI workload portability used to sound like a cloud architecture concern. In 2026 it belongs in the risk register. UK firms are building useful AI into service desks, compliance review, sales operations, software delivery, finance processes and customer communication. Many of those workflows start with a single model API, a single vector store, a single cloud region and a set of managed services that feel productive during the pilot. The trouble begins when the workload becomes operational and the business discovers that moving it would require rewriting prompts, changing embeddings, reworking identity, re-indexing data, replacing observability, changing security reviews and renegotiating cloud costs.

The UK competition context makes this more than a theoretical worry. In its 2025 final decision on cloud services, the Competition and Markets Authority said UK customers spent GBP 10.5 billion on cloud services in 2024, with spending growing by nearly 30% each year since 2020. The CMA also said cloud services underpin AI model development and deployment. That means AI lock-in and cloud lock-in are converging. A firm may think it is choosing a model, but the real decision can quietly include storage patterns, GPU access, data movement costs, identity controls, monitoring tools and proprietary orchestration layers.

What this means in practice is straightforward. If an AI workflow would be painful to pause for a week, expensive to move, or hard to explain to a regulator, it needs a portability test before it becomes business critical. The test does not need to prove that every workload can move instantly. It needs to prove that the business knows what is portable, what is not, what the switching cost is, and which choices are deliberate.

The UK market evidence says switching is rare

The leading misconception is that multi-cloud automatically protects a business from lock-in. It can, but only when workloads have genuinely been designed and tested to move or split across environments. Buying services from more than one cloud provider is not the same as having portable AI workloads. The CMA made that distinction clearly. Its final decision summary said less than 1% of customers switch cloud provider each year. It also found that large customers are more likely than smaller ones to use multiple providers, but their spending generally remains concentrated with one main provider.

The CMA appendix on multi-cloud is even more useful for AI leaders because it shows how nominal multi-cloud can still leave a business dependent on a primary cloud. Based on the CMA analysis, customers operating a two-cloud architecture had an average spend split of around 80/20, meaning 80% on the primary cloud and 20% on the secondary cloud. In a three-cloud architecture the average split was approximately 75/20/5. That does not make multi-cloud pointless. It means leaders should ask whether the secondary cloud is a real exit route, a procurement hedge, a disaster recovery pattern, or simply a handful of disconnected workloads.

For AI, the gap is even sharper. A team might use OpenAI for customer support drafting, Anthropic for document review, Azure AI Search for retrieval, Bedrock for internal agents, Snowflake for data, Databricks for pipelines and Kubernetes for serving small models. That sounds diversified. Yet the actual production workflow may depend on one embedding model, one managed identity pattern, one vector schema, one cloud data store and one set of safety filters. If those dependencies are not tested, the business has diversity on the supplier list but fragility in the workflow.

A useful AI portability test starts with the workload, not the vendor

The worst way to test portability is to ask each vendor whether its platform is open. Most will say yes, and many will be partly right. The better way is to choose a representative workload and make it run somewhere else under controlled conditions. Pick one workflow that matters, such as a customer email classifier, a document extraction process, a policy question answering tool, a coding assistant evaluation harness or an internal support agent. Then define what must remain stable: input format, data permissions, retrieval quality, latency, cost per successful task, audit log, safety rules, monitoring and rollback.

The test should include both model portability and cloud portability. Model portability asks whether the workflow can move from one model family to another, for example from GPT-5.4 to Claude Sonnet, Gemini, Mistral, Llama or a smaller hosted model, without rewriting the business process. Cloud portability asks whether the same workload can run across Azure, AWS, Google Cloud, a specialist GPU provider or a local Kubernetes environment without rebuilding the system around proprietary services. The answer may be no, but the no should be explicit and priced.

What this means in practice is a small test pack. Use 100 to 300 representative cases, including edge cases, sensitive-data cases and known failures. Run them through the current stack and one alternative stack. Measure accuracy, refusal behaviour, latency, token cost, cloud cost, data movement, security controls and operational effort. Keep the test boring and repeatable. A portability test is not a vendor bake-off for a slide deck. It is an engineering rehearsal for an exit, a workload relocation, a regulatory constraint, a commercial dispute, a region outage or a better model arriving.

Containers and open interfaces help, but they do not solve lock-in alone

There are useful technical foundations for portability. The CNCF Kubernetes conformance programme says conformance enables interoperability from one Kubernetes installation to the next and lets organisations choose between vendors. The Open Container Initiative provides specifications used across container image formats and distribution. These matter because AI services are increasingly assembled from model servers, retrieval workers, evaluation jobs, queues, caches, gateways and monitoring components. Packaging those parts as containers gives a team more room to move than if every component is wired directly into a proprietary platform.

But containers are not magic. An AI workload can be containerised and still locked to one cloud through managed databases, vector stores, object storage semantics, identity services, networking, GPU drivers, observability, secret management, policy engines and data residency assumptions. Kubernetes can move the application runtime, but it will not automatically move the data plane, the model licence, the embedding index, the governance evidence or the commercial contract. This is why portability tests must include the dependencies around the container, not only the container itself.

Vendor tools can still be part of a sensible strategy. Azure Arc, Amazon EKS Anywhere, Google Kubernetes Engine, Red Hat OpenShift, VMware Tanzu, Canonical Kubernetes and managed inference platforms can all reduce operational friction in different circumstances. The practical question is not whether a tool is proprietary or open in the abstract. It is whether the business has a documented replacement path for the components that would hurt if pricing changed, a UK data requirement tightened, a model was withdrawn, or a provider no longer met risk expectations. Architecture diagrams should show the lock-in points honestly, not hide them behind a generic cloud icon.

Sovereignty means testing data routes as well as model routes

For UK firms, sovereign-cloud thinking is not only about national flags on data centres. It is about knowing where data, prompts, embeddings, logs, model outputs and support access can go, and being able to prove those routes under pressure. The ICO guidance on AI and data protection points organisations back to accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights. In an AI portability context, those principles become operational questions. Can the workload move without exporting personal data unnecessarily? Can embeddings be regenerated in a new location? Can logs be redacted or retained lawfully? Can a person explain which data was used if a customer challenges an outcome?

NCSC guidance is equally relevant. The Guidelines for secure AI system development apply to AI systems created from scratch and systems built on top of tools or services provided by others. They emphasise secure design, secure development, secure deployment, and secure operation and maintenance. A portability test should therefore include secrets, identities, logging, monitoring, patching, model supply chain, incident response and fallback operations. Moving an AI workload insecurely is not resilience. It is a faster way to duplicate risk.

This is where the counterargument deserves attention. Some leaders will say portability is a distraction because the safest option is to choose one major cloud and use it well. For some workloads, that is a reasonable decision. A single-cloud design can be cheaper, simpler and more secure than a poorly governed multi-cloud design. The mistake is pretending that simplicity removes lock-in. It only makes the lock-in easier to manage if the exit costs, data routes and replacement options are documented and periodically tested.

The practical test schedule for 2026

A useful 2026 portability programme does not need to start with a grand transformation. Start with a register of production and near-production AI workloads. For each one, record the business owner, data classification, current model, fallback model, cloud services used, vector store, orchestration layer, monitoring, security approvals, personal data exposure, region requirements, monthly run cost and estimated outage impact. This creates the basic evidence needed to decide which workloads deserve a portability test first.

Then run three levels of testing. Level one is model substitution: keep the same cloud and data layer, but swap the model route using an AI gateway, evaluation harness or orchestration layer. Level two is component relocation: move one important dependency, such as inference, embeddings, retrieval or evaluation, to another environment. Level three is workload relocation: deploy the whole workflow in an alternative cloud, a specialist provider or a local environment and run the same test pack. Each level should produce a short report: what moved, what failed, what cost changed, what security evidence changed and what decision follows.

Connect the work to existing governance rather than creating a separate AI theatre. Link portability tests to procurement renewals, cloud contract reviews, UK GDPR assessments, business continuity exercises, cyber incident playbooks and board risk reporting. Where the workload supports regulated activity, customer outcomes or critical internal operations, put the test evidence into the same evidence pack used for approval. Internal links help teams stay aligned too: model upgrade governance should connect to AI model release evaluation windows, and compute choices should connect to small language model routing. The firms that do this well will not avoid every dependency. They will know which dependencies are strategic choices and which ones are accidents waiting to become invoices.

Frequently Asked Questions

What is an AI workload portability test?

It is a controlled exercise that runs an AI workflow through an alternative model, cloud service or local environment to measure what breaks, what changes, what it costs and what evidence the business needs before relying on that route.

Does multi-cloud mean our AI workloads are portable?

No. Multi-cloud means the organisation uses more than one provider. Portability means a specific workload can move or be recreated with acceptable cost, risk, latency, security evidence and business disruption.

Which AI workloads should UK firms test first?

Start with workflows that touch personal data, customer outcomes, regulated activity, critical internal operations, large monthly spend, proprietary data stores or a single model route that would be hard to replace quickly.

How often should portability tests be run?

Run a baseline test before production approval, then repeat before major model upgrades, procurement renewals, cloud contract changes, data residency changes or significant increases in workload volume.

Do portability tests require Kubernetes?

No. Kubernetes can help with runtime portability, but the test still needs to cover data, identity, logging, vector indexes, security controls, model licences and operational procedures.

How does UK GDPR affect AI portability?

If personal data is involved, the organisation must consider accountability, security, transparency, data minimisation, accuracy and individual rights when moving prompts, logs, embeddings or outputs between environments.

Is single-cloud AI always a bad decision?

No. Single-cloud can be simpler, cheaper and safer for some workloads. The risk is unmanaged dependency. A good single-cloud decision should still include an exit route, fallback option and tested assumptions.

What should a portability test report include?

Include the workload tested, source and target environments, model route, data moved, controls changed, results, failures, cost difference, security evidence, unresolved dependencies, owner and recommended decision.