It now shows up in almost every enterprise AI deal: a redline, a security questionnaire answer, or a procurement addendum that says some version of “Vendor shall not use Customer Data to train, retrain, or improve any artificial intelligence or machine learning model.”
For an AI startup, that sentence can be harmless, or it can quietly prohibit things the product needs to function. The difference is in the details — and most founders see the clause for the first time on a deal they badly want to close.
This article explains why enterprises insist on no-training terms, the forms the clause takes, what an AI SaaS startup can usually accept, what it needs to carve out, and what it should never promise. It’s written from the vendor’s side. (If you’re a business buying AI tools and want to restrict your vendors, see Andrew’s guide to AI data ownership rights.)
Why Enterprise Customers Demand No-Training Terms
Understanding the customer’s concern makes the negotiation easier. Enterprises typically worry about:
- Leakage — their confidential information surfacing in outputs delivered to other customers, including competitors
- Their own obligations — contracts and privacy laws that limit how their customers’ data can be used
- Loss of control — data that trains a model can’t practically be pulled back out
- Regulatory scrutiny — the FTC has warned AI companies to honor their privacy and confidentiality commitments and not quietly expand data use through terms changes
- Market norms — major foundation model providers generally state that they don’t train on business customers’ API data by default, and enterprises expect their SaaS vendors to match
Most enterprise reviewers aren’t trying to cripple the product. They want assurance that their data won’t improve a model that serves someone else.
The Five Forms of the No-Training Clause
Not all no-training clauses are the same. From most to least restrictive:
- 1. Absolute ban on AI or ML use. No use of customer data with any machine learning system at all. This can prohibit the product itself — and ordinary features like spam filtering or search ranking.
- 2. No training of any model. Customer data may be processed by AI to deliver the service, but not used to train or fine-tune any model — including one used only for that customer.
- 3. No training of shared models. Customer data may improve a model used only for that customer, but not models used for anyone else. This is often the right landing point.
- 4. De-identified or aggregated use permitted. Training on shared models is banned, but aggregated metrics or properly de-identified data may be used.
- 5. Opt-in training. No training by default; the customer may opt in, sometimes in exchange for a pricing benefit.
The first step in any negotiation is identifying which of these the customer actually needs — and which the startup’s product can live with.
Step 1: Map What Your Product Actually Does
Before responding to a redline, the startup needs an honest map of how customer data flows through the product:
- Is customer data sent to a third-party model provider? Under what retention and training terms?
- Is any customer content used to fine-tune or train models today?
- Are examples retained for evaluation or quality testing?
- Is there a retrieval index or embedding store built from customer content?
- Are customer-specific models or adapters created?
- What do engineers see when debugging failures?
- What is collected as telemetry, and does it include any content?
The answers decide what the startup can promise. A no-training clause the product can’t comply with isn’t a negotiating win — it’s a future breach.
Step 2: Protect the Carve-Outs the Product Needs
Even when a startup is happy never to train shared models on customer data, a broadly drafted clause can prohibit ordinary operations. The carve-outs worth protecting:
- Providing the service — processing customer data through AI models to deliver outputs to that customer
- Customer-specific models — retrieval indexes, embeddings, or fine-tunes used solely for that customer
- Debugging and support — reviewing specific interactions to fix problems, with access controls
- Security and abuse monitoring — detecting misuse, fraud, and attacks
- Aggregated usage metrics — operational statistics that contain no customer content
- Legal compliance — retention required by law
A no-training clause that preserves these is usually acceptable to both sides:
Provider will not use Customer Data to train, retrain, or fine-tune any artificial intelligence or machine learning model that is made available to any person other than Customer. The foregoing does not restrict Provider from processing Customer Data (a) to provide, maintain, secure, and support the Services for Customer, (b) to create and maintain models, indexes, or configurations used solely for Customer, or (c) to generate aggregated usage statistics that do not contain Customer Data.
Sample language is illustrative only, not a template.
Step 3: Get the Definitions Right
The clause is only as clear as the terms it uses. Four definitions do most of the work:
- “Customer Data” — does it include Usage Data and telemetry? Enterprise drafts often define it to include everything, which can sweep in operational metrics.
- “Train” or “Model Improvement” — does it include evaluation, retrieval indexing, or prompt tuning, or only changes to model weights?
- “Model” — does it cover only foundation and shared models, or any machine learning component, including spam filters and ranking?
- “De-identified” or “Aggregated” — is it tied to a real legal standard, or just “names removed”?
These definitions are covered in depth in AI beta testing agreement key terms — the same traps apply in production contracts.
Step 4: Flow It Down to Your Model Provider
A startup’s no-training promise is only as good as its model provider’s. If customer data passes through a third-party model, the startup should confirm:
- The provider’s commercial terms don’t permit training on API data
- The provider’s data retention period, and whether zero or reduced retention is available for the account
- That the provider is listed as a subprocessor in the customer’s DPA
If the startup promises “no training” and “no retention” but its provider keeps data for abuse monitoring, the startup has made a promise it can’t keep on its own.
What Not to Promise
Some enterprise requests should be declined or narrowed:
- “No AI processing of Customer Data.” For an AI product, this prohibits the product.
- “Delete Customer Data from all models.” If data was used for training under an earlier agreement, it generally can’t be removed from learned weights. Promise deletion of data, logs, and customer-specific models — not something the architecture can’t deliver.
- Retroactive commitments. A clause that applies to data already used for training under earlier terms creates immediate breach.
- Unlimited liability for any breach of the clause. A higher cap or supercap for data breaches may be reasonable; uncapped liability usually isn’t.
- Audit rights with no limits. Offer certifications, written attestations, or annual questionnaires instead of on-site inspection of model infrastructure.
Turning the Clause Into an Advantage
Handled well, the no-training clause can help close deals:
- Publish a clear position. A short, public data-use statement answers the question before procurement asks it.
- Offer tiers. Default no-training for enterprise, with an opt-in program for customers who want to contribute data.
- Price the difference. Some startups offer a discount to customers who opt in to training — a trade enterprise buyers understand.
- Keep documents consistent. The subscription agreement, DPA, privacy policy, and security documentation should all say the same thing.
Consistency matters most in the first enterprise deal. Andrew’s guide to structuring your first B2B AI SaaS customer contract covers how these pieces fit together.
Don’t Forget the Beta
No-training expectations often start before the first paid contract. If beta or design partner data was used for training, and the same customer later signs an enterprise agreement with a no-training clause, the two documents need to fit together. Whether beta data can be used at all is covered in can an AI beta use customer data?, and design partner data terms in design partner agreements for AI startups.
No-Training Clause Checklist
- Map every way customer data flows through the product and the model provider
- Identify which of the five clause forms the customer actually needs
- Preserve carve-outs for service delivery, customer-specific models, support, security, and aggregated metrics
- Define Customer Data, Train, Model, and De-identified precisely
- Confirm the model provider’s training and retention terms match the promise
- Avoid absolute AI bans, model-deletion promises, and retroactive terms
- Keep the subscription agreement, DPA, privacy policy, and public statements consistent
Frequently Asked Questions
Should an AI startup agree not to train on enterprise customer data?
Often yes — for shared models. Most enterprise buyers expect it, and major model providers generally make similar commitments. The key is preserving carve-outs for delivering the service and for customer-specific models.
Does a no-training clause stop us from using AI on the customer’s data at all?
It shouldn’t, if drafted correctly. The clause should restrict training, not processing. Watch for drafts that ban any “AI or machine learning use.”
Can we still fine-tune a model just for that customer?
Usually, if the clause is limited to models made available to others. Say so expressly — many enterprise drafts don’t distinguish.
What if our model provider retains data?
Disclose the provider as a subprocessor, confirm its training and retention terms, and don’t promise more than it does. Some providers offer reduced or zero retention for eligible accounts.
Can we train on anonymized customer data?
Only if the clause permits it and the data meets a real legal de-identification standard. Many enterprise customers will ask to exclude this too.
Is this article legal advice?
No. The right position depends on the product architecture, the model provider, and the customer.
Get Help With Enterprise AI Contract Negotiations
Andrew S. Bosin helps AI and SaaS startups respond to enterprise redlines on training, data use, and AI-specific liability — with positions the product can actually support. Flat-fee drafting and negotiation support for founders nationwide.
About Andrew S. Bosin, Esq.
Andrew S. Bosin is a New Jersey technology attorney and two-time SaaS founder who represents AI and SaaS startups nationwide on a flat-fee basis. He personally drafts every agreement, gives every client his personal cell phone number, and responds to calls and texts quickly.
📌 Andrew S. Bosin LLC
📧 andrewbosin@gmail.com
📞 (201) 446-9643
📍 36 Highland Road, Glen Rock, NJ 07452
Call for a consultation. Flat-fee legal services for AI and SaaS startups, nationwide.
#AISaaSLawyer #BestAISaaSLawyer #AIStartupLawyer #AIContracts #EnterpriseSaaS #AIDataRights
This post is provided for general informational purposes and does not constitute legal advice.