Data Sovereignty Doctrine

Sovereignty is not a hosting location. It is the ability of an institution to decide, at any moment, how its information is processed and to continue operating if any external party is removed. AI adoption must not quietly transfer that ability to a vendor.

• Adopting advanced AI must not require surrendering custody of institutional data.
• Control must be verifiable by the institution rather than promised by a supplier.
• Capability and dependency are separable, and should be separated deliberately.

We evaluate every deployment against three distinct layers. Institutions frequently secure the first and lose the second and third without noticing.

• Data sovereignty: where information resides, who can read it, and how long it persists.
• Operational sovereignty: who can change policy, approve models, and administer the system.
• Technological sovereignty: whether models, compute, and vendors can be replaced without redesign.

Residency is the minimum condition; custody is the requirement. The institution should hold the storage, the key material, and the authority over movement of data across boundaries.

• Institution-held encryption keys and defined key-rotation authority.
• Explicit classification of what may never leave the national or organisational perimeter.
• Retention and deletion expressed as enforceable policy, not administrative practice.
• Cross-border processing permitted only by named, recorded exception.

Model selection is a data-governance decision. The control plane routes each request to the most capable model permitted for that classification, and refuses when no permitted model exists.

• Local and on-premise models for restricted classifications.
• External frontier models only for explicitly permitted, lower-sensitivity work.
• Refusal rather than downgrade when policy and capability cannot both be satisfied.
• No institutional data used for external model training by default.

Model and compute markets change faster than institutional procurement cycles. The control layer is designed to remain stable while what sits beneath it is replaced.

• Models and compute treated as interchangeable, substitutable components.
• Policy, audit, and identity configuration outlive any individual vendor.
• Exit paths defined at the start of an engagement, not at its end.
• No architectural requirement for a single foreign provider.

The operative test of sovereignty is continuity. An institution should be able to lose connectivity, a supplier, or a jurisdiction of convenience and continue to run its critical workflows.

• Documented degraded and offline operating modes.
• Institution-side custody of configuration, policy, and audit history.
• Transfer of operation to institutional personnel as a defined pilot outcome.
• No dependency on vendor goodwill for access to institutional records.

Sovereignty claims are tested during the Secure AI Assessment and the 90-day pilot, against the institution's own classification scheme and legal constraints.

• Classification and data-flow mapping for the candidate workflow.
• Deployment-mode selection driven by the strictest applicable class.
• Policy and audit review with security, legal, and oversight stakeholders.
• Written statement of residual dependencies before production use.