Where it belongs in your automation, and where a rule is still the better tool.

Automation is not new

Businesses have been automating for decades. Approval thresholds. Recurring invoices. Reordering rules. Scheduled reports. Follow-up sequences.

All of that is automation, and none of it is AI. It is rules — written by a person, doing exactly what they were told.

The useful question is not “should we use AI to automate?” It is: for this particular task, is a rule or a model the right tool?

Getting that wrong in either direction is expensive.

The difference in one line

A rule does what you told it. A model does what usually works.

Everything else follows.

A rule is explicit, predictable and auditable. It handles exactly the cases it was written for and fails on everything else.

A model handles cases nobody anticipated, and it is right most of the time rather than always.

Where rules are the right answer

Five situations. Notice how many ordinary business tasks fall here.

The logic is a definite policy. “Orders over 50,000 need director approval.” There is no judgement in that. A rule is correct every time and a model would be worse.

You must explain the decision. Anything an auditor, regulator or customer may question. “Because the rule says so” is an answer. “The model determined it” is not.

An error is expensive. Payment thresholds, credit limits, tax treatment. You want predictable, not usually-right.

You have little data. A model needs examples. A rule needs one person who knows the policy.

The rule changes by decision. Your approval limit changes because management decided. A model learning from history would still apply the old one.

Where a model is the right answer

Four situations.

The variation is unbounded. Supplier invoices arrive in thousands of layouts. Writing a rule per layout is impossible.

A pattern exists that nobody can articulate. Which invoices get paid late. Which leads convert. There is a pattern; nobody can write it down.

Conditions shift over time. Demand moves. A fixed reorder minimum does not. A forecast does.

The input is unstructured. Documents, free text, images. Rules need structure.

Most systems need both

The practical answer is rarely one or the other. It is a chain.

Processing a supplier bill:

A model reads the scanned document and extracts vendor, dates, amounts and lines. Rules could not handle the variety.

Rules check it. Does the total match the purchase order within tolerance? Is the vendor approved? Is it within the approval limit? These are policies and must be exact.

A model flags it if the amount is unusual for this vendor. No rule captures “unusual” well.

Rules route it. Above the threshold it goes to a director.

A person reviews and posts.

Each part uses the right tool, and the person is at the point where money moves.

The quick test

If you can write the logic in a sentence or two, use a rule.

If you would need pages of exceptions and still miss cases, use a model.

That single test settles most decisions correctly.

What people forget about rules

They rot. A reorder minimum set three years ago is still running with last year’s demand. A rule is predictable, not correct — it keeps doing what it was told even when what it was told is outdated.

Review your rules yearly. Nobody questions a rule that has been running quietly for years, which is exactly why it should be checked.

What people forget about models

They need data. Not just any data — enough of it, clean, with outcomes recorded. Most disappointments trace back to this rather than to the technology.

They cannot explain themselves in detail. Fine for an operational nudge. Not fine for anything you must defend.

They change. Retrained on new data, behaviour shifts. A rule does not drift.

Where to keep a person

Whatever the tool, three places:

Anywhere money moves. Draft and review, never automatic posting.

Anywhere a customer sees the output. Scale turns one error into a thousand.

Anywhere you must explain the outcome. If a regulator may ask, you need reasoning you can articulate.

This line should not move, however good the accuracy figures look. The review costs seconds. Removing it eventually costs a duplicate payment or a wrong price sent to a thousand people.

Deciding for a given task

Five questions.

• Can I write the logic in a sentence? → rule
• Must I explain the decision? → rule
• Is the input unstructured? → model
• Do I have hundreds of examples with recorded outcomes? If no → rule
• Does an error cost real money? → keep a person on the commit, either way

What goes wrong

Using a model where a rule would do. More expensive, less predictable, harder to explain. If your approval limit is 50,000, write a rule rather than training something to guess where the limit is.

Using rules where variety defeats them. The classic is invoice processing built as a template per supplier. It works until a supplier changes their layout, and then you are writing rules forever.

Automating a process nobody agreed on. It runs faster in the same wrong direction.

Removing the human because the demo was impressive.

The short version

Rules and models are both automation, and they suit different problems.

Rules for definite policy, explainability and expensive errors. Models for unbounded variation, patterns nobody can write down, and unstructured input.

Good systems use both — a model to read and flag, rules to check and route, a person to commit.

And review your rules yearly. Predictable is not the same as correct.