When to say no to AI
Not every process improves with a model in it. Eight situations where the answer is no, or not yet, and how to say it well.
The short answer
Not every process is improved by putting a model in it, and a business that cannot say no to AI proposals will end up with a collection of demos and no return. There are eight situations where the right answer is no, or more often not yet: the data does not exist or is not usable; a plain rule would do the job; the decision is irreversible and about people; the volume is too low for the effort; nobody would own it; the cost exceeds the problem; the trust cost with customers or staff is too high; or the only reason is that a competitor did it. A no with a reason and a condition keeps credibility for the yeses. Strategy is as much the list of things you will not do with AI as the list you will.
The eight situations
| Situation | Why no | What makes it a yes later |
|---|---|---|
| The data is not there | A model on missing or messy data produces confident nonsense | The data project: one source of truth, entry rules, an owner |
| A rule would do | If a person can state the logic in a sentence, code it; it is cheaper, faster and explainable | Only when free text or judgement enters the task |
| Irreversible decisions about people | Harm cannot be undone; the law often requires a human decision | Use AI to prepare and recommend; keep the decision human |
| Volume too low | A task done ten times a year does not repay a system | Volume grows, or the task is bundled with similar ones |
| No owner | An unowned system decays into a liability | Someone wants it enough to review its exceptions |
| Cost exceeds the problem | The full cost, including running and people, is larger than the pain | The problem grows, or the cost falls, which it does |
| Trust cost too high | Customers or staff would experience it as a downgrade or a deception | Design that keeps a person visible, and honest disclosure |
| Because a competitor did | The weakest reason; produces features nobody asked for | Your customers have the problem the feature solves |
Saying it well
- Name the specific proposal, not AI in general.
- Give the reason from the eight, in a sentence.
- State the condition under which it becomes a yes, and who owns getting there if anyone.
- Point to the yes: the project that is going ahead and why it passed.
- Record it in the roadmap as a deferred item with its condition, so it is not re-proposed monthly.
What a strategy’s no list looks like
We will not automate decisions about hiring, credit or access. We will not deploy a customer-facing assistant until the knowledge base is current and owned. We will not build on a vendor’s proprietary framework without a written exit. We will not start a pilot without a baseline, criteria and an owner. We will not adopt a tool because a competitor announced one. Five lines like these, written down, do more for a business’s AI outcomes than most of what is called strategy.
What this means for you
Practise the specific no: this proposal, this reason, this condition, and here is what we are doing instead. Keep a written list of what you will not do with AI alongside the list of what you will. Most of your best AI decisions this year will be the ones where you said not yet and fixed the data, the process or the ownership first.
Frequently asked questions
How do we say no without looking like we are against progress?
Say no to the specific proposal with the specific reason and the condition under which it becomes a yes: when the data exists, when the process is stable, when someone owns it. Then point to the project you are saying yes to. A business that says yes to one well-chosen thing and no to five poor ones is not against progress; it is doing strategy.
Is there a category we should never automate?
Decisions that significantly affect a person's rights or livelihood and cannot be easily reversed: hiring and firing, credit, access to essential services, medical and legal conclusions. The system may prepare and recommend; a person decides. Beyond that, most categories are a matter of readiness and design rather than principle.
What about when a competitor announces an AI feature?
Ask what problem it solves for their customers and whether your customers have that problem. Often the announcement is marketing and the feature is a demo. If the problem is real for your customers, put it through the same criteria as any other project. Doing it because they did is the weakest reason on the list and produces the worst projects.