Can a customer make you pull their data from a license after delivery?

Where a customer's right to pull data comes from#

A customer's right to have its data pulled from a license comes from one of three places: its contract with you, privacy law protecting individuals in the records, or the license itself. Without one of these, a removal request may be a relationship question rather than a legal obligation, though it can still matter a great deal. Counsel decides which it is, request by request.

Corporate customers usually rely on contracts. Master service agreements, data processing addenda and NDAs can define the customer's information as confidential, limit its use to providing the service, or require return and deletion on request. Individuals inside the records, such as a customer's staff who wrote tickets, may hold privacy rights of their own.

Read the signed paper, not your template. Large customers often negotiated their own data clauses, and those negotiated versions are the ones that bind you.

What removal can and cannot reach after delivery#

Removal after delivery can usually reach copies of records the buyer still holds and anything not yet sent, but it rarely reaches what a model has already learned. The table shows how the practical limits change as data moves through a buyer's process.

This is why the timing of an objection matters so much. An objection raised before delivery costs a filter; the same objection after a training run may only be answered with a promise about the future.

Contract levers that make post-delivery removal workable#

Contract levers decide whether a post-delivery removal request becomes a routine task or a dispute. They belong in the license before signing, because a buyer has little reason to accept them afterward.

• 1Exclusion list: a named schedule of customers whose records are never included, which the supplier can update for future deliveries.
• 2Future-delivery exclusion: a right to remove any customer from refreshes and later deliveries on written notice.
• 3Deletion on notice: the buyer deletes identified raw records and derived datasets it controls within an agreed period and certifies it in writing.
• 4Forward-use limit: removed records are not used in training runs that start after the notice.
• 5Record identifiers: stable IDs on every delivered record so specific items can be found and removed.
• 6De-identification warranty: the supplier confirms personal and confidential details were removed to an agreed standard.
• 7Survival: deletion and use limits continue after the license ends.

Why de-identifying first prevents most removal fights#

De-identifying records before delivery prevents most removal fights, because a customer usually objects to being recognizable rather than to the existence of anonymous support conversations. If a ticket thread no longer shows the company name, its contacts, its account numbers or its product configuration, there is often nothing a reasonable reader would tie to that customer.

Names are not the only giveaway. A unique part number, a distinctive custom integration, a city paired with a niche industry, or a quoted contract amount can identify a customer as clearly as its name. Preparation should hunt for these indirect identifiers in free text and attachments.

De-identification does not replace contract review. Some agreements restrict use of all information received from the customer, identifiable or not, and those records should be excluded rather than cleaned.

Illustrative: a vertical SaaS company and an objecting customer#

Illustrative: a fictional vertical software company serving property managers licensed de-identified Intercom conversations and linked Jira issues. After the first delivery, one of its largest customers heard about the program and asked to be removed.

The general counsel pulled that customer's negotiated MSA, which limited use of customer data to providing the service. The records had been de-identified, but the agreement still restricted use. Fortunately, the license included stable record IDs, a future-delivery exclusion and a deletion-on-notice clause for raw records.

The company added the customer to the exclusion list, sent the buyer the affected record IDs and received a written deletion certificate for raw copies. The buyer confirmed the records would stay out of later training runs. The customer accepted that outcome, and the program continued without its records.

Handling a removal request when one arrives#

A removal request is handled best with a fixed sequence, so the response is fast and consistent no matter who in the company receives it first.

Keep the request, the contract analysis, the buyer's certificate and your reply together with the delivery records. If the same customer asks again, or a regulator or auditor later asks how objections were handled, that file answers the question without anyone relying on memory.

• 1Log the request with the date, the requester and the scope they describe.
• 2Read the customer's contract, DPA and any NDA for data-use, confidentiality and deletion terms.
• 3Find the customer's records in every delivered package using record IDs and the delivery log.
• 4Decide with counsel whether the request is a legal obligation, a contract right or a goodwill accommodation.
• 5Invoke the license's removal or deletion clause in writing and ask for certification.
• 6Add the customer to the exclusion list for all future deliveries.
• 7Reply to the customer in writing, stating what was removed and what cannot be undone.

How SourceX approaches customer exclusions#

SourceX handles customer exclusions in the Rights step of the SourceX five-step transaction, before Preparation begins, so excluded customers are filtered out rather than chased later. The supplier approves the exclusion list and the final scope.

The SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each delivery. That record is what makes it possible to answer, long afterward, exactly which records went where.