Data sovereignty is more than local hosting

Local hosting is often treated as an unambiguous sign of data sovereignty. Files remain on owned hardware, the model runs inside the organisation's network and no external provider receives the prompt. This can be an important component. Yet it answers only where processing happens. It does not automatically answer who controls meaning, access, versions, keys, dependencies and the ability to leave.

Local is not automatically sovereign

A locally installed system can depend on proprietary formats, non-exportable indexes or opaque model logic. It can use outdated records without recognising their status. It can distribute access too broadly and document changes poorly. The server remains on the premises while operational control remains incomplete.

Conversely, an external service can be used within a deliberately bounded architecture while canonical data, keys, rules, evaluations and exit paths remain under organisational control. Sovereignty is therefore not a binary property of location. It is the ability to make dependencies visible, retain decisions and replace a service without losing meaning.

Control begins with canonical meaning

Organisations do not merely own files. They own concepts, states and relationships. Which document governs? Which table supersedes the earlier version? Which person or role confirmed a value? Which exception applies only until a certain date? When this meaning exists only in platform configuration or individual memory, data control is fragile.

A sovereign data space keeps identity, version, provenance, validity and relationships in an exportable form. Canonical meaning must not emerge solely from filenames or search similarity. It needs explicit fields and accountable decisions.

Keys and permissions are part of data control

An organisation that encrypts data but does not control the keys has only limited control. A local system whose administrators have blanket access to every record is not a clean sovereignty model either. Data control includes key management, roles, purpose limitation and reviewable access decisions.

Not every agent, application or person needs the same data space. Rights should follow task and data zone. A research agent may read public and internal sources without seeing sensitive personnel data. An implementation agent may access project files without production customer data. A publishing process needs approved content, not the entire creation context.

Portability is a practical test

A system is genuinely controllable only when its important holdings can be exported and reused elsewhere. This includes more than raw files. Metadata, relationships, vector indexes, evaluation cases, prompt and skill versions, decision history and audit trails also matter.

An exit test is therefore more concrete than a general sovereignty promise. Can the team export the data space in documented formats? Can identities and references remain intact? Can an index be rebuilt? Can rules and tests continue in another runtime? Is it known which capability will be temporarily lost after migration?

Proprietary convenience creates invisible lock-in

Platforms create convenience by combining storage, retrieval, permissions, models and automation. The cost is often that these layers work completely only inside the same environment. A simple file export may then lose the actual working context.

This does not mean proprietary platforms should always be avoided. It means their role should be deliberately bounded. A platform can be the working interface without becoming the sole source of truth. Critical rules, identities and evaluation cases can be maintained outside it or at least in independently exportable form.

Hybrid is not automatically non-sovereign

A hybrid architecture can be more sovereign than a poorly governed local monolith. Public or low-sensitivity tasks can use external models while sensitive data, retrieval and keys remain local or within controlled EU infrastructure. The decisive issue is which data crosses a boundary, in what form and with what retention.

Model routing can also be designed deliberately. A local model handles classification or preprocessing. An external frontier model receives only abstracted or pseudonymised information. Results are reviewed before they trigger effects. The architecture distributes capability without distributing responsibility.

Data sovereignty is an organisational capability

Technical control is insufficient when nobody owns the ongoing state. Data sovereignty needs accountable owners, review dates, deletion rules, version practices, incident processes and a genuine right to object. An organisation can self-host every system and still not know which data governs, who may change it and when it becomes stale.

Sovereignty becomes most visible during conflict. Can an incorrect source be withdrawn? Are derived indexes and summaries corrected as well? Can an affected person challenge a decision? Can a dependency be terminated without collapsing the operational knowledge space?

The sovereignty model

# LOCATION AND PROCESSING
Where is data stored, where does inference happen, which logs are created?

# CANONICAL MEANING
Who defines identity, status, version, validity and relationships?

# KEYS AND RIGHTS
Who controls keys, roles, purposes and approvals?

# PORTABILITY
Which data, metadata, indexes, rules and tests can be exported?

# REPLACEABILITY
Can a provider or model be replaced without losing meaning?

# ACCOUNTABILITY
Who reviews currency, incidents, deletion and exceptions?

Local hosting can be a highly valuable part of this model. It becomes real data sovereignty only through controllable layers of meaning, access and exit. The decisive question is not simply where the file lives. It is who can explain, change, limit, export and take responsibility for what that file means inside the system.

All materials to download — the topic overview and the worksheet: