The Decision: What's Required?

In part 4, I covered buyer responsibilities, and in part 5, I addressed data leaks through code during software development. Here's the table to refresh your memory, and you can continue testing with the filters:

Five articles have now demonstrated how complex this landscape has become: thirteen routes lead to two models, each with its own data protection, its own jurisdiction, and its own endpoints. Naturally, you're left with one question: okay, but how do I choose? This final section is exactly about that. It's not about which model is best—though that matters—but about how to make good, informed decisions.

The tension of competing priorities

When the landscape gets this complicated, some people want to find one system that covers all their needs and stop thinking about the rest.

The problem is that this approach rarely works in practice. When it fails, we get exactly what we want to avoid: other solutions are brought in as half-thought-out patches to bridge a specific gap. For example, a new powerful feature is introduced as the obvious best choice in the industry.

A domino effect quickly builds when people look at others in the same field. The strongest software companies start watching Claude, software teams in the private sector follow suit so they don't fall behind, and suddenly the government, municipalities, and large financial institutions are doing the same thing.

This often creates false confidence around AI implementations. The decision is made quickly, without the careful thought and risk assessment it should have received. Then one factor carries the entire decision. Sometimes it's the price: we just use the cheapest option. Sometimes it's location: we just use what's available in the EU. Sometimes it's quality: we just use the best, no matter the cost. Each factor looks reasonable on its own, but good decisions rest on more.

Because behind these factors lie many forces pulling against each other: quality of the model, cost to run it, where the processing happens, and security around it. They rarely all point in the same direction. The best way to see it isn't to list them but to watch how the tension actually plays out. Here I'll mention a few examples most people recognize.

Before I mention a few examples most people recognize, you can weigh these four forces against your own priorities below. The scale doesn't tell you what's right—it shows you where the tension exists between them.

Quality pulls you out of Europe. Claude has become one of the strongest models for coding, and those who've tried it rarely want to switch. The same goes for others. But as soon as you want to use it fully, the quality demand often leads you straight out of European jurisdiction. As these five articles have shown, not all Claude experiences are always available within EU Data Boundary. There's a tension between quality and location: do you want the best tool or do you want to keep your data at home?

Cost pulls you the same direction. When usage is low, this matters less. But as soon as it grows, cost can start to bite, and you naturally begin looking for ways to lower it. A monthly subscription directly from Anthropic is often cheaper than running the same processing on European infrastructure through Bedrock or Vertex, so cost pulls you outside the EU—the same direction quality pulled you, but for a different reason. Cheaper and better point the same way: west. When two factors pull the same direction, it's easy to forget the other two.

The ecosystem you belong to pulls against it. But then there's the other picture, pulling the opposite way: choosing one vendor and letting the ecosystem your company belongs to decide. Here at home, it's usually Microsoft, and not because it's the cheapest option. It's because your specialists know it, there are plenty of service providers who know it, and the government once required institutions to use those solutions in the name of savings, so adoption is very widespread. Then it weighs heavier to keep everything in one place, within an environment you know and trust, than to chase the best or cheapest model every time. This is a valid decision about security and environment—but not necessarily about price or quality. It's important not to confuse them.

At the same time, a growing political and ethical tension enters the picture. There's growing discomfort with how much power is concentrated in American tech giants. On one hand, this involves ethical questions—heated debates about copyright violations, where many feel their creative work is being weighted unfairly. On the other hand, there's a changed global landscape. A tougher tone in foreign policy and threats toward neighbors create underlying uncertainty about reliability over time. But even though people clearly feel this risk, technology lock-in means companies close their eyes, follow the current, and hope cloud providers stay out of these global political matters. However, regulation is coming in Europe to work against this lock-in—it's about to be implemented in Iceland: the EU Data Act.

This uncertainty is no longer just theoretical or strong feeling. I wrote these articles a few weeks before Fable was released—the most powerful Claude model to date—but the U.S. government closed access to it for everyone except American citizens after just a few days. This development adds another layer: it's not a given that we can even access the best models in Iceland. If Western politics begins to determine which markets cloud providers can serve, this stops being just about where our data lives. It becomes whether the most powerful models are available to us at all.

And that brings us to security, which can be subtle when new tools break the framework that existed before. Say your company has built everything around AWS or Microsoft: access control, monitoring, and risk assessment. Then you add Anthropic directly because quality or cost pulled you there. Suddenly that processing stands outside the framework you'd built. You're trusting that everything around it is fine, rather than knowing it is.

And this connects directly to the processing agreement I started the whole series with. This is usually how it begins: a few developers get to try Anthropic directly. The agreement is read once at the start—if it's read at all—and then no more. Or IT sets up the solution in "testing" in-house with selected users. It works well, and then the storm hits: more and more want to use it. But the whole time it's sitting off to the side of everything else, outside the formal framework, outside the risk assessment, with a processing agreement no one has looked at since the beginning. This isn't because someone decided to bypass security. It's because the solution grew faster than the framework around it.

The conclusion isn't that one approach is right and another wrong. There's no single right setting for these factors—it depends on what your company does, what data you're working with, and what environment you operate in. Companies in finance or healthcare don't have the same room to maneuver as others working with open data. Your environment doesn't just determine what you should choose—it determines what you can actually allow yourself. The job is to deliberately balance the competing priorities based on your circumstances, not to let one factor decide and hope for the best.

What I'd want to see in the conversation

If I got a proposal or offer today, whether from a contractor or my own IT department, I'd want to see three things—and none of them should be unreasonable to ask for:

• A clear picture of where my data goes.  Which cloud provider will be used, which region, which subprocessors are involved, who has access to what, and whether EU Data Boundary actually applies to this specific model—not just the cloud in general. (The roadmap in part 3 shows this for each route).

• A clear stance on AI in the project's code development. Which tools, which model underneath, where they run, and how my code snippets and actual data are handled in development—who bears the cost of AI tools and usage. That's exactly what part 5 covered. (The risk assessment in part 5 gives a sense of the current state).

• Reasoning for the model choice. Not "we use X because it's good," but a comparison of at least two options where the competing forces are weighed—quality, cost, location, and security—with an honest answer about what limitations come with the choice we land on. Because they always do.

Any provider—contractor or your own IT department—who can answer these three things has clearly thought the matter through.

Iceland and the question of where

I'm not going to tell you whether your data should be stored in Iceland, but the articles discuss cloud providers that aren't located here. That's a bigger conversation with more sides than this article can handle—cost, competitiveness, electricity, sustainability, copyright, regulations like EU AI & Data Act, and the risk of relying on cloud providers outside your jurisdiction. But it's a conversation that's happening and it should be.

You try to measure these matters based on several factors, and that's exactly what separates an informed buyer from someone who lets one factor decide and hopes for the best. You don't need to reach the same conclusion I do. But you need to ask the questions, and you need to ask them before your data goes wandering—not after.

Where is your data? Who sees it? Where does the model run? Is EU Data Boundary active for this specific model? What kind of endpoint are we using, and what happens when load increases? What tools does the contractor use, and how does he handle your code? Who bears the cost of AI tools and usage?

If the question doesn't get an answer, that's the answer you need. It means someone is looking the other way.

And that's exactly when it's time to turn around and look.

——————————————————————————————————

This was the final part of six. If you haven't read parts 1 to 3 (the facts and overview of all routes), part 4 (the consequences—buyer responsibilities) or part 5 (data leaks through code), I recommend you review those as well. Together, the articles form the complete picture this final part builds on.

The promise doesn't hold on its own. For it to hold, you need to back it up—ask the right questions, demand transparency from your service provider, and ultimately take responsibility for your own data rather than trusting that someone else has already thought it through. No one else does that before you click the next checkbox.