Data Residency Is Not the Same as Digital Sovereignty

Data residency describes the geographic location in which data is stored or processed. Digital sovereignty asks a broader set of questions: where execution occurs, which identity system grants authority, where credentials are held, which model performs inference, where evidence is retained, who controls upgrades and what outbound dependencies are required for core operation.

A service can keep records in a chosen region while still depending on a remote vendor control plane, external model API, external identity service or call-home mechanism. The storage statement may be accurate, but it does not answer whether the organisation can continue to operate, inspect and govern the system on its own terms.

The distinction is not an argument against cloud. A private or sovereign cloud can sit inside the organisation's controlled operational boundary. The meaningful test is control and dependency, not a simplistic split between cloud and physical hardware.

Execution asks where the workflow engine and runtimes operate, and whether a core process requires a vendor runtime elsewhere. Data asks where inputs, intermediate state and outputs are retained. Models ask where inference runs and who controls the model endpoint and version.

Identity asks which authority authenticates users and services, and whether role-based access and multi-factor policy remain available inside the boundary. Secrets ask where credentials are stored, retrieved and rotated. Evidence asks where workflow versions, approvals, actions and outcomes remain available for review.

These surfaces are connected. Keeping a database in-region does not help if prompts leave through an external model API, or if a remote control plane can no longer start the workflow. A sovereignty review must trace the complete operation rather than approve each component in isolation.

• 01Execution
• 02Data
• 03Models
• 04Identity
• 05Secrets
• 06Evidence

Organisations often combine on-premises infrastructure, private cloud, sovereign cloud and disconnected environments. The architecture can remain sovereign when the customer controls the runtime, access model, data paths, evidence and change process across those locations.

Conversely, equipment installed on premises is not automatically sovereign if licensing, orchestration or inference depends on an external vendor service. Physical placement is evidence, but it is not the whole test.

Nexus supports deployment on premises, in private or sovereign cloud, and in air-gapped environments. The architecture question stays the same in each case: does core operation remain under customer control, and are any configured outbound integrations explicit rather than hidden dependencies?

Ask whether a representative workflow can complete when access to the vendor is unavailable. Confirm where authentication continues, where secrets resolve, where model inference occurs and where the resulting evidence is written. Identify every telemetry path and decide whether it is required, optional or prohibited.

Then examine operational authority. Who can publish a workflow, rotate a credential, change a model version or apply an upgrade? Can the customer choose the maintenance window and preserve a known version while its own assurance process runs? Those questions expose control more reliably than a regional hosting badge.

Sovereignty does not automatically mean secure or compliant. It creates the conditions for customer control. Security configuration, operational discipline and the organisation's own legal obligations still determine the resulting posture.

Nexus runs the control plane, execution, self-hosted AI endpoints, identity integration, vault-backed secrets and execution history inside the customer estate. Workflows can combine connector actions, direct interfaces, Rules + Code, AI and human approval without depending on an external Nexus runtime.

That operating model extends to Atlas, Cerberus, Sentinel and Shield because the products inherit the same execution, identity, secret and audit foundations. Each product still has its own scope. Shared sovereignty does not collapse their different security functions.

Customers may intentionally configure outbound integrations. Those routes are part of the customer's workflow architecture and must be governed accordingly. The claim is not blanket zero egress. It is that the core platform does not require a vendor runtime or external model API to perform its work.