A government can own its servers and still depend on an external supplier to restore a service. An organisation can use a cloud service and retain meaningful control over its information, its operating decisions and its exit options. The word sovereign becomes useful when it explains these differences clearly enough to guide a decision.
For architecture discussions, Speedykom proposes a practical working definition:
Digital sovereignty is the accountable ability to decide how digital systems and data are used, to operate them under agreed conditions, and to change their technology or suppliers when necessary.
This is an architectural lens. It complements the political and legal meaning of sovereignty; it does not replace it. A ministry, a business and a continental organisation have different mandates. The rights of the people affected by their systems must remain part of the discussion.
Start with the decision and its legitimate owner
Before selecting infrastructure, identify which decisions need to remain under whose authority. Who approves a new use of health information? Who can authorise cross-border exchange? Who decides whether an AI recommendation becomes part of a public service? Who can challenge an incorrect decision?
There may be several legitimate actors. A government establishes public policy; a regulator supervises specific obligations; an organisation manages a service; individuals hold rights over information relating to them. Regional and continental organisations coordinate shared purposes across countries. A useful governance design makes those responsibilities explicit and provides a route for resolving conflicts.
This matters particularly for Digital Public Infrastructure (DPI), where foundational systems support interactions between people, businesses and governments. The scale of those relationships makes accountability an architectural concern from the beginning. UNDP’s overview of DPI describes this public-service role.
Four dimensions that need to work together
The following four dimensions are Speedykom’s organising framework for this article series. They are a practical discussion tool, rather than a formal certification scheme.
| Dimension | The practical question | Evidence to look for |
|---|---|---|
| Authority and accountability | Who can make, review and challenge decisions? | Mandates, decision rights, escalation routes and oversight |
| Data and technical control | Who can access, process, share or stop an activity? | Identities, permissions, keys, policies, logs and data-flow maps |
| Operational capability | Who can maintain the service and recover it? | Skilled teams, access to tooling, restore exercises and funded support |
| Choice and continuity | Can the organisation adapt or change suppliers? | Usable exports, deployment rights, documented interfaces and an exercised exit plan |
The dimensions interact. An access policy has limited value if administrators can bypass it without oversight. A source-code repository is more useful when a team can build, deploy and maintain its contents. A migration clause becomes credible when someone has tested the export and measured the cost of moving.
Diagram: “Four dimensions of practical digital sovereignty”. The accompanying visual connects accountable authority to technical controls, operating capability and credible choices. It shows the decisions and evidence needed in each dimension.
Data location answers one question
Hosting location affects latency, infrastructure choices and the jurisdictions involved. Its importance depends on the service and applicable requirements. A complete assessment also follows remote administration, backups, telemetry, support access, encryption-key custody and subcontractors.
For example, a locally hosted system may still send detailed operational logs to an external service. A managed service may provide customer-controlled keys while retaining important administrative privileges. Both arrangements need an explicit description of the control boundary.
Open-source software can make inspection, adaptation and alternative maintenance possible. These opportunities depend on the licence, accessible source and dependencies, reproducible builds and the capacity to sustain operations. Those conditions belong in procurement and handover discussions.
Sovereignty can support cooperation
In a data space, participants agree how selected data can be discovered and exchanged while maintaining defined responsibilities. IDSA describes data sovereignty through control and responsibility across the data lifecycle, including access and conditions of use. IDSA’s explanation provides a useful foundation for this part of the discussion.
The practical design question is how cooperation becomes trustworthy. Participants need a shared understanding of identity, purpose, permissible use, security, remedies and the limits of technical enforcement. Once information has been delivered to a recipient, controlling every subsequent action may require contractual, organisational and assurance measures alongside software controls.
An African perspective with global relevance
The African Union Data Policy Framework connects stronger data governance with shared data spaces, digital rights and equitable economic development. The Continental AI Strategy links responsible AI with development priorities and regional cooperation. These are substantive policy references for governments and organisations designing services in Africa. AU Data Policy Framework, AU Continental AI Strategy.
Their implications need to be translated into each setting. Language coverage, connectivity, energy availability, public procurement, regional coordination and the capacity of local teams can materially shape an architecture. Requirements should be investigated with the participating organisations; Africa contains many distinct operating and legal environments.
The same working definition travels well. A European public agency, an African regional organisation and an international business can all ask who decides, who operates and what happens when a dependency changes.
How Speedykom approaches the question
Speedykom Group brings software engineering, systems integration, sovereign data architecture and AI into a shared delivery conversation. The starting point is the service’s purpose and the responsibilities around it. Architecture then makes those responsibilities concrete through data boundaries, access controls, integration choices, operating arrangements and handover.
SpeedyMesh Ecosystem contributes to this broader practice through governed data products, data spaces and AI-related capabilities. Its relevance follows the requirements of the service and the systems already in place.
A useful first conversation needs a short service description, the organisations involved and the decisions they need to retain. From there, a sovereignty assessment can identify the evidence needed to make a defensible architecture choice.
Next in the series: assessing sovereign data and AI systems through evidence, practical tests and explicit decision gates.
Explore: Speedykom’s sovereign data and AI architecture services.
Continue the series
How to assess sovereign data and AI systems: an evidence-led guide · From policy to architecture: building sovereign data and AI services