Using Claude under GDPR: the 14 checks that decide whether a rollout is lawful

There is no GDPR setting in Claude, and that is the whole problem

Nothing you can switch on inside Claude makes a rollout lawful. Fourteen separate checks do, and not one of them is answered by a certificate — each is answered by a document you write or a setting you can read back from a console. That is the difference between the question a data protection officer asks and the question a procurement deck answers.

Search this topic and you get legal explainers. They are competent and they are not wrong. They are also written by people who have never had to find out, on a Thursday afternoon, why a zero-retention agreement stopped covering the model a team wanted to use. This is the other view: the same obligations, worked from the console outward.

The fourteen split cleanly by owner, which is the only number that matters when you are staffing this. Five land on engineering, four on legal and procurement, and five on whoever maintains the record of processing. None of them is a question you ask Anthropic. All fourteen are questions you answer about yourself.

One framing before the list. The regulation does not know what a large language model is. It knows about controllers, processors, purposes, recipients, transfers and risk. Every check below is one of those five words pointed at a configuration setting, and that is why the answers are stable even as the platform changes underneath them.

Checks 4 to 7: retention is four numbers, and the newest models broke the fourth

Thirty days is the number everybody quotes and it is only one of four. Anthropic's commercial retention policy states that inputs and outputs are automatically deleted from the backend within 30 days of receipt or generation. That is check four, and it is the easy one.

Check five is the flagged path, and it is the number that belongs in your retention schedule rather than the headline. Where a chat is flagged by automated trust and safety systems, Anthropic states it may retain inputs and outputs for up to 2 years, and trust and safety classification scores for up to 7 years. The platform documentation adds the part that matters most: this retention applies regardless of arrangement, so it survives a zero-retention agreement.

Check six is per feature, not per product, and it is the one that quietly moves when a developer flips a flag. Files stay until explicitly deleted. Batch jobs retain for 29 days. Code-execution containers keep data up to 30 days. Structured-output schemas are cached for up to 24 hours since last use. Anthropic's own wording for turning on a non-eligible feature under a zero-retention arrangement is blunt: using one is a choice to step outside your ZDR arrangement for that specific data. A retention statement written per product is wrong the moment someone enables the Files API.

Check seven is the newest and the least known, and it is the reason we now run this as a command rather than a conversation. Since 9 June 2026, Anthropic designates Claude Fable 5 and Claude Mythos 5 as Covered Models that require 30-day data retention, and they are not available under zero data retention. Anthropic states the 30-day requirement applies wherever Covered Models are offered. An organisation with a valid ZDR arrangement therefore cannot call them at all until it enables 30-day retention — per workspace, if it wants to keep zero retention everywhere else. Your paperwork is fine. Your model access is not.

Check 7

The check is one request. Send anything to a Covered Model and read the error rather than the answer.

# Check 7 in one request. You are reading the status code, not the completion.
curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
        "model": "claude-fable-5",
        "max_tokens": 1024,
        "messages": [{"role": "user", "content": "ping"}]
      }'

# 200  -> this workspace stores prompts and outputs for 30 days.
#         Say so in the record of processing before anyone celebrates.
#
# 400  -> your zero-retention arrangement is live and this model is not:
# {"type":"error","error":{"type":"invalid_request_error",
#   "message":"In order to access this model, your organization or workspace
#              must have data retention enabled."}}

Checks 11 to 14: the four that are yours alone

Checks eleven through fourteen have no vendor component at all. They are also the four that a supervisory authority is most likely to ask for first, because they are the four that show whether anyone thought about the deployment rather than just bought it.

Check eleven is the record of processing, and it is mostly a copy exercise once the first ten are done. The regulation asks for the purposes, the categories of data subjects and personal data, the categories of recipients including any in third countries, the transfers with their safeguards, the envisaged erasure time limits where possible, and a general description of the security measures. Every one of those has an answer above. Erasure time limits is where the four retention numbers go, which is why check six matters more than it looks.

Check twelve is the impact assessment, and the trigger is your use case rather than the model. An assessment is required where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons — with systematic and extensive automated evaluation of people that produces legal or similarly significant effects called out explicitly, alongside large-scale processing of special categories. A summariser over public product documentation and a screening assistant over job applications are the same model and completely different assessments.

Check thirteen is the one almost no checklist carries, and it belongs to you as the deployer rather than to whoever trained the model. The European Data Protection Board's Opinion 28/2024, adopted 17 December 2024, addresses exactly this: where personal data is retained in a model and processed by a different controller at deployment, supervisory authorities should take into account whether the deploying controller conducted an appropriate assessment, as part of its accountability obligations, to ascertain that the model was not developed by unlawfully processing personal data. That is a piece of diligence with your name on it, and it should be proportionate to the risk of what you are deploying, not a ritual.

Check fourteen is human review. Where an output drives a decision based solely on automated processing that produces legal effects or similarly significantly affects a person, the individual has the right not to be subject to it, and the safeguards owed include at minimum the right to obtain human intervention, to express a point of view and to contest the decision. In practice this is a product decision made months before anyone reads the regulation: whether the assistant recommends or decides, and whether the human in the loop is real or decorative.

Yours alone

The four documents

• The record of processing entry — purposes, data subjects, recipients, third countries, erasure limits, security measures.
• The impact assessment decision, written down with its reasoning, including the decision that one was not required.
• The deployer's own assessment that the model was not built on unlawfully processed personal data, sized to the risk.
• The human-review path for any output that drives a decision with legal or similarly significant effect.

Where each of these comes from

Every factual claim above traces to one of the documents below, read on 4 August 2026. Where a source states a number, we quote the number; where it does not, we have written the qualitative statement instead. Nothing here is inferred from a vendor blog post.

The two that repay reading in full are Anthropic's retention page and the EDPB opinion. The first is the only place the feature-level retention differences are written down in one table. The second is the reason check thirteen exists at all — thirty-five pages, and our position is that it is the one document on this list a team should read in full rather than in summary, because the sentence that makes check thirteen workable is the one saying the assessment should be less or more detailed depending on the risks raised by the deployment.

Sources: Anthropic, API and data retention (processor identity per platform, ZDR scope, per-feature retention, Covered Models) · Anthropic, Data retention practices for Covered Models (Claude Fable 5 and Claude Mythos 5, 30-day requirement, effective 9 June 2026) · Anthropic, How long do you store my organization's data (30 days, 2 years flagged, 7 years classification scores) · Anthropic, Commercial Terms of Service · Anthropic, Data Processing Addendum (training position, controller/processor, SCC modules, 15-day sub-processor objection window) · European Data Protection Board, Opinion 28/2024 on certain data protection aspects related to the processing of personal data in the context of AI models, adopted 17 December 2024 (deployer diligence on model provenance, 35 pages). Read 4 August 2026. Vendor documentation changes; verify against the current release.

Keep reading

• Claude EU hosting and GDPR: which of the five platforms can process European personal data
• Claude in your own cloud tenant: Bedrock or Azure, under your own IAM roles
• Claude EU data residency: Bedrock, Foundry or the direct API