An AI adoption dashboard can tell a board how many people use a tool. It may say very little about which workflows exceed approved authority, who owns the unresolved exceptions, or what evidence supports giving a system more freedom to act.
That is where I would change the reporting conversation. Alongside the adoption story, ask management to bring a short record of the exceptions that require a decision.
The point is not to send every operating issue to the board. Management still runs the business. The useful distinction is between an exception management can resolve within its delegated authority and one that needs escalation because it exceeds an agreed boundary or carries a material consequence.
Make the exception visible enough to decide
A red, amber or green status is a summary. It does not show whether the evidence is complete, whether the control covers the workflow in question, or whether anyone has authority to accept the remaining uncertainty.
A useful exception report connects the workflow, the authority boundary, the evidence and the decision owner. The following six fields are a proposed reporting format, not a universal governance requirement. An organization should adapt them to its delegation model and reporting obligations.
1. Bounded use case and accountable executive
Name the workflow and the management executive accountable for it. Be specific about the business activity, the relevant data and the action the system may take. “AI across customer operations” is too broad to support a decision about one workflow.
2. Approved authority and current exception
State what is currently permitted and what has changed or remains unresolved. Distinguish an existing breach of an approved boundary from a request to expand that boundary. The two may need different responses.
3. Business consequence and evidence quality
Explain the plausible consequence in business terms. Then distinguish what has been demonstrated, what has been independently checked, what is asserted by a supplier and what remains unknown. An empty evidence field should remain visible; a confident narrative should not fill it.
4. Management recommendation
State whether management recommends expanding, maintaining, restricting or pausing the activity, and why. Tie the recommendation to the evidence and unresolved dependencies. Identify what would change that recommendation.
5. Decision owner and review condition
Name the person or body authorized to make this particular decision. Record the approved scope, any conditions and the point at which it must be reconsidered. A new data source, a different action or a loss of a required control may warrant review before a calendar date arrives.
6. Closure and recovery evidence
State what would establish that the exception is resolved, who will review that evidence and how the approved action could be stopped or reversed where applicable. “Remediation complete” is not a substitute for a reviewable record of what changed and what was verified.
A hypothetical exception: more access than the evidence supports
The scenario below is entirely illustrative. It describes no client, deployed system or observed result. The proposed response is a design choice for this example, not a general risk threshold.
1. Bounded use case and accountable executive
An AI assistant prepares proposed changes to customer contact records. A customer-operations executive owns the workflow, and employees currently review each proposed change before applying it.
2. Approved authority and current exception
The assistant is permitted to draft changes. Management is considering direct write access. The request for broader authority remains unresolved because reliable access revocation and a complete record of changes have not yet been demonstrated.
3. Business consequence and evidence quality
An incorrect record could affect later customer communications or operating decisions. A successful demonstration shows that the assistant can make a selected change. It does not establish how the workflow handles an incorrect proposal, a failed approval step or an interrupted update. Those evidence gaps remain open.
4. Management recommendation
Maintain the existing draft-and-review workflow and withhold the proposed direct write access. Reconsider a bounded expansion after the missing controls and exception paths have been verified. Missing evidence does not prove that the system is unsafe; it limits the case for granting more authority.
5. Decision owner and review condition
The authorized management executive makes the operating decision within the organization’s delegation model. Escalate it if the unresolved consequence or proposed authority exceeds that delegation. Reconsider the decision before changing the permitted fields, data source or approval path, or if a required control stops working.
6. Closure and recovery evidence
Management supplies the agreed access scope, reviewable activity records and evidence from the relevant exception checks. It also demonstrates who can revoke access and how an incorrect change would be corrected. A named management reviewer records what is verified, what remains open and the next review condition.
Let the evidence change the recommendation
The missing revocation evidence in that example is consequential. Adding a reassuring sentence to the report would not resolve it. Producing reviewable evidence could support reconsidering a bounded expansion; discovering that the boundary cannot be enforced could support restricting or pausing the affected activity.
The same discipline applies to apparently successful use cases. Adoption, speed and user satisfaction may be useful operating measures. They do not, by themselves, establish that a system is operating within its approved authority.
A recommendation should therefore say what the evidence supports today. It should also say what management is declining to authorize while an important uncertainty remains unresolved.
Keep oversight and operating responsibility clear
Directors can challenge whether management has identified the right owner, made uncertainty visible and followed through on the decision. They should not need to configure permissions or adjudicate every routine exception to do that.
Management should resolve issues within its authority and escalate matters that exceed it. The board or relevant committee can then focus on the consequential exceptions that fall within its oversight role, according to the organization’s own governance arrangements.
A completed template is not assurance, a certification or a legal conclusion. Its value depends on the quality of the evidence, the clarity of the decision and whether the people responsible actually follow through.
The board should be able to see the permitted activity, the unresolved exception, the accountable owner and the reason for the next decision. That is a more useful basis for oversight than an adoption total standing alone.