Where Does AI Earn Its Place, and Where Is a Rule Enough?

A team asks for AI in their triage step. What they describe, once you push on it for ten minutes, is a rule: if the enquiry mentions billing, send it to the person who handles billing. Nobody needs a model for that. They need somebody to write six lines of logic and then have the useful argument about the seventh.

That pattern is common enough that we start from the opposite default to the one currently in fashion. Write the rule first, and make the model argue for its place. A model earns that place on three tests: how much the input varies, what a wrong answer costs, and whether anybody will need the reasoning explained afterwards. Two of the three pointing the same way usually settles it before lunch.

The question of when to use AI gets asked as a technology question and is almost always a process question underneath. What follows is the three tests, three jobs where a rule wins outright, three where a model genuinely earns its keep, and the shape most working systems settle into once the novelty has worn off.

Start from the rule and make the model argue

A rule is anything a person wrote down and a machine follows exactly: an if-then, a lookup table, a threshold, a pattern match, a small state machine. Unglamorous, and that is most of the appeal. A rule costs nothing per run. It gives the same answer today and in March. A test can prove it. And the person who has to defend the decision in a meeting can read it.

The reason to start there is not nostalgia for older software. It is the failure shape. A rule fails loudly and completely: it does the wrong thing for every case that hits it, somebody notices within a day, and the fix is a line. A model fails quietly and partially. It is right nine times, then wrong in a way that looks exactly as confident as the nine, and nobody notices until a customer does. Loud total failure gets fixed on Tuesday. Quiet partial failure runs for a quarter.

There is also a diagnostic worth applying before any of the technical tests. A request for AI is often a request for something else in better clothes: faster answers, fewer handoffs, a decision made without another meeting. Those are process problems, and automating around them tends to preserve them. The instinct here is the same one that asks whether a feature request is really a positioning problem: answer the question behind the question first.

When to use AI: the three tests

Run these in order on the specific step, never on the whole workflow. Workflows do not qualify for anything. Steps do.

How much does the input vary?

Can you write the cases down? Not approximately. Actually list them on one page. If the thing arriving is a form with six fields and a dropdown, the variance is bounded and a rule covers it completely. If the thing arriving is a paragraph a human typed at eleven at night, in their own words, about a situation you did not anticipate, the variance is unbounded and every rule you write will be a new exception.

The dividing line is enumeration, not complexity. A rule with two hundred branches is still a rule, still testable, still explainable one branch at a time. It only becomes the wrong tool when you cannot list the branches at all, because new ones keep arriving from outside your control.

What does a wrong answer cost?

Price the worst plausible wrong answer rather than the average one. If a wrong answer moves money, grants access, states a legal position, or tells somebody they qualify for something they do not, the cost is high. High cost means a rule or a person, not a probability. If a wrong answer produces a slightly clumsy first draft that an editor fixes in ten seconds, the cost is near zero and you should stop agonising over it.

Then look at where the error surfaces. An error caught inside a review step costs the review. An error that reaches a customer costs trust, and trust is repaired at a rate you do not control. Two designs can use the same model and sit on opposite sides of that line purely because one of them put a person between the output and the world.

Does anybody need to be told why?

Some decisions carry an obligation to explain: a refusal, a price, an eligibility outcome, anything a customer or a regulator can reasonably ask about. A rule explains itself by existing. You point at the condition that matched and the conversation ends. A model produces an answer and, if asked, a plausible account of that answer, which is a reconstruction rather than a record. Treat it accordingly.

If you cannot describe what the model decided in one sentence containing the word "because", it is not ready to make that decision unsupervised.

They fail in opposite directions

Hold one distinction before reading the table. Rules fail on the cases you did not think of. Models fail on the cases they were not shown. Those sound like the same sentence and behave nothing alike, because you can read a rule and find the gap, whereas the gap in a model is visible only in its output, after the fact, if somebody is watching.

Three jobs where the rule wins outright

Each of these gets proposed as an AI project somewhere every week. In each one the model would be slower, more expensive, harder to test, and occasionally wrong in a way nobody catches.

1. Routing an enquiry that arrived on your own form. You already asked which service the person wants and what kind of organisation they are. You paid for that classification at the point of collection. Using a model to re-derive it from the message body is paying twice and then trusting the less reliable copy.
2. Deciding eligibility. Refund windows, discount tiers, access levels, approval thresholds. The policy is written down, it has to be applied identically to everybody, and when it changes it changes by a decision somebody can point at. That is the definition of a rule.
3. Turning structured data into a sentence. Order confirmations, status updates, weekly figures, appointment reminders. A template with slots is faster, free, testable, and structurally incapable of inventing a delivery date nobody promised.

The tell in all three is that the information was already structured before anybody reached for a model. When the fields exist, use the fields. A model asked to infer what you already know is an expensive way to introduce doubt into a process that had none.

Three jobs where the model genuinely earns it

The mirror image. In each of these a rule would need an unbounded number of branches, and the cost of being occasionally wrong lands somewhere survivable.

• Pulling structure out of text a human wrote freely. Call notes, transcripts, inbound emails, supplier documents that arrive in nine formats. No rule enumerates the phrasings. A model extracts the fields, and a person confirms them in a form that takes four seconds instead of four minutes.
• Answering questions across your own documentation. The phrasing of the questions is unbounded; the set of correct answers is not. That asymmetry is exactly what a grounded assistant is for, provided it answers only from your material and says so plainly when it cannot.
• First drafts and transformations. Summarising a long thread, rewriting to a set tone, suggesting alternative text for images, drafting release notes from commits. The output is a starting point, and a person sits between it and anybody who matters.

The second one deserves a caveat, because it is where most of the disappointment lives. An assistant answering from a general model rather than from your pages will produce confident answers about your business that nobody at your business would give, which is the failure examined in why a chatbot gives wrong answers when your pages are correct. The split that works is visible in a widget like Flidu, which pairs website-informed AI assistance with ordinary contact, information and conversion actions: the model handles the phrasing, and the actions stay buttons that do exactly what they say.

What working systems actually look like

Nearly every system we would ship is a rule with a model inside it, rather than a model with rules bolted on afterwards. Deterministic on the outside: routing, permissions, thresholds, anything touching money or access. Probabilistic in the middle, at the one step where the input genuinely will not sit still. The model is a component. It is not the architecture.

Concretely: a rule decides that an enquiry is a sales enquiry, a model summarises the free-text field into three lines, a rule decides the owner from the fields already collected, a template writes the acknowledgement, and a person approves anything crossing a threshold. Remove the model from that and the system still works, slightly worse. That is the test of a good placement, and it is what separates automation and integration work that removes a handoff from work that only adds a dashboard.

The design rule we keep returning to: put the model where its failure is somebody’s inconvenience, never where its failure is somebody’s outcome. Applied across a business, that is what an honest programme of AI-enabled operations looks like: a handful of narrow placements with review around them, rather than one large ambition with a demo attached to it.

The cost you are signing up for

The honest concession, because the rules side of this argument has a weakness it likes to skip: rules rot. A rule written for last year’s product accumulates exceptions until nobody can read it, and the twentieth condition that only one person understands is genuinely worse than a small model with an evaluation set behind it. When a rule reaches that state the problem is not the technique, and it is the same signal discussed in when to rewrite instead of refactor, deserving the same honesty.

That said, the model carries the larger standing cost, and most of it is invisible on the day you ship. You are committing to an evaluation set somebody maintains, a review step somebody performs rather than clicks through, a bill that scales with usage, a vendor whose behaviour can change without appearing in your release notes, and the slow, unglamorous work of noticing that outputs have drifted since March.

The review step is the part teams under-resource first, usually within a fortnight of launch. It needs a named reviewer, a defined thing they are checking for, and permission to send work back, which is the discipline set out in the reviewer’s pass. Build the evaluation set before the feature rather than after the first complaint. It is the same instinct as choosing between testing with five users and shipping to measure: decide what would count as evidence while you can still act on the answer.

How we would decide, on an ordinary Tuesday

Write the rule first, even when you fully intend to replace it. It takes an afternoon. It produces the baseline every later comparison needs. And often enough it turns out to be sufficient, at which point the project is finished and nobody has to maintain a prompt for the next three years.

If the rule is not good enough, you now know precisely where it fails, and that list is the only useful specification for whatever replaces it. Show the model those cases. If it handles them, and you have a way to see the day it stops handling them, ship it behind a review step. Take the review step away later, if you take it away at all, on evidence rather than on confidence.

The reversal condition is arithmetic rather than philosophy. At very high volume with cheap errors, a model earns its cost easily and a rule collapses under its own exceptions. At low volume with expensive errors, the model is a liability wearing a demo. Most businesses live nearer the second corner than the first, and buy for the first one anyway.

So the default stands: a rule wherever the cases can be listed, a model where the input genuinely refuses to sit still, and a person wherever a wrong answer costs more than the review would. That is most of what good AI development and integration comes down to in practice. If you want a second opinion on one specific step before anybody builds it, tell us what the step is and what happens when it gets the answer wrong.