Processing data in Europe matters. It does not, however, tell you who controls the model, the operations, the keys, the updates or the ability to change provider.
When AI is discussed in Europe, the conversation often stops at data residency. When customer data or personal data is involved, GDPR quickly becomes central. Under GDPR, where data is stored and processed is a major point. But is it enough that data stays within the EU?
If the service runs in a European region, a large part of the problem can feel solved. I understand why the discussion lands there. It is a concrete requirement that can be written into a contract and checked in an architecture diagram.
But data residency is only one part of control. A service can run in Europe and still be tightly bound to a model owner, an API, a support chain or an update policy that the customer does not control. That dependency often becomes clear only when something changes, fails or needs to be moved.
Questions about what is logged, and whether data can be sent elsewhere for inference, matter. So does how long logs are retained. AI model operators often require logging that cannot be turned off, arguing that it is part of their security routines if an incident occurs. Incidents do happen. The compromise involving OpenAI and Hugging Face was a reminder that logging can be necessary when something goes wrong.
Control is more concrete than big labels
I sometimes think we make this question larger than it needs to be. For a buyer, the goal is not complete independence. That is neither realistic nor necessary. The real work is knowing which parts of the solution you must be able to steer, and which dependencies you accept.
The European Commission's Cloud Sovereignty Framework points in the same direction. It uses 48 criteria across eight areas, including legal, data and AI, operations, technology, supply chain and security. The useful idea is that control can be broken down, required and compared.
For AI, a few questions quickly become practical:
- Do we know exactly which model version is used, and can we pin it?
- Can we reproduce a result and see which sources and tools were used?
- Who has administrative access to data, logs and keys?
- Can the workflow move to another model or operating environment without being rebuilt?
These are not philosophical questions. They affect incident response, procurement, cost and how long the solution can actually be operated.
More self-operation is not automatically better
There is also a trap in the other direction. A self-managed environment or an open-weight model is not automatically safer. Taking more control also means taking more responsibility for patching, monitoring, permissions, testing and competence.
For low-sensitivity tasks, an established cloud service can be entirely reasonable. For a long-lived, business-critical workflow, customer-controlled keys, pinned model versions or the option of dedicated operations may matter more. The right level depends on the task. It cannot be generalised to every case.
When I choose an AI provider, the most important points are that data storage can be secured, that it is clear where inference runs, that logs are removed after a defined period, and that access to those logs is strictly limited and used by the provider only in the event of a security incident.
What Hyperity Core will test
Hyperity Core is an initiative, not a finished product. The hypothesis is that some Nordic organisations need a clearer control layer around AI workflows. The first test is a document and tool workflow where quality, sources, model version, operations, security and cost can be measured together: a classic RAG flow in which prior knowledge is enriched with AI, and AI helps produce a high-quality output.
It is not enough that a model gives a good answer in a demo. It has to work on the real task, in Swedish, at a reasonable cost, with a review chain the organisation accepts. If customers do not value the extra control, that is also an important result.
Data residency is important, but it is the beginning. The better question is: what control does this task require, who has it today, and can that be shown in practice?
Hyperity is looking for conversations with Nordic technology and business leaders who want to challenge that hypothesis. The conversation is about real requirements, not about selling a finished platform.
Sources
- European Commission: Cloud Sovereignty Framework explained (48 criteria across eight control areas)