The Decision: What's Required?

In Part 4, I covered the responsibility of buyers, and in Part 5, I addressed data leaks through code during software development. Here is the table for review, and you can experiment with the filters:

Five articles have now been dedicated to demonstrating how complex this landscape has become: thirteen paths to two models, each with its own data protection, its own jurisdiction, and its own endpoints. Naturally, the reader is left with one question: fine, but how do I choose? This final part is precisely about that. It is not about which model is best, although that matters, but rather how to make good and informed decisions.

A Tug-of-War of Temptations

When the landscape becomes this complex, one can feel that some people want to find a single system that covers all their needs and stop thinking about the others.

The problem is that this approach rarely works in practice. When it fails, exactly what we want to avoid happens: other solutions are brought in as a sort of afterthought to bridge a specific gap—for example, when a powerful new feature is introduced that is supposed to be the best option in the industry.

This quickly creates a certain domino effect when looking at others in the same sector. The most powerful software houses start looking to Claude, software departments in the private sector follow suit so as not to miss the train, and suddenly the state, municipalities, or large financial institutions have started doing the same.

This often creates a false sense of security around AI implementations. The decision is made in a hurry without all the reflection and risk assessment that should have characterized the decision, and then one single factor is seized upon and made to carry the entire decision. Sometimes it is the price: we just use the cheapest. Sometimes the location: we only use what is within the EU. Sometimes the quality: we only use the best, no matter what it costs. Each point looks sensible on its own, but a good decision stands on more.

Because behind these points actually lie many opposing forces: the quality of the model, the cost of running it, where the processing takes place, and the security surrounding it. They rarely all point in the same direction. The best way to see this is not to list them but to look at how the conflict actually manifests, and here I mention a few that most people will recognize.

Before I mention a few examples that most people are familiar with, you can match the four forces to your own priorities below; the scale does not tell you what is right, it shows you what tension exists between them.

Quality pulls you outside of Europe. Claude has become one of the most powerful models for coding, and those who have tried it rarely want to switch, and the same goes for Cowork. But as soon as you want to utilize it to the fullest, the quality requirement often leads you directly outside European jurisdiction, because as these five articles have shown, the full Claude experience is not always available within the EU Data Boundary. There, quality clashes with location: do you want the best tool or do you want to keep the data at home?

Cost pulls you to the same place. When usage is low, this matters less, but as soon as it grows, the cost can start to bite, and then one instinctively starts looking for ways to lower it. A monthly subscription directly with Anthropic is often cheaper than running the same processing on European infrastructure through Bedrock or Vertex, and thus cost pulls you outside the EU—the same way quality did for a different reason. Cheaper and better point in the same direction: west, and when two factors pull in the same direction, it is easy to forget the other two.

The ecosystem you belong to pulls in the opposite direction. But then there is the other picture, which pulls in the opposite direction: choosing one supplier and letting the ecosystem the company belongs to decide. Here at home, that is most often Microsoft, and that is not because it is the cheapest option. It is because your experts know how to work with it, there is an abundance of service providers who know it, and the state at one point obligated institutions to use those solutions in the name of savings, so the penetration is very high. In that case, keeping everything in one place, within an environment you know and trust, weighs heavier than chasing the best or cheapest model at any given time. This is a valid decision about security and environment, but not necessarily about price or quality, and it is important not to confuse the two.

Alongside this, growing political and ethical friction plays a role. There is growing discomfort regarding how much power is concentrated in the hands of US tech giants. This relates on one hand to ethical aspects, such as noisy disputes over copyright infringement where many feel their own intellectual property and creativity are being encroached upon, and on the other hand to a changed international landscape. A harsher tone in foreign affairs and threats toward neighboring nations create an underlying uncertainty about long-term reliability. But even though people clearly feel this risk, vendor lock-in causes companies to close their eyes, follow the trend, and hope that the cloud giants stay out of these matters in the international arena. However, a regulation has been enacted in Europe to combat this lock-in, which has yet to be implemented in Iceland: the EU Data Act.

This uncertainty is no longer just theoretical or a strong feeling. I wrote these articles a few weeks ago, before Fable was released, which is the most powerful Claude model to date, but the US government blocked access to it for everyone except US citizens after only a few days. That development adds yet another dimension: it is not a given that we will get access to the best models in Iceland at all. If politics across the ocean start to dictate which markets cloud giants are allowed to serve, then this is no longer just about where our data lies, but whether the most powerful models are available to us to begin with.

That brings us to security, which can be tricky when new tools break the existing framework. Suppose the company has built everything around AWS or Microsoft: access control, monitoring, and risk assessment, and then you add Anthropic directly because quality or cost pulled you there; suddenly that processing stands outside the framework you had built. You have started trusting that everything around it is in order, rather than knowing it.

And this connects directly to the data processing agreement with which I started the entire series. Because this is usually how it begins: a few developers get to try Anthropic directly, the agreement is read once at the beginning—if it is read at all—and then not again. Or the IT department puts the solution into "testing" internally with selected users. It goes well, and then a storm hits: more and more people want to use it. But all the while, it sits to the side of everything else, outside the formal framework, outside the risk assessment, with a processing agreement that no one has looked at since the beginning. This is not because someone decided to bypass security, but rather that the solution grew faster than the framework around it.

The conclusion is not that one way is right and another is wrong. There is no single correct configuration for these factors, and the weight depends on what the company is doing, what data is being processed, and what environment they operate in. Companies in the financial or healthcare sector do not have the same leeway as other companies working with public data. The environment dictates not just what you should choose, but what you can actually afford to choose. The task is to consciously balance the tug-of-war based on your circumstances and not let one single factor dictate and hope for the best.

What I Would Like to See in the Conversation

If I received a proposal or an offer today, whether from a contractor or my own IT department, I would 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 giant is to be used, which region, which subprocessors are involved, who has access to what, and whether the EU Data Boundary actually applies to this specific model and not just to the cloud in general. (The roadmap in Part 3 shows this for each path).

• A clear stance on AI in the project's coding. Which tools, which underlying models, where they run, and how my code snippets and actual data are handled in development, who is to bear the cost of the AI tools—exactly what Part 5 was about. (The risk assessment in Part 5 gives an idea of the current status).

• Justification for the choice of model. Not "we use X because it is good", but a comparison of at least two options where the competing forces are weighed: quality, cost, location, and security, and an honest answer about what limitations come with the chosen option. Because they always come with limitations.

The party, whether a contractor or your own IT department, that can answer these three things has clearly thought the matter through to the end.

Iceland and the Question of Where

I am not going to tell you whether your data should reside in Iceland, but the articles discuss the cloud giants that are not located here. That is a larger conversation with more sides than this article can handle—cost, competitiveness, electricity, sustainability, copyright, regulatory frameworks like the EU AI & Data Act, and the risk that comes with relying on these cloud giants outside our own jurisdiction. But it is a conversation that is ongoing and should be.

One tries to evaluate these matters based on several aspects, and that is precisely what distinguishes an informed buyer from one who lets a single factor dictate and hopes for the best. You do not have to arrive at the same conclusion as I did. But you need to ask the questions, and you need to do so before your data  goes wandering, not after the fact.

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

If the question does not get an answer, then that is the answer you need. It means someone is looking the other way.

And that is precisely the time to turn around and take a look.

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

This was the final part of six. If you have not read Parts 1 to 3 (the facts and an overview of all paths), Part 4 (the consequences—buyer responsibility), or Part 5 (data leaking through code), I recommend skimming through those as well. Together, the articles form the big picture on which this final part is built.

The promise does not keep itself. If it is to hold, effort must be put into it—asking the right questions, demanding transparency from your service provider, and ultimately taking responsibility for your own data rather than trusting that someone else has thought the matter through to the end. There is no one else who will do it for you before you click the next checkbox.