Exit, Data Return and Deletion Terms in an AI Contract

The moment usually arrives twice. The first time is at signature, when procurement asks you to sign off the data protection schedule and you skim a termination clause promising that customer data will be deleted within thirty days. The second is eighteen months later, when the business has decided to move supplier, the vendor has been acquired, or a model you depend on is being retired — and someone asks you, in writing, to confirm the data is out and gone.

That is when the thirty-day clause stops being adequate. It was drafted for a SaaS application with a database and some file storage. The system you are exiting has prompts and completions in a logging pipeline, embeddings in a vector index, a fine-tuned adapter trained on your documents, an evaluation set built from real customer tickets, a human review queue run by a subcontracted annotation firm, and safety-monitoring records the vendor keeps on its own account. None of that is covered by "delete the data".

Why AI exit is not SaaS exit

Derived artefacts. Deleting source records does not delete an embedding index built from them, and embeddings are not reliably anonymous — reconstruction of underlying text is an active research area, so treat an index as personal data unless you have a specific reason not to. The same applies to evaluation sets, cached responses and feature stores.

Model weights. If the vendor fine-tuned on your data, deleting the training corpus does not remove that data's influence on the resulting weights. Machine unlearning techniques exist, but there is currently no recognised standard or accepted test by which a vendor can prove a model has forgotten a specific record. A contract promising verified removal from a model promises something nobody can presently evidence. What you can contract for is retirement of the fine-tuned artefact itself, plus a warranty of non-use and non-redistribution.

Split roles. A vendor is frequently your processor for the service and its own controller for something else — abuse monitoring, security, aggregate service improvement, statutory retention. Deletion obligations flowing from your instructions reach the first category only. This is the most common gap in signed AI contracts.

Who is responsible for what

Under UK and EU GDPR, where you are the controller and the vendor is your processor, Article 28(3)(g) requires the processor, at your choice, to delete or return all personal data at the end of the provision of services and to delete existing copies, unless Union, Member State or UK law requires retention. The choice between return and deletion is yours, so a clause hard-coding deletion has already narrowed your rights; and while performance is the processor's obligation, accountability for confirming it happened is yours. Continued retention without a lawful basis is a storage limitation problem under Article 5, which sits in the higher enforcement tier of up to 4% of global annual turnover.

Where the vendor processes for its own purposes it is a controller in its own right, and your Article 28 instructions do not bind it; those terms must be negotiated separately. Note also that the EDPB has addressed whether AI models trained on personal data can be regarded as anonymous; the answer is case-by-case, not automatic.

Under the EU AI Act the split is provider versus deployer. If you use a high-risk system supplied by someone else, you are the deployer: Article 26(6) requires you to keep the automatically generated logs under your control for a period appropriate to the purpose and at least six months, unless other Union or national law provides otherwise. The provider has a parallel duty under Article 19, and must keep technical documentation and the EU declaration of conformity for ten years under Article 18. So a clause that deletes everything on day thirty can put you in breach of a retention duty — sequence deletion after retention, not before. Obligations of this kind carry penalties of up to 3% of global annual turnover. Watch Article 25 too: put your own name on a system, substantially modify it, or change its intended purpose so it becomes high-risk, and you become the provider with the longer documentation duties.

Under ISO/IEC 42001, nobody external audits your vendor. The certification body audits your AI management system against the standard and against what you yourself wrote down. Exit surfaces there as a supplier control claimed in your Statement of Applicability, a documented procedure you must show you followed, a risk assessment updated when the arrangement ended, an internal audit sample, and an item management review considered. Annex A includes controls addressing third-party relationships and the management of data used in AI systems; check the current text for exact references rather than relying on a summary. If your SoA claims a supplier exit control and you cannot produce a record of exercising it, that is a nonconformity requiring correction, root cause analysis and corrective action.

The artefact map

Artefact	What "delete" realistically means	Evidence to require
Production records	Hard delete, not soft-delete flags	Signed certificate naming systems and dates
Backups and snapshots	Expiry on the normal rotation cycle	Stated retention period and a no-restore-to-live undertaking
Prompt and completion logs	Deletion, but check who controls the pipeline	Log inventory and retention settings taken before exit
Embeddings and vector indexes	Index and replica deletion; treat as personal data	Confirmation the index and its replicas are dropped
Fine-tuned weights and adapters	Artefact retirement, not removal from the base model	Warranty of non-use and non-redistribution
Evaluation and test sets	Routinely overlooked; often real customer data	Named list of datasets derived from your data
Human review and annotation	Held by subcontractors, sometimes offshore	Sub-processor list and flow-down deletion confirmations

What to negotiate before you need it

• Return or deletion at your election, exercisable more than once, and available on suspension or dispute as well as termination.
• A defined export format and completeness standard, plus a test export during the term — not a promise of "reasonable assistance".
• A transition assistance period continuing after termination at a pre-agreed rate, including where you terminate for the vendor's breach.
• An artefact schedule listing every derived asset, updated whenever a new capability is switched on.
• Express treatment of fine-tuned weights: ownership, retirement, non-use, and what happens on acquisition or insolvency.
• Deletion by sub-processors, with flow-down obligations and a right to the confirmations they give the vendor.
• Separate terms for the vendor's own-controller processing, which you cannot instruct away.
• A retention carve-out for logs and documentation you must legally hold, requiring the vendor to preserve rather than destroy them.
• Deletion certification within a fixed period, signed by an identified officer, listing systems, artefact types and dates.
• Survival of confidentiality, audit and data protection terms past termination, so the certificate is enforceable.

Limits, and when to take advice

Several things here are genuinely unsettled. There is no agreed technical method for verifying that a model has forgotten specific data. Harmonised standards under the EU AI Act and parts of the implementing framework are still being developed, so some obligations will be clarified after your contract is signed — build in a change-of-law mechanism. Certification bodies apply their own audit procedures within the accreditation rules, so confirm expectations with yours rather than assuming.

Take specialist advice where exit involves insolvency or acquisition of the vendor, where intellectual property in fine-tuned weights or outputs is contested, where restricted or onward transfers by sub-processors are in scope, or where sectoral rules apply. Financial entities in scope of DORA, for example, must maintain exit strategies for ICT arrangements supporting critical or important functions, and regulated firms may carry outsourcing notification duties on top. The general shape of a good exit clause is well understood; the consequences of a bad one are specific to your sector, your data and your counterparty.