You’re listening to “Limitations of RPA Implementations: Exploring the Barriers of Organizational Environments,” by I.D. Nunes, E. Sosa-Sanchez, and L.H. Thom. Published in 2026.

Abstract.

In recent years, the literature has provided evidence of the increasing adoption of Robotic Process Automation (RPA) by organizations. This technology has been changing the way organizations perform their operations. However, despite the market’s enthusiasm for RPA, the failure rates of initial RPA projects are high (between 30% and 50%). The literature lacks a consolidated taxonomy detailing these limitations faced by RPA, leading organizations to go through a costly and inefficient trial-and-error process. Addressing this gap, this article aims to identify and catalog the limitations observed in RPA as well as investigate the capabilities of Generative Artificial Intelligence (GenAI) that can be used in this context.

The authors conducted a Systematic Literature Review (SLR) to collect and analyze works on RPA and GenAI, seeking to identify the limitations of RPA and observed capabilities of GenAI. The search was conducted in academic databases, resulting in a final selection of 94 primary studies for in-depth analysis. These were then subjected to a thematic analysis to synthesize the results and generate the taxonomy. As a result, 10 limitations were identified and cataloged, which were grouped into a taxonomy of three categories: Strategic, Organizational, and Technical Limitations. It concludes that GenAI can be used to help overcome RPA limitations and has the potential to redefine the way process automation is performed. The synergy between the two technologies represents a fundamental transition from ‘‘task automation’’ to ‘‘knowledge automation’’.

Introduction.

Currently, organizations that aim to offer better solutions and services to customers, are ahead of the race for customer acquisition. However, for an organization to provide quality services, it must first embody the idea of constant innovation and evolution in what drives a company and its business processes. By executing processes more efficiently, an organization can outperform others even if they deliver the same services because one organization manages its processes better. In the context of process improvement

The associate editor coordinating the review of this manuscript and approving it for publication was Arturo Conde.

and optimization, organizations that adopt Robotic Process Automation (RPA),, observe substantial advan-tages in areas such as cost, process correctness, regulatory compliance, speed, reliability, error reduction, and improved customer satisfaction.

RPA is a technology based on information technology, which involves the development of software robots (bots) programmed to mimic human behavior by interacting with information system environments. The main objective is to efficiently perform repetitive and structured tasks. To achieve this goal, organizations should seek to automate the tasks best suited for this purpose, namely those that are repetitive, rule-based, and involve structured data,

, that is, tasks that are frequently repeated and follow a well-defined flow, such as invoice processing, purchasing, sales orders, among others. Such repetitive tasks are usually tedious and costly for employees. Thus, RPA emerges to help employees in these tasks that consume a large part of their time,,, allowing them to apply their human expertise to other tasks that are more important to the organization, generating improvements in productivity and cost reduction.

RPA integrates with other areas, including Artificial Intelligence (AI). This integration motivates the called Intelligent Automation,, which uses AI techniques such as computer vision and natural language understanding, to provide RPA bots with the capability to perform tasks that involve decision-making, data interpretation, and experiential learning. These techniques allow the bot to work with unstructured data and predict patterns. This integration takes RPA to a much higher level, as the skills that AI can provide to the bots apply to the execution of various tasks, making the bot created for a specific task more dynamic and adaptable to performing different tasks.

The ideal implementation of RPA in organizations should follow a workflow called the RPA lifecycle, which typically consists of six stages, covering everything from analyzing the process candidate for automation to its automation and performance evaluation,.

This work presents a study, based on the literature, on the limitations that RPA faces in organizational environments, also contributing with an analysis of the main skills explored in Generative AI (GenAI) according to the literature, aiming to identify in which limitations of RPA, such skills can be explored.

The remainder of this article is organized as follows: Sec-tion II presents fundamental research concepts; Section III outlines related works on the research topic; Section IV describes the method used to conduct the research; Section V presents the obtained results and discussions; Finally, Sec-tion VI provides conclusions and prospects for future work.

II. FUNDAMENTALS.

Throughout the execution of this work, specific research was necessary on fundamental themes to compose and support our study. In this chapter on fundamentals, key topics explored and referenced throughout the text will be presented and described.

A. ROBOTIC PROCESS AUTOMATION

A widely known and accepted concept of RPA is that it is an umbrella term covering all those tools that operate on a user interface simulating what a human would do. RPA is a set of techniques aimed at automating processes through pro-grams called bots. These programs are developed to execute tasks in a business process by simulating human interaction with a system. RPA implementation usually happens in an organization during a process improvement procedure stemming from Business Process Management (BPM),, and organizations that apply this management approach to monitor their processes from start to finish perform better than those that do not.

Even with significant investment and market enthusiasm, a significant portion of RPA initiatives fail to achieve the expected success. Approximately 30% to 50% of initial RPA projects fail.

The tasks most suitable for automation are those repetitive, rule and structured data-based, processes with a high volume of manual tasks that demand a lot of execution time from the employee, tasks that are often tedious for employees. These structured processes of task execution (routines) are programmed as scripts executed by the bots. RPA comes to relieve employees of these tasks that consume much of their time, so that employees can then apply their human expertise to other tasks that are more important for the organization.

Process automation is gaining space and confidence, being applied in many fields, such as manufacturing, banking, edu-cation, procurement and inventory management, agriculture, healthcare, and digital forensics,,.

Another strength of RPA is that the development and implementation of bots can be facilitated by RPA platforms and tools. Some of the most well-known ones are Power Automate, Kofax, Pega, WorkFusion, Jacada, WinAutoma-tion, NICE systems, Automation Anywhere, Blueprism, and UiPath,. Therefore, an organization does not need to hire employees with excellent programming skills, as working with RPA development interfaces is basic. The graphical modeler tool assists in designing the process, dragging, dropping, and connecting elements that represent steps in a process. Other complementary tools are specific to each implementation, according to their needs. These tools include schedulers and collaborators, auditing tools, or some AI features that facilitate bot development. It is important to note that the boundaries between traditional RPA and AI are becoming increasingly blurred.

Modern RPA platforms already incorporate AI features, therefore, such platforms are also taken into consideration in this work.

B. GENERATIVE ARTIFICIAL INTELLIGENCE

Within the broad field of AI, there exists GenAI, which refers to a subset of AI techniques and models designed to generate new content, such as text, images, music, and more, allowing machines to learn and adapt to various situations. This technology is changing the world as we know it, bringing forth content that is now difficult to discern whether it was created by humans or machines. Companies in a variety of industries (human resources, education, banking, manufacturing, sustainable IT management, among others) have been exploring the use of GenAI. In addition to mimicking writers and illustrators, GenAI can be used as assistants simulating question-answering systems, such as ChatGPT (Generative Pre-trained Transformer), and

Gemini, which can generate new content and also answer questions, acting as a conversational agent, allowing users to engage in interactive dialogues. All these abilities are encapsulated in Large Language Models (LLMs).

LLMs are deep learning-based models characterized by extensive training on data to learn and perform various Natural Language Processing (NLP) tasks. One of the main goals of NLP is to enable computers to perform tasks involving human natural language, such as human-machine communication and improving that communication. They have numerous parameters and are designed to capture the complexities and nuances of human natural language.

It is important to highlight that to use LLMs to their full potential, whether in RPA or other activities, it is necessary to create effective prompts so that the LLM can perform tasks in the best possible way. The field that studies this is Prompt Engineering. Prompt Engineering deals with the use of task descriptions in natural language, which are provided to the LLM at inference time to give information about the requested task.

One of the most well-known LLMs frequently addressed in recent research is OpenAI’s ChatGPT. ChatGPT 3.5 was launched in November 2022 as a versatile conversational model. Since then, there have been numerous releases of different models, and also by different companies. Regarding ChatGPT, currently, in December 2025, it is in version 5.2. ChatGPT could generate code, images, videos, write stories, translate texts, and even conduct semantic analyses,. ChatGPT uses a form of learning based on human feedback, known as reinforcement learning from human feedback (RLHF). It is fine-tuned using a reward signal that assesses the quality of its generated responses, to maximize the reward signal over time. The model’s ability to learn from the reward signal allows it to generate increasingly relevant and coherent responses.

III. RELATED WORKS.

The intersection between RPA and LLMs is recognized as a high-impact research frontier, requiring an interdisciplinary perspective to understand its effects on business processes. In a ‘‘Panel Report’’ in 2023, the authors synthesize the views of prominent researchers in the field, establishing an agenda for future research. The paper articulates both sides of the phenomenon: RPA, as a mature technology that generates ‘‘side effects’’ such as skill decay, and LLMs, as a new driving force that, despite its potential, presents its own limitations. As a result of the discussion, the authors point to the need to advance the technical integration of AI into RPA tools as an open limitation.

Addressing this discussion, this chapter will first analyze the literature that addresses the limitations of RPA and then explore studies that already investigate the synergy between RPA and Generative AI, to then delimit the original contribution of this work.

According to, the maturity of RPA has brought with it the awareness of its intrinsic limitations. The literature often explores these limitations through case studies detailing their implementation in specific contexts. A relevant example is the work of, where the authors conducted a case study at the manufacturing company WJY Corporation to investigate the application of RPA in its Human Resources Shared Services Center (HRSSC). The study initially aimed to identify the bottlenecks and operational limitations the organization encountered. The study identified clear operational limitations, such as errors in payroll calculation, inefficiencies in the employee lifecycle (hiring and dismissing), and regulatory compliance risks.

With the implementation of RPA in areas such as time and attendance data integration, salary calculation, and social security declarations, the study indicates a 94% improvement in transaction processing timeliness and a 97% reduction in error rates. The paper concludes by proposing a three-stage digital transformation strategy, culminating in the incorporation of AI capabilities into decision-making. This paper presents the benefits of RPA; however, its nature as a case study fundamentally differs from the approach taken in this work. While the article investigates the business process limitations that RPA can solve, this work delves deeper into the limitations of RPA technology itself. Furthermore, the future step suggested by the authors, AI integration, is the starting point for the central analysis of this work.

However, rather than being treated as a final step in a single company’s roadmap, this AI integration is approached systematically and prospectively, investigating how Generative AI, specifically, can serve as a countermeasure to the spectrum of RPA limitations identified in the literature.

The literature indicates that many of the limitations of RPA projects emerge even before development, during the analysis and design phases. Reference delve deeply into this problem, which they describe as an ‘‘unstable foundation’’ for bot implementation, since process documentation is typically incomplete or imprecise. According to the authors, relying on manuals to design RPA bots that will operate in production environments carries significant risk. As a solution, they propose a method to improve the early phases of the RPA lifecycle, which consists of capturing employ-ees’ real-world knowledge through non-invasive monitoring of their interactions with the systems. This capture of screen, mouse, and keyboard logs is then processed using image analysis techniques and process mining algorithms to discover and model the workflow as it actually occurs.

Evaluation of the method in two industrial cases demon-strated benefits in accuracy and speed during the analysis phase.

The work by proposes a solution that addresses a major limitation of RPA: its reliance on a discovery and analysis process, which is itself a bottleneck. The proposed solution, based on process mining, is a countermeasure to this specific limitation. The present work, however, has a broader scope. While the authors focus on improving the input phase of the automation lifecycle, this work, through an SLR, aims to consolidate a catalog of limitations that encompasses all phases, from discovery (as addressed by them) to technical maintenance limitations, organizational scalability limitations, and strategic governance issues.

To support our understanding of RPA’s limitations, reviews like the one by and are crucial. Reference argue that while RPA is a powerful tool, its success is not guaranteed, and implementation can fail if not executed correctly. The review identifies a set of recurring limitations and also highlights an inherent limitation: traditional RPA works well with structured data, but integration with AI and ML is necessary to handle more complex tasks and unstructured data.

Reference investigated feasible and infeasible tasks to automate with RPA, as well as how the use of AI can over-come the complexities of automating such tasks. The work was conducted with an SLR that selected 91 studies, which were complemented by a survey of 86 industry professionals who implement and use RPA. The study presented RPA’s capabilities and limitations regarding data manipulation, process logic, and software applications operated during work execution, and highlighted new capabilities that can be implemented with the use of AI.

Both works ( and ) are valuable for mapping the literature consensus on the general categories of RPA limitations and how AI can help in this context. However, the contribution of this work differs in depth and focus. In addition to presenting RPA limitations, this work sought to understand the countermeasures found in the literature and also present Generative AI as a new paradigm to mitigate these limitations. Generative AI adds an important point of difference between our works.

A work closely related to the present work, in method-ological terms, is presented in. The authors conducted a systematic review, analyzing 54 articles published between 2020 and 2024, where the objective was to investigate the impact of RPA on the higher education sector. The work confirms the benefits of RPA in administrative efficiency, but delves deeper into the limitations faced by institutions. Among the limitations identified are high implementation costs, concerns about the security of sensitive data, cultural resistance to the adoption of new technologies, and the complexity of managing changes in workflows. Even more aligned with this work, the authors point out that traditional RPA often struggles to automate complex tasks and process unstructured data, and that gaps in educator knowledge and training hinder the effective use of RPA.

While the review by is crucial for validating the relevance of RPA limitations, it differs from this work in two crucial respects. Firstly, its scope is restricted to the educa-tional sector, while the present work created a taxonomy of limitations present in organizational environments broadly. Second, and more importantly, in their recommendations for future research, the authors suggest that the integration of advanced technologies such as AI, ML, and NLP could enhance RPA capabilities. This work directly addresses this point, focusing on Generative AI to mitigate the limitations of RPA identified in the literature, thus offering an original contribution and an advancement in relation to the established state of the art.

IV. METHODOLOGY.

The methodology used in this work was adapted from the guideline for systematic reviews presented by. The Systematic Literature Review (SLR) has proven to be the most effective methodology for conducting our research. Our aim was to gather information about RPA and its limitations, and also the use of GenAI in this contexts.

We chose to use the guide ‘‘Guidelines for performing Systematic Literature Reviews in software engineering’’ as our main reference, given its comprehensiveness and specificity in conducting SLR in the field of Software Engineering, which is crucial for our research. This guide has more than 14000 citations on Google Scholar as of the date of this article. This high number of citations reflects the credibility of the methodology. This guide provides support from the initial phase of research identification to the stage of data extraction and synthesis.

A. RESEARCH QUESTION

A SLR should be primarily based on research questions, which bring with them the objectives of the work. Therefore, these questions are of utmost importance to guide the paths that will be taken during the research. The main objective of the SLR was to analyze, in the literature, works related to RPA, its implementation, and GenAI. For such work, the following research questions (RQs) were defined:

RQ1 - What is the procedure for implementing RPA in organizations?

RQ2 - What limitations does RPA face when entering organizational environments?

RQ3 - What countermeasures or strategies to overcome these limitations are proposed in the literature?

RQ4 - Can GenAI be used to overcome the limitations of RPA?

B. SEARCH SCHEME

In the research stage, the keywords of the study were defined. Synonyms of words were also introduced, as well as logical operators ‘‘AND’’ and ‘‘OR’’ to compose the query string, which was:

(‘‘Generative Artificial Intelligence’’ OR ‘‘GAI’’ OR ‘‘GenAI’’ OR ‘‘Generative AI’’ OR ‘‘LLM’’ OR ‘‘Large Language Model’’) AND (‘‘Software robot’’ OR ‘‘Robotic process automation’’ OR ‘‘RPA’’ OR ‘‘RPA lifecycle’’).

The inclusion of the term ‘‘RPA lifecycle’’ in the search string was strategic. Given that RQ1 aims to identify the implementation procedure, ‘‘lifecycle’’ was selected as the representative keyword because it technically encompasses the procedural stages frequently cited in the literature regarding RPA adoption.

This query string was first executed in February 2024 and was completed in August 2025 on the selected databases for the work:

• Scopus: For its broad multidisciplinary coverage and indexing of high-quality articles.

• ACM Digital Library: For being the main repository of the Association for Computing Machinery, focusing on publications in the field.

• IEEE Xplore: For its strong collection of conference and journal papers in the fields of engineering and technology.

• Springer: For its rigorous curation and citation analysis tools.

• SBC Open Lib (SOL) and Scielo Brasil: Brazilian Databases.

In the primary research, 858 works published between the years 2018 and 2025 were found. However, a large portion of the articles found were associated with ‘‘Recombinase polymerase amplification’’ (RPA) and the ‘‘Replication protein A’’ (RPA), topics present in many articles about COVID-19 diagnostics and medicine in general. There were also articles about ‘‘Random-phase approximation’’ (RPA), which is addressed in the field of nuclear physics. Due to having the same acronym as Robotic Process Automation (RPA), they were also collected in the databases reference lists. But, these articles were promptly excluded in the selection stage as they were not part of the research scope.

Secondary research was conducted in parallel with the primary research, which involved checking the references of the articles to identify possible articles relevant to the work but not included in the initial selection due to oversight. This added 12 articles to the work.

After these researchs, exclusion and inclusion criteria 1 were applied, which removed 776 articles. In the end, 94 relevant works were selected for the work.

C. STUDY SELECTION PROCESS

To ensure a refined selection of quality articles for the research, a rigorous application of inclusion and exclusion criteria for articles was conducted (see Table1). Table 2 shows the works selection process in our SLR.

Regarding the time period, no filters were applied based on the year of publication during the search process. This approach was chosen to ensure the retrieval of all relevant studies on our topic. The resulting period for the selected works (2018–2025) reflects the advancement of research on the topic of RPA and AI.

D. DATA EXTRACTION

To compose and substantiate the work, data about RPA and GenAI were extracted from the 94 selected articles. In Figure1, there is a graph of the distribution of selected articles by year of publication.

It can be noticed that the number of relevant publications on GenAI and RPA between the years 2022 and 2023 (see Figure1) experienced a significant leap. This difference could have been caused by the release of ChatGPT, which is a versatile language model capable of generating code, writing stories, and performing automatic translation. The release of ChatGPT sparking numerous studies in the literature, assessing its performance and highlighting limitations and opportunities in its utilization. The number of relevant publications presented by the SLR conclusion suggests that an upward trend of publications may be occurring in the context of RPA and GenAI.

Narrative Synthesis was used to synthesize the extracted data. Data were grouped thematically to answer each research question. The limitations and countermeasures identified were categorized through thematic analysis, allow-ing the construction of a consolidated taxonomy, which will be presented in the results chapter (V).

1) THEMATIC ANALYSIS.

To create the taxonomy of limitations (RQ2), Thematic Analysis was used, following the six-phase protocol proposed by, a fundamental reference for qualitative data analysis. The phases consist of: (i) familiarising yourself with your data, (ii) generating initial codes, (iii) searching for themes,

(iv) reviewing themes defining and naming themes, and producing the report.

1) Data Familiarization: The selected papers were read in.

full, focusing on the results and discussion sections to extract all mentions of RPA limitations and barriers. We emphasize that, although the terms ‘‘barrier’’ and ‘‘limitation’’ may have distinct semantic meanings, it has been noted that in the literature these terms are frequently used interchangeably in RPA studies. To ensure a comprehensive taxonomy, this study treats ‘‘limitations,’’ ‘‘barriers,’’ and ‘‘challenges’’ as syn-onymous concepts, broadly defined as any factor that hinders the adoption, implementation, or operational efficiency of RPA projects.

2) Initial Code Generation: In this phase, labels were.

created for limitations identified: ‘‘Correct choice of process’’, ‘‘Access and Process Security’’, ‘‘Employee Resistance’’, ‘‘Data Incompatibility’’, ‘‘Ethical Lim-itations’’, ‘‘Lack of Knowledge and Experience’’, ‘‘Implementation and Maintenance Cost’’, ‘‘Integra-tion with Systems’’, ‘‘System Design’’ and ‘‘Lack of Documentation’’.

3) Theme Search: After generating the initial codes in.

the previous phase, the third phase of the Thematic Analysis protocol consisted of searching for themes, which would form the basis of the taxonomy. To ensure maximum rigor and systematicity in this process, a semantic clustering analysis was employed. To this end, a code was developed to handle semantic vector-ization and clustering:

Semantic Vectorization (Sentence Embeddings):

The textual labels of the 10 limitations were converted into numerical vectors, which represent their meaning in a mathematical space. For this task, the pre-trained paraphrase-multilingual-MiniLM-L12-v2 model from the Sentence-Transformers library was used. This model, based on the Transformer architecture, is capa-ble of capturing the contextual meaning of sentences, ensuring that limitations with similar semantics result in mathematically close vectors.

K-Means Clustering: Using the generated vector matrix, the K-Means clustering algorithm was applied. The algorithm was configured to group the 10 lim-itations into k=3 clusters. This number was chosen because tests with higher values revealed a significant dilution of related limitations, such as systems design and system integration. However, with a lower number, there were incorrect groupings of limitations such as implementation costs and ethical limitations. K-Means works to minimize the Euclidean distance between vectors, grouping the limitations that are semantically most similar to each other.

Using the generated vector matrix, the K-Means clustering algorithm was applied. To determine the ideal number of clusters (k), we performed an iterative analysis testing values from k=2 to k=5, evaluating the results based on semantic coherence and inter-pretability. The analysis revealed that k=3 proved to be the most stable. Smaller values (k=2) resulted in undersegmentation, merging distinct domains into a single incoherent cluster. On the other hand, larger values (k=4) caused oversegmentation, artificially dividing semantically related technical limitations. Therefore, k=3 was selected as the ideal parameter, as it minimized intra-cluster variance while preserving conceptual boundaries.

Clusters generated: (i) Correct choice of process, Access and Process Security, Implementation and Maintenance Cost, Integration with Systems and Sys-tem Design, (ii) Data Incompatibility, Lack of Knowl-edge and Experience, and Lack of Documentation, (iii) Employee Resistance and Ethical Limitations. Models tested to vectorize the labels: sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 and sentence-trans- formers/bert-base-multilingual-cased, due to their good performance in working with word sentences. Table 3 shows the clusters generated by each model. The segmentation performed by sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 was adopted in this work because it generated more balanced and cohesive clusters. The developed code is available on GitHub.

4) Theme Review: It was verified whether the labels.

within each theme made sense together and whether the themes were distinct from each other, resulting in a cohesive taxonomy.

5) Theme Definition and Naming: Formal names were.

created for each theme: ‘‘Strategic Limitations’’, ‘‘Organizational and Human Limitations’’, and ‘‘Tech-nical Limitations’’.

6) Report Production: This phase was presented in the V.

chapter.

V. RESULT AND DISCUSSION.

Throughout the SLR, we examined and synthesized data on RPA and GenAI from a set of 94 selected articles. With this analysis, our aim was to identify and highlight the most relevant information for our research, particularly those that address our research questions. In this section, the research questions are addressed.

A. THE RPA LIFECYCLE: RESULTS AND IMPLICATIONS -ANSWERING RQ1

In this section we study the results and implications related to RQ1 ‘‘What is the procedure for implementing RPA in organizations?’’

The implementation of RPA in an organization must follow a well-defined flow. Since automation significantly changes process routines, careful attention is needed to execute this automation. In this context, there is the RPA lifecycle, whose function is to oversee the implementation of automation.

In this work, the RPA life cycle was adopted containing 6 phases,,,, because it presents a better division and definition of phases. The phases are (see Figure 2): (i) analysis, (ii) design, (iii) development, (iv) deployment, (v) control and monitoring, (vi) operation and maintenance.

Analysis: The first phase of the lifecycle is the analysis phase, which consists of analyzing which processes are candidates for automation. For example, the task ‘‘The vacations request process starts when an employee submits a vacation request via the ERP system’’, this task involving interaction with the system could be a candidate for automation.

Design: The design phase is where the design of the processes selected in the analysis takes place. This comprises identifying data flows, actions, and everything necessary to execute that process.

Development: The development phase consists of develop-ing each step that will be automated in the process, faithfully following its previously constructed design.

Deployment: The bots developed are allocated to the environments where they will perform the tasks for which they were created.

Control and Monitoring: In the control and monitoring phase, the bots are monitored to measure their performance and effectiveness in carrying out their tasks.

Operation and Maintenance: The last phase of the cycle, operation and maintenance, consists of the continuous evaluation of the bots performance, providing support and applying improvements if necessary.

Based on a lifecycle analysis, we have some strengths and weaknesses to highlight. The inclusion of Analysis as an independent phase prior to Design imposes a mandatory feasibility check, where the suitability of the process is validated. This mechanism directly mitigates the risk of automating the wrong process. The explicit separation between Design (data flow mapping) and Development (coding) allows for the definition of a solution architecture before the start of implementation. This ensures that technical dependencies are mapped before writing the code, avoiding structural improvisations.

On the other hand, like other life cycle versions, in this lifecycle there is an explicit absence of a phase (or sub-phase) to test the bots before Deployment. However, there is the possibility of creating an environment to test the bots before their deployment, this possibility is explored by. Furthermore, the inherent linearity of the sequence Analysis → Design → Development can create a gap between the theoretical definition of the process (Design) and the technical reality (Development). This disconnect can lead to operational failures when bots encounter undocumented exceptions during the Operation phase.

It is important to note that, although many approaches present the RPA lifecycle with different numbers of phases, no consensus regarding this number was found in the literature. Understanding the RPA lifecycle is crucial for the good practice of RPA implementation, ensuring that the process is carried out consistently and efficiently. Reference highlight the importance of correctly dividing the phases of the RPA lifecycle, noting that each phase has different responsibilities and roles within the workflow. This also emphasizes the importance of the organization’s internal structure in the context of RPA implementation.

An analysis of this lifecycle reveals that early phases, such as ‘Analysis’, are predominantly managerial, while later phases, such as ‘Operation and Maintenance’, are more technical. This distinction has direct implications for the types of limitations that arise at each stage, as will be detailed in the following section (V-B).

B. RPA LIMITATIONS AND COUNTERMEASURES: RESULTS AND ANALYSIS - ANSWERING RQS 2 AND 3

In this section we study the results and implications related to RQ2 - What limitations does RPA face when entering organizational environments? and RQ3 - What countermeasures or strategies to overcome these limitations are proposed in the literature?

RPA has been explored in different types of processes, focusing mainly on tasks that involve low complexity processes (processes with few steps and few people involved, for example), based on rules and standardized. However, this technology must be used carefully in organizations because its implementation changes the internal culture, modifying the way the workflow is executed. Even if the correct procedures are followed when implementing RPA, it still faces some limitations (see Figure 3) when entering the organizational environment.

The Figure 3 presents, in a heatmap, the limitations in order of number of citations, their indicators to facilitate in-text reference, and the number of citations that reference each limitation. Based on the analysis of these limitations, and in applying the methodology proposed by, this work proposes a taxonomy for the limitations found (table 4), separating them into three categories: (i) Strategic limitations, (ii) Organizational and human limitations, and (iii) Technical limitations.

This taxonomy shows signs of positive validation, carried out with an RPA specialist who works as an RPA leader in a large cosmetics organization in Brazil, and who followed the results obtained from our research.

To ensure a clear interpretation of the clusters generated by the K-means analysis, we established the following operational definitions and we also present the boundaries between these categories, which align with the observed semantic groupings.

Strategic Limitations: These encompass high-level chal-lenges related to governance, feasibility, and enterprise architecture. This category includes not only business decisions (e.g., Correct Process Choice, Implementation Cost), but also IT structural strategies such as System Design, System Integration, and Security. They are treated as strategic because they define the fundamental environment and feasibility of the RPA initiative. Our model classifies Implementation and Maintenance Cost (L5) and System Integration (L8) as Strategic Limitations due to their direct impact on project viability and ROI. However, they have a strong technical component, cost increases are often driven by technical complexity, and integration failures stem from API incompatibilities. They are ‘‘Strategic’’ in consequence, but ‘‘Technical’’ in nature.

Organizational and Human Limitations: These address the sociocultural limitations within the organization. This category addresses the ‘‘Human Factor,’’ specifically encom-passing Employee Resistance and Ethical Limitations, which dictate the acceptance of the initiative to implement a digital workforce.

Technical Limitations: Refers to the specific operational obstacles encountered during the development and main-tenance of bots. This category addresses problems related to the data and skills required for execution, such as Data Incompatibility, Lack of Documentation, and Lack of Knowledge and Experience. The Lack of Knowledge and Experience (L6) is grouped as a Technical Limitation because it refers to specific coding and architecture skills. However, addressing this limitation requires Organizational interventions, such as hiring strategies and training programs.

Recognizing these intersections and operational defini-tions allows professionals to use the taxonomy as a guiding framework, rather than a rigid classification system.

1) STRATEGIC LIMITATIONS AND THEIR.

COUNTERMEASURES

Before discussing the limitations, it is important to emphasize that their order does not reflect the degree of impact on the organization, but rather merely the quantity of references found in the works selected in this SLR, not implying any order of importance or relevance.

The first category of the taxonomy groups Strategic limitations, which encompasses the high-level challenges related to the fundamental decisions that shape the archi-tecture, governance, and viability of the entire automation program. The rationale for grouping these limitations is that they represent the architectural and governance choices that define the nature and contours of the RPA initiative, going beyond the implementation of a single robot. This group includes Process Selection L1, Access and Process Security L2, Implementation and Maintenance Cost L5, Systems Integration L8, and System Design L9.

These elements were combined because they represent the pillars of the automation strategy: process selection L1 and cost analysis L5 determine value and return on investment, integration and design L8, L9 define the long-term technical architecture, and security L2 establishes the governance policies and risk profile of the program.

a: L1 - CORRECT CHOICE OF PROCESS

Choosing an inappropriate process for automation can lead to a serious failure in the implementation of RPA in the organization. The L1 limitation is one of the most cited and problematic for RPA implementations. Choosing candidate processes for automation requires great care because it is necessary to list selection criteria, such as the level of complexity of that process. And then, after a thorough application of these criteria, the process is chosen.

According to, incorrect process selection is a major cause of failures in RPA projects, resulting in premature deactivation of bots and investment losses. This strategic challenge is corroborated by, who highlight that the effective identification of candidate processes for automation is an obstacle for organizations, especially when relying on manual analysis of textual process descriptions.

Functionally, this limitation arises when RPA is applied to processes that exceed the technology’s capabilities. Refer-ence argues that processes requiring human judgment, exhibiting frequent variations, or relying on unstructured inputs are unsuitable for RPA and prone to operational failures. Similarly, emphasizes that candidate processes should have low cognitive requirements and limited excep-tion handling.

Choosing a very complex process has several implications. The complexity of a process is something very broad and can be measured through a series of characteristics that the process has. For example, the number of tasks, the type of input data, the number of applications involved, complex decision points, etc. Greater complexities result in greater risks and the difficulty of implementation, as there is more at stake if the automation fails

Analyzing the literature, the following countermeasures were identified:

• Process Mining. It is a prominent technique, the idea here is to use process mining to access event logs and from them create process maps, illustrating processes to organizations in a dynamic way, allowing the identification of processes that are candidates for automation, focusing on rule-based procedures with predictable results,, through careful evaluation against predefined parameters.

• Rule-based Robotic Process Analysis (RRPA). Refer-ence presents a method called RRPA, which cal-culates the suitability of a process for automation. The method uses process relevance metrics and automation feasibility to score processes. The authors present an efficiency result of 82.05% in tests.

• Reference propose a robust method for selecting appropriate processes. First, the processes are collected and documented, then the business value of that process is defined (employee satisfaction, time savings, for example). After defining the business value, the process maturity level is assessed using the proposed CMMI-RPA approach, which evaluates processes based on 11 factors and eliminates high-risk and complex processes (rule-based, with few exceptions, using digital data, etc.). If the process achieves level 4 or higher, it is selected for the next phase. The selected processes undergo a quantitative analysis using process mining metrics and a qualitative analysis conducted by domain experts. Finally, a score is calculated for each process, generating a prty ranking.

The same methodology is then applied at a more granular level to prioritize individual tasks within the chosen process, optimizing the automation implementation roadmap.

Although there are approaches and techniques for selecting the best candidate processes, the methods found in the literature generally converge on a ‘‘checklist’’ of ideal charac-teristics: manual, repetitive, rule-based, standardized, mature, low-complexity processes with structured data.

However, the implications of disregarding these criteria go beyond mere technical difficulties, as there are risks. Reference warn that ‘‘wrong process selection’’ is one of the main factors in RPA failure, with 30% to 50% of projects initially failing or facing premature shutdown due to the inability to deliver the expected ROI. Regarding Imple-mentation, choosing complex or unstable processes shifts the burden to the post-deployment phase. Reference note that, for poorly selected processes, maintenance costs often exceed implementation costs. Consequently, processes should not only be selected but also stabilized before automation to avoid negative outcomes. Thus, the trend towards data-driven approaches, such as Process Mining, represents a necessary shift to mitigate these significant risks.

b: L2 - ACCESS AND PROCESS SECURITY

Within organizations, there are processes of all kinds, from simple processes involving the task of filling out spreadsheets to banking processes dealing with sensitive customer data. Each process has its peculiarities and must be thoroughly studied before undergoing automation. The L2 limitation concerns the entire security order protocol and access that bots will have when performing the tasks.

In environments without automation, access to resources and data is managed by humans, but with the advent of bots such management does not occur because the bot is the one that will access the resources and information necessary to perform the tasks. Security must also occur in the physical environment, where security protocols must also be implemented to prevent accidents with human workers.

When a bot lacks adequate security or suffers a secu-rity breach, unauthorized access can occur within these systems, leading to serious security consequences for the organization.

Dealing with any type of data nowadays is something that must be handled carefully so that everything occurs in accordance with laws governing the processing of personal data, such as the General Data Protection Law (LGPD) in Brazil, which regulates any and all handling of personal information in the digital and physical environment. Measures that seek to increase security include: bot activity logs, audits, adherence to security standards, protections against cyber vulnerabilities, strict login and password security policies, and reinforced security on the internal network.

Reddy in 2019, says that a resource coming from the union of RPA and AI is that bots can be suitable alternatives for performing tasks that handle sensitive data. This is because during their development, the bot is configured to follow a well-directed process without inappropriate data collection, deviations, or fraud.

Analyzing the literature, the following countermeasures were identified:

• Reference present in their paper an analysis of RPA platforms that incorporate security features into their development. The authors cite UiPath, Automation Anywhere, and Blue Prism. According to the authors, these platforms manage the security of their bots through role-based access control, data encryption, audit trails, and secure credential storage. These techniques are used to ensure the secure development and execution of RPA bots.

• According to, the limitation of managing security in RPA begins when process control is transferred to a bot, specifically access control, which gives the bot significant power. The authors then cite approaches that can be used to make RPA solutions more secure, including: (i) robust logging and auditing (of changes), (ii) adherence to security standards, (iii) protections against intrusion vulnerabilities, (iv) robust login and password policies, and (v) broader network security. As an additional security measure, the authors also cite that bots should also be able to operate behind locked screens when necessary to ensure the privacy of the data being used in the process.

• On the other hand, according to, the security limitation in RPA manifests itself when bots gain privileged access to multiple organizational systems, creating a new attack surface for cybercriminals and increasing the risk of severe impact if their creden-tials are compromised. The author suggests several countermeasures to mitigate these risks: (i) restricting bots to the principle of least privilege, (ii) ensuring security is part of the scope from the bot’s development stage, (iii) continuously improving security with regular patches, and (iv) verifying the data generated by bots to ensure their integrity. The author also presents a credential management system, which aims to improve security by granting temporary access to bots, automat-ically terminating the session after the allotted time, and providing different, non-reusable credentials for each request.

Additionally, this system should maintain detailed records of all activities for audit purposes.

• According to, when integrating RPA with GenAI and the Internet of Things (IoT), data security and pri-vacy limitations are magnified, involving risks such as unauthorized access to sensitive production data and the protection of customer information. The authors empha-size that addressing these risks fundamentally depends on strategic planning and well-defined governance. The suggested countermeasures are: (i) the use of encryption techniques to secure communication between systems; (ii) the application of anonymization techniques to protect the privacy of customer and shipping data; (iii) strict adherence to data protection regulations; and (iv) ensuring transparency by obtaining individuals’ consent for data collection and informing them when interacting with AI systems. Governance, in turn, must establish clear guidelines for the responsible handling of data at all stages.

The diversity of proposed countermeasures, ranging from platform features to governance policies, indicates that security in RPA is also a complex issue. The security cannot be an afterthought, but rather a central pillar of the automation strategy, which requires governance practices that treat bots as digital identities that must be rigorously managed.

c: L5 - IMPLEMENTATION AND MAINTENANCE COST

RPA presents cost reductions for organizations through the reduction of manual work, but this reduction is perceived in the medium to long term. The cost (L5) of an RPA implementation and configuration can be expensive and can hardly be measured at the beginning, since the value can vary greatly considering that each organization will have different procedures and applications, which will require a customized implementation for each organization for better efficiency, and this will imply different costs.

An initial cost implication is that the workflow to be automated needs to be presented to the bot, and this requires a trained expert to map the workflow, develop the bot, and integrate it with the organization’s infrastructure. Another initial cost will also be to train employees so that they understand and learn how to work with automated processes.

An important point about RPA implementation is that once bots are in operation, this does not mean that the RPA lifecycle is over. This cycle is iterative because the bot needs to be monitored for maintenance and necessary updates. This can be costly for organizations, depending on the complexity of the automated process and the size of the updates required to keep the bot running.

Updates must occur whenever the process or business rules undergo any change, since the bot script is designed to perform a task in the as-is model, as the process is at that moment, but if it undergoes changes, it is also necessary to update the bot script.

Analyzing the literature, the following countermeasure was identified:

• Less complex processes. Correctly implementing RPA reduces costs, but in the long term. Therefore, what can be done is to make this investment efficient, knowing how to apply it in the best way. This can be done by avoiding overly complex and difficult-to-automate processes, which, in addition to consuming a lot of resources, also consumes a lot of time. Therefore, it is essential to identify the appropriate processes for automation. It’s important to choose less complex processes for automation, as they are simple enough for bots to be implemented quickly. A highly complex process can increase operational costs and potentially lead to process interruptions. Using RPA tools, which enable rapid development and implementation, is a good option that helps organizations reduce costs.

The countermeasure of focusing on less complex pro-cesses, while pragmatic, reveals an inherent tension in RPA: the desire to automate high-impact processes versus the reality that these are often the most expensive and complex to implement and maintain. This suggests that the strategic value of RPA may be limited if the organization cannot evolve to more sophisticated automation in a cost-effective manner.

d: L8 - INTEGRATION WITH SYSTEMS

It is common for processes to have tasks that are executed in different software or systems. In these cases, it is important that the bot has the ability to deal with changes in systems, changing its use as necessary. However, there are still cases where the organization uses legacy systems,, which often have depreciated functions and navigation, making it difficult for the bot to perform actions efficiently, requiring customized solutions for this task.

Another factor that hinders the integration between sys-tems and software is that there may be cases where the data that needs to be shared between systems during the process is not compatible and is not standardized, a fact that meets the limitation already mentioned L4, highlighting the importance of having standardized data in processes.

Analyzing the literature, the following countermeasures were identified:

• Integration with existing systems is something that needs to be explored before integrating RPA into the organizational environment. Reference present a possible countermeasure to address this limitation: Creating better standardization and compliance with these standards. Standardization will ensure that, during bot development, the bot knows what to expect from the systems, and provides additional assurance that the system follows a defined standard and will not undergo changes that alter the way the bot is integrated into the system.

• To handle interface changes between systems, inte-grating AI and Machine Learning (ML) with RPA proves to be an excellent option. The use of these two technologies helps the bot interpret changing interfaces.

However, systems change, and this can affect how the bot is integrated, even if it’s not the organization’s intention. Whether due to optimization or market pressure, the organization may be forced to change its systems. To achieve this, contingency measures must be implemented so that the bot’s development can adapt to that change. This must be presented and supported by RPA Governance. This governance is extremely important for the organization to achieve RPA maturity. In this contingency measure, the organization can, for example, allocate resources for possible bot modifications and also establish process adaptation protocols, ensuring that the changes do not affect the organization’s internal rules.

The suggested countermeasures expose a major weakness of RPA: Standardization is often impractical, especially with legacy systems. The suggestion to use AI/ML again reinforces the conclusion that RPA alone is insufficient to deal with the dynamic nature of modern IT environments, requiring an additional layer of intelligence to be truly robust.

e: L9 - SYSTEM DESIGN

The bot is trained to imitate human actions through clicks and keyboard inputs, for example. To do this, the typing fields and click action buttons must be legible and well arranged in the design of the interface of the system where the bot is operating. This is important because during the development of the bot it is custom developed for each system, it learns to perform its tasks using the current structure of the system, location of buttons for example. If the design of the system changes, it is necessary that the bot is also updated to match the system.

Therefore, if a bug occurs in the design and the buttons are out of position or undergo an unscheduled change, the bot may fail. In the same way, if the system has a verification captcha, the bot is not able to bypass this verification. If the process has such a verification measure, the bot’s execution would be impaired. Studying interactions with Graphical User Interface (GUI) design is challenging, but important for validating RPA solutions.

Analyzing the literature, the following countermeasures were identified:

• Proactively use Process Mining in the analysis phase to discover variations and exceptions from the actual process, ensuring that the robot is designed with a more complete understanding of the workflow.

• Adoption of a software engineering approach to robot development and maintenance. The systematic review of identifies ‘‘Development’’ and ‘‘Maintenance and Error Handling’’ as recurring limitation themes in the literature. In practice, this translates into counter-measures such as modular design to manage complexity, that is, the software should be logically partitioned into elements or subsystems, the creation of resilient UI selectors to combat fragility, and the implementation of exception handling frameworks to handle failures in a structured manner.

The analysis of countermeasures for fragility is particularly revealing. They indicate that the literature proposes mitigat-ing the problem on two fronts: proactively, in the analysis phase, using Process Mining for a more accurate mapping of reality, and during development, with the adoption of robust Software Engineering principles, such as modular design, to create more resilient robots. However, it is crucial to note that these strategies, while representing the field’s maturity, are essentially palliative. This reinforces the idea that there is a limit to the resilience of traditional RPA and points to the need for a new class of solutions that can handle change more dynamically and intelligently, rather than simply guard against it.

The prominence of these limitations in the literature suggests that many RPA project failures occur before development even begins, fundamentally resulting from flaws in business analysis and strategic planning. Difficulty selecting appropriate processes (L1) and predicting the total cost of automation (L5) indicates a maturity gap in how organizations approach automation, often treating it as a purely technical solution and underestimating the complexity of feasibility analysis. This limited vision extends to the lack of robust architectural and governance planning. Critical decisions about system integration (L8), system design (L9) to ensure scalability, and defining access and process security policies (L2) are often overlooked, creating a shaky foundation for automation.

Taken together, these findings demonstrate that without a solid strategic foundation that includes business viability, technical architecture, and security governance, a robot’s technical success becomes irrelevant because it may be automating the wrong process, insecurely, and at an unsustainable cost.

2) ORGANIZATIONAL AND HUMAN LIMITATIONS AND THEIR.

COUNTERMEASURES

The second category focuses on Organizational Limitations, which encompass the sociotechnical and cultural challenges that emerge from the interaction between the digital work-force and the organization. This category groups the factors that determine the company’s ability to absorb and sustain the change introduced by RPA, with a focus on the impact on people. Included here are Employee Resistance L3 and Ethical Limitations L7. These two challenges were grouped together because they represent the human capital and social responsibility capital that the company needs to manage. Resistance L3 addresses the internal acceptance of the technology, while ethical limitations L7 address its acceptance and its external and social impact, both crucial to the initiative’s legitimacy and success.

a: L3 - EMPLOYEE RESISTANCE

The L3 limitation may occur even before starting the implementation of RPA in the organization. Employees who perform tasks that are suitable for automation are afraid of losing their jobs and then oppose that implementation. In these cases, changes in the company’s strategic manage-ment may be necessary, since automation will change the culture that the organization has. This limitation is quite delicate because it involves cultural issues within the organization as well as psychological issues on the part of the employees.

Analyzing the literature, the following countermeasures were identified:

• There are works that study how to mitigate this resis-tance on the part of employees when also implementing BPM in their workflow. Reference conducted a study on resistance to change in the implementation of BPM in the Brazilian market. The work data were obtained through 113 questionnaires applied. The study revealed that the criterion that most affects employees’ resistance attitudes towards the implementation of BPM is trust in management. The authors point out that leaders and BPM implementers must invest in skills such as: clarity in defining objectives, communication, negotiation, and closer relationships with employees, in order to promote opportunities and mitigate employee resistance.

• This clear definition of objectives can be implemented by establishing governance, which should occur before implementing RPA. According to, in the con-text of technology incorporation, governance plays a fundamental role. Governance structures assist in recognizing, assessing, and addressing risks associated with technology integration. These risks may involve data protection, addressing privacy issues, mitigating potential system failures, and complying with legal requirements, as well as the cultural change that will occur within the organization and impact employees.

• Cultural resistance to change arises due to a lack of knowledge and experience with this software, which is why effective communication presents itself as an excellent solution to mitigate resistance as it allows the organization to achieve internal synergies, manage expectations and mitigate resistance.

The emphasis on management and communication coun-termeasures positions RPA adoption not just as an IT project, but as an organizational change management initiative. From the analysis of limitations and countermeasures, it is clear that failure to address the human aspect of automation is a primary cause of failure, regardless of the robot’s technical quality.

Analyzing the literature that addresses limitation L3, it becomes clear that this limitation is rooted in employees’ psychological response to automation, and not just in techni-cal skepticism. The literature indicates that the main factor of resistance is anxiety regarding job loss and the ethical implications of replacing human labor with algorithms,, which take the form of bots. As observed by Pereira et al., the ‘‘human factor’’ remains the most critical determinant for successful implementation, without initial acceptance, employees often see bots as intruders, leading to a lack of cooperation that Costa et al. identify as a failure in preparing the organizational culture. This resistance is more intense when the intention of automation is not clearly communicated by management, allowing rumors of layoffs to obscure the advantages that RPA can bring to productivity.

To address L3, the countermeasures advocate a paradigm shift, moving from passive user training to an active workforce transformation. Reference argue that skills enhancement and reskilling programs are not optional add-ons, but essential prerequisites, enabling employees to transition from task execution to higher value-added roles for the organization, such as bot supervision and exception handling. Furthermore, suggest reframing this context: instead of focusing on cost reduction, organizations should demonstrate how RPA eliminates repetitive ‘‘wasteful’’ tasks, thus augmenting human capabilities rather than replacing them. This holistic approach to Change Management— combining cultural preparation, transparent and effective communication about job security, and concrete career plans—is cited as the best strategy to convert resistance into active adoption.

b: L7 - ETHICAL LIMITATIONS

The L7 limitation is quite delicate because it deals with the organization’s ethical concerns. This occurs because often when acquiring a bot on an RPA platform, the organization does not have much access to its development, it comes ready for installation. Thus, there are concerns about the internal rules for executing this bot, when dealing with sensitive data, for example, in a certain process that requires access to customers personal information. There are many ethical implications when dealing with a bot impersonating people. There are studies that present the adaptation of GenAI in this context, to introduce aspects of morality to the machine.

Analyzing the literature, the following countermeasures were identified:

• To overcome ethical limitations, guidelines must be developed to ensure the responsible deployment of tech-nologies, such as RPA. In this regard, transparency and disclosure play a crucial role. During customer interactions with bots, customers should be informed that they are interacting not with humans, but with bots. This transparency gives customers knowledge and clarity about the nature of their interactions.

• Another important point is data privacy. Proper handling and analysis of customer data must comply with data protection regulations. The objective is to protect sensitive information and ensure customer privacy is respected.

These countermeasures focus primarily on transparency and compliance with existing regulations. This indicates that the ethical discussion in RPA literature is still at the ‘‘best implementation practices’’ stage, rather than a deeper questioning of the limits of automation and the nature of decisions that can be delegated to software.

Analyzing this category of limitations highlights that RPA adoption is fundamentally a sociotechnical and change management initiative. The literature suggests that ignoring human and governance factors is a key reason why technically successful pilot projects fail to scale across the organization. In this context, Employee Resistance L3 emerges not as a simple obstacle, but as a symptom of an implementation that failed to communicate and manage team expectations. Similarly, Ethical Limitations L7 emerge when automation is introduced without clear guidelines regarding its responsibil-ities and its impact on both internal and external stakeholders. This reinforces the idea that RPA’s success depends less on the perfection of the robot’s code and more on the organization’s preparedness to welcome it responsibly and collaboratively.

3) TECHNICAL LIMITATIONS AND THEIR.

COUNTERMEASURES

Finally, the third category of the taxonomy addresses Technical Limitations. This group differs from the Strategic category by focusing not on architectural decisions, but on the quality of the inputs and prerequisites required for development and implementation. The logic behind this grouping is that these three elements are the developer’s ‘‘raw material,’’ and a failure in any of them directly compromises the technical execution of the project. These include Data Incompatibility L4, Lack of Knowledge and Experience L6, and Lack of Documentation L10. To build a functional robot, a development team needs three essential inputs: quality data to process L4, clear instructions on what the process does L10, and the technical knowledge to perform the work L6.

a: L4 - DATA INCOMPATIBILITY

In general, bots perform well with tasks where the data is structured. However, they may have difficulty dealing with unstructured or semi-structured data, such as text extracted from scanned images or complex documents. The success of RPA depends heavily on the quality of the input data, which must consist of structures, with no exception of null values.

Analyzing the literature, the following countermeasures were identified:

• One way to deal with data incompatibility is to use Optical Character Recognition (OCR), which allows the bot to handle more complex tasks that require extracting information from images or documents,,,, in addition to also allowing analysis and extraction even from low-quality documents.

• Another solution found in the literature is the Agentic AI, which refers to AI systems capable of making decisions and performing actions at multiple levels to achieve a user’s goal, with limited supervision. These systems are capable of coordinating multiple agents, each performing a specific task, orchestrated and aligned with the goal. In short, an agent is a system that senses its environment, decides what to do, and takes action to achieve a goal. Reference presented a study in which agentic AI systems were integrated with RPA and demonstrated remarkable capabilities in independent decision-making and process optimization. These next-generation systems, called Agentic Process Automation (APA), demonstrated a 40– 60% reduction in manual intervention requirements in complex workflows.

It is clear that the main countermeasures to the L4 limita-tion involve the use of other technologies (OCR and AI). This demonstrates that RPA, in its pure form, is fundamentally limited in this regard. The literature implicitly acknowledges that, to overcome the unstructured data barrier, RPA needs to evolve into a form of Intelligent Automation.

b: L6 - LACK OF KNOWLEDGE AND EXPERIENCE

The L6 limitation can occur both on the organization’s side and on the employee’s side. If the implementation of RPA is something new for the organization, it will initially encounter many doubts about how the implementation should occur and also how to conduct post-automation processes. On the employee’s side, this can also occur because they will not yet know how to behave when participating in an automated process, because even if the bot performs tasks, it still requires human monitoring, checking compliance, making decisions, etc. It is possible to notice that limitations L3 and L6 are intrinsically linked, as the lack of experience can lead to resistance to accepting this new culture.

Analyzing the literature, the following countermeasure was identified:

• To address the lack of knowledge and experience, employee qualifications through training are necessary. Training is a recurring feature of successful RPA imple-mentations, ensuring employees understand and work with RPA. It focuses on good communication between process specialists and RPA developers, standardizing data and tasks, and creating backup strategies for potential automation failures. This training should be provided in the initial implementation phase to ensure a smooth transition for employees during this integration. Organizations can explore employee skill development programs; these programs have economic, social, and individual benefits for both the organization and the employee.

Once an organization is starting its RPA integration from scratch, it is important to document the entire process so that this information serves as a basis for future implementations and provides insights for dealing with failures and setbacks arising from an implementation.

The emphasis on training and capacity building as a countermeasure reveals that RPA is not a ‘‘plug-and-play’’ solution. The technology requires a medium to long-term organizational investment in building new skills, suggesting that successful automation depends on building an internal culture and knowledge base.

c: L10 - LACK OF DOCUMENTATION

The lack of process documentation (L10) can cause count-less other problems for the organization, not only in the implementation of RPA, such as affecting the discovery of processes for automation (L1) and also harming the documentation of important information about the process such as types of data used (L4) that the process uses in its execution. Cases where the lack of documentation is evident are when adopting new software, in which cases the organization needs to document from scratch the process and usage standards of that software. Interest in automation is relatively recent, so there is a lack of awareness and basic knowledge about RPA implementation, resulting from the lack of theoretical foundations that allow objective reasoning and development of methodologies for RPA.

Analyzing the literature, the following countermeasure was identified:

• RPA platforms. To overcome this limitation, organizations must seek out established solutions in the market, such as well-known RPA development platforms, which have proven success stories and can guide organizations in their implementations. Organizations must carefully document their integrations so that this serves as a basis and reference for any potential needs regarding the integration and use of RPA in internal processes. With adequate information, organizations can create their own RPA integration guide, managed by their governance, which will serve as the basis for all implementations. Documentation is a basic and necessary ingredient in the context of process automation.

Taken together, these technical limitations reveal a fun-damental truth about RPA: the quality and robustness of a robot are a direct reflection of the quality of the organizational inputs and knowledge available for its development. Technical flaws, therefore, often originate not in the code itself, but in the raw materials used. A poorly documented process (L10) leads to an incorrect automation scope, data incompatibility (L4) forces the creation of complex and fragile exception handling logic, and a lack of knowledge and experience (L6) within the team results in an inefficient and difficult-to-maintain system design. This cluster suggests that RPA’s ‘‘technical’’ limitations cannot be resolved with the best programming practices alone.

They expose a deep dependence on process maturity and organizational capabil-ities, indicating that technical excellence in automation is unattainable without a solid foundation of documentation, data, and knowledge.

The in-depth analysis of the limitations and their respective countermeasures presented in this section paints a clear picture of the limitations that permeate the implementation of RPA in organizational environments. The taxonomy developed reveals that the obstacles to successful automation are not purely technical; they are equally, and perhaps more impactfully, rooted in strategic planning issues and organizational and human complexities. From the wrong process choice (L1) to employee cultural resistance (L3) and a lack of internal knowledge (L6), it’s clear that RPA implementation is an initiative that requires high management, governance, and process maturity, long before it becomes a software limitation.

Additionally, the nature of the traditional countermea-sures identified in the literature is particularly interesting. They largely consist of applying greater managerial rigor (governance, change management), better and more dis-ciplined software engineering practices (modular design, resilient selectors), and proactive analysis strategies (process mining). While arguably essential, these solutions share a common characteristic: they are mostly palliative. They aim to mitigate the symptoms of RPA’s fragility and lack of contextual intelligence, rather than addressing the root cause of the problem. They require more human effort, more planning, and more rework to implement an inherently rigid technology to operate in a dynamic business environment.

This finding leaves a fundamental question open: do current countermeasures represent the ceiling on process automation’s capabilities, or is there a new technological paradigm capable of addressing these fundamental limita-tions in a more direct and transformative way? Rather than simply building more robust robots to navigate a fragile environment, would it be possible to create robots that understand and adapt to this environment? To answer this question, the following discussion will delve deeper into the analysis of Generative AI as the next evolutionary stage in process automation.

To conclude Section B, we will present, in summary, a mapping of the identified limitations for the RPA lifecycle phases (defined in RQ1) where they predominantly occur:

• Analysis and Design: These preparatory phases deter-mine the project’s feasibility. The Analysis phase is cru-cial for addressing L1 and estimating L5. Subsequently, the Design phase must resolve architectural constraints, specifically L2, L8, and L9, ensuring that the solution is feasible before coding begins.

• Development: During bot construction, specific execu-tion barriers arise. L4 and L6 directly hinder the script creation process. Furthermore, L10 is a critical obstacle in this phase because, given the absence of clear process definitions, precise development is impeded.

• Deployment, Operation, and Maintenance: The final stages focus on the interaction between the digital and human workforce. L3 and L7 typically manifest during Deployment and persist during Operation as employees adapt to the new workflow. Finally, the challenges related to L5 and continuous documentation updates are fundamental to the sustainability of the Operation and Maintenance phase.

C. GENAI AS A NEW COUNTERMEASURE PARADIGM -ANSWERING RQ4

In this section we study the results and implications related to RQ4 - Can GenAI be used to overcome the limitations of RPA?

The analysis of the results presented in the V-B section presents a clear outlook: although RPA is a high impact technology, its path presents strategic, organizational, and technical limitations. The investigation of the countermea-sures presented in the literature revealed that they are largely reactive or palliative. Practices such as adopting better governance frameworks, focusing on effective change management, and applying software engineering principles to robot development are crucial to mitigating the symptoms of problems. However, they do not address the root cause of many of the limitations, especially the inherent fragility of GUI-based automation. This finding points to a ceiling in the capabilities of traditional RPA and the need for a new solution paradigm, one that can endow automation with cognitive and adaptive capabilities.

Addressing this gap, this work answers its fourth research question, positioning Generative AI as this new paradigm. The capabilities of LLMs, presented in the II-B chapter and in the 4 image, offer a set of cognitive tools that can be directly mapped to the categories of limitations identified and presented in the V-B section.

For strategic limitations, Generative AI offers solutions that improve the architecture, governance, and feasibility of RPA projects. Planning challenges such as L1 and L5 can be mitigated, as an LLM can pre-assess a process’s com-plexity and business alignment based on textual descriptions. Regarding architecture, Generative AI can directly address the challenges of L8 and L9. The ability to generate code opens the possibility for the creation of ‘‘self-healing bots’’: a bot that, upon encountering an interface error, could consult an LLM to analyze the problem and generate a suggested fix in real time. Additionally, for L2, Generative AI can be used to generate security policies, create test scenarios for vulnerabilities, and monitor logs for anomalies, strengthening digital workforce governance.

Regarding organizational and human limitations, Genera-tive AI can serve as a tool to improve change management and the social responsibility of automation. The limitation L3, often fueled by fear of the unknown and a lack of clear communication, can be mitigated by using Generative AI to create personalized training materials and interactive simulations that demystify technology and demonstrate its role as a tool to assist, not replace. Additionally, when addressing L7, the summary and explanation capabilities of LLMs can be used to increase the transparency of automated decisions. Generative AI can generate plain-language reports that explain why a robot made a particular decision, a fundamental step toward more ethical and responsible governance, although human oversight remains essential to ensure accurate and impartial analysis.

In terms of technical limitations, Generative AI also proves useful. Data Incompatibility L4, especially with unstructured sources, is directly addressed by the Natural Language Understanding capabilities of LLMs, which can read, inter-pret, and structure information from emails and PDFs. Additionally, L10, a chronic bottleneck that compromises development quality, can be overcome by automatically generating the first version of a Process Design from a simple textual description or a recording of the process. Finally, L6 is mitigated by Generative AI ability to act as a ‘‘co-pilot’’ for developers, generating code skeletons, explaining complex APIs, and accelerating the learning curve of the technical team.

In short, Generative AI positively answers the fourth research question of this work. Generative AI can be used to overcome the limitations of RPA and has the potential to rede-fine the way process automation is performed. The synergy between the two technologies represents a fundamental tran-sition from ‘‘task automation’’ to ‘‘knowledge automation’’. The focus shifts from simply replicating human interactions with the system interface to automating the understanding, reasoning, and communication that are part of the process of executing these tasks.

By equipping the RPA digital agent with the ‘‘digital brain’’ of Generative AI, this new form of Intelligent Process Automation mitigates the chronic problems of fragility and dependence on structured data, also presenting a new range of possibilities for the automation of more complex, dynamic and higher value-added business processes, shaping the future of work in organizations.

In the Figure 4 there is a table with a heatmap showing the number of citations that each GenAI capability found has in the literature. In the Table 5 there is a summary of all the references that cite the capabilities of GenAI.

GenAI, based on its capabilities (see Figure 4), can be applied to all six phases of RPA as well as the limitations of RPA. Each phase of RPA has a different execution character, but all have activities that can be driven by a GenAI model, such as document analysis, script writing, report analysis, and improvement suggestions based on the analysis of some documents:

• Analysis: This initial phase of the RPA lifecycle often involves studying many documents related to the company’s processes. Effectively identifying processes and tasks that are suitable for automation is a limitation for RPA,,,, and it is at this stage that it occurs. Analysts may spend a lot of time identifying and analyzing processes suitable for automation. Unfortunately, this phase receives little support from RPA tools. In this context, the alternative is to use GenAI models in two different ways: (i) By taking the large volume of text found in process documents as input and generating summaries and insights about the processes described therein as output. (ii) By identifying processes, analyzing documentation existing in the organization, and then generating a more comprehensive output for the analyst.

• Design: LLMs can be used in process modeling to enhance flexibility, efficiency, and accessibility by gen-erating process models from textual descriptions. In the Design phase, an alternative is to use the LLM to generate the Extensible Markup Language (XML) script for a process model from a textual description of the process as input, and then use the generated XML in a process modeling tool. There are works that explore the use of LLMs in this context. Li and Toxtli present an analysis of ChatGPT 4o in the creation of XMLs for Camunda, a popular process modeling platform. The authors present promising results for LLMs for modeling valid and readable processes in basic and intermediate scenarios. Limitations arise in scenarios where processes are more complex, particularly in terms of completeness and correctness of arrows.

This approach would significantly enhance productivity in developing a process model, as the interpretation of the description is handled by the LLM. Currently, many design tools already incorporate AI to assist engineers and designers, facilitating the execution of complex tasks.

• Development: Today, tools that interact with LLMs, such as ChatGPT, are commonly used to work with code generation,. Siderska, Aini and Kedziora present a case study where ChatGPT was used to improve the efficiency of the programming team at an RPA solutions development company. The alternative to using LLMs in this phase is to employ them as an extension of the human programmer, assisting the developer in formatting and structuring code, as well as implementing parts of the code. But it is important that there is still human oversight to check the code, ensuring that the model can capture and follow best practices in coding and optimization.

• Deployment: In this deployment phase, this work proposes the alternative of using the LLM model to generate scripts that automate the deployment of a bot in its execution environment. To provide context, White et al. present an example. In the example, the LLM is asked to question the user about how to deploy a Python application in an Amazon Web Services (AWS) environment. As the user responds, the LLM acquires the necessary information for the deployment, and finally, it is asked to create a script to automate this deployment. The same can occur in the deployment of an RPA bot, where the user, an RPA professional with experience in bot deployment, provides the LLM with the correct instructions for the deployment, resulting in an automated script for this task.

It is necessary that the person overseeing the deployment phase has the required knowledge and expertise to guide the LLM with the correct information so that the integration can be efficient.

• Control and Monitoring: This phase is typically semi-automated, with analysts monitoring the bot through an RPA tool dashboard. In the BPM lifecycle, LLMs can be used for process monitoring,, in the RPA context, LLMs can also play a role in monitoring automated processes. LLMs work very well with extensive information. So, the alternative is to use an LLM to receive a report from the RPA tool containing information about the bots execution and then provide insights, for example, about possible bottlenecks occurring during the operation of the bot. The LLM would eliminate the intermediate step of the analyst having to access dashboards to get an overview of the process and would allow the user to directly know the status of the processes.

• Operation and Maintenance: Like the phase of Control and Monitoring, this one is typically semi-automated as well. The alternative in this phase is to provide the LLM with prompts containing information, such as guidelines for the execution of the process, so that the LLM can identify quality issues and suggest corrections for the process. Based on this, the user can also ask the LLM for ways to implement the suggested corrections by presenting different scenarios. Since it’s a phase of continuous monitoring aimed at improving the bot, it’s a process that can consume a lot of time for those involved. Therefore, having an LLM trained to assist could be beneficial.

In order to fully leverage the use of LLMs, it is necessary to know how to work with prompts. Effective prompts can have patterns and even be reused for various purposes. Prompts also enable the LLM to achieve higher accuracy, creating the desired and correct content for the user.

The table 6 summarizes the applications of Generative AI in the phases of the RPA life cycle. In this table, the uses of Generative AI were classified as Empirical: for those uses for which we found real-world evidence with tests and/or case studies in articles, and Conceptual: for those uses for which we did not find evidence, but whose use in another similar field was identified, presenting itself as a possible use for RPA as well.

What is evident from current contributions in the literature is that generative AI offers significant potential as an auxiliary tool to address the limitations of RPA. Currently, there is increasing attention on AI-based software that includes AI resources within its layers to assist users during application use. These software solutions are becoming increasingly well-structured, and as AI learns from each user interaction, they become more adapted and personalized for specific uses. AI-based software is setting new precedents for software development. Reference emphasize that the quality of AI-based software should be approached differently compared to traditional software, as it generally deals with distinct and more complex types of problems.

D. THE INFLUENCE OF CONTEXT AND ORGANIZATIONAL MATURITY

RPA implementation presents various limitations within the organizational context. These limitations evolve significantly depending on the maturity of an organization or sector regarding experience in RPA adoption. The literature shows that the limitations faced during RPA pilot implementa-tions differ substantially from those found in large-scale implementations, and regulatory constraints shape distinct priorities across industries.

Regarding organizational maturity, the transition from an initial phase to a mature Center of Excellence (CoE) shifts the focus from technical problems to issues related to governance and sustainability, topics of extreme interest today, in a study in the accounting sector, highlight that while immature organizations struggle with workforce acceptance and technical feasibility, mature organizations face complex challenges in IT governance and long-term system sustainability. Emphasizing this point, point out that scalability becomes the central bottleneck as the organization seeks to expand the use of RPA beyond simple rule-based tasks.

Regarding the sector segment, in the highly regulated banking sector, points out that the initial limitations are not only technical, but also encompass design risks, compliance, and interaction with legacy systems. In contrast, sectors such as retail face more pronounced economic barriers. Reference indicate that, in retail, in early adoption stages, the complexity ofcost savings often stems from underestimated hidden costs—such as infrastructure setup, user rights management, and testing—rather than just development effort.

Furthermore, motivations alter the workforce’s perception of limitations. Reference present an empirical compar-ison: while in the financial sector RPA is more associated with cost reduction and ‘‘staff reduction’’—which often generates resistance and fear of job loss—in the public and healthcare sectors, the technology is seen as a tool to improve service quality and patient safety. In these regulated sectors, RPA frees up human resources from administrative tasks so they can focus on essential activities (such as patient care), which significantly reduces barriers to internal adoption. Therefore, it is possible to conclude that organizations should not necessarily follow a single implementation strategy, but rather adapt to specific regulatory pressures and maturity.

The potential of GenAI is undeniable, however, for its implementation to be meaningful within the limitations of RPA, attention must be paid to some organizational and technical points.

Unlike traditional RPA, which requires logical and struc-tured programming, GenAI solutions demand competence in Prompt Engineering. Reference identify this skill as a new competency, arguing that the quality of the bot’s output—whether in code generation or log summarization— depends on the operator’s ability to create precise and con-textualized prompts. Organizations should invest in training developers to master these interaction patterns.

The integration of LLMs introduces risks of data exposure. As highlighted by, the reliance on publicly available, closed-source models creates risks of ‘‘data contamination,’’ where sensitive corporate data can leak into training sets. Therefore, in this context, it is necessary to have a governance layer or access to exclusive and official versions of the models, ensuring data protection.

E. BUSINESS IMPACT AND SEVERITY OF LIMITATIONS

To address the practical implications of the identified limitations, we analyzed the impact associated with the most critical limitations. While aggregated financial data is scarce in the literature, we identified specific instances of failure rates, cost implications, and delays in the primary studies:

• Critical Impact (Project Failure Rates): Limitations in Correct Choice of Process (L1) are the pri-mary driver of failure. Seminal studies indicate that a significant portion of RPA projects fail to scale beyond the initial proof-of-concept due to poor process selection. Selecting unstable processes leads to high volatility; for instance, Morelli reports bots crashing simply due to unexpected ‘‘MS Teams pop-ups’’ or resolution changes, requiring constant restart and monitoring.

• Financial Implications (Hidden Costs): Implementa-tion and Maintenance Cost (L5) often exceeds initial estimates due to ‘‘hidden’’ infrastructure demands. Morelli provides a breakdown of these often-overlooked costs, including ’’license costs for bot users, setting up virtual machines, and managing SAP user rights’’, which extend beyond mere development time. When these costs are not factored in, the ROI calculation

(typically based only on hours saved) becomes invalid, turning the asset into a liability.

• Implementation Delays (Time-to-Value): Operational limitations cause measurable delays. While coding a bot might take only ‘‘1 to 3 days’’ as noted in retail case studies, the associated testing and stabilizing phases can take weeks. Morelli highlights that ’’two weeks of testing’’ were required just to fix basic stability issues. Furthermore, Employee Resistance (L3) and Access and Process Security (L2) can halt deployment indefinitely if IT departments perceive the bots as ‘‘Shadow IT’’ risks, forcing a rollback of developed solutions.

This data suggests that while the technical construction of a bot is fast, the organizational limitations (L1, L2, L3) introduce delays and costs that significantly distort the projected Time-to-Value.

We recognize that the application of GenAI in RPA is a rapidly evolving field. While the identified countermeasures offer significant potential, many are currently supported by theoretical proposals and early proofs of concept, rather than large-scale industrial validations. Future maturity in this domain will likely bridge the gap between these proposed capabilities and their widespread practical implementation.

VI. CONCLUSION.

This work began by investigating the paradox of RPA, a rapidly adopted technology that faces significant imple-mentation and scalability limitations in organizational envi-ronments. Through an SLR, it sought to answer four central research questions: RQ1 - What is the procedure for implementing RPA in organizations? RQ2 - What limitations does RPA face when entering organizational environments? RQ3 - What countermeasures or strategies to overcome these limitations are proposed in the literature? and RQ4 - Can Generative AI be used to overcome the limitations of RPA?

In response to RQ1, the RPA lifecycle was identified and presented, a six-phase lifecycle that serves as a guide for implementing the technology. In response to RQ2, 10 limitations faced by RPA were identified and cataloged, with the correct selection of the process to be automated being the most cited. RQ3 allowed for the compilation of countermeasures proposed in the literature to mitigate RPA’s limitations, such as the correct choice of the process to be automated, security and access to data in automated processes and data incompatibility. RQ4 investigated the potential of Generative AI as a new countermeasure paradigm.

The discussion demonstrated that GenAI’s capabilities not only offer palliative solutions but also address the root cause of many of RPA’s limitations, especially those of a technical nature, such as the weakness of robots in handling system integration and system design, and the difficulty with unstructured data.

Thus, the main contributions of this work are: (i) A consol-idated taxonomy of RPA limitations, classifying 10 identified RPA limitations into strategic, organizational/human, and technical categories, which provides a clear map of the problem space. (ii) A prospective analysis that maps Genera-tive AI capabilities (e.g., code generation, natural language understanding) as solutions to the identified limitations, proposing a transition from ‘‘task automation’’ to ‘‘knowl-edge automation’’. (iii) This work serves as a foundation for future work on measuring organizational maturity in RPA implementation, and also presents a taxonomy and conceptual basis for RPA limitations, which can be studied to develop an instrument that highlights an organization’s level of RPA implementation maturity.

A. RISKS AND LIMITATIONS

The limitations of this work are acknowledged and presented here. One limitation is the rapid evolution of Generative AI, since it advances at an exponential pace, with new models and capabilities constantly emerging. One limitation of this work was to consolidate an analysis of a technology that is still in full development. To mitigate this limitation, the focus was maintained on the fundamental and already established capabilities of Generative AI, rather than on specific products, ensuring that the conceptual analysis remains relevant.

Another limitation of this work, which used the SLR protocol to achieve its objectives, is publication bias and search scope. SLRs are subject to potential publication bias, where studies reporting failures in RPA projects may be published less frequently than those reporting successes. Additionally, the scope of the results is naturally limited by the search string and the chosen databases.

B. FUTURE WORK AND RESEARCH DIRECTIONS

The conclusions of this work open several promising avenues for future research. Based on the findings and technological trends, possible directions are noted. One is the exploration of new Generative AI tools, as the evolution of LLMs into models that can interact directly with web interfaces, such as the ‘‘OpenAI Operator’’, represents a promising advance. Future research could investigate how these tools, which allow to perform a wide variety of repetitive browser tasks, such as filling out forms and placing grocery orders, blur the lines between RPA and GenAI, potentially creating a new class of automation.

Another promising line of future research is the inves-tigation of Agentic Process Automation (APA). This term describe the integration of multiple LLM agents in process automation. Future research could delve deeper into this concept, exploring how systems with multiple AI agents can collaborate to reduce the need for human intervention in complex workflows.

Furthermore, our findings suggest that organizational context plays a crucial role. It is interesting that future research investigates how the priority of these limitations changes according to organizational maturity (e.g., orga-nizations implementing RPA for the first time compared to organizations with years of experience and successful integrations) and industry sectors (e.g., highly regulated sectors such as finance versus creative sectors).

Finally, given the persistence of human-centered limita-tions, a more in-depth exploration of change management frameworks specifically adapted to the era where human and digital workers coexist would be a valuable contribution to the field.

ACKNOWLEDGMENT.

We would like to thank all the funding agencies that financed this work.

FUNDING

This study was financed in part by the Coordenação de Aperfeiçoamento de Pessoal de NÍvel Superior - Brasil (CAPES) - Finance Code 001. This work was also funded by the project TED2021-129194B-I00 funded by MICIU/ AEI/ 10.13039/501100011033, and by the ‘‘European Union NextGenerationEU/PRTR’’. The 0100TID4AGRO4E project is co-financed by the European Regional Devel-opment Fund (ERDF), managed through the INTERREG VI-A Spain-Portugal (POCTEP) Programme 2021-2027 of the European Commission. This activity has been co-financed 85% by the European Union, the European Regional Development Fund and the Regional Government of Extremadura. Managing Authority: Ministry of Finance. Grant File Number: GR24099.