Claude API Data Privacy & GDPR Compliance Guide

Is the Claude API GDPR compliant?

Anthropic's Claude API can be used in a GDPR-compliant way, but "compliant" isn't a checkbox the provider flips for you — it's a shared responsibility. Anthropic offers a Data Processing Addendum (DPA), doesn't train its models on API inputs/outputs by default, and lets you control data retention settings. Your job is to configure those settings correctly, document your lawful basis for processing, and make sure every tool in your pipeline (including any gateway or middleware sitting between your app and Claude) handles personal data the same way.

This article walks through what Anthropic actually commits to, what falls on you as the data controller, and the practical steps to tighten up a Claude-based product for EU users.

What Anthropic commits to

A few facts matter more than marketing language here:

• No training on your data by default. Anthropic states that API inputs and outputs are not used to train its models unless you explicitly opt in (e.g., via feedback mechanisms you control).
• Data Processing Addendum available. Anthropic offers a standard DPA for API customers, which is the contractual basis you need to process EU personal data through a third-party processor under GDPR.
• Data retention controls. You can configure how long inputs/outputs are retained for abuse monitoring and trust & safety purposes, separate from any logging you do on your own infrastructure.
• Regional infrastructure disclosures. Anthropic publishes subprocessor and infrastructure information so you can assess international transfer mechanisms (Standard Contractual Clauses, etc.).

None of this makes your application compliant automatically. It establishes that the underlying model provider can be a lawful processor — the rest depends on how you build.

What you're responsible for as the controller

If your app sends user data — names, emails, support tickets, health notes, financial details — to Claude, you are almost certainly the data controller under GDPR, and Anthropic is a processor. That split means:

1. Lawful basis. You need a documented reason to process that personal data (consent, contract, legitimate interest) before it ever reaches the API.
2. Data minimization. Don't send more than the model needs. Strip or mask PII that isn't required for the task — names in a support ticket often aren't needed for a summarization call.
3. Retention policy. Define how long you store prompts, responses, and logs on your own systems, independent of Anthropic's retention settings.
4. Data subject rights. You need a process for deletion, access, and export requests that covers data stored in your database and any logs tied to API calls.
5. Vendor chain mapping. Every service between the user and Claude — your backend, a logging tool, an API gateway — is a link in the processing chain and needs its own basis for handling data.

That last point is where a lot of teams get sloppy, especially once they add middleware for API key management, usage tracking, or billing.

Where an API gateway fits into the compliance picture

If you route Claude traffic through a management layer — for rate limiting, per-team keys, usage metrics — that layer touches the same prompts and completions Claude sees. It needs to be accounted for in your data flow diagram and DPA chain.

SubToAPI sits between your application and Claude to give you application-scoped API keys (sub_live_...), streaming, tool use, and usage metadata without you building that infrastructure yourself. From a privacy standpoint, treat it like any other processor in your stack: it needs to be documented in your data inventory, and you should only send through it what you'd otherwise send directly to Claude. It doesn't add a new destination for your data beyond relaying requests to Claude and recording the usage metadata needed for billing and dashboards — which is the kind of narrow, purpose-limited processing that's easy to justify under Article 6.

If you're evaluating any gateway, ask three things: does it log full prompt content or just metadata, how long are logs kept, and does it have its own DPA. Get those answers in writing before you route production traffic through it.

Practical steps for a compliant integration

Redact before you send.

function stripPII(text) {
  return text
    .replace(/[\w.+-]+@[\w-]+\.[a-zA-Z]{2,}/g, "[email]")
    .replace(/\b\d{3}-\d{2}-\d{4}\b/g, "[ssn]")
    .replace(/\b(?:\d[ -]*?){13,16}\b/g, "[card]");
}

const safePrompt = stripPII(userMessage);

This is a blunt first pass — pair it with a proper PII-detection library for anything regulated (health, finance, children's data).

Set short retention where possible. If your use case doesn't need conversation history, don't store it. Pass only the current turn plus the minimum context required.

Log metadata, not content, by default.

logRequest({
  timestamp: Date.now(),
  model: "claude-sonnet",
  tokenCount: response.usage.output_tokens,
  // no raw prompt or completion stored
});

Keep full content logs behind a separate, access-controlled, short-retention store if you need them for debugging.

Document the full chain. A one-page data flow diagram — user → your backend → gateway (if any) → Claude → response path — makes DPA review and audits dramatically faster.

Review the DPA and subprocessor list yourself. Don't rely on a summary blog post (including this one) as your legal basis. Read Anthropic's current terms and have counsel confirm the SCCs or equivalent transfer mechanism fit your jurisdiction.

Getting started without over-engineering it

You don't need a compliance team to ship a GDPR-reasonable Claude integration. Start with data minimization, keep a clear processor list, and add redaction at the boundary where user input enters your system. If you're using a gateway like SubToAPI to manage keys and usage, check out /docs and the /docs/quickstart guide to see exactly what gets logged and how requests flow, then add your own minimization layer upstream.

questions

Does Anthropic use my API data to train Claude? No, not by default. API inputs and outputs are excluded from training unless you explicitly opt into providing feedback data. Confirm current terms before processing sensitive categories of data.

Do I need a Data Processing Addendum to use Claude API in the EU? Yes, if you're processing personal data of EU residents. Anthropic provides a standard DPA for API customers — request it and attach it to your internal data processing records.

Is using a third-party API gateway like SubToAPI a GDPR problem? Not inherently. Treat any gateway as a processor in your chain: confirm what it logs, for how long, and that it has its own DPA, then document it alongside your other subprocessors.