Does Your SaaS Vendor Train Models on Your Customer Data?

Does owning your data stop the vendor from using it?

No. Most SaaS agreements state clearly that the customer owns its data, and customers read that and move on. Ownership answers who the data belongs to. What the vendor may do with it is answered by the licence you grant, which usually sits a paragraph or two later.

That licence has to exist, because a vendor cannot host and process your data without permission. The question is scope. A licence limited to providing the service to you is narrow and appropriate. A licence extending to improving, developing or enhancing the vendor's products and services is considerably wider, and it is the standard drafting in many templates.

Indian law does not fill this gap for you. There is no general statute protecting business data as such, and India has no separate trade secrets law, so the protection for your non-personal business information comes mainly from the contract: the licence, the confidentiality clause and the remedies for breach under the Indian Contract Act, 1872.

Where does model training hide in a SaaS contract?

Contracts rarely say 'training a machine learning model' in those words, particularly older ones. The language that carries it is improvement of the services, development of new features, or analytics and product research. Whether that language extends to training a model on your data is a question of interpretation, and a customer who assumed it did not may find the vendor reads it differently.

Three other places deserve a look. The first is the definition of usage data or service data, which the vendor often owns outright; check whether it includes your inputs, prompts, files or outputs, or only technical logs. The second is the feedback clause, which usually gives the vendor unlimited rights over suggestions you make, and can be drafted to sweep in content. The third is the sub-processor list: a vendor may route your data through third-party model providers whose own terms decide whether your data is retained or used.

Newer agreements are more explicit in both directions. Some vendors now state that customer data is not used for model training. Others have added express training rights, sometimes with an opt-out buried in account settings. Either way, the absence of any statement is itself informative.

Reading the clauses side by side

The table below shows typical wording, what it tends to permit, and a narrower alternative to ask for.

What does anonymised really mean?

The common carve-out permits use of aggregated or anonymised data derived from customer data, on the basis that it no longer identifies anyone. That is a legitimate concept and it does real work.

The Digital Personal Data Protection Act, 2023 applies to personal data, meaning data about an individual who is identifiable by or in relation to that data. Data that genuinely cannot identify anyone falls outside it. But the Act does not define anonymisation or set a standard for it, so the contract's own definition carries the weight.

Two things are worth checking. First, what the contract means by anonymised, since the term is used loosely and removing names and email addresses is not the same as making data impossible to link back to a person, especially for detailed records like call transcripts or medical notes. Second, whether the carve-out is drafted so broadly that anything derived from your data qualifies, which turns a narrow exception into a general permission.

The DPDP overlay

Where the data includes personal data, the Act adds a layer. It is built around processing for a lawful purpose, on consent for a specified purpose or for a legitimate use, and Section 8(2) allows a data fiduciary to engage a data processor only under a valid contract.

A processor acts on your behalf for your purposes. A vendor that uses your customers' personal data to train its own models is deciding a purpose of its own, which looks more like acting as a fiduciary for that processing, needing its own lawful basis. It is also hard to square with the notice you gave the individual, who agreed to your service, not to the vendor's product development.

Since you remain responsible under Section 8(1) for processing on your behalf, a broad improvement right is a compliance question for you, not just a commercial one for the vendor. The substantive obligations under the DPDP Rules, 2025 are scheduled to apply from 13 May 2027, so contracts signed now should be aligned.

How do you check what your vendor does today?

• Pull the signed order form and the terms it incorporates, including any online terms, data processing addendum and privacy policy referred to by link.
• Search the documents for improve, develop, enhance, analytics, usage data, service data, aggregated, de-identified, feedback, model and machine learning.
• Read the licence grant to Customer Data first, then the definitions those words point to.
• Open the sub-processor list and note any third-party model or analytics providers.
• Check account or admin settings for a data sharing or model improvement toggle, and record its state with a dated screenshot.
• Write to the vendor with three questions: is our data used to train any model, is it shared with any third party for that purpose, and how can we opt out in writing.
• Keep the reply with the contract, since a written answer from the vendor is useful evidence of how both sides understood the terms.

What to ask for

• An express statement that customer data will not be used to train, retrain or fine-tune any machine learning model without your prior written consent.
• The licence narrowed to providing and supporting the service to you.
• Usage data defined as technical logs and metrics only, excluding your content, inputs and outputs.
• A definition of anonymised that is meaningful: data that cannot reasonably be re-identified by any person using reasonably available means.
• The no-training term extended to every sub-processor, with the list disclosed.
• Notice and a right to terminate without penalty if the vendor changes its position.
• Confirmation of what happens to data already used if you later opt out, and deletion of fine-tuned models built only on your data.

Sample clause you can propose

A workable clause reads: 'Vendor shall not use Customer Data, including any Personal Data, inputs or outputs, to train, retrain, fine-tune or otherwise develop any machine learning model, whether for Vendor or any third party, without Customer's prior written consent. Vendor shall ensure each sub-processor is bound by an equivalent obligation. Aggregated data may be used only for service analytics and only where it does not contain and cannot reasonably be used to derive Customer Data or identify any individual.'

Vendors serving many customers often accept this for enterprise plans. On self-serve plans, check whether there is an account-level opt-out and switch it off on day one, keeping a screenshot as a record.

A worked example

A Pune-based lending startup uses a call analytics tool at ₹4 lakh a year to transcribe and score customer calls. The transcripts contain names, phone numbers, loan amounts and sometimes income details. The contract says the startup owns its data, but grants the vendor a licence 'to use Customer Data to provide and improve the Services and to develop new features'. The sub-processor list includes an overseas speech recognition provider.

Read together, those clauses could support training the vendor's scoring model, and perhaps the provider's speech model, on the startup's customer calls. As fiduciary, the startup would struggle to explain that use to its borrowers or to its regulator. The fix it negotiated at renewal: a no-training clause covering sub-processors, usage data limited to technical logs, and deletion of transcripts ninety days after processing. The price did not change.

What if the vendor refuses?

Weigh what is actually going into the tool. A project management tool holding task titles is different from a support desk holding customer complaints with phone numbers, or a code assistant reading your source. For low-sensitivity data a broad improvement right may be an acceptable trade. For customer personal data, source code or confidential deal documents, a refusal is a reason to look at another vendor or to restrict what your team puts into the product, by written internal policy.

Whatever you decide, write it down. A short internal note recording that you reviewed the terms, what data goes into the tool, and why the risk is acceptable is useful later, both for your own audit trail as a data fiduciary and if a customer or regulator asks how you chose the vendor.