AI Vendor Offboarding Checklist: Leaving Without Losing

Leaving an AI vendor is harder than leaving ordinary software, because the data includes history you cannot recreate. This checklist covers exiting cleanly, drawn from FISTA Solutions' AI enablement governance work.

What has to come back?

Six categories, in order of difficulty to replace.

Category	Replaceability
Evaluation cases and results	Irreplaceable
Labelled data and corrections	Irreplaceable
Audit trails	Irreplaceable and legally required
Configuration and prompts	Rebuildable with effort
Operational knowledge	Lost when the team disperses
Integration code	Usually yours already

Before notice is given

Do this while cooperation is easy. See the future of AI procurement.

• Contract reviewed for export, transition, and post-termination terms
• Notice period and its implications understood
• A full export requested and completed as a test
• Export format assessed for whether it is actually usable
• Gaps in the export identified and raised while leverage exists
• Transition assistance provisions confirmed
• A replacement plan sketched with a realistic timeline

Data export

Export everything, then verify it is complete and readable.

• Evaluation cases, criteria, and historical results exported
• Labelled data and human corrections exported
• Configuration, prompts, and routing rules exported
• Conversation or interaction history exported
• Metadata and relationships preserved, not flattened
• Export verified by loading it somewhere and querying it
• A second export taken close to the termination date

Audit trails and records

Your obligations outlast the contract. See the coming audit of AI systems.

• Decision records exported for the full retention period you require
• Records stored in a system you control with equivalent protection
• Retention period confirmed against your policy and obligations
• Record format documented so it remains interpretable
• Ability to answer a query about a past decision tested
• Legal consulted on what must be retained and for how long
• Access controls applied to the retained records

Access and credentials

Both directions, and verify rather than assume.

• Vendor access to your systems identified and revoked
• Service accounts created for the vendor disabled
• Network access rules removed
• Your credentials in their system rotated or deleted
• API keys and tokens revoked and confirmed non-functional
• Single sign-on integration removed
• Revocation verified by attempting access, not assumed

Deletion and confirmation

Ask in writing and keep the answer. This is general guidance, not legal advice.

• Deletion of your data requested formally in writing
• Scope of deletion specified including backups and derived data
• Whether your data trained their models clarified and addressed
• Subprocessor deletion confirmed, not just the primary vendor
• Deletion certification obtained and filed
• Retention exceptions the vendor claims documented
• Timeline for deletion agreed and followed up

Knowledge transfer

The part no export contains and the part most often lost.

• Configuration decisions documented with their reasoning
• Known edge cases and workarounds recorded
• Past incidents and their resolutions captured
• Operational runbooks obtained or reconstructed
• Handover sessions held with the vendor's operating team
• Your own team has run the system before the vendor leaves
• Open issues and their status documented

What are the most common failures?

Requesting export after giving notice. Verifying export by file size rather than by loading it. Revoking one direction of access. No deletion certification. And losing operational knowledge because handover was a document rather than a period of shadowing.

Who should own this?

The business owner of the system, with procurement handling contractual steps and engineering handling export and revocation. Offboarding owned solely by procurement misses the technical and knowledge dimensions.

How often should it run?

Per vendor exit, plus an annual test of the export path for any vendor holding data you could not recreate. An export you have never tested is an assumption.

What evidence should it produce?

Verified exports with load confirmation, revocation verification, deletion certification, and handover records. That set demonstrates the exit was controlled rather than abandoned.

What if the vendor is uncooperative or fails?

A vendor in distress or in dispute may not cooperate, which is why routine exports matter more than exit clauses.

If you hold a recent export and your own audit records, an abrupt termination is survivable. If you rely on the vendor to produce them at the point of exit, you may not get them. Test the export path annually. See AI third party risk checklist.

What should you do first?

Request a full export from your most critical AI vendor today and try to load it. Whatever is missing is what you would lose.

How FISTA Solutions helps

FISTA Solutions builds and operates production AI systems through AI agents, AI enablement, and forward deployed engineering: exports tested by loading them rather than by file size, and operational knowledge captured through shadowing rather than handover documents, decisions documented with their reasoning, and handover that leaves your team able to maintain what was delivered. The record is 150+ projects for 50+ companies across 12+ countries.

To adapt this checklist to your environment, message FISTA on WhatsApp, or read AI third party risk checklist.