Anthropic Claude in the Enterprise – Data Protection and Compliance Requirements for the Use of Generative AI

Anthropic Claude is among the most capable AI systems and is increasingly being used in enterprise contexts for document analysis, text generation, and the automation of internal work processes. With its growing adoption, however, the data protection and compliance-related legal framework is coming into focus. Particular attention is being paid to the fact that Anthropic, as a US-based provider, does not currently hold a certification under the EU-U.S. Data Privacy Framework according to its publicly available certification information. At the same time, AWS Bedrock and Google Vertex AI offer alternative deployment models whose data protection assessment differs considerably. Additionally, new challenges arise from agentic features such as Claude Cowork, which can grant the AI extensive access and action capabilities. Against this background, the following article examines the key issues when deploying Claude in an enterprise context.

This assessment gains additional significance in light of the current European debate on technological sovereignty. As recently as 3 June 2026, the European Commission presented a “European Technological Sovereignty Package” that includes, among other things, the “Chips Act 2.0”, a Cloud and AI Development Act, an open-source strategy, and a strategic roadmap for digitalisation and AI in the energy sector. The proposal aims to strengthen European cloud and AI capacities, better protect critical applications and sensitive data, and create an EU-wide framework for assessing cloud and AI sovereignty. At the same time, it must be noted that the legislative proposals must first be negotiated by the European Parliament and the Council of the European Union.

I. Direct Use of Claude: The Data Protection Starting Point

The direct use of Claude initially raises questions regarding the transfer of personal data to the USA. Anthropic is headquartered in the United States and, according to its publicly available certification information, does not currently hold a certification under the EU-U.S. Data Privacy Framework. Where personal data is processed through Anthropic’s services, a third-country transfer regularly occurs that must meet the requirements of Art. 44 et seq. GDPR.

Anthropic bases such transfers on Standard Contractual Clauses pursuant to Art. 46 GDPR, which are automatically incorporated into the Commercial Terms of Service via the Data Processing Addendum. Nevertheless, the uncertainties associated with processing by a US provider remain. In particular, US authorities may assert access rights under certain statutory conditions, for example on the basis of the CLOUD Act or FISA 702. The fact that data may be stored on servers outside the USA does not necessarily preclude such access possibilities.

For enterprises, the contractual structure is also decisive. Anthropic provides a Data Processing Agreement within the framework of its Commercial Terms for its commercial products, in particular for Claude for Work – which, according to Anthropic’s own documentation, encompasses both the Team and the Enterprise plan – as well as for the Anthropic API. Insofar as personal data is processed within the commercial services in accordance with the DPA, the customer is typically the controller and Anthropic the processor. Data is not used for model training in this context. By contrast, the Free, Pro, and Max tiers do not include a Data Processing Agreement and are subject to the Consumer Terms. For a deployment that is robust from a data protection perspective, therefore, only the commercial offerings (Team/Enterprise) or the API are generally suitable.

II. Claude via AWS Bedrock or Google Vertex AI

Against this background, the question arises whether the assessment changes when Claude is used not directly through Anthropic, but via AWS Bedrock or Google Vertex AI. Both services enable access to the Claude models and their integration into existing cloud infrastructure, with usage subject to commercial terms that exclude model training.

A precise distinction must be drawn between the deployment variants. With “Claude in Amazon Bedrock,” AWS operates the inference infrastructure, is the sole data processor, and, according to its own representations, does not grant Anthropic access to the inference environment. Through regional endpoints – such as Frankfurt – processing within the EU can be achieved. This variant can improve the data protection position compared to direct use. However, it does not replace the assessment of what role Anthropic plays in the specific data flow and what significance the absence of a dedicated European Anthropic cloud has for the respective use case. The situation is different with “Claude Platform on AWS”: here, Anthropic operates the inference. AWS and Anthropic act as independent processors, and data does not necessarily remain within AWS but may be forwarded to Anthropic’s own cloud. EU data residency is not envisaged for this variant at launch. Only a coarse geography (US or global) can be controlled per request. With Google Vertex AI as well, the assessment depends on the chosen endpoint type. Global endpoints offer no residency guarantee. The advantage of EU processing therefore exists only with an appropriate regional configuration. Additionally, many enterprises already have established data protection and compliance structures for AWS or Google Cloud. This facilitates integration into existing governance frameworks. At the same time, an independent assessment remains necessary because the data protection evaluation depends significantly on the deployment model, endpoint selection, routing, and operator role.

AWS furthermore maintains certification under both the EU-U.S. and the Swiss-U.S. Data Privacy Framework. When using a DPF-certified platform provider, a different transfer-law basis may apply for certain transfer constellations. However, this does not replace the assessment of whether and to what extent data reaches Anthropic or other recipients outside the EEA – which is practically always the case with the Anthropic-operated variants. Whether the specific Google Cloud recipient used is also certified accordingly must be examined separately. For enterprises, this means: Claude cannot simply be approved as a “cloud feature” but requires a separate, product- and route-specific data protection assessment.

In conclusion, the use via AWS or Google does not automatically eliminate the underlying third-country connections. Amazon and Google are also US companies, meaning that questions regarding potential government access may persist. A data protection-compliant configuration rather requires that a platform-operator-side (AWS or Google) operated variant with an EU region is selected, global routing is excluded or controlled, and the specific data flow – including any onward transfers to Anthropic – is examined on a case-by-case basis. For broadly deployed enterprise use, this means that the configuration, data flows, and contractual roles must be documented in advance and included in the Data Protection Impact Assessment.

III. Claude Cowork and Desktop Access

The agentic features of Claude carry particular compliance relevance, especially Claude Cowork, which Anthropic offers as an agentic function and product interface for multi-step knowledge work. Unlike the conventional use of an AI chatbot, processing here is not limited to individual user inputs: depending on the configuration, the AI can access applications, files, browser content, and other enterprise resources, as well as independently execute certain work steps.

This shifts the risk assessment from the question of data location to the question of the AI’s access and action capabilities. While conventionally only consciously entered information is regularly processed, Claude Cowork can access significantly larger data sets within the permissions granted – such as personal data, confidential corporate information, communication content, or business-critical documents. That Cowork requires separate treatment is also evident from the fact that Anthropic regulates the function separately in its contracts and, for example, excludes it from BAA coverage.

From a compliance perspective, the focus is therefore on adherence to the need-to-know principle, the protection of trade secrets, and control over the actions performed by the AI. Deficient permission concepts or overly broad access rights can lead to sensitive information being processed even though this is not necessary for the task. Particular sensitivity is required where professional secrets, personnel data, or other particularly sensitive information is concerned.

Enterprises should therefore carefully assess before deployment which systems and data sets Claude Cowork may actually access. Clearly defined permission concepts, a restriction of access rights to the necessary minimum, logging of activities, and appropriate approval and control mechanisms for critical actions are recommended.

IV. Conclusion and Outlook

The deployment of Claude in an enterprise context requires a careful data protection and compliance assessment. With direct use and with the Anthropic-operated variant “Claude Platform on AWS,” the transfer of personal data to the USA, the absence of a DPF certification by Anthropic, and the lack of a genuine first-party EU cloud are the primary concerns. In these constellations, significant legal assessment and justification requirements exist. By contrast, the AWS- or Google-operated variant with an EU region can reduce risks through controllable data residency and – in the case of AWS – the DPF certification of the platform operator. This, too, applies only with careful configuration and case-by-case assessment.

The assessment of Claude thus differs from the assessment of other enterprise solutions such as Microsoft Copilot or OpenAI ChatGPT Enterprise, each of which requires examination of their own data protection, contractual, and operational models. With Claude, the absence of Anthropic’s own EU cloud, the varying operator role depending on the deployment model, and the potential third-country connections are particularly prominent. The fact that Anthropic models in Microsoft 365 Copilot are currently excluded from the EU Data Boundary and are disabled by default in the EU, EFTA, and the United Kingdom illustrates the practical relevance of these questions. As long as Anthropic does not offer its own EU cloud, it remains necessary to assess with particular care in data protection-sensitive constellations whether and under what conditions deployment is legally defensible. This assessment aligns with a regulatory trend that is increasingly focused on European cloud and AI sovereignty, the protection of sensitive data, and the reduction of strategic dependencies. The determining factors are, in particular, the chosen deployment variant, the endpoint and routing configuration, the contractual roles, the sub-processors employed, and the question of whether personal data or confidential corporate information is affected. Productive deployment should therefore only take place on the basis of a documented risk assessment and with close technical and organisational controls.

With the increasing proliferation of agentic features such as Claude Cowork, the legal discussion is also shifting from classic questions of third-country transfer towards information security, access control, and AI governance. For enterprises, it will therefore be decisive in the future not only where data is processed, but also which systems and information AI applications may access and how such access is controlled.

Enterprises should therefore only consider deploying Claude within a comprehensive data protection, security, and governance framework. The focus is on the documented assessment of data residency, operator role, third-country connections, contractual safeguards, and agentic access rights. Only when these points have been robustly clarified for the specific use case can the deployment be classified as sustainable from a data protection and compliance perspective.

This article was created in collaboration with our student employee Emily Bernklau.