How should you review the deletion standard in an AI product contract? This checklist includes a sample clause and the drafting issues raised by each sentence. This language is not a model provision. It’s included for illustrative purposes to highlight common problems with deletion provisions.
1. Background
A deletion clause in a contract for an artificial intelligence product sets the standard the vendor must meet, the method it uses, and what happens when it says deletion is not technically feasible. Customers have three levers in a short clause: the deletion standard, timing, and certification. The problematic sentences below address the deletion standard, the method, and the de-identification fallback one at a time.
2. PDF Download
Here is the link to download the PDF version of this checklist.
3. Sample Language (Illustrative, Not Model Provision)
FLAWED LANGUAGE TO ILLUSTRATE ISSUES. DO NOT USE.
“Provider shall use commercially reasonable efforts to delete Customer Data from all systems within the timeframe specified in Section 8.2. Deletion shall be performed in accordance with Provider’s standard data management practices. Where deletion of specific data elements is not technically feasible, Provider shall de-identify such data so that it can no longer be associated with Customer.”
A. Commercially Reasonable Efforts
“Provider shall use commercially reasonable efforts to delete Customer Data from all systems within the timeframe specified in Section 8.2.”
Striking the Efforts Qualifier. Delete use commercially reasonable efforts from the sentence as the customer. The sentence then reads that the provider shall delete customer data, which is a firm obligation.
Commercially Reasonable Versus Best Efforts. Compare the two efforts standards before you accept either, and note that case law addresses both. A best efforts standard makes the vendor keep working at the deletion whether or not it costs money. A commercially reasonable standard lets the vendor decide the deletion costs too much and skip it.
Control on the Cost Judgment. Add a control for when deletion becomes commercially unreasonable. Without one, a person inside the vendor’s business makes that call, and may make it subjectively.
All Systems and Backup Copies. Ask the vendor which systems all systems covers. Put guardrails on any carve-out for backups, residual copies, and archival copies, including limited retention, logical separation, no active processing, and automatic purging on the backup rotation cycle. A backup carve-out without those guardrails can become a backdoor to indefinite retention.
B. Standard Data Management Practices
“Deletion shall be performed in accordance with Provider’s standard data management practices.”
The Vendor’s Internal Standards. Avoid accepting the vendor’s internal standards as the deletion method. The vendor commits only to what it already does. It can change that internal standard tomorrow.
A Named External Certification. Ask whether the vendor holds SOC 2 or ISO certification. Point the deletion obligation at a published standard the customer can check, rather than at a practice the vendor sets for itself.
The Practices on a Schedule. Ask the vendor to attach its standard data management practices to the contract as a schedule. Read the schedule and confirm those practices meet your own deletion standard.
Commitment to an Existing Plan. Confirm the vendor commits in the contract to follow the disaster recovery plan or security document it gave you during diligence. Handing over a document is not a promise to comply with it.
Deletion to a Legal Standard. Require the vendor to render the data completely deleted, in line with the laws on data destruction. The deletion standard is one of the levers a customer has in a short clause. Timing and certification are the other two.
C. Not Technically Feasible
“Where deletion of specific data elements is not technically feasible,”
Specific Data Elements. Ask the vendor which data elements this phrase covers in its systems. The phrase is vague on its own, so ask for the categories the vendor has in mind.
Who Decides Technical Feasibility. Ask who decides that deletion is not technically feasible, and what standard that person applies. Ask whether disruption to the vendor’s systems, or harm to its other customers, counts as infeasible. A vendor may prefer to leave these details out of the contract.
The Reason Deletion Fails. Ask the vendor to explain exactly why it cannot delete the data. Press harder for that explanation as the data becomes more sensitive.
Extraction From a Trained Model. Ask the vendor how it removes your data from a model it has already trained. Deletion was simpler when the vendor put the data in a database and deleted the records. This question drives the remedy discussion when the vendor has trained on your data without permission.
D. De-Identifying Instead of Deleting
“Provider shall de-identify such data so that it can no longer be associated with Customer.”
Permitting the Fallback. Decide whether you allow the vendor to de-identify data in place of deleting it at all. Tie the answer to the volume, nature, and sensitivity of the data at issue.
The Level of De-Identification. Ask the vendor how far its de-identification goes where you allow the fallback. Consider writing a stronger de-identification standard into the contract. State what the vendor may then do with the de-identified data.
Audit Rights Over Deletion. Ask for an audit right so you can confirm the vendor deleted the data to your standard. Tracing your data back to a specific system may no longer be possible, so the contract control does that work.
