RPA vs AI: not the same thing, and confusing them is expensive

When someone on a management committee asks what RPA is and whether it isn't the same as AI, they are usually asking something else: they want to know why they have two different quotes for what looks, from the outside, like the same problem. The short answer is that RPA and AI solve different things. RPA executes steps you already know how to describe; AI handles decisions you cannot write down as rules. Blurring those two definitions is where most abandoned automation projects begin.

This article separates them with concrete examples, explains when each one fits, why so many RPA robots break, and how they combine well when the process calls for it. No extra acronyms, and no promise that software removes anyone's work on its own.

What is RPA and what does it actually do?

RPA stands for Robotic Process Automation. The word "robotic" is misleading: there is no mechanical arm involved. An RPA robot is a program that mimics what a person does with a mouse and keyboard on the applications you already have: it opens the email, downloads the attachment, logs into the ERP, copies twelve fields, clicks save, writes a line in a spreadsheet and sends a notification.

Three traits define it:

• It works on the interface, not the database. That is why it can automate legacy systems with no API. It is its greatest strength and its greatest fragility at once.
• It follows deterministic rules. If field A says "urgent", it goes to queue B. Zero interpretation, zero ambiguity. If something unforeseen happens, it stops.
• It does not learn. An RPA robot will do exactly the same thing two years from now, no better and no worse, unless someone modifies it.

Real examples of what RPA does well: reconciling bank statements against ledger entries when the matching criteria are exact, creating orders that always arrive in the same format, pulling a report from the ERP every Monday at 7:00 and dropping it in a folder, or replicating a new customer record across three systems that do not talk to each other.

How is RPA different from AI?

The practical difference is not about technology, it is about the type of problem. RPA automates tasks you can write into a procedure; AI tackles tasks where the judgement exists but nobody has managed to put it in writing without leaving out fifty exceptions.

One example makes it obvious: "when an invoice arrives from this supplier, in this format, take the amount from the bottom right box" is RPA. "When an invoice arrives from any supplier, in whatever format, find the total" is AI. The first statement is a rule. The second is a judgement call.

| | RPA | AI | |---|---|---| | What it solves | Repetitive, fully described steps | Decisions, classification, interpretation | | Typical input | Structured, stable data | Free text, images, variable formats | | Behaviour | Deterministic: same input, same output | Probabilistic: right a percentage of the time | | Faced with the unexpected | It stops or fails | It answers, sometimes wrongly | | How you fix it | By editing the flow by hand | With more data, tuning or human review | | What it needs to start | The documented process | Historical data or labelled examples | | Maintenance cost | High if the systems change | High if the business or the data change | | Traceability | Total: every step is explicit | Partial: it has to be designed in |

There is a governance consequence many companies discover late. RPA is auditable line by line: if it did something wrong, you know exactly why. AI gives answers with a known error margin, and that margin has to be decided up front, not discovered in production. In processes with legal or accounting implications, that difference matters more than any price comparison.

If you can write the full procedure on one page without using the word "depends", your problem is an RPA problem. If you need the word "depends", it is an AI problem.

When does RPA fit and when does AI fit?

You make the call by looking at the process, not at the vendor's catalogue. These signals work well in practice:

Choose RPA when:

• The process is documented and exceptions account for less than 10-15 % of cases.
• Input data always arrives in the same structure: a CSV, a form, an ERP screen.
• The systems involved have no API and will not have one any time soon.
• You need full traceability for audit or compliance.
• Volume is high and steady: hundreds or thousands of identical repetitions a month.

Choose AI when:

• The input is free text, emails, scanned documents or formats that change depending on who sends them.
• The task involves classifying, summarising, prioritising or predicting, not just moving data.
• Exceptions are the norm and maintaining the rule tree has become unworkable.
• There is enough history to learn from, or an expert willing to validate examples early on.

Choose neither when the process is broken at its root. Automating an approval chain nobody respects only means it gets bypassed faster. And if the process runs four times a month, the return rarely pays for the maintenance: it is cheaper to leave it alone and spend the effort elsewhere. We develop that prioritisation criterion further in AI process automation.

Why do so many RPA projects break?

It is the uncomfortable question in this space, and the answer is not that the technology is bad. RPA robots break for very specific, mostly predictable reasons:

They depend on the screen. If the robot looks for a "Save" button in a particular position and the ERP vendor ships an update that moves it, the robot stops working that same morning. Multiply that risk by every application the flow touches.

Nobody maintains what nobody sees. A working robot is invisible. When it fails at three in the morning during month-end close, the question of who maintains it appears, and often the person who built it has left, or worked for a consultancy that closed the project two years ago.

The wrong process was automated. The classic case: automating the most visible step instead of the most expensive one, or automating a process that was going to disappear with the ERP migration planned for the following year.

Exceptions grow. You start with 5 % of cases the robot routes to a person. Two years later it is 30 %, because the business added variants that were never built into the flow. At some point the person reviews almost everything and the robot has only added a layer of complexity.

There is no measurement. Without a figure for how many cases it processes, how many it routes out and how much time it saves, defending the maintenance line in a budget is impossible. Robots without metrics are the first to lose funding.

The lesson is not to avoid RPA: it is to treat it as production software. It needs an owner, monitoring, alerts when it fails and a review at least every six months. If your vendor does not include that in the offer, the project has an expiry date even if the launch goes perfectly.

How do RPA and AI combine in a real process?

In practice, complete processes are rarely pure. The combination that works best puts each technology where it is strong: AI at the intake, where there is ambiguity; RPA in execution, where the steps are fixed.

A supplier invoice flow, step by step:

1. Intake (AI). A PDF arrives by email, from any supplier, in a format you do not control. An extraction model identifies supplier, number, date, net amount, VAT and total. 2. Validation (rules + human). It is checked against the purchase order and the delivery note. If the model returns high confidence and the amounts match, it moves on. If not, it goes to a tray where a person confirms in ten seconds. 3. Execution (RPA). The robot logs into the ERP, creates the entry, attaches the document and updates the status. Fixed steps, zero interpretation. 4. Close (measurement). You record how many invoices went through untouched, how many needed review and which suppliers concentrate the failures.

That fourth point is what turns the project into something that improves rather than decays. Without it you do not know whether the model is getting worse, nor which exception is worth covering with a new rule.

One important nuance about AI agents, which is the evolution being sold hardest right now. An agent can chain steps and decide the next one by itself, which seems to make RPA unnecessary. In processes with accounting or contractual consequences, though, it is still better for the execution layer to be deterministic and auditable. The agent deciding what to do does not mean it should be the one pressing the button. We cover that in AI agents for business.

Where do you start without picking the wrong tool?

An order that works, and that requires buying nothing in the first two steps:

1. Measure the process before automating it. How many cases a month, how long per case, who does it, what percentage are exceptions. If you cannot answer, you are not ready to request quotes. 2. Classify each step. Walk the flow and mark every step as "rule" or "judgement". That gives you the split between RPA and AI, and you usually discover most of the time goes into two or three specific steps. 3. Check for an API before going through the screen. If the system offers a real integration, use it: it is more stable and cheaper to maintain than a robot clicking buttons. We return to this in integrating AI into your tools. 4. Start with one case that has volume and pain. Just one, measured over 90 days, with a threshold agreed before you start. 5. Name the maintainer on day one. A person, an annual budget, and what happens when the ERP changes. If that question has no answer, do not start.

A final warning on cost: RPA platform licences are usually billed per unattended robot per year, and that recurring figure can exceed the initial development. Always ask for the three-year cost, not the implementation cost. The ranges and the line items everyone forgets are in what an AI project really costs.

Frequently asked questions

What is RPA in plain words?

It is a program that does with the mouse and keyboard what a person would do on the applications you already use: copying data between systems, filling in forms, downloading reports. It follows fixed rules and interprets nothing, so it suits repetitive, well-described tasks.

Does AI replace RPA?

It does not replace it, it covers a different part of the problem. AI handles ambiguous input — documents, emails, variable formats — and RPA executes the fixed steps with full traceability. In processes with accounting or legal implications, that deterministic execution is still an advantage.

How long does an RPA project take to pay for itself?

It depends on volume and licence cost, but a case with hundreds of monthly repetitions typically pays back in six to eighteen months. The key is not the initial saving but the maintenance: a robot that breaks every quarter can consume the whole return in support hours.

Do I need RPA if my systems have APIs?

Usually not. If there is an integration supported by the vendor, it is more stable, faster and cheaper to maintain than a robot that depends on the interface. RPA earns its place precisely when that route does not exist and is not going to.

If you are at the point of choosing between the two — or you suspect you were sold one when you needed the other — the fast route is to look at the process with data in front of you. In the audit we review your flows and tell you which step is a rule, which is a judgement call and which is not worth automating yet. And if you would rather sanity-check it in half an hour before moving anything, let's talk.