When your AI leaves the country without telling you

Most European and Swiss customers of Microsoft 365 Copilot still haven't heard about this, and the ones who have are usually finding out the way these things tend to be found out: a compliance officer reads the release notes on a Sunday afternoon and sends a Slack message that ruins somebody's Monday.

What's actually happening: as of 17 April 2026, Microsoft has switched on a feature called "flex routing" for Copilot. You'll find it in the admin centre under the slightly euphemistic label "Flexible inferencing during peak load periods." When Microsoft's European data centres are under heavy load, Copilot prompts may get sent to the US, Canada or Australia to be processed there. Encrypted in transit, encrypted at rest, but processed abroad all the same. Anyone who signed up after 25 March had it on from day one. Existing customers get it turned on by default unless an admin goes in and switches it off.

Some of the coverage has treated this as a betrayal of European customers. That's not quite right. Microsoft is a US company running a global service and flex routing, from where they sit, is an engineering choice about capacity. The more useful question is what the episode tells you about the gap between "EU-hosted" or "Swiss-hosted" as a marketing line and actual control over where your data gets touched.

‍

Storage is easy. Processing is where the exposure lives.

For years, the conversation around data sovereignty has focused on storage. Where do the files sit at rest? Which jurisdiction's data centre? Which cable runs to where? That conversation is largely solved. Almost every major vendor will happily sell you an EU region or a Swiss region for storage.

AI changes the shape of the problem. An inference isn't a file sitting on a disk. It's a moment of computation: your prompt, your attached documents, your mail context, everything the model needs to answer, all assembled and loaded into a GPU somewhere. That "somewhere" is where the data is, however briefly, in the clear. Encryption in transit doesn't help you at the inference step, because the model, by definition, has to read the input.

So when Microsoft says "data at rest stays in the EU Data Boundary," they're telling the truth and also not answering the question most regulated businesses actually care about. For a bank running under FINMA expectations, or a healthcare provider under the revised FADP, or any company with DORA obligations, the question is: who, in which jurisdiction, under whose legal process, could theoretically see this content while it's being processed? Under flex routing, the answer shifts from "Europe" to "depends on the load on Tuesday."

‍

The CLOUD Act hasn't gone anywhere

This is the part that makes the flex routing update more than a footnote. The US CLOUD Act, in force since 2018, allows US authorities to compel American companies to hand over data under their control, wherever that data physically sits. The Swiss Federal Office of Justice has written about this repeatedly. Swiss banking law and the revDSG set limits on what can leave the country, or be disclosed to a foreign authority, without going through the proper channels. A US vendor that routes processing to US soil, even briefly, sits squarely in the middle of that tension.

None of this is theoretical for financial institutions. Anyone who has sat through a FINMA audit on outsourcing in the last few years knows that "the provider says it's encrypted" doesn't close the question. Auditors want to see the data flow. They want to know who holds which key, which sub-processor runs which step, and what happens in the unhappy case where a foreign authority comes knocking. Flex routing, with its capacity-based fallback to foreign jurisdictions, is exactly the sort of thing that turns a clean diagram into a messy one.

‍

A small thing you can do this week

If you're on Microsoft 365 Copilot and you've read this far nodding, the immediate fix is quick. Sign into the admin centre with the AI Administrator role, open Copilot, go into Settings, and under "Flexible inferencing during peak load periods" choose "Do not allow flex routing." That's it. You'll trade a bit of peak-hour availability for keeping inference inside the EU Data Boundary. For most regulated workloads, that's the trade you want.

The harder, slower thing is the conversation this should start internally. If your vendor can change where your data is processed through a default setting that lands in an admin centre while everyone is on holiday, what else is like that? Which other services have a "peak load" clause buried in the documentation? Which of your AI workflows have you actually mapped end to end, from prompt assembly to response delivery?

‍

The bigger pattern

Flex routing is not the scandal some posts are making it out to be. It's a design choice, and Microsoft has been reasonably transparent about publishing the details. The real story is that it's one more data point in a pattern: when your infrastructure, your provider and your legal framework all live in different jurisdictions, someone else's engineering convenience can quietly override your compliance posture. You get a notification, you get a setting, and the burden of reading the release notes lands on your team.

The straightforward alternative: pick providers whose defaults already match the regime you operate under, who can't route your data somewhere else because they never built the pipe for it, and whose legal obligations answer to the same courts as yours. It doesn't make for dramatic blog posts. It does make for shorter audits.

‍

What Swiss sovereignty looks like, concretely

At DSwiss we come at this from a specific angle, and it's worth being honest about it. Our products are built around a few principles that make the flex routing problem structurally impossible for us, not just a setting we promise to leave off.

The data lives on servers in Switzerland, in Tier III data centres, with triple redundancy. The operating company is Swiss, governed by Swiss law, which includes the revDSG, Swiss banking secrecy where relevant, and no mutual legal assistance shortcuts for US agencies under the CLOUD Act. Encryption is AES-256 and the architecture is zero-knowledge: user content is encrypted before it lands in storage, and the platform is built so that readable customer data is not something that sits around accessible to the operation. Combine that with a jurisdiction that doesn't hand data to foreign agencies through informal backchannels and you end up with a posture that stays inside one legal regime from the moment data arrives to the moment it's deleted.

That design predates the current sovereignty conversation by quite a lot. It was built for Swiss banks, who have had these kinds of questions on their plate for decades. What's changed is that the rest of the market is catching up to the same questions, driven by GDPR enforcement, DORA, NIS2, and now the realisation that AI features bolt a whole new processing layer on top of systems that used to be mostly about storage.

If you want to talk through what any of this means for your own AI or document workflows, we're around. No hard sell. Just the specifics of how the data actually moves.