Your EU AI Endpoint Can Still Send Data Outside Europe

Take one support ticket containing a passport scan, a billing dispute, and an account number. An EU customer-service team wants an AI model to summarize it, extract the requested action, and draft a reply. Its policy says the ticket and anything derived from it must remain in the EU, while human access is limited to approved EU personnel.

A vendor’s Frankfurt or EU endpoint appears to settle the matter. It does not.

The endpoint usually answers a narrower question: where does the vendor run inference, meaning the computation that turns the prompt into an output? The passport ticket can still produce an abuse-monitoring record, appear in an application log, enter a support workflow, or leave for a connected search service. Each path has its own configuration and contract language.

Regional endpoints have made hosted AI practical for workloads that previously required self-hosting or a broad residency exception. Buyers can now keep supported model processing inside a selected geography without operating GPUs. The constraint is that “the AI service” is rarely one service.

Follow the passport ticket, not the product name

Start with request processing. OpenAI’s data controls documentation distinguishes data residency, which concerns stored customer content, from regional processing, which concerns model execution.

Customers selecting Europe must create an eligible project in that region and use supported models and endpoints. A project setting cannot make an unsupported feature regional.

Microsoft makes the deployment choice explicit in Azure OpenAI deployment documentation. A regional deployment processes prompts in its Azure geography.

A Data Zone deployment can process them anywhere inside the specified data zone, while a Global deployment can process them in any Azure region where the model is available. Those options may expose different model availability and capacity.

That distinction changes the approval decision. “Hosted in an EU Azure subscription” is insufficient if the model deployment says Global Standard. For the passport ticket, the reviewer needs the deployment type, resource region, model, and endpoint together. The fallback matters too: if regional capacity is unavailable, the application should queue the ticket, switch to an approved regional model, or fail closed rather than silently call a global deployment.

AWS exposes the same tradeoff through routing. Amazon Bedrock’s [cross-region inference](https://docs.aws.amazon.

com/bedrock/latest/userguide/cross-region-inference.html) can move a request beyond its source region to obtain capacity. Geographic inference profiles limit routing to a geography such as Europe, whereas global profiles can route more broadly. Cross-region routing can improve availability, but the profile identifier becomes residency-relevant configuration rather than a performance-only setting.

The endpoint is therefore evidence, not proof. It shows where the application sent the request. The deployment documentation shows where the provider may process it.

Storage starts after the model answers

Suppose the model returns a six-line summary. The application writes that output to a ticketing database and records the prompt, token usage, request identifier, error status, and response in an observability platform. “Data at rest” means information retained on storage media, and every one of those stores needs its own region and retention rule.

Some model APIs retain customer content for safety monitoring by default, even when they do not use it for training. OpenAI documents abuse-monitoring logs that may retain API content for up to 30 days, with approved customers able to request Modified Abuse Monitoring or Zero Data Retention. Zero Data Retention is not a universal switch: some endpoints and capabilities are not eligible, while features that intentionally preserve application state need storage to work.

That creates a concrete test for the passport ticket. If the team relies on an endpoint that stores conversation state, deleting its own database copy does not necessarily delete the provider-side object. Procurement must match the selected endpoint against the vendor’s retention table, then test deletion behavior rather than extending a general API promise to every feature.

Amazon Bedrock takes a different default position. Its [data-protection documentation](https://docs.aws.amazon.

com/bedrock/latest/userguide/data-protection.html) says Bedrock does not store or log prompts and completions and does not use them to train AWS models; model providers also do not receive access to those inputs and outputs. Bedrock model invocation logging is optional. Once a team enables it, however, prompts and responses can be delivered to Amazon CloudWatch Logs or Amazon S3, so residency follows the chosen log group, bucket, encryption key, access policy, and retention setting.

That is newly practical for tightly controlled deployments: the team can keep model invocation stateless while retaining selected audit data in an EU account it manages. It also creates a familiar failure mode. An engineer enables verbose logging during an incident, sends the passport ticket to a preexisting non-EU observability destination, and bypasses the model endpoint’s regional controls without changing the model call.

Safety review and support are separate data paths

Model vendors inspect traffic for abuse, security incidents, and policy violations. Automated filtering may run alongside inference, but a flagged request can enter a different review system. Human review is the decisive issue for a policy that limits personnel location or nationality rather than storage alone.

Microsoft’s Azure OpenAI data privacy documentation says prompts and completions are not available to OpenAI and are not used to train foundation models without permission. It also describes abuse monitoring under which content flagged for potential abuse may be selected for review by authorized Microsoft employees.

Eligible managed customers can apply for modified abuse monitoring, which changes that review arrangement; deploying in an EU region does not itself grant the modification.

For the passport ticket, the contract review must separate automated processing from possible human access. The relevant evidence is the abuse-monitoring term, the eligibility decision for any modified controls, the location and authorization rules for reviewers, and the escalation path if Microsoft or another provider needs content during a security investigation.

Ordinary support creates another route. A customer may paste a request identifier, prompt, or screenshot into a vendor support case. The regional inference commitment may not cover that support portal, and account metadata such as billing details, user identities, or service telemetry can sit outside a customer-content residency promise. OpenAI’s documentation, for example, distinguishes customer content from system data and says regional commitments do not necessarily apply to system data.

The practical control is mundane: support staff should submit identifiers first, disclose content only through an approved channel, and record which vendor personnel may access it. An EU endpoint cannot constrain what an administrator pastes into a global ticketing system.

One connected tool can rewrite the answer

Now add web grounding so the draft reply can cite the company’s latest return policy. Grounding is a feature that supplies retrieved information to the model before it answers. The request no longer travels only through the selected model endpoint.

Google’s Vertex AI data-governance documentation separates core generative AI handling from feature-specific terms. Its documentation for Grounding with Google Search states that prompts, contextual information, and generated output are stored for 30 days for that feature.

A buyer cannot infer the grounding tool’s retention from the base model’s regional endpoint or general training commitment.

The same problem appears with external model context protocol servers, plug-ins, vector databases, document parsers, and SaaS ticketing connectors. A subprocessor is another company that handles data on the provider’s behalf; a customer-selected third-party tool may instead operate under its own direct terms. That legal distinction changes who promises the region, but the packet leaves either way.

For the passport ticket, the safest design is to prevent raw attachments and account numbers from reaching search or external tools. The application can retrieve the public return policy separately, then send only the policy text to the approved regional model. If the tool cannot document its processing location and retention, it should not receive regulated content.

Turn residency into six acceptance checks

A workable approval record follows the ticket through six controls: model processing, provider storage, customer-controlled logging, safety review, support access, and connected tools. For each control, record the promised geography, retained fields, retention period, possible human access, and governing document. This is a technical procurement worksheet, not a legal conclusion.

Documentation and contracts must agree. The architecture diagram names the exact deployment type and inference profile. The data processing addendum defines covered customer content and subprocessors. Service-specific terms cover abuse monitoring, support, and feature-level retention.

The production configuration then supplies evidence through project settings, resource regions, log destinations, tool allowlists, and deletion tests.

Do not accept “EU available” as the value in any field. Use an answer such as “regional Azure deployment in the resource geography” or “Bedrock EU geographic inference profile,” accompanied by the vendor page and the deployed resource identifier. Recheck after changing a model, enabling grounding, turning on invocation logging, or adding a support integration, because each change can create a new processor or storage location.

The passport ticket is approved only when the team can account for every copy. Regional inference removes the largest compute-location obstacle. It does not remove the need to trace the request after the model returns six lines of text.

Questions people ask

Does an

EU endpoint guarantee that all AI data stays in the EU?

No. It may guarantee regional processing for supported model calls, while logs, system metadata, abuse-review records, support cases, or connected tools follow different terms. Verify the exact deployment mode and trace every stored or forwarded copy of the prompt and output.

Is a zero-data-retention setting enough for residency?

Only for the endpoints and data categories covered by that setting. Stateful features may retain objects to function, while your application, cloud logs, observability vendor, and support workflow can store separate copies. Match the vendor’s eligibility table to the production endpoints and run deletion tests.

Can cross-region inference still meet an EU-only requirement?

It can if the vendor documents that the selected inference profile routes only within the required EU geography and the contract covers that processing. A global profile does not meet the same condition. Configure the application to reject unapproved profiles rather than using them as an automatic capacity fallback.

What should buyers request before approving a regional AI service?

Request the deployment type, supported model and endpoint list, retention table, abuse-monitoring terms, support-access rules, subprocessor list, and feature-specific documentation for every connected tool. Then compare those documents with the actual project region, logging destinations, inference profile, and deletion behavior.