EU AI Data Residency and Sovereign AI: A Practical Guide

Enlarge

"Our AI runs in Europe" sounds precise. Often it only describes one hop.

An AI request can enter a gateway in Frankfurt, fail over to a model in the United States, write its prompt into an observability database and still sit inside a system described as EU hosted. The claim only means something if it holds across the entire request path.

The practical way to assess AI residency is to follow a request from the application to the model and back. Then do it again for the failure path.

This guide explains how to do that with Requesty. It covers where Requesty processes requests, how to restrict models and fallbacks to EU regions, what Requesty stores, how zero data retention works, how to produce evidence that the policy held, and where the idea of sovereign AI goes beyond an AI gateway.

What do EU residency and sovereign AI mean?

These terms get used as though they mean the same thing. They do not.

In this guide, end-to-end EU residency means a configuration where Requesty processing happens through the EU gateway, only EU-region model deployments are permitted, every fallback stays in the EU, and Requesty's payload storage policy has been set deliberately rather than left at its default.

Sovereign AI asks more questions. Who owns the infrastructure? Which country's laws apply to the provider? Can non-EU support staff reach the environment? Who controls encryption keys? Could the organisation keep operating if a supplier withdrew service? Can the model or the workload move somewhere else?

The European Commission's Cloud Sovereignty Framework reflects that broader reading. It covers legal and jurisdictional control, data and AI control, operations, supply chains and technological independence, rather than treating server location as the whole answer.

So where does Requesty fit?

Requesty is the policy and enforcement layer between an application and its model providers.

We control which endpoint an application uses, which models it may call, which regions are permitted, where a failed request may be rerouted, whether request content is stored by Requesty, and which users or API keys can change any of those decisions.

We do not turn a globally hosted model into an EU-hosted one. We do not change the corporate ownership or legal jurisdiction of an upstream provider. That is the boundary of what Requesty can enforce.

What can Requesty enforce?

Here is the practical answer before the detail.

Requesty's EU gateway runs in AWS eu-central-1 in Frankfurt. The EU endpoint keeps Requesty's processing and storage in the EU, but it does not by itself restrict the upstream model to an EU deployment. Approved Models, EU region filters and region restriction supply that second half.

Where does the complete inference process happen?

With Requesty's EU configuration, the basic request path looks like this.

The EU base URLs are:

A minimal OpenAI-compatible configuration looks like this.

import os
 
from openai import OpenAI
 
client = OpenAI(
    api_key=os.environ["REQUESTY_API_KEY"],
    base_url="https://router.eu.requesty.ai/v1",
)
 
response = client.chat.completions.create(
    # This example assumes an EU-only routing policy called "eu-production".
    model="policy/eu-production",
    messages=[
        {
            "role": "user",
            "content": "Summarise this support request.",
        }
    ],
)
 
print(response.choices[0].message.content)

Using the EU endpoint determines where Requesty handles the request. The model value determines where inference happens. That is the first distinction a deployment team should write down.

Do not forget the systems around the gateway

The complete data flow usually contains more than the gateway and the model:

• Application logs
• A vector database
• A retrieval or search service
• Object storage
• An application performance monitoring tool
• A SIEM
• A customer support platform
• An analytics warehouse
• A model provider's own logs or caches

Requesty can enforce the path between the application and the model. You still need to assess the rest of the architecture. A RAG application with an EU gateway and a vector database in the United States does not have an end-to-end EU-resident data path.

Why is an EU gateway only half the answer?

By default, sending a request through an EU gateway does not mean the selected model runs in Europe. A request can follow this path.

The call to Requesty stayed in the EU. The inference did not.

To prevent it, create an organisation-wide list of Approved Models and filter that list by region and data policy. Requesty checks every model request against the allowlist, routing policies may only select models the organisation has approved, and requests for anything else are rejected.

How an EU deployment is identified depends on the provider. AWS Bedrock uses regions such as eu-central-1, eu-west-1 and eu-north-1, Azure uses names such as francecentral and swedencentral, and Vertex has its own European deployments. Requesty exposes that metadata in the Model Library, so policies can be built against current region data rather than a static list maintained in application code.

Enlarge

A residency policy only works if applications cannot bypass it. There is an important difference between guidance, configuration and enforcement.

Requesty enforces this at the organisation level. Restricting allowed Requesty regions to the EU means clients must use the matching regional domain, and requests arriving through the global domain or another region are rejected. Combined with an EU-only Approved Models list, that controls both sides of the request: which Requesty gateway an application can use, and which model deployments it can reach.

What happens when the primary model fails?

This is where residency designs usually break. A team selects an EU-hosted primary model carefully, then configures a generic global fallback for availability. Everything looks correct until the primary model times out.

Requesty fallback policies try eligible models in order when a request hits an error, a rate limit or a timeout, and policies can filter targets by provider, region and data policy.

Enlarge

Residency has to survive failure

An EU-only policy needs to cover the primary model, every fallback, every load-balancing target, any automatic provider substitution, retry behaviour, disaster recovery routes and the manual runbook an engineer follows at three in the morning.

Approved Models is the safety net underneath all of that, because a routing policy cannot select a model outside the organisation's approved set. Requesty rejects a request for a model outside the list on failover, load balancing and automatic routing, and does not substitute a different model, provider or hosting region.

Enforcement is visible in the response. A request for a model outside the approved set is stopped by the router before any provider sees the data, and comes back as an HTTP 403.

A custom policy also makes the intended behaviour easy to inspect.

Policy: eu-production
 
1. Primary:  Provider A, Frankfurt
2. Fallback: Provider A, Ireland
3. Fallback: Provider B, EU deployment
4. Otherwise: fail the request

Compare that with:

Policy: global-availability
 
1. Choose any available model
2. Optimise for latency
3. Use global fallback

The second policy is useful for a public, non-sensitive workload. It should not serve a workload with a strict EU-only requirement.

What data does Requesty store, and where?

There are two categories to separate:

• Telemetry, which describes what happened.
• Payload data, which contains what the user and the model said.

Conflating them produces vague answers such as "we store logs" or "we are zero retention". A useful assessment needs to be more specific.

Requesty encrypts stored data with AES-256 and uses TLS 1.2 as a minimum, TLS 1.3 by default, in transit. Customer personal data stored by Requesty is stored in Frankfurt in all cases, whichever endpoint you call. The endpoint choice decides where routing, caching and logging happen.

Enlarge

Observability does not require storing every prompt

Most security and compliance teams need to know that the policy operated. That is a metadata question.

None of that requires a permanent copy of the customer's message, the retrieved documents or the model's full response. It is a useful design principle well beyond Requesty: store enough evidence to prove the policy operated, and do not retain sensitive content merely because an observability product makes it easy.

There is a real trade-off to record. Where logging is disabled or ZDR is enabled, Requesty holds no prompt or output content, and therefore cannot search for, extract, rectify or delete that content on your behalf when a data subject asks. That is a consequence of the configuration, and it is worth writing into your own data subject process before you turn ZDR on.

Is customer data used for model training?

There are two separate answers.

Does Requesty train models on customer data?

No. On a paid plan Requesty does not use customer prompts, outputs or tool call content to train, fine-tune, evaluate, benchmark or otherwise improve any model, whether its own or a third party's, and does not sell, rent, share or licence that content. That obligation is contractual, it survives termination, and it applies to every model in the catalogue.

A small number of models in the catalogue are made available by their provider on terms where the provider retains prompts and outputs and uses them to train its models, in exchange for free access. Every one of those is free, no model Requesty charges for is one of them, and they are labelled as training-permitted in the product, in the model metadata returned by the API and in the model library. On a paid plan they are excluded for your organisation by default and Requesty rejects requests for them, whether or not you have configured Approved Models. Making them available takes a written request from an authorised administrator.

Does the upstream model provider train on customer data?

That depends on the provider, the endpoint, the plan and the contract.

Requesty's Model Library exposes data policy metadata per model: data retention, whether data may be used for training, privacy notes, and provider and deployment information. That metadata reproduces the provider's own published position, which Requesty checks against their published terms and updates when it becomes aware of a change.

Enlarge

How do you make the policy technically enforceable?

The strongest compliance control is usually the one an application team cannot switch off by accident.

Approved Models gives you the organisation-wide allowlist. Access Lists narrow that list for a group or an individual key. RBAC, groups and enterprise SSO separate policy administration from routine application use.

Enlarge

Guardrails scan requests and responses for personal information, credentials and secrets, and financial data such as payment card and banking details. Because automated detection produces both false positives and false negatives, treat guardrails as one layer of the design rather than the whole privacy strategy.

Separate policy ownership from application ownership

The team building an application usually needs to use a key, call approved models, review its own usage and see errors and latency. That is not the same as being able to add a global model, disable the EU-only allowlist, change organisation-wide logging, enable a training-permitted provider or edit every production fallback.

This is where an AI gateway becomes more than a convenience layer. It separates application code from organisation-wide policy.

Where does the evidence come from?

Configuration screenshots prove what a setting looked like on the day someone took the screenshot. A compliance review usually wants something harder: what the policy was, and what the traffic did under it, over a period.

The Compliance page in Requesty answers both in one place. It shows each control's current policy next to what was observed over a selected period, and it generates a point-in-time report you can download as a PDF or as JSON.

Enlarge

Three things make this more useful than a screenshot folder.

The controls you can change from the same page

The Compliance page is not only a report. The controls that decide the answers are editable in place, and each change is recorded in the audit log.

Restricting allowed Requesty regions is the self-serve form of strict endpoint enforcement. Choose the regions that may serve your requests, and clients must then use the matching regional domain. Requests arriving through the global domain or another region are rejected, so residency no longer depends on every application being configured correctly. Changes take effect immediately for all traffic.

Enlarge

Requesty zero data retention stops Requesty storing request and response content for the whole organisation, across every existing and future key, and overrides content logging configured on individual keys. Usage metadata such as model, token counts, cost and latency is still recorded. Enabling it is deliberately one-way: turning it off again takes a written request to Requesty.

Enlarge

Requiring model zero data retention is the control for the layer Requesty does not own. With it on, Requesty only routes to models whose providers neither retain request data nor use it for training, and rejects models that fail that test even when they are on your approved list. This is the setting that closes the gap between "we enabled ZDR" and "no provider in our path retains content".

Enlarge

The provider side of the report answers the questions a reviewer asks next: how much traffic went to providers that retain or train, where the models that served it were hosted, whether requests used Requesty-managed credentials or your own keys under BYOK, what the guardrails found, and how many configuration changes were made by how many people.

Enlarge

How do you configure an EU-resident deployment?

This checklist is written for a production deployment rather than a proof of concept.

1. 1
   Define the boundary first

   • Write down whether the requirement is EU gateway processing, EU inference, end-to-end EU residency or a broader sovereignty requirement.
   • List the countries and regions that are permitted.
   • Decide whether EEA locations outside the EU are acceptable.
   • Decide whether non-EU-owned providers operating EU infrastructure are acceptable.
   • Identify the personal, confidential or regulated data you expect in prompts and responses.

   Do not begin with model names. Begin with the boundary.

2. 2
   Point applications at the EU endpoint

   • Configure the EU base URL in every production application.
   • Keep API keys in an approved secrets manager.
   • Remove global Requesty endpoints from production configuration templates.
   • Confirm no network or proxy rule rewrites the endpoint.
   • Restrict allowed Requesty regions to the EU where you need a hard boundary.
3. 3
   Approve only acceptable model deployments

   • Filter the Model Library by EU region.
   • Review data retention and training attributes.
   • Add only acceptable regional deployments to Approved Models.
   • Exclude ambiguous global endpoints.
   • Record the provider, model, region and data policy decision for each one.
4. 4
   Create workload-specific Access Lists

   • Create separate groups for workloads with different sensitivity.
   • Attach narrower model lists to higher-risk teams or keys.
   • Avoid a single unrestricted organisation-wide key.
   • Give every production key an owner and an expiry process.
5. 5
   Build EU-only routing and fallback policies

   • Choose an EU-region primary model.
   • Add only EU-region fallback models.
   • Review load-balancing targets.
   • Remove global catch-all policies.
   • Decide whether the request should fail closed when every EU target is unavailable.
   • Test the failure path before launch.
6. 6
   Choose the storage policy

   • Decide whether prompt and response logging is genuinely required.
   • Disable payload logging on keys that do not need it.
   • Enable organisation-wide ZDR where no Requesty payload storage is permitted.
   • Review and delete historical logs separately where required.
   • Agree the telemetry retention period you need.
7. 7
   Review the upstream provider policy

   • Confirm the model endpoint's location.
   • Confirm provider-side retention and whether submitted data may be used for training.
   • Confirm whether abuse-monitoring exceptions apply.
   • Review support and administrative access locations.
   • Turn on the model zero data retention requirement where no provider in the path may retain content.
   • Use your own provider account through BYOK where you need that contractual control.
8. 8
   Apply request and response guardrails

   • Identify the sensitive data categories relevant to the workload.
   • Run in report mode first, then move to mask.
   • Test masking and false-positive behaviour with realistic examples.
   • Decide what happens when detection is uncertain.
   • Apply separate controls against prompt injection and tool abuse for agentic applications.
   • Keep source documents out of prompts where they are not needed.
9. 9
   Restrict access to the control plane

   • Configure SSO for administrative users.
   • Assign least-privilege roles.
   • Separate platform administrators from application developers.
   • Use service accounts for applications rather than personal keys.
   • Revoke unused and compromised keys promptly.
   • Review privileged access on a schedule.
10. 10
    Complete the contractual review

    • Accept the Requesty DPA and record when it took effect.
    • Review the subprocessor list, both infrastructure and model providers.
    • Review every model provider your organisation permits.
    • Confirm the breach notification and deletion terms against your own policy.
    • Record the international transfer mechanism that applies to your configuration.
    • Connect all of it to your DPIA or vendor assessment.
11. 11
    Test, then keep the evidence

    • Attempt to call a non-approved model.
    • Attempt to use a Requesty endpoint outside your allowed regions.
    • Trigger a primary-model failure and confirm every fallback stayed in the approved region set.
    • Inspect the selected model and region in request telemetry.
    • Confirm prompt and response bodies are absent under ZDR.
    • Generate the Compliance report for the period and store it with the request IDs from your tests.
    • Record the date, the tester and the outcome.

How do you verify the configuration?

Configuration screenshots are useful. Failed tests are stronger evidence. A deployment review should include both normal and adversarial tests.

The evidence pack

For a higher-risk workload, keep one compact pack:

• Architecture diagram
• Approved Models export
• Access List configuration
• Routing and fallback policy
• Logging or ZDR configuration
• Guardrail configuration
• Test results, with request IDs
• The Compliance report for the period, PDF or JSON with its payload hash
• The DPA and the date it took effect
• Subprocessor review
• Provider data policy review
• Owner and review date

That is a great deal more useful than a statement that the system is hosted in Europe.

How anwalt.de runs EU-only AI in production

The design above is not hypothetical. Here is what it looks like at scale in a regulated market.

What does the Requesty DPA cover?

Technical configuration and contractual protection should describe the same system. Here is what the Requesty DPA says, clause by clause, so you can check the two against each other.

The DPA is Requesty's standard processor agreement under GDPR Article 28. It applies to every customer, takes effect on acceptance of the agreement and does not need a separate signature to bind. You are the controller and Requesty is the processor for personal data processed in providing the service. Where you are yourself a processor for a third-party controller, Requesty is your sub-processor. For account information, such as administrator names and billing records, both parties act as independent controllers.

The residency clauses match the product

The DPA states residency in two layers, and it says plainly that both are required for processing to stay inside the EEA end to end.

That second card is the whole argument of this guide, written into the contract.

The clauses worth reading before you sign

The technical and organisational measures schedule is specific rather than decorative. Production runs in Tier III facilities in Frankfurt with no Requesty-operated data centre. Encryption is AES-256 at rest and TLS 1.2 as a minimum with TLS 1.3 by default in transit, with keys in a managed KMS on a documented rotation. Prompt and output content is excluded from application logs and error traces. Production access is role-based and least privilege, through a bastion host, with SSO and mandatory MFA, no shared accounts, quarterly access reviews and revocation within 24 hours of a leaver. Access to customer prompt and output content is restricted to a named support group, requires a ticket recording the business reason, and is logged. Backups are encrypted, retained for 35 days and replicated to a second EEA region.

International transfers

Data stored by Requesty stays in Frankfurt whichever endpoint you use. Where you use the EU endpoint and restrict Approved Models to EEA-hosted deployments, no restricted transfer of prompt or output content arises at all. Where you use the EU endpoint but select a model hosted outside the EEA, a restricted transfer arises at the inference layer and the transfer clauses apply. Where you use a global endpoint, data remains stored in Germany but transient processing such as routing and caching may happen outside the UK and EEA.

For the transfers that do arise, the DPA incorporates the European Commission Standard Contractual Clauses with the selections written out: Module 1 for account information as independent controllers, Module 2 where you are controller and Requesty processor, Module 3 where you are a processor and Requesty your sub-processor. The docking clause applies, sub-processor authorisation is general with 30 days' notice, and the SCCs are governed by the laws of Ireland with disputes before the Irish courts. For UK transfers the UK International Data Transfer Addendum version B1.0 is incorporated. Swiss transfers are read across to Switzerland with the FDPIC as competent authority. Requesty is not certified under the EU-US Data Privacy Framework and does not rely on it. A transfer impact assessment covering the infrastructure subprocessors is available at the Trust Centre.

Sensitive data has its own conditions

Special category data under Article 9 and criminal conviction data under Article 10 are not expected in the standard configuration. They may be processed only where organisation-wide ZDR is enabled, you have a lawful basis and have completed any required assessment, and you have restricted Approved Models to providers whose published position is that they do not retain content. In every configuration, and regardless of ZDR, children's data, government identifiers and payment card data must not be transmitted.

That clause is worth reading next to the guardrails configuration. The contract says do not send it; guardrails are the mechanism that helps you catch it when someone does.

Administrative or support access from outside the EEA can matter to a transfer analysis even when the server is in Europe. That is one reason sovereignty assessments look at access and jurisdiction rather than storage location alone.

Where does sovereign AI go further?

An end-to-end EU-resident request path is measurable. Sovereign AI is less binary. Different buyers use the term for different combinations of EU processing, EU-controlled operations, EU ownership, protection from third-country legal access, customer-controlled encryption keys, model portability, open-weight models, independence from a single hyperscaler, EU-based support, supply chain continuity, and the ability to run without a foreign control plane.

The European Commission's framework separates data and AI control from legal, operational, supply chain and technological sovereignty. That is a useful way to avoid reducing the topic to a data centre pin on a map.

Requesty Ltd is a UK company, the EU gateway runs on AWS infrastructure in Frankfurt, and you choose the upstream model provider. That combination supports an EU data residency requirement without automatically satisfying a procurement rule that every organisation in the supply chain must be EU-owned.

So we would describe Requesty as a control layer for EU-resident and sovereign-oriented AI deployments. We would not describe it as a sovereignty label that overrides the characteristics of every provider behind it.

Three practical deployment levels

Is Requesty the right EU AI gateway for this use case?

Those are valid requirements. They are also broader than EU routing, and an AI gateway is the wrong tool to satisfy them.