Does deleting customer data remove it from your AI training sets?

Short answer: datasets yes, models rarely#

Deleting customer data removes it from AI training sets only when the sets are rebuilt from live source records or purged by a lineage-driven job. A static snapshot copied into a training bucket keeps the data until someone deletes that snapshot as well.

A model trained on the data is a different matter. Its weights do not hold records in a form you can find and remove, and machine unlearning research has not yet produced methods most SaaS teams can rely on to erase one customer's influence. The practical options are to retrain or fine-tune again without the data, or to retire the model version.

The distinction matters because customers rarely ask about models in those words. A request to delete our data, including from AI features, covers both, so the answer has to separate what is purged now from what changes at the next model version.

Where customer data hides after deletion#

Customer data survives deletion in every copy the pipeline made along the way. Production deletion is usually well understood; the derived copies are where promises fail.

What published vendor practices show#

Published vendor practices show that derived copies can be tied to deletion when the pipeline is designed for it. Notion, for example, commits to removing the vector embeddings derived from a page or workspace within 60 days of that page or workspace being deleted, which treats a derived artifact as part of the customer's data rather than the vendor's.

Backups usually lag behind. Greenhouse's security overview says database backups are kept for 30 days and a deleted record is purged on the 31st day, with remnants of a departing organization's data persisting until backups expire. A deletion promise that ignores backup windows overstates what actually happens.

How to build a training pipeline that can honor deletion#

A training pipeline can honor deletion when every example carries its origin and every dataset can be rebuilt. The work is mostly bookkeeping, and it is far cheaper to add before the first model ships than after.

• 1Tag every training example with tenant ID, source record ID and extraction date.
• 2Keep a manifest for each dataset version listing the tenants that contributed to it.
• 3Rebuild datasets from source on a schedule instead of appending to old snapshots.
• 4Register each model version with the dataset versions it was trained on.
• 5Run deletion jobs that purge by tenant across the lake, feature stores and vector indexes.
• 6Set a retraining or retirement rule for models trained on a departed customer's data.
• 7Log each deletion run so the customer's request can be evidenced later.

Options when a departing customer's data was used for training#

A departing customer whose data was used for training leaves the vendor with a handful of options, each with a trade-off. Choose the default in advance and write it into the DPA, so the answer is ready before anyone asks.

What to promise in contracts and offboarding#

Promises about AI training data in contracts and offboarding should match the pipeline exactly. A DPA can commit to deleting customer data from training datasets within the deletion period, while stating that models already trained are retrained or retired on a defined cycle rather than edited.

Some vendors sidestep the problem by never training on customer content, or by training only on content from customers who opted in. Others train only on aggregated or de-identified data, which reduces the deletion question without removing it. Individuals may also hold deletion rights under the GDPR or US state privacy statutes that reach training data; how those rights apply to trained models is unsettled and worth reviewing with counsel.

Illustrative: a help desk vendor builds a deletion-ready pipeline#

Illustrative: a fictional help desk software vendor trains a reply-suggestion model on tickets from customers who opted in. A large customer leaves and asks for full deletion, including from AI features.

The vendor's manifests show which dataset versions included the customer's tickets. A deletion job purges those tickets from the lake, the vector index and the evaluation set, and backups expire on their normal schedule. The current model was trained on the data, so the vendor confirms in writing that it will be replaced at the next scheduled retraining, exactly as its DPA describes.

When the customer's security team asks for evidence, the vendor sends the deletion log, the list of dataset versions purged and the retraining date. The request closes without escalation, because the DPA, the trust page and the written confirmation all say the same thing.

Why lineage matters when you license records too#

Lineage matters just as much when a software company licenses its own records to an AI developer. In the SourceX five-step transaction, Preparation removes personal and confidential details before delivery, and the SourceX Evidence Packet records provenance and the privacy record, so the company can show which source records went into each licensed package and answer a later deletion question with facts.

License terms can also set what the licensee must do if identifiable records were delivered and a deletion request arrives later, which is one more reason to de-identify before delivery.