TL;DR: Nigeria's pending Digital Economy Bill would require AI risk classification, annual impact assessments, and licensing for high-risk systems. Comply54, an open-source runtime engine, already enforces this at the point an agent tries to act, before execution, not after. Below: a LangChain code example, a table mapping the bill's requirements to the architecture, and why compliance has to be jurisdiction-specific rather than one global ruleset.
Nigeria's National Digital Economy and E-Governance Bill has been "about to be signed" since November 2025. Whenever it clears assent, it hands NITDA power to classify AI systems by risk, mandate annual impact assessments for high-risk deployments (finance, public administration, automated decision-making, surveillance), and fine non-compliant providers up to 2% of Nigerian revenue.
Every part of that is described in legal language. None of it is described in code. So here's the code version.
The gap: compliance-as-paperwork vs. compliance-as-runtime
Most compliance tooling checks whether a system was compliant, after the fact, via a report someone compiles for an auditor. That's fine for annual reviews. It's useless for an autonomous agent that's about to approve a transaction, move personal data across a border, or make an automated decision about a person, right now, in this function call.
The bill's own language, "high-risk applications in finance, public administration, and surveillance," describes exactly the class of agent action that needs to be checked before execution, not logged after.
That's what Comply54 does. It's an open-source runtime engine that intercepts an agent's tool call, evaluates it against jurisdiction-specific policy packs, and blocks or allows it before the action happens.
What this looks like with a LangChain agent
from comply54 import PolicyEngine
from comply54.packs import nigeria_ndpa, nigeria_cbn
from langchain.agents import AgentExecutor
engine = PolicyEngine(packs=[nigeria_ndpa, nigeria_cbn])
@engine.enforce
def transfer_funds(account_id: str, amount: float, destination: str):
# this function body only executes if the call
# clears every loaded policy pack first
return payment_service.transfer(account_id, amount, destination)
agent_executor = AgentExecutor.from_agent_and_tools(
agent=agent,
tools=[transfer_funds],
# engine intercepts at the tool-call boundary
callback_manager=engine.as_callback_manager(),
)
If the agent tries to move funds in a way that violates a CBN transaction control, say a geo-fencing rule or a threshold that requires additional authorization, the call never reaches payment_service.transfer. It's rejected at the boundary, and the rejection, along with the full context of the attempted action, is written to the audit trail automatically.
Mapping the bill's requirements directly to the architecture
| What the bill asks for | What Comply54 does |
|---|---|
| Risk classification of AI systems | Policy packs are pre-classified by jurisdiction and regulation (NDPA 2023, CBN, NIMC Act 2026, NFIU-AML) |
| Mandatory annual impact assessments | Every enforcement decision is logged at the moment it happens, so the "assessment" is a continuous, queryable trail rather than a point-in-time report |
| Licensing and accreditation of AI auditors | Apache 2.0 licensed, publicly inspectable. Nobody has to trust a vendor's black box; the enforcement logic is readable Rego/policy code |
| Regulator authority to suspend non-compliant systems | Enforcement happens at the function boundary already; disabling a pack or tightening a threshold is a config change, not a system rebuild |
Why this can't be a single global ruleset
A common instinct when building compliance tooling is to write one universal ruleset and let it cover "AI ethics" broadly. That doesn't survive contact with African regulatory reality. NDPA 2023 and POPIA (South Africa) define personal information differently. CBN's geo-fencing mandate for point-of-sale terminals, enforceable from August 2026, has no equivalent in Kenya's KDPA. NFIU-AML thresholds for suspicious transaction reporting are Nigeria-specific.
That's why Comply54 is structured as composable packs rather than one framework. A team deploying only in Nigeria loads nigeria_ndpa and nigeria_cbn. A team operating across Nigeria, Kenya, and South Africa loads all three, and the engine enforces the union, not an averaged-out approximation of "African compliance" that satisfies none of them precisely.
Where the project's African-specific detail actually comes from
The seed for this was agt-policies-nigeria, 12 regulatory policy packs covering NDPA 2023, CBN, NFIU/AML, KDPA, and POPIA among others, contributed to Microsoft's Agent Governance Toolkit and merged as PR #3077. That contribution is the reason the project exists as jurisdiction-specific packs instead of a generic "compliance-as-a-service" wrapper: the regulatory detail came from people who actually work inside these frameworks, not from a vendor approximating them from outside the continent.
That's also the open call. Adapters currently cover LangChain, LangGraph, CrewAI, AutoGen, and Vercel's Eve. Policy packs cover 10+ jurisdictions but not all 54 African nations, not even close. If you know a regulatory framework, Ghana's Data Protection Act, Rwanda's, Egypt's emerging AI rules, that isn't represented yet, that's a policy pack, not a rewrite of the engine.
Try it
pip install comply54
# or
npm install eve-policy
Repo, docs, and the full policy pack list are on GitHub. Issues and PRs on new jurisdiction packs are the fastest way to get something added.
Top comments (0)