A bank in Nairobi approves a credit-scoring model in March. A telco in Lagos signs off a customer-service assistant in May. A health insurer in Johannesburg clears a claims-triage tool in July. Each approval rests on a risk assessment written for one version of the system, one vendor contract and the rules in force that day. Six months later the model has been retrained, the vendor has shipped a new version, the assistant now also handles collections, and a regulator has published new requirements. The assessment still says "approved". It describes a system that no longer exists.
This is the quiet failure mode of AI governance, and it is reaching African organisations faster than most governance teams expect.
Adoption is outpacing governance
The Central Bank of Kenya's Survey on Artificial Intelligence in the Banking Sector, published in 2025, offers a rare data-backed view. Half of the institutions surveyed had adopted AI, including 66 percent of commercial banks, and 68 percent of adopters were already using generative AI. Yet only 41 percent of adopters had AI policies, 37 percent did not actively monitor the ethical behaviour of their models, and 40 percent had outsourced development. The most common use was credit risk assessment, exactly the kind of decision that shapes people's access to finance. And 93 percent of institutions asked the regulator for guidance on AI governance and risk management.
Kenya is not an outlier. Banks, insurers, telcos, retailers, hospitals and public agencies across the continent are moving from one or two pilots to portfolios of AI systems, many of them bought rather than built. A governance team of two or three people can do a careful first assessment of each. What it cannot do is redo every assessment by hand whenever something changes.
Five changes that make an assessment stale
An assessment covers one version of a system, at one point in time, under one set of rules. All three keep moving. Five kinds of change should trigger a new review:
- A new or amended rule. The African Union's Continental AI Strategy was endorsed in July 2024. Rwanda approved a national AI policy in 2023, Kenya launched its National AI Strategy 2025–2030 in March 2025, and Nigeria published a draft national strategy in 2024. Nigeria's Data Protection Commission issued its General Application and Implementation Directive under the NDPA in March 2025. In South Africa, the joint standards on IT governance and on cybersecurity for financial institutions took effect in November 2024 and June 2025. Each can change what "acceptable" means for systems already in production.
- A change to internal policy, such as a new fairness threshold for every credit model or a rule that customer data may not leave the country.
- A change to the system: a retrained model, a new data source, a new integration, or an assistant that can now take actions rather than only answer.
- A vendor update. When development is outsourced, the vendor can change the model underneath you. A new version may behave differently in Kiswahili, Hausa or isiZulu even if it scores better in English.
- A new use case. A model approved for salaried customers is extended to informal traders, or rolled out to a neighbouring market with a different data protection law.
Multiply these across a portfolio. An organisation with 40 AI systems that updates its policies quarterly faces 160 potential reassessments a year before a single model changes. A team that finalises a few assessments a month cannot keep up, and hiring more reviewers does not close a gap of that size. So the reassessment does not happen, and the risk register drifts out of date one change at a time.
From one-off approval to continuous assessment
The answer is not more forms. It is to treat AI risk the way a security team treats software vulnerabilities: when something relevant changes, the affected systems are found automatically and each gets a short, specific review task.
Start a reassessment from every change that can move a risk. A new design document, model card or vendor release note should queue a review of that system. A policy change should queue a review of every system it applies to, which saves the most time because one change reaches many systems at once.
Reassess only what changed. Compare the new version with the previous one and evaluate only the affected sections. AI tools can draft proposed risks, revised scores and mitigations, while a person decides.
Show people what moved. Reviewers should see which risks were re-scored, which are new and which were already rejected as not applicable. Earlier human decisions should be kept, not relitigated.
Four design rules that keep it auditable
Whether you buy a platform or build the workflow yourself:
- Patch only what changed. Diff the new version against the old one rather than starting from scratch.
- Keep every human decision, stored against the version it applies to. An approved risk keeps its approval and is flagged as changed; a rejected risk stays rejected.
- Use AI for judgement and fixed logic for rules. Let a model suggest new risks. Let deterministic code set the risk level from your likelihood and impact matrix, and never let a model rewrite an approved control.
- Record who decided what, and when. Every version should note its trigger and whether each change came from a person or the system. That is the first thing an auditor will ask for.
For African deployments, add one more: keep the workflow, documents and audit trail in an environment you control, ideally in-country, and if a model assists the review, host it where your data protection obligations allow.
Three questions for your leadership team
- When the last rule relevant to your AI took effect, which systems were reassessed against it, and how long did that take?
- When a vendor last changed the model behind one of your products, did your risk assessment change?
- For any one system, can you show an auditor every change to its risks, who made it and when?
If the honest answer to the first is "months" or "none", your risk register describes systems that no longer exist. The exposure grows with every retrained model, vendor release and new rule: credit decisions nobody rechecked, conversations in languages the new model handles worse, and obligations that took effect after approval and were never tested.
Where to start
Begin with your inventory and risk tiering, as set out in our regulation checklist. For your highest-risk systems, list the triggers that should prompt a review, name an owner for each and agree what a reassessment must produce. Automate the triggers first, then the drafting. The goal is simple: when something changes, the right people know within days, not at the next annual audit.
General information, not legal advice. Requirements differ by country and sector, so involve your legal and compliance teams.
