Data sovereignty is more than local hosting

A server location tells you where processing occurs. Data sovereignty tells you who can determine, inspect, restrict, transfer and terminate that processing.

"We run the system locally, so the data is safe" sounds reassuring. It confuses location with control. A server may sit inside the organisation and still have weak administrator privileges, unencrypted backups, uncontrolled updates or undocumented remote access. An external service may provide controls that a small organisation could not operate alone, while creating dependencies, subprocessors or international transfers that require deliberate assessment.

Data sovereignty is therefore not a property of a data centre. It is an organisation's demonstrable ability to govern data and derived artefacts throughout their lifecycle. The scope includes inputs, documents, embeddings, caches, logs, backups, models, configurations and outputs. Looking only at primary storage misses much of the real processing environment.

Local describes placement, not a level of trust

On-premises, private cloud, public cloud, edge and hybrid are deployment models. None is automatically secure, sovereign or unsuitable. Risk emerges from the combination of data class, purpose, architecture, access, supply chain, operations and jurisdiction.

NIST Zero Trust provides a useful principle: physical or network location does not create implicit trust. An internal device may be compromised, a privileged account misused, and a local service may still retrieve packages or send telemetry to external systems. Every request therefore needs justified, bounded and verifiable authorisation.

The stronger question is not "Is it local?" but "Which control claim can we prove for this data flow?"

Data sovereignty has six control dimensions

A defensible assessment separates at least six dimensions:

1 · Legal and contractual control: who determines each purpose, who processes on whose behalf, and which subprocessors and regions are involved?

2 · Technical control: which systems store, transmit or transform data, and how are interfaces, tenants and environments separated?

3 · Operational control: who may configure, update, restore, monitor and handle incidents?

4 · Cryptographic control: who holds keys and may use, rotate, disable or destroy them?

5 · Portability and exit control: can data, metadata, rules, logs and dependencies be exported completely and operated elsewhere?

6 · Evidence and audit control: can access, change, deletion and exceptions be reconstructed with reliable evidence?

A platform may be strong in one dimension and weak in another. A single sovereignty score without this decomposition conceals more than it decides.

Map the data journey before evaluating the platform

An architecture decision begins with a Data Flow Map. It records source, purpose, classification, transfer, processing, storage, derived artefacts, recipients, retention and deletion path. For AI applications this includes prompt histories, search indexes, vector representations, caches, evaluation data, security logs, support dumps and telemetry.

A locally executed model may process documents on a workstation while downloading extensions from external package sources. A local search service may create embeddings through a remote interface. Support staff may copy logs from a European environment into a global ticketing system. Sovereignty is decided at these transitions, not by the marketing label of the primary system.

The map must distinguish intended from observed behaviour. Architecture diagrams show planned connections. Network observation, configuration review, supplier information and testing reveal which connections actually exist.

Roles and contracts must match technical reality

Privacy roles are not freely chosen product labels. Responsibility and processing on behalf of another party follow real purposes and decision-making power. Contracts should describe processing, instructions, confidentiality, security, subprocessors, assistance, return, deletion and audit rights in a way that matches the architecture.

A subprocessor list is only a beginning. The organisation needs to understand each party's task, access, location, replacement procedure and technical boundary. Supplier-chain changes require a defined assessment and, where appropriate, objection or exit options. Paper control without technical verification is incomplete; technical control without accountable roles is equally incomplete.

Identity is the new perimeter

An internal network is not an identity. Access is bound to people, services, devices and workloads. Least privilege, strong authentication, time-limited administrator access, separate service accounts and verified machine identities reduce the impact of compromised credentials.

Break-glass accounts, support access and automation secrets are especially sensitive. They need an owner, purpose, expiry, logging and regular recertification. A local administrator with permanent unrestricted access may create more risk than a tightly bounded external service. Conversely, a cloud control panel must not become the single weak switch for data, keys and backups.

Encryption becomes meaningful only with key control

"Encrypted" does not answer who can decrypt. Distinguish encryption in transit, encryption at rest, application-level encryption and key management. Provider-managed keys simplify operations but may leave the operator with broad technical capabilities. Customer-managed keys shift control while creating duties for rotation, backup, permissions, availability and emergency recovery.

The key-custody chain matters: who creates the key, where it is held, who authorises its use, which logs are created, and what happens after a role change, incident or contract termination? A key that cannot be recovered threatens availability. A key that too many people can export threatens confidentiality.

Local operations have distinct failure patterns

Local systems can reduce certain external data flows and suit isolated or latency-sensitive scenarios. They also transfer operational responsibility to the organisation. Patch management, hardware failure, physical protection, endpoint security, backup separation, monitoring, incident response and staff coverage must be delivered in practice.

Common weaknesses include shared administrator accounts, backups in the same physical failure zone, missing restore tests, outdated dependencies and unnoticed telemetry. "No internet connection" helps only when software supply, data transfer and maintenance are controlled. A removable drive or improvised support tunnel can bypass the assumed boundary immediately.

Cloud operations shift responsibility; they do not remove it

Cloud services can offer mature security capabilities, redundancy, automation and rapid scaling. The organisation still controls data classification, configuration, identity, purpose, permissions and supplier selection. Misconfigured storage, excessively broad roles and uncontrolled exports are not cured by certificates.

Evaluate tenant isolation, regions, support access, telemetry, subprocessors, key options, recovery, availability and contract changes. International transfers are a separate legal and technical question. A region name alone does not prove that every access and downstream process remains there.

Hybrid architecture requires explicit trust boundaries

Hybrid is not automatically the safe compromise. It multiplies interfaces, identities, synchronisation paths and operating models. For each boundary, define which data may pass, who initiates transfer, how content is filtered, what happens when the connection fails and which side is authoritative.

A useful pattern keeps raw data inside a controlled zone and transfers only minimised, approved artefacts. It works only if transformation and re-identification risk are assessed. Embeddings and aggregate features may still contain sensitive information; "derived" does not automatically mean "anonymous".

Deletion includes copies and derivatives

A "delete record" button does not prove complete deletion. A deletion design distinguishes production data, replicas, caches, search indexes, logs, backups and derived artefacts. It defines timelines, exceptions, technical execution, restoration effects and evidence.

Backups often cannot be modified selectively without undermining integrity. The organisation then needs justified retention, access restrictions and rules that re-apply deletions after restoration. For trained or fine-tuned models, determine whether data can be reconstructed, whether a model artefact must be replaced, and which deletion claim can actually be supported.

Exit capability is part of the architecture

Sovereignty becomes visible when a relationship ends. An Exit Plan identifies exportable data formats, metadata, identities, keys, rules, configurations, logs, models, licences and dependencies. It defines timelines, cost, ownership, parallel operation, validation and deletion confirmation.

A CSV export is rarely enough. Without schemas, relationships, version history and provenance, content may be professionally unusable. Proprietary interfaces and managed specialist services increase switching cost. Such dependencies are not inherently wrong, but they must be visible, assessed and tested before adoption. An annual test export is stronger evidence than an untested contract clause.

Control must be measured and renewed after change

An architecture decision is not a permanent certificate. New models, regions, packages, subprocessors, administrator roles and logging features change the control state. Each critical data flow therefore receives an owner, control objective, test, evidence, review interval and escalation rule.

Useful measures include orphaned privileged accounts, key age, failed restore tests, unclassified exports, unauthorised endpoints, deletion backlog and time to revoke access. An Architecture Decision Record captures assumptions, alternatives, rationale, residual uncertainty and exit conditions. Material change triggers targeted reassessment.

Method: MAP → CLASSIFY → CONTROL → VERIFY → EXIT → REVIEW

MAP records actual flows and derivatives. CLASSIFY assigns purpose, sensitivity, roles and consequences. CONTROL implements identity, keys, permissions, retention and contracts. VERIFY tests configuration, behaviour, recovery, deletion and evidence. EXIT tests portability and termination. REVIEW examines change, incidents and effectiveness.

The outcome is not a universal recommendation for local or cloud. It is a reasoned architecture decision in which every material control claim has an owner and evidence.

Worksheet: Build a Data Sovereignty Control Map

1. Select a real AI data flow and map source, processing, storage, derivatives and recipients.

2. Classify raw data, prompts, embeddings, logs, backups and outputs separately.

3. Assign owner, operator, region, identity and key custody to every stage.

4. Define one control each for access, transfer, retention, deletion and change.

5. Define evidence: which test proves that each control works in practice?

6. Simulate a supplier change or system outage and document export, restart and deletion.

7. Name three residual uncertainties and assign who must resolve them by when.

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

Scope: This article presents an architecture and control model, not legal advice. Applicable duties depend on roles, data, purpose, region and risk classification. "Local", "cloud" and "hybrid" are deployment forms, not universal quality or compliance seals.

Sources and professional scope