AI Data Residency: Four Paths Out of a Model Call

"EU hosted" on a vendor page usually describes one thing: where the inference runs, or where the data sits at rest. A model call has four separate paths out of your estate (compute, retention, human review and operator access) and each one is governed by a different clause with a different artefact proving it. Microsoft's 20 October 2026 sovereignty announcement is about the fourth, the one residency pages never described.

The reader here is the person who will have to answer where a prompt went: the IT manager, informatiemanager, IT director or security officer in a Dutch or Flemish organisation of 250 to 5,000 people. Crux Digits specifies and evidences AI alongside whoever runs the estate; we sell no beheer, no infrastructure, no hosting and no service desk. The narrow question is yours alone: what goes into an evidence pack that somebody who was not in the meeting can reproduce from scratch.

Does "EU hosted" mean stored, or processed?

Two words carry most of the confusion: stored and processed. Microsoft's own terms for models sold by Azure say both of these things, and both are true at once. On storage: for Global and DataZone deployment types, "any data stored at rest, such as uploaded data, and including the abuse monitoring data store created for Global and DataZone deployments, is stored in the customer-designated geography." On processing: "For any deployment type labeled as 'Global,' prompts and responses may be processed in any geography where the relevant model sold by Azure is deployed."

A vendor page that promises your data stays in Europe can be quoting the first sentence while the second is what happens on every call. Under the AVG an inference call is a processing operation, not a storage question, so the second sentence is the one your DPIA has to survive. That gap is not a vendor trick; it is two accurate sentences doing different jobs.

So stop asking whether a service is EU hosted and start asking which of four paths each claim covers. Two neighbours to this piece are worth reading instead of repeating: we have asked before whether a managed agent keeps its data in the EU, and the prediction that AI sovereignty would collapse into the question where is my data, actually has aged well, and our buyer-side case for a European AI partner sits beside this one. What follows is the mechanical version of all three.

Path 1: where does the inference actually run?

All three large platforms let you choose, and on all three the convenient default is not the European option.

On Azure, the deployment type decides. A Standard deployment processes "within the customer-specified geography," though it "may be processed between regions within the geography for operational purposes (including performance and capacity management)." A DataZone deployment processes anywhere inside its data zone. A Global deployment processes anywhere the model is deployed, and so does Batch. Four behaviours, one resource blade.

On Google, the endpoint decides. The EU multi-region endpoint keeps machine-learning processing (which Google defines as tuning, training and inference) inside EU member states, and the documentation is explicit that this "strictly covers data residency within EU member states," excluding the United Kingdom and Switzerland. Requests to a global endpoint, by contrast, "may be processed in any Google Cloud location around the world," and Google states flatly that global endpoints "don't provide any data residency guarantees." That page was last updated on 20 October 2026, which tells you how often this surface moves.

On Amazon Bedrock, the inference profile decides. A geographic profile routes each request to a Region inside the chosen geography; a global profile routes it anywhere. Amazon does commit that "all data transmitted during cross-Region operations remains on the AWS network and does not traverse the public internet," which answers an interception question but not a residency one.

The part worth taking into a change ticket: do not accept the claim, take the field. Bedrock writes the Region it actually used into CloudTrail, in the source Region, as additionalEventData.inferenceRegion. On Azure the deployment type is a property of the deployment, readable without asking anyone. On Google it is in the endpoint hostname your code calls. Three artefacts, reproducible by an auditor who was not in the procurement meeting, and none of them a vendor statement.

Path 2: what is kept, and for how long?

Abuse monitoring is the retention nobody buys deliberately. On Azure, a separate store exists in each geography where the model is available, and prompts and generated content are stored in the geography where the resource is deployed. Customers approved for modified abuse monitoring lose both that storage and the human review, but not the inspection: "automated review may still be conducted, leveraging algorithms including AI models that review prompts and completions at the time provided or generated." The setting is checkable rather than promised: the ContentLogging attribute appears at all, and then reads false, only when abuse-monitoring storage is genuinely off.

OpenAI's European residency works at the project boundary. An eligible API project created with European residency is handled in-region with zero data retention, and the constraint that matters operationally is that existing projects cannot be converted later; only new ChatGPT workspaces can be created with European residency at all, and in-region GPU inference for eligible Enterprise, Edu and Healthcare workspaces arrived separately on 16 January 2026. In an 800-person estate that is not a legal problem but a migration project with a list of integrations attached.

One discipline for both: file the date with the quote. The Azure terms page carried a last-updated date of 19 May 2026 when we read it this week, and a residency statement is only true as of the version you read.

Path 3: who reads a flagged prompt?

This path is missing from most residency comparisons, and on Azure it is the one with the strongest written commitment. Human reviewers see data only once it has been flagged, and they are "authorized Microsoft employees who access the data via point wise queries using request IDs, Secure Access Workstations (SAWs), and Just-In-Time (JIT) request approval granted by team managers." Then the sentence that belongs in your DPIA: "For Models sold by Azure deployed in the European Economic Area, the authorized Microsoft employees are located in the European Economic Area."

That is better than the market assumes, and it is narrow in three ways worth writing down. It covers reviewers, not support engineers. It covers models sold by Azure, not every model in the catalogue. And it says nothing about where a Global deployment processed the prompt in the first place, which is path 1 again.

Path 4: who can reach the system while it is running?

On 20 October 2026 Microsoft announced controls for exactly this path. Data Guardian adds, for EU and EFTA customers, "European-resident oversight by a trusted EU partner" for qualifying Microsoft engineer remote access, and is rolling out now. Production Touch Ledger creates "tamper-evident records of that access and the actions performed," phased across the EU and EFTA. Customer Lockbox and just-in-time access extend operator-access control, external key management with Azure Managed HSM is generally available, and a Sovereign Control Panel enters public preview at Ignite in November. At the far end of the same announcement, Foundry Local and GitHub Enterprise Local are promised generally available at that same Ignite, for connected and disconnected operation on Azure Local, and the national partner clouds (Bleu in France, Delos in Germany) get another round of top billing.

Read as a launch, that is a sovereignty story. Read as a control catalogue, it is an admission: until now the operator-access path had no customer-visible evidence at all. It is also where the incident question lands: the supplier whose engineer can reach the system is the supplier you will be calling, the other half of who gets paged when it breaks. And it gives you a cheap test for any supplier answer. If the residency reply covers paths 1 and 2, mentions neither review nor operator access, and arrives with no dates, it is answering a question about hosting while you asked one about data.

What the four paths still do not answer

Jurisdiction, and we are not the first to say so. A July 2026 analysis of Microsoft's sovereign line put it more sharply than we would: "Every Sovereign Cloud feature answers 'who operates the system.' None answers 'whose law owns the operator.'" Anton Carniaux, director of public and legal affairs at Microsoft France, told a French Senate commission of inquiry in June 2025 that he could not guarantee data on French citizens would never be passed to the United States government without the French authorities' agreement, adding that it had not happened.

So treat the four paths for what they are: a control set that makes a residency claim checkable. The legal question is answered elsewhere: in the contracting entity, in who holds the keys, and at the far end in not using that provider for that data class. Of the controls above, customer-held root keys in hardware you operate are the only one that changes the calculus rather than documenting it.

Can you put sovereignty in a tender without writing the criteria yourself?

You can borrow the European Commission's. Its Cloud Sovereignty Framework turned sovereignty into procurement criteria scored across eight objectives, from legal and operational considerations to supply-chain transparency, technological openness and compliance with EU law. Providers are graded on a sovereignty scale from SEAL-0, a demonstrated absence of sovereignty, to SEAL-4, which requires a full EU supply chain from chips to software. SEAL-2, data sovereignty, was the eligibility floor in the Commission's own tender, awarded in April 2026. Nobody is bound by it outside that tender: the Commission encourages all organisations, public and private, to use the framework, which makes the vocabulary the cheapest thing in this article.

What a Dutch IT department can ask for

The Netherlands already has a written answer to the same four paths, drafted for a buyer with more lawyers than you have. The revised Rijksbreed Cloudbeleid, sent to the Tweede Kamer on 3 July 2026, requires central-government public-cloud data to be stored and processed inside the EEA and Switzerland and encrypted in storage and transit, with public-data files the only exception to the encryption rule, not to the location rule; requires the risk of interference by a foreign government to be weighed explicitly and mitigated as far as possible; and, for material cloud use, requires a planned-exit plan and a plan for a disruptive interruption of service, both assessed yearly.

It binds every part of central government bar the Hoge Colleges van Staat, with Defence exempt and arm's-length bodies expected rather than obliged to follow, not a 900-person manufacturer in Brabant. It reaches you anyway, through tender and contract conditions, which is why it is the most useful template on the market. A Flemish reader should not adopt it as local: it is Dutch central-government policy, and Flanders runs its own cloud and certification route.

What that turns into, for an AI supplier or an internal build, is five lines in an evidence pack: the deployment type or endpoint name per environment, in writing; the retention mode plus the approval if abuse monitoring is modified; the human-review clause with the date of the page it came from; the operator-access control and where its records live; and the contracting entity with its subprocessor list.

Your ICT partner keeps running the estate. What a specialist adds is the specification and the evidence, the same discipline we bring to applied AI work in a mid-sized estate and to a private AI assistant inside your own tenant. Those five lines are the deliverable, not a slide that says EU hosted.

Frequently asked questions