GDPR
ComplianceDefinition
The EU General Data Protection Regulation, governing the protection of personal data for EU data subjects. Design implications include data minimization, establishing a lawful basis for processing, honoring data-subject rights, and respecting data-residency requirements.
Tested in: CCAR-P, CCAO-F, CCDV-F
Why It Matters for the Claude Certification Exams
Professional, Associate, and Developer blueprints all treat personal data in prompts and logs as a design choice, not an afterthought. Expect scenarios where the fluent next step is to paste a customer record into Claude — the defensible choice is to minimize, anonymize, or keep the record out of the model call.
In Depth
The EU General Data Protection Regulation (GDPR) governs personal data of people in the EEA. For a Claude application, the model call is just another processing step: the prompt, the retrieved chunks, the tool arguments, and the logs can all contain personal data even when the UI never shows a "GDPR" label.
What counts as processing in a Claude system
Personal data in this context is any information that identifies a person, directly or indirectly: names, emails, ticket text, voice transcripts, support dumps, and embeddings derived from those sources. Sending that data to the Claude API, storing it in a prompt-cache, writing it into an eval set, or shipping it to an MCP server are all processing activities. The exam does not ask you to recite article numbers. It asks whether your design minimizes what leaves the trust boundary.
Design implications that show up on the exams
- Data minimization. Do not paste a whole CRM row into the prompt if a hashed id and a non-identifying summary will do. Strip names and contact fields before retrieval unless the task truly needs them.
- Lawful basis. A team that "just tries Claude on production tickets" without a basis and without a vendor review is the anti-pattern. Partner and enterprise contracts, regional endpoints, and data-use settings are how organisations actually authorize this — not a developer's laptop.
- Purpose limitation. An eval set built from real tickets is still personal data. If you need quality measurement, use a held-out set that has been reviewed and redacted, not a live production dump.
- Retention. Prompt caches, session transcripts, and tool logs outlive the chat UI. Set TTLs and redaction on those stores the same way you would for any other processor.
Associate-level questions often stop at "should this go to Claude at all?" Developer questions add PII leakage through tools and logs. Professional questions add the architecture: where anonymization sits relative to retrieval, which region the API is called from, and who owns the Record of Processing.
GDPR is not a reason to avoid Claude. It is a reason to treat the prompt as a data pipeline with the same controls you already apply to databases and object stores. See also FedRAMP and Held-out eval set.
Frequently Asked Questions
Does sending a customer email to the Claude API count as GDPR processing?
Yes. The prompt, any retrieved context, and typically the logs are processing of personal data. Minimize or anonymize before the call unless you have a lawful basis and a reviewed vendor path for that data.
Is prompt caching a GDPR issue?
It can be. A cached system prompt or conversation that still contains personal data is stored for the cache TTL. Redact before you set a cache breakpoint, and do not cache raw customer records as reusable context.