Decision guide

RPA vs AI automation: when to keep, extend or replace your bots

RPA (robotic process automation) is software that repeats a fixed sequence of steps in the applications a person already uses, usually by driving their screens, following rules written in advance. It is dependable when the inputs are structured and the screens and rules rarely change. AI automation adds a model step that can read unstructured inputs, such as emails, letters and scanned documents, and make judgement calls a rule cannot express. Its output is probabilistic, so it needs checks a bot does not. In practice you rarely choose one over the other for the whole business; you choose per process. Keep a bot where the inputs are structured and the screens are stable. Extend it with an AI step where the only thing holding it back is input a rule cannot read. Replace it with a direct integration, or redesign the process, where the bot breaks whenever a screen changes or most cases end up with a person anyway.

Intelligent automation. Automation that combines rule-following steps, such as RPA bots or API integrations, with AI model steps that read unstructured inputs and make judgement calls the rules cannot express.

Written by Tayyeb Mahmud, founder and Principal Architect. Claude Certified Architect – Professional · LinkedIn profile of Tayyeb Mahmud

Checked 29 September 2026. Vendor statements on this page were read on UiPath's, Microsoft's and Automation Anywhere's own pages, and describe what each vendor says about its own products. Naming them is not a ranking or a recommendation. This guide quotes no prices, because licence models differ between vendors and change; ask each vendor to quote against your own volumes. Features change too, so confirm them on the sources below before you buy.

RPA, AI automation and intelligent automation, in plain words

Pitches blur three kinds of automation together, and they fail in different ways, so I name them before anything gets chosen. There is a fourth option that tends to go missing from the shortlist, because it does not touch the screens at all. The numbers in brackets point to the sources at the foot of the page.

RPA (robotic process automation): Software robots that repeat a fixed sequence of steps in the applications a person already uses: reading fields, typing, clicking and moving files. UiPath describes RPA as software robots handling repetitive, rule-based tasks by mimicking human actions on screens and systems [1]. Microsoft says its Power Automate desktop flows broaden the product's RPA capabilities, for rule-based tasks in modern and legacy applications, terminal emulators included [2].
AI automation: A step where a model reads something a rule cannot, such as a free-text email, a scanned letter or an invoice in a layout nobody planned for, and proposes an answer: a category, a set of extracted fields, a draft reply or a next action. Its output is probabilistic. It can be wrong with complete confidence, which is why the step needs checks that a rule-following bot does not.
Intelligent automation: The two combined, also called intelligent process automation. Automation Anywhere describes intelligent automation as pairing RPA with AI to understand unstructured data and add decision-making, and says RPA on its own can only operate effectively with structured data [3].
Direct integration: Where a system offers an API, a supported export or database access, software can exchange data with it directly instead of going through its screens. It is neither RPA nor AI, and a redesigned screen does not break it.

What each is good at, and where each breaks

The useful comparison is what each one needs to be true about the work. A bot needs fixed screens and complete rules. An AI step needs a way to check its answer before anything relies on it.

How an RPA bot and an AI step compare on inputs, decisions, failure, upkeep and risk
Dimension	RPA bot	AI step
Inputs it handles well [3]	Structured data in known fields and formats: forms, spreadsheets, system screens	Unstructured text and documents: emails, letters, free-text notes, documents in varied layouts
Decisions	Only the rules written into it. A case the rules do not cover stops, or goes to a person	Judgement calls a rule cannot express, such as which team a free-text complaint belongs to
Same input, same result?	Yes. It is deterministic, which makes it straightforward to test	Not guaranteed. Test it on a fixed set of real cases, and again whenever the prompt or model changes
How it usually fails	Visibly: a screen element it relies on has changed, and it cannot find its target [4, 5]	Quietly: a plausible answer that is wrong, in the same confident form as a right one
What drives upkeep	Changes to the applications it drives, plus the exceptions people pick up by hand	Model and prompt changes, the review queue, and the test set that shows each change is safe
Risk it adds	The access held by the bot's own account, which can grow beyond any one person's if nobody reviews it	Instructions hidden in the documents it reads, called prompt injection, which OWASP lists as LLM01 in its 2025 Top 10 for large language model applications [8]

RPA vendors document this weak point themselves. UiPath's documentation says that if an attribute a selector relies on changes each time the application starts, the selector will not be able to identify the element [4]. Microsoft lets a desktop flow hold several selectors for one screen element and try the next when one fails [5]. Features like these cut the breakage down. They do not change the bet every bot makes, which is that the screens it drives will stay the same.

What drives the cost, before anyone quotes a price

You will not find prices here. Licence models differ between vendors and change, so ask each vendor to quote against your own volumes, then read what the quote leaves out. What I can set out is where the money goes beyond the licence, because that is what decides whether the automation pays back.

Build: Mapping the process as it really runs, including the exceptions nobody wrote down, then building and testing. Both need this. An AI step also needs a test set of real cases with the right answers recorded.
Run: For a bot: the machines and accounts it runs under, and the scheduling around them. For an AI step: the cost of each model call at your volumes, however the vendor bills it, so ask how it is charged before you design around it.
Maintenance: For a bot: every update to an application it drives can move a field or a button it depends on. For an AI step: every change of model or prompt needs the test set run again before it goes live.
Exceptions: Cases the automation cannot finish land with a person. If a large share of cases end up there, the automation is doing the easy part and your people are still doing the hard part. Count exceptions before and after any change.
Controls: Review queues, logs and access reviews take time to run. They are also what lets finance, audit and risk sign the automation off, so a business case that leaves them out will look better than the thing it describes.

Keep, extend or replace: deciding bot by bot

Decide per process, not for your whole automation estate in one go. The same organisation can sensibly keep one bot, extend a second and retire a third. The table sets out when each choice fits, what changes and the controls to add.

When to keep an RPA bot, extend it with an AI step, replace it with an integration or redesign the process
Dimension	When it fits	What changes	Controls to add
Keep the bot	Inputs are structured, the rules are complete, the screens rarely change and few cases fall out as exceptions	Nothing. Keep counting exceptions and failed runs	Review the bot account's access; alert on failed or half-finished runs
Extend it with an AI step	The bot works, but a person still reads each email, letter or document before it can start, or sorts the cases the rules cannot place	A model reads the input and proposes structured fields or a category; the bot enters the checked result as before	A fixed output format checked by code; rules checked against the system of record; failed or uncertain cases to a person with the reason attached
Replace it with an integration	The target system has an API or a supported export, and the bot breaks whenever a screen changes	Software exchanges data with the system directly, and the screens drop out of the path	A check before each write can run, a way to undo a bad run, and a log of what changed and on whose behalf
Redesign the process	Exceptions are the norm, or the process exists only to move data between systems that could share it directly	Steps are removed before anything is automated	One owner for the new process, measured against the old one

Extending a bot with an AI step, safely

If you extend a bot, the AI step proposes and ordinary code decides. That split is the pattern we call agent proposes, verifier gates. The model does the reading and the judgement, and deterministic checks, not another model, decide what goes through.

The case here is a bot that sits idle until a person has read an email or document for it. The extension puts a model step in front of the bot and a check behind the model, and leaves the bot's own work unchanged.

1. The model reads: It turns the email or document into the fields the bot needs, in a fixed format that code can check.
2. Code checks: Every field is checked against rules and the system of record: the supplier exists, the total adds up, the date falls in the period. None of those checks is a model.
3. A person decides the rest: Cases that fail a check, or that the model marks as uncertain, go to a person with the reason attached. The vendors build for this step. UiPath's Validation Station is an interface for people to validate and correct data extracted from documents [6]. Microsoft's preview action for generating text in desktop flows will not run unless the flow shows its output to a person, and Microsoft tells users to have people review AI-generated content because the model might make mistakes [7].
4. The bot enters it: Only checked data reaches the bot, which enters it through the screens as before. Its rules, schedule and logs stay as they were.

None of this depends on RPA. On a government-accredited EdTech's speaking assessment, the band rules are applied in ordinary code, and where the system is not confident it says so and routes the case to a human examiner (engagement file D-02).

When replacing the bot is the better answer

A bot is a way of using a system through its screens. If the system offers an API, a supported export or database access, use that instead. The screens drop out of the path, and the next redesign of a screen no longer breaks the run.

Our position on systems of record is plain. Scheduled exports, file drops and database-level integration are legitimate when there is no API, provided the same guarantees hold. Screen-scraping a system of record is normally where we would advise against automating at all.

The guarantees are the ones any automated write needs: a check before a change runs, a way back from a bad run, and a log of what changed, when and on whose behalf. We built an identity provisioning system for more than 1,000 users on those terms. Access is driven from the HR record, each run applies only the difference between intended and actual state, changes can be inspected before they land, and people are matched across systems by explicit rules, because a wrong match grants the wrong person access (engagement file D-04).

Replacing a bot is also the moment to ask whether the step should exist at all. If two systems could share data directly, automating the hand-off between them only preserves the hand-off.

The controls an AI step needs before it touches a live system

A bot does what it was told. An AI step does what it concludes, so its controls have to sit around it rather than inside it. Where published security guidance or UK data protection law sets a control out, I cite it.

A fixed output, checked by code: Ask the model for a fixed format and validate it with ordinary code before anything uses it. OWASP lists defining and validating output formats with deterministic code among its mitigations for prompt injection [8].
Least privilege: The step gets only the access it needs. OWASP recommends restricting a model's access to the minimum necessary [8], and the NCSC endorses the principle that when a model processes information from a party, its privileges drop to that party's [9].
Untrusted input stays untrusted: An email or document can carry text written to steer the model. The NCSC says prompt injection may never be totally mitigated in the way SQL injection can be, and recommends deterministic, non-model safeguards that constrain what the system can do [9].
Approval for high-risk actions: A named person approves anything that moves money, changes a record of consequence or affects someone's access. OWASP recommends human approval for high-risk actions [8].
Logs: Record the input, the model's output, the checks run and who approved what. The NCSC recommends logging model inputs, outputs and tool use so that misuse can be spotted [9].
Tests on every change: Keep a set of real cases, including the exceptions the bot already produced, and run it whenever the prompt, model or rules change. Our governance guide includes a sample AI policy mapped to its controls, owners and evidence.
Decisions about people: If the step makes a decision about a person based solely on automated processing, with legal or similarly significant effects, UK data protection law requires safeguards: telling people about the decision, letting them make representations and challenge it, and letting them obtain human intervention [10]. The ICO says all the data protection provisions of the Data (Use and Access) Act 2025 are now in force, and that special category data remains more protected [11]. This is a summary, not legal or tax advice: take advice on your own case.

A decision checklist for each process

Answer these for one process at a time, with the person who runs that process in the room, not only the person who bought the bot. Together the answers point to keep, extend, replace or redesign.

Seven questions to ask of each process before choosing an RPA bot, an AI step, an integration or a redesign
Dimension	If yes	If no
1. Does the system offer an API, a supported export or database access?	Integrate through it. A bot is not needed for this step	A bot on the screens may be the only route. Keep it narrow and watch for screen changes
2. Are the inputs structured, in known fields and formats?	Rules can handle them. No model is needed	An AI step can read them, with the controls set out above
3. Can every decision in the process be written as a rule?	Keep the decisions in code or in the bot	Let a model propose, and let rules or a person decide
4. Have the screens the bot uses stayed the same since it was built?	Keep the bot	Count the fixes. Frequent breakage is the case for an integration
5. Is a silent error cheap to find and put right later?	Lighter review is proportionate	Put deterministic checks and a named approver before anything is written
6. Does a step decide something about a person, based solely on automated processing, with legal or similarly significant effects?	UK data protection safeguards apply. Take advice before automating it	The controls above are enough to start
7. Do you know today's volumes, exception rate and handling time?	Measure the same things after the change and compare	Measure first. Without a baseline, nobody can say whether the change paid back

Where 1AYM fits

1AYM has built RPA bots for clients, run them and replaced them, so we have been on both sides of the keep-or-replace decision. For a single process, we scope the change as a fixed statement of work: an AI step with checks in front of the bot, or an integration into the systems you already run, such as NetSuite, Xero, Slack and Notion, which is our AI integration and automation services work: every write can be checked before it runs, undone if it goes wrong and traced afterwards. Once the scope is signed, the build can start within a day.

If you have a whole estate of bots to sort, the AI Opportunity & Feasibility Sprint, part of our AI strategy work, runs the checklist above across every process and scores each candidate on value, feasibility and risk. Either way, the first step is a 30-minute call.

For engineers: architecture, controls and evidence

The hybrid pattern in engineering terms. Each item is something a reviewer can check in configuration, code or logs, and each one answers a failure mode described above.

Selector resilience: Target attributes whose values stay constant between sessions [4], and use the platform's fallback or text-based selectors where it offers them. Treat every release of a driven application as a regression run for the bots that drive it.
Structured extraction: The model returns JSON against a schema. A validator rejects anything that fails to parse or fails type, range or reference checks, and the case goes to review instead of a silent retry. Retrying until the output parses hides the cases you most need to see.
Confidence routing: Route on explicit signals: a failed check, low extraction confidence where the tool reports it, or disagreement between repeated runs. Set thresholds from the labelled test set rather than by feel.
Idempotent hand-off: The bot or integration writes idempotently, keyed on a business identifier, so a retry after a partial run cannot post twice. A dry-run mode shows the diff before any write.
Privilege separation: The model holds no credentials for the target system. It emits proposals; a separate component with scoped credentials executes only the ones that passed validation.
Evaluation in CI: A labelled set built from the bot's exception history runs on every change to prompt, model version or rules. A score below the agreed threshold blocks the release.
Audit record: One structured record per case: input reference, model and prompt version, output, checks run, reviewer, action taken and timestamp. Stored append-only, with a stated retention period.

Sources

Frequently asked questions

Is RPA being replaced by AI agents?

Not for work with structured inputs, complete rules and stable screens, where a bot is predictable and straightforward to test. The RPA vendors themselves position the two together: UiPath describes its robots working alongside AI agents in a complementary role [1], and Automation Anywhere describes AI stepping in to process documents and interpret natural language where RPA flags an exception or is blocked [3]. What usually changes first is the step in front of the bot, where a person reads the input.

What is the difference between RPA and intelligent automation?

RPA follows fixed rules, usually through an application's screens. Intelligent automation, also called intelligent process automation, combines RPA or direct integrations with AI steps that read unstructured data and make judgement calls [3]. It describes a design rather than a product, and it can be built on one vendor's platform or across several.

Can we add an AI step to the RPA platform we already run?

Check that before anything else, because it keeps the bots, logs and access model you already have. UiPath, Microsoft and Automation Anywhere each document AI features alongside their RPA tools [3, 6, 7]. Judge those features on whether they let you enforce the controls on this page. That means a fixed output format, checks before anything is written, a review queue and a log.

What should we ask an RPA consultant or automation partner?

Ask which of your processes they would not automate, and why. Someone who would automate every one of them has picked the tool before looking at the work. Then ask whether they would reach each system through an API or an export before its screens, what happens to a case the automation cannot finish, how a bad run is undone, and how an AI step is retested when its model changes. The answers show whether they are choosing per process or applying one tool to everything.

Further

AI integration and automation services · AI and automation built into the systems you already run, with dry runs, rollback and audit logs.
Agentic workflow design · Where the gates sit when an AI step writes to finance or compliance systems.
Engagement file D-02 · Band rules in ordinary code, with uncertain cases routed to a human examiner.
AI governance framework · A sample AI policy mapped to its controls, owners and evidence, and the gates that enforce it.
AI readiness assessment · Thirteen questions, scored on the page, on whether your organisation is ready to build with AI.

We build these systems for a living. See the engagement files for what that looks like in practice, or write to us if yours is the next one.

Book a 30-minute call tayyeb@1aym.com See the engagement files

Last reviewed 29 September 2026 · 1AYM