GDPR and AI: what cross-border data transfer rules mean for AI model calls

When an employee at a German law firm pastes a client’s name and contract terms into ChatGPT, they are not just violating their firm’s AI policy. Depending on the circumstances, they may be making a cross-border personal data transfer under GDPR — without a lawful basis, without contractual protections in place, and without the data subject’s knowledge.

This is not a hypothetical edge case. It is a compliance gap that exists in most European organizations using AI tools, including those with otherwise mature GDPR programs.

This article is written for DPOs, compliance officers, and legal counsel at EU-regulated organizations trying to understand when AI model API calls trigger GDPR transfer rules, what those rules require, and what a compliant AI governance posture looks like.

Does a prompt constitute a cross-border data transfer?

The threshold question is whether sending a prompt to an AI model provider counts as a “transfer of personal data to a third country” under GDPR Chapter V.

The answer is yes — when the prompt contains personal data and the model provider processes that data outside the EEA.

The legal analysis is straightforward:

GDPR Article 4(2) defines “processing” as any operation on personal data, including transmission and storage.
GDPR Article 44 requires that transfers of personal data to a third country may only take place where the conditions of Chapter V are met.
If an employee submits a prompt containing a natural person’s name, email address, employment details, health information, or any other information relating to an identified or identifiable individual, and that prompt is processed by a model running on infrastructure outside the EEA, the transfer rules apply.

The key practical question is when a prompt “contains personal data.” The answer:

A prompt that includes a client’s name and legal matter details: contains personal data.
A prompt that describes a situation involving named individuals without anonymization: contains personal data.
A prompt asking for help with a generic task (e.g., “improve this paragraph”) without any identifying information: generally does not contain personal data.
A prompt that includes pseudonymized data (e.g., a case file number without the associated name) may or may not contain personal data depending on whether re-identification is reasonably possible.

The default assumption for professional services firms, financial institutions, and any organization whose employees routinely work with client information should be: prompts submitted during client work contain personal data unless specifically stripped.

The Schrems II position for AI providers

Since the invalidation of the EU-US Privacy Shield in 2020 (Schrems II), the primary mechanism for EU-US personal data transfers has been Standard Contractual Clauses (SCCs). The new SCCs adopted by the European Commission in 2021 must be used for transfers to US processors.

Where do the major AI model providers stand?

OpenAI (ChatGPT, GPT-4 API): OpenAI offers a GDPR-compliant Data Processing Agreement and includes SCCs for EEA-to-US transfers. The API DPA covers the SCCs and includes data processing provisions that can satisfy GDPR Article 28 requirements. However, the default ChatGPT consumer product does not carry the same DPA terms — enterprise and API customers must ensure they are using the API tier with the signed DPA.

Microsoft (Azure OpenAI Service, Copilot for M365): Microsoft offers an EU Data Boundary for Azure services, which can keep certain customer data in the EU. The Azure OpenAI Service DPA includes SCCs. Microsoft Copilot for M365 can be configured for EU Data Boundary under enterprise agreements. However, the scope of what data remains in the EU versus what is processed in the US for model inference may require specific verification with Microsoft’s data residency documentation.

Anthropic (Claude API): Anthropic is a US company and processes data in the US. A GDPR-compliant DPA with SCCs is available for API customers. EU data residency for inference is not currently available. For EU-regulated organizations processing sensitive personal data, this means the SCC framework is the transfer mechanism, which requires a Transfer Impact Assessment (TIA) under post-Schrems II practice.

Google (Gemini API, Vertex AI): Google offers a Data Processing Amendment covering GDPR requirements and SCCs for applicable transfers. Google Cloud’s EU data residency options apply to Vertex AI customers but not to the consumer Gemini products.

General pattern: API-tier enterprise agreements with signed DPAs and SCCs provide a legal basis for EEA-to-US transfers. Consumer-tier products generally do not. Organizations whose employees use browser-based consumer AI tools (chat.openai.com, claude.ai, gemini.google.com) may not have the contractual protections in place even if the enterprise equivalent would be compliant.

What a Transfer Impact Assessment must cover for AI providers

Post-Schrems II, SCCs alone are not sufficient for transfers to the US. Organizations must conduct a Transfer Impact Assessment (TIA) to determine whether SCCs provide an adequate level of protection given the US legal and regulatory context.

For AI providers, a TIA should address:

1. Data categories and sensitivity: What personal data categories are likely to enter the AI system? For most organizations, this includes names and contact details at minimum. For healthcare, financial services, and legal, it may include special category data (health data, financial data, legal proceedings data).

2. US surveillance law exposure: The primary Schrems II concern is US intelligence surveillance laws, including FISA Section 702 and Executive Order 12333, which could compel US providers to disclose data without meaningful judicial oversight. The EU-US Data Privacy Framework (2023) partially addresses this for certified companies. As of 2026, OpenAI, Microsoft, Google, and Anthropic all participate in the DPF or rely on SCCs supplemented by technical safeguards.

3. Technical safeguards: Do technical measures (encryption in transit, access controls, processing isolation) reduce the practical risk of access by US authorities? Model providers generally cannot offer encryption at rest that prevents their own engineers from accessing data during model inference — this is a technical constraint of current LLM architectures, not a policy choice.

4. Purpose limitation: Is the personal data used only for the stated purpose (processing the prompt to generate a response) or does the provider use it for model training? This directly affects the scope of the transfer. Most enterprise API DPAs include “no training on customer data” provisions — verify this is in your agreement.

A completed TIA does not guarantee compliance — it documents the risk assessment and the decision basis. If the TIA reveals unacceptable residual risk, the organization must either implement additional safeguards, restrict the data categories that may enter the AI system, or choose a provider with a lower-risk transfer profile.

The Article 28 processor relationship

Under GDPR Article 28, when personal data is processed by a third party on behalf of the controller, a Data Processing Agreement (DPA) must be in place that meets specific requirements:

The processor processes personal data only on the controller’s documented instructions
Personnel are bound to confidentiality
Appropriate technical and organizational security measures are implemented
Subprocessors are approved and subject to equivalent data protection obligations
The processor assists the controller in fulfilling its obligations (subject access requests, breach notification, DPIA)
Data is deleted or returned after the services end
The processor provides information necessary to demonstrate compliance

For AI model providers receiving employee prompts that contain personal data, they are processors. Most major enterprise AI providers offer Article 28-compliant DPAs. The compliance gap in practice is that organizations have not reviewed and signed these DPAs, or have employees using consumer-tier products that are not covered by enterprise DPAs.

The sub-processor question: AI providers use sub-processors (cloud infrastructure, content moderation services, safety systems). Article 28(4) requires that sub-processors are subject to equivalent data protection obligations. When reviewing an AI provider’s DPA, verify: is the sub-processor list disclosed? Are SCCs flowing down to sub-processors? What is the process for notifying the controller of sub-processor changes?

The “legitimate interest” trap for AI use

Organizations sometimes attempt to rely on Article 6(1)(f) “legitimate interest” as the lawful basis for processing personal data through AI tools. This approach is generally inappropriate for several reasons:

Legitimate interest requires a balancing test against the data subject’s interests and fundamental rights. If the data subject is a client of a professional services firm, their interest in confidential professional advice not being shared with a US cloud provider is typically strong enough to outweigh the firm’s operational interest in AI tool productivity.
The data subject has no reasonable expectation that their personal data will be processed by an AI provider. The transparency requirement (Article 13/14 notices) would require disclosure — and that disclosure may itself raise concerns with data subjects.
For special category data (health, financial, legal, biometric), Article 9 applies and requires an explicit exception beyond legitimate interest. Article 6(1)(f) does not authorize processing of special category data at all.
DPAs and contractual bases with clients typically establish Article 6(1)(b) (contract performance) as the lawful basis. Submitting client data to a third-party AI provider is typically outside the scope of the contracted service — it requires either a separate basis or explicit disclosure in the service agreement.

The correct approach: Restrict what personal data may enter AI tools through technical controls (prompt inspection that detects and redacts or blocks personal data before transmission), and ensure that the AI tools used for any remaining personal data processing have signed Article 28 DPAs and Article 46 transfer safeguards.

1. AI tool classification: Classify AI tools by whether they receive personal data. Tools that only process non-personal data (generic research queries, code without personal data) require less documentation. Tools that receive personal data in prompts must be covered by Article 28 DPAs and Article 46 transfer safeguards.

2. Article 28 DPA register: Maintain a register of AI providers as processors, including DPA status and the transfer mechanism in use. This should be integrated with the organization’s existing processor register under Article 30.

3. Transfer Impact Assessments: For AI providers with US processing, complete a TIA at onboarding and review annually or when the provider makes material changes to their processing.

4. Technical enforcement: Deploy a prompt inspection layer that detects personal data in prompts and enforces your classification policy — blocking, redacting, or routing for review before the prompt reaches the external model. This is the control that makes the policy enforceable, not just documented.

5. Privacy notices: If employees use AI tools in ways that process client or employee personal data, consider whether your existing privacy notices adequately disclose AI tool use as part of your processing operations. The EU AI Act is developing disclosure requirements that will add to this.

6. DPIAs for high-risk processing: If AI tools are used in processing that poses high risk to data subjects — large-scale processing, processing of special category data, systematic monitoring — a Data Protection Impact Assessment (DPIA) may be required under Article 35 before the processing begins.

The practical compliance checklist

Action	Requirement	Priority
Audit which AI tools process personal data	Article 30 record of processing	Immediate
Obtain signed Article 28 DPAs from all AI providers receiving personal data	Article 28	Immediate
Verify SCCs or DPF coverage for US providers	Articles 44-46	Immediate
Complete Transfer Impact Assessments for US-based providers	Post-Schrems II	High
Deploy prompt inspection to detect and restrict personal data in prompts	Technical enforcement	High
Update Article 30 register to include AI providers as processors	Article 30	High
Review privacy notices for AI processing disclosure	Articles 13/14	Medium
Conduct DPIA for high-risk AI processing	Article 35	Medium
Establish sub-processor approval process for AI providers	Article 28(4)	Medium

Qadar AI Shield is designed for EU-regulated organizations managing GDPR compliance for AI tool use: prompt inspection that detects and restricts personal data before transmission, DPA-ready audit logging for Article 28 processor compliance, and cross-provider policy enforcement across browser, desktop, and API surfaces. Learn more.