Why UK businesses need an AI exit strategy before the next vendor outage

The Sovereign Cloud

18 April 2026 | By Ashley Marshall

The hard part of AI adoption is not getting in. It is knowing how you get out when a supplier fails, changes terms, or becomes too risky to trust with core operations.

The next outage will not just be a cloud problem

Most AI conversations still start with capability. Which model is best, which assistant is fastest, which workflow tool integrates cleanly, which vendor can get a pilot live before quarter end. That is understandable, but it misses the operational question that matters once AI moves into real delivery. What happens when one part of that stack is unavailable, degraded, repriced, or suddenly no longer acceptable to your risk team?

That question is not theoretical. In October 2025, the BBC reported that an AWS outage affected more than 1,000 companies and hit services ranging from HMRC to banks and consumer platforms. The immediate cause was a DNS issue, not some dramatic cyber-attack, which is exactly the point. Your AI estate does not only fail because of sophisticated threats. It also fails because mundane infrastructure problems ripple through tightly coupled systems. If your chatbot, document pipeline, retrieval layer, CRM automations and internal copilots all rely on the same small group of upstream suppliers, a routine fault becomes a business interruption event.

The Guardian pushed that point further when it reported that AWS has won 189 UK government contracts worth £1.7 billion since 2016. Whether you agree with the politics of that or not, it is a useful proxy for concentration risk. The same pattern exists in the private sector. Many firms believe they have multiple AI tools, but in practice those tools often sit on the same cloud, use the same model providers, depend on the same identity layer, and call the same APIs. That is not diversification. It is just a more complicated form of dependency.

What this means in practice is simple. If your leadership team cannot answer four basic questions, you do not yet have an AI resilience strategy. Which suppliers are mission-critical, what breaks if each one goes down, how fast can you switch to a fallback, and what data can leave with you in a usable format? An exit strategy is the discipline of answering those questions before an incident forces you to. It is not anti-innovation. It is what makes innovation survivable.

BBC coverage of the October 2025 AWS outage is worth reading because it frames the problem plainly. We are building modern AI on a small number of very large platforms. That is efficient, right up until it is not.

UK regulators are already signalling that concentration and resilience matter

If this were only a technical preference, boards could safely treat it as an architecture debate. They cannot, because UK regulators are increasingly describing resilience, concentration and switching barriers as economic and governance issues, not just engineering detail. That should change how business leaders think about AI vendor dependency.

Three recent UK signals stand out. First, the Competition and Markets Authority announced in March 2026 that Microsoft and Amazon had agreed to take material steps on cloud egress fees and interoperability following CMA engagement. The CMA was explicit about the goal: greater choice for UK customers and stronger resilience in UK tech stacks. That language matters. The watchdog is not discussing egress and interoperability as nice-to-have features. It is treating them as conditions for a competitive and resilient digital economy, especially as AI becomes embedded into everyday business software.

Second, the Government Cyber Action Plan published in January 2026 says the UK has experienced repeated, systemic failures in digital resilience and warns that both hostile attacks and accidental failures can cause immediate and profound impacts. It also commits more than £210 million of central investment behind the newly formed Government Cyber Unit. Even if you are not a public sector organisation, the direction of travel is clear. Digital resilience is moving from technical aspiration to accountable operating requirement.

Third, the Cyber Security and Resilience Bill factsheet reinforces that cloud computing services sit inside the UK regulatory conversation around essential and digital services. The document stresses that organisations must take appropriate and proportionate security measures and report incidents that significantly disrupt services. Again, the important point is not whether your company falls directly inside every part of that regime today. It is that operational resilience expectations are getting sharper, and critical third-party dependence is part of that picture.

What this means in practice is that an AI exit strategy helps with far more than outage recovery. It supports board assurance, procurement scrutiny and evidence that your business has considered foreseeable third-party failure. If a regulator, insurer, enterprise customer or due diligence team asks how you handle supplier concentration, a hand-wavy answer about trust in a major vendor will not be enough. You need documented fallback options, export paths, contractual protections and tested recovery decisions.

The CMA announcement is particularly useful because it links interoperability and multi-homing directly to resilience. That is the core business case for exit planning.

An AI exit strategy is not a procurement appendix, it is an operating model

When people hear the phrase exit strategy, they often imagine a legal clause at the back of a contract. That is part of it, but only a small part. A real AI exit strategy is an operating model for reducing dependency before it becomes a crisis. It covers technology, process, data, people and commercial terms together.

Start with the dependency map. Most businesses underestimate the number of hidden single points of failure inside their AI stack. You may have one model provider, one orchestration layer, one vector database, one cloud region, one identity provider, and one workflow engine triggering everything around it. Lose any one of those and your service may not fail gracefully. It may stop entirely, or worse, continue in a degraded state that creates customer harm or compliance issues. Mapping those dependencies is the first discipline because it turns vague concern into something the business can govern.

Then deal with portability. Can prompts, system instructions, evaluation datasets, retrieval pipelines and structured outputs move to another environment without months of rebuilding? Can your team export data in open formats? Can another provider replicate the core workflow with acceptable quality? If not, you are not buying AI capability, you are renting it on someone else’s terms.

NCSC guidance on cloud resilience has been pointing in this direction for years, advising organisations to make sure resilience arrangements actually match the impact of likely outages and to understand hosting across multiple data centres, availability zones or regions. The same logic now applies to AI. It is not enough to ask whether a vendor has a status page and a high uptime number. You need to know whether your own use case has a realistic failover path.

A practical exit strategy usually includes six artefacts. A supplier criticality register, a technical fallback design, a data export and deletion plan, a contract schedule for egress and transition support, a communications playbook, and a test calendar. None of this needs to be bureaucratic. For many mid-market firms, a well-run two week exercise can get you most of the way there. The value comes from forcing clear decisions while the system is working, rather than improvising when it is not.

The misconception to challenge here is that exit planning slows adoption. In my experience, the opposite is true. The teams that move fastest are usually the ones confident they can change vendor, reroute traffic, or downgrade service safely if conditions change.

Data protection and governance make lock-in more dangerous than many firms realise

For UK businesses handling personal data, AI vendor lock-in is not only an uptime issue. It is also a governance and accountability issue. The ICO guidance on AI and data protection is clear that organisations remain responsible for compliance and for demonstrating that compliance. You cannot delegate that obligation to data scientists, engineering teams or external vendors. Senior management must understand and address the risks, and a data protection impact assessment is presented as an ideal way to demonstrate compliance.

That matters because the moment you cannot explain where data is processed, how a model provider uses it, how outputs are logged, or how information will be returned or deleted on exit, your governance problem gets bigger than the outage itself. The service may come back online, but you can still be left with unanswered questions about controller and processor relationships, retention, auditability and cross-border transfers. Those are not abstract legal concerns. They affect procurement sign-off, incident response, client trust and the speed at which you can keep deploying AI.

The ICO also warns that organisations should not underestimate the initial and ongoing investment needed to demonstrate data protection by design and default. That is an important correction to the current market mood. Too many businesses are buying AI tools as if they were lightweight productivity subscriptions, when in reality they are introducing new data processing chains, new decision-support layers and new third-party risk. If you need to leave a supplier quickly, you need proof that data can be extracted, deleted, reconfigured and governed elsewhere without losing control.

What this means in practice is that every significant AI supplier should be assessed against a simple set of governance questions. What personal data enters the system, who decides the purpose and means of processing, how can logs be exported, what retention controls exist, what happens to training or fine-tuning artefacts on termination, and how long will transition support last? If your vendor cannot answer those questions cleanly, your exit risk is already too high.

This is where sovereign cloud and UK-hosted options become relevant. They are not automatically better, and they are certainly not the only answer, but they can make data lineage, jurisdiction and fallback design easier to explain. For sectors with heavier scrutiny, that alone can justify keeping at least one credible alternative outside the default US hyperscaler stack.

The counterargument sounds sensible, but it breaks down in production

The most common pushback is straightforward: the biggest vendors are the safest vendors, so why spend time designing exits from them? There is a grain of truth in that. Large cloud and model providers usually have stronger security teams, broader infrastructure and better tooling than smaller players. For many workloads, they are the right primary choice. The mistake is turning that into an argument against contingency.

Recent events show why. According to reporting in the Guardian in February 2026, AWS experienced at least one customer-facing interruption linked to an AI tool misconfiguration, with a previous 13-hour internal interruption also reportedly tied to an AI agent. Amazon argued the incidents were user error, not AI error. That distinction matters less than people think. From a customer perspective, the relevant fact is that operational complexity is rising. As vendors add more automation, more agentic controls and more layered services, the pathways to failure multiply. Whether the root cause is human error, AI-assisted error or a dependency fault, your business still carries the consequence.

The other version of the counterargument is commercial. Some leaders assume multi-vendor resilience is simply too expensive, especially for mid-market firms. That can be true if you try to duplicate everything in full. But an exit strategy does not require you to run two complete stacks permanently. Often the sensible approach is lighter. Keep secondary model compatibility for key use cases. Maintain exportable data structures. Avoid proprietary workflow logic where possible. Negotiate egress and transition clauses early, before spend scales. Test a manual fallback for customer-critical journeys. These steps cost far less than a rushed migration during an incident.

There is also a strategic misconception that switching later will be easier because the market will mature. Sometimes it does. Sometimes your dependency deepens faster than your options improve. Custom integrations, embedded prompts, user habits, governance paperwork and commercial discounts all increase the cost of change over time. That is why the best moment to design an exit is near the start of adoption, when your leverage is highest and your architecture is still flexible.

So the right conclusion is not avoid major vendors. It is use them with your eyes open. A primary supplier is fine. A blind dependency is not.

What a board-ready AI exit plan should contain in the next 90 days

If you want this conversation to move from general concern to practical control, set a ninety day target and make the output tangible. A board-ready AI exit plan does not need to be a thick document. It needs to show that the business understands where it is exposed, what it will do under stress, and who owns the decisions.

In the first thirty days, identify every AI-related supplier touching customer delivery, internal decision support, data processing, hosting, identity, orchestration and observability. Rank them by business criticality. Then record the failure mode for each one: outage, degraded performance, pricing shock, regulatory unsuitability, contractual lock-in, or unacceptable change in terms. This alone is often revealing because it shows that the highest risk is rarely the model alone. It is usually the surrounding infrastructure and process dependencies.

In days thirty to sixty, define the fallback state for each critical use case. For a customer service assistant, that may mean rerouting to a simpler model and narrowing scope. For document automation, it may mean queueing work and invoking human review. For internal knowledge search, it may mean local retrieval with a different model endpoint. Choose one or two tools to standardise portability, such as containerised services, open model APIs, exportable vector stores, or prompt libraries stored outside the vendor platform. If you already use Microsoft Azure OpenAI, AWS Bedrock or Google Vertex AI, ask what would be needed to run the same core workflow on another route within days rather than months.

In the final thirty days, test the plan. Run a tabletop exercise around a real scenario such as a cloud outage, a supplier data use policy change, or a sudden suspension of a critical feature. Include operations, legal, security, procurement and communications. Measure time to decision, not just time to recovery. Many firms discover that the real bottleneck is not technical failover. It is uncertainty over who has authority to degrade service, inform customers, approve emergency spend or switch to a lower-risk configuration.

The board-level message is clear. An AI exit strategy is a resilience asset, a governance control and a negotiating lever. In a market shaped by concentration, interoperability disputes and rising regulatory expectations, it is quickly becoming part of competent management. The next vendor outage will not wait for your architecture to mature. You need the plan before you need the exit.

Frequently Asked Questions

What is an AI exit strategy in practical terms?

It is a documented plan for how your business would switch, downgrade or withdraw from a critical AI supplier without losing control of operations, data or compliance. It usually covers contracts, architecture, data export, fallback workflows and decision-making.

Is this only relevant for large enterprises?

No. Mid-market firms are often more exposed because they depend heavily on a small number of suppliers and have less internal redundancy. A lighter exit plan is still better than none.

Do we need a full multi-cloud setup to have an exit strategy?

Not necessarily. Many firms start with compatible APIs, portable data structures, contract protections and tested reduced-service modes rather than duplicating their whole environment.

How often should we test an AI exit plan?

At minimum, test critical scenarios annually and whenever a major supplier, data flow or customer-facing AI workflow changes. High-risk use cases may justify more frequent tabletop exercises.

Which suppliers should be in scope first?

Start with any supplier whose failure would stop customer delivery, disrupt regulated processes, block access to important data, or materially change your security and governance posture.

How does this relate to UK GDPR and ICO expectations?

If personal data is involved, your organisation remains accountable for lawful processing, governance and evidence of compliance. An exit plan supports that by proving how data can be controlled, moved and deleted.

Are sovereign cloud options always the best answer?

No. They are one option, not a universal rule. The right choice depends on data sensitivity, sector requirements, cost, portability and the maturity of the workload.

What is the first sign we are too locked in?

A common warning sign is when no one can clearly explain how long a switch would take, what it would cost, what data can be exported, or what service level customers would receive during transition.