By Chisom Obiudo
Boards often ask the wrong first question when considering an AI tool: Does it work?
A product demonstration can show speed, accuracy and cost savings under controlled conditions.
It cannot show whether the organisation is prepared for the tool to expose confidential information, produce unfair outcomes or fail at a critical moment. Those are governance questions.
Before approving the tool, the board should ask: What could go wrong, how will the organisation respond, and who will be accountable for the consequences?
Answering those questions begins with purpose. The board must first understand exactly where the tool will sit in the organisation’s decision-making process.
Start with the decision the tool will influence
The board should begin by identifying the decision or workflow the tool will support. An AI tool used to draft internal meeting summaries does not carry the same consequences as one that screens job applicants, recommends credit decisions or flags insurance claims for investigation.
The tool’s purpose determines the level of oversight required. The greater its potential effect on a person’s rights, livelihood or access to services, the stronger the testing and human review should be. Management should also explain how the tool’s performance will be assessed against the current process. Time saved is not a sufficient benefit if employees cannot identify and correct its errors.
Board question: What decision will this tool influence, who could be affected if it is wrong, and how will management know whether it is working as intended?
Make accountability visible before examining the technology
Once the board understands the decision the tool will influence, it should identify who owns the outcome. A named executive should be able to explain who operates the tool, who checks its outputs, who has authority to override it, and who reports material failures. Without clear accountability, responsibility for an error shifts from the user to IT, from IT to procurement, and from procurement to the vendor, while nobody assumes ownership.
The vendor may be contractually responsible for correcting a technical fault. The organisation remains responsible for deciding where and how the tool is used and for responding when people are harmed. The organisation can outsource technology, but not accountability.
Board question: Which executive is accountable to the board for this tool’s outcomes, including any harm resulting from an error?
Follow the data through the entire process
Once accountability has been assigned, the board should follow the information on which the tool depends. What data will the tool receive, and where will that data go?
Management should be able to trace personal, confidential and commercially sensitive information from the moment it enters the tool until it is deleted. This includes where the data is stored, who can access it, whether it crosses national borders, how long it is retained and whether the vendor may use it to train or improve other systems.
Data protection requirements differ across African jurisdictions. Management should identify the rules that apply to the organisation and the proposed use of the tool. A practical test is whether management can answer an employee or customer who asks: What information did you use? Why did you use it? Who received it? When will it be deleted?
Board question: Can management trace the information this tool will use from entry to deletion, including where it goes and who can access it?
Test bias and explainability together
Knowing where the data goes is only part of the board’s oversight. The board must also ask what patterns the data may teach the tool and whether those patterns could disadvantage particular groups.
Bias arises when the data, design or use of an AI system produces unfairly disparate outcomes. Historical discrimination may be embedded in the data, local populations may be poorly represented, or the tool may be used for a purpose for which it was not designed.
An imported recruitment tool may misinterpret local qualifications. A customer-service system may perform poorly with African names, accents or languages. Management should show how the tool was tested on the people it will affect, whether error rates differ across groups, and what human review will address those weaknesses.
Bias testing and explainability should be considered together. Explainability means the organisation can provide an affected person with a clear reason for an AI-supported outcome. If a tool recommends rejecting a loan application, staff should identify the relevant factors, correct any inaccurate information, and refer the decision to someone with authority to change it. Human review is ineffective if the reviewer simply repeats the tool’s recommendation.
The same discipline applies when AI supports the board’s own decisions. AI can help directors compare strategic options, analyse financial forecasts or identify risks in a proposed investment. Its output, however, depends on the data and assumptions behind it.
Before relying on the analysis, directors should know how it was produced, who verified the figures and sources, and which assumptions shaped the recommendation. AI can strengthen the board’s analysis. It cannot replace the board’s judgement.
Board questions: Has management tested the tool on the people it will affect, and can the organisation explain, review and reverse an unfair outcome? If AI contributed to a strategic or financial recommendation presented to the board, who verified the data, assumptions and figures?
Plan for failure and exit
Even a tool that performs well can leave the organisation dependent on a single supplier. Vendor lock-in arises when changing providers becomes expensive or impractical because the organisation cannot recover its data, configurations or audit history in a usable form.
Before signing the contract, management should explain how the organisation will retrieve its information, switch to another provider and continue the affected service if the supplier changes the product, raises its price, experiences prolonged downtime, or ceases operations. The contract should also address the return or secure deletion of the organisation’s data.
The board must also understand what happens if the tool itself fails. Failure may include inaccurate outputs, discriminatory treatment, a data breach, system downtime, or employees relying on AI when human judgement was required.
For each material failure, management should explain how it will be detected, who has authority to suspend the tool, who must be informed, and whether a safe manual process is available. Clear thresholds should determine when a serious incident must be reported to the responsible board committee.
Board question: If the tool or vendor failed tomorrow, could the organisation stop its use, recover its information, continue the affected service and report the incident promptly?
Require evidence before approval
By this stage, management should be able to substantiate every material claim about the tool with evidence. The board should not rely on unsupported assurances that the tool is secure, unbiased or suitable for the proposed purpose.
The board paper should include the business case, impact assessment, testing results, data protection review, human oversight arrangements, contractual protections, an exit plan, incident response arrangements, and the name of the accountable executive. Together, these documents should demonstrate that the proposed benefits are realistic and that the material risks can be controlled.
The company secretary can strengthen the approval process by ensuring that the request reaches the correct committee, that directors receive the supporting papers early, and that approval conditions are recorded precisely. Each condition should be tracked as a management action with a responsible owner and a completion date.
The board should also decide how often it will receive reports on the tool’s performance and incidents. It should identify the changes or failures that would require the tool to be reassessed, suspended or returned to the board for renewed approval. Approval is the beginning of oversight, not the last time the board should hear about the tool.
Board question: What evidence supports approval, what conditions should the board impose and when will the tool be reviewed again?
Use AI to prepare the questions, not to make the decision
An approved AI assistant can help directors, executives and company secretaries prepare an initial set of questions ahead of the meeting. This can improve the quality of preparation, but it does not transfer the board’s judgement or accountability to the AI system.
Use general or anonymised information unless the organisation has approved a secure AI environment for confidential work. Do not enter non-public contracts, personal information, customer records or board papers into a publicly available AI service.
Copy-ready prompt
Act as an AI governance adviser to a board. Our organisation is considering adopting [name the AI tool] for [purpose].
Give me 10 questions the board should ask management before approving it. Cover the tool’s purpose and expected benefits, accountability, data protection, bias, explainability, human oversight, vendor lock-in and exit, what happens when it fails, the evidence supporting approval and ongoing monitoring.
For each question, explain in one sentence why it matters and identify the evidence the board should request.
The generated questions are a starting point, not a substitute for board judgement. Adapt them to the organisation’s sector, legal obligations, risk appetite, and the people the tool may affect. Management should answer each material question with evidence before directors are asked to vote.
Good AI governance begins before the approval meeting. Directors should enter the meeting knowing what could go wrong, who will be accountable, and what evidence supports the proposed decision. If management cannot provide clear, evidence-based answers, the board should defer its decision until the outstanding governance gaps are addressed.
