RPA and Generative AI Integration 2026 — Automation Stalls Where Judgment Is Mixed In

You deployed RPA, and then the hours saved stopped growing. The cause is rarely the number of exceptions. It is that judgment sits inside the workflow. This article treats the integration of RPA and generative AI not as a replacement but as a connection to the judgment node. We split the process into five nodes and model the payback of three cases for a Japanese-owned manufacturer operating in Thailand.

Before designing RPA and generative AI integration, find where automation actually stalls

There is a pattern you see repeatedly at Japanese-owned plants in Thailand. RPA went in a few years ago, several scenarios are running, overtime dropped in the first year, and the results made it into a management report. From the second year onward, the curve flattens. Every attempt to add a scenario ends with the same verdict, that this process has too many exceptions to automate, and the target list stops there.

The diagnosis offered at that point is usually one of three. Too many exceptions, no cooperation from the floor, outdated tooling. Each is partly true and none of them explains the ceiling. If those three were the whole story, then eliminating exceptions, involving the floor and switching tools would raise the automation rate. In practice, doing all three barely moves the ceiling.

The places where automation stops share one property. Judgment is embedded there. The unit price on the order acknowledgement is 3 THB off from the price on the purchase order. The quantity is one unit short, but a split-delivery notice may have arrived. The item is written as Stainless plate t1.0 on one document and SUS plate 1.0t on the other. What a person does in those moments is not apply a rule. It is read the situation and decide whether to let it pass or stop it. RPA can execute a conditional branch, but it cannot author the condition. Against work whose criteria have never been written down, RPA is structurally powerless.

There is survey evidence behind this reading. Hitachi Solutions ran a study on replacing or reconsidering RPA after deployment, fielded from 9 to 15 February 2021 among decision makers and programme owners at companies that had already deployed RPA, with 100 respondents. In it, 93% said they had already changed their RPA setup or were considering an addition or a change. Among the reasons for reconsidering, 40% cited that the work they wanted to automate could not be automated. This is a 2021 study, not a recent one, but that is the point. Five years ago the limit of RPA was already understood to sit in the nature of the target work rather than in how the tool was used.

At the same time, it is too early to hand judgment wholesale to a machine. On 25 June 2025 Gartner published a prediction that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. The same release also reported a poll of more than 3,400 respondents conducted in January 2025, which showed that only a limited share of organisations had moved into serious investment. The poll is a separate instrument and not the sample behind the forecast, and that distinction is worth keeping. Gartner also describes agent washing, noting that while thousands of vendors claim agentic capability, only around 130 are judged to actually have it. Dropping an autonomous agent straight onto the judgment node is, for now, hard to justify on payback.

This article takes the middle position. Avoiding the judgment node will not raise the automation rate, and handing the judgment node over entirely is premature. Insert generative AI as a drafting step that a person then approves, and it becomes measurable in money where the approach works and where it stops working. What follows shows that behaviour through a process breakdown and a set of figures.

Note that every case volume, time allocation, unit rate and cost used here is a model assumption made by this article, not a measured figure from any specific company. Sourced statistics and model estimates are kept clearly separate throughout the text.

Splitting the process into five nodes — RPA alone covers only 31%

The organisation modelled here looks like this. These are assumptions for the estimate, not the numbers of any real company.

• A regional back office of a Japanese-owned manufacturer in Chonburi Province, Thailand, consolidating order and invoice processing for 3 sites
• The target process is matching supplier order acknowledgements, delivery notes and invoices, then registering them in the core system
• Monthly volume is 8,000 cases, so 96,000 cases per year
• Current handling time is 8.0 minutes per case, so 96,000 × 8 = 768,000 minutes, or 12,800 hours per year
• Administrative labour is costed at a monthly salary of 25,000 THB with a statutory-burden factor of 1.25, giving 31,250 THB per month. Divided by 160 hours per month, 31,250 ÷ 160 = 195.3, rounded to 195 THB per hour
• Current annual labour equivalent is therefore 12,800 × 195 = 2,496,000 THB

We split those 8.0 minutes into five nodes by what gets completed, not by who does it. Cutting by role blurs the boundaries as soon as several people work in parallel.

The split is 12.5 / 37.5 / 31.25 / 12.5 / 6.25, which rounds to 13 / 37 / 31 / 13 / 6.

There is one thing to take from this table. RPA on its own covers N1, N4 and N5, a combined 2.5 minutes, which is 31% of the process. The remaining 69% is reading, at 37% in N2, and deciding, at 31% in N3. Neither falls inside what RPA can do.

This is the source of the unease most companies feel after an RPA rollout. Vendor material promises automation of routine work, and order processing certainly looks routine. Break the process apart, though, and only three tenths of it is routine. The rest is non-routine reading and deciding. An automation rate that flattens at three tenths is not evidence of sloppy scenario building. It was the ceiling from the start.

What matters is that this 31% ceiling does not move through process improvement. Enumerate exception patterns and add conditional branches, and the ceiling rises a little. But every branch adds lines to the scenario, and every change to a document format triggers maintenance. If the automation rate goes to 35% while maintenance effort doubles, that is not progress. As long as you attack with RPA alone, automation rate and maintenance cost stay locked in a trade-off.

Why RPA stops at the judgment node — a structural problem, not an exception count

Saying the work has too many exceptions to automate is convenient shorthand and inaccurate. A large number of exceptions can be handled by writing more branches. The real reason RPA stops is that at the judgment node the mapping from input to output has not been fixed in advance.

Break down what a person does in N3 and you find three kinds of work with different natures mixed together.

RPA reaches the first two and never the third. The third is what consumes time on the floor. Plenty of companies have an internal rule that a price gap within 1% passes, and situations that the rule cannot cover always appear. Just after a raw-material price move, with a new supplier, or when only the THB-denominated amount is off because of a currency shift. The person then makes a call outside the criterion, something like letting it through this time and checking next time.

Ignore this structure and keep piling on branches, and one common outcome is the rogue robot. A staff member modifies a scenario to fit their own process, the modification never gets documented, and it goes into production anyway. When the person who built it transfers out, nobody can explain why that branch exists. An auditor asks on what basis this transaction was passed, nobody can answer, and the scenario is eventually switched off and the work returns to manual. Part of the high rate of RPA reconsideration comes from exactly this.

The other outcome is exceptions pushed back at people. Cases RPA could not process pile into an exception queue for humans. That queue is more awkward to handle than the work was before automation, because the case arrives stripped of context and the handler has to re-read the documents from the beginning. Time genuinely falls on the volume RPA processed, while handling time per exception rises. Most of the reason total savings fall short of the plan is this increment in exception-handling cost.

So the question that moves automation to the next stage is not how to reduce exceptions. It is who owns the judgment node. There are only three options. People continue to own it, the criteria are fully documented and handed to RPA, or generative AI drafts and a person approves. The second is ideal and does not hold where judgment involves creating a criterion. The realistic comparison is between the first and the third. Handing the whole thing to an autonomous agent, including the control implications, is covered in our article on the practicalities of deploying AI agents.

There are only three places to connect generative AI — extraction support, judgment drafting, exception explanation

When you build generative AI into process automation, the design to avoid above all is replacing RPA with generative AI. N1, N4 and N5 are repetitions of a fixed procedure, and RPA is cheaper, faster and more stable there. There is no rational reason to make a language model register records in the core system. As UiPath frames it, generative AI takes reading and interpreting while RPA takes collecting and registering, and that division is the straightforward one both to implement and to fund.

Within the five-node model here, generative AI belongs in exactly three places.

Start with extraction support. AI-OCR alone handles standard documents, but order acknowledgements whose layout differs by supplier get stuck at field mapping. Deciding which column holds the unit price on a document that never uses the words unit price is that kind of task. Insert generative AI and the meaning of a column can be inferred from neighbouring words and the magnitude of the figures, which cuts the effort of hand-building a document template for each supplier. Reading accuracy itself still depends on the OCR engine, so adding generative AI does not make OCR unnecessary. Engine selection criteria are set out in our AI-OCR comparison article.

Judgment drafting is the core of this article. What you ask generative AI to output here is neither an approval nor a rejection. It is a recommendation paired with its reasoning. For example, a unit price of 12.50 THB on the order against 12.80 THB on the invoice, a gap of 2.4% that exceeds the internal tolerance of 1%, with the note that a material-cost revision notice for this item arrived the previous month by email dated 2026-07-14, so a missed price revision is the likely cause and confirmation with purchasing is recommended. The handler reads that text and decides whether to approve or send it back. Their work shifts from investigating and thinking to reading and deciding.

The essential point of this design is that generative AI never holds the final decision. As long as the decision stays with a person, the process does not break when the output is wrong. Wrong outputs instead survive as rejection logs and become material for improving prompts and criteria. Hand the decision over and errors flow into the core system undetected, surfacing months later. Given that inadequate risk control was one of the cancellation reasons Gartner listed, keeping the decision with a person is less conservative than it is realistic.

Exception explanation is unglamorous and effective. Cases that fall into the exception queue usually reach the handler with no indication of why they fell. Have generative AI summarise in three lines what diverged from what, and display it alongside the case. That alone visibly reduces handling time per exception. The increment from exceptions pushed back at people, described in the previous section, is cancelled by this modest connection point.

One precondition applies to all three. The operational data has to exist somewhere in structured form. Where a hand-keyed spreadsheet ledger is the only record, the way data is held needs sorting out before generative AI is connected at all. That sequencing is covered in our article on automating spreadsheet work with AI.

Control and evidence — drafting judgment by machine means keeping more records

Put generative AI on the judgment node and the list of things you must record grows. This belongs in the budget from the start, because adding it later means redoing the design.

With RPA alone, the audit trail only needs when, which scenario, which data and which system. Processing is deterministic, so the same input yields the same output. Generative AI does not always return the same output from the same input. To reproduce afterwards why a given judgment was made, the following have to be stored as a set.

The item most often missed first is the model name and prompt version. Improving prompts is routine operational work, and every improvement shifts the tendency of the judgments. When an auditor asks about a case from six months ago and the prompt of that time was never kept, you cannot say how the system judged back then. Deciding at the outset to version prompts exactly as you version source code is the cheap option.

Recording rejection reasons is not a control item alone. How often the generative AI proposal passes as issued, in other words the acceptance rate of the judgment, can only be measured from this record. Since the sensitivity analysis below makes the acceptance rate decisive for the investment case, a design that cannot measure acceptance rate is a design that cannot measure the investment. Put approve, amend and approve, and reject on the approval screen, and always attach a reason list to amend and reject.

Personal data handling has to be settled at design time as well. Contact names and email addresses at suppliers are personal data and fall under PDPA in Thailand. A configuration that sends whole documents to generative AI means sending those to an external API. The practical moves are masking fields that are not needed before transmission, documenting the defined scope of data sent to external APIs, and putting a data processing agreement in place with the provider. None of the three is technically hard, and retrofitting them means reworking every path.

Breaking cost into five layers — payback depends on how far up you buy

Costs are split into layers so that stopping partway remains a decision you can make. A single lump-sum quotation hides how far a given spend takes you, and leaves you unable to say what to cut when the results do not appear. The five layers below assume all 3 sites combined. Every figure is a model assumption of this article and not an actual quotation.

The ordering carries meaning. Layer 1 precedes everything else, because until the target process is broken into nodes, neither the RPA scenarios nor the AI-OCR templates have a defined scope. What the initial 280,000 THB of Layer 1 buys is a process flow diagram, an exception list and a criteria document, and no hardware or software at all. Cutting this layer as mere investigation cost degrades the accuracy of every quotation that follows.

In Layer 2, note that annual running cost of 380,000 THB is large relative to the initial 620,000 THB. RPA is not a one-time install. Every change to a document format and every core-system update triggers scenario rework. Deploy without budgeting the running cost and, in year two, scenarios go untouched for lack of a maintenance budget, and dead scenarios accumulate.

Layer 4 differs from the others in what the money is actually for. API charges are only part of the 360,000 THB annual running cost, and the bulk goes into designing and refining prompts and building the approval screen. Estimate this layer as calling an AI API and it will always come up short. The substance of this layer is the work of fitting the format of the reasoning to the business.

Layer 5 implements the storage items described in the previous section. It produces no benefit on its own and is therefore easy to cut, but if you buy Layer 4 then Layer 5 is mandatory. Having a machine draft judgments while keeping no evidence is choosing, deliberately, to be unable to explain yourself in an audit.

Layer 5 is not solely for Layer 4, though. Even an RPA-only configuration needs scenario version control, execution permission management and proper handling of the personal data processed. Skip that and rogue robots multiply. The three cases in the next section therefore all include Layer 5.

Not every configuration needs all five layers. As the next section shows, how far up you buy changes the payback period. If the order process is not held in a system at all, work on the core system comes before these five layers. That scope is set out in our article on order and purchasing management systems.

Three modelled cases — buying RPA first alone gives the slowest payback

Now to the money. Three cases are defined, and each is matched against the layers it requires and the savings it produces. Everything below rests on the model assumptions of this article and is not measured data.

Case A, RPA only. What can be automated is N1, N4 and N5, a saving of 2.5 minutes. Time per case falls from 8.0 minutes to 5.5 minutes, a reduction of 31%. Annually that is 96,000 × 2.5 = 240,000 minutes, or 4,000 hours. In money, 4,000 × 195 = 780,000 THB per year.

Case B, RPA plus AI-OCR. On top of Case A, 80% of N2 is mechanised. That adds 3.0 × 0.8 = 2.4 minutes, for a cumulative saving of 4.9 minutes. Time per case becomes 3.1 minutes, a reduction of 61%. Annually that is 96,000 × 4.9 = 470,400 minutes, or 7,840 hours, worth 1,528,800 THB per year.

Case C, RPA plus AI-OCR plus generative AI for judgment support. A further 60% of N3 is removed by generative AI drafting. That adds 2.5 × 0.6 = 1.5 minutes, for a cumulative saving of 6.4 minutes. Time per case becomes 1.6 minutes, a reduction of 80%. Annually that is 96,000 × 6.4 = 614,400 minutes, or 10,240 hours, worth 1,996,800 THB per year.

Next, the layers each case requires alongside simple payback in months.

Each figure is simple payback, initial investment divided by annual net. For A, 1,220,000 ÷ 250,000 = 4.88 years, or 58.6 months. For B, 1,640,000 ÷ 698,800 = 2.35 years, or 28.2 months. For C, 2,200,000 ÷ 806,800 = 2.73 years, or 32.7 months.

The conclusion this table produces runs against intuition. The slowest payback belongs to Case A, the option that looks most cautious. Starting small with RPA alone and expanding once results appear seems like sound decision making. In the numbers, A carries an initial investment of 1,220,000 THB against an annual net of only 250,000 THB, and takes close to five years to pay back. The reason is plain. A touches neither the judgment node nor the extraction node, so its benefit stops at 31%, while the platform costs of Layer 2 and the control costs of Layer 5 land up front. Platform paid first, benefit capped early. That is the worst combination for payback.

The fastest payback is Case B at 28.2 months. Handing reading to the machine through AI-OCR nearly doubles the saving, from 2.5 minutes to 4.9 minutes, while the only additional spend is Layer 3. The gap between how fast the numerator and the denominator grow is exactly the gap in payback months.

Note that these three cases do not price in the increment in exception-handling cost. As discussed below, the higher the automation rate, the harder the cases left for people and the longer the handling time per case. Price it in and the benefits of A and B fall further, while C, which carries exception summaries, gains relative ground. In other words, the comparison here is somewhat harsh on C.

Case C pays back in 32.7 months, 4.5 months later than B. Its annual net of 806,800 THB is the highest of the three, however. If payback period is the priority, choose B. If capital is available and the goal is to maximise the annual profit figure, choose C. Neither is superior. They differ in capital constraint and time horizon.

Two practical implications follow. First, stopping at RPA alone has no rational basis. That is not to say A loses money. An annual net of 250,000 THB against an initial 1,220,000 THB is a real return, and after payback it is pure gain. Against B, though, capital efficiency is clearly worse. Since Layer 1 and Layer 2 get bought first either way, going on to include Layer 3 and choose B is the rational move. Second, even when choosing B, Layer 1 must not be skipped. Skip the process inventory and node breakdown and neither the range of documents AI-OCR must read nor the boundary of the RPA scenarios gets defined, and the Layer 2 and Layer 3 estimates inflate as a result. The 280,000 THB of Layer 1 buys accuracy in every quotation downstream.

Sensitivity — below a 46% acceptance rate, hold off on Layer 4

Any investment decision must model the case where things do not go to plan. How the sensitivity is applied matters here. Do not multiply the entire benefit by a uniform factor such as only 70% of the benefit materialises. Mail retrieval in N1 and OCR reading in N2 work regardless of how well the generative AI performs. Only the N3 term moves, and replacing that term alone is the correct treatment.

The downside scenario used here is a drop in the acceptance rate of generative AI judgments from 60% to 40%. The plan assumed 60% of proposals would be approved as issued. In reality only 40% pass and the handler ends up investigating the rest themselves.

Under that scenario the N3 saving becomes 2.5 × 0.4 = 1.0 minute, down from the original 1.5 minutes. The 4.9 minutes saved across N1, N2, N4 and N5 is unchanged, so the cumulative saving is 4.9 + 1.0 = 5.9 minutes. Annually that is 96,000 × 5.9 = 566,400 minutes, or 9,440 hours, worth 1,840,800 THB per year.

The cost side does not move. Layer 4 and Layer 5 are already built and the annual running cost of 1,190,000 THB is incurred in full. Annual net for Case C therefore becomes 1,840,800 − 1,190,000 = 650,800 THB, and payback stretches to 2,200,000 ÷ 650,800 = 3.38 years, or 40.6 months.

The decisive point is that this annual net of 650,800 THB falls below Case B at 698,800 THB. At a 40% acceptance rate, putting 560,000 THB into Layer 4 and paying 360,000 THB a year to run it produces less profit than not buying Layer 4 and stopping at B. Layer 4 does not merely become less effective. Beyond a certain acceptance rate it stops working as an investment at all.

That threshold can be calculated. In this model, start from what one minute of reduction per case is worth annually. 96,000 cases ÷ 60 = 1,600 hours per minute, and multiplied by 195 THB that is 312,000 THB. So one minute of reduction is worth 312,000 THB per year. Writing the acceptance rate as r, the annual net of Case C is 312,000 × (4.9 + 2.5r) − 1,190,000. Solve for the r at which this equals Case B at 698,800 THB.

Rearranging 312,000 × (4.9 + 2.5r) − 1,190,000 = 698,800 gives 780,000r = 360,000, so r = roughly 46%.

The conclusion of this article follows. Investment in Layer 4, the generative AI judgment layer, turns on whether the acceptance rate of judgments exceeds about 46%. Rather than an intuition that around half will probably pass, you need an evidenced estimate of whether your own process can clear that level.

What matters in practice is that this acceptance rate can be measured before the investment. During the Layer 1 process inventory, sample a few dozen historical discrepancy cases, have generative AI produce recommendations and compare them with what the handlers actually decided. That gives a working figure for the acceptance rate. Spending a few tens of thousands of THB on that test before committing 560,000 THB to Layer 4 is obviously the cheaper sequence. If the acceptance rate sits well below 46%, hold Layer 4, stop at B, and push ahead with documenting the judgment criteria first. Documented criteria raise the acceptance rate, which makes Layer 4 something you buy after its case is confirmed rather than something you buy on faith.

Different regulatory ground in Thailand and Vietnam

Companies with several sites across ASEAN need to check the regulatory ground before rolling the same setup out horizontally. As of August 2026, Thailand and Vietnam are in very different positions. Conflated accounts of the two are circulating, so start from an accurate picture.

Vietnam is already in force. The AI Law was passed by the National Assembly on 10 December 2025 and came into force on 1 March 2026. It classifies AI systems into high, medium and low risk tiers, and providers must complete an assessment of which tier applies before going live. Systems already running before the effective date get transitional relief, 12 months for general sectors and 18 months for healthcare, education and finance. Implementing detail sits in Decree 142/2026/ND-CP, promulgated on 30 April 2026 and effective from 1 May 2026, which sets out the risk classification detail, the labelling obligation for AI-generated output, and reporting of serious incidents within 72 hours. The decree also applies to foreign organisations carrying out AI-related activities inside Vietnam.

Keeping the qualifiers intact matters here. Internal back-office uses such as invoice matching and reconciling order acknowledgements do not normally fall into the high-risk tier. High-risk uses are enumerated by sector in Prime Minister Decision 33/2026/QD-TTg of 30 June 2026, which lists 46 systems and takes effect on 15 August 2026. It covers 6 sectors, namely transport, ethnic and religious affairs, education, healthcare, banking and justice, with transport accounting for the largest share at 31 systems. The important feature is that this operates as a whitelist, where only what appears on the list is treated as high risk. A mechanism for making internal accounting processing more efficient is not on that list and does not automatically become subject to the high-risk regime. The belief that using AI necessarily triggers high-risk regulation is simply wrong. What is required in practice is carrying out the risk classification assessment and keeping the record, confirming whether the labelling obligation for AI-generated output reaches your own operation, and having a reporting route for serious incidents that can run inside 72 hours.

Thailand has not enacted one yet. AI legislation remains at draft stage, and as of August 2026 no comprehensive AI act is in force. The legal foundation for embedding AI in operations at a Thai site therefore remains PDPA, the personal data protection act. On 17 February 2026 the PDPC opened a public consultation on draft guidelines for personal data protection in the development and use of AI. The guidelines carry no binding force, but they should be read as an indication of the regulator’s expectations and the likely direction of interpretation. The draft touches on including a prohibition on use for model training in data processing agreements, and on requiring a data protection impact assessment for high-risk AI use.

Administrative fines under PDPA have different ceilings by provision, set at three levels of 1,000,000 THB, 3,000,000 THB and a maximum of 5,000,000 THB. For the back-office use modelled here, the exposures most likely to bite are use beyond the consented purpose and inadequate management of processors. A configuration that ships whole documents to a generative AI API touches both directly.

For horizontal rollout, the cheap approach is to design the control and audit trail of Layer 5 to the Vietnamese standard. Vietnamese requirements are more concrete, so building to them means little rework if the Thai guidelines are finalised later. Build to the Thai standard first and carry it into Vietnam, and the risk classification records and incident reporting route have to be bolted on afterwards.

Six patterns in which RPA and generative AI integration fails

The material above can be restated as failure shapes. All six recur in practice.

Pattern 1, trying to replace RPA with generative AI. A design that pushes the routine processing of N1, N4 and N5 onto generative AI costs more, produces less stable results and generates more evidence to keep. RPA is cheaper and more reliable on those three nodes. Generative AI is not a replacement. It is an addition where RPA cannot reach, at N2 and N3.

Pattern 2, skipping Layer 1 and starting from tooling. Choose tools before the process inventory and node breakdown, and development begins with the scope undefined. Requests for extra scenarios then arrive without limit, and Layer 2 and Layer 3 overrun the original estimate. It is the classic case of saving 280,000 THB and losing several hundred thousand THB.

Pattern 3, buying Layer 4 without measuring the acceptance rate. As shown above, below roughly 46% the layer does not hold as an investment. Acceptance rate can be measured before spending, through sample testing. Buying without measuring leaves payback to chance.

Pattern 4, deferring the evidence design. A design that retains model name and prompt version, approver and rejection reason becomes a rework of every path if it is added after go-live. Worse, the acceptance rate for any period in which rejection reasons went unrecorded cannot be reconstructed, which sets the improvement cycle back a full round.

Pattern 5, delegating judgment wholesale to an autonomous agent. Given that Gartner forecasts over 40% of agentic AI projects will be cancelled by the end of 2027 and cites inadequate risk control among the reasons, a design that keeps no human approval is currently hard to justify on payback. Gartner also puts the number of vendors with genuine agentic capability at around 130, against thousands that claim it. At product selection, insist on a clear separation between what is autonomous and what is a draft.

Pattern 6, going live without designing the exception queue. The higher the automation rate, the harder the cases that reach people. Stack exceptions without context and handling time per case exceeds what it was before automation. Generative AI summaries of exceptions exist precisely to cancel that increment. Any estimate that omits the increment in exception-handling cost will diverge from actual results.

A 90 day approach

Deployment follows the order of the layers. The goal for the 90 days is not to have everything live. It is to reach a state where the decision on buying Layer 4 can be made.

Weeks 1 to 4, measure. Not starting improvements here is the important part. Take action and the baseline disappears, leaving no way to prove the effect later. The measurement granularity is a start and end timestamp for N1 through N5 on each case. Self-reporting by handlers is acceptable, but cover a window that includes both month-end peak and normal periods. Over these four weeks you will discover things like a real figure of 11 minutes rather than 8.0 minutes, and that is fine. The numbers in this article are model assumptions and are meant to be replaced.

Weeks 5 to 8, validate the acceptance rate. Sample historical discrepancy cases in proportion to the nature of the work, have generative AI produce recommendations with reasoning, compare against what the handler decided at the time, and derive the share that could have been approved as issued. This validation needs no production environment, only document samples and the criteria document. If the acceptance rate lands well below 46%, hold Layer 4 and stop at Case B. If the cause is that recommendations miss the mark because criteria were never documented, documenting them first will raise the acceptance rate.

Weeks 9 to 13, build the platform. Implement Layer 2 for RPA and Layer 3 for AI-OCR, and fix the Layer 5 evidence design at the same time. Layer 5 comes before Layer 4 so that buying Layer 4 involves no rework. By the end of this period, measured savings and a validated acceptance rate are both in hand, so the Layer 4 investment decision can be made in numbers.

One thing is deliberately excluded from these 90 days, and that is expanding scope. Even with 3 sites consolidated, narrowing the start to one site and one document type is faster. Widen the scope after the Layer 4 decision is made.

Frequently asked questions

Should RPA or generative AI come first

In the estimates here, Case A with RPA alone has the slowest payback at 58.6 months, because platform costs land up front while benefit is capped at 31%. The recommended sequence is to design RPA and AI-OCR within the same plan and defer the generative AI judgment layer until the acceptance-rate validation is in. Ahead of any tool, however, comes the node breakdown of the process in Layer 1. Without it, neither RPA nor generative AI has a defined scope.

How much does RPA and generative AI integration cost

The model here, covering 3 sites combined at 8,000 cases per month, assumes 2,200,000 THB initial and 1,190,000 THB annual running across all five layers. A Case B configuration excluding the Layer 4 generative AI judgment layer comes to 1,640,000 THB initial and 830,000 THB annual running. These are estimates and vary widely with site count, document types and the state of the existing core system. When taking actual quotations, ask for the amounts broken out by layer. A lump-sum quotation removes your ability to stop partway.

Is connecting OCR and RPA alone insufficient

Not necessarily. In these estimates, Case B with RPA plus AI-OCR has the fastest payback at 28.2 months and is the best option on investment efficiency. That said, Case B leaves 3.1 minutes per case, of which the 2.5 minutes of the judgment node remain essentially untouched, and the reduction stops at 61%. Cutting further into those 3.1 minutes is what requires the generative AI judgment layer. Until there is a credible prospect of clearing roughly 46% acceptance, stopping at B is a defensible call.

How far can data entry work realistically be reduced

Under the model assumptions here, Case C with all five layers brings 8.0 minutes per case down to 1.6 minutes, a reduction of 80%. Annually that is 10,240 hours, equivalent to 1,996,800 THB. That figure assumes a 60% acceptance rate for judgments. At 40%, the saving falls to 5.9 minutes, a reduction of 74%, worth 1,840,800 THB. Full automation at 100% should not be the target. Keeping human approval on the judgment node produces steadier results on both control and payback.

How do we expand automation without multiplying rogue robots

Rogue robots usually appear because a staff member tried to fill the judgment node with conditional branches. The remedy is therefore not to ban scenario modification but to build a structure in which the judgment node does not need branches. Concretely, fix the design so judgment happens on an approval screen operated by a person, and confine RPA scenarios to the routine processing of N1, N4 and N5. On top of that, budget scenario version control and review rules inside Layer 5. Trying to stop modifications with human rules alone always collapses during peak periods.

If generative AI drafts the judgment, can we explain it in an audit

A design that can be explained is achievable, provided the storage items are decided at the start. At minimum that is five things, the input data and referenced documents, the full text of the generative AI output, the model name and prompt version, the approver identity and approval timestamp, and the rejection reason. The one most easily dropped is prompt version, without which past judgments cannot be reproduced. Version prompts exactly as you version source code. Keeping the final decision with a human approver additionally makes accountability explicit and sharply reduces the effort of responding to an audit.

Summary

RPA automation rates plateau not because exceptions are numerous, but because judgment is mixed into the workflow and RPA cannot make judgments. Splitting the process into five nodes in this model leaves RPA covering N1, N4 and N5, a combined 2.5 minutes and 31% of the whole. The remaining 69% is reading in N2 and deciding in N3, and neither is within reach of RPA.

There are only three places to connect generative AI, namely extraction support, judgment drafting and exception explanation. All three leave the decision with a person while changing the handler’s work from investigating and thinking to reading and deciding. A design that replaces RPA with generative AI is unjustifiable on cost and on control alike.

In money, the conclusion is paradoxical. Under the model assumptions here, Case A with RPA alone pays back slowest at 58.6 months, Case B with RPA plus AI-OCR is fastest at 28.2 months, and Case C including generative AI pays back in 32.7 months while producing the largest annual net at 806,800 THB. Starting small with RPA alone, an order that looks safe, can be the worst choice for payback, because platform costs land up front while benefit stops at 31% unless the judgment node is touched. Even when choosing B, the Layer 1 process inventory must not be skipped.

Investment in Layer 4 turns on the acceptance rate of judgments. In this model one minute of reduction is worth 312,000 THB per year, and the acceptance rate at which Case C matches Case B works out to roughly 46%. At 40% acceptance the annual net for Case C falls to 650,800 THB, below the 698,800 THB of Case B. That 46% figure can be estimated through sample validation before the money is spent.

On the regulatory side, Vietnam’s AI Law has been in force since 1 March 2026 while Thailand has not enacted one. Vietnam requires a risk classification assessment and 72 hour reporting of serious incidents, but high risk is confined to the 46 systems enumerated in Prime Minister Decision 33/2026/QD-TTg, and internal back-office uses such as invoice matching do not fall within them. Thailand’s foundation is PDPA, with the PDPC having opened a public consultation on draft AI guidelines on 17 February 2026.

Even before you know how many minutes your own process actually takes or which node holds the time, the approach is worth discussing. Simply settling which node to measure first and how to sample-validate the acceptance rate will sharpen the investment decision. For a design fitted to conditions on your own floor, get in touch through our contact page at any time.

References

• Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027
• Hitachi Solutions, survey on replacing and reconsidering RPA after deployment, fielded February 2021, 100 respondents
• UiPath, where RPA sits within agentic automation
• Vietnam, Decree 142/2026/ND-CP elaborating the Law on Artificial Intelligence, English translation
• Atsumi and Sakai, key points of the decree implementing Vietnam’s AI Law
• Vietnam, Prime Minister Decision 33/2026/QD-TTg listing 46 high-risk AI systems
• Tilleke and Gibbins, Thailand’s AI governance framework
• Thailand PDPC, public consultation on draft data protection guidelines for AI