Teaching Your Team the Three Questions to Ask Before Approving Any AI Use Case

A well-designed AI governance framework, with careful risk tiers and clear approval processes, only actually works if the people proposing new AI use cases internalize the underlying judgment well enough to apply it themselves, most of the time, without needing to consult the full policy document for every decision. This is a teaching problem as much as a policy problem, and the most effective governance programs invest specifically in making three questions second nature across the whole team, not just documented in a framework few people read closely.

Question one: what happens if this is wrong?

This is the single most important habit to build, because it's the question that naturally sorts a proposed AI use case into the right risk tier without anyone needing to consult a formal tiering document. Teaching people to ask this concretely — not "could this go wrong" in the abstract, but "what specifically happens, to whom, if this particular output is wrong" — does most of the work of risk assessment before any formal review even happens.

A team member proposing an AI tool for drafting internal meeting summaries who asks this question concludes, correctly, that a wrong summary is a minor, easily-caught inconvenience. The same team member proposing an AI tool that auto-approves expense reports asks the same question and arrives at a very different, much more cautious answer — the habit of asking is what surfaces the difference, not a policy lookup.

Question two: who is accountable if it does go wrong?

This question does something different and equally important — it forces clarity about ownership before a system launches, rather than surfacing confusion about ownership only after an incident, when it's most costly to sort out. Teaching people to ask "if this fails, whose job is it to notice and fix it" before proposing a use case catches a specific, common gap: use cases proposed with genuine enthusiasm but no clear answer to who's actually watching the system once it's live.

A use case with a clear, specific answer to this question — "I own this, I'll review a sample of outputs weekly" — is meaningfully more ready to move forward than one where the honest answer is "I guess whoever notices a problem." The second answer isn't a reason to reject the use case outright, but it's a real gap that needs to be closed with a named owner before launch, not something to discover only after something's already gone wrong.

Question three: can we explain this decision to the person it affects?

This question catches a category of problem the first two don't fully cover — cases where the individual risk of any one output being wrong is low, but the aggregate pattern across many decisions raises a fairness or trust concern that only becomes visible when you imagine explaining a specific instance to a specific affected person. "We can't fully explain why the system flagged your loan application, the model just scored it this way" is a genuinely uncomfortable thing to have to say to a real customer, and imagining that exact conversation in advance surfaces explainability gaps that a purely risk-focused analysis might miss entirely.

Teaching this question specifically helps with cases that don't obviously fall into "high risk of harm" but still deserve real scrutiny — decisions that affect individuals in ways that feel consequential to them personally, even when the aggregate business risk looks manageable on paper.

Why three questions, and not a longer checklist

A short, memorable set of questions gets internalized and actually used; a longer checklist becomes something people consult occasionally rather than a habit they carry into every proposal. These three cover the core of what a formal risk-tiering framework is trying to assess — severity of a wrong outcome, clarity of ownership, and explainability to affected individuals — in a form simple enough that someone can genuinely hold it in mind while thinking through a new idea, rather than needing to open a document to check.

How to actually teach this, not just state it

Stating these three questions in a policy document accomplishes little on its own — the teaching happens through repetition in real moments: asking them out loud in meetings where a new AI use case comes up, referencing them specifically when reviewing a proposal ("walk me through your answer to the accountability question here"), and modeling the habit yourself visibly enough that it becomes the normal way ideas get discussed, not a compliance step people route around.

Over time, a team that's genuinely internalized these three questions produces meaningfully better-scoped AI proposals from the start — not because the formal review process caught fewer problems, but because far fewer problems ever reach formal review in the first place, having already been caught and addressed by whoever was proposing the idea, simply because asking felt natural rather than like consulting a policy nobody wants to open.

The AI Governance Playbook builds this exact three-question habit into its own risk-tiering framework as the practical, teachable front door — the formal tiering system described in this framework and the three questions here work together, with the questions doing the everyday work of catching most issues early, and the formal framework handling the smaller number of genuinely high-stakes cases that need real, structured review.