Why an EU region is not sovereignty, and what to ask instead

The console checkbox problem

Every major model provider now offers some form of European deployment. That is good news, and you should use it. But I have watched enough enterprise deals stall to know the conversation that follows. The buyer's DPO asks where the data goes. The vendor answers with a region name. The DPO asks who operates that region. The room goes quiet.

A region is a physical statement. It tells you which buildings hold the servers, and therefore roughly what your latency will be and which country's facility rules apply. Sovereignty is a legal statement. It asks which entity controls the service, which courts can order that entity to act, and whether an order issued abroad can reach data processed at home. The two overlap, but they are not the same question, and treating them as one is how teams end up with an architecture that satisfies the engineering review and fails the legal one.

What the CLOUD Act actually says

The Clarifying Lawful Overseas Use of Data Act, passed in March 2018, amended the Stored Communications Act so that US providers must comply with qualifying legal process for data within their possession, custody or control, regardless of whether that data is located inside or outside the United States. It was a direct response to the Microsoft Ireland litigation, which had turned on exactly the question of data stored in Dublin.

So when a US-parented provider runs a Frankfurt region, the Frankfurt subsidiary's data sits within reach of an order served on the parent, subject to the comity challenge mechanism the Act provides. Providers publish transparency reports and commit to contest overbroad requests, and many do so in good faith. None of that changes the legal reach. Anyone who tells you a US-parented service is immune from the CLOUD Act because the servers are in Germany is selling you something, and the same applies to us: YTT SECUNET PRIVATE LIMITED is incorporated in India, and we do not claim immunity from US or Indian access laws either.

What actually reduces exposure

If immunity is off the table, the useful question becomes what is available to be disclosed. A compelled disclosure order reaches data that exists. Design choices can make that set very small.

Zero data retention is the first lever. If prompts and completions stream through memory and are never written to disk, there is no stored content for a later order to reach. Customer-held keys are the second: receipts and configuration encrypted under keys in your HSM cannot be decrypted by the operator. Deployment location is the third: a data plane running in your own VPC or on premises is operated by you, under your entity, and the vendor's legal exposure becomes largely irrelevant to the content. These measures reduce risk by design. They do not eliminate it, and your transfer impact assessment should say so plainly.

• Retention: is anything written to disk, for how long, and for what purpose?
• Keys: who holds the keys for anything the service does store?
• Operation: whose employees can reach the running data plane, from where?

The hidden paths out of a region

Even with an honest regional deployment, several mechanisms can move prompts or their derivatives elsewhere. They are rarely malicious. They are usually defaults that nobody revisited when the AI feature went from prototype to production.

Abuse monitoring is the most common. Some providers retain samples of prompts and completions for a period to detect misuse, and human reviewers may look at flagged content. Exemptions often exist for qualifying customers, but they are not automatic. Global routing modes are the second: several platforms offer deployment types that send a request wherever capacity is free, which is excellent for throughput and wrong for residency. Support access is the third. If a ticket escalates to an engineer outside the EU who can attach a debugger or read logs, that is access from a third country.

Questions to put to any provider, including us

Replace the region question with a short list that an engineer and a lawyer can both verify. Ask it of your model providers, your gateway, your observability stack and anything else that sees prompts in the clear.

Do not forget the observability stack. Teams that carefully pin a model deployment to an EU region then ship full request and response bodies to a tracing vendor whose ingestion endpoint defaults to the US. The prompt has left the jurisdiction through the side door, and nobody on the AI team thinks of the logging pipeline as an importer. It is one.

• Which legal entity operates the service in this region, and who is its ultimate parent?
• Is any deployment mode able to process my requests outside the selected geography, and how do I disable it?
• What is retained for abuse monitoring, for how long, where, and can I be exempted?
• Who can access running systems or logs for support, and from which countries?
• What evidence do I receive, per request, showing where it was processed?

Sovereignty as an operating property

The last question on that list is the one most vendors cannot answer, and it is the one that matters most over time. Residency promises live in contracts and architecture diagrams, which describe intended behaviour. What auditors and supervisory authorities increasingly want is evidence of actual behaviour: this request, at this time, was resolved to this endpoint, operated in this jurisdiction, under this policy.

That is why we treat sovereignty as an operating property of every request rather than a deployment setting. A router that knows the tenant's domicile picks an in-jurisdiction endpoint, a policy engine records why, and a signed receipt goes back with the response. The region still matters. It is just the starting point of the answer, not the answer.