Skip to main content
Back to Perspectives

Data Residency Does Not Give You AI Control

Hyperity

Perspective ·

Network cables plugged into a server rack in close-up

Image: Jordan Harrison on Unsplash

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 personal or confidential data is involved, data location quickly becomes part of the architecture discussion. GDPR does not impose a general requirement that all data must remain in the EU, but transfers outside the EEA introduce additional legal and contractual requirements.

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.

Hosted AI services may retain prompts, outputs or abuse-monitoring data for a defined period. The scope varies by provider, product and contract. Retention, access and incident-handling rules therefore need to be verified rather than assumed.

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.

Why control matters for PineHive

PineHive is being built as an AI-native casework platform for document-heavy expert workflows—not as a finished product with every deployment option available on day one. The working hypothesis is that many organisations need a clearer control layer around AI-assisted preparation and review. That includes workflows where quality, sources, model version, operations, security and cost can be measured together: relevant source material is retrieved, supplied to the model and preserved for review alongside the output.

Data residency and inference location are part of that picture. For sensitive casework, where data is stored and processed is not a side note—it is a prerequisite for trustworthy use of AI in the workflow.

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 interested in conversations with organisations evaluating controlled AI-assisted workflows for repeatable expert work—where data residency, operational control and review requirements need to be explicit, not assumed.

Sources