Boards are fielding more AI questions than ever. In the past year alone, the volume of AI-related agenda items has surged across industries — and that trend shows no sign of slowing.
Most of the conversations I see stay stuck in the technical layer: model types, data privacy architecture, vendor security certifications, and whether the organization has selected the right platform. These are legitimate topics, especially when systems touch customer data, regulated processes, or sensitive internal information.
That’s not the wrong conversation. But it’s often a way to feel rigorous without being accountable. Leaders-and-boards can spend an hour on encryption standards and never once ask whether an AI-generated recommendation is quietly changing hiring, pricing, underwriting, sales prioritization, customer support, or financial forecasting.
The governance question I’d push every leader to answer first is much simpler: what decisions are being influenced by AI output, and who catches it when the output is wrong? Not who owns the AI strategy. Not who approved the budget. Not who reviewed the vendor contract. Those questions matter, but they are second-order.
[Email-readers,continue-here…]
The first-order issue is operational accountability. Who knows where AI is embedded? Who has authority to challenge the output? What evidence would show that the system is drifting, biased, incomplete, or simply wrong? And when something fails, how fast does the escalation reach a human with both context and responsibility?
If the leaders can’t answer that about even one material workflow, the oversight gap is already open. The technical briefings can come later, but they should not become a substitute for mapping decision rights, failure points, and escalation paths. AI oversight should begin with a plain-language inventory of where the technology affects consequential choices.
Good governance has always been about accountability before complexity. AI doesn’t change that principle. It just makes the gap more expensive when boards skip it, because errors can scale faster than traditional controls are designed to detect. A useful board discussion should therefore end with names, thresholds, and response times, not just enthusiasm about capability or reassurance about compliance.
