Intelligent process automation: when you need AI and when RPA is enough

Intelligent process automation is often sold as the next generation of classic process automation: the same thing, only better. That is misleading, and it regularly produces expensive projects in which a language model handles a task that twenty lines of rule-based code would have covered.

AI is not a better version of RPA. It is the tool for a different part of the same process. Knowing where the boundary runs means buying less and getting a more stable system.

What RPA actually does

Robotic process automation is, at its core, a very reliable clicking and copying robot. You describe a sequence step by step and the software executes it: open file, read field, enter it into another system, wait for confirmation, continue.

The properties that follow from this are often underrated:

• It is predictable. The same input produces the same output today and in two years. For accounting, regulatory reporting, and anything audit-relevant, that is not a detail but the main point.
• It is traceable. When something goes wrong, the cause sits in a rule a human can read.
• It is cheap to operate. No model costs, no quality drift, no exposure to a vendor changing prices.

The weakness is equally clear: RPA breaks as soon as the input deviates from the expected shape. A shifted field, a new invoice layout, an extra column, and the sequence stops.

What AI adds

AI solves exactly that one weakness. A language model or a document model does not need a fixed position where a value sits. It recognizes that a number next to the words invoice total is an invoice total, regardless of where on the page it appears or how the supplier laid out their template.

That opens up processes RPA could never reach: anything arriving in unstructured form. Free text, changing layouts, emails, scanned documents, speech.

The price is the inversion of all three RPA properties. AI is not exactly predictable, it is harder to trace, and it costs money continuously in operation. None of that argues against using it. It argues against using it where rules would do.

The decision boundary

There is a single question that carries most of the decision:

Is the input structured or not?

Does the value always sit in the same place, in a named field, in a database, in a CSV file? Then it is a rules problem. Use RPA or an interface. AI would be slower, more expensive, and less reliable here.

Does the value arrive in free text, in changing layouts, or in speech? Then it is an AI problem, and no amount of rules will solve it permanently.

Two follow-up questions sharpen the picture. How often does the shape of the input change? With a single stable supplier format, a rule is often cheaper even for unstructured material. And how high are the error costs? The more expensive a mistake, the more a review step belongs in the middle, regardless of method.

The normal case is a combination

In practice a real process almost never consists of only one of the two types. That split is exactly what intelligent process automation means: AI for the unstructured beginning, rules for the structured remainder.

An example that looks like this in almost any mid-sized company. Incoming invoices from 200 suppliers, some PDF, some paper, in dozens of layouts.

Step	Method	Why
Fetch invoice from mailbox	Rule	fixed structure, no judgement
Extract totals, numbers, line items	AI	layouts vary, unstructured
Match to supplier	Rule	lookup against master data
Check invoice against purchase order	Rule	pure arithmetic
Explain discrepancies	AI	free text, judgement
Obtain approval	Rule	threshold, clear ownership
Post to ERP	Rule	fixed interface

The AI portion is two of seven steps. That is the usual proportion, and that is what pays off. A project that tries to hand all seven steps to a language model will be more expensive to run, slower, and less reliable on the rule-based steps than the simple version.

So the question in vendor selection is not whether somebody can do AI. It is whether they are willing to build five of seven steps without it.

What the AI portion adds in operations

Wherever AI sits in the sequence, three operational duties appear that pure rule-based automation does not have.

Quality has to be measured continuously. A rule-based sequence either works or fails visibly. A model can quietly get worse, for instance because the provider shipped a new version. Without an ongoing sample check you notice only when a customer complains.

A fallback path has to exist. If the model provider's interface goes down, the process needs to switch to a manual mode rather than stop. For incoming invoices that is an inconvenience. For customer communication it is a problem.

Costs are variable. Model usage is billed by volume. A process that carries itself at today's volume can look different at three times the volume. Whoever runs the numbers should run them for the expected volume in two years, not today's. We worked through that full calculation in a separate piece on automating business processes.

These three points are precisely why we operate the systems we build. With pure rule-based automation, a handover is debatable. With AI in the loop, handover without continuous quality measurement means nobody notices when the system starts slipping.

How to recognize a good offer

A solid offer for intelligent process automation contains three things that weak offers lack.

First, a breakdown of the process into steps stating which step uses which method. If it says AI everywhere, nobody has looked at the process.

Second, a statement of the expected hit rate for the AI steps and what happens to the remaining cases. One hundred percent is not a serious figure.

Third, an operating cost line that shows model costs separately and is calculated for a realistic volume.

If one of the three is missing, the offer has not been thought through. What else to watch for in vendor selection is covered in our piece on choosing an AI agency.

If you have a process in front of you and want to know which steps actually need AI: thirty minutes with an engineer is enough to draw the split. How we build and operate such systems is on the AI automation page.