Guide
A working checklist for personal data and the EU AI Act in LLM applications
- 01
Identify sensitive values
- 02
Replace with stable tokens
- 03
Restore only inside your boundary
Direct answer
Most customer-facing LLM applications that handle personal data need to satisfy GDPR and the EU AI Act together: GDPR's lawful basis and data-minimisation requirements, and the AI Act's transparency and risk-management obligations for whichever risk tier the system falls into. Start by classifying the system's risk tier, then work through data-minimisation and vendor due-diligence questions before treating the build as compliant.
Start with classification, not controls
The EU AI Act layers obligations by risk tier, so the first question isn't which control to add — it's which tier the system falls into. Most LLM-based chat and support tools fall under limited-risk transparency obligations, such as disclosing that a user is interacting with an AI system. Systems used in contexts like employment decisions, credit scoring, or law enforcement can fall under the high-risk (Annex III) category, which carries substantially more extensive requirements.
Classification should happen before a data-protection review, not after, since it determines which obligations apply on top of GDPR rather than instead of it.
Personal data minimisation before the model ever sees it
GDPR's data-minimisation principle applies to what reaches a model, not just what a company stores afterward. A practical checklist for teams building on top of LLM providers:
- Map every point where personal data can enter a prompt, attachment, or retrieved context
- Apply pseudonymisation or redaction before submission, not after a response is generated
- Log what policy action was taken, not the original sensitive value itself
- Treat a model's own content filtering as a backstop, not the primary data-protection control
- Confirm whether retrieved documents (RAG context) can carry personal data the prompt itself didn't include
Vendor and processor due diligence
Every AI provider and gateway in the request path is a processor or sub-processor under GDPR, and each one needs to be accounted for in due diligence, not just the primary model vendor.
- A signed DPA covering the AI provider and any intermediary gateway
- A published sub-processor list, kept current as vendors change
- Confirmed data residency and processing region for prompts and any retained context
- A stated retention policy for prompts and model outputs, not just for account data
- Incident-notification terms that reach your team on a timeline you can act on
Related PII guidance
Frequently asked questions
Does the EU AI Act replace GDPR obligations for LLM apps?
No — it adds requirements on top of GDPR rather than replacing it. An LLM application handling personal data typically needs to satisfy both frameworks at once.
Is every chatbot a high-risk AI system under the Act?
No. Most general-purpose chat and support assistants fall under limited-risk transparency obligations. High-risk classification depends on the use case — such as employment, credit, or law-enforcement contexts — not on the technology alone.
Is this checklist legal advice?
No. This is a practical starting point for internal review, not a substitute for legal advice. AI Act obligations depend on your system's specific risk classification and use case; confirm requirements with counsel before relying on this list for compliance.