
GDPR-Compliant AI: Building LLM Features for the EU Market
Every time a user types a message into your AI chatbot, you're processing personal data. The message might contain a name, an email, a health concern, a complaint about a service. Under GDPR, that's personal data — and you need a legal basis to process it.
Most engineering teams building AI features treat compliance as a post-launch problem. "We'll add the privacy stuff later." That approach works until a DPA sends you a questionnaire, or a user exercises their right to deletion and you realize you can't actually delete their data from your vector database.
Here's how to build LLM features that are compliant from day one.
The Two Laws You Need to Know
GDPR (Active Since 2018)
The General Data Protection Regulation governs how you collect, process, and store personal data of EU residents. Key requirements for AI:
- Legal basis for processing (consent, legitimate interest, or contract performance)
- Data minimization — don't send more data to the LLM than necessary
- Right to deletion — users can request their data be erased
- Right to explanation — users can ask why an automated decision was made
- Data processing agreements with all sub-processors (including your LLM provider)
EU AI Act (High-Risk Deadline: August 2026)
The AI Act adds requirements on top of GDPR:
- Risk classification of your AI system
- Transparency — users must know they're interacting with AI
- Human oversight for high-risk decisions
- Bias testing and monitoring
- Technical documentation
For most startups building chatbots, search, or content generation features, you're in the minimal risk category under the AI Act. But GDPR applies regardless.
Where Does User Data Go?
When a user sends a message to your AI feature, the data typically flows through:
User → Your Backend → LLM API (OpenAI/Anthropic/etc.) → Response → User
Each hop is a data processing step. Let's trace what happens:
OpenAI API
- Data is sent to US servers (or EU via Azure OpenAI)
- OpenAI's data processing addendum says they don't train on API data
- But: data traverses US infrastructure → CLOUD Act applies
- Retention: 30 days for abuse monitoring (can be reduced to 0 with zero-retention policy)
Anthropic API
- Data processed in the US (GCP infrastructure)
- No training on API data
- Similar CLOUD Act concerns
- EU hosting available via AWS eu-west (ask your account manager)
Self-Hosted Models (Llama, Mistral)
- Data stays on your servers
- Full control over retention and deletion
- No sub-processor concerns
- Higher infrastructure cost
If personal data leaves the EU to reach an LLM provider, you need: (1) a Data Processing Agreement with that provider, (2) Standard Contractual Clauses or adequacy decision, and (3) a Transfer Impact Assessment. Self-hosting eliminates all three requirements.
The GDPR Compliance Checklist for AI Features
1. Establish a Legal Basis
For most AI features, you have two options:
Consent: User explicitly agrees to AI processing. Requires granular opt-in, easy withdrawal, and the feature must work (in degraded mode) without consent.
Legitimate Interest: You argue the AI feature is in both your and the user's interest. Requires a documented Legitimate Interest Assessment (LIA). Easier to implement but legally riskier.
2. Implement Data Minimization
Don't send the entire user profile to the LLM. Strip out unnecessary personal data before making the API call:
def sanitize_for_llm(user_message: str, user_context: dict) -> str:
"""Strip PII before sending to LLM."""
# Only include what's necessary for the response
context = {
"subscription_tier": user_context.get("tier"),
"language": user_context.get("language"),
# DON'T include: email, name, address, phone
}
return f"Context: {json.dumps(context)}\n\nUser question: {user_message}"
3. Handle Right to Deletion
This is where it gets tricky. If you're using RAG with a vector database, user data might exist in:
- Chat history (PostgreSQL) — easy to delete
- Vector embeddings (Pinecone, Qdrant, pgvector) — harder
- LLM provider logs — depends on their retention policy
- Application logs — often overlooked
For vector databases, you need to:
- Track which embeddings contain which user's data
- Delete those specific vectors on request
- Re-index if necessary
async def handle_deletion_request(user_id: str):
# 1. Delete chat history
await db.execute("DELETE FROM chat_messages WHERE user_id = $1", user_id)
# 2. Delete vector embeddings
vector_ids = await db.fetch(
"SELECT vector_id FROM user_embeddings WHERE user_id = $1", user_id
)
await vector_store.delete(ids=[v["vector_id"] for v in vector_ids])
await db.execute("DELETE FROM user_embeddings WHERE user_id = $1", user_id)
# 3. Request deletion from LLM provider (if applicable)
await llm_provider.delete_user_data(user_id)
# 4. Purge application logs
await log_store.purge(filter={"user_id": user_id})
4. Add Transparency
Users must know they're talking to AI:
// Clear AI disclosure — don't hide it
<div className="text-sm text-muted-foreground mb-2">
This response was generated by AI. It may contain inaccuracies.
</div>
5. Sign a DPA with Your LLM Provider
Both OpenAI and Anthropic offer Data Processing Agreements. Sign them before you go to production. They cover:
- What data is processed and why
- Sub-processor list
- Security measures
- Breach notification obligations
EU-Hosted Alternatives
If you want to keep data in the EU entirely:
| Option | Model Quality | EU Hosting | Cost |
|---|---|---|---|
| Azure OpenAI (EU region) | GPT-4 level | Yes (EU West) | Pay-per-token |
| Mistral (La Plateforme) | Excellent | Yes (France) | Pay-per-token |
| Self-hosted Llama 3 | Very good | Full control | €200-500/month (GPU) |
| Self-hosted Mistral | Excellent | Full control | €200-500/month (GPU) |
| Ollama on Hetzner | Good-Excellent | Yes (Germany) | €50-200/month (CPU) |
Our default recommendation for EU startups: Mistral API for production, Ollama on Hetzner for development and testing.
Common Mistakes
- Logging entire conversations without a retention policy. Set a 90-day auto-delete.
- Embedding user PII in RAG documents. Separate user data from knowledge base data.
- No consent management for AI features. Add a toggle.
- Ignoring sub-processor chains. OpenAI uses Azure. Azure uses... you need to know the full chain.
- No Data Protection Impact Assessment. Required for AI processing personal data at scale.
Building AI features for the EU market? We handle compliance from day one. See our AI & LLM Integration services.

