Boards have spent a lot of time learning about AI.
They have heard from vendors. Sat through demonstrations. Reviewed responsible-AI principles. Asked management where generative AI might create productivity or growth.
That phase is ending. AI is beginning to act. A system can respond to a customer, change a record, recommend a price, write code, approve a workflow, initiate communication, or hand work to another system. The distance between a recommendation and a business consequence is getting very short.
That changes the board question from “Do we understand AI?” to “Who can stop it?”
It sounds almost absurdly simple. In practice, many companies cannot answer it.
A chatbot that drafts a customer response creates one level of risk. An AI agent that sends the response, changes the customer record, and issues a refund creates another. The underlying model may be similar. What changed is the authority the company gave it.
When I work with boards and executive teams on AI, I want to know where the system stops recommending and starts acting. I also want to know who has the authority to intervene once it does. Companies are usually much better at explaining their AI architecture than their decision architecture.
The problem becomes obvious when you trace a real workflow.
Take an AI system involved in customer service, pricing, hiring, healthcare, financial decisions, or any other activity where an error has a meaningful consequence. Management should be able to show the board what the system is allowed to do on its own, which decisions require human approval, what conditions trigger escalation, and who can halt the process immediately.
Those answers often span several functions. Technology owns the platform. The business unit owns the process. Legal and compliance set some of the constraints. Risk may oversee the controls. A vendor may operate part of the model.
That distribution of responsibility is unavoidable. Ambiguity about the final decision is not.
The person who sees a problem also needs enough authority to do something about it. This is where the familiar promise of a “human in the loop” can give boards false comfort.
A company may technically allow an employee to override an AI recommendation while making that override difficult in practice. Perhaps every exception requires additional approval. Perhaps managers are rewarded heavily for automation rates or speed. Perhaps challenging a model that has been endorsed by senior leadership carries an implicit career cost.
The human remains in the process. The organization has quietly taught that person to defer to the machine.
That is a governance failure, even if the controls look perfectly respectable on paper.
I use a simple test with leadership teams to make these boundaries visible: Detect, Decide, Deploy, and Debrief.
AI is increasingly good at the first step. It can identify patterns, anomalies, and options at a scale no management team could replicate manually. The harder questions start when those signals become decisions. Some decisions can safely be automated. Others require context, ethical judgment, or an understanding of consequences the system does not possess.
Deployment introduces another boundary. Once a decision turns into an action, the company needs to know exactly what the system is authorized to do, and under what conditions that authority disappears.
Then comes the step companies often neglect: debriefing. Someone has to examine overrides, failures, unexpected outcomes, and changes in model behavior. Otherwise organizations can accumulate risk while dashboards continue to show that the system is functioning as designed.
This is also why average accuracy tells a board so little by itself. A system can perform well overall while failing badly in the cases the company cares about most. The board needs to understand what kinds of errors occur, who bears their consequences, and what level of failure management has decided is unacceptable.
The same principle applies to drift. Models operate inside businesses and markets that change. Customer behavior changes. Data changes. Products change. Regulations change. A system that performed adequately when it was approved may behave differently six months later. Boards do not need to become model engineers to oversee this. They need evidence that management knows when performance has materially changed, and has already decided what happens when it does.
I would therefore spend less board time on broad AI briefings and more time examining a small number of consequential deployments in detail.
Pick one system. Follow the decision from beginning to end. Understand what the AI sees, what it recommends, what it can execute, and where human judgment enters. Then identify who can override it, who can stop it, and who owns the result when something goes wrong.
If management cannot answer those questions cleanly, the board has learned something important before an incident forces the issue.
The board does not need to know everything the AI knows. It does need to know where the company has transferred authority to it.
And somebody, somewhere in the organization, needs the power to take that authority back.
Resources for Directors
- Board AI Readiness Scorecard (free). Eighteen questions. A board-ready PDF of where oversight is thin.
- AI Governance Playbook for Boards. The operating guide: control rights, escalation triggers, agentic oversight, a 90-day roadmap.
- How should boards oversee AI, and what metrics actually tell them something useful?
- If AI agents are running workflows in the background, how does a board keep control?
