Every time you send a prompt to an LLM API, ask yourself: where does that text go after you get your response?
For most major LLM providers, the honest answer is: it’s retained. In server logs, in abuse monitoring queues, in training data pipelines. Sometimes for 30 days. Sometimes indefinitely, unless you explicitly opt out — and even then, the contractual guarantees may be weaker than you think.
Zero data retention (ZDR) means something simple but radical: the provider does not store your requests or responses. Period. After inference completes, the data is gone. There’s no log entry to breach, no prompt to subpoena, no training dataset to accidentally include your users’ private conversations.
In this article, you’ll learn what ZDR means in practice, why European courts and regulators are increasingly treating it as a legal requirement rather than a nice-to-have, and how to verify that your LLM provider actually delivers on it — plus how to build ZDR-first applications on our European Data Centers.
🤙 Start building with Regolo’s zero-retention LLM API →
What Data Do LLM Providers Actually Retain?
Most API documentation is vague. “We may retain data to improve our services” is a common clause that can cover an enormous range of practices. Here’s a breakdown of what providers typically retain at different levels:
| Retention Level | What’s Stored | Risk |
|---|---|---|
| Full retention | Prompts, responses, metadata, user IDs | Training data leakage, breach exposure, GDPR violations |
| Abuse monitoring | Prompts for 30 days for safety review | Moderate — still creates a breach surface |
| Aggregated logs only | Timestamps, token counts, latency — no content | Low — no re-identification possible |
| Zero retention | Nothing — not even logs with content | Minimal — no stored data means no breach surface |
The distinction between “aggregated logs” and “zero retention” is important. A provider can legitimately say “we don’t store your prompts” while still retaining token counts, response latencies, and session identifiers. For most privacy purposes, aggregated technical logs without content are acceptable. True ZDR means no content — no prompts, no responses — is persisted after the request completes.
The Legal Case for Zero Retention
Zero retention has moved from a marketing claim to a legal expectation in the EU.
European courts have delivered a series of rulings that establish data minimisation and storage limitation as fundamental rights, not optional policies. The GDPR’s Article 5(1)(e) requires that personal data be “kept in a form which permits identification of data subjects for no longer than is necessary” — a principle the European Data Protection Board (EDPB) applies strictly to AI systems.
In practice, DPAs across Europe have ruled against blanket data retention policies and required providers to demonstrate that retention serves a specific, documented, necessary purpose. “Model improvement” is increasingly not accepted as sufficient justification when the provider cannot demonstrate that the specific retained data was necessary.
The parallel with Reddit’s decision to sell user data for LLM training illustrates the broader concern: when retention becomes a business model rather than a technical necessity, the incentive structures work against user privacy. ZDR eliminates this risk entirely — you cannot monetize data you never had.
Zero Retention vs. Zero Logging: Know the Difference
Be precise when evaluating providers. Common claims and what they actually mean:
- “We don’t train on your data” — Prompts may still be retained for other purposes (abuse monitoring, debugging, analytics)
- “Data is deleted after 30 days” — 30 days of exposure is 30 days of breach risk
- “Zero data retention” — Means nothing is stored after inference, but verify this in the DPA, not just the marketing page
- “Zero logging” — More stringent; means no server-side logs contain your content; may impact debugging and support
When evaluating a provider, ask for a copy of their Data Processing Agreement and look for explicit contractual language about retention periods — not just blog posts or FAQ entries.
How Regolo Implements Zero Retention
Regolo’s zero retention policy is architectural, not just contractual. Data processed during inference runs on GPU clusters in Italian data centers, operated by Seeweb, an Italian company subject exclusively to EU law. After a request completes:
- No prompt content is written to persistent storage
- No response content is logged
- No conversation history is retained server-side
- Conversation state, if needed, is managed entirely client-side
This means conversation continuity is the developer’s responsibility — which is actually the right design. Your application controls what context is passed to the model, and nothing persists beyond what you explicitly manage.
Here’s how to implement stateful conversation management client-side with Regolo:
import regolo
import json
import os
from datetime import datetime
regolo.default_key = os.getenv("REGOLO_API_KEY")
regolo.default_chat_model = "Llama-3.3-70B-Instruct"
class PrivacyFirstConversation:
"""
Manages conversation state client-side only.
No data is ever sent to persistent storage — history lives
in memory (or your own encrypted store) only.
"""
def __init__(self, system_prompt: str = None, max_history: int = 10):
self.history = []
self.max_history = max_history
self.system_prompt = system_prompt
self.client = regolo.RegoloClient()
if system_prompt:
self.client.add_prompt_to_chat(role="system", prompt=system_prompt)
def chat(self, user_message: str) -> str:
# Enforce history limit — avoid sending excessive context
if len(self.history) >= self.max_history * 2:
# Keep only the most recent exchanges
self.history = self.history[-(self.max_history * 2):]
self._rebuild_client_context()
self.client.add_prompt_to_chat(role="user", prompt=user_message)
self.history.append({"role": "user", "content": user_message,
"ts": datetime.utcnow().isoformat()})
role, response = self.client.run_chat()
self.client.add_prompt_to_chat(role="assistant", prompt=response)
self.history.append({"role": "assistant", "content": response,
"ts": datetime.utcnow().isoformat()})
return response
def _rebuild_client_context(self):
"""Rebuild client context from local history after trimming."""
self.client = regolo.RegoloClient()
if self.system_prompt:
self.client.add_prompt_to_chat(role="system", prompt=self.system_prompt)
for msg in self.history:
self.client.add_prompt_to_chat(role=msg["role"], prompt=msg["content"])
def export_history(self, filepath: str):
"""Save conversation to YOUR encrypted storage — not the provider's."""
with open(filepath, "w") as f:
json.dump(self.history, f, indent=2)
def clear(self):
"""Wipe all local state."""
self.history = []
self.client = regolo.RegoloClient()
if self.system_prompt:
self.client.add_prompt_to_chat(role="system", prompt=self.system_prompt)
# Usage: a support assistant that never retains user data server-side
assistant = PrivacyFirstConversation(
system_prompt="You are a helpful customer support agent. Be concise and friendly.",
max_history=5
)
response1 = assistant.chat("I can't log into my account")
print(f"Assistant: {response1}")
response2 = assistant.chat("I tried resetting but the email never arrived")
print(f"Assistant: {response2}")
# Save locally if needed (under your own access controls)
assistant.export_history("session_2026_03_09.json")Code language: Python (python)
Implementing PII Stripping Before Inference
Even with a zero-retention provider, you should strip PII from prompts before they leave your infrastructure. Defense in depth: if the data never reaches the API, there’s nothing to retain even if policy were to change.
import re
import regolo
import os
regolo.default_key = os.getenv("REGOLO_API_KEY")
regolo.default_chat_model = "Llama-3.3-70B-Instruct"
# Simple rule-based PII stripper (extend with a dedicated library like spaCy or Presidio)
PII_PATTERNS = {
"email": r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b',
"phone_eu": r'\b(\+39|0039)?\s?[\d\s\-\.]{8,15}\b',
"iban": r'\b[A-Z]{2}\d{2}[A-Z0-9]{4}\d{7}([A-Z0-9]?){0,16}\b',
"fiscal_code_it": r'\b[A-Z]{6}\d{2}[A-Z]\d{2}[A-Z]\d{3}[A-Z]\b',
}
def strip_pii(text: str) -> tuple[str, dict]:
"""Remove PII from text. Returns cleaned text and a map of replacements."""
replacements = {}
cleaned = text
for pii_type, pattern in PII_PATTERNS.items():
matches = re.findall(pattern, cleaned, re.IGNORECASE)
for i, match in enumerate(set(matches)):
placeholder = f"[{pii_type.upper()}_{i+1}]"
replacements[placeholder] = match
cleaned = cleaned.replace(match, placeholder)
return cleaned, replacements
def safe_inference(user_prompt: str) -> str:
"""Send prompt to LLM with PII stripped. Never sends raw personal data."""
clean_prompt, stripped = strip_pii(user_prompt)
if stripped:
print(f"[ZDR] Stripped {len(stripped)} PII items before inference")
client = regolo.RegoloClient()
_, response = client.run_chat(user_prompt=clean_prompt)
return response
# Test
raw_input = """
My name is Marco Rossi, my email is marco.rossi@company.it
and my fiscal code is RSSMRC80A01H501Z. I need help with my invoice.
"""
response = safe_inference(raw_input)
print(f"Response: {response}")Code language: Python (python)
Data Minimisation: Only Send What You Need
ZDR is most effective when combined with data minimisation at the application layer. Before sending any user data to an LLM:
- Ask: does the model actually need this information to answer the question?
- Strip: remove fields that are not necessary for the specific task
- Aggregate: where possible, send counts and categories rather than raw records
- Pseudonymise: replace identifiers with internal tokens that only your system can reverse
This is not just a privacy best practice — it also reduces token count and cost.
Zero data retention is not a checkbox — it’s an architectural commitment that changes the risk profile of your entire AI stack.
Regolo is designed by default for ZDR.
No opt-ins, no premium tiers, no fine print — your data is never stored.
FAQ
Does zero retention mean I lose conversation history?
Yes — conversation history is not retained server-side. You manage it client-side. This is actually better from a privacy standpoint: you control exactly what context is passed and you decide the retention policy.
How can I verify a provider’s zero retention claim?
Request the DPA (Data Processing Agreement). Look for explicit clauses stating that no request content is written to persistent storage. Marketing pages are not sufficient — the DPA is the legally binding document.
Does ZDR conflict with the AI Act’s logging requirements?
No. The AI Act requires logging for high-risk AI systems, but that logging must be under the deployer’s control — it’s your responsibility, not the provider’s. ZDR at the provider level is fully compatible with deployer-side audit logging.
What about caching for performance?
Some providers cache responses for identical prompts to improve latency. Ask explicitly whether prompt content is used in any caching layer and what the retention period of the cache is.
Is ZDR enough on its own for GDPR compliance?
It’s a significant enabler but not sufficient alone. You still need a lawful basis for processing, a valid DPA with the provider, appropriate security measures, and — for high-risk use cases — conformity assessments under the AI Act.
🚀 Ready? Start your free trial on today
- Discord – Share your thoughts
- GitHub Repo – Code of blog articles ready to start
- Follow Us on X @regolo_ai
- Open discussion on our Subreddit Community
Built with ❤️ by the Regolo team. Questions? regolo.ai/contact or chat with us on Discord