RPA — robotic process automation — is software that operates other software through its interface. It opens the portal, logs in, finds the field, types the value, clicks save. It is fast, it never gets bored, and it can work with a system that has no API and no export at all. That last part is the whole reason it exists.
A language model does something unrelated: it turns unstructured input into structure. Given an email, a scanned delivery note or a call transcript, it produces fields you can act on. It does not click anything and it does not move data between systems. Those two capabilities are complements, not alternatives — which is why the question as usually asked has no answer.
Almost every process we are asked to automate comes with an assumption already attached: someone has decided it is an RPA job, or an AI job, before anyone looked at what the systems can do. The cheaper habit is to work through three options in order.
An API or a database. If both systems expose one, this is the answer. It is faster, cheaper to run, survives interface redesigns and fails loudly when it fails. Check for it before anything else, including with vendors who did not advertise it.
A file the system already produces. A nightly export, a report, a CSV somebody downloads manually. Unglamorous and completely reliable, and it removes most of the reason to drive a screen.
Then the robot. Screen-level automation is what remains when a system genuinely cannot be reached any other way. It is legitimate — it is just the third choice, not the first.
A model can sit inside any of these three, and usually does: reading whatever arrives as language and handing structured fields to the step that moves the data.
There is real work that nothing else can do. Legacy systems with a terminal interface and no vendor left to ask. Government and banking portals that publish no API and never will. Desktop applications with a licence that forbids direct database access. In those cases a robot on the screen is not a compromise, it is the only path, and it can be a very good one.
Where it goes wrong is scope. A bot that logs into one portal, downloads a statement and drops it in a folder will run for years. A bot that clicks through fourteen screens across four systems, each maintained by someone who redesigns without warning, becomes a maintenance job that quietly costs more than the work it replaced.
RPA breaks on layout. A moved button, a new consent dialog, a slow-loading page, an extra confirmation step — the robot does not understand the screen, it follows coordinates and selectors. Vendor updates are its natural enemy.
A model breaks on confidence. It does not stop when it is unsure; it produces a fluent, plausible, wrong answer. That is handled with thresholds, source references and a route to a human, not with hope.
RPA fails visibly, a model fails quietly. A stopped bot is an alert. A misread field enters your accounts and is found at the month end. The second failure mode needs the more careful design.
Both fail on undecided policy. If nobody has written down what happens to an exception, neither technology will invent an answer. That is a management decision wearing a technical costume.
Write down the steps of one process and mark each with what it needs: move data, or interpret something. Then ask, for every move-data step, whether an API or an export already exists — ask the vendor directly, because this information is often not in the documentation. What is left after those questions is the honest RPA surface, and it is normally much smaller than it looked.
In our experience the answer is a small integration plus a model on the one or two steps that read language, with no robot at all. When a robot is genuinely needed, we keep it to the narrowest possible span — one system, one screen path — so a redesign costs an afternoon rather than a rebuild.
We map this for free in a mini audit: the steps, what each one needs, which systems have an API you did not know about, and what it would take to run without a screen robot.
We use cookies for analytics — to see which pages bring enquiries. Nothing else, and nothing before you agree. Cookie Policy