When Not to Use AI

There’s a question I find myself asking more often than “should we use AI for this?” It’s the opposite: should we not?

The pressure to add AI to everything is real. Every roadmap review, someone suggests an AI-powered version of a feature that already works fine. Every competitor ships an AI something, and the instinct is to match it. But the best product decisions I’ve made in the last two years have been deciding where AI doesn’t belong.

Here’s the framework I use.

Question 1: Is the problem shaped right for AI?

AI is good at a specific class of problems: tasks where the input is messy or ambiguous, the “right” answer is fuzzy, and a human would use judgment rather than follow a rule. Classification, summarization, extraction from unstructured data, pattern recognition — these are AI-shaped problems.

But plenty of product problems aren’t shaped like that. If the task has clear rules, deterministic logic, and well-structured inputs, a traditional algorithm will be faster, cheaper, more reliable, and easier to maintain. You don’t need a language model to validate an email address or calculate sales tax.

The test I use: could a very literal, rule-following person do this task perfectly by following a flowchart? If yes, you probably don’t need AI. AI shines when the flowchart would be impossibly complex or when the task requires the kind of judgment that’s hard to encode in rules.

Question 2: Can you tolerate the failure mode?

Every AI feature will be wrong sometimes. The question isn’t whether it will fail — it’s whether the failure is acceptable.

There are tasks where being wrong 5% of the time is fine. Search suggestions, content recommendations, auto-tagging — if these are occasionally off, users shrug and move on. The cost of failure is low.

Then there are tasks where being wrong 5% of the time is catastrophic. Financial calculations, medical dosage recommendations, access control decisions. If an AI feature deletes the wrong file or miscalculates a payment, the damage far outweighs the convenience.

Before committing to an AI approach, I map out the worst-case failure scenario and ask: if this happens to a real user, what’s the impact? If the answer makes me uncomfortable, I either add heavy guardrails or choose a deterministic approach instead.

Question 3: Is the juice worth the squeeze?

AI features are expensive to build and maintain. Not just in compute costs — though those are real — but in the ongoing effort to evaluate quality, retrain models, handle drift, and debug issues that are inherently harder to reproduce.

A deterministic feature, once shipped, is largely done. An AI feature is never done. You’re committing to an ongoing investment in evaluation, monitoring, and iteration. That’s fine when the value justifies it. But I’ve seen teams introduce AI for marginal improvements over simpler solutions, then spend months maintaining a system that’s more complex than it needs to be.

The question I ask: if we built the simplest non-AI version of this feature, how much worse would it be? If the answer is “a little worse but much simpler,” that’s usually the right call. Save the AI investment for the features where the delta is enormous — where AI enables something that simply wasn’t possible before.

Putting it together

When I evaluate whether to use AI for a feature, I walk through these three questions in order. If the problem isn’t AI-shaped, stop there. If the failure mode is unacceptable, stop there. If the value over a simpler approach is marginal, stop there.

This sounds conservative, and it is. But I’d rather ship five AI features that genuinely work than fifteen that are mediocre. Users don’t give you credit for using AI — they give you credit for solving their problem. And sometimes the best way to solve the problem doesn’t involve AI at all.

The hardest skill in AI product management isn’t knowing when to use AI. It’s knowing when not to.