No training on your data: what that actually means
No training on customer data: what the promise means technically and contractually, where RAG, DPAs and deletion obligations apply, and where their limits lie.
Martin Semmele
Key takeaways
- Processing and training are different: only training makes your data a permanent part of the model; processing is reversible.
- RAG retrieves knowledge from your knowledge base into the context for each query. The model learns nothing from the conversation.
- According to DataGrail 2026, possibly 63.6% of AI providers — out of 2,400 software systems analysed — may not be disclosing external sub-processors in their legal documents.
- Even without training, data remains: up to 90 days of log storage for IT security is considered acceptable.
- Anthropic does not train on API data by default, but stores reported feedback for up to 5 years.
Processing is not training. The difference first.
Almost every AI provider in support writes the sentence somewhere: no training on your data. Sounds good. But it only helps you if you know what it means technically. Because behind the statement lie two completely different processes that are often conflated in a single sentence.
- Processing: your data is used in real time to complete a task. A customer query comes in, the model delivers an answer, done. Once the task is complete, the data does not flow back into a learning system.
- Training: your data is fed into a model to change it permanently. Your inputs become part of the model's knowledge. There is no reset. Extracting the content again would mean retraining the model, and nobody has the budget for that.
The difference is therefore reversibility. Processing you let pass through like a query in the inbox. Training bakes the data in. That is exactly why the statement matters, and exactly why it is worthless as a standalone sentence on a marketing page. The sentence has no scope, names no sub-processors, no retention periods, and carries no one's signature1.
What you therefore anchor the promise to: the verifiable parts. Which providers receive the data, how long each type of data is kept, whether the exclusion also covers anonymised and aggregated versions, and whether all of this is set out in the signed contract1. The next sections work through these points in order.
RAG: the model does not learn from your conversations.
In customer support, the promise usually rests on an architecture called Retrieval-Augmented Generation, or RAG. The principle: the language model is not trained on your data. Instead, with each question the system searches an external knowledge source and incorporates the retrieved information into the answer2.
- 01Retrieve: the customer query is converted into a vector representation and matched against the vector database of your knowledge base. The search finds the sections most similar to the question2.
- 02Augment: the retrieved sections are inserted into the context of the query. The prompt now contains the original question plus the relevant passages2.
- 03Generate: the model formulates an answer in natural language from this context. After that the process is complete; nothing flows back into any training2.
The side effect is at least as important for you as the privacy aspect: because the model only answers from the retrieved sections, every answer can cite its source. This also limits hallucinations, because the system does not improvise from memory but draws on your maintained knowledge2. How a RAG pipeline is protected against hallucinations in detail we have described separately: Preventing hallucinations.
Data isolation: tenant separation and its limits.
The second technical pillar is isolation. Providers separate the data of different customers so that your knowledge base and conversations are not mixed with those of other tenants. Two levels are common3:
- Tenant separation: the data of different customers is processed in logically separated environments. Each tenant sees only its own content.
- Tenant isolation: isolation additionally operates at infrastructure level — systemically or physically — so that mixing is technically ruled out.
Both make sense and raise the level of protection considerably. But keep two limits in mind. First: pseudonymisation is not anonymisation. Replacing identifying attributes with identifiers does not make data anonymous. As long as re-identification remains at least theoretically possible, data continues to be treated as personal and falls entirely within the scope of GDPR3.
Second: technical safeguards do not replace a legal basis. GDPR requires that every processing of personal data rest on a legal basis under Art. 6, regardless of how well the data is technically protected. Isolation can make a processing operation more secure, but not more lawful3. For use in customer service this means: alongside the technology you also need a sound legal basis and a clean contract4.
The DPA: where the promise becomes binding.
As soon as an AI provider processes personal data under instruction on behalf of your company, you need a data processing agreement under Art. 28 GDPR, or DPA. The DPA is where the promise moves from marketing copy to a contractual obligation. These mandatory elements should be reviewed:
- Instruction binding: the provider processes data only on your documented instructions.
- Confidentiality: the persons involved are bound by confidentiality obligations.
- Deletion rule: what happens at the end of the contract, within what timeframe data is deleted or returned.
- Sub-processors: which sub-processors exist, under what conditions they are engaged and what obligations are passed on to them.
The critical point with AI providers is the last one. The training exclusion must be recorded for every sub-processor, not just for the main provider. Because the actual model processing usually runs through a model or embedding service further back in the chain. How wide the gap is in practice is shown by a DataGrail analysis from 2026: of 2,400 software systems analysed, possibly 63.6% of providers with AI functionality may not be disclosing external sub-processors in their legal documents5.
That does not mean all these providers are secretly training. Some simply have none. But from the outside you cannot distinguish the two groups as long as the supply chain remains unnamed1. A checklist for provider selection based on GDPR criteria we have compiled in a separate article: GDPR-compliant AI in customer service.
What OpenAI and Anthropic actually commit to.
If your support provider uses a large model as a front end, your position also depends on that model's commitments. These can be checked against the exact wording.
OpenAI states: by default, no data from ChatGPT Enterprise, ChatGPT Business, ChatGPT Edu and the API platform — neither inputs nor outputs — is used to train or improve the models. For qualifying organisations there are additionally retention controls up to a zero-data-retention policy on the API platform6.
Anthropic commits the same for commercial products such as Claude for Work and the Anthropic API: inputs and outputs are not used for training by default. There is however one exception you should know about. If users submit feedback via the thumbs-up or thumbs-down button, Anthropic stores the entire associated conversation for up to 5 years in the secured back end and may use the feedback for training7.
For your evaluation this means: ask not only which model the provider uses, but via which endpoints, with which retention settings, and whether feedback functions for customers are disabled or can feed into the training chain.
Limits: logs, metadata, aggregated reports.
Now the part most provider pages leave out. Even with a genuinely meant commitment, a lot remains. This is not a scandal but the normal operation of an online service. You should just know it before you promise or expect total absence of data.
- Operational and security logs: log files record who accessed which system when. A storage period of up to 90 days for IT security purposes is considered acceptable under data protection law; longer storage only with a clearly overriding interest. The Federal Commissioner for Data Protection and Freedom of Information has, with reference to the landmark ruling of the Federal Constitutional Court on data retention, designated six months as the upper limit of proportionality8.
- Billing metadata: timestamps, token counts and latency must be stored, otherwise no one can issue you an invoice. This survives even a zero-data-retention commitment that only covers content1.
- Backups and reports: backups outlive the deletion of individual conversations until they are overwritten. And aggregated reports — such as resolution rates or frequently asked questions — almost always arise beyond the content of individual conversations1.
That is exactly why the useful question to a provider is not whether it has logs. Everyone has logs. The question is which data types it stores, for how long each, and whether the training exclusion also covers derived versions of your data — that is, the criteria from the first section above1. What usage-based billing does with such metadata we have set out separately: Usage-based costs.
ComLayer as an example. And your checklist.
To close, a concrete example — our own. ComLayer processes conversations, knowledge base, file attachments and AI processing in European regions. Sign-up, payment, email sending and semantic search run through services in the USA, and we name these providers rather than concealing them. We do not analyse your content to train proprietary models, and the model and embedding providers used have contractually committed to the same exclusion. The DPA records this for each provider.
This is not a special case but what you can demand from any provider. These questions help with evaluation:
- Who are the sub-processors, by name, including the model and embedding services?
- How long is each type of data retained, in days, not in clauses?
- What is the deletion SLA on request, and does it cover backups?
- Does the training exclusion also cover anonymised, de-identified and aggregated data?
- Is everything set out in the signed DPA, with precedence over the online terms?
A provider that answers all questions in a flowing paragraph is guessing. A provider that answers with names, figures and clause references has been audited before1. Our plans and pricing are transparently available on the pricing page.
A note to close: this article is not legal advice. It contextualises technology and contractual practice, but does not replace an individual review by a specialist, not least because liability for incorrect AI answers remains with the operator: Liability for AI errors.
Frequently asked questions
What does "no training on customer data" mean technically?
The provider processes your content only to deliver the requested result: an answer, a summary, an extraction. The data does not flow into the training, fine-tuning, evaluation or benchmarking of a model. The difference from processing is reversibility: processed data can be deleted; data fed into a model cannot practically be removed.
Does the AI model learn from conversations with my customers?
With a RAG architecture, no. The customer query is converted into a vector representation and matched against your knowledge base. The retrieved sections are inserted into the context of the prompt; the model formulates the answer from this. After the answer, nothing has been learnt: the model does not retain the conversation as knowledge.
Is the "no training" promise sufficient for GDPR?
No. Technical safeguards such as tenant separation raise security but do not replace a legal basis under Art. 6 GDPR. And pseudonymisation is not anonymisation: as long as re-identification remains theoretically possible, data continues to be treated as personal. The promise must additionally be recorded contractually in the DPA.
What must a DPA with an AI provider contain?
Under Art. 28(3) GDPR at a minimum: instruction binding, confidentiality obligations, technical and organisational measures, deletion obligations and the naming of sub-processors. On the topic of training: the exclusion must be recorded for each sub-processor, not only for the main provider. According to DataGrail's analysis of 2,400 software systems analysed, possibly 63.6% of providers with AI functionality may not be disclosing external sub-processors in their legal documents.
Do OpenAI or Anthropic use my support data for training?
By default, no. OpenAI does not use data from API and Business products for training or improving the models. Anthropic makes the same commitment for commercial products such as the API. But: with Anthropic, reported feedback (thumbs up or down) including the conversation can be stored for up to 5 years. Check the feedback routes too, not just the training clause.
Which data remains stored despite the promise?
Operational and security logs, billing metadata such as timestamps and token counts, backups and aggregated reports. Log files are necessary for IT security and intrusion detection: up to 90 days of storage is considered acceptable under data protection law; longer storage requires a justified interest. Zero data retention changes little here because billing data and abuse monitoring survive it.
How do I evaluate an AI provider before signing a contract?
With the five questions from the checklist above: sub-processors with names and locations, retention periods for each data type in days, deletion SLA including backups, training exclusion also for anonymised and aggregated data, and everything set out in the signed DPA.