There is one question that appears in every enterprise procurement review of an AI-enabled SaaS product. It appears before the security questionnaire, before the DPA redline, before the pricing negotiation. It is the question that determines whether the deal moves forward or stalls in legal review for three months.
Does your AI train on my data?
If you do not have a clear, specific, contractually binding answer to this question, you are not ready for enterprise sales. The answer cannot live in a FAQ or a blog post. It needs to be in your Terms of Service, your DPA, and your Privacy Policy, and all three need to say the same thing.
This is not a new concern. SaaS customers have always cared about how their data is used. But AI has elevated it from a procurement checkbox to a deal-defining issue. One major enterprise software vendor is running a multimillion-dollar advertising campaign built entirely around the message that it will never use customer data to train AI models. That tells you how much the market cares about this right now.
Why This Question Is Different Now
Before AI features, “we use customer data to provide and improve our service” was standard, accepted language. Customers understood that their usage patterns might inform product roadmap decisions or that aggregated metrics might help optimize performance. Nobody objected because the data stayed within the service boundary and was used in predictable ways.
AI changes this in three ways.
First, training an AI model on customer data is a fundamentally different use than providing the service. When a customer sends a query to your AI feature and gets a response, that is inference. The model processes the input and generates an output. The data flow is functional and temporary. When that same input is used to train or fine-tune a model, the data is being incorporated into the model’s learned parameters. It is no longer just being processed. It is being absorbed into a system that will generate outputs for other customers. Enterprise buyers understand this distinction, even if they do not use the technical vocabulary.
Second, the three-actor model from the previous post in this series means training can happen at multiple layers. Your product may not train on customer data, but your LLM provider might. If you are sending customer inputs to an API and that API provider retains inputs to improve its models (unless you have explicitly opted out), customer data is being used for training regardless of what your own terms say. Your contractual commitment needs to cover the entire chain, not just your layer.
Third, the regulatory environment has caught up. Under GDPR, using personal data for model training constitutes a new processing purpose that requires a lawful basis. Under CCPA, using customer data for model training may implicate “sale” or “sharing” definitions depending on the specifics. Your DPA processing purposes schedule and your Privacy Policy disclosures both need to account for whether AI training occurs and under what conditions.
The Technical Distinctions That Matter Contractually
Not all AI data usage is the same, and your contracts need to reflect the differences. There are four categories that matter for contractual purposes, and conflating them creates problems for both you and your customers.
Inference-only processing is what happens when a customer uses your AI feature in real time. Customer data goes in, the model processes it, an output comes back. The data is not retained for any purpose beyond generating the response. This is the baseline that most customers expect and accept. It is analogous to how a search engine processes a query: the input is used to generate a result, not to rebuild the index.
Retrieval-augmented generation (RAG) is a step beyond inference. In a RAG architecture, customer data is indexed and stored so the AI feature can retrieve relevant context when generating responses. The data is not used to train the model itself, but it is stored and processed in a way that goes beyond a single request-response cycle. Customers need to understand that their data is being indexed and persisted, even if it is not being used to train a model.
Fine-tuning uses customer data to adjust the model’s behavior for a specific use case. The data is used to modify model parameters, which means it becomes part of how the model operates. Fine-tuning is more targeted than full model training (it adjusts an existing model rather than building one from scratch), but the customer’s data is still being incorporated into the system. This is where most enterprise customers draw a hard line unless they have given explicit, informed consent.
Full model training uses large volumes of data to build or rebuild a model from scratch. This is what the major LLM providers do with public data, and it is what enterprise customers fear most. If customer data ends up in a model training dataset alongside data from other customers, a competitor’s inputs could theoretically influence the outputs your customer receives. This concern may be technically overstated in most architectures, but it is commercially real and needs to be addressed directly.
Your contracts need to specify which of these categories your AI features use. A provision that says “we may use customer data to improve our AI” without distinguishing between inference, RAG, fine-tuning, and training is a provision that will be redlined by every serious procurement team.
The Training Spectrum: Four Contractual Positions
There are four positions a B2B SaaS provider can take on AI training, and each has different contractual implications.
Absolute prohibition means your terms explicitly state that customer data will not be used to train, fine-tune, or improve any AI or machine learning model, full stop. No exceptions, no anonymization carve-out, no opt-in mechanism. This is the strongest position for enterprise sales and the easiest to communicate. It is also the most restrictive for your product development. If you take this position, make sure your LLM provider’s terms support it. If your provider retains the right to train on API inputs unless you opt out, your absolute prohibition is only as strong as your upstream opt-out.
Opt-in training means your default position is no training, but customers can affirmatively consent to having their data used for model improvement. The consent should be granular: per data category, per AI feature, and per model. A customer might consent to training on low-sensitivity text inputs but not on files containing personal information. The opt-in should be documented (account settings or written consent, not buried in a terms acceptance flow) and revocable. If a customer withdraws consent, you need to be able to exclude their data from future training runs. Be transparent that removing data from a model already trained is not technically feasible, as trained models do not store discrete copies of training data.
Aggregated and anonymized use means your terms permit using customer data for model improvement, but only after it has been anonymized and aggregated with data from other customers. This is a middle-ground position that many SaaS companies adopt. The problem is that “anonymized” is doing a lot of work in that sentence. True anonymization means the data cannot be re-identified, even in combination with other datasets. Aggregation means individual customer data is merged to a level where no single customer’s inputs are distinguishable. If your anonymization process is a simple scrub of names and email addresses, that may not meet the bar, especially under GDPR’s standard, which considers data anonymous only if re-identification is not reasonably likely by any means. If you take this position, document your anonymization methodology and be prepared to defend it.
Default-on training means customer data is used for model improvement unless the customer opts out. This is the position most consumer AI products take and the position most B2B enterprise customers will not accept. If you are selling to businesses that handle sensitive data (which is most B2B customers), default-on training is a deal-killer. Even if the opt-out is easy to exercise, the default matters because it signals how you think about customer data.
How Training Provisions Interact With Your DPA
Your training provision does not live in isolation. It needs to align with at least three other parts of your legal stack.
Your DPA processing purposes schedule defines why you process personal data. If your schedule says you process personal data “to provide the Service as described in the Agreement” and your Agreement says nothing about AI training, then training is not an authorized processing purpose. Starting to use customer data for model improvement without updating your DPA is a contractual breach, and potentially a regulatory violation if the data includes personal information subject to GDPR or CCPA.
Your subprocessor list needs to account for where training happens. If customer data is sent to your LLM provider and that provider uses it for model improvement, the provider’s training activity is part of the processing chain your DPA covers. Your DPA needs to either restrict your subprocessor from training on customer data or disclose the training activity as a processing purpose.
Your Privacy Policy needs to disclose training practices in language accessible to data subjects. If customer data includes personal information of the customer’s end users (which it usually does in B2B SaaS), those individuals have a right to know how their data is being used. Your Privacy Policy disclosure should be consistent with what your DPA and Terms commit to. If your DPA says “no training” but your Privacy Policy says “we may use data to improve our products,” you have an internal contradiction that will surface during a procurement review or a regulatory inquiry.
The Existing Customer Problem
If your current DPA authorizes processing “to provide the Service” and you start using customer data to improve your AI, the question is whether that existing authorization covers it.
Usually, it does not. “Providing the Service” is a purpose tied to delivering the product the customer signed up for. Using data to train a model that will benefit other customers (or the model generally) is a different purpose. It may benefit the original customer indirectly through a better product, but that is a stretch of the original authorization that most data protection authorities would not accept.
For self-serve customers, you may be able to address this through updated terms (subject to the modification clause considerations discussed in the previous post). For enterprise customers on negotiated contracts, this is a conversation. It requires updating the DPA processing purposes schedule, potentially amending the training provision in your Terms, and getting documented consent if you want the option to train on their data.
The good news is that most enterprise customers will accept inference-only processing and RAG without significant pushback. The hard line is typically at fine-tuning and training. If your AI features are inference-only and your LLM provider has a contractual commitment not to train on API inputs, you can often satisfy procurement by documenting these commitments clearly without needing to negotiate a training consent mechanism.
The Practical Framework
Here is how to approach this.
Start with your data flow map. For each AI feature, document whether the feature operates in inference-only mode, uses RAG, involves fine-tuning, or contributes data to model training. Document the same for your LLM provider: what does their API agreement say about data retention and training?
Choose your position on the training spectrum. For most B2B SaaS companies selling to enterprises, the right starting position is inference-only processing with a contractual no-training commitment, backed by an upstream opt-out from your LLM provider. If you want the flexibility to offer fine-tuning or training as a value-add, build it as an opt-in with granular consent mechanics.
Update your legal stack to reflect that position. Your Terms need a clear training provision. Your DPA processing purposes need to match. Your Privacy Policy needs consistent disclosure. Your subprocessor list needs to include your LLM provider with a note on data usage.
For existing customers, prioritize the enterprise accounts. Update their DPA processing purposes at renewal or through a proactive amendment. For self-serve customers, update your standard terms and implement feature-gated consent if you offer any training-related functionality.
Document everything. Your anonymization methodology if you use aggregated data. Your LLM provider’s contractual commitments on training. Your internal processes for handling opt-in and opt-out requests. This documentation is what you will produce when procurement asks their follow-up questions, and they will.
This is the second post in the AI-Enabled SaaS series. Previous: AI Addendum or Full Redraft? A Decision Framework for B2B SaaS Companies Adding AI. Next: AI Outputs: IP Ownership, Accuracy Warranties, and the Marketing Claims Problem.
No Boiler provides self-service legal document generation and educational content. This material and our service is not a substitute for legal advice. Please have a qualified attorney review any documents before relying on them.