When your AI leaves the country without telling you

‍Microsoft's Copilot "flex routing" can send EU prompts abroad under load. Here is what it means for FINMA, DORA and revDSG compliance, and how to switch it off.

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 April 17, 2026, Microsoft has switched on a feature called "flex routing" for Copilot. You'll find it in the admin center under the slightly euphemistic label "Flexible inferencing during peak load periods." When Microsoft's European data centers are under heavy load, Copilot prompts may be 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 March 25 had it on from day one. Existing customers get it enabled 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 is 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 center? Which cable runs to where? That conversation is largely solved. Almost every major vendor will 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 operating under FINMA expectations, 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 is 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 kind 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 center 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 little 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 center 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 SecureSafe 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 centers, with triple redundancy. The operating company, DSwiss AG (the Swiss entity behind SecureSafe), is 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 operator. Combine that with a jurisdiction that does not 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 has changed is that the rest of the market is catching up to the same questions, driven by GDPR enforcement, DORA, NIS-2, and now the realization 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.