How to build an exit plan for an AI vendor

Why an exit plan belongs in the contract, not the crisis

Companies usually start thinking about an exit plan for an AI vendor only once the vendor announces the end of a service, changes its terms significantly, or an outage runs longer than the business can absorb. By that point there is no time left to negotiate an export format, and no time to check what the contract actually allows. This method instead orders the steps chronologically, by the point at which each one can still be influenced.

It splits into four phases: what to agree before signing, what to keep current during normal operation, the order of steps after you give notice, and how to confirm the switch is genuinely finished. An exit plan sits close to the same vendor relationship covered in managing a budget across multiple AI tools, just worked from the opposite direction. A separate section near the end covers what changes when the vendor, not you, decides the timing: through a shutdown, an acquisition, or a change of terms.

Phase 1: what to agree before you sign

The items below belong in contract negotiation, while your operational dependence on the vendor is at its smallest.

Item	What to get described in writing	Why companies usually miss it
Export format and schema	the specific format, plus a documented structure of fields and the relationships between them	without a schema description, someone has to reverse engineer the structure by hand at every migration
Export frequency	whether a full or incremental export can be requested at any point during the contract	export only gets addressed after notice is given, when it is slowest and most expensive
Who holds the credentials	which named roles have administrator access and can run an export without the vendor’s cooperation	access often sits with one person or an outside consultant who has since left
Notice periods	the length of notice for both sides, and the difference between notice without cause and termination for breach	a short notice period may not leave enough time for the steps in Phase 3
Fate of fine-tuned models and stored prompts	whether a fine-tuned model and a prompt library stay portable, or remain tied to the vendor’s platform	portability only gets raised on the way out, when there is no leverage left to change it
Price of assisted migration	whether and on what terms the vendor provides paid cooperation, roughly in line with what deploying an AI tool actually costs elsewhere	without agreeing this in advance, the price gets negotiated under deadline pressure
Deletion confirmation and its form	what form of confirmation the vendor provides on request, and within what timeframe	without an agreed form, you have nothing to file in your own records

The deletion question connects to how the vendor processes data in its role as a processor under GDPR, a question that also comes up when deciding whether company data is safe to put into a tool like ChatGPT in the first place. Whether a specific contract clause actually delivers on that requirement is something your own counsel needs to assess against the wording used.

Phase 2: what to keep current so an exit is actually possible

The agreement from Phase 1 does not make an exit possible on its own without three operational habits, otherwise it stays a clause that only activates too late.

A recent, verified export. It is not enough that an export happened once during onboarding. Exported data needs to be opened and checked periodically against the agreed schema, the same logic that applies to backing up company data generally: a backup that has never been tested is only a promise.

A current list of integration points and their owners. Which system, workflow or recurring process reads data from the vendor or sends data to it, and who on the team is responsible for that connection. Without this list, dependencies only surface once something breaks after notice has already been given.

A note of which business processes would stop. A short, regularly updated note of what would stop working today if access to the vendor disappeared without warning. It serves as a fast, rough estimate of severity, alongside a formal risk assessment rather than instead of one.

Keeping this kind of dependency documentation current sits inside ongoing risk management under the NIST AI Risk Management Framework as well, specifically its Govern and Map functions.

Phase 3: the order of steps after you give notice

The order is not optional. The most common mistake when leaving an AI vendor is a step taken out of sequence, typically a deletion request sent before the replacement has been verified in production.

Step	What to do	Cannot start until…
1. Confirm the calendar	get the last day of access and the notice period from Phase 1 confirmed in writing	notice has been given or accepted
2. Run a fresh full export	run and download an export against the schema from Phase 1, even if a tested export from Phase 2 already exists	the calendar is confirmed, so the export can be scheduled with margin
3. Check the export against the integration list	verify the export contains everything the Phase 2 list marks as dependent on the vendor	the export from step 2 has been downloaded and opened
4. Pause or redirect integrations	pause or redirect, on a controlled schedule, the processes identified in step 3	the check from step 3 is complete, because without it you do not know what to pause
5. Verify the replacement	run and verify a new tool or a temporary manual process against the exported data	the integrations from step 4 have been paused or redirected
6. Settle assisted migration billing	settle the cost of the vendor’s cooperation under the term agreed in Phase 1	the replacement from step 5 has been verified in production
7. Request data deletion	request deletion in writing, and the confirmation in the form agreed in Phase 1	the replacement from step 5 is running verified and billing from step 6 is closed
8. Revoke credentials	invalidate or rotate credentials and close the account, a step that belongs alongside wider practice on securing AI use across the enterprise	the deletion request from step 7 has been sent, because revoking access earlier can block a follow-up export

The key dependency sits between steps 5 and 7: requesting deletion at the departing vendor comes only after the replacement is verified, because it is the one step you cannot undo if a gap later shows up in the replacement.

Phase 4: how to know the exit is actually finished

• Exported data has genuinely been opened and used in the target environment, not just downloaded into a folder.
• Every item on the Phase 2 integration list is marked migrated, paused, or knowingly abandoned.
• The deletion request has been sent, and any confirmation is dated and filed in your own records.
• The assisted migration bill matches what was agreed before signing, or the difference is documented.
• No access key, webhook or login credential still points at the departing vendor.
• The exit completion date is logged somewhere internal that stays accessible after the people who ran the exit have moved on.

When the switch is not your choice

The Phase 3 sequence still applies when a vendor ends a service, changes terms significantly, is acquired, or an outage stops being temporary. What changes is who sets the pace, and what is actually available to you.

The calendar in step 1 is no longer yours to negotiate: the vendor, an insolvency administrator, or a new owner announces it, and the notice period is typically shorter than Phase 1 assumed. Assisted migration in step 6 may not be available at all if the vendor is winding down or a new owner has different priorities. Step 2, a fresh export, often cannot happen because access disappears before its turn comes; the process then effectively starts at step 3, working from the last tested export from Phase 2. This is the main reason Phase 2 puts weight on ongoing preparation: it is the difference between having some starting point and having none.

The deletion request in step 7 may need to go to a different party than the one you signed with, such as an insolvency administrator or an acquirer, and a response or confirmation may not arrive at all. Whether obligations from the original contract genuinely transfer to a new owner or administrator is a matter of interpreting that specific contract and the applicable law, which your own counsel needs to assess.

Sources and limits

This method rests mainly on what a company negotiates into its own contract and keeps current in operation; two sources from the closed library back the legal and risk-management points. GDPR is cited for Article 28 as the general frame for what a processor should do with data once a service ends; the article does not claim that any specific contract clause satisfies that requirement on its own. The NIST AI Risk Management Framework is cited only for the general practice of keeping dependency documentation current as part of ongoing risk management; the framework itself does not prescribe the sequence of steps described here. Nothing in this article states a typical migration length, a typical switching cost, or how often AI vendor relationships end, because the source library has no basis for such figures. Whether a specific contract clause actually secures export, deletion, or portability of a fine-tuned model, and whether obligations transfer to a new owner after an acquisition, are questions for your own counsel to assess against the contract wording. Verifying in depth that a vendor deleted data after a request, beyond filing its confirmation, is deliberately outside the scope of this article.