Approving or Rejecting an AI Use Case: A Board Decision Checklist

When a board is asked to approve an AI system, a clear decision framework prevents drift and keeps governance working. The framework should be simple enough that the board can apply it consistently, and detailed enough that it covers real risk.

The checklist starts with a business case. Is there a clear problem this system solves? Is the problem real, or is this an example of looking for a use case for a new technology? Who benefits if the system works, and who is harmed if it fails? A strong business case does not mean the system will succeed, but it sets a foundation. If the business case is weak (we want to use AI because it is trendy), the board should reject the project or send it back for rework.

The second element is risk classification. What category does this system fall into? Is it high-risk because it makes decisions about people? Is it medium-risk because it affects many customers but with lower individual impact? Is it low-risk because it is internal or advisory? This classification determines what level of scrutiny the system needs. The board’s risk appetite, set in advance, should map to each category. High-risk systems need high scrutiny. Low-risk systems can move faster.

The Core Questions

For high-risk systems, the checklist includes specific questions. First: Is there an impact assessment? An impact assessment is a documented analysis of how the system affects people, what risks exist, and how they are mitigated. It is not a checkbox; it is an active document showing the team has thought through consequences. If the system classifies people into groups (creditworthy or not, high-risk or low-risk), the impact assessment must include analysis of whether these classifications are accurate and fair across demographic groups.

Second: Has the system been tested on representative data? The test data should include people from all the demographic groups the system will serve. If the system is tested only on data from one region or one age group, its real-world performance might be worse. The board should see the actual test results, broken down by demographic group, and confirm that performance is acceptable across groups.

Third: Is there a documented baseline for comparison? The system should be compared to something: the previous system, a human alternative, or random assignment. If the new system is not better than what it replaces, why deploy it? The baseline comparison should be on the same test data. A report that says the new system is 95 percent accurate but the old system accuracy is unknown is incomplete.

Fourth: Is monitoring in place? After the system goes live, who will check that it continues to perform as expected? Drift happens: models trained on historical data become less accurate over time as the real world changes. Monitoring typically includes tracking key metrics (accuracy, fairness measures, error rates) on a monthly or weekly basis. The board should know who owns monitoring and what triggers an alert.

Fifth: Is there a rollback and escalation plan? If the system performs poorly in production, what happens? Can you revert to the previous system? If an alert triggers, who is notified and when? A clear escalation path ensures that problems are noticed and acted on quickly.

Sixth: Is the system documented? Documentation includes model cards (what the system is, how it was trained, what its limitations are), technical documentation (architecture, dependencies, how to retrain), and operational documentation (how to deploy, how to monitor, how to shut down). This documentation is needed so the team can understand and maintain the system over time, and so regulators or auditors can assess it.

Seventh: Have you identified the owner? Someone must be accountable for this system on an ongoing basis. Not the engineer who built it, but the person responsible for the system’s performance and behaviour over time. This might be a product manager, a department head, or a compliance officer, depending on the system. The owner is the person the board can ask in six months: is this system meeting expectations?

The Rejection Criteria

The board should have clear criteria for rejection. If the business case is not compelling, reject. If the system is high-risk and impact assessment shows unmitigated harm, reject. If the system’s performance is not better than the alternative, reject. If testing shows unacceptable bias that cannot be mitigated, reject. If monitoring is not feasible, reject.

Rejection is not a failure; it is part of the approval process. Projects that cannot pass the checklist either need rework or should not proceed.