When not to use AI: a practical test for business leaders

AI has got good enough that people now suggest it for problems it has no business touching. That happens with every new tool. The hard part is knowing when to say no, and you do not need to be technical to spot it.

It’s worth saying who’s doing the suggesting, because the pressure has more than one source. Vendors, obviously, since AI is what’s selling. But also your own team, who’ve used it at home and want it at work; consultants whose proposals need a topical hook; and the general climate where “we’re using AI for that” sounds like an answer and “we wrote a validation rule” doesn’t. None of these people are lying to you. They’re just all pushing the same direction, and nobody in the room is paid to say “this is a job for a form”. So that job lands on whoever owns the budget, which is probably you. The good news is that saying no correctly doesn’t take technical depth. It takes a handful of patterns, and once you’ve seen them you can’t unsee them.

Use a rule when the rule is clear

If the work follows a stable rule, write the rule. Don’t ask an AI model to decide whether an invoice is overdue, whether a field is blank, whether a file exists, or whether a number has crossed a threshold. Software has done that kind of logic reliably for decades, and it does not hallucinate.

The comparison is stark when you line it up. A rule costs almost nothing to run, gives the same answer every time, and when it’s wrong, it’s wrong in a way you can read in the code and fix once. A model call costs money every single time, can give different answers to the same input, and when it’s wrong, the fix is prompt engineering, which is a polite term for negotiating with a black box. We’ve seen a proposal to use a language model to check whether purchase orders exceeded approval limits. That’s a greater-than sign wearing a very expensive costume.

AI is worth reaching for when the input is messy, the wording varies, or you need to interpret documents, images or language. “Is this email a complaint, an order, or a question?” is a real AI problem. “Is this invoice more than 30 days old?” never will be.

Use a form when the problem is missing data

Often the issue isn’t intelligence at all. Your staff or customers simply aren’t giving you the information you need. A better form with required fields, some validation and a cleaner handoff will fix that more reliably than any model.

This one hides well because the symptom looks like an interpretation problem. Enquiries arrive missing the job address, the preferred date, the budget, so someone proposes AI to extract what’s there and infer the rest. But inference can’t manufacture information that was never collected; it can only guess, and now your pipeline contains confident guesses dressed as data. The upstream fix, ask for the address, make the field required, validate the phone number, costs a fraction as much and produces information that’s actually true. We’ve built plenty of booking and intake forms that removed the need for a downstream AI project entirely. AI can help read messy submissions when you can’t control the source, a supplier’s PDFs, inbound email from the public. It’s a poor patch for a process that never asks for the right information in the first place.

Use integration when people are copying data

When staff are shifting data between systems you already know, API integration is usually the answer. AI might classify or tidy a few fields along the way, but the actual job is connecting the systems and deciding who owns what.

The tell here is the phrase “we want AI to read the screen and type it into the other system”. If both systems have APIs, and most modern ones do, then a direct connection moves the data perfectly, every time, for a known cost. Putting a model in the middle adds a component that can misread, costs per transaction, and needs monitoring, to solve a problem that plumbing already solves. The model-in-the-middle only makes sense when one end of the pipe is unstructured, when what’s arriving is a scanned docket or a free-text email rather than a record with fields. Then AI is doing a job integration can’t. Otherwise, swapping copy-paste for a language model is rarely the clean path; it’s the same manual process with a more unpredictable typist.

Avoid AI where errors are unacceptable and review is weak

AI can be wrong, and wrong with total confidence. You can manage that when a human checks the output, when the system shows its sources, and when a mistake costs little. It gets much harder when the output decides something about safety, legal position, money, medical care or someone’s job, and nobody is reviewing it.

The two-part structure of that test matters: it’s the combination of high stakes and weak review that’s disqualifying, not the stakes alone. AI drafting legal correspondence that a solicitor reads before sending is a sensible use. The same model sending it unreviewed is malpractice waiting for a docket number. So when someone proposes an AI use, ask where the human checkpoint is and what the checker actually sees. If the answer is that volume makes review impossible, that’s not an argument for skipping review. It’s an argument that this workflow, at this stake level, isn’t ready for automation of any kind. If you can’t support review, logging and correction, slow down.

Watch for novelty bias

AI can make a weak process feel exciting for a few weeks. Then the old problems wander back in: nobody owns the data, the approvals are still missing, and no one is on the hook for maintenance. A plain workflow fix looks boring next to a demo and usually does more.

Novelty bias has a budget signature you can spot in hindsight: the pilot that impressed everyone in month one, got quietly abandoned by month six, and taught the business nothing except cynicism. The pattern repeats because demos select for impressiveness and operations select for reliability, and those are different qualities. A chatbot answering staff questions demos brilliantly; whether anyone still asks it things in August is the real test. Before approving an AI initiative, ask what it will look like on a boring Tuesday in eight months: who maintains it, who notices when it drifts, what happens when the person who championed it leaves. The test is whether AI changes the outcome, not whether it changes the demo.

A useful question

Ask yourself: if this model vanished tomorrow, what simpler system would we build instead? If the answer is a database, an integration, a form or a rule engine, start there. If the answer is still that you need to read messy language, images or documents at scale, then AI is probably the right tool.

That question has a companion worth asking in the same breath: what has to be true about our data and processes for this to work? A surprising number of AI proposals assume clean, reachable data the business doesn’t have, in which case the real project is getting the data in order, and the AI part comes later, if it still needs to.

Good AI strategy includes restraint. Turning down the wrong use cases is how you protect budget for the ones worth doing, and it’s how you keep the team’s trust for the project that deserves it. This is, admittedly, an odd article for a studio that builds AI systems to publish, but it’s exactly why we publish it: the fastest way to lose a client’s confidence is to sell them a model where a rule would do. If you’ve got a proposal on your desk and you’re not sure which side of the line it falls on, send us the problem, not the pitch, and we’ll tell you whether it needs AI, plumbing, or a required field.