Rolling out Claude in compliance with the GDPR: DPA, data categories, team rules

Claude is getting access to real company data in more and more businesses, from customer emails and draft contracts to internal reports. The question is rarely whether Claude is technically good enough, but whether its use is set up on a sound legal footing. Three points decide that: the data processing agreement, the question of which data may go into the chat at all, and clear rules for the team. If you ignore all three, you are relying on luck instead of a process.

English edition of an article from our German magazine. Read the German original

The contract comes before the first prompt. That is exactly the order in which a Claude rollout in a company should run. Photo: Kampus Production on Pexels

Why “we only use the chat” is not enough

Many companies think of Claude as a better search engine: try it out, like it, roll it out. That underestimates the fact that every prompt is a data transfer as soon as personal data is in it, a name, a customer number, an email address in a pasted block of text. From that moment, Anthropic becomes a processor within the meaning of the GDPR, and the company sending the prompt remains the controller with full accountability. If you want an overview of the platform first, you will find it in our Claude guide covering plans and features.

The fundamental difference from a general GDPR check for AI tools, as described in our overview article on ChatGPT, Copilot and Claude (in German), is that Anthropic’s contracts, retention periods and residency options differ in detail from those of other providers. If you only tick off the general seven-point checklist, you miss Claude-specific pitfalls such as the missing certification under the EU-US Data Privacy Framework or the special role of Claude Cowork. This article clears up exactly these details, together with the practical question: who on the team may do what with which data?

The data processing agreement: not every Claude plan is covered

The first and most important filter is the plan. Anthropic provides a data processing agreement (DPA) under Art. 28 GDPR exclusively for commercial offerings: Claude for Work, which by Anthropic’s own definition covers both the Team and the Enterprise plan, and the Anthropic API. The DPA is part of the Commercial Terms and is accepted electronically through the customer portal; there is no separate PDF to download and countersign. Anyone looking in the files for a signed contract therefore finds nothing and sometimes wrongly concludes that there is none. Anyone who works with a free Claude.ai account or the individual Pro plan instead has no contract, no chain of responsibility and therefore no legal basis for processing personal data of customers or employees there.

This sounds like a formality, but in practice it is the most common mistake: a single employee tries Claude through a private Pro account, likes it, and suddenly part of the customer communication runs through an account for which the company never concluded a contract. So the first team rule, before data categories are even discussed, is simply: business requests only through the licensed company account, never through private accounts.

Legally, the DPA covers the classic processor obligations: being bound by instructions, control of sub-processors, deletion obligations and support with data subject rights. For cross-border transfers to the USA, the EU standard contractual clauses under Art. 46(2)(c) GDPR are automatically part of the Commercial Terms. What is missing, and what law firms such as Heuking explicitly stress in their assessment of Claude in enterprise use: Anthropic currently holds no certification under the EU-US Data Privacy Framework. The standard contractual clauses do apply, but open questions about access by US authorities under the CLOUD Act or FISA 702 remain. For companies with particularly sensitive data, for example from healthcare or finance, this gap belongs in the data protection impact assessment, not in a footnote.

Data categories: what may go into the chat and what stays out

The DPA settles the legal basis, but it does not answer the question that counts in everyday work: which data may be entered at all? A short but binding categorization pays off here before Claude is switched on company-wide. As a rule of thumb for areas that should stay out before the broad rollout, compliance assessments of Claude in companies regularly name four groups: personnel data relating to health or performance, professional secrets for example from legal or tax advice, confidential company internals such as unpublished financial figures, and communication content that itself contains personal data of third parties, such as complete customer email threads.

This does not mean that Claude can never be used in these areas, but that each category needs its own check: legal basis, deletion period, technical safeguard. A practical example: a quote for a new customer with the company name and a contact person is usually uncritical, but as soon as an applicant’s health data or an employee’s salary details end up in the prompt, the risk level changes fundamentally. If you already work with the Claude API and build your own workflows (in German), you should build this categorization directly into the technical integration, for example with a pre-check that does not even pass recognizable personnel data fields on to the API.

A short, documented list is usually enough: green for unproblematic, yellow for approval by the data protection officer needed, red for off-limits in principle. Without this list, every employee makes the decision alone, often under time pressure shortly before the end of the working day, and that is exactly when the mistakes happen that later end in a breach notification.

Retention periods, training and the Zero Data Retention option

For commercial products the standard is: Anthropic does not use inputs and outputs to train its models. An exception arises only when a user actively gives feedback through the thumbs up or thumbs down function. These conversations are then kept for up to five years in a secured backend and stripped of user identifiers before any possible use for training. Organizations can disable this feedback function for the entire workforce in the admin settings, which is the simplest first step for companies with stricter internal policies.

For regular retention, Anthropic states 30 days for the commercial plans: inputs and outputs are deleted automatically in the backend within this period, and Claude Enterprise allows its own configuration. Two exceptions are worth knowing before someone in management passes on the 30 days as a promise. Whatever Anthropic’s automated abuse detection flags as a violation of the usage policy stays stored for up to two years, the associated classification scores for up to seven years. And the thumbs feedback mentioned above entails a five-year period. For a data protection impact assessment, the realistic upper limit is therefore not the 30-day figure from the product description.

If you need to be stricter, you can apply for Zero Data Retention, a contractual agreement that the sales team enables per organization. Prompts and responses are then no longer stored permanently once the response has been returned. The decisive point for decision-makers is in the small print: Zero Data Retention applies at the level of the Anthropic API. According to the documentation, the product interfaces of Claude Team and Claude Enterprise are explicitly excluded, as are Console and Workbench, Claude for Excel and the Claude Managed Agents, whose session logs remain until they are deleted manually. There is a single exception: Claude Code through Claude Enterprise, if Zero Data Retention is enabled for the organization.

Two technical constraints belong in the same review. Stateful features such as the Files API, batch processing and code execution fall outside the agreement, because they have to store files and containers. And the models Claude Fable 5, Fable 5.1, Mythos 5 and Mythos 5.1 are excluded from Zero Data Retention as so-called covered models, unless Anthropic explicitly grants an exception: they require 30 days of retention, otherwise the API responds with a 400 error. If you still want to work with these models in a ZDR organization, you can switch on 30-day retention for individual workspaces in the Console. That then belongs in your record of processing activities as a separate processing step, because exactly these workspaces fall outside zero retention.

One more period appears in no product description, but it affects every company that uses Claude Cowork or Claude Code. Anthropic’s compliance API keeps session logs from these applications so that admins and auditors can retrieve them. Local sessions from employees’ computers are stored there for six years by default, unless the organization has set a finite retention period in the privacy settings of claude.ai; then that period applies. Cowork sessions in the cloud are also kept for six years unless someone deletes them earlier, and the activity feed for a fixed six years. For audits this is useful; for your deletion concept it is a number you need to know.

EU data residency does not exist at Anthropic

Since the first version of this article in July, our own account has turned out to be too optimistic here, and the correction matters for every data protection impact assessment. We had written that Claude for Enterprise could be booked with an EU data residency option, with prompts and attachments staying in Frankfurt or Dublin. This option does not exist.

Anthropic’s documentation knows two separate controls. The value inference_geo controls per request where the model runs. The workspace geo controls where data rests and where secondary processing such as image conversion or code execution takes place; it is set when the workspace is created and cannot be changed afterwards. The section on the current limits of the feature is unambiguous: for inference, us and global are available, for the workspace only us. An EU region appears in neither list, in no plan, not even in Claude Enterprise.

What the default does also matters: according to Anthropic, global means that inference can run in any available region. If you want to at least pin it to US infrastructure, you set the value to us, either per request or through the workspace defaults default_inference_geo and allowed_inference_geos. Two details for the calculation: Anthropic charges 1.1 times the token price for the US pinning, and the parameter only works from Claude 4.6 on; older models respond with a 400 error. If you had previously booked the old organization-wide opt-out from global routing, you were migrated automatically to allowed_inference_geos: ["us"].

Processing within the EU therefore remains tied to a single route: Claude through AWS Bedrock or Google Cloud in an EU region such as Frankfurt, Dublin, Paris or Stockholm. There, the endpoint URL or the inference profile determines the region. The price for this is a change in the contract chain. The processor is then the cloud provider, not Anthropic, its contracts apply, and Anthropic’s own agreements on Zero Data Retention no longer take effect there. This explicitly does not apply to Microsoft Foundry, by the way: the deployment type available there keeps inference in the USA, and there is no EU zone so far. Which of the AWS variants allows which region and which retention, we took apart in the article Claude through AWS Bedrock: when the detour pays off (in German).

Another route often does not register as a Claude rollout at all. Microsoft Copilot uses Anthropic models in Word, Excel and PowerPoint on request. According to Microsoft, this setting is switched on by default for tenants from the EU, the EFTA and the UK that were created after 25 March 2026; older tenants find their status in the Message Center. Processing then runs outside the EU Data Boundary. Microsoft remains the contractual partner, Anthropic works as a sub-processor under Microsoft’s Product Terms and the Microsoft DPA, and the Anthropic DPA plays no role on this route. How the two worlds differ in everyday work is shown in our comparison of Claude and Microsoft Copilot (in German).

Because Anthropic also holds no certification under the EU-US Data Privacy Framework, the transfer remains based on the standard contractual clauses under Art. 46 GDPR in any case. So the transfer impact assessment does not go away when you switch to US inference; it just becomes easier to document.

Productive deployment should therefore only take place on the basis of a documented risk assessment and with close technical and organisational controls.

Heuking Rechtsanwälte, assessment of Claude in enterprise use, 2026

If you are already checking which Claude plan fits the size of your company, it is worth looking at our comparison of Claude and ChatGPT in company use (in German), which puts the plan differences in context beyond the pure data protection question.

Since 2 August 2026, the GDPR check alone is no longer enough

When this article appeared in July, the data processing agreement was the only legal hurdle before the rollout. Since 2 August 2026, the EU AI Regulation has been generally applicable, including its framework for fines and its chapter on supervision. In Germany, the Bundesnetzagentur carries out market surveillance, on the basis of the AI Market Surveillance and Innovation Act (KI-MIG), which came into force on 29 July 2026. Two points of it affect a typical Claude rollout.

The first is Article 4, AI literacy. The obligation has applied since February 2025, and the Digital Omnibus weakened it in July 2026: the duty to ensure a sufficient level of literacy became a duty to take measures to develop literacy. Nobody has to guarantee a particular level for individual people. In practice this means: the short introduction that belongs in every rollout plan anyway counts as such a measure if you document it. A list of participants and the training material are enough as proof. Which measures fit and how to document the proof is covered in our article on Article 4 and the proof in companies (in German).

The second point is Article 50, disclosure. It applies in two places where Claude is regularly used in mid-sized companies. When an AI system talks directly to people, for example as a chatbot in customer service, the people concerned must know that they are talking to a machine; the regulation only exempts what is obvious to an attentive user anyway. And anyone who publishes AI-generated texts on topics of public interest must label them. For this second case there is an exception that often fits everyday marketing: if a human reviews the text editorially and a natural or legal person holds editorial responsibility for the publication, the labeling is not required. The notice must be clear and distinguishable and must be in place at the latest at the first interaction.

The framework for fines for violations of Article 50 is up to 15 million euros or 3 percent of worldwide annual turnover; for small and medium-sized enterprises, whichever is lower applies. We have written up the details on deadlines, wording and borderline cases in our overview of the AI Act deadlines and the labeling obligation (in German), and the role of the German supervisory authority in the article on the KI-MIG and the Bundesnetzagentur (in German).

Team rules that make the contract effective

The DPA protects you legally, but it prevents nothing technically. What counts in everyday work are clear, written rules before Claude is rolled out widely, not afterwards as a reaction to an incident.

Four points belong in every rollout plan. First, a permission concept based on the principle of least privilege: not every colleague needs access to every function, especially not to far-reaching automations. Second, a special rule for Claude Cowork and similar agent features that can independently access applications, files, browser content and other company resources and carry out work steps on their own: these need tighter approval mechanisms and logging that, if in doubt, also makes it traceable afterwards which action touched which data. Third, a short data categories list that everyone understands, as described above, easy to find in an internal wiki instead of buried in a policy that nobody reads. Fourth, a short briefing for new team members that explains exactly these three points in five minutes before the first access is granted.

If you are building your own automations with Claude in parallel, for example with Claude Code in a team without programming skills (in German), you should build these rules directly into the workflow instead of running them alongside as a separate document. Governance that is added only after the technical rollout almost always comes too late in practice.

A realistic rollout for a mid-sized company

What this looks like in concrete terms is best shown with a typical case: a business with 60 employees wants to introduce Claude for writing quotes, internal research and first drafts of customer communication. The first step is a short conversation between management, IT and the data protection officer in which exactly the three points from this article are settled: which plan it will be, which data is allowed, who gets which access. The license order comes after that.

Only then comes the license decision. For a company of this size, Claude Team is enough in most cases, because the DPA is already included and rights can be managed centrally through the admin console without every single seat having to be managed by hand. Switching to Enterprise pays off as soon as you need a configurable retention period, a more fine-grained permission concept or audit logs. And if a customer from the financial sector requires processing within the EU, the route leads past Anthropic to Bedrock or Google Cloud, because as things stand today, Enterprise cannot meet this requirement.

In parallel, the data categories list is created. Half a page with concrete examples from your own everyday work is enough: which three or four document types land in the chat every day, and which of them contain names, health information or confidential figures. This list is presented in a short training session before the first accesses go live, as a ten-minute conversation with examples from your own practice. If you do not want to run this training yourself, you can book one of our AI workshops for your team (in German) for it. This conversation serves two purposes: it keeps the list present in people’s minds and at the same time documents the AI literacy measure under Article 4. After the first four weeks comes a short review: which questions came up, which borderline cases were decided unclearly, does the list need sharpening? This loop, start small and adjust early, is more effective in practice than a set of rules that is written once and never touched again.

Arno Hoffrichter

CTO, Collective Brain GmbH · Hamburg

CTO at Collective Brain. Responsible for the technical delivery of web projects and the SEO architecture.

Get in touch