The Question That Turns AI Approvals Into Strategy

Key Takeaways

• Approvals Are Strategy: Every AI tool approval shapes direction whether anyone frames it that way
• Ask Before You Approve: An outcome-first question exposes what a vague justification hides
• Undefined Outcomes Compound: Unmeasured tools survive on habit, and the pattern repeats
• Checkpoints Aren't Judgment: Passing every review doesn't mean the tool is worth having
• Ownership Beats Management: Define who confirms the outcome, not just who administers the tool

---

A department lead sits through a fifteen-minute demo, watches an AI tool summarize a messy spreadsheet in seconds, and says yes. A colleague on another team already uses something similar. The vendor's pricing page has a "starter tier."

The demo already answered one question: does this look impressive? Here's the better one: what outcome is this tool supposed to produce? This kind of moment repeats itself across organizations, and it usually doesn't register as a strategy conversation at all.

AI strategy gets treated like a document that leadership writes and departments execute. In practice, every approval within a department's authority is a small strategic decision in its own right, and enough of them can reshape how a team works long before anyone above the department connects the pattern.

The fix is one question anyone with approval authority is already positioned to ask.

Ask What Outcome You're Approving

Strategy usually sounds like something that happens above your pay grade, in a planning offsite or a slide deck with a five-year horizon. But every time someone with budget authority approves an AI tool, they're making a small-scale strategic decision.

It changes how work gets done, and those adjustments accumulate into something that shapes the organization's direction even if nobody planned it that way. ITIL version 5 reflects this directly. The framework's strategy model builds in a feedback loop between long-term direction and what happens during implementation, and every AI approval sits inside this loop.

• Vague justification: "Everyone's using AI." "It saves time." "The demo looked great."
• Outcome-first question: What changes because of this tool, for whom, and what would we see in three or six months that tells us it worked? Who's checking?

The problem sits in how the approval gets framed the moment it's made. Without a reason to treat it otherwise, it can default to something informal: a favor to a colleague, a convenience, or a request nobody thought to slow down on. The fix starts with a simple distinction: an outcome-first question versus a justification that only sounds like one.

An outcome-first question forces a level of specificity a vague justification can’t. Skipthe specificity at the approval stage, and you have no meaningful basis for evaluating the decision later.

A department lead who asks an outcome-first question up front might get an answer like this: the tool should cut the time spent compiling weekly status reports, freeing up two hours a week across the team. This answer gives the approval something to measure against later, and a clear signal if the tool doesn't deliver instead of a vague sense that things feel a little faster.

Turn Every Approval Into Evidence You Can Use

A defined outcome does more than justify an approval. It becomes something to point to later, when the department needs to know whether the tool delivered any real benefit. Skip this step, and there's nothing to point to when that moment comes.

Without a defined outcome, there's no baseline to measure the tool against later:

• No accountability trail: nobody can say six months in what the tool was supposed to change
• Habit over evidence: usage continues because it's routine, not because anyone re-confirmed the value
• Absence as proof: the only sign it's "working" is that no one has complained

If a loosely justified tool survives on the strength of no one challenging it, the next request gets the same light treatment. Precedent does more work than policy here. A department that approved a note-taking tool based on a colleague's word and a research tool based on an impressive demo provides no standard for the next tool request. These choices seemed reasonable at the time, but together they add up to an indefensible tool stack.

This isn't about achieving certainty. It's about having enough evidence to make a reasonable call, rather than defaulting to "it feels fine" because no one set a bar to check against.

Replicated across multiple departments, what looks like scattered inefficiency is an accountability problem hiding in plain sight. The people positioned to catch it typically aren't looking for it, because that judgment call sits outside their usual scope.

Use the Judgment No One Else Can

Department-level approvals often never need to cross a desk above them, even though other functions may weigh in on pieces of it along the way. No executive reviews the decision as a whole, and no governance committee logs it. The judgment that ties those pieces together, whether the tool is worth having, stands entirely on what the department lead brought to it.

It's tempting to lean on other organizational functions to catch what the department lead might miss. Several checks typically apply before a tool goes live, and each matters in its own right.

• Procurement: confirms the contract terms are sound, not whether the tool should exist in the first place
• IT and security: confirm the tool won't create technical or data risk, not whether it solves a real problem
• Finance: validates cost and return assumptions, not what the tool is specifically meant to change for this team

But those checks validate different dimensions of the case. None of them can stand in for the department lead's own judgment about whether the business case is worth pursuing. This judgment belongs to the person closest to the work, and it doesn't transfer because a tool clears every other checkpoint.

A tool can pass every check and still be the wrong tool for the job it was bought to do. None of them were ever built to catch that.

A clear outcome doesn't settle every question either. Security, integration, and workflow disruption still deserve a look. It gives the business case something concrete to evaluate instead of a guess.

You can outsource the vetting. You can't outsource the decision.

None of this is a case for building a bigger governance apparatus. The question at the center of this is a local control that lives with the person saying yes, not a substitute for enterprise AI governance, and it's the one question worth asking before making a decision.

Make the Question Part of Every Approval

The person closest to the business problem, not just the tool, is best positioned to ask what outcome it's meant to produce, yet that question sometimes goes unasked. Fixing that doesn't take a new process or a committee. It takes one standing question, asked the same way every time: what outcome are we approving, how will we know, and who owns it.

Ownership means being accountable for checking back later and confirming whether the outcome materialized. The check must happen at a specific interval: three months out, at renewal, or whenever the team expected the outcome to show up.

• Who manages it: handles the license, renewals, and vendor relationship
• Who owns it: answers, months later, whether the outcome the tool was approved for showed up

The timing of the question matters. Ask it once a tool has already impressed everyone in the room, and it feels like second-guessing something already settled. Ask it before any decision is made, and it becomes how approvals work.

In practice, that means replying to a tool recommendation with one line before any demo gets scheduled: what outcome are we hoping this produces? Setting the expectation early costs nothing.

A quick example shows the difference. Someone requests an AI meeting tool because "it saves time." The justification sounds complete, but it isn't specific enough to evaluate.

No matter the tool, the question remains the same, but the depth of the answer doesn't. A low-cost, low-risk tool might take thirty seconds to answer well. A tool that touches customer data or automates a consequential decision should trigger a longer conversation before anyone says yes.

Questioning outcomes forces it further. Saves time on what, exactly, for which team? Does that mean fewer administrative hours or faster follow-up on decisions made in the meeting? Answering those questions also identifies who's accountable for checking whether it worked.

None of this requires new tooling or sign-off from someone else. It's one question, asked at the right moment, by whoever already has the authority to say yes. This authority makes the question a starting point, not an ending one: the same standing question that governs one approval is what turns scattered decisions into something the organization can account for.

Claim the Authority You Already Have

Department-level AI approvals aren't downstream of strategy. They're inputs into it. Every yes at that level either strengthens the organization's overall AI direction or works against it, whether anyone above the department ever finds out.

You don't need to own the company's AI strategy to shape it. If you have the authority to approve an AI purchase, you're already shaping it, one decision at a time. The standing question from here forward is simple: what outcome are we approving, how will we know, and who owns it.

Asking that question takes more than good instincts. It takes enough structure to tell a compelling demo apart from a capability that solves the problem in front of you, which is exactly what a framework like ITIL version 5 is built to provide.

New Horizons delivers ITIL version 5 training, built for the AI-driven environments the framework now addresses. This training sharpens the judgment to tell a compelling demo from a capability that solves business problems, before the final decision instead of after.

Would your last AI approval survive that question?

Reach out to New Horizons to build the skills your teams need to evaluate what an AI tool is meant to accomplish, and who's accountable for confirming it did.