SovAIHub
ModulesAll
Topic library contents
Reference3 min read

Sovereignty terminology

Distinguish sovereignty from privacy, residency, localization, autonomy, portability, and security.

Last content review 2026-08-03Included in SAI-100, SAI-120, SAI-250

Use terms as engineering constraints

Terms such as sovereign, private, resident, secure, and autonomous are often used interchangeably. They describe different properties. In architecture work, define the property you require and the evidence that will demonstrate it.

Sovereignty

The capability to make, enforce, verify, and change material decisions about a system within an accepted dependency and authority model.

Sovereignty is multidimensional and contextual. A system can have strong data control and weak operational independence, or strong infrastructure control and weak evidence.

Data residency and localization

Data residency describes where specified data is stored or processed. Data localization usually describes a requirement to keep defined data within a jurisdiction or approved geography.

Neither term, by itself, states who can administer the service, where support access originates, which encryption authority controls keys, whether telemetry leaves the environment, or how data is recovered.

Privacy

Privacy concerns appropriate processing of personal data and the rights and obligations connected to it. A private deployment can still mishandle personal data, and a managed service can provide meaningful privacy controls. Privacy requirements are part of the sovereignty profile, not a synonym for it.

Security

Security protects confidentiality, integrity, availability, authenticity, and related properties against threats. Sovereignty depends on security, but also asks who holds decision rights, how dependencies can be changed, and whether the organization can verify control.

Autonomy and operational independence

Autonomy describes the ability to continue operating or make decisions without a particular external service or party. It may be required only for defined failure conditions or periods.

Avoid claiming total independence. Record the exact dependency, acceptable outage, alternative, restoration method, and exit plan.

Portability and reversibility

Portability is the ability to move a workload, model, data set, or operational process to another supported environment. Reversibility is the practical ability to exit a provider or architecture decision without unacceptable loss, delay, or risk.

Portability must be tested at the levels that matter: data formats, model packages, APIs, identities, policy, automation, evidence, and staff capability.

Private, on-premises, and air-gapped

  • Private means access or operation is restricted to an approved population or boundary; the precise boundary must be stated.
  • On-premises describes infrastructure location or ownership, not the complete control model.
  • Air-gapped describes a strong network separation. It does not remove the need for a controlled artifact import, identity, update, evidence, and recovery process.

Assurance and evidence

Evidence is an artifact or record supporting a claim about a system. Assurance is the justified confidence produced by evaluating claims, controls, and evidence with an appropriate level of independence and rigor.

Replace broad claims with scoped statements:

For [system and version], the organization requires control over [decision].
The control applies within [boundary] and is enforced by [mechanism].
It is verified using [evidence], reviewed by [owner], every [frequency].
The accepted external dependency is [dependency and rationale].

This pattern makes architecture claims testable and reviewable.