An architecture proposal may promise local hosting, open source and model choice. Each promise should lead to evidence: the boundaries of the deployment, the licence and build process, the controls around inference, and the work needed to change a dependency.
This guide sets out a practical assessment method proposed by Speedykom Group for governments, businesses, civil society, and regional and continental organisations. It supports architecture and procurement discussions. It is not an accreditation or a substitute for a deployment’s legal review.
1. Define the service and the decisions it supports
Describe the service in one paragraph: its users, purpose, information, operating environment and potential consequences of failure. Identify who has authority over each important decision, including the people who can approve changes and the people who can challenge outcomes.
Choose a concrete boundary. “Our AI system” may include a user interface, a retrieval index, an external model endpoint, a logging service and a managed database. Assessing only the model would leave significant dependencies outside the exercise.
For a cross-border service, include each participant’s role and the shared governance arrangement. Keep national requirements, organisational responsibilities and regional agreements visible in the same map.
2. Map the complete data and dependency path
Follow information from collection to deletion. Include source records, derived data, embeddings, prompts, model outputs, caches, backups and telemetry. Record where each category is processed, which actor can access it and which contract governs the activity.
Then map operational dependencies: identity providers, certificate services, encryption keys, package registries, model artefacts, cloud administration, network links and support suppliers. A hosting diagram becomes much more informative when it also shows the services required to keep the deployment working.
3. Build an evidence register
Use the four dimensions from the first article to organise the evidence. The questions below can be adapted to the service’s risk and resources.
| Dimension | Ask | Inspect or test |
|---|---|---|
| Authority and accountability | Who approves use and accepts residual risks? | A responsibility map, approved purposes, oversight and complaint procedures |
| Data and technical control | Can unauthorised access or use be prevented and detected? | Access rules, key custody, administrative privileges, data flows and audit records |
| Operational capability | Can the responsible team run and recover the service? | Deployment documentation, operator access, monitoring and a measured restore exercise |
| Choice and continuity | Can a dependency be replaced within acceptable limits? | Export completeness, licences, integration contracts and a trial migration |
For each item, record the evidence, scope, date, owner and remaining uncertainty. Useful states are demonstrated, documented but untested, gap, and not applicable with a reason. These describe the state of knowledge; they are not numerical sovereignty scores.
4. Examine the AI lifecycle
Model choice becomes meaningful when the service can evaluate and govern the choice. Review training or fine-tuning inputs where relevant, retrieval permissions, inference processing, output handling, retention and model updates.
A practical review asks:
- Which information reaches the model provider, and what happens to it afterwards?
- Are retrieval permissions checked for the requesting user before content enters the prompt?
- Who approves model or prompt changes, and which evaluations must pass?
- How are performance, language coverage and harmful failures tested for the intended users?
- Which actions require human approval, and who can stop the service?
- What changes when the model, hosting provider or embedding model is replaced?
NIST’s AI Risk Management Framework offers a voluntary reference for considering trustworthiness throughout AI design, use and evaluation. Its guidance can inform this review alongside the organisation’s own risk processes. It does not establish a sovereignty certification. NIST AI RMF.
5. Set decision gates before comparing options
Agree the minimum conditions for this specific service. A condition might require that a named operator can revoke access, that a sensitive data category stays within an agreed processing boundary, or that restoration meets an approved recovery target.
These are gates. A failure on a critical condition needs a design change, a narrower scope, or an explicit decision by the authorised risk owner. An attractive average score would obscure that decision.
After the gates, compare cost, usability, delivery time, energy demand, performance and maintainability. Record the reasoning, including dependencies the organisation chooses to accept and when it will revisit them.
Diagram: “From requirements to a defensible decision”. The accompanying visual shows scope, evidence, tests, critical gates and an approved decision, with a review loop for changes in suppliers, models or policy.
6. Run a small set of meaningful tests
An illustrative test plan could include:
- Revoke a participant’s access and attempt a fresh request; document any retained copies and their governance.
- Restore the service from backup using the designated operating team and measure the result.
- Export an approved data product, including its schema and essential metadata, and validate it outside the original system.
- Switch an AI endpoint using representative tasks and compare quality, latency, cost and data exposure.
- Trace a decision from its input and approved model version to its output and human review.
These are suggested tests, not results from a Speedykom customer deployment. Evidence should record limitations: switching an embedding model may require rebuilding an index, and cancelling access cannot make a recipient forget previously disclosed information.
Make the assessment useful after procurement
The assessment should leave a decision record, responsibility map, prioritised gaps and a practical operating plan. Revisit it when a model changes, a new participant joins, processing moves, or contractual conditions change.
In African and international settings, include the people who will maintain the service and the organisations whose requirements must be coordinated. Their access, skills, resources and authority are part of sovereignty’s operating foundation.
Speedykom’s contribution is to connect this evidence with architecture, software engineering, integration and handover. The aim is a service whose controls can be explained, tested and maintained by the people responsible for it.
Next in the series: turning assessment findings into a federated data and AI architecture.
Discuss a service: Speedykom Group.
Continue the series
Digital sovereignty: who can decide, operate and change? · From policy to architecture: building sovereign data and AI services