AI governance and data protection
What are LLM data controls? Definition and examples
Also: No training, zero data retention, DPA, allowlist, log hygiene
In short
LLM data controls are the technical and contractual measures that determine what happens to your data in a language model. Six building blocks answer three questions: what does the provider do with it, where and under which law, and what stays in your own systems?
Why it matters: They give a defensible answer to the question “what happens to our data?”.
- At the providerNo training, zero data retention
- Law and locationDPA, data residency
- In your own systemsTechnical allowlist, log hygiene
Why does LLM data controls matter for your company?
AI projects often get stuck on this question in security review, especially in Switzerland and Germany. A single commitment is not enough: a provider can forgo training and still store the data.
The six building blocks work in three pairs. No training and zero data retention govern what the provider does with the data. A DPA and data residency govern law and location; a technical allowlist and log hygiene govern your own systems.
LLM data controls in detail
No training
No training means the provider of a language model does not use your prompts, files and responses to train its models. The commitment says nothing about whether the data is still stored. That takes zero data retention.
Many free and personal accounts of AI tools use inputs for training by default unless someone opts out. Business offerings usually exclude this by contract. Which version applies decides whether customer data or strategy papers can end up in a model.
Zero Data Retention
Zero Data Retention (ZDR) means the provider does not store prompts and responses after processing, except in clearly defined cases. ZDR goes further than no training because it rules out storage, not just use.
Many providers keep prompts for a while, for example for abuse detection or debugging. Every stored copy is one more place where data can be compromised or requested by authorities.
DPA
A DPA (Data Processing Agreement) is the contract that governs how a provider processes personal data on your behalf. It sets out safeguards, sub-processors and deletion, and makes technical commitments enforceable.
In the EU, Art. 28 GDPR requires such a contract as soon as a service provider processes personal data on your behalf; in Germany it is called an Auftragsverarbeitungsvertrag (AVV). In Switzerland the revised Federal Act on Data Protection (revFADP) governs processing by a processor: you must make sure the provider ensures data security, and sub-processors need your prior approval.
Data residency
Data residency defines in which region data is stored and processed, for example only in Switzerland or the EU. It governs location, not automatically access: data in Europe can still be reachable for support teams or authorities in other countries.
Technical allowlist
A technical allowlist is the list of permitted AI models, interfaces and tools; everything else is blocked technically. It turns a policy into a control you can evidence in an audit.
Without an allowlist every data commitment is only a policy. Anyone who quickly tests a new model or connects an agent that stores data bypasses no training, zero data retention and the DPA, often without noticing.
Log hygiene
Log hygiene is the deliberate handling of logs, monitoring and error data so that prompts and personal data never land unfiltered in your own systems. It is the data control that sits with you, not with the provider.
AI applications create a lot of data on the side: requests in application logs, error reports with the full prompt, usage data in analytics. There it often sits for months, readable by many people and with no deletion period.
Example: The data protection officer's question
Leadership wants to use an AI assistant to translate Strategy 2027 into actions for every team. The data protection officer asks: where does the paper end up, who can read it, is it used for training? So far there is only the provider's marketing page.
With LLM data controls the answer fits on one page, building block by building block, with evidence from the contract and the technical setup. The data protection officer approves the project, and the team starts with a tool that meets all six building blocks.
3 common mistakes to avoid
Checking only for “no training”
No training does not mean no storage. Checking only this point gives you half the answer.
Contract without technology
A DPA does not stop anyone from quickly connecting another model. Only a technical allowlist enforces the commitment.
Forgetting your own systems
Zero data retention at the provider achieves little if prompts sit in your own logs for months.
Step by step
- 1
Define data classes
Decide which data is public, internal or confidential and what may go into a language model.
- 2
Check the provider
Get no training, zero data retention and data residency in writing, including the exceptions.
- 3
Sign the contract
Sign a DPA with a list of sub-processors and deletion periods.
- 4
Secure it technically
Allow only reviewed models through an allowlist and mask prompts in your logs.
Where does your company stand on AI?
The AI Readiness Check shows in a few minutes where you stand across the six dimensions of the AI Monitor.
Start the AI Readiness CheckRead on in the PM Lab
Articles that go deeper.
Related terms
- AI governance →AI governance is the set of rules a company uses to decide who may use AI for what, with which data and under whose responsibility.
- Data residency →Data residency defines in which region data is stored and processed, for example only in Switzerland or the EU.
- Shadow AI →Shadow AI is the use of AI tools the company has neither approved nor knows about, such as personal chatbot accounts used for work data.