Keeping every Azure OpenAI and Amazon Bedrock request inside the EU

Which Azure OpenAI deployment types keep processing in the EU

Only two kinds of Azure deployment keep inference inside the EU: Data Zone deployments created in a resource in an EU region, and Standard or Regional Provisioned deployments in an EU geography. Every Global type can process prompts outside the EU, even when the resource itself sits in an EU region.

Microsoft's deployment types page, last updated on 12 August 2026, separates two things that are often mixed up. Data stored at rest, such as uploaded files, stays in the Azure geography of the resource for every deployment type. Processing, meaning the inference that reads your prompt and writes the response, follows the deployment type. A resource in an EU region with a Global Standard deployment therefore stores data in the EU but may process it anywhere. Most questions along the lines of "we picked an EU region, so why can our data leave it?" come down to this combination.

Two details belong in your records. Microsoft's data privacy page says an EU Data Zone deployment may process prompts in any EU member state. The deployment types page adds that the EU data zone follows the EU Data Boundary, which can include EFTA countries such as Norway and Switzerland, and that Microsoft can add regions to a data zone without prior notice. If your requirement is one country rather than the EU, only a Standard deployment in that country's geography comes close, and it may still move work between regions within that geography.

Not every model is offered in every deployment type and region. Before you commit to a model, check Microsoft's current model availability for Data Zone Standard and Standard in your region. A model that is offered only as Global Standard cannot be used under an EU-only rule, however good it is.

Who can see your prompts on Azure

For models Microsoft sells in Foundry, including the Azure OpenAI models, OpenAI does not receive your prompts and they are not used for training. Claude in Foundry works differently, and abuse monitoring can involve Microsoft staff. Microsoft's data privacy page, last updated on 5 June 2026, states that prompts and completions are not available to OpenAI or other providers of models sold by Azure, are not used by those providers to improve their models, and are not used to train generative AI foundation models without your permission or instruction. It also says the models are stateless and do not interact with services operated by OpenAI, such as ChatGPT or the OpenAI API.

Claude models in Foundry are a separate case. Microsoft's hosting comparison, last updated on 22 September 2026, states that Anthropic is the seller and operator of Claude in Foundry and acts as an independent data processor for prompts and outputs, under Anthropic's data processing addendum and commercial terms. Azure-hosted Claude is offered as Global Standard and Data Zone Standard (US). Anthropic-hosted Claude is Global Standard only and may process data outside Azure. As of 7 November 2026 there is no EU data zone option for Claude in Foundry, so an EU-only rule excludes it there.

Abuse monitoring and who can switch it off

Abuse monitoring is part of the service by default. Automated classifiers check prompts and completions, and Microsoft says content that only goes through automated review is not stored. Content flagged by the system can be kept for human review in a data store in the geography of your resource, including for Global and Data Zone deployments. Only authorised Microsoft employees can reach it, through secure access workstations with just-in-time approval, and for models deployed in the European Economic Area those reviewers are located in the EEA.

You cannot switch it off yourself. Microsoft's limited access page says modified abuse monitoring is available only to customers and partners managed by a Microsoft account team or under an eligible programme, by application, and that some advanced models have stricter criteria. Once approved, the storage and human review steps are not performed, but automated review may still run. The current Microsoft pages we checked on 7 November 2026 state no retention period for the abuse monitoring store. Figures such as 30 days circulate in forum threads. Ask Microsoft to confirm the current period in writing instead of relying on them.

Some features keep content by design. The Responses API, threads in the Assistants API and stored completions create a data store for message history, and files uploaded for fine-tuning, batch jobs or vector stores are stored in the resource within its geography. Global Batch keeps the queued data at rest in your geography but may process it wherever the model is deployed.

Keeping Amazon Bedrock calls in the EU, and what AWS retains

On Bedrock, EU processing depends on the model identifier you call: a model in an EU Region or an EU geographic inference profile keeps requests in the EU, while a global profile does not.

The AWS re:Post Knowledge Center article on model data use says Bedrock does not store customer input and output data, does not share it with third-party model providers and does not use it to train models. The Bedrock user guide adds that each provider's model runs in a model deployment account owned and operated by the Bedrock team, which the provider cannot access, so providers have no access to your prompts, completions or Bedrock logs.

That general statement has model-specific exceptions for abuse detection. As of 7 November 2026, Bedrock's abuse detection page says classifier-flagged traffic for certain OpenAI models, and all traffic for Claude Fable 5 and Claude Fable 5.1, is retained for up to 30 days, with flagged traffic for those Claude models open to human review by AWS. Retained data stays with AWS, is not shared with the model provider and, with cross-region inference, is stored in the destination Region where the request ran. The data retention page lets you set a retention mode per Region. With the mode none, requests to models that require retention are blocked rather than retained. The legacy provider_data_share mode that appears in forum questions does not share content either: AWS states that Bedrock does not share content with model providers today.

For geographic profiles, AWS states that a profile tied to a geography such as the EU keeps requests in that geography and that its list of destination Regions never changes, while global profiles can gain Regions over time. AWS also warns against relying on the prefix in a profile ID alone. Read the destination Regions for the exact profile from your source Region before you approve it:

# 1. Active EU profiles available from Frankfurt
aws bedrock list-inference-profiles \
    --region eu-central-1 \
    --type-equals SYSTEM_DEFINED \
    --query "inferenceProfileSummaries[?status=='ACTIVE' && starts_with(inferenceProfileId, 'eu.')].[inferenceProfileId,inferenceProfileName]" \
    --output table

# 2. Destination Regions of one profile, called from Frankfurt
aws bedrock get-inference-profile \
    --region eu-central-1 \
    --inference-profile-identifier <eu-profile-id> \
    --query 'models[].modelArn'

Which models are available in Frankfurt, directly or through an EU profile, changes often, so check the current model list and the output above rather than any article, this one included. LiteLLM's Bedrock documentation notes that recent Claude models accept on-demand calls only through an inference profile, so for those models the EU profile is the realistic EU option.

If your organisation uses service control policies to block unused Regions, cross-region inference fails unless you allow the profile's destination Regions or add an exception with the bedrock:InferenceProfileArn condition. AWS also documents a policy that denies global profiles outright. Attach it to every account that may call Bedrock:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyGlobalCrossRegionInference",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": { "aws:RequestedRegion": "unspecified" },
        "ArnLike": { "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*" }
      }
    }
  ]
}

Does an EU region protect you from the US CLOUD Act

Not on its own. An EU region decides where data is processed and stored. The CLOUD Act is about which law the provider must obey. Section 2713 of Title 18 of the US Code, added by the CLOUD Act in 2018, requires providers of communication and remote computing services to preserve and disclose data in their possession, custody or control whether that data is located inside or outside the United States. Microsoft and Amazon are US companies, so choosing Frankfurt or the EU data zone does not take your data out of that scope.

Microsoft said as much in France. At a French Senate inquiry hearing on public procurement on 10 June 2025, Anton Carniaux of Microsoft France was asked whether he could guarantee under oath that French citizens' data entrusted to Microsoft through the public purchasing body UGAP would never be passed to US authorities without explicit French authorisation. He answered that he could not guarantee it, added that this had never happened, and said Microsoft commits contractually to contesting requests that are unfounded.

An EU deployment still does useful things. It keeps routine processing and stored data in the EU, and on Azure it places abuse reviewers for EEA deployments in the EEA. In our view it also makes the GDPR transfer assessment simpler to document. Whether that is enough depends on the data. For most internal assistants we consider an EU deployment with the controls in the next section a defensible choice. Where access by a foreign government is the specific risk you must rule out, as with some public sector, defence or health data, look at an EU-headquartered provider or your own servers. This guide is not legal advice. That decision belongs to your data protection officer and legal counsel.

Enforcing EU-only routing for every team with one LLM gateway

The dependable way to keep every team on EU endpoints is to make the gateway the only path to the models and give it nothing but EU endpoints to route to. With LiteLLM that takes six steps:

1. 1

   List only EU endpoints

   Each model_list entry points at a Data Zone or Standard deployment in an EU Azure resource, where LiteLLM expects azure/ followed by your deployment name, or at a Bedrock model or eu. profile with an EU aws_region_name. Put the region in the entry name, for example with an -eu suffix, so nobody has to guess.

2. 2

   Leave out wildcard entries

   LiteLLM's wildcard routing forwards any model name with a given prefix to the provider without listing it. That is convenient and defeats the purpose here, because a client could then reach a global deployment or a global. profile just by naming it.

3. 3

   Issue keys per team with an allowed model list

   Create each team with a models list and issue its keys under that team. LiteLLM documents that a key's models list both hides other models from the model listing and blocks calls to them, and that a team request for a model outside its list fails with an error naming the valid models.

4. 4

   Keep fallbacks inside the EU

   Fallbacks go from one model_name to another, fallback targets must exist in the router, and LiteLLM applies the calling key's and team's model access checks to every fallback target. With only EU entries in the list there is no global deployment to fall back to, even during an outage. Decide whether a regional outage should fail the request or move it to another EU deployment, and write that decision down.

5. 5

   Close the side doors

   Keep provider credentials only in the gateway's secret store, restrict who may create deployments in the Azure resources the gateway uses, and attach the policy above to the AWS accounts. Otherwise one Global Standard deployment created for a quick test, or a developer calling Bedrock directly with a global profile, bypasses everything above.

6. 6

   Check it on a schedule

   Once a month, list every deployment and its deployment type in the Azure resources behind the gateway, and the Bedrock models and profiles in use, then compare them with the model list. A mismatch is the first sign that someone has added a path outside the EU.

model_list:
  # Azure OpenAI: Data Zone Standard deployment in an EU resource
  - model_name: gpt-eu
    litellm_params:
      model: azure/<data-zone-eu-deployment-name>
      api_base: https://<eu-resource-name>.openai.azure.com/
      api_key: os.environ/AZURE_EU_API_KEY
      api_version: "<api-version>"
  # Amazon Bedrock: EU geographic inference profile, called from Frankfurt
  - model_name: claude-eu
    litellm_params:
      model: bedrock/<eu-profile-id>
      aws_region_name: eu-central-1
# No wildcard entries such as azure/* or bedrock/*
# No fallbacks to models outside this list

curl -X POST "$LITELLM_URL/team/new" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_alias": "claims", "models": ["gpt-eu", "claude-eu"]}'

curl -X POST "$LITELLM_URL/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"team_id": "<team-id-from-the-response>"}'

A short checklist for the data protection officer

The data protection officer needs the contract position, the list of processors and a record of every place prompts are kept. Engineering can prepare all of it:

• Processing agreement (AVV or DPA): for models sold by Azure, Microsoft points to its Products and Services Data Protection Addendum. Claude in Foundry falls under Anthropic's data processing addendum. On Bedrock, check the data processing terms of your AWS agreement. Article 28(3) GDPR requires a contract that sets out the subject matter, duration, nature and purpose of the processing.
• Sub-processors: Article 28(2) GDPR requires your authorisation before a processor engages another processor. Record who processes what: Microsoft or AWS for the model service, and on Foundry, Anthropic as an independent processor for Claude.
• Deployment inventory: every deployment and profile the gateway uses, with its deployment type or profile ID, its region and the date you last checked it.
• Abuse monitoring and retention: on Azure, where the store sits, that reviewers for EEA deployments sit in the EEA, and whether you applied for modified monitoring. On Bedrock, which of your models require retention and which retention mode each Region uses.
• Features that store content: whether anyone uses the Responses API, Assistants threads, stored completions, batch jobs or uploaded files, which keep content by design.
• Your own logs: gateway request logs, traces and cloud logging often hold full prompts, and managing them is your job. Set their retention deliberately. Our guide on AI trace data retention covers how.
• Review date: the provider pages this guide relies on were updated between May and September 2026. Recheck the sources below at least every quarter and whenever you add a model.

If the checklist shows that the models you need are not available in the EU, or the CLOUD Act question rules out US providers for some data, the options are an EU-only deployment in your own cloud account with fewer models, or models on your own servers for that data.

AI in your own AWS or Azure accountLiteLLM gateway setup and operationOn-premise AI on your own servers