What RPA is: a complete guide to where it divides from document AI

RPA (Robotic Process Automation) has software reproduce the screen operations and input procedures a person used to repeat, carrying them out according to defined rules.

Strong only where the rules are fixed

RPA is strong only where the rules are fixed.

It runs reliably when which position on a screen to click and what goes in which field are settled. On procedures fixed by design — moving data between systems, producing a routine report — it is highly efficient.

The difficulty is what comes before that. Which form an arriving document is, and where the needed values sit, are not fixed by rule. The same application is laid out differently by branch and by year, and fax intake arrives skewed. Handling that segment with RPA means writing rules per form and revising them each time a form changes. In practice, therefore, the front where documents are read and the back where values are entered are placed separately.

What RPA actually is: how it differs from document AI

Document AI and RPA across three axes

First, the target differs. Document AI works on the content of a document. RPA works on operating screens and systems. One handles what is written; the other handles where to click.

Second, the response to change differs. Document AI locates values by field label and context even when the layout moves. RPA needs its rules revised when the screen structure changes. In exchange, RPA is faster and more predictable where the rules are fixed.

Third, the metrics differ. Document AI is judged on recognition accuracy and field extraction accuracy. RPA is judged on case volume, failure rate, and the cost of maintaining rules.

The two are not alternatives. Document AI pulling values out of documents and RPA entering those values into fixed screens is the most common arrangement in practice.

Four criteria for deciding placement

Four criteria for the split

First, look at the input. If the input is a file or image, it belongs to document AI. If the input is already structured data, it belongs to RPA.

Second, look at volatility. Count how many times the forms or screens changed over the past year. Placing a rule-based tool on a volatile segment means maintenance cost that keeps rising.

Third, look at whether judgment is required. Where different handling depends on conditions, check whether the basis for that judgment sits inside the document or inside the system.

Fourth, look at failure behaviour. RPA stops when it meets an unexpected screen. Document AI separates low-confidence cases as exceptions. Decide which suits the work.

How to combine RPA with document AI

Define what passes at the boundary

Settle in advance what crosses the point where the two tools connect. Passing only field and value pairs, or passing source position and confidence alongside, changes what the downstream side can do.

Passing confidence lets RPA route low-confidence cases to review rather than entering them. Passing position information lets an operator open the exact part of the source when confirming.

Align the failure paths on both sides

A case document AI separated as an exception and a case where RPA stopped on a changed screen have different causes. Piling both into one queue makes the operator judge which is which every time.

Display exceptions and faults separately and decide who handles each. Business staff handling exceptions and operations staff handling faults is the usual arrangement.

Combining them in the Korean environment

Core system screens in Korean finance and the public sector are frequently custom-built, sometimes with no integration interface available. In that case, RPA operating the screen is the only route.

On top of this, network separation requires both document AI and RPA to run inside the internal network. The path over which the two tools exchange data has to stay inside that network as well, so confirm it when designing the configuration.

Frequently asked questions