Putting AI into a process makes it easy to make mistakes when improving it.
A team can classify requests faster yet still send them to the wrong owner. It can extract information from invoices while approvals remain untouched. It can generate a better forecast without changing the decision that determines what happens next.
Technology may work. The business problem can remain.
Choosing between AI and rules-based automation should start with a clearer question: what prevents the outcome we need? Sometimes the answer is repetitive work. Sometimes it is information that needs interpretation. Sometimes nobody has agreed on the process in the first place.
Those are different problems. They shouldn’t get the same solution.
When should you use AI instead of rules-based automation?
Use rules-based automation when the required action follows explicit conditions and inputs are dependable. Consider AI when the task requires interpreting variable information, recognizing patterns, or generating a useful proposal. If ownership, policy, or the desired outcome is unclear, resolve that uncertainty before automating the decision.
AI and automation are not mutually exclusive. AI can be part of an automated process. IBM describes intelligent automation as combining AI, business process management, and robotic process automation.[3] The useful distinction is between work that follows specified rules and work that requires a model to interpret information.
My starting point is to separate the problem from the proposed tool. “We need AI” is a technology preference. “We need fewer incorrect payments without adding approval delays” is a problem we can investigate.
Diagnose the work before selecting the technology
Before considering a solution, I would trace one item through the process: where it enters, what information it carries, which decisions it encounters, and when it’s finished.
That exercise should distinguish work from waiting. A request may take little time to process but spend days between owners. Reducing processing time will not remove that delay unless the intervention also addresses the handoff.
I would look for these different sources of friction:
- Missing or inconsistent information at the point of entry.
- Repeated manual steps that produce the same result.
- Time spent interpreting documents, messages, or other variable inputs.
- Unclear ownership, conflicting rules, or decisions nobody is authorized to make.
- Exceptions that return repeatedly because of an upstream cause remain unresolved.
Several can exist in the same process. Good design addresses each at the appropriate point rather than treating the entire workflow as one AI use case.
For example, if two departments disagree about who approves an exception, a model can recommend an owner. It cannot settle the organization’s accountability merely by producing a confident answer. Someone still needs to define the responsibility.
Use rules where the business has already decided
Rules-based automation is a strong starting point when the conditions can be stated clearly and checked reliably.
Consider a defined approval threshold, a required field, a duplicate identifier, or a scheduled transfer between approved systems. If the organization has determined the correct action, implementing that logic directly can be more useful than repeatedly asking a model to infer it.
The difficult part may be maintaining the rules, not executing them. Ownership, version control, exceptions, and validation still matter. Deterministic software can consistently carry out an incorrect policy.
A few questions help establish whether a rule is ready to automate:
- Do people agree on the correct result for the same inputs?
- Are the required inputs available and sufficiently reliable?
- Can the decision be expressed without relying on unwritten context?
- Is there a defined response when the conditions are not met?
If those answers are clear, start by testing the rules. Do not add a model just because the task is part of a wider AI initiative.
Add AI where interpretation creates a real constraint
AI becomes more relevant when the information varies in ways that are difficult to handle with a manageable set of explicit rules.
A request may describe the same issue in many ways. A document may contain relevant details about changing locations. A forecast may depend on patterns across several inputs rather than a single threshold.
Those are reasonable candidates for model-assisted work. They do not prove that a particular model will perform well enough. The task needs evaluation against representative cases and an acceptable error standard.
The type of AI also matters. Extracting fields from a document, forecasting demand, and generating a response are different tasks. They do not automatically require the same model or an autonomous agent.
Anthropic’s guidance on agentic systems recommends finding the simplest sufficient solution and increasing complexity only when needed. It also notes the cost and latency trade-offs that agents can introduce.[1]
I would apply that discipline to the business case: identify the specific step that needs interpretation, test whether AI improves it, and keep the rest of the process as simple as possible.
One process can need different kinds of intervention
Consider a hypothetical invoice process. The objective is to pay valid invoices correctly and on time, with a clear explanation for anything held back.
Calling this “an AI invoice process” hides several different jobs:
The extraction model should not become the authority for supplier identity, payment eligibility, and exception policy just because it is already involved.
A layered approach can use AI for interpretation while keeping calculations, access controls, and agreed validation rules explicit. A person can handle decisions that fall outside those rules.
This is not a claim that every invoice process should be designed this way. It shows how breaking down the work produces a more precise technology decision.
The same reasoning applies to other functions. For service requests, AI might interpret the description while explicit rules enforce eligibility. In employee onboarding, better ownership and dependable handoffs may matter more than adding another conversational interface.
Measure the completed outcome, not just the automated step
A faster component does not necessarily create a better process.
If invoice extraction improves but staff spend more time correcting fields, the benefit must account for that rework. If requests reach a queue faster but remain there longer, faster classification has not delivered faster resolution.
I would define a baseline before a pilot and compare the complete outcome afterward:
Define the denominator carefully. A low cost per processed document can look attractive while excluding documents that failed, were rerouted, or needed manual repair. Cost per successfully completed item answers a more useful question, provided the organization defines success consistently.
The business case should include integration, monitoring, maintenance, and exception handling alongside model or software charges. Time saved in one task is not automatically cash saved. It may create capacity, reduce delay, or allow people to do work that was previously neglected. State which benefits you expect and how you will observe it.
Preserve ownership where the decision has consequences
Better interpretation does not remove accountability for the action that follows it.
A person responsible for a payment, access change, or consequential exception needs enough context to decide. A summary may help, but it should not replace access to the relevant evidence or hide what remains uncertain.
NIST’s AI Risk Management Framework emphasizes defining and differentiating human roles and responsibilities. It also cautions that human–AI interaction can amplify biases rather than automatically improve decisions.[2]
That makes review design part of the process, not a final checkbox. Decide which cases require review, who is qualified to decide, what they need to see, and what happens if the case cannot be resolved.
Don’t make every employee inspect every routine transaction just to say a human was involved. Do not send every difficult case to an unowned queue either. The review burden needs its own operating model.
A decision brief before the pilot
Before approving a tool or a pilot, I would want one concise brief that answers the following questions.
The brief should make it possible to reject an unnecessary AI component without rejecting the improvement effort.
If a simpler intervention solves the problem, that is a successful decision. If AI adds a measurable benefit to a specific step, the brief makes that contribution easier to explain and defend.
Common questions
Should a process be perfect before adding AI?
No. It should be understood well enough to identify the change being tested. AI may help with information that is difficult to interpret, but unclear policy and unassigned responsibility should not be disguised as model limitations.
Is rules-based automation less advanced than AI?
It is a different way to solve a problem. Explicit logic is useful where the required decision is known. A model is useful where interpretation or prediction is needed, and its performance can be evaluated. Complexity is not an outcome measure.
Can AI and rules-based automation work together?
Yes. A model can propose a classification or extract information, while explicit rules validate required conditions and control the next step. The design still needs a response for errors, uncertainty, and cases outside the agreed scope.
What should make an AI pilot stop?
Set the conditions before the pilot starts. Examples include unacceptable errors, increased unresolved exceptions, review effort that removes the expected benefit, or operating costs that exceed the business case. Investigate why, rather than extending the pilot indefinitely because the demonstration was impressive.
Make the improvement the objective
I would rather see a clear problem solved with modest intervention than a sophisticated AI system attached to a process nobody understands.
Start with the outcome. Find the constraint. Use explicit rules where the business decision is already known. Test AI where interpretation offers a useful advantage and retain accountable people for the decisions that require them.
The result should be easier to explain in operational terms: fewer incorrect outcomes, less unresolved work, more useful capacity, or better decisions. “We implemented AI” does not tell us whether any of those things happened.
For a related look at designing around dependable outcomes, see Practical Home-Lab Automation: Start Small and Build for Reliability.
Sources
[1] Anthropic — Building effective agents
[2] NIST — AI Risk Management and Human-AI Interaction
[3] IBM — What is intelligent automation?
Related reading
More articles are taking shape.