Anatomy of a Real AI Vendor Exit Plan: The Seven Components Procurement and Risk Teams Actually Need

source[code] | BFSI Technology Insight | 11 September 2026

Key Takeaways

• An exit plan is not a clause; it is a documented, resourced, testable capability with seven distinct components - data and artifact portability, model/workflow substitution, transition assistance, timelines, cost allocation, activation triggers, and rehearsal - and most BFSI AI contracts have, at best, one or two of them (Morgan Lewis, 2026; Hunton, 2026).

• AI adds a portability problem outsourcing law has not had to solve before: when the model itself cannot move, the exit plan has to specify substitute deliverables - fine-tuning datasets, prompt libraries, evaluation sets, telemetry - or there is nothing to hand the replacement vendor (Morgan Lewis, 2026).

• Practitioners advising on live AI exits report the same failure mode repeatedly: teams start the exit process at 30 days' notice instead of 90, and skip dependency mapping, so workflows lose their replacement path before vendor access is cut (InformationWeek, 2026).

• Business continuity practice has tested this for two decades: a plan is not credible until it has been exercised, not merely written - ISO 22301 makes "test business continuity plans and monitor outcomes" a standing requirement, not a one-off (BSI, 2026).

• Not every AI vendor warrants a fully rehearsed exit plan; the discipline is proportioning exit investment to what the vendor actually does, not building the same seven-component plan for a chatbot FAQ tool and a core underwriting model.

From "Why" to "What": Picking Up Where The Concentration Analysis Left Off

source[code]'s prior analysis of APRA's AI letter covered why exit planning has become a supervisory expectation rather than a contracting nicety - the regulator's finding that entities were "heavily dependent on a single AI system provider... with no substitution or exit strategy that had actually been tested," and CPS 230's material-service-provider obligations, in force since 1 July 2026. That piece answered the question procurement committees ask first: do we need one of these. This piece answers the question they ask second, usually while staring at a vendor contract with an exit clause that reads "the parties will cooperate in good faith to facilitate an orderly transition" and nothing else: what is actually supposed to be in it.

That single sentence is the exit plan in most BFSI AI contracts today. It is not a plan - it is a hope, dressed in legal language. A real exit plan is a document with named owners, specific formats, dated obligations, and a cost allocation, closer in spirit to a disaster recovery runbook than to a termination clause. The discipline for building one already exists; it has lived in outsourcing law and business continuity management, not in AI procurement. Firms advising on technology outsourcing exits have made the point for years: "the best time to plan for exit is at signing" (Hunton, 2026), because that is the only moment the customer still has leverage. Once a bank is dependent on a model for underwriting or fraud scoring, the vendor holds the pen.

What follows is the component-by-component anatomy - what a plan needs to contain to survive contact with an actual exit, not just an audit.

The Seven-Part Exit Anatomy

source[code] proposes seven components, each independently testable and independently absent from most current contracts.

1. Data and artifact portability - four categories, not one. Most contracts address "customer data" and stop there. A workable AI exit clause separately covers: customer data itself (ownership retained, provider use limited to service delivery); customer-created artifacts - prompts, prompt libraries, workflows, evaluation datasets, retrieval indexes, embeddings, and guardrails built up over the life of the engagement; the outputs generated for the business, with usable rights beyond the vendor relationship; and the provider's own return-and-deletion obligation, including written certification of deletion before final payment clears (Morgan Lewis, 2026; InformationWeek, 2026). Institutions that only negotiate the first category discover, mid-exit, that the second and third - the tuned prompts, the retrieval index, the evaluation harness built over eighteen months - belong to the vendor by default.

2. Model and workflow substitution deliverables. Proprietary models frequently cannot move at all - the weights are the vendor's IP. The exit plan has to specify what stands in for the model: exported training and fine-tuning datasets, prompt libraries and system instructions, evaluation datasets and their results, performance logs and telemetry, and documented workflow configurations (Morgan Lewis, 2026). Without these, a "portable" contract is portable in name only - there is a right to leave and nothing to carry with you. One reviewer of live AI exits put the stakes plainly: if the agents and workflows cannot move between platforms, the loss is comparable to losing an entire team's institutional knowledge (InformationWeek, 2026).

3. Transition assistance as a binding service, not a courtesy. "The parties will cooperate in good faith" is not a service obligation - it has no scope, no deliverable, and no price. A real transition assistance clause specifies the incumbent's express obligations: technical and operational knowledge transfer, support for data export and migration, configuration documentation handover, and cooperation with the replacement vendor's integration and identity-management work, ideally with pre-negotiated rates or bundled hours so the incumbent cannot price the transition punitively once notice is given (Morgan Lewis, 2026; Hunton, 2026).

4. Defined timelines, not open-ended "reasonable" periods. Specify concrete deliverables due within defined windows - commonly 90 to 180 days - rather than a generic transition period (Morgan Lewis, 2026). Critically, the clock on exit needs to start well before the contract's stated notice period: practitioners handling live AI exits recommend beginning the exit process 90 days before intended termination, not 30, specifically to get ahead of auto-renewal clauses and vendor-side model deprecation timelines that can otherwise force a rushed migration (InformationWeek, 2026).

5. Cost allocation, fixed at signing. Exit services need pricing decided before either party has leverage to distort it - a fixed exit-services charge or an agreed pricing methodology set at contract signing, not negotiated under the time pressure of an actual departure (Hunton, 2026).

6. Activation triggers, mapped beyond vendor failure. Most contracts frame exit as something that happens only if the vendor defaults. A working plan defines a wider set of triggers that activate it: contract expiry, a decision to insource or switch suppliers (Hunton, 2026), and - for AI vendors specifically - model deprecation or material retraining, a change of control or acquisition of the vendor, a pricing change outside pre-agreed bands, and security incidents. Broader ICT exit-strategy guidance built for regulated entities frames the same idea: provider insolvency, major data breaches, regulatory non-compliance, and service degradation are all distinct triggers, each with a different exit path and different urgency (Panorays, 2026).

7. Rehearsal - the component almost no one has. Every component above can be present in a contract and the exit can still fail in practice, because nothing has actually been run. This is the component covered in the next section.

How You Actually Rehearse An Exit Without Breaking Production

Business continuity management solved this problem before AI vendors existed, and the solution transfers directly. ISO 22301 treats testing as a standing requirement of the management system, not a one-time deliverable - its Plan-Do-Check-Act structure includes, explicitly, "test business continuity plans and monitor outcomes" as an ongoing "Check" activity (BSI, 2026). The same logic applies to an AI vendor exit plan: a document nobody has exercised is a hypothesis, not a capability.

Three ways to test that do not require pulling the plug on a production vendor:

Tabletop exercises. Walk a cross-functional group - procurement, risk, the business owner, technology - through a specific trigger scenario (the vendor is acquired by a competitor; the model is deprecated with 60 days' notice; pricing jumps 40% at renewal) and have them work through the plan's actual steps: who requests the data export, in what format, who validates it, who signs off that the substitute model or process meets the same accuracy bar. ICT exit-strategy guidance for regulated entities recommends these run at least annually or after any significant change to the vendor relationship, with post-exercise reviews that feed back into the plan (Panorays, 2026).

Shadow-run a replacement path. For higher-materiality AI use cases, stand up the fallback - a secondary vendor, a manual process, an in-house model - and run it in parallel against live inputs without it making live decisions, for at least one operating cycle, before treating it as validated. Practitioners advising on AI vendor transitions describe exactly this pattern: "shadow-run replacements for one cycle before decommissioning" the incumbent (InformationWeek, 2026). This is the AI-era equivalent of a disaster recovery failover test - it proves the fallback works under real data volume and real edge cases, not just in a sandbox.

Dependency mapping as a standing artefact, not a crisis-time exercise. The single most common reason cited for exit failures is sequencing: "most exits fail because the dependency map wasn't built first" (InformationWeek, 2026). A dependency map - which downstream systems, decisions, and staff processes rely on this vendor's output - should exist and be current before any trigger fires, not be assembled after notice is given. Maintaining it costs a few hours per quarter for a material vendor; building it from scratch during an actual exit costs weeks the transition timeline may not have.

None of this requires disrupting the live service. Tabletop exercises use no production capacity at all; shadow-runs use spare capacity by design; dependency mapping is documentation work. The cost is calendar time and cross-functional attention - which is precisely why it does not happen without a deliberate governance cadence forcing it.

The Counterpoint: Not Every Vendor Earns This Treatment

Building all seven components and rehearsing them annually is a genuine cost - in negotiation time at signing, in ongoing documentation discipline, and in calendar time for tabletop and shadow-run exercises. Applied indiscriminately across a vendor estate, it becomes the kind of compliance theatre that erodes credibility with the business units who have to resource it.

The proportionality test is materiality, not novelty. A vendor supplying an internal document-summarisation tool with no customer-facing decision authority and easy substitutability does not need a rehearsed exit plan with quarterly dependency mapping - a documented, lightly-tested version of components one through six is proportionate. A vendor embedded in credit decisioning, claims triage, or fraud scoring - the kind of use case APRA's letter singled out for concentration risk - earns the full seven, rehearsed annually, because the cost of an untested exit failing under pressure (a 48-hour manual fallback that turns out not to work, a data export in a format nobody can actually load) falls on customers and the institution's regulatory standing, not just on a budget line. The judgement call procurement and risk need to make jointly is which category each AI vendor sits in - and to make it explicitly, in writing, rather than by default because nobody asked.

The source[code] Perspective

We see the same pattern across most BFSI technology estates we work with: exit clauses exist, but they were drafted against a template that predates AI-specific portability problems like model weights, tuned prompts, and evaluation harnesses.


The fix is not more contract language - most institutions already have enough words in their termination clauses. The fix is treating exit as an operational capability with an owner, a rehearsal cadence, and a materiality-based investment decision, the same way institutions already treat disaster recovery.


Vendors that resist naming a transition-assistance scope or pricing exit services up front are telling you something about how the relationship will go if you ever need to leave.


Contact us for a 45-minute session with procurement and risk present.

Conclusion

The distance between "we have an exit clause" and "we have an exit plan" is the distance between a sentence and seven components: data and artifact portability across four categories, substitution deliverables for the model itself, binding transition assistance, defined timelines, fixed cost allocation, a full set of activation triggers beyond vendor failure, and - the component almost everyone skips - rehearsal. Business continuity management settled the rehearsal question two decades ago: an untested plan is a document, not a capability. For AI vendors specifically, the portability question is harder than it was for traditional SaaS, because the artefact worth protecting is not just the data but the tuned, evaluated, institution-specific configuration built on top of someone else's model.


Getting the anatomy right at signing, and proportioning the investment to what each vendor actually does, is the difference between an exit that takes 90 planned days and one that takes six chaotic months.

Frequently Asked Questions

What are the essential components of an AI vendor exit plan? Seven: data and artifact portability (across customer data, customer-created artifacts, outputs, and provider deletion obligations), model/workflow substitution deliverables, binding transition assistance, defined timelines (typically 90-180 days for specific deliverables), fixed cost allocation agreed at signing, a full set of activation triggers, and a rehearsal mechanism (Morgan Lewis, 2026; Hunton, 2026).

Why can't you just port the AI model itself when you exit a vendor? Proprietary model weights are usually the vendor's IP and do not transfer. The workaround is specifying substitute deliverables in the contract - exported fine-tuning datasets, prompt libraries, evaluation datasets and results, telemetry, and workflow documentation - so a replacement vendor or in-house team has something to rebuild from (Morgan Lewis, 2026).

How far in advance should an AI vendor exit process start? Practitioners handling live AI vendor exits recommend starting 90 days before the intended termination date, not the 30 days many contracts' notice periods assume, specifically to get ahead of auto-renewal clauses and vendor-side model deprecation schedules (InformationWeek, 2026).

What should trigger an exit plan besides vendor default? Contract expiry or a decision to insource (Hunton, 2026); for AI vendors specifically, model deprecation, a change of control at the vendor, pricing changes, and security incidents. Broader ICT exit-strategy guidance frames insolvency, major data breaches, regulatory non-compliance, and service degradation as distinct triggers each warranting a different response (Panorays, 2026).

How do you test an exit plan without disrupting a live production vendor relationship? Three non-disruptive methods: tabletop exercises walking a cross-functional team through a specific trigger scenario; shadow-running a replacement path in parallel with live inputs for at least one operating cycle before treating it as validated; and maintaining a current dependency map as a standing artefact rather than building one during an actual exit (Panorays, 2026; InformationWeek, 2026).

Does every AI vendor need a fully rehearsed, seven-component exit plan? No. Proportionality should follow materiality - vendors embedded in decisions like credit, claims, or fraud scoring warrant the full anatomy rehearsed annually; lower-risk, easily-substitutable tools warrant a documented but lightly-tested version. The judgement of which category a vendor sits in should be made explicitly, not by default.

Reference List

BSI (2026) ISO 22301 - Business Continuity Management. Available at: https://www.bsigroup.com/en-US/products-and-services/standards/iso-22301-business-continuity-management/ (Accessed: 11 September 2026).

Hunton Andrews Kurth (2026) Outsourcing: Draft the Exit Before You Need It. Available at: https://www.hunton.com/insights/legal/outsourcing-draft-the-exit-before-you-need-it (Accessed: 11 September 2026).

InformationWeek (2026) Tips for Successfully Exiting AI Vendor Contracts. Available at: https://www.informationweek.com/it-management/tips-for-successfully-exiting-ai-vendor-contracts (Accessed: 11 September 2026).

MinterEllison (2026) APRA's AI Letter: A Wake-Up Call for Managing Your Third-Party Suppliers - What Banks and Insurers Must Fix Before Enforcement. Available at: https://www.minterellison.com/articles/apra-ai-letter-third-party-suppliers (Accessed: 11 September 2026).

Morgan Lewis (2026) Building Exit Rights and Portability into AI Deals. Tech & Sourcing @ Morgan Lewis. Available at: https://www.morganlewis.com/blogs/sourcingatmorganlewis/2026/02/building-exit-rights-and-portability-into-ai-deals (Accessed: 11 September 2026).

Panorays (2026) Creating Effective ICT Exit Strategies to Meet DORA Standards. Available at: https://panorays.com/blog/ict-exit-strategies-for-dora-standards/ (Accessed: 11 September 2026).