The Accra Standard: why emerging markets will write the next AI governance playbook.
The frameworks the world is adopting were drafted for institutions with clean data, continuous power, and regulators who arrive after the technology. Most of the world operates under none of those assumptions — and the systems built to survive that are the ones that will generalise.
There is a quiet assumption inside almost every AI governance framework currently in circulation: that the organisation implementing it already works. That its data is centralised, its records are complete, its identity systems are authoritative, its infrastructure is continuous, and that a regulator exists with the capacity to inspect what it is told. Strip any one of those assumptions away and most of the framework quietly becomes paperwork.
We build from Accra. Not as a matter of sentiment, but because the constraints here are instructive. A manufacturer's batch records may live across three notebooks and a WhatsApp thread. A lender's identity verification may need to work when the national database is unreachable for six hours. A supply chain may cross four jurisdictions where only two publish machine-readable customs rules. In these conditions, a governance programme that depends on a single source of truth does not degrade gracefully — it stops.
Governance written for stable institutions is a description of good behaviour. Governance written for unstable ones has to be a mechanism.
The distinction between a policy and a mechanism
A policy says model changes must be reviewed. A mechanism refuses to promote an unreviewed model. A policy says personal data must not leave the jurisdiction. A mechanism cannot physically route it elsewhere. In mature markets the gap between the two is absorbed by institutional culture, legal exposure, and the sheer cost of being caught. Where enforcement capacity is thinner, that absorbing layer is not there, and the gap becomes the whole story.
This is why we treat compliance as running code rather than as a document set. It is not a philosophical preference. It is the only version that holds when nobody is watching, and it happens to be the version that survives an audit anywhere.
Four constraints that make better systems
Intermittency. If the system must function during a connectivity gap, state has to be local, reconcilable, and tamper-evident. Build that once and you have also built the thing every distributed enterprise wants: an append-only record that can be replayed and proven after the fact.
Data scarcity. Where training data is thin, you cannot hide a weak model behind volume. You are forced into narrow scope, explicit uncertainty, and human checkpoints at the decision boundary — which is precisely what the EU AI Act asks of high-risk systems, arrived at by engineering necessity rather than by legal instruction.
Plural jurisdictions. Operating across markets whose rules disagree forces residency, retention, and lawful basis to become configuration rather than architecture. A system that can be told where its data lives is a system that can enter a new market in weeks.
Cost discipline. When there is no budget for a governance department, controls have to be embedded in the workflow that people already perform. Governance that requires a separate team to be observed is governance that will be skipped.
Why this generalises upward
The history of infrastructure is full of constraints exported as standards. Mobile money did not emerge in markets with excellent retail banking; it emerged where branch networks were absent, and it is now the reference design for account-to-account payments worldwide. Leapfrogging is not a story about catching up. It is a story about which constraints produce better engineering.
AI governance is on the same path. As models move from pilots into load-bearing operational roles, even well-resourced institutions discover that their data is messier than the framework assumed, that their lineage is incomplete, and that the compliance narrative and the production system have drifted apart. At that point the useful question is not what the policy says. It is what the system can prove.
The question that matters is not whether an organisation has a governance framework. It is what its systems can prove without being asked.
What we mean by an authentic system
An authentic system is one whose behaviour and its account of its behaviour are the same object. The record is not written about the work; it is produced by the work. Provenance is captured at the moment of action, not reconstructed at quarter-end. Access is bound to purpose, and the purpose is recorded alongside the access.
That standard is harder to reach than a policy binder. It is also the only version that holds up in front of a regulator, a customer, an auditor, or a court — in Accra, Brussels, or anywhere else. This is the discipline we apply across our portfolio: an AI product lifecycle ledger that records what it did, a compliance layer that executes controls rather than describing them, a supply-chain suite that assumes the network will fail, and a knowledge layer that keeps authorship attached to what it retrieves.
The practical version
For leaders building now, three commitments carry most of the value. Make evidence a by-product of operations, not a reporting exercise. Make residency and retention configurable before you need a second market. And design every control to work when the network, the vendor, or the central registry is unavailable — because that condition is not exotic, it is simply earlier here than elsewhere.
Emerging markets will not write the next playbook because of geography or moral claim. They will write it because they are running the harder test first, and because systems that pass a harder test travel well.
Further reading
Written by the senior practitioners at AITW Authentica. To discuss how this applies to your organisation, start a conversation.