GDPR Compliant ChatGPT API: Use GPT and Claude in Europe (2026)

On January 16, 2026, OpenAI expanded European inference options for eligible ChatGPT business customers. A European company can also use GPT and Claude APIs under GDPR: establish a lawful basis and processor terms, minimize personal data, and control transfers, retention and access. An EU-only policy adds a separate task: choose and verify regional deployments.

This guide covers APIs. ChatGPT Enterprise and Edu workspace residency has separate settings and eligibility. We make Requesty, the gateway discussed below. Use this guide with your privacy and legal teams; it is not legal advice.

Which GPT and Claude routes support European processing?

These options are documented as of October 2026. Which data stays where comes down to the model, the features you turn on and your contract.

Pick the OpenAI API if you need GPT directly and its published Europe boundary fits your policy. Pick Azure OpenAI if you already use Microsoft's deployment controls. For Claude, pick Bedrock if its profile's destinations meet your boundary, or Google-managed Claude for EU multi-region inference. Pick Requesty if you want GPT and Claude behind one API with a Frankfurt gateway and centrally managed deployment choices.

If policy prohibits sending data to an external model provider, use an open-weight model on infrastructure you control. That replaces GPT or Claude with a different model; your team owns hosting, security and operations.

Bedrock also lists GPT models. An EU source endpoint can use a profile with a wider destination set: the GPT-5.6 Terra card, for example, lists US, India and global profile IDs. Inspect the chosen profile before approving it.

What GDPR requires before the first request

Start with the purpose, and the data that has to leave your application for it. A support assistant that needs a product name and error message does not necessarily need the customer's full ticket history, account number and home address. Strip what the task does not need before it reaches a model.

Identify the legal basis and data categories

Document an Article 6 lawful basis for the purpose under the GDPR. Consent is one possible basis, not a requirement for every API call. Legitimate interests require a balancing assessment; contractual necessity has its own conditions.

Health information and other special-category data also require a condition under GDPR Article 9. OpenAI's standard DPA schedule says no sensitive data is intended to be transferred except when unexpectedly included in unstructured data. Anthropic's standard schedule lists special categories as none. Before deliberately sending such data, agree appropriate terms for the selected service and use.

Pseudonymization lowers the risk, but data that can be linked back to a person using additional information is still personal data under GDPR Recital 26.

Map contracts and transfers

A data processing agreement, or DPA, sets the processor's instructions and obligations. GDPR Article 28 covers security, subprocessors and assistance with data-subject rights. Your company might itself be a processor for its customer, so map the actual roles.

Standard contractual clauses, or SCCs, are a possible safeguard for certain transfers outside the EEA. An adequacy decision is another route where its conditions are met. The European Commission's adequacy list covers US commercial organizations participating in the EU-US Data Privacy Framework; verify the relevant entity and certification scope. Where SCCs apply, assess the destination and any necessary supplementary measures with counsel.

Map the application, gateway, model provider and external tools, including support access. A US parent company, an EU server and a transfer of personal data are different facts; review the complete data flow.

Assign owners and keep evidence

A data protection impact assessment is required when processing is likely to result in high risk under GDPR Article 35. Review the GDPR rules for solely automated decisions under Article 22 if the system makes solely automated decisions with legal or similarly significant effects. Route consequential decisions to an appropriate review process.

The GDPR text also sets transparency requirements in Articles 13 and 14 and processing-record obligations in Article 30. Assess which apply to your organization and workflow.

Configure the model processing region

OpenAI: select Europe deliberately

OpenAI documents two paths for eligible API customers: use the EU-prefixed endpoint with a key from a new Europe project, or use the same endpoint with a key from an eligible Global project for request-level regional processing. The endpoint is https://eu.api.openai.com/v1. The per-request option leaves the Global project's geography unchanged. For project-level separation, create a Europe project and use the EU endpoint.

Non-US residency requires approval for abuse-monitoring controls and a Modified Retention amendment. The permitted retention arrangements include options other than zero data retention. Regional processing applies to supported models and endpoints.

Now, the fine print on the boundary: OpenAI defines Europe as the EEA plus Switzerland. Its regional commitment covers customer content on supported services; system data can be processed outside the region. Structured output schemas are among the system data OpenAI identifies, so keep personal data out of schema definitions. A contract requiring EU member states only needs a narrower commitment than the published Europe definition.

For a synthetic connectivity test, install the OpenAI Python SDK, set OPENAI_API_KEY to an eligible key, and run:

from openai import OpenAI
 
client = OpenAI(base_url="https://eu.api.openai.com/v1")
response = client.responses.create(
    model="gpt-6.1-sol",
    input="Reply with OK.",
)
print(response.output_text)

OpenAI lists GPT-6.1 Sol for EU regional processing on the Responses API. If the call fails, check approval, the retention amendment and the key's project before changing the region.

Azure OpenAI: inspect the deployment type

Microsoft says standard Models sold by Azure process prompts and responses within the customer-specified geography, potentially across regions in that geography. An EU DataZone deployment can process in any EU member nation. A Global deployment can process wherever the model is deployed, even if the Azure resource is in Europe.

Choose a supported GPT model and deployment type. Save the resource geography and configuration with the Microsoft terms. Check stateful features and abuse monitoring separately. Microsoft describes Batch as a Global deployment type, so resolve its scope before using it for an EU-only inference policy.

Claude on Bedrock: inspect every destination

An AWS geographic inference profile can route to multiple destinations. The source region receives the request; the destination runs inference. For Claude Sonnet 5.5, AWS lists six EU destinations for eu.anthropic.claude-sonnet-5-5 when the source is Frankfurt. The same profile from Zurich includes Switzerland, and from London includes the UK.

Assume your policy permits Frankfurt only. Five of the six possible destinations are outside Frankfurt, so this profile from that source does not meet the policy. A policy covering those six EU locations reaches a different answer.

With an AWS identity permitted to inspect the profile, query it from the source region:

aws bedrock get-inference-profile \
  --region eu-central-1 \
  --inference-profile-identifier eu.anthropic.claude-sonnet-5-5 \
  --query 'models[].modelArn'

Compare each returned model ARN's region with your permitted countries. Repeat for every source region. AWS warns that an eu. prefix alone is insufficient and that blocking any destination in a service control policy can make the request fail. For a synthetic request, inspect the CloudTrail additionalEventData.inferenceRegion field. One observation identifies that request's destination; the profile output shows the possible set.

Claude on Google Cloud: choose the Google-managed route

Google-managed Claude supports region="eu" for EU multi-region inference. Its client is AnthropicVertex; Anthropic-managed Claude on Google Cloud is a different product with a global location. Google Cloud billing alone is not a location control.

Google lists Claude Sonnet 5.5 in the Europe multi-region. Anthropic says newer models use global or multi-region endpoints; single-region endpoints serve Sonnet 4.6 and earlier. Enable the model in a Google Cloud project, give the calling identity aiplatform.endpoints.predict, configure Application Default Credentials, and install anthropic[vertex]:

import os
from anthropic import AnthropicVertex
 
client = AnthropicVertex(project_id=os.environ["GOOGLE_CLOUD_PROJECT"], region="eu")
message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=100,
    messages=[{"role": "user", "content": "Reply with OK."}],
)
print(message.content)

Set GOOGLE_CLOUD_PROJECT to your project ID. EU multi-region can include more than one location. Review Google's data governance rules for the model and features you enable.

Retention follows the whole workflow

Not using data for training and not retaining data are different promises. OpenAI says API data is not used to train its models by default unless the customer opts in. Default abuse-monitoring logs can contain prompts and responses and are retained for up to 30 days, subject to exceptions. Application state has separate rules: Responses data is stored for at least 30 days when its storage behavior applies, while Files and vector stores have their own deletion behavior.

Claude retention depends on the product, model and features. Anthropic lists Fable 5.1, Fable 5, Mythos 5.1 and Mythos 5 as Covered Models that require 30-day retention wherever offered. Anthropic says ZDR for these models requires its express authorization. AWS also documents model-specific abuse-detection retention for Fable models.

For each copy, record its location, owner, retention period, deletion path and access. Include retrieval documents, embeddings, caches, traces and ticket attachments. External MCP servers have their own policies; OpenAI's data controls separate those from its own retention rules. Avoid personal data in tags and custom headers, which can themselves identify people.

Use GPT and Claude through Requesty's EU gateway

Requesty's EU gateway processes gateway traffic in Frankfurt and gives your team one OpenAI-compatible integration for GPT and Claude. Restrict your organization to the EU gateway, select regional deployments for both models, and set your logging policy.

Sign up, add credits for the paid GPT and Claude deployments below, and create a Requesty API key. Then configure the organization and model controls.

1. 1
   Restrict the gateway region

   An organization admin opens Compliance, selects Edit beside Serving region, chooses Restrict regions, selects EU and saves. Requests to the global, US and AP Requesty gateways are rejected for that organization. Use https://router.eu.requesty.ai/v1 with an OpenAI-compatible client.

2. 2
   Approve the model deployments

   Use the Model Library or Approved Models to find EU deployments. Establish their possible inference destinations and applicable terms from provider evidence, then approve the routes that meet your policy in Admin Panel > Approved Models.

   If no approved-model list or access list is configured, all catalog models are available by default. Review access lists attached to keys and groups, the group default and organization approvals: a more specific list can take precedence. Restrict every relevant list to routes that meet your policy. Groups are an Enterprise feature; organizations without groups can attach access lists directly to API keys.

3. 3
   Set retention and fallback rules

   Turn off logging on each key that handles sensitive data, or have an organization admin enable Requesty zero data retention in Compliance. Requesty's data privacy documentation says usage metadata remains and historical payload logs are not removed by enabling ZDR. Select fallback deployments that meet the same location and retention requirements as the primary route.

4. 4
   Complete the contract review

   Obtain the Requesty DPA and review the subprocessor list. The Requesty DPA covers Requesty as processor; review applicable upstream terms and the contract chain, including any bring-your-own-key arrangement. AWS documents retention for Claude Fable 5 and 5.1, so include the selected model and features in the retention review.

The Model Library lists azure/gpt-6.1-terra@swedencentral and bedrock/claude-sonnet-5-5@eu-central-1 as EU-tagged deployments. A catalog tag identifies the deployment; provider evidence establishes the possible inference destinations. The AWS command above inspects your own account, not a Requesty-managed account.

After approving both routes, set REQUESTY_API_KEY, install openai, and send synthetic requests:

import os
from openai import OpenAI
 
client = OpenAI(
    api_key=os.environ["REQUESTY_API_KEY"],
    base_url="https://router.eu.requesty.ai/v1",
)
 
for model in [
    "azure/gpt-6.1-terra@swedencentral",
    "bedrock/claude-sonnet-5-5@eu-central-1",
]:
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": "Reply with OK."}],
    )
    print(model, response.choices[0].message.content)

Requesty's PII and secrets scanners can mask detected values before they reach the provider. Report records matches and forwards the original content; Mask replaces detected values and restores matching values in the response. Test coverage on synthetic data: scanning does not detect every identifier or scan the model's output for new sensitive data.

Prove the restrictions before production

Use synthetic prompts. Repeat these checks for each production key and its attached key and group lists:

1. Send an approved model request through the EU endpoint and confirm success. This positive control checks the key, balance and route before testing denial.
2. With the same key, send an approved model request through https://router.requesty.ai/v1/chat/completions. For an EU-restricted organization, expect a region-policy rejection. Save the response and any request ID returned. Authentication and transport errors are inconclusive.
3. Through the EU endpoint, request a model absent from the key's resolved list. Expect the documented provider violates policy error and no upstream forwarding. Save the response and verify provider-side evidence where available.
4. Trigger a controlled primary failure in a test fallback policy. Inspect the actual backup provider, deployment, permitted destination set, retention and contract. Confirm the request stays on an approved route.
5. Inspect application logs, gateway settings, provider state and external tools for the synthetic prompt. Check deletion and access permissions for each store.

For test 3, first exclude openai/gpt-6.1-terra from the test key's resolved list. Use the approved-model request in test 1 as the positive control, then run:

curl -i https://router.eu.requesty.ai/v1/chat/completions \
  -H "Authorization: Bearer $REQUESTY_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"openai/gpt-6.1-terra","messages":[{"role":"user","content":"Reply OK"}]}'

Requesty's access-list documentation says a request outside the resolved list returns provider violates policy without being forwarded upstream. If you receive an authentication or balance error instead, fix it and repeat the test.

Download Requesty's compliance report as PDF or JSON evidence. It covers chat completions and counts provider attempts. Keep change records and upstream destination evidence alongside it, particularly for cross-region Bedrock profiles.

For the protocol detail, see the EU routing documentation.

What to do this week

For a team that needs both GPT and Claude under an EU infrastructure policy, we recommend the Requesty EU gateway, EU model deployments whose destinations meet that policy, and Requesty ZDR. Before sending personal data, run the denied-model test above with a synthetic prompt and the production key. If the route cannot be established or the test fails, hold the request instead of falling back to a global model. Start with the EU routing setup.