When not to use AI

Most writing about these tools is about what they can do. The more useful skill, and the harder one, is recognizing the cases where reaching for one is the wrong move — particularly the cases that look like good candidates.

When a rule would do

The most common waste, and the easiest to miss because the AI version demos better.

If a clear rule solves the requirement, start there: for example, flag an empty field or escalate an amount above a defined threshold. Test the implementation and exceptions; explicit logic is easier to inspect, but can still contain bugs, bad inputs or stale rules.

Try articulating the conditions before choosing a model. Some apparent judgment tasks have a useful rule-based part; others contain ambiguity that a fixed rule will not resolve.

When you cannot check the output

The hardest constraint, and the one most often waved away.

If a consequential answer cannot be adequately validated, limit its use or keep a qualified decision maker involved. Define an evaluation appropriate to the task; not every creative or exploratory output has one objectively correct answer.

Count verification and correction in the total effort. If no time is saved, other measured benefits may still justify the workflow, but faster generation alone does not establish value.

When the failure is silent and consequential

Pay special attention when errors are both hard to notice and consequential. Assess those properties alongside their likelihood and recovery controls.

Silent failure means nothing announces the error. Consequential means it matters. A misfiled document that surfaces in six months. A subtly wrong figure that enters a board pack. A permission check that fails open.

A visible failure can still be costly, and a small silent error can accumulate. Assess likelihood, severity, detectability and recovery together instead of assuming either property alone is harmless.

When the problem is waiting, not working

A workflow can be slow for reasons outside the step you plan to accelerate. Find the cause before choosing the intervention.

Measure touch time and queue time before diagnosing a slow process. Either may dominate, and the causes can differ across steps and cases.

Reducing a four-minute task to one minute will not remove a separate six-day approval queue. Ownership, routing and alerts may address that delay; AI can sometimes assist triage, but it must address the cause and be compared with simpler changes. None of these changes is automatically free.

If you have not measured touch time against queue time, you do not yet know which problem you have.

When the interaction is the point

Some exchanges carry meaning beyond their content.

A manager’s feedback, condolence or apology can carry value because a person has taken responsibility and paid attention. If you use assistance, preserve that responsibility and review the actual message rather than sending an unread draft.

Using a model to think through what to say is fine and often helpful. Using it to produce the thing that gets sent, unread, is a category error that damages exactly the relationship it was meant to serve.

Two more worth naming

When you cannot explain the decision. In regulated contexts, some decisions must come with a defensible reason. “The model determined” is not one, and discovering this after deployment is expensive.

When benefits do not justify the total cost. Low frequency can weaken an automation case, but a rare task may still be costly, risky or valuable. Compare build, maintenance and review effort with the task’s actual outcomes rather than imposing a frequency cutoff.

The honest test

Use these questions to identify what needs evidence before proceeding. A weak answer should trigger investigation or a narrower scope, not an unsupported blanket verdict.

What would an acceptable outcome look like? How will it be checked at an appropriate cost? How will important errors be detected and recovered? Do the expected benefits justify implementation, operation and risk?

These questions can screen out a poor candidate early. They do not replace testing, data review or a fuller business case when the consequences justify it.

Three cases that look wrong and are not

Symmetry matters, because over-correcting wastes as much as over-adopting.

Routine work you can verify. Reformatting or drafting tests may be useful candidates, provided you check the result and compare with simpler tools. Repetition alone does not establish a high return.

A draft of work you understand. A generated starting point may help you get moving. Measure whether editing and verification are worthwhile rather than assuming they are faster than writing directly.

Work that needs judgment you will still apply. Thinking through a difficult decision with a model, then deciding yourself, is a legitimate and underused pattern. The failure is handing over the decision; using it to surface the counter-argument you had not considered is not the same thing at all.

The pattern underneath all of it

Every case in this post reduces to the same question: is the answer determined by something checkable, and will anybody actually check it?

Checkability and a real checking process are useful conditions, but not sufficient ones. Data handling, permissions, cost and human responsibility still matter, and an apparently checkable task can be a poor fit.

That question survives every model release, which is more than can be said for most advice in this area. It is also, usefully, a question you can answer in a meeting, before anybody has spent anything.

Why saying no is the valuable skill

Selection is one constraint alongside capability, integration, skills and governance. Match the proposed task to what the system can demonstrably do.

A team that has deliberately declined three bad candidates and shipped one good one is far ahead of a team that has three half-finished pilots nobody uses. And the declining is the harder skill, because it produces nothing visible and it requires saying an unpopular thing in a room where somebody is enthusiastic.

Which is why it is worth writing the reason down each time. “We considered this and here is precisely why not” is a genuinely valuable artifact — it stops the same idea returning blind in a year, and it makes the next proposal you bring considerably more credible.

Technical review, October 10, 2026. References: Anthropic: building effective agents; NIST: AI Risk Management Framework; OpenAI: evaluation best practices.

Try this

Write the strongest reason not to automate a proposed task, then identify the evidence that would support or overturn it. Record a bounded test or a reason to decline. The exercise surfaces assumptions; it does not prove you saved a quarter or found every objection.