Accountability: One Click and Your Data Is Exposed

In parts 1 through 3, I reviewed where EU Data Boundary works and where it doesn't, which cloud providers run Claude and ChatGPT, and how different these implementations are across providers.

If you want to see how your path looks in the interactive guide, click here:

But facts alone don't change anything. What matters is what this picture means in practice for the buyer, for the service provider, and for the responsibilities both parties carry—and that's the focus of this section.

The responsibility sits with the buyer

The responsibility for this choice sits with the buyer. Not the cloud provider, not the reseller, not Anthropic. With you.

You need to understand: that shiny new feature you see announced at some conference or in a LinkedIn post might not show up for you—and not because it doesn't exist, but because you're a Microsoft shop and the feature landed first on AWS, or vice versa. Or because there's something in the Anthropic model itself that doesn't work yet due to technical constraints.

And then comes temptation.

You see there's a checkbox in the portal that says "Enable Anthropic models". Or "Allow cross-region inference". Or "Switch to Global endpoint for higher availability". Someone decides to click it, the feature works, life goes on. Somewhere in the background, your data processing has just moved from Frankfurt to Virginia, without anyone noticing.

This is exactly what happens in M365 Copilot when an admin enables Anthropic in an EU tenant. There's one checkbox that moves certain processing outside the EU Data Boundary.

What this means: the buyer needs processes. Not just to choose the right solution upfront, but to make informed decisions when new features become available. Where will the processing happen? Do we need to review our processing agreements again? These are questions you need to ask before you check the box, not after.

But this isn't just the buyer's responsibility—the service provider has a role too. They need to communicate this information to the customer in good faith. When someone asks to check that box in the portal—the one that moves processing from Frankfurt to Virginia—the service provider should be able to tell them: "this means your data goes outside Europe; here's what you need to know before we click it."

And when the service provider is also in an advisory role, process becomes even more critical, because there can be conflicting interests in recommending the exact solution the service provider is best at selling or that brings the most margin. It doesn't have to be a problem—but it requires transparency about which options were considered, why the solution was chosen, and what limitations come with it. Transparency about where data ends up. Transparency about when things change and what that means.

Without that transparency, the buyer is flying blind, and blind faith isn't the same as informed choice.

How does this chain of responsibility work when a service provider is involved?

In privacy law (GDPR), there's a distinction between two roles: data controller and data processor. You're the data controller and you carry the primary responsibility—and it can't be delegated. Whether your service provider counts as a processor depends on what they actually do, not what the contract says. Anyone who hosts the system, operates it, or has access to data on your behalf is a processor and carries independent responsibility. Anyone who just advises, without processing personal data, is neither controller nor processor under the law and carries no GDPR responsibility—though they may carry general advisory or contract responsibility if the advice turns out to be wrong.

If privacy authorities show up because data went missing, the investigation and any fine always start with your company first. Your name will be the one in the news. If the service provider messed up or checked a box without your written approval, you'll face the regulators first, but you can then, depending on circumstances, pursue a claim against the service provider. If they were a processor, the claim is based on Article 82 of GDPR and the processing agreement; if they were only an advisor, it's based on general contract or liability law.

The hit always lands on you first, but whether and how you pass it on depends on the other party's role.

It comes down to a choice

Here's something that isn't obvious on the surface, partly because the technology is still new enough that the knowledge simply hasn't spread widely yet. When you want to use Claude through a cloud provider, you can set your Claude app to run on their infrastructure—that's called 3P mode (third-party mode), as I mentioned in part 2. Your Claude request then goes through Amazon Bedrock, Vertex AI, or Microsoft Foundry instead of going directly to Anthropic, and you get your data processed within the environment you've already chosen. This is exactly what keeps you within EU Data Boundary when a European region is selected. But that path comes with limitations—you don't get the full Claude experience; you get the version that platform supports.

Let me give you a concrete example. As I covered in part 2, Claude can use built-in tools like web search to search the internet or code execution to run code. These are standard directly from Anthropic, but the moment you use them through a cloud provider in 3P mode, things get complicated:

• On Amazon Bedrock, web search isn't always available.

• On Vertex AI, only the base version is available, not the same version as at Anthropic.

• On Microsoft Foundry, it's available but with the same EU Data Boundary limitations I mentioned earlier—meaning processing happens outside Europe.

And that's just one example. The same applies to code execution, computer use, managed agents, request size limits, and when new models arrive—each cloud provider is on their own timeline with their own list of what's supported and what isn't.

What this means in practice: when it comes to a choice, you have to decide what to prioritize, and sometimes you live with certain limitations for now. You can't have the latest features, European processing, the lowest price, the easiest interface, and everything else in the same package all at once.

Who has time to read the fine print?

There's also something important to keep in mind: storing personal data within the EEA isn't just "recommended"—it's a legal requirement under Icelandic privacy law (No. 90/2018) and GDPR. Transferring personal data to countries outside the EEA is strictly prohibited unless the destination country provides adequate protection, or appropriate safeguards are put in place like standard contract clauses (SCCs) along with a formal transfer risk assessment (TIA).

So why is it so common for companies to just trust what the cloud providers say and not dig deeper? There are several common reasons:

• The regulation is enormously complex. After the Schrems II ruling, companies face high complexity and high costs in compliance, and conducting a TIA and setting up technical safeguards is simply such a massive undertaking that it's beyond many organizations to do well.

• Lack of understanding. In many cases, there's simply not enough knowledge on hand—companies don't realize that their data is typically being transferred to the US. In the Seesaw case involving Reykjavik City, managers thought student data wasn't leaving the EEA, but investigation showed otherwise.

• Over-trust in cloud services. Many companies believe that Microsoft, AWS, or Google carry all the responsibility for data security. The reality is that cloud security is built on a shared responsibility model: the provider handles the infrastructure, but your Icelandic company, as data controller, carries full legal responsibility for the processing and for where data goes. If your service provider (the processor) changes their technology so data leaks, regulators fine you first, and it's then your job to seek compensation from the service provider. You can't delegate your legal responsibility for customer data to a third party.

• Lack of realistic European alternatives. For many companies, it's simply not feasible to run their operations without US software (Microsoft 365, AWS, or other cloud solutions). When few or no comparable European alternatives exist, companies choose to take the risk and hope for the best rather than sacrifice operational efficiency.

The requirement is clear and unambiguous in law when companies look the other way, and it's not because the law is unclear—it's because meeting those requirements takes significant work, expertise, and cost. Privacy authorities have shown that complexity doesn't excuse violations when cases are examined, as Reykjavik City received a 5 million króna fine and was ordered to delete data in the Seesaw case(Iceland's Supreme Court reversed both in 2024 due to procedural defects in the Privacy Authority's handling, but confirmed that violations had occurred).

The legal risk is real, and it sits with the buyer, not the cloud provider.

Timelines on every statement

There's nothing inherently wrong with not getting the newest feature right away—that's just the state at a specific moment in time. It changes fast, but never quite the way you hoped. Features you've been waiting for finally arrive, but on a different platform. Processing you wanted in the EU is on its way, but not this year. Tools you want to use work, but not all the capabilities you wanted.

And here's the core of it: you can't choose the best cloud provider—the partner who will have everything exactly the way you want—because the pace of change is so rapid that no state lasts long.

If someone tells you today: "this is the best option for you," that might well be true in that moment, based on the conditions at hand right then—but it's worth keeping in mind: that statement has a timeline. You can measure it in months, but sometimes in weeks or days. That's how fast things move.

A new model arrives. A new region opens. A new feature appears at a competitor. Microsoft gets Anthropic, and suddenly Microsoft has access to Claude—but only outside EU Data Boundary. When Sweden Central finally opens for Anthropic within Europe, as Microsoft has announced, the situation changes again. This happens week after week.

You need to be able to live with this—without jumping at the next thing that promises you everything best available today, because "everything best available today" often means you have to give something up somewhere. You need to be ready to re-evaluate your choice regularly, because whoever was best three months ago might not be best for you anymore.

The processing agreement you read three years ago isn't the same one today

The processing agreement you read and signed three years ago isn't the same one today. Not because someone pulled a fast one on you, but because that's how these agreements are structured from the start.

When you sign a DPA with a large cloud provider, you're not just agreeing to the content of the document as it looks on signing day. You're also giving advance consent for new subprocessors to be added later. Microsoft's DPA says, for example, "from time to time, Microsoft may engage new Subprocessors." Microsoft commits to notifying with at least six months' notice for customer data, sometimes less, but it's primarily a notice, not a request for permission—and the other cloud providers have the same thing.

This is exactly what happened in January 2026 when Anthropic became a subprocessor for Microsoft 365 Copilot. Microsoft didn't need consent from every company and organization using Copilot—they updated their subprocessor list on their website, sent a notice, and it was done. A company that read the DPA three years ago and thought "yes, this is all on EU infrastructure, this is fine" suddenly has Anthropic in the US as a processor for part of Copilot without a single sentence changing in the contract itself(Assuming you turn on the model).

Here's where it gets even more complicated: the DPA isn't the only agreement that applies. Microsoft splits their terms into several parts: (the names of these terms tend to change)

• DPA Terms, which are the general privacy rules

• Product Terms (or Product-specific Terms), which are specific rules for each product and each model

• Online Services Terms, which are the business terms themselves

• Service-specific notices, which are notices about individual features

Microsoft's DPA clearly states: "The DPA Terms apply to all Products and Services except as described in this section. The DPA Terms will not apply to any Products specifically identified as excluded ... in the Product Terms." In other words: DPA terms apply generally, but Product Terms can exclude specific models like Claude from certain rules. This is what happens with the statement that "Anthropic models are out of scope for the EU Data Boundary." It's not a change to the DPA. It's a provision in Product Terms that applies specifically to Claude.

So when someone says "we reviewed the processing agreement three years ago and it was fine," the right answer is: that might well be true, but the DPA is just one layer of terms. The other rules change, and sometimes without anyone noticing.

What this means in practice:

• You need to monitor changes to subprocessors. Microsoft, AWS, and Google all keep lists of subprocessors on their websites. You can sign up and get notifications.

• You need to read Product Terms, not just the DPA. That's where new exclusions show up.

• You have the right to terminate if a new subprocessor is unacceptable to you—most cloud providers allow termination of the related service without penalty, but within a specified period. But that's rarely an easy decision, and if you don't say anything, it's treated as consent.

• Risk assessment. What went through a DPIA (Data Protection Impact Assessment) three years ago might need reassessment today based on new subprocessors or new processing regions.

This regulatory framework isn't designed to keep information from customers—rather, it allows scale: the cloud providers maintain competitive advantage by offering new features the market wants to adopt, and they can't negotiate custom terms with every single customer using their service.

But the result is that responsibility shifts entirely to you: you need to track the changes and respond when they happen.

Processing agreements and what they don't say

Processing agreements (DPAs) have become standardized among cloud providers, and they're generally fine as a foundation. They specify where data is stored at rest, how encryption is handled, and that the data won't be used to train models.

But where they get fuzzy is in these areas:

• When a user sends a query to an AI model, what is the "processing region"? Is it the same one you thought you selected?

• Who is the subprocessor and where are they located? Anthropic as a subprocessor at AWS is completely different from Anthropic as a primary processor through its own API.

• Which tools are actually available and what data flows through them when they're used?

• What happens to logs and telemetry—every cloud provider looks at some information related to you, at some point, for some reason. Some let you turn it off; others don't.

• Whether flex routing is active and under what conditions your query or processing leaves Europe.

These are questions you should be able to ask, and if the answer is "that's just how it is" or "what Microsoft's terms say," there's reason to pause and look more carefully.

This was part 4 of six. Here I've covered the consequences of not understanding these issues and that responsibility sits with the buyer, that the service provider needs to be transparent, and that processing agreements can't just be signed and set aside without review.

In part 5, I'll cover a specific problem affecting many companies: software development with AI, and how customer data can leak out through the code itself without anyone noticing.

In the final section, part 6, I'll discuss the choice of model and why it usually doesn't work to pick one system and stop thinking about others. How false security develops when entire sectors chase each other into the same solution. And what I would want to see in a conversation with a service provider if I were a buyer today.