AI Vendor Exit Plans Need Operational Evidence Before UK Businesses Deploy Agents

AI Trust & Governance

11 June 2026 | By Ashley Marshall

Agentic AI changes the risk profile of vendor lock-in. Before UK businesses connect agents to real systems, exit plans need evidence, not assurances.

The exit plan is now an operational control

Most AI vendor conversations still treat exit planning as a procurement afterthought. The buyer asks whether the contract allows termination, the supplier points to a data export clause, and everyone moves on to model capability, price and integrations. That was already thin for software as a service. It is nowhere near enough for agentic AI, where a tool can access internal systems, remember context, take actions, call other tools and shape live workflows.

The practical question is no longer, can we leave this vendor one day. It is, can we prove that leaving this vendor will not stop the business from operating, destroy our audit trail, expose personal data, strand automated workflows or leave privileged credentials hanging around the estate. That proof has to exist before deployment, because once an AI agent is embedded in service desks, sales operations, finance approvals, case management or customer communications, the switching cost becomes operational rather than commercial.

Recent UK guidance points in the same direction. The NCSC's May 2026 blog on agentic AI adoption says organisations should start with tightly bounded pilots, limit access and define who can stop the system before it is connected to real data. The Bank of England, FCA and HM Treasury said in May 2026 that frontier AI has significant implications for cyber security and operational resilience, including third party and supply chain risk. Those are not abstract policy signals. They tell boards that AI vendor exit planning belongs in the same control family as identity management, incident response, business continuity and supplier assurance.

What this means in practice is simple. A supplier's statement that data is portable is not evidence. Evidence is a completed export of representative prompts, tool logs, vector records, embeddings metadata where relevant, configuration files, retention settings, role mappings and incident logs into a format the business can inspect. Evidence is a tested runbook showing how Microsoft 365 Copilot, Salesforce Agentforce, ServiceNow AI Agents, OpenAI API based assistants or Anthropic powered workflows can be disabled, contained or replaced without losing control of customer outcomes.

For UK businesses, the strongest exit plan is not the one with the best legal wording. It is the one that has been rehearsed while the stakes are low.

UK regulators are asking for evidence, not AI theatre

The UK has deliberately avoided a single, heavy AI law for most business use cases. That does not mean there is a governance vacuum. It means organisations are expected to map AI into existing duties, including data protection, consumer outcomes, senior management accountability, operational resilience and cyber security. The FCA says it does not plan extra AI regulations, but will rely on existing frameworks and an evidence based view of benefits and risks. That makes operational evidence more important, not less.

The ICO's updated data protection by design and by default guidance, refreshed on 5 February 2026 after the Data (Use and Access) Act 2025, says organisations must put appropriate technical and organisational measures in place from the start and throughout the lifecycle. For an AI agent, the lifecycle includes onboarding, live use, monitoring, model or vendor changes, suspension, deletion and exit. A DPIA that says a vendor has a deletion policy is weaker than one backed by logs showing test data was deleted, retained records were justified, and access was removed from connected systems.

Financial services offers the clearest warning, but the lesson travels. Parliament's Treasury Committee has recommended that HM Treasury designate major AI and cloud providers as Critical Third Parties by the end of 2026. HM Treasury's May 2026 response said evidence gathering is underway and initial designation decisions are expected this year. The point for ordinary UK firms is not that every supplier will become a Critical Third Party. It is that concentration risk is now a board level issue. If many businesses build operational processes around the same model provider, cloud platform or agent framework, the exit plan becomes part of resilience.

What this means in practice is that procurement should ask for proof in business language. Can the supplier provide a sample exit evidence pack. Can it show a data inventory, subprocessors, logging retention, deletion verification, model change notification process, continuity approach and support for export testing. Can your team run a realistic offboarding exercise before go-live. If the answer is that these questions are too early, the deployment is too early.

There is a useful misconception to challenge here. Some leaders think exit planning is pessimistic, or that asking hard portability questions slows innovation. In reality, it is the opposite. A clear exit test makes adoption faster because risk owners can approve bounded use cases with fewer hidden dependencies.

Data portability is only the first layer

When people hear vendor exit, they usually think about data export. That matters, but it is only the first layer. Agentic AI creates a wider dependency map. The agent may rely on prompts, tools, retrieval indexes, permissions, workflow automations, approval rules, guardrails, memory, monitoring dashboards, human review queues and connected APIs. If those components cannot be documented and moved, the organisation may own the raw data but still be locked into the operating model.

A proper exit evidence pack should cover at least six artefact groups. First, source and derived data, including files, CRM records, ticket histories, conversation transcripts, prompt libraries and retrieval sources. Second, configuration, including system instructions, tool permissions, safety settings, escalation rules and routing logic. Third, identity and access mappings, including service accounts, OAuth grants, API keys, privileged roles and temporary credentials. Fourth, logs and audit records, including tool calls, approvals, overrides, rejected outputs and incident notes. Fifth, performance baselines, including accuracy checks, false positive patterns, latency and cost. Sixth, operating procedures, including who reviews exceptions, who can pause the agent and how the business reverts to manual processing.

The GOV.UK AI Adoption Research published in 2026 gives the commercial backdrop. Three quarters of AI using businesses reported improved workforce productivity, and 57 percent reported new or improved processes or operations. The same research found that common safety challenges included data security and accuracy of outputs. That is exactly why portability has to include operating context. A business does not just need to recover a dataset. It needs to recover a way of working, with enough control to protect customers, staff and evidence trails.

For tools such as Microsoft 365 Copilot, Gemini for Workspace, ChatGPT Enterprise, Claude Enterprise, Salesforce Agentforce or bespoke assistants built on Azure OpenAI, the hard question is not whether you can download files. It is whether you can reconstruct the decisions and permissions that made the agent behave as it did. If an agent summarised a complaint, drafted a regulated response, approved a workflow or changed a CRM record, the organisation needs traceability after the vendor relationship ends.

That is why exit tests should include a sample restore into a neutral environment. Export the artefacts, revoke the original access, rebuild a minimal workflow and compare results. The aim is not perfect vendor interchangeability. The aim is a controlled landing if the supplier fails, prices change, terms shift, risk appetite changes or a regulator asks how the business remained accountable.

Agent access makes lock-in a security issue

Traditional lock-in is often framed as commercial inconvenience. Agent lock-in is also a security issue because the vendor's service may sit close to privileged systems. An agent that can read mailboxes, query customer records, draft invoices, create support tickets, trigger refunds or update project systems needs carefully bounded access. If the organisation cannot rapidly remove that access, it has not got an exit plan. It has got a dependency with optimistic paperwork.

The NCSC's agentic AI guidance is explicit about the risk. It says agents can have broader access than non-agentic systems, their behaviour can be harder to predict, problems may happen faster than humans can review them, and organisations should never grant unrestricted access to sensitive data or critical systems. It also recommends least privilege, temporary credentials, scope limits, behaviour monitoring, threat modelling and incident plans. Those recommendations double as exit requirements.

What this means in practice is that the buyer should insist on an access revocation drill. Pick a representative agent. Disable its vendor token. Remove its service account. Revoke OAuth grants. Rotate connected API keys. Confirm that the agent cannot continue acting through cached credentials, background jobs, sub-agents or third party integrations. Then inspect logs to prove the shutdown worked. This is basic hygiene, but many businesses only discover the gaps when a supplier relationship is already distressed or an incident is underway.

There is another layer. AI agents often sit across several vendors at once. A workflow may use Slack, Microsoft Graph, HubSpot, Salesforce, Jira, Zendesk, Zapier, Make, Pinecone, Snowflake, AWS Bedrock, Azure OpenAI and a model provider. Exit planning therefore needs a dependency graph, not a single vendor note. If the model provider changes its API, if an orchestration platform loses access, or if a retrieval store has a data incident, the business needs to know which agents, departments and customer journeys are affected.

The Bank of England, FCA and HM Treasury joint statement on frontier AI tells regulated firms to manage frontier AI cyber risks from third parties and supply chains, including external applications, libraries and services integrated into networks. That is sensible advice for any UK business deploying agents. You cannot manage what you cannot see, and you cannot exit what you cannot isolate.

The counterargument is speed, but weak exits slow adoption

The leading counterargument is familiar. AI is moving quickly, competitors are experimenting, and businesses cannot spend months building governance packs before every pilot. There is truth in that. A small internal drafting assistant should not face the same process as an autonomous finance agent connected to banking, ERP and customer communications. Over-governance can smother useful adoption, especially in small and medium sized businesses where legal, security and data teams are thin.

But that argument often attacks the wrong version of governance. An evidence based exit plan does not have to be a 90 page document. For a low risk pilot, it might be a two page runbook, a data inventory, a named owner, screenshots of access settings, a successful export test and a record of how to switch the tool off. For a high impact agent, it should be deeper, with legal, security, data protection, operational resilience and business continuity input. The standard should scale with the harm that could occur if the agent fails, leaks, drifts, overreaches or becomes unavailable.

NCSC's May 2026 agentic AI blog makes the same pragmatic point. It encourages organisations to start small, use agents for tightly bounded pilots, apply cyber hygiene from the start and plan for failure. The FCA's AI approach also favours proportionate use of existing frameworks over detailed AI specific rules. That is not bureaucracy. It is a way to avoid freezing innovation later. The quickest route to a board level ban on AI agents is a poorly evidenced deployment that creates customer harm, exposes data or leaves no audit trail when challenged.

There is also a procurement benefit. Vendors that can support export testing, explain retention, document tool permissions and participate in exit rehearsals are more likely to be mature partners. Vendors that treat these questions as hostility are telling you something useful. If they cannot help you leave cleanly, they may not be ready to support you responsibly while you stay.

What this means in practice is a tiered adoption model. Tier one covers personal productivity tools with no sensitive data and no system actions. Tier two covers assisted workflows with human review and limited integrations. Tier three covers agents that act in operational systems. Tier four covers regulated, customer impacting or financially material agents. Exit evidence should rise with each tier. That keeps momentum where risk is low and discipline where the business is exposed.

A practical evidence checklist for UK buyers

Before a UK business deploys an AI agent, it should ask for evidence in five areas. The first is portability. Run a test export of prompts, configuration, knowledge sources, logs, user mappings and retention settings. Record the format, completeness, time taken and any manual supplier intervention required. If embeddings or vector stores are involved, document what can be exported, what must be rebuilt, and how source documents map to indexed content.

The second is continuity. Define the manual fallback and the replacement route. If a customer service agent is unavailable, can the team triage tickets without it. If a finance agent stops working, can approvals move through a manual queue. If a sales assistant loses CRM access, can the sales team still see activity history. Continuity does not mean the business works at full speed during exit. It means the business knows which services degrade, who owns the workaround and how customers are protected.

The third is auditability. Keep records that survive the vendor relationship. Export logs for tool calls, approvals, rejected recommendations, human overrides, model versions where available, policy settings and incident events. This matters under UK GDPR accountability, FCA expectations for regulated firms, contractual disputes and internal governance. If an agent's action cannot be explained after exit, the organisation may have outsourced evidence it still needs to own.

The fourth is access control. Test revocation, not just provisioning. Agents should use least privilege, short lived credentials where possible, named owners, scoped APIs and monitored service accounts. The exit evidence should show how access is removed across primary systems and connected third party tools. A supplier portal screenshot is useful, but logs from Microsoft Entra ID, Okta, Google Workspace, AWS IAM or equivalent identity tooling are stronger.

The fifth is commercial and legal trigger clarity. Define what happens if the vendor changes terms, introduces a risky model update, suffers a material incident, fails service levels, changes data processing, is acquired, loses a subprocessor or becomes too expensive. Contract rights matter, but only if the operational team has rehearsed how to use them. A good exit clause without a tested runbook is a locked fire door with a polished sign.

Precise Impact's view is that this should become a standard pre-deployment gate for serious AI agents. The buyer should be able to say: here is the agent, here is what it can touch, here is how we monitor it, here is how we stop it, here is what we can export, here is how we continue the service, and here is the evidence. That is the difference between adopting AI and merely hoping the supplier relationship holds.

For organisations building an AI governance route, this also links naturally to broader implementation work such as AI implementation planning and AI consulting support. Exit planning should not sit in legal isolation. It should sit in the operating model.

Frequently Asked Questions

What is an AI vendor exit plan?

An AI vendor exit plan is the tested process for leaving, replacing, suspending or materially reducing reliance on an AI supplier. For agentic AI it should cover data export, configuration, logs, connected tools, access revocation, fallback workflows, deletion evidence and contractual triggers.

Why do AI agents need stronger exit planning than ordinary software?

AI agents can access systems, call tools, remember context and take actions. That means exit affects operations, security, auditability and accountability, not just data migration. The organisation needs evidence that it can stop the agent and continue critical work.

What evidence should a UK business request before deploying an AI agent?

Ask for a sample export, a data and dependency inventory, logging and retention details, access control records, deletion verification, subprocessors, model change notifications, incident processes and a practical exit runbook tested against a realistic use case.

Does UK law require a specific AI exit plan?

There is no single UK AI exit planning law for all businesses. However, UK GDPR accountability, ICO data protection by design guidance, FCA expectations for regulated firms, cyber security guidance and operational resilience principles all point towards documented, tested controls.

How does this apply to Microsoft 365 Copilot or Google Gemini for Workspace?

For workplace AI tools, focus on permissions, audit logs, data retention, tenant settings, connectors, prompt and response handling, and how quickly access can be removed. The exit test should prove that the organisation can disable the service without losing core records.

Should small businesses do this too?

Yes, but proportionately. A small business does not need enterprise bureaucracy for a low risk assistant. It does need a clear owner, a data inventory, an export check, a shutdown process and a record of what systems the tool can access.

What is the biggest misconception about AI vendor lock-in?

The biggest misconception is that lock-in is only about price or contract renewal. With agents, lock-in can involve workflows, permissions, audit records, customer processes, model behaviour and operational resilience.

When should the exit plan be tested?

Test it before live deployment, then repeat after major changes such as new integrations, expanded permissions, new data sources, model upgrades, supplier contract changes or movement into customer impacting workflows.