What if a customer objects after their data was licensed?

What happens legally when a customer objects to a data license?#

A customer objection starts a review of your rights; it does not automatically mean the license was a breach. The answer turns on what the customer agreement permitted when the records were prepared, what actually reached the licensee, and what the data license lets you change after delivery.

For a SaaS company, the objection usually arrives through an account manager or a procurement contact, not through legal. The first job of the general counsel is to get it into one channel, in writing, before sales promises a deletion the company cannot deliver or concedes a breach that did not happen.

Sort the objection before you answer it#

Objection type determines the remedy, so classify each complaint before drafting a reply. Customers rarely use legal language, and the same sentence, such as "we never agreed to this", can mean a contract claim, a privacy worry or simple surprise.

The table below pairs common objections with the first record to pull and the remedy that usually fits. Keep the classification in the matter file; it shows later why the company chose one response over another.

A response playbook for the legal team#

A written playbook keeps the company consistent when the second and third objections arrive. Run the same steps every time, and keep sales and support on scripted acknowledgments until legal has an answer.

Speed matters less than accuracy here. A fast reply that guesses wrong about scope is harder to walk back than a short acknowledgment followed by a precise answer.

• 1Log the objection: who raised it, their authority to speak for the customer, the exact wording and the date received.
• 2Acknowledge in writing that the company is reviewing the concern, without admitting breach or promising deletion.
• 3Pull the delivery manifest and check, by customer and account identifiers, whether any of that customer's records were delivered.
• 4Place the customer on the suppression list immediately so nothing new ships while the review runs.
• 5Read the customer agreement, any order form changes, the DPA and any AI or data-use addendum that applied at preparation time.
• 6Decide the remedy, and if it involves the licensee, send notice under the license using record IDs rather than the customer's name.
• 7Confirm the outcome to the customer in writing, stating what was delivered, what was removed and what will not ship again.
• 8Update customer notices, the internal FAQ and the scoping rules so the same gap does not recur.

Contract terms that make removal possible#

Removal is possible only where terms on both sides of the transaction anticipate it. The customer agreement decides whether the records could be licensed at all, and the data license decides whether anything can be pulled back once delivered.

General counsel should review both columns before the first delivery. A gap on either side leaves the company with goodwill requests instead of enforceable rights.

What a remedy can and cannot reach#

A remedy reaches records the company still controls and records the licensee agreed to give back; it rarely reaches a model that has already been trained. Explaining that boundary early prevents a customer from expecting a result no one can deliver.

Suppression handles the future: the supplier simply stops including that customer's records in any refresh or new package. Stored copies at the licensee are reachable through a removal clause and a deletion certificate. Trained model weights are a different matter: licenses typically address them by limiting future training runs and evaluation use rather than promising to undo past training, and that is the term to negotiate if your customers are likely to ask.

Whatever the remedy, describe it precisely. "Your records will not be included in any future delivery, and the licensee has certified deletion of the copies it held" is an answer a customer's counsel can accept; "we have taken care of it" is not.

Illustrative: a dispatch software vendor answers a large account#

Illustrative: a fictional maker of dispatch software for elevator service companies licensed de-identified Zendesk tickets and linked Jira issues to an AI developer. Several months later, the operations director at one of its largest customers emailed the account manager to say the customer had never agreed to its data training anyone's AI.

The general counsel logged the objection, put the customer on the suppression list and checked the delivery manifest. Tickets from the customer's admins were in the delivery, with company names and contact details removed, and the customer agreement contained a clause allowing de-identified support data to be used for product and service purposes, which did not clearly cover licensing.

Because the clause was ambiguous, the company chose not to argue it. It sent a removal notice under the license using record IDs, received a deletion certificate, and gave the customer a written summary of what had been delivered and removed. It then updated its customer FAQ and added an explicit AI-licensing opt-out to its renewal paperwork.

How SourceX handles objections and removal#

SourceX builds removal into the transaction rather than treating it as an exception. In the SourceX five-step transaction (Supply, Rights, Preparation, Approval, Delivery), the Rights step reviews customer agreements before any record is prepared, and customers whose contracts restrict use are excluded at that stage.

Each delivery is documented in a SourceX Evidence Packet covering provenance, licensing rights, permitted use, the privacy record and release authorization, so a supplier can answer "was our data included?" from a record rather than from memory. Removal and suppression terms are negotiated in the license itself, and the supplier approves every step. Industry provenance metadata points the same way: the Data & Trust Alliance's Data Provenance Standards include fields for consent documentation location and license to use.