Here is a scenario that plays out in enterprise technology conversations more than it should. A team identifies a process that is slow, error-prone, and consuming too much manual effort. Someone proposes AI. A vendor is brought in. A proof-of-concept is scoped. Months later, the team has a model that does not quite fit, a business case that does not hold up, and a process that is still being managed largely by hand.

The process could have been automated with RPA in four weeks.

The reverse happens too. An organization deploys bots on a claims triage process and watches coverage collapse under the weight of exceptions. The process needed AI to handle variable inputs. The bot handled only the clean ones.

Both failures come from the same root cause: selecting a technology before understanding what the process requires. The question is not which technology is better. It is determining which technology is appropriate for this specific process, given its structure, its decision logic, and the cost of getting it wrong.

This article gives you a framework to answer that question. It covers the three evaluation criteria that determine which option is right, the diagram that maps the decision, and a concrete 30/60/90-day pilot structure for each path.  

First, Understand What You Actually Have

Before reaching for any automation technology, it helps to be honest about two things: what the process does and what it costs to run it badly.

According to Gartner’s 2024 market analysis, the RPA software market grew 14.5 percent to $3.6 billion, while AI innovations, including generative AI and agentic automation, began slowing traditional RPA growth rates as organizations sought more intelligent capabilities. That shift reflects a market learning the hard way that not every process is the same problem.

Gartner’s guidance from its June 2025 research is direct: use AI agents when decisions are needed, use automation for routine workflows, and use assistants for simple retrieval. Most use cases positioned as agentic today do not require agentic implementations.

That is the lens through which this framework applies. Not “what can we automate” but “what does this process actually need.”

The Three-Question Framework 

Question 1: Is the input structured or variable? 

This is the first and most important filter. Structured inputs are consistent in format, arrive predictably, and can be read without interpretation. A database record, a standardized form, and a system-generated file are structured inputs. An email, a scanned document, a handwritten form, and a PDF format contract are variable inputs that require interpretation before any action can be taken.

If the input is structured and arrives in a consistent format, the process is a candidate for RPA. The bot does not need to understand the input. It needs to read it, execute a defined sequence, and move on.

If the input is variable, the process needs an AI layer before automation can execute reliably. Feeding variable, unstructured inputs into a rule-based bot produces the single most common RPA failure pattern: the bot handles the clean inputs and crashes on everything else.

Deloitte’s global RPA survey found that 78 percent of companies have implemented or plan to implement RPA, and that 58 percent intend to integrate AI and machine learning into their RPA deployments by 2026. The reason for that integration trend is precisely this: organizations that started with pure RPA are discovering that the processes with the most volume also have the most variance, and variance requires AI.

Question 2: Does the process require execution or judgment? 

Execution means doing the same thing every time, given the same input. Judgment means the correct action depends on context, history, risk signals, or information that a rule cannot fully capture.

Execution belongs to RPA. Judgment belongs to AI.

Most real-world processes contain both. A mortgage processing workflow has structured data entry at the intake stage, which is considered execution and should be handled by RPA. It has a creditworthiness evaluation in the middle, thus includes judgment and requires AI. A customer service operation has ticket routing and status updates, which entail execution. It has intent classification and response drafting, hence judgment.

The hybrid pattern is not a compromise. It is the architecturally correct approach for processes that contain both types of work. AI handles the front end, interpreting and classifying the input. RPA handles the back end, executing the downstream workflow once AI has produced a structured output. Forrester reports that 44 percent of organizations already use AI-powered bots for document processing, reflecting the growing adoption of this front-end AI, back-end RPA pattern.

Question 3: Is the process worth the cost of AI inference?

This is the question that most automation frameworks skip, and it matters more than it used to.

Every time an AI model runs on a process, it consumes compute resources. At low volume, this cost is negligible. At high volume, it accumulates. The calculation is straightforward in concept: if a process runs fifty thousand times a month and each AI inference costs a fraction of a cent, the monthly inference cost is real and needs to appear in the business case. If the process runs two hundred times a month and the error rate without AI creates meaningful downstream consequences, the cost is justified regardless.

The conceptual test is this: is the process complex enough, variable enough, or high-stakes enough that AI inference is the most cost-effective way to handle it? Or is the input clean enough, structured enough, and consistent enough that a rule-based bot can handle it at a fraction of the cost with equivalent reliability?

Running AI on a process that RPA could handle is considered an economic failure. The inverse is equally costly, running RPA on a process that produces constant exceptions and requiring manual intervention to clean up the ones the bot could not handle.

McKinsey’s 2025 research on scaling agentic AI found that while nearly two-thirds of enterprises worldwide have experimented with AI agents, fewer than 10 percent have scaled them to deliver tangible value. Eight in ten companies cite data limitations and mismatches in process complexity as the primary roadblocks. The gap between experimentation and value is largely an evaluation failure, deploying AI before confirming the process warrants it.

The Decision Framework

The diagram maps the three questions sequentially. Starting with the input structure immediately filters the candidates. Execution vs. judgment determines which technology handles the core workflow. The inference cost question settles the hybrid cases where both technologies are viable. The output of the three questions is one of three recommendations: RPA, AI, or hybrid.

Applying the Framework in Practice

The accounts payable process. Structured inputs. Deterministic logic. Low judgment requirement. No meaningful inference cost-benefit over rules. Recommendation: RPA.

The contract review workflow. Variable inputs in multiple document formats. High judgment requirement, including relevance, risk flags, and non-standard clauses. High value per document, low volume. Inference cost is justified. Recommendation is AI or AI-first hybrid.

The insurance claims triage process. Mixed inputs, some structured intake forms, some unstructured supporting documents. Structured intake is RPA-appropriate. Document review and coverage assessment require AI. High volume justifies inference at scale. Recommendation: Hybrid.

The fraud detection process. Pattern-dependent decision. No static rule captures emerging fraud signals. Context and historical behavior determine the output. Inference cost is directly offset by fraud exposure reduction. Recommendation: AI.

The framework does not replace judgment. It structures it. Every process has details that will affect the final recommendation, and applying the three questions is the starting point, not the endpoint.

How to Experiment: A 30/60/90-Day Pilot Structure

The organizations that scale automation programs well do not start with the most ambitious process. They start with the process best suited to produce a clean, verifiable result within a defined window, and they build a standard for what “working” means before they start.

If the framework points to RPA

Days 1 to 30 — Map and qualify. Document the process at the step level. Identify every input source, every decision point, and every exception type. Define the automation coverage target: what percentage of transactions will the bot handle without human intervention? A realistic first-deployment target for a well-scoped RPA process is 75 to 85 percent coverage, not 100. Build the exception routing logic before writing a single bot script.

Days 31 to 60 — Build and test in staging. Deploy against a controlled transaction set that includes clean inputs and deliberate edge cases. Measure actual coverage against the target. Track the exception rate and categorize exceptions by type. Any exception category that appears in more than 5 percent of transactions is a redesign signal, not a deployment defect.

Days 61 to 90 — Go live with monitoring. Deploy to production with daily monitoring for the first two weeks. Track coverage rate, exception rate, error rate, and processing time against the pre-automation baseline. The 90-day mark should produce a verified ROI figure that either confirms the business case or revises it for the next process.

If the framework points to AI

Days 1 to 30 — Define success criteria and prepare training data. This is where most AI pilots fail. The success criteria must be defined in business terms before model development begins. What accuracy rate is required for the output to be trusted in production? What happens when the model is uncertain? Does it route to a human queue, or does it halt? Prepare a labeled dataset that reflects real production inputs, including the messy ones.

Days 31 to 60 — Build, evaluate, and validate. Train the model on the prepared dataset. Evaluate against a held-out test set that was not used in training. Measure not just accuracy but the failure modes, what type of errors does the model make, and what is the business consequence of each? A model that is 92 percent accurate on a fraud detection task may be acceptable or unacceptable depending on what the 8 percent misclassification rate costs.

Days 61 to 90 — Shadow production. Run the model in parallel with the existing process. Do not replace human decisions yet. Compare the model’s outputs to actual decisions over a full 30-day window. Identify where the model agrees with human judgment, where it diverges, and whether the divergences represent model errors or human ones. This shadow period is what produces the evidence base for a production deployment decision.

If the framework points to a hybrid strategy

Days 1 to 30 — Decompose the process into AI components and RPA components. Draw the boundary explicitly. Which steps require interpretation? Those belong to AI. Which steps are pure execution following a structured handoff from AI? Those belong to RPA. Define the data contract between the two layers: what structured output does AI need to produce so that RPA can execute without ambiguity?

Days 31 to 60 — Build both layers independently and test the handoff. Do not build both simultaneously with the same team. Build the AI layer and validate its output structure. Build the RPA component against the defined output specification. The handoff test is the most important validation: when AI produces a structured output, does RPA execute correctly against it, including in edge cases?

Days 61 to 90 — Integrate and measure end-to-end. Run the full pipeline in production and measure cycle time, coverage, error rate, and inference cost against the baseline. The metric that matters most for a hybrid deployment is end-to-end throughput, the percentage of transactions that flow from input to completion without human intervention.

At Paragon Shift, we build the process qualification assessment by mapping your candidate processes against the three evaluation criteria before any technology selection is made. The programs that deliver within their business case timelines are the ones that completed that qualification before the build, not during it.

What the Market Is Signaling in 2026 and 2027

The direction of travel in the automation market is clear, and it validates the RPA AI hybrid strategy. Gartner predicts that at least 15 percent of day-to-day work decisions will be made autonomously through agentic AI by 2028, up from zero percent in 2024, and that 33 percent of enterprise software applications will include agentic AI by 2028. At the same time, Gartner is explicit that over 40 percent of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, and inadequate risk controls.

Those two predictions are not contradictory. They describe the same market at two different maturity levels: organizations that apply AI to processes that warrant it will scale; organizations that apply AI to processes that do not warrant it will cancel. The framework in this article is the mechanism for telling the difference before the investment is made.

McKinsey’s research projects that AI agents could add $2.6 to $4.4 trillion in value annually across business use cases. That value will not accrue uniformly. It will accrue to organizations that identified the right processes, chose the right technology for each, and built the integration architecture that lets RPA and AI operate as complements rather than alternatives.

The organizations furthest ahead in automation did not choose AI over RPA. They chose the right tool for each process and built the layer that connects them.

Key Takeaways

1. The three-question framework, input structure, execution vs. judgment, inference cost justification, determines whether a process belongs to RPA, AI, or a hybrid of both. Skipping the evaluation and selecting technology first is the most consistent predictor of automation failure.

2. Gartner’s own guidance is to use automation for routine workflows and AI when decisions are needed. Many use cases positioned as requiring AI today do not require AI implementations. Recognizing that distinction is what makes the framework valuable.

3. Hybrid is not a fallback. For processes that contain both structured execution and variable judgment, the AI-interprets, RPA-executes pattern is the architecturally correct design.

4. The 30/60/90-day pilot structure is designed to produce a verified result and a defensible business case within one quarter, not a proof-of-concept that needs another six months of evaluation before deployment.

5. Nearly two-thirds of enterprises have experimented with AI agents, but fewer than 10 percent have scaled them to deliver value. The gap is almost always a process qualification failure, not a technology failure.

6. Inference cost is a real operational variable that belongs in every automation business case. Running AI on a process that RPA could handle is an economic error. Running RPA on a process that requires judgment is an architectural error. The framework addresses both.

Conclusion

The question is not whether to automate. Most organizations have already decided that. The question is whether the automation they are building is matched to the work it is being asked to do.

RPA and AI are not competing answers. They are tools with different capabilities and different cost structures, suited to different categories of work. Getting the allocation right before the build, not after deployment, is what produces programs that scale rather than pilots that stall.