Three Questions Every Executive Should Ask About Their AI Program

I've sat through enough executive AI briefings to see the pattern. They follow a pattern. The team presents metrics — adoption rates, cost savings, user satisfaction scores. Leadership nods. Someone asks "is the AI working?" The team says yes. Everyone moves on.

That question — "is the AI working?" — is the wrong question. It's too vague to govern against and too easy to answer with a number that sounds good but means little.

After a year of watching these briefings fail to surface the risks that matter, I've distilled it to three questions. If an executive asked only these three questions in every AI briefing, they'd have more governance insight than most organizations generate with entire committees.

1. "What decision does this AI system influence?"

This question forces specificity. And specificity is where governance starts.

A bad answer sounds like: "It improves efficiency in our customer service operations." That tells you nothing. Which decisions? Routing a call? Approving a claim? Recommending a denial? The governance requirements are wildly different depending on the answer.

A good answer sounds like: "This system recommends whether to escalate a customer complaint to a supervisor. The recommendation is accepted by the agent approximately 80% of the time. It influences complaint resolution outcomes for roughly 15,000 customers per month."

The good answer tells you what's at stake. It tells you who's affected. It tells you whether a human is meaningfully in the loop or just rubber-stamping. It gives you something to govern.

Why it matters: If you can't name the decision, you can't assess the risk. If you can't assess the risk, you can't design the controls. If you can't design the controls, you don't have governance — you have hope. And hope is not a strategy that survives examination.

Every AI system in your portfolio should have a clear, documented answer to this question. If a system "does a lot of things," break it down until each function maps to a specific decision. Vague scope is where accountability goes to die.

2. "Who is accountable when it's wrong?"

Not "who monitors it." Not "which team owns it." Who — a person, by name — is accountable when this system produces a wrong, biased, or harmful outcome?

A bad answer sounds like: "The AI Center of Excellence oversees model performance." That's a team, not a person. When the model drifts and nobody catches it for three months, who explains that to the board? When a customer is harmed by an automated decision, whose name is on the incident report?

A good answer sounds like: "Maria Chen, VP of Claims Operations, is accountable for this system's performance. She reviews monitoring reports monthly and has authority to suspend the system if performance degrades below defined thresholds."

The good answer has a name, a cadence, and authority. Maria doesn't just watch — she can act. That's the difference between accountability and observation.

Why it matters: Committees don't feel consequences. Individuals do. When accountability is distributed across a team, across a center of excellence, across a governance board — it's diluted to the point of meaninglessness. The question "who is accountable?" should produce a single name. If it produces an org chart, you have a structural problem.

I learned this in banking examination. Examiners don't ask "does the bank have a risk management function?" They ask "who is responsible for this control, and what evidence do they have that it's working?" The same question applies to AI, and it's coming.

3. "How would we know if it drifted?"

Not "do we monitor it?" — almost everyone says yes to that. The real question is: what specific signal would tell us this system is no longer performing as intended?

A bad answer sounds like: "We have a monitoring dashboard." Dashboards are tools, not answers. Who looks at the dashboard? How often? What thresholds trigger action? What happens when a threshold is breached? If the dashboard shows a yellow light, does anyone do anything, or does it stay yellow until someone asks about it in the next quarterly review?

A good answer sounds like: "We track three metrics: decision consistency rate, override frequency, and outcome distribution across customer segments. If any metric deviates more than two standard deviations from baseline for five consecutive days, an alert goes to the system owner, and the model is flagged for review within 48 hours."

The good answer is specific and actionable. It defines what "drift" looks like in measurable terms. It specifies who gets notified and what happens next. It doesn't depend on someone choosing to look.

Why it matters: Every AI system drifts. The data changes. The users change. The world the model was trained on stops being the world it operates in. The question is not whether drift will happen — it's whether you'll detect it before a customer does, before a regulator does, or before it shows up in the Wall Street Journal.

"We monitor it" is not an answer. "Here's what we watch, here's what triggers action, and here's what happens next" — that's an answer.

The briefing that works

Three questions. Each one takes sixty seconds to ask and forces the presenting team to demonstrate — not claim — that governance exists in practice.

1. What decision does this system influence?

2. Who is accountable when it's wrong?

3. How would we know if it drifted?

If your team can answer all three with specificity, you have the foundation of a governed AI program. If they can't, you've just learned more in three minutes than a 40-slide deck would have told you.

Ask the questions. Listen to the answers. The quality of those answers is your governance posture — not the framework on the shelf, not the principles on the website, not the committee on the org chart.