A policy may require responsible data sharing, organisational control and human oversight of AI. Delivery teams need to translate those intentions into identities, permissions, interfaces, operating procedures and tests.
Speedykom Group’s architecture perspective connects those layers. Software engineering, systems integration, data governance and operating capability need to be considered together, especially when a service spans governments, businesses, civil society, and regional or continental organisations.
The reference pattern below illustrates that translation. It is a design for discussion; a real deployment needs its own requirements, threat analysis and verification.
Begin with a bounded service
Choose a service that participating organisations can describe and govern. An illustrative agricultural use case could exchange approved crop indicators between national teams and a regional coordinator. An energy service could share selected capacity or maintenance information. An Africa Health Data Space could exchange approved information for a defined health purpose.
These examples describe possible architecture requirements, rather than project outcomes. The first decisions concern purpose, participants, permissible use, sensitivity, quality, accountability and the people affected by the service.
Translate those decisions into a small set of acceptance conditions. For example: a participant can approve an outgoing data product; an unauthorised consumer receives no response; an operator can trace a transfer; a designated team can recover the service.
Keep each participant’s control boundary visible
Within an organisation, domain teams can prepare governed data products from existing systems. Each product needs a responsible owner, an understandable schema, quality expectations and rules for use. The original systems may continue to serve their existing operational purposes.
Across organisations, a data space provides arrangements for discovery and governed exchange. A catalogue can publish selected metadata; identity and trust mechanisms establish who is participating; agreements describe the authorised use; transfer controls handle the approved exchange. The precise data movement follows the use case: a federation can still involve copying selected information, and the handling of those copies must be governed.
The boundary is also operational. Administration, support access, keys, backups and incident response should be assigned explicitly. A regional coordinator’s discovery role should not silently give it unlimited access to participants’ source systems.
Diagram: “A governed path from local data to shared services”. Two participant boundaries connect through agreed exchange. Each keeps its source systems, identities and operating responsibilities visible. An AI service consumes only information authorised for its purpose.
Give standards distinct jobs
Standards are useful when teams know which problem each one addresses.
| Reference | Architectural purpose |
|---|---|
| Bitol Open Data Contract Standard (ODCS) | Describe data contracts, including structures and expectations around a data interface |
| Bitol Open Data Product Standard (ODPS) | Describe data products and their associated metadata |
| IDS Reference Architecture Model (IDS-RAM) | Structure architectural roles and design discussions for data spaces |
| IDSA Rulebook | Inform organisational roles, trust and governance arrangements |
| Dataspace Protocol (DSP) | Define interactions for catalogue exchange, agreement negotiation and transfer processes |
These references help different layers fit together. A machine-readable data contract does not, by itself, settle legal permissions. A protocol implementation needs compatibility testing against the relevant specification and partner implementation. Applicable legal obligations need a separate assessment.
The source materials are available from Bitol ODCS, Bitol ODPS, IDSA’s architecture knowledge base, the IDSA Rulebook and IDSA’s DSP overview.
Make AI choice operational
An AI layer introduces further processing and decision boundaries. Define which models can be used for which purposes, where inference runs, which data may reach it and who approves changes. Hosting can be on premises or in an approved cloud environment, depending on the service’s requirements and operating resources.
The architecture should isolate provider-specific integration where practical, maintain evaluations for representative tasks and document the dependencies of each model. An interchangeable API helps with substitution; model behaviour, licence conditions, hardware needs and retrieval dependencies still require assessment.
For retrieval-based services, enforce access at retrieval time and assess what is retained in prompts, traces and outputs. AI-assisted actions need permissions proportionate to their consequences. Where a person must authorise an action, the workflow should preserve that authority and its audit trail.
UNESCO’s Recommendation on the Ethics of AI provides a policy reference for human rights, oversight and responsible governance. Those principles need to be translated into the service’s actual controls and decision procedures. UNESCO Recommendation.
Where SpeedyMesh Ecosystem fits
SpeedyMesh Ecosystem brings together governed data capabilities and connected tools such as DataLens, AI Fabric, Pipeline Co-Pilot and SpeedyMesh Pulse. In an architecture discussion, we consider their contribution alongside existing infrastructure, required integrations and the client’s operating model.
The Ecosystem is open source. The public RePAN implementation offers an accessible example within the ecosystem. Its scope and licence should be read at repository level.
Speedykom’s broader contribution covers the architecture, integration, software development and delivery work around the service. That includes explaining trade-offs and helping the responsible teams operate what has been built.
Deliver the operating capability with the software
A useful handover includes deployment instructions, access arrangements, data-product ownership, incident procedures, monitoring, backup restoration and the ability to change key dependencies. Training should use the actual environment and responsibilities of the operating team.
For regional services, plan how new participants join, how trust arrangements change and how disputes or incidents are handled. Connectivity, language needs, staffing and recurring costs should be validated with each participant. A service should have a credible maintenance path after its initial delivery budget ends.
This is the connection between policy and engineering: the agreed responsibilities become controls, the controls become testable behaviour, and the behaviour becomes an operating capability.
Explore the approach: Speedykom’s sovereign data and AI architecture services.
Continue the series
Digital sovereignty: who can decide, operate and change? · How to assess sovereign data and AI systems: an evidence-led guide