Where it belongs in your automation, and where a rule is still the better tool.<\/p>\n
Businesses have been automating for decades. Approval thresholds. Recurring invoices. Reordering rules. Scheduled reports. Follow-up sequences.<\/p>\n
All of that is automation, and none of it is AI.<\/strong> It is rules \u2014 written by a person, doing exactly what they were told.<\/p>\n 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?<\/strong><\/p>\n Getting that wrong in either direction is expensive.<\/p>\n A rule does what you told it. A model does what usually works.<\/strong><\/p>\n Everything else follows.<\/p>\n A rule is explicit, predictable and auditable. It handles exactly the cases it was written for and fails on everything else.<\/p>\n A model handles cases nobody anticipated, and it is right most of the time rather than always.<\/p>\n FIGURE 1: TWO KINDS OF AUTOMATION<\/p>\n Rules<\/p>\n Models<\/p>\n Five situations. Notice how many ordinary business tasks fall here.<\/p>\n The logic is a definite policy.<\/strong> “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.<\/p>\n You must explain the decision.<\/strong> Anything an auditor, regulator or customer may question. “Because the rule says so” is an answer. “The model determined it” is not.<\/p>\n An error is expensive.<\/strong> Payment thresholds, credit limits, tax treatment. You want predictable, not usually-right.<\/p>\n You have little data.<\/strong> A model needs examples. A rule needs one person who knows the policy.<\/p>\n The rule changes by decision.<\/strong> Your approval limit changes because management decided. A model learning from history would still apply the old one.<\/p>\n Four situations.<\/p>\n The variation is unbounded.<\/strong> Supplier invoices arrive in thousands of layouts. Writing a rule per layout is impossible.<\/p>\n A pattern exists that nobody can articulate.<\/strong> Which invoices get paid late. Which leads convert. There is a pattern; nobody can write it down.<\/p>\n Conditions shift over time.<\/strong> Demand moves. A fixed reorder minimum does not. A forecast does.<\/p>\n The input is unstructured.<\/strong> Documents, free text, images. Rules need structure.<\/p>\n FIGURE 2: WHICH TOOL FOR WHICH JOB<\/p>\n Use a rule when<\/p>\n Use a model when<\/p>\n The practical answer is rarely one or the other. It is a chain.<\/p>\n Processing a supplier bill:<\/strong><\/p>\n A model<\/strong> reads the scanned document and extracts vendor, dates, amounts and lines. Rules could not handle the variety.<\/p>\n Rules<\/strong> 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.<\/p>\n A model<\/strong> flags it if the amount is unusual for this vendor. No rule captures “unusual” well.<\/p>\n Rules<\/strong> route it. Above the threshold it goes to a director.<\/p>\n A person<\/strong> reviews and posts.<\/p>\n Each part uses the right tool<\/strong>, and the person is at the point where money moves.<\/p>\n FIGURE 3: THE TWO WORKING TOGETHER<\/p>\n Model reads<\/p>\n Rules check<\/p>\n Model flags<\/p>\n Person posts<\/p>\n If you can write the logic in a sentence or two, use a rule<\/strong>.<\/p>\n If you would need pages of exceptions and still miss cases, use a model<\/strong>.<\/p>\n That single test settles most decisions correctly.<\/p>\n They rot.<\/strong> A reorder minimum set three years ago is still running with last year’s demand. A rule is predictable, not correct \u2014 it keeps doing what it was told even when what it was told is outdated.<\/p>\n Review your rules yearly.<\/strong> Nobody questions a rule that has been running quietly for years, which is exactly why it should be checked.<\/p>\n They need data.<\/strong> Not just any data \u2014 enough of it, clean, with outcomes recorded. Most disappointments trace back to this rather than to the technology.<\/p>\n They cannot explain themselves in detail.<\/strong> Fine for an operational nudge. Not fine for anything you must defend.<\/p>\n They change.<\/strong> Retrained on new data, behaviour shifts. A rule does not drift.<\/p>\n Whatever the tool, three places:<\/p>\n Anywhere money moves.<\/strong> Draft and review, never automatic posting.<\/p>\n Anywhere a customer sees the output.<\/strong> Scale turns one error into a thousand.<\/p>\n Anywhere you must explain the outcome.<\/strong> If a regulator may ask, you need reasoning you can articulate.<\/p>\n This line should not move<\/strong>, 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.<\/p>\n Five questions.<\/p>\n Using a model where a rule would do.<\/strong> 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.<\/p>\n Using rules where variety defeats them.<\/strong> 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.<\/p>\n Automating a process nobody agreed on.<\/strong> It runs faster in the same wrong direction.<\/p>\n Removing the human because the demo was impressive.<\/strong><\/p>\n Rules and models are both automation, and they suit different problems.<\/p>\n Rules for definite policy, explainability and expensive errors. Models for unbounded variation, patterns nobody can write down, and unstructured input.<\/strong><\/p>\n Good systems use both \u2014 a model to read and flag, rules to check and route, a person to commit.<\/p>\n And review your rules yearly. Predictable is not the same as correct.<\/p>\n Not sure whether your automation problem needs a rule or a model?<\/p>\n Get in touch. We will look at the specific task \u2014 and quite often the answer is a rule you can configure this afternoon.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 \u2014 written by a person, doing […]<\/p>\n","protected":false},"author":3,"featured_media":9151,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-9150","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-ai"],"yoast_head":"\nThe difference in one line<\/h2>\n
\n
\n
Where rules are the right answer<\/h2>\n
Where a model is the right answer<\/h2>\n
\n
\n
Most systems need both<\/h2>\n
\n
\n
\n
\n
The quick test<\/h2>\n
What people forget about rules<\/h2>\n
What people forget about models<\/h2>\n
Where to keep a person<\/h2>\n
Deciding for a given task<\/h2>\n
\n
What goes wrong<\/h2>\n
The short version<\/h2>\n