AI Governance and Risk: Five Questions Every Board Should Ask

A decade ago, cyber risk made the same journey AI risk is making now. It started as a technical line item in the CIO's report, became a recurring agenda topic after a few public failures, and ended up as a standing board responsibility with its own committee time, its own disclosure expectations, and its own vocabulary. Directors learned to ask about patch cadence and incident response without becoming engineers. AI governance and risk is at the start of that same arc, but most boards have not yet built the vocabulary.

The gap matters because the stakes are asymmetric. A company that governs AI badly faces regulatory exposure, quiet model failures, and data it had no right to use. A company that refuses to engage with AI at all faces something worse: irrelevance on a five-to-ten-year horizon, in an era when institutional advantage is being repriced. The board's job is not to choose between those risks. It is to hold both at once.

You do not need a data science degree to do that. You need five questions, asked consistently, with follow-up. Here they are.

1. Where is AI already in use in this company — sanctioned or not?

Most boards assume the answer is whatever appears in the technology budget. It almost never is. Surveys of knowledge workers consistently find that more than half use generative AI tools at work, and that a majority of that use happens on personal accounts, invisible to IT. Whatever the true figure inside your company, it is not zero.

This is shadow AI: the sales team drafting proposals in a consumer chatbot, a finance analyst summarizing contracts in a free tool, developers running coding assistants on personal subscriptions. A 40-person logistics firm might discover its dispatchers have been using a chatbot to draft customer delay notifications for six months. That discovery is useful signal, not grounds for discipline. It tells you where the demand is.

The first act of governance is an inventory. Ask management to run a 30-day amnesty: every team declares what AI tools it uses, on what data, feeding which decisions, with no penalty for honesty. The output is a simple register — tool, owner, data touched, decision affected. Expect the first version to be incomplete. Repeat it quarterly until it stabilizes.

What boards should not do is reach for a ban. Blanket prohibitions rarely stop use; they relocate it to personal devices where you cannot see it, log it, or correct it. You cannot govern what you have not mapped. Map first.

2. Which decisions has AI been delegated, and who is accountable when it is wrong?

There is a meaningful line between AI that drafts and AI that decides. A model that suggests an email is a productivity tool. A model that declines a refund, screens a job application, or flags a transaction has been delegated a decision — and delegation without accountability is where governance failures begin.

Ask management for a decision-rights register: every consequential decision where a model now participates, classified by two axes. First, reversibility — can the decision be cheaply undone, or does it compound? Second, impact — does it affect a customer's money, health, employment, or legal standing? High-impact, hard-to-reverse decisions need a human making the final call with the model advising. Lower-stakes, reversible decisions can run with a human reviewing samples after the fact. The vocabulary is worth learning: human-in-the-loop for the former, human-on-the-loop for the latter.

Then ask the harder question: when the model is wrong, who owns it? Every consequential model needs a named human owner — not a committee, not a vendor, a person. "The model decided" is not an answer a regulator, a court, or a wronged customer will accept, and boards should not accept it internally either. Accountability follows the decision, not the tool. If nobody in the room can say whose name is on a given model, that model is ungoverned, whatever the policy document says.

3. What data feeds our models, and do we have the rights to use it that way?

Data rights are where AI risk and legal risk meet, and the exposure usually hides in the gap between what data you hold and what you collected it for. Customer records gathered to deliver a service are not automatically available to train a model. Most privacy regimes apply some version of purpose limitation: data used for a materially different purpose than the one disclosed needs a fresh basis. A model trained casually on support tickets, call transcripts, or contract archives can embed an obligation problem that surfaces years later.

The same scrutiny applies in both directions. Inbound: where did the training data come from — licensed, scraped, purchased, generated — and would the provenance survive a dispute? Outbound: when employees paste documents into consumer AI tools, that is data leaving the building. Some consumer tiers retain inputs and may use them for training; most enterprise tiers contractually do not. The difference is a procurement decision, and it is cheap relative to the alternative.

Boards do not need to read the contracts themselves. Ask for a data map covering the top five AI use cases: what data goes in, under what rights, what comes out, and where it is stored. If management cannot produce one inside a quarter, that is the finding.

4. How would we know if a model started failing?

Software tends to fail loudly. Models fail quietly. A fraud model, a pricing model, or a document classifier does not crash when the world changes — it keeps producing confident answers that are gradually more wrong. The technical term is drift: the data flowing in shifts away from the data the model learned from, or the underlying relationships change. A model that scored 92 percent accuracy at launch may be running at 84 percent eighteen months later, and nothing on any dashboard will say so unless someone built the dashboard.

The board does not need to understand drift detection mathematically. It needs to confirm four things exist. A golden dataset — a fixed set of cases with known correct answers, re-scored monthly, so accuracy is measured rather than assumed. Output sampling — a human reviews a random slice of model decisions on a schedule, looking for the errors metrics miss. Thresholds set before launch — the accuracy or error level at which the model gets escalated, agreed in writing while everyone is calm. And an escalation path — who gets the call, who can suspend the model, and what the fallback process is when they do.

This is the same discipline boards already expect for cyber incidents, applied to a quieter class of failure. If the answer to "how would we know" is "a customer would complain," the monitoring does not exist yet.

5. Which regulations apply to us today — and in 24 months?

The regulatory picture is moving fast enough that a point-in-time answer is already stale, so the question has two horizons.

Today, three forces matter for most companies. First, the EU AI Act, which classifies systems by risk tier — prohibited practices, high-risk systems with substantial compliance obligations, limited-risk systems with transparency duties, and minimal-risk everything else — with obligations phasing in through 2026 and 2027. Its reach extends beyond Europe: serve EU customers, and portions apply to you. Second, sector regulators applying existing law to new tools — financial supervisors extending model-risk expectations, health authorities scrutinizing clinical AI, employment regulators examining automated hiring. AI does not exempt a decision from the rules that already governed it. Third, in the United States, a growing patchwork of state-level AI statutes with differing definitions and duties, which effectively forces multi-state operators to build to the strictest standard they touch.

The 24-month horizon is the board-level question, because compliance built reactively is expensive and compliance built early is mostly process you wanted anyway. Ask for a one-page regulatory map — which regimes apply now, which will apply within two years, and what the gap is — refreshed twice a year. Honest answer included: for some emerging rules, the correct entry is "not yet clear, monitoring." Candor beats false precision.

Governance is how you say yes

It is worth being direct about what all this scaffolding is for, because the word governance has come to suggest friction. The scaffolding on a building is not there to stop the work. It is there so people can work at height, quickly, without anyone falling.

The pattern shows up consistently: companies with a clear decision-rights register, a data map, and pre-agreed monitoring thresholds approve new AI pilots in days, because nobody has to litigate first principles each time. Companies without them either stall every proposal in legal review or wave everything through and absorb the risk unexamined. Good AI governance is the mechanism by which a company says yes to AI more often, faster, with fewer regrets. Weak governance produces both outcomes you fear at once: slow adoption and unmanaged exposure.

Which points to the board's real job here. It is not to become technical, and it is not to choose between caution and ambition. It is to set pace — to satisfy itself that the company is moving as fast as its controls allow, and no faster, and that the controls themselves are improving fast enough to permit more speed next year. Directors who can hold that line need a working vocabulary more than they need expertise, which is precisely what executive AI training is for. Turnings reward the prepared. The five questions above are how a board starts preparing.

If you want a candid read on where your organization stands, book a strategy call and we will tell you plainly what we see — including where the answer is "you are further along than you think." Or start on your own time with our AI Maturity Assessment, a structured way to score your current posture across strategy, data, governance, and capability before the next board meeting.