RPA

An RPA bot is a program that operates other programs. It opens screens, reads fields, copies values, clicks buttons and enters data. The typical job is moving data between systems: the bot takes input, for example from a reviewed form, a spreadsheet or an inbox, and transfers it into an existing application according to fixed rules. The applications themselves stay as they are.

RPA makes no decisions of its own. People define every step and every rule in advance, and the bot carries them out the same way on every run. That is what separates it from AI. Recital 12 of the EU AI Act explicitly excludes systems that are based on rules defined solely by people to execute operations automatically from its definition of an AI system. AI can help prepare unstructured information, such as splitting a free-form email into fields, before a bot processes them.

For executives, RPA is a trade-off. A bot is often quick to build because it needs no API. In exchange, it depends on interfaces that change and on rules that don't cover special cases. Introducing RPA means committing to ongoing operations with maintenance, access management and clear ownership.

How an RPA bot works.

An RPA process runs in a loop. It starts with input, such as a reviewed form, a row in a spreadsheet or a file in a folder. If the input is unstructured, like a free-form email or a scanned letter, AI can help prepare the information first. The bot then transfers the data into an existing application according to fixed rules. If the interface has changed or a special case comes up that the rules don't cover, the process can break. Otherwise the next run follows, repetitive and rule-based.

Bots are built in RPA tools, usually with a visual editor; some tools record what a person does on screen and turn it into a starting point.

A separate orchestration layer starts bots, assigns work and logs every run. There are two modes. Attended bots run on an employee's workstation and are triggered by that person for one step of a task. Unattended bots run in the background on a schedule or in response to an event, often on dedicated virtual machines.

When RPA fits and when it doesn't.

RPA fits processes that happen often, look the same every time and are decided by clear rules. The input is digital and follows a fixed format. The applications involved rarely change. And no API connects the systems, or building one would cost too much. Typical cases are transfers between legacy systems, reconciling two lists, or creating master data records from a fixed template.

RPA is a poor fit for processes with many exceptions, with judgment calls, or with input that looks different every time. Every exception needs its own rule or a person, and maintenance grows with the number of rules.

A common mistake is automating a clumsy process exactly as it is. The bot then performs the same unnecessary steps, just faster, and keeps a bad process alive. Before anyone builds a bot, the process belongs on the table: which steps are actually needed, which exceptions really occur, and who handles them?

RPA, APIs and AI are different tools.

An API connects two systems directly. It is sturdier than a bot because it doesn't depend on screen layouts. Where a usable API exists, it is usually the better choice. RPA is the bridge for applications without one.

AI solves a different problem. It reads, classifies and writes, even when the input has no fixed format. A large language model (LLM) works with probabilities and can be wrong, which is why AI automation needs checkpoints where a person or a rule reviews the result. When AI and RPA are combined, vendors call it intelligent process automation. The IEEE set out terminology for this field in its 2017 guide IEEE 2755.

Newer still are AI models that operate screen interfaces themselves; Anthropic released one such capability, computer use, as a public beta in October 2024. It resembles RPA only on the surface. A bot follows a fixed path; the model chooses its own. Anthropic draws the same line between workflows, where the process sets the steps, and agents, which pick their own path. The more freedom a system has, the higher the bar for permissions, monitoring and stop conditions.

What matters in day-to-day operations.

A bot depends on things it doesn't control. An update to the target application moves a field, a new required entry appears, a login screen suddenly looks different. The bot can't find what it expects, and the process stops or, worse, keeps running with the wrong values. Rule-based automation also needs ongoing support.

Good implementations plan for that support from day one. The bot checks after each step whether the result makes sense and stops rather than guessing. Cases the rules don't cover go to a queue that a person works through. Monitoring reports failures right away. And before every update to the applications involved, the bot is tested again in a test environment.

Ownership is part of this: the business side owns whether the rules are still right, the technical side whether the bot still runs. If you hire a vendor, ask how failures are reported, where exceptions end up, how the bot is documented and who adjusts it after an update to the target application.

Access, permissions and traceability.

A bot logs in to applications like a person and needs credentials, a common weak spot. If a bot runs under an employee's personal account, the logs no longer show what the person did and what the bot did.

So bots get their own accounts with exactly the permissions their task requires and nothing more. Credentials sit in a secure vault, not inside the process itself. Every run is logged: what the bot read, changed and transferred. For sensitive actions, such as payments or changes to bank details, a person still gives the final approval.

If a bot processes personal data, the GDPR applies as it does to any other processing. The process belongs in the record of processing activities, and retention periods must also cover the bot's temporary files and logs.

A separate risk arises when business units build bots without IT knowing. They run with unclear access and no monitoring, much like shadow AI. A register of all bots with their purpose, account and owner prevents that.

What RPA costs and what drives it.

The cost of RPA falls into several buckets. The most visible is licensing for the RPA tool. Vendors price it differently, for example per bot, per execution or per developer seat. Target applications may need licenses too, since a bot's account counts as a user.

The second bucket is the build: documenting and simplifying the process, defining rules, building and testing the bot. The third is infrastructure, such as virtual machines for unattended bots.

The fourth and most often underestimated bucket is operations. Every update to a target application can require changes, people handle the exceptions, and someone has to respond to alerts.

Which bucket dominates depends on how stable the applications are, how many exceptions the process has and how often it runs. An honest calculation weighs the working time saved against the total effort, including maintenance and exception handling, and gets redone after a few months with real numbers.

Where the term stops working

RPA only does what was defined in advance; changes to user interfaces and special cases can break a process, and rule-based automation also needs ongoing support. RPA is distinct from API integration, which connects systems directly, from AI automation, where a model judges and writes and therefore needs checkpoints, and from AI agents, which choose their own path. If an RPA process includes an AI step, that step is held to the standard for AI output.