Accountability: One Click and Your Data Is Exposed

In parts 1 to 3, I summarized where the EU Data Boundary works and where it doesn't, where the cloud giants run Claude and ChatGPT, and how much this varies by cloud giant.

If you want to see what your path looks like in an interactive roadmap, click here:

But facts alone change nothing. What matters is what this picture means in practice for the buyer, for the service provider, and for the responsibility that both parties bear, and that is the subject of this part.

The responsibility lies with the buyer

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

You need to realize that the next dazzling feature you see introduced at some conference or in a LinkedIn post might not appear for you, and not because it doesn't exist, but because you are a Microsoft shop and the feature first arrived on AWS, or vice versa. Or because there is some part of the Anthropic model itself that doesn't work yet due to technical architecture.

And that's where the temptation dilemma comes in.

You see there is one 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 push the button, the feature works, life goes on. Somewhere in the background, the processing of your data 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 is a single checkbox that transfers specific processing outside the EU Data Boundary.

What this means: the buyer needs to have processes in place. Not just to choose the right solution initially, but to make informed decisions when new features become available. Where does the processing take place then? Do we need to review our data processing agreements again? These are questions that need to be asked before clicking the checkbox, not after.

But this is not only the buyer's responsibility but also the service provider's, as they must convey this information to the customer to the best of their knowledge. When asked to check the box that appears in the portal that moves processing from Frankfurt to Virginia, the service provider should be able to tell the requester: "this means your data goes outside Europe, here is what you need to know before we click.”

And in cases where the service provider is also in an advisory role, the process matters even more as there can be conflicts of interest in advising a customer to use the exact solution that the service provider is best at selling or yields the most return for them. This doesn't necessarily have to be a problem  but it requires transparency about what options were considered, why a specific solution was chosen, and what limitations come with it. Transparency about where the data ends up. Transparency about when things change and what that means.

Without this transparency, the buyer is in blind faith, and blind faith is not the same thing as an informed choice.

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

In data protection law (GDPR), a distinction is made between two roles: the data controller (e. data controller) and the data processor (e. data processor). You are the controller and bear primary responsibility, which cannot be delegated. Whether the local service provider is considered a processor, however, depends on what they actually do, not what is written in the contract. Whoever hosts the system, operates it, or accesses the data on your behalf is a processor and bears independent responsibility. Anyone who merely advises, without processing personal data, is neither a controller nor a processor under the law and therefore bears no GDPR responsibility, although they may bear general advisory or contractual liability if the advice proves incorrect.

If the Data Protection Authority shows up because data was misplaced, the investigation and potential fine are always directed first at your company. It will be your name that goes in the media. If the service provider messed up or checked boxes without your written instructions, you first have to bite the sour apple regarding the Data Protection Authority, but can then, as applicable, seek recourse against the service provider. If they were a processor, the claim is based on Article 82 of the GDPR and the data processing agreement; if they were only an advisor, it is based on general contractual or tort liability. 

The blow always starts with you, but whether and how you pass it on depends on the role of the other party.

Decision time approaches

Here is something that doesn't lie on the surface, as the technology is so new that knowledge is simply not widely available yet. When you want to use Claude through a cloud giant, you can configure the Claude app to run on their infrastructure, referred to as 3P mode (third-party-mode), as I mentioned in part 2. Then your Claude request goes through Amazon Bedrock, Vertex AI, or Microsoft Foundry instead of directly to Anthropic, and you get your data processed within the environment you have already chosen. This is precisely what keeps you within the EU Data Boundary when a European region is selected. But this path comes with limitations, which are that you are not getting the full Claude experience, but rather the version of it that the respective platform supports.

Let's take a tangible example. As I discussed in part 2, Claude can use built-in tools, e.g., web search to search the internet or code execution to run code. These are standard directly from Anthropic, but as soon as you utilize them through a cloud giant in 3P mode, the picture gets complicated:

• On Amazon Bedrock, web search is not always available.

• On Vertex AI, only the basic version is available, not the same version as with Anthropic.

• On Microsoft Foundry, it is available but with the same EU Data Boundary limitations I have mentioned before, i.e., outside the EU.

And this is just one example. The same applies to code execution, computer use, managed agents, maximum request size, and when the newest models are introduced, meaning each cloud giant is at its own pace with its own list of what is supported and what is not.

What this means in practice: when it comes to making a decision, you have to choose and compromise, and sometimes you have to live with certain limitations for the time being. You cannot have everything like the newest features, European processing, the lowest price, the most convenient environment, all in the same package.

Who bothers to read the fine print?

It is also right to keep one thing in mind that matters: hosting personal data within the EEA is not just "recommended" - it is a legal obligation under Icelandic data protection law (no. 90/2018) and GDPR. Transferring personal data to countries outside the EEA is explicitly prohibited unless the receiving country ensures adequate protection, or appropriate safeguards are implemented, such as standard contractual clauses (SCCs) along with a formal transfer impact assessment (TIA).

Why then is it so common for companies to just trust what the cloud giants say and not investigate further? There are several common reasons:

• Immense complexity of the regulatory framework. After the Schrems II ruling, companies face high complexity and high costs in compliance, and performing a TIA and setting up technical safeguards is simply such a massive undertaking that it is not within everyone's reach to do it well.

• Lack of understanding. In many cases, there is not enough understanding - companies simply do not realize that their data is being transferred to the United States at all. In the City of Reykjavík's Seesaw case, managers believed that school children's data did not leave the EEA, but an investigation showed otherwise.

• Blind faith in cloud services. Many companies trust that Microsoft, AWS, or Google bear all responsibility for data security. The reality is that cloud security is based on a shared responsibility model: the service provider takes care of the infrastructure, but the Icelandic company as the data controller bears full legal responsibility for the processing and where the data goes. If your service provider (the processor) changes the technical setup so that data leaks, the authorities will fine you first, and it will be your job to seek damages from the service provider afterwards. You cannot transfer the legal responsibility for your customers' data to a third party.

• Lack of viable European alternatives. For many companies, it is simply unthinkable to run their business without US software (Microsoft 365, AWS, or other cloud solutions). When few or no comparable European alternatives are available, companies prefer to take the risk and hope for the best rather than sacrifice operational efficiency.

The requirement is therefore clear and unambiguous in the law when companies look the other way, and it is not because the law is unclear, but because it requires a lot of work, expertise, and cost to comply with it. The Data Protection Authority, however, has shown that complexity does not excuse violations when cases are examined, as the City of Reykjavík received a 5 million ISK fine and an order to delete data in the Seesaw case (The Supreme Court annulled both in 2024 due to procedural flaws by the Data Protection Authority, but confirmed that violations had occurred).

The legal risk is real, and it rests on the buyer and not on the cloud giant.

An expiration date on every statement

There isn't exactly something wrong with the system when you don't get the latest feature right away,  that's just the status at a given point in time. It changes rapidly, but never exactly the way you were hoping. Features you were waiting for finally arrive, but on a different platform. Processing you wanted in the EU is on the way, but not this year. Tools you wanted to use work, but just not all the features you wanted.

And here is the core of the matter: you cannot choose the best cloud giant - the partner that will have everything exactly as you want, because development is so rapid that no status quo remains for long.

If someone tells you today: "this is the best option for you", then that may well be true at that second, based on the premises that exist exactly then, but it is good to keep in mind: there is an expiration date on that statement. It can be counted in months, but sometimes in weeks and days. Such is the speed.

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 the 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 accept this, without rushing to the next checkbox that offers you all the best today, because "all the best today" often means having to sacrifice something at the same time; you must be ready to reassess 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 is not the same agreement today

A data processing agreement you read through and signed three years ago is not the same agreement today. Not because someone tricked you, but because that's how these contracts are structured from the start.

When you sign a DPA with the major cloud giants, you are not just accepting the content of the document as it looks on the day of signing. You are also giving prior consent for new subprocessors to be added later. The Microsoft DPA says, for example, that "from time to time, Microsoft may engage new Subprocessors". Microsoft commits to giving at least six months' notice for customer data, even shorter for other things, but this is primarily a notice, not a request for permission, and the same applies to the other cloud giants.

This is exactly what happened in January 2026 when Anthropic became a subprocessor for Microsoft 365 Copilot. Microsoft did not need to get consent from every company and institution using Copilot because they updated the subprocessor list on their website, sent a notice, and the matter was settled. A company that read the DPA document three years ago and thought "yes, this is all in the EU region, this is fine" now suddenly has Anthropic in the United States as a processor for part of the Copilot queries without a single sentence being changed in the contract itself (Assuming you turn on the model).

Here is where this gets even more complex: the DPA is not the only contract that applies. Microsoft divides its terms into several parts: (the names of these terms are prone to change)

• DPA Terms which are the general rules on data protection

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

• Online Services Terms which are the business terms themselves

• Service-specific notices which are notices about individual features

In the Microsoft DPA it states clearly: "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 plain English: DPA rules apply generally, but Product Terms can exclude individual 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". That is not a change to the DPA. It is a provision in the Product Terms that applies specifically to Claude.

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

What this means in practice:

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

• You need to read the Product Terms, not just the DPA. That is where new exceptions appear.

• You have the right to terminate if a new subprocessor is unacceptable to you; most cloud giants then allow termination of the associated service without penalty but within a certain period. But that would rarely be a trivial decision, and if you say nothing, it counts as consent.

• Risk assessment. What went through a DPIA (data protection impact assessment) three years ago might need a reassessment today based on a new subprocessor or new processing regions.

This kind of regulatory framework is not designed to keep information from customers, but rather to be scalable so they can maintain a competitive advantage by offering new features that the market wants, and cloud giants cannot negotiate individually with everyone who uses their services. 

But the consequence is that responsibility shifts entirely to you: you must monitor the changes yourself and react when they occur.

Processing agreements and what they do not say

Data processing agreements (DPA) have become standardized among cloud giants, and they are generally fine as a foundation. They specify where data is stored at rest, how encryption is handled, and that the data is not used to train the models.

But where they get vague is in the following areas:

• When a user sends a query to the AI where is the "processing region"? Is it the same region you thought you had selected?

• Who is the subprocessor and in what locations are they? Anthropic as a subprocessor with AWS is entirely different from Anthropic as a main processor through their own API.

• What tools are actually available and what data goes through them when they are used?

• What happens to logs and telemetry – all cloud giants look at some information related to you, at some time, for some reason. Some allow turning this off, others do not.

• Whether, for example, Flex Routing is enabled and under what circumstances your query or processing then goes outside Europe.

These are questions you should be able to ask, and if the answer is "that's just how it is" or "what is stated in the terms with Microsoft " then there is reason to pause and examine things more closely.

This was part 4 of six. Here we covered the consequences of not looking into these matters and that responsibility lies with the buyer, that the service provider needs to have transparent information disclosure, and that processing agreements cannot just be signed and put aside without review.

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

In the final part, part 6, I will address model selection and why it rarely works out to choose one system and stop thinking about the others? How a false sense of security is created when entire sectors follow each other into the same solution? And what I would want to see myself in a conversation with a service provider if I were a buyer today.