When to Say No to an AI Project

The hardest AI decision you'll make this year isn't which project to approve. It's which one to kill.

The pressure runs the other way. Every vendor is selling urgency. Every conference is selling FOMO. Every team has an idea, and every idea sounds plausible in a two-minute pitch. The default answer becomes yes, and the yeses pile up until the AI portfolio is a graveyard of demos that never became operations.

Saying no is how the yeses survive. The teams that win with AI aren't the ones that approved the most. They're the ones that killed the most, fast, with a clear reason.

The five questions

You don't need a committee or a scoring model. You need five questions, asked in order, with a no at any point ending the conversation.

Question one: does this solve a problem the business actually has? Not a problem the vendor identified, not a problem the technology could solve, not a problem that would be cool to have. A problem someone in your company can name, with a cost attached. If nobody can name the pain and its price, there's nothing to solve.

Question two: is this problem better solved by something simpler? This is the question that kills more AI projects than any other. The request to "automate our reporting with AI" that's actually solved by a scheduled export. The "intelligent" routing that's solved by a dropdown. AI is a hammer, and most requests are nails that a cheaper tool can drive. If a rule, a script, or a form fixes it, that's the answer.

Question three: can we check the output? If the AI's work can't be verified by a human in a reasonable time, you're building a black box that will eventually do something expensive and wrong. The unverifiable AI project is a liability with a roadmap.

Question four: is the cost of being wrong acceptable? This is the stakes question. The internal draft where wrong costs an hour is a yes. The customer-facing decision where wrong costs an account is a maybe. The compliance answer where wrong costs a regulator is a no — unless the human verification layer is built in and funded.

Question five: who owns it, and do they have time? An AI project without an owner is a demo. An owner without time is a wish. The owner is whoever feels the problem, not whoever's available. If the answer to question five is a shrug, the answer to the whole pitch is no.

The purpose of the questions isn't to find reasons to approve. It's to find reasons to kill — early, cheaply, and out loud.

How to say no without killing the culture

The no is easy. The culture damage is the risk. People stop bringing ideas when their ideas get dismissed, and the flow of ideas is the pipeline every good project eventually comes from. The no has to preserve the pipeline.

Say no to the project, not the person. The distinction is everything. "This specific problem doesn't justify AI" is a decision. "This idea is bad" is an insult. The team that proposed a dead project well is a team you want proposing again.

Say no with the reason. A no without a reason is a black box, and people read black boxes as "don't bring me anything." The reason makes the no teachable. "The problem's real, but a scheduled export solves it" teaches the team what AI is actually for. That's the no that makes the next proposal better.

And say no to the project, yes to the underlying need. When a proposal fails question one — no real problem — the conversation shouldn't end. It should pivot: "what are you actually trying to fix?" Sometimes the answer reveals a real problem with a different solution. That pivot is what keeps the proposer engaged instead of defeated.

The no that protects the yes

Here's the framing that makes this whole thing work. Every AI project competes for the same scarce resources: engineering time, review time, operator attention, and leadership patience. Every project you approve spends those resources. Every project you kill returns them to the pool.

The portfolio you want at the end of the year isn't the one with the most projects. It's the one where every project has a named problem, a verifiable output, an acceptable cost of error, and an owner with time. That portfolio only exists if you killed everything else.

The five questions take five minutes. The no saves a quarter. The team that got a clear no, with a reason, keeps bringing ideas — and their next idea is the one that works.

Five questions, asked in order, with a no at any point ending it. That's the whole discipline. The AI projects that survive are the ones that earned their yes. The rest get killed fast and out loud — and the portfolio gets stronger every time you do it.

Think this argument fits your event? Tell me about the room — the calendar is selective.