When not to use AI: signs a rule, a form or a report will do better.

The request reads: “Use AI to check whether items are in stock before we confirm an order.” It is a reasonable wish and the wrong tool. The stock level already sits in the inventory system, and a query returns it exactly, instantly and for almost nothing.

Many AI requests look like this. They are better solved by a rule, a lookup, a redesigned form or a report. A model used where the answer must be exact, the volume is tiny or nobody owns the outcome adds cost and risk without adding value.

Why should saying no be part of an AI strategy?

Every model call brings a price, a delay, a way to be wrong and something to monitor. A rule brings none of these. Saying no to the wrong requests protects the budget, and the credibility, for the right ones.

It also sharpens the yes. A useful strategy names where AI makes a real difference and where it would be a distraction, and “stop” is a legitimate answer. The four patterns below are good reasons to give it.

When is a rule or a lookup better than a model?

The model as calculator. Warning signs: the answer already sits in a system of record, the logic fits on one page of if-then rules, and the answer must be identical every time.

Take some illustrative examples. Tax calculations belong in code that applies the rates your finance team maintains with its tax advisor. A stock check is a query against the inventory system. Routing approvals by amount is a rule: above the threshold, the request goes to a manager. A model asked to do any of these will usually get them right, and “usually” is not a standard for tax or stock.

The fix: keep calculations and exact lookups in systems of record, and use models for what they do well: reading, classifying and drafting unstructured text.

A model is the most expensive way to get an answer a rule already knows.

When does the process need fixing first?

The model that guesses the missing field. Warning signs: most of the AI’s work would be compensating for bad inputs, such as free-text forms, optional fields that should be mandatory or three versions of one template.

In an illustrative case, a supplier onboarding form lets people type the bank country and tax office as free text, and someone proposes a model to infer them. A form that asks for them, with a list to choose from and a check before submission, gets them right every time for a fraction of the cost.

Watch for disagreement, too. If two experts answer the same case differently, the policy is unclear, and no system will be more consistent than the rules it follows. The fix: repair the form or the policy first. The AI question often disappears.

When is the volume too low to justify a system?

The system for a dozen cases a year. Warning signs: the task happens about once a month, each case is different, and the person who does it spends an hour a quarter on it.

A system has fixed costs whatever the volume: the build, an evaluation set, monitoring, a security review and an owner. Low volume never repays them. The fix: a checklist, a template or a report. If the need is to see numbers, build the report; a weekly exceptions list from the ERP beats an assistant people must remember to ask. For occasional drafting, the general assistant a person already has is enough.

When is the tolerance for error too tight?

Zero tolerance, probabilistic tool. Warning signs: a single wrong answer is unacceptable and would not be caught before it matters, as with a regulatory filing, a payment instruction or a safety procedure.

Language models produce likely answers, not certain ones. If a reviewer would have to redo the whole task to catch an error, AI adds cost, not speed. The fix: keep the decision in code or with a person. At most, let AI gather the evidence a person then checks line by line, and measure whether that is actually faster.

How do rules and models work together?

Good designs rarely choose one. They combine three layers:

1. Rules handle the clear cases: anything that can be decided from structured fields.
2. A model handles the unstructured rest: the email, the attachment, the free-text justification.
3. A person handles the exceptions: whatever the rules can’t decide and the model isn’t sure about, plus every consequential action.

Take an illustrative purchase-request flow. Rules route by amount and cost center. A model reads the justification and the attached quote, suggests a category and flags missing information. A person approves above the threshold and handles whatever was flagged. The approval points are designed before anything is automated, as in how we work, and the same logic decides whether you need an agent or a workflow.

What is a quick test before approving an AI idea?

1. Could a rule, a lookup or a calculation give the exact answer? If yes, write the rule.
2. Is the input unstructured, such as text, documents, conversations or images? If not, a language model is probably the wrong tool; structured data may need classic machine learning or plain statistics.
3. Is the process stable and owned, with inputs you could fix at the source? If the form is the problem, fix the form.
4. Is there enough volume to repay building, testing and monitoring a system?
5. Can errors be caught or afforded, by a reviewer or a cheap reversal?

An idea that fails the first or third question needs a rule or a fix, not a model. One that passes all five is ready for the four tests for a first workflow. For a second opinion on a long list, sorting ideas into build, buy, wait or stop is part of AI strategy and discovery.