Build an Exit Plan for Your AI Provider Before You Need It
Matthew Leo · Published October 23, 2026 · Guides
An AI provider can change a model, retire an API, raise prices, restrict a feature or suffer an outage. A company that waits for one of those events before planning its exit will discover that “we can switch vendors” is not a plan.
An exit plan does not require a costly multi-provider architecture for every experiment. It requires knowing which business processes depend on the service, what must move, what cannot move and how the organization will keep operating during the transition.
Canada’s Office of the Superintendent of Financial Institutions made this practical in its July 2026 bulletin on generative and agentic AI. OSFI tells federally regulated financial institutions to map AI dependencies to critical operations, test failure scenarios, establish manual fallbacks and assess the portability and substitutability of AI services.
Most Canadian businesses are not governed by OSFI. The control still makes sense for any organization that has embedded an external model into customer service, software development, document review, analytics or internal search.
Start with the business process, not the model name
List each business process that would slow down or stop if the provider disappeared tomorrow. Record the owner, users, frequency, data involved and maximum tolerable interruption.
Do not write “marketing uses AI.” Name the dependency precisely:
- the support team uses a model to draft replies but a person sends them;
- a document workflow extracts invoice fields and posts them into accounting;
- developers call an API from production code;
- staff search internal policies through a vendor-hosted retrieval system;
- an agent can create tickets, send messages or change records.
This inventory separates inconvenience from operational dependency. It also exposes hidden components such as plugins, vector databases, prompt-management tools, identity services and monitoring platforms.
Define the events that trigger an exit
A plan needs specific triggers. “When the provider is no longer good enough” invites delay and argument. Define thresholds that an owner can observe and escalate.
- Availability: repeated outages or a recovery time that exceeds the process tolerance.
- Security: a material incident, loss of an essential control or inability to obtain evidence required by a customer or regulator.
- Privacy: a change in data use, retention or processing location that conflicts with policy or contract.
- Performance: accuracy or latency remains below the documented threshold after remediation.
- Commercial: price, usage limits or contract terms move outside the approved range.
- Strategic: the provider retires a model, feature or Canadian availability that the process needs.
Give one person authority to invoke a temporary fallback and identify who approves a full migration. An exit plan that requires an emergency search for decision-makers will waste the first hours.
Know what can actually be exported
Separate the organization’s assets from the provider’s service. The list may include prompts, system instructions, evaluation cases, model settings, conversation records, embeddings, vector indexes, logs, safety rules, user feedback, fine-tuning data and custom code.
For each item, record:
- the owner and authoritative location;
- the available export format;
- how often an export or backup is created;
- whether the format can be read without the provider;
- retention and deletion requirements;
- dependencies on proprietary model features.
A downloaded archive is not proof of portability. Restore a sample into a separate environment and confirm that the organization can read, validate and reuse it.
Measure behaviour before changing providers
Models are not interchangeable even when their APIs look similar. Keep a representative evaluation set that covers the real process: routine inputs, difficult cases, Canadian spelling and terminology, French content where relevant, prohibited actions, privacy-sensitive data and known failure modes.
Run that set against the current service and a candidate replacement. Compare task success, error severity, latency, cost and the amount of human review required. Do not rely on a general benchmark that ignores the organization’s data and workflow.
Where the AI can act, preserve the control boundary. Mapletechie’s approval-gate checklist for AI agents explains how to keep sending, paying, deleting and deploying behind explicit human authorization.
Create two playbooks
A planned exit and a stressed exit need different instructions.
Planned exit
- complete security, privacy and commercial review of the replacement;
- migrate a low-risk workflow first;
- run old and new services in parallel for a defined period;
- compare evaluation results and operating cost;
- move traffic gradually and keep a rollback point;
- confirm deletion and contract closure after the retention period.
Stressed exit
- stop high-risk automated actions;
- switch to the manual or reduced-service process;
- preserve logs, inputs and outputs needed for investigation;
- revoke provider tokens and rotate credentials if compromise is possible;
- notify affected teams, customers or regulators through the incident process;
- restore only the critical workflow before optional features.
OSFI’s Third-Party Risk Management Guideline uses the same split. It calls for playbooks for stressed exits caused by failure or insolvency and non-stressed exits driven by commercial, performance or strategic reasons. It also says plans should include timelines, costs, resources, interim workarounds and severe but plausible scenarios.
Test the plan without the provider
Once or twice a year, disable access to the service in a test environment and run the fallback. Time how long it takes to identify the affected workflows, retrieve data, change credentials, switch endpoints and communicate with users.
Record every manual step and every unavailable record. Update the plan when a model, plugin, API, contract or data flow changes. A beautiful exit document that describes last year’s architecture is another dependency, not a control.
Canadian organizations building around foreign AI services should also read Mapletechie’s analysis of what AI sovereignty means beyond a Canadian server location. Control includes the ability to continue operating when a supplier relationship changes.
Tags: AI providers, vendor exit plan, third-party risk, operational resilience, Canada