Executive summary
Nelle aziende che gestiscono grandi volumi di operazioni ripetitive, trasferire dati da un'applicazione all'altra, compilare moduli e verificare informazioni sono attività che assorbono risorse significative senza generare valore diretto. Esiste una famiglia di tecnologie che consente di delegare queste operazioni a programmi software in grado di utilizzare le stesse schermate e gli stessi passaggi che un operatore umano seguirebbe manualmente. Questa analisi esamina i fondamenti di tali tecnologie, distingue tra automazione assistita e completamente autonoma, e mostra come la scoperta automatica delle attività ripetitive e l'integrazione con sistemi capaci di comprendere documenti e prendere decisioni stiano trasformando strumenti originariamente rigidi in piattaforme adattabili. L'elemento centrale che emerge è che il valore non risiede nella singola operazione automatizzata, ma nella capacità di coordinare componenti diversi, programmi, servizi e moduli intelligenti, in modo affidabile anche quando le applicazioni sottostanti cambiano.
Background
La Robotic Process Automation (RPA) si configura come un paradigma di automazione dei processi aziendali in cui software robot, comunemente denominati bot, eseguono attività su sistemi informativi interagendo con le interfacce utente esistenti, senza richiedere modifiche alle applicazioni sottostanti [1]. A differenza dell'integrazione applicativa tradizionale basata su API, l'RPA opera al livello della presentazione: il bot replica le azioni che un operatore umano compirebbe, click, inserimento di testo, lettura di campi, navigazione tra finestre, attraverso tecniche di UI automation che intercettano gli elementi dell'interfaccia grafica o ne analizzano la resa visiva [2].
Le radici concettuali dell'RPA risalgono ai primi strumenti di screen scraping e macro recording degli anni Novanta, ma la disciplina ha acquisito identità propria a partire dal 2012-2015, quando Willcocks, Lacity e Craig hanno condotto i primi studi empirici rigorosi sull'adozione della tecnologia in contesti enterprise, documentando i risultati dell'implementazione presso Telefónica O2 e Xchanging [3]. Questi lavori hanno dimostrato che l'RPA non è un semplice strumento di scripting, ma una strategia di automazione con implicazioni organizzative significative: la scelta di quali processi automatizzare, come strutturare la governance dei bot e come gestire il rapporto tra automazione e workforce richiede un framework decisionale che va oltre la dimensione tecnica.
Il campo ha subito una rapida evoluzione tassonomica. Enriquez et al. [2] hanno prodotto un systematic mapping study che, analizzando 54 studi primari, ha identificato le dimensioni fondamentali della ricerca sull'RPA: tecnologie di interazione con le interfacce, architetture di orchestrazione, integrazione con intelligenza artificiale, e sfide di manutenibilità. Syed et al. [4] hanno condotto una structured literature review su 125 pubblicazioni, sintetizzando i risultati lungo i temi della definizione dell'RPA, dei benefici quantificabili, della readiness organizzativa e delle metodologie di implementazione. Il risultato convergente di queste survey è che l'RPA si distingue da altre forme di automazione per tre caratteristiche: opera al livello dell'interfaccia utente (non delle API), è non-invasiva rispetto ai sistemi esistenti, e viene tipicamente configurata piuttosto che programmata in senso tradizionale.
Dal punto di vista del mercato, l'RPA ha registrato una crescita senza precedenti. Gartner ha identificato l'hyperautomation, definita come l'uso combinato di RPA, AI, process mining e event-driven architecture, come trend strategico a partire dal 2020, stimando che il mercato del software di hyperautomation raggiungerà 1.040 miliardi di dollari entro il 2026, con un tasso di crescita annuo composto dell'11,9% [5]. Questa traiettoria riflette non solo l'adozione crescente dell'RPA, ma la transizione verso piattaforme di automazione che integrano capacità cognitive, orchestrazione multi-sistema e scoperta automatica dei processi.
Architettura e modelli di esecuzione
Bot attended e unattended
La distinzione architetturale fondamentale nell'RPA è tra esecuzione attended (assistita) e unattended (autonoma), due modelli che riflettono differenze profonde nel ciclo di vita dell'automazione, nella topologia di deployment e nel pattern di interazione uomo-macchina [6].
Un bot attended risiede sulla workstation dell'operatore e viene attivato manualmente o in risposta a eventi specifici dell'interfaccia utente, ad esempio l'apertura di un ticket in un CRM o la ricezione di una email classificata come richiesta di informazioni. Il bot opera in co-presenza con l'utente, tipicamente eseguendo sotto-attività all'interno di un processo più ampio che richiede giudizio umano per le decisioni non standardizzabili. L'architettura attended è caratterizzata da latenza minima nell'attivazione (il bot è già caricato in memoria sulla macchina dell'utente), accesso diretto al contesto applicativo dell'operatore e dipendenza dalla sessione utente attiva. Il caso d'uso paradigmatico è l'assistenza in tempo reale negli ambienti di contact center, dove il bot recupera informazioni da sistemi eterogenei e le presenta all'operatore durante la conversazione con il cliente [6].
Un bot unattended, al contrario, opera in modo completamente autonomo su infrastrutture dedicate, macchine virtuali, container o ambienti cloud, senza richiedere interazione umana durante l'esecuzione. L'attivazione avviene tramite schedulazione temporale, trigger basati su eventi (ricezione di un file, inserimento in una coda, variazione di stato in un database) o invocazione da parte di un orchestratore centralizzato. L'esecuzione unattended è progettata per elaborazioni batch ad alto volume: riconciliazioni contabili, migrazione dati tra sistemi legacy, generazione massiva di report, processing di fatture elettroniche. Le caratteristiche architetturali includono l'esecuzione in sessioni utente dedicate (spesso in background, senza desktop interattivo), la scalabilità orizzontale attraverso pool di macchine, e la gestione centralizzata delle code di lavoro [7].
La convergenza tra i due modelli ha prodotto l'architettura ibrida, in cui un workflow orchestrato può combinare fasi unattended (elaborazione batch) con fasi attended (validazione umana di eccezioni). Gartner ha stimato che entro il 2024 oltre il 50% delle organizzazioni che adottano RPA avrebbe implementato modelli ibridi [5], riconoscendo che la maggior parte dei processi aziendali reali non è interamente automatizzabile né interamente manuale, ma presenta un profilo misto che richiede punti di intervento umano programmati.
Orchestrazione e infrastruttura
L'orchestratore è il componente architetturale che gestisce il ciclo di vita dei bot, l'assegnazione delle risorse computazionali e il monitoraggio dell'esecuzione. Nelle piattaforme enterprise, l'orchestratore svolge funzioni analoghe a un resource manager in un sistema distribuito: mantiene un registro dei bot disponibili, gestisce code di lavoro (work queues) con semantica FIFO o prioritaria, assegna job ai bot in base alla disponibilità e alle capability, e raccoglie log di esecuzione e metriche di performance [7].
UiPath Orchestrator, ad esempio, implementa un modello in cui i robot unattended vengono registrati come risorse in un catalogo centralizzato, organizzati in folder gerarchici con ruoli e permessi granulari, e attivati tramite trigger temporali o basati su eventi. L'architettura supporta la scalabilità attraverso pool di macchine: quando un desktop flow è in coda e nessun bot è disponibile, l'orchestratore può richiedere il provisioning di macchine virtuali aggiuntive, un pattern analogo all'auto-scaling nei sistemi cloud-native [7]. Microsoft Power Automate adotta un approccio architetturalmente distinto: i cloud flow fungono da livello di orchestrazione che invoca i desktop flow (componente RPA) solo quando è necessaria l'interazione con sistemi legacy, mantenendo la maggior parte della logica nel cloud dove è scalabile, auditabile e manutenibile. L'infrastruttura Hosted RPA di Microsoft esegue i bot su macchine virtuali Azure con provisioning automatico, eliminando la necessità di gestire infrastruttura on-premise dedicata [8].
Il pattern architetturale emergente è quello del cloud-native orchestration, in cui l'orchestratore non è più un server monolitico ma un servizio distribuito che espone API RESTful, supporta webhook per l'integrazione event-driven e si integra nativamente con le piattaforme di identity management per l'autenticazione e l'autorizzazione dei bot. Questa evoluzione riflette la maturazione dell'RPA da strumento tattico a componente infrastrutturale dell'automazione enterprise.
graph TD
subgraph Orchestratore
Q[Work Queue] --> D[Dispatcher]
S[Scheduler / Trigger] --> D
D --> R1[Bot Unattended 1<br/>VM / Container]
D --> R2[Bot Unattended 2<br/>VM / Container]
D --> R3[Bot Unattended N<br/>Auto-scaled]
M[Monitor & Logging] --> D
end
subgraph Workstation Operatore
U[Utente] --> A[Bot Attended]
A -->|UI Automation| APP1[Applicazione Legacy]
end
R1 -->|UI Automation| APP2[ERP]
R2 -->|API| APP3[CRM / Cloud Service]
R3 -->|UI Automation| APP4[Applicazione Mainframe]
A -.->|Eccezioni / Escalation| Q
M -.->|Metriche| DASH[Dashboard Operativa]
Figura 1, Architettura di orchestrazione RPA con bot attended e unattended. Il dispatcher assegna job dalla work queue ai bot unattended disponibili nel pool, con auto-scaling su macchine virtuali o container. I bot attended operano sulla workstation dell'operatore e possono instradare eccezioni nella coda centralizzata. Il monitor raccoglie log e metriche per la dashboard operativa.
Tecniche di UI automation
Interazione con le interfacce grafiche
Il meccanismo tecnico che distingue l'RPA dall'integrazione applicativa tradizionale è la capacità di interagire con le applicazioni attraverso le loro interfacce utente. Questa interazione si realizza attraverso tre strategie principali, ciascuna con compromessi specifici in termini di affidabilità, performance e manutenibilità [2, 9].
La prima strategia è il selector-based automation, in cui il bot identifica gli elementi dell'interfaccia grafica attraverso attributi strutturali, identificatori univoci, classi CSS, proprietà di accessibilità, posizione nell'albero DOM per applicazioni web, o attributi UI Automation per applicazioni Windows. Questa tecnica è la più robusta: finché gli attributi strutturali rimangono stabili, il bot funziona indipendentemente da variazioni di layout, risoluzione dello schermo o tema grafico. I framework di UI Automation di Microsoft e la tecnologia Apple Accessibility forniscono API native per l'enumerazione e la manipolazione degli elementi di interfaccia, consentendo al bot di leggere valori, impostare testo, attivare pulsanti e navigare tra controlli senza simulare input fisici del mouse o della tastiera [9].
La seconda strategia è lo screen scraping basato su OCR (Optical Character Recognition), utilizzato quando l'applicazione target non espone un albero di accessibilità strutturato, tipicamente applicazioni legacy basate su terminale, applicazioni Citrix/Remote Desktop, o ambienti virtualizzati dove il bot ha accesso solo alla resa visiva dell'interfaccia. In questo scenario, il bot cattura screenshot dell'interfaccia e applica algoritmi OCR per estrarre il testo visibile, combinandoli con template matching per identificare la posizione di elementi grafici noti. La fragilità di questo approccio è significativa: variazioni di font, risoluzione, anti-aliasing o tema grafico possono compromettere il riconoscimento, e la performance è ordini di grandezza inferiore rispetto all'accesso diretto all'albero di accessibilità [2].
La terza strategia è la computer vision-based automation, un approccio più recente che utilizza modelli di deep learning per identificare elementi dell'interfaccia a partire dalla resa visiva, indipendentemente dalla tecnologia sottostante. UiPath ha introdotto Computer Vision come componente della propria piattaforma, impiegando reti neurali addestrate su dataset di screenshot annotati per riconoscere pulsanti, campi di testo, checkbox e altri elementi di interfaccia con una precisione che si avvicina a quella dell'accesso strutturale [7]. Questo approccio rappresenta un compromesso tra la robustezza del selector-based automation e la generalità dello screen scraping, ed è particolarmente rilevante per l'automazione di applicazioni eterogenee in ambienti virtualizzati.
API vs. GUI: il trade-off fondamentale
Un tema ricorrente nella letteratura è il confronto tra l'automazione basata su interfaccia grafica (GUI) e quella basata su API. Hofmann, Jost e Zerbato [10] hanno dimostrato empiricamente che i bot RPA che utilizzano API sono, in alcuni casi, fino a dieci volte più veloci rispetto ai corrispondenti bot basati su GUI, con vantaggi aggiuntivi in termini di affidabilità e manutenibilità. L'API elimina la dipendenza dalla resa visiva dell'interfaccia, riduce la superficie di errore legata a variazioni dell'UI e consente l'elaborazione di volumi superiori per unità di tempo.
Tuttavia, il ricorso alle API non è sempre possibile. Molte applicazioni enterprise, in particolare sistemi legacy, ERP con interfacce proprietarie e applicazioni mainframe, non espongono API documentate o sufficientemente granulari. In questi contesti, l'RPA basata su GUI rappresenta l'unica strategia praticabile per l'automazione senza modifica del sistema sorgente, configurandosi come un bridge tecnologico temporaneo in attesa della modernizzazione dell'applicazione [8, 10]. La raccomandazione architetturale emergente è un approccio ibrido: utilizzare API dove disponibili e ricorrere alla UI automation solo per le interazioni con sistemi che non offrono alternative programmatiche.
Process recording e scoperta automatica dei processi
Dal task mining al Robotic Process Mining
La creazione di automazioni RPA richiede tradizionalmente un'analisi manuale del processo da automatizzare: un analista osserva gli operatori, documenta le sequenze di azioni e traduce questa conoscenza in un workflow eseguibile dal bot. Questo approccio presenta colli di bottiglia significativi in termini di tempo, costo e accuratezza, la documentazione manuale è soggetta a omissioni, semplificazioni e bias dell'osservatore [11].
Il Robotic Process Mining (RPM), formalizzato da Leno, Polyvyanyy, Dumas, La Rosa e Maggi [11], propone un approccio alternativo: registrare automaticamente le interazioni degli utenti con i sistemi informativi, click, input da tastiera, cambi di finestra, selezioni di menu, e analizzare queste registrazioni per identificare routine ripetitive automatizzabili e derivare script RPA corrispondenti. La definizione formale di RPM lo colloca come una famiglia di tecniche per la scoperta di routine ripetitive automatizzabili tramite tecnologia RPA, ottenuta analizzando le interazioni tra uno o più lavoratori e una o più applicazioni software durante l'esecuzione di uno o più task in un processo aziendale [11].
Il collegamento con il process mining classico è diretto ma non banale. Mentre il process mining tradizionale opera su event log generati dai sistemi informativi, dove ogni evento corrisponde a un'attività di business con semantica nota, il task mining opera su UI log a granularità molto più fine: ogni evento corrisponde a un'azione elementare sull'interfaccia (click su un pulsante, digitazione in un campo, scroll di una pagina) la cui semantica di business deve essere inferita attraverso tecniche di astrazione [11, 12]. La sfida centrale del RPM è colmare questo gap semantico: trasformare sequenze di eventi UI di basso livello in rappresentazioni di processo di alto livello che siano comprensibili per gli analisti e traducibili in automazioni.
Tecniche di process recording
Le piattaforme RPA commerciali hanno integrato funzionalità di process recording che implementano, con gradi variabili di sofisticazione, i principi del RPM. UiPath Task Capture e Process Mining, Microsoft Power Automate Process Advisor, e Automation Anywhere Process Discovery offrono strumenti che registrano le azioni degli utenti, le aggregano in sequenze significative e generano documentazione di processo o bozze di automazione [7, 8].
Il workflow tipico di process recording prevede quattro fasi. Nella fase di registrazione, un agente software installato sulla workstation dell'operatore cattura eventi UI (click, keystroke, cambio di finestra, apertura di URL) insieme a screenshot contestuali e metadati delle applicazioni coinvolte. Nella fase di preprocessing, gli eventi grezzi vengono filtrati (rimozione di azioni irrilevanti come scroll o ridimensionamento finestre), normalizzati (unificazione di varianti della stessa azione) e segmentati in sequenze corrispondenti a task distinti. Nella fase di analisi, algoritmi di pattern mining identificano sequenze ricorrenti, varianti del processo e punti di decisione. Nella fase di generazione, le routine identificate vengono tradotte in bozze di workflow RPA che richiedono revisione e completamento da parte di uno sviluppatore [11, 12].
Linn et al. [12] hanno proposto un framework di task mining che arricchisce i log UI con feature estratte da screenshot, utilizzando alberi di decisione per identificare i fattori che determinano le varianti nelle azioni degli operatori. Questo approccio affronta un problema critico: le stesse azioni UI possono avere significati diversi in contesti diversi, e l'analisi puramente sequenziale degli eventi non è sufficiente a distinguere le varianti. L'integrazione di informazione visiva dal contesto dell'interfaccia consente di costruire modelli più accurati del processo reale.
Van der Aalst [13] ha collegato esplicitamente il process mining all'RPA, osservando che la distanza tra il processo così come è stato progettato e il processo così come viene effettivamente eseguito è quasi sempre maggiore di quanto si assuma. Il process mining fornisce gli strumenti formali per quantificare questa distanza, e il task mining la estende al livello delle interazioni utente, creando un ciclo continuo di scoperta, automazione e monitoraggio che van der Aalst ha definito il "Pareto principle" dell'automazione: un numero relativamente piccolo di routine ricorrenti rappresenta una frazione sproporzionata del carico di lavoro manuale [13].
Intelligent automation: la convergenza tra RPA e AI
Dall'automazione deterministica all'automazione cognitiva
L'RPA nella sua forma originaria è un sistema deterministico: il bot esegue una sequenza predefinita di azioni, gestendo varianti limitate attraverso strutture condizionali esplicite (if-then-else). Come documentato da Aguirre e Rodriguez [14] in un caso di studio sull'automazione di processi aziendali, i bot RPA tradizionali operano su task altamente standardizzati, data entry da fonti strutturate, riconciliazioni basate su regole, generazione di report, ottenendo risultati significativi entro tali confini, ma si rivelano fragili di fronte a input non strutturati, eccezioni non previste e decisioni che richiedono giudizio contestuale.
L'integrazione tra RPA e intelligenza artificiale, comunemente definita intelligent automation (IA), affronta questa limitazione arricchendo i bot con capacità cognitive: comprensione del linguaggio naturale, riconoscimento di documenti, classificazione di contenuti, estrazione di informazioni da fonti non strutturate e processo decisionale basato su modelli predittivi [14, 15]. La tassonomia proposta da Syed et al. [4] identifica tre livelli di maturità dell'automazione intelligente: il livello base (RPA pura) per task deterministici su dati strutturati; il livello intermedio (RPA + AI specializzata) per task semi-strutturati che richiedono capacità di percezione o classificazione; il livello avanzato (automazione autonoma) per processi che richiedono ragionamento, pianificazione e adattamento dinamico.
Intelligent Document Processing
Il caso d'uso più maturo della convergenza RPA-AI è l'Intelligent Document Processing (IDP), dove i bot devono estrarre informazioni da documenti con formato variabile, fatture, ordini d'acquisto, contratti, corrispondenza. L'approccio tradizionale basato su template fissi (definizione esplicita delle coordinate di ciascun campo in ogni formato di documento) non scala: un'organizzazione che riceve fatture da centinaia di fornitori, ciascuno con un formato diverso, non può mantenere centinaia di template.
Le piattaforme RPA hanno risposto integrando modelli di machine learning per l'estrazione documentale. UiPath Document Understanding combina OCR, classificazione dei documenti mediante reti neurali e estrazione dei campi attraverso modelli addestrati su dataset annotati [7]. Automation Anywhere ha sviluppato IQ Bot, successivamente evoluto in Document Automation, che impiega un Process Reasoning Engine per estrarre, validare e instradare dati da documenti di qualsiasi tipologia, dichiarando accuratezze superiori al 95% sull'estrazione di dati non strutturati [16]. L'architettura di questi sistemi segue un pattern comune: il documento viene prima classificato (fattura, ordine, contratto), poi analizzato con un modello specifico per la tipologia identificata, e infine i campi estratti vengono validati contro regole di business prima di essere inseriti nel sistema target.
Chakraborti et al. [15] hanno documentato come l'integrazione di AI nell'RPA vada oltre l'estrazione documentale, includendo l'analisi dei dati per l'identificazione di pattern, la classificazione automatica delle informazioni e la previsione, con applicazioni documentate in manifattura, agricoltura, sanità, finanza e retail. Il denominatore comune è la sostituzione di regole esplicite con modelli appresi dai dati, consentendo al bot di gestire variabilità che sarebbe impraticabile codificare manualmente.
Agentic automation e la frontiera LLM
La convergenza più recente, e quella con le implicazioni architetturali più profonde, è tra RPA e agenti AI basati su large language model (LLM). A differenza dell'intelligent automation tradizionale, dove modelli ML specializzati vengono integrati come componenti discreti in workflow predefiniti, l'agentic automation introduce agenti capaci di pianificare, ragionare e decidere autonomamente come eseguire un task [17].
L'architettura emergente prevede due modelli distinti. Il primo modello, definito process-centric, ancora gli agenti AI al backbone del processo: agenti specializzati operano come helper integrati all'interno di workflow deterministici esistenti, gestendo le eccezioni e i passaggi che richiedono giudizio senza alterare la struttura complessiva del processo. Il secondo modello, definito reasoning-centric, inverte la relazione: l'agente AI è al centro e utilizza ragionamento e pianificazione per decidere dinamicamente come eseguire il lavoro, invocando bot RPA, API e servizi come strumenti a disposizione [17]. Forrester prevede che nel 2026 meno del 15% delle organizzazioni attiverà le funzionalità agentiche integrate nelle suite di intelligent automation, segnalando che la maturità tecnologica e organizzativa necessaria per il modello reasoning-centric è ancora in fase di sviluppo [17].
UiPath ha posizionato la propria piattaforma come sistema di agentic automation, con un'architettura che consente di orchestrare agenti UiPath, agenti di terze parti, automazioni UI e workflow basati su API all'interno di un framework unificato con governance granulare, monitoraggio in tempo reale e controlli di compliance [7]. Automation Anywhere ha introdotto l'Agentic Process Automation (APA), dove agenti AI integrati analizzano dati, suggeriscono azioni e agiscono autonomamente all'interno di processi documentali [16]. Microsoft, attraverso Dynamics 365 e Power Platform, ha annunciato l'introduzione di agenti AI task-specific nelle applicazioni enterprise, stimando che il 40% delle applicazioni enterprise includerà agenti AI dedicati entro la fine del 2026 [8, 17].
Limiti, sfide e problemi aperti
Fragilità delle automazioni UI-based
La dipendenza dall'interfaccia grafica è simultaneamente il principale vantaggio e la principale vulnerabilità dell'RPA. Ogni aggiornamento dell'applicazione target che modifica la struttura dell'interfaccia, rinominazione di un campo, riorganizzazione di un menu, aggiornamento di un framework frontend, può interrompere l'automazione. Questa fragilità genera un costo di manutenzione che cresce con il numero di bot in produzione e con la frequenza degli aggiornamenti delle applicazioni sottostanti [2, 4]. I dati empirici suggeriscono che le organizzazioni con centinaia di bot in produzione dedicano una quota significativa delle risorse del centro di competenza RPA alla manutenzione reattiva, correzione di bot interrotti da aggiornamenti non previsti, piuttosto che allo sviluppo di nuove automazioni.
Le strategie di mitigazione includono l'uso di selettori resilienti (basati su attributi stabili piuttosto che su posizioni assolute), l'implementazione di pattern di retry con fallback, il monitoraggio proattivo dello stato di salute dei bot e l'adozione di test automatizzati che verifichino il funzionamento delle automazioni in ambienti di staging prima del deployment in produzione. Tuttavia, nessuna di queste strategie elimina il problema fondamentale: l'RPA crea un accoppiamento implicito tra il bot e l'interfaccia dell'applicazione che non è governato da un contratto formale (a differenza di un'API con versioning e backward compatibility).
Sicurezza e governance
L'RPA introduce un profilo di rischio specifico nei sistemi informativi enterprise. I bot operano con credenziali che devono avere accesso ai sistemi target, spesso con privilegi equivalenti a quelli di un operatore umano, creando una superficie di attacco che richiede gestione dedicata. Chakraborti e Iyengar [18] hanno identificato otto sfide tecniche significative nella sicurezza dell'RPA e dell'intelligent automation, con il logging robusto, l'auditing e il controllo degli accessi come temi più frequentemente discussi nella letteratura. Le best practice includono la gestione centralizzata delle credenziali tramite vault dedicati, l'implementazione del principio del minimo privilegio per ciascun bot, l'audit trail completo di ogni azione eseguita e la segregazione degli ambienti di sviluppo, test e produzione.
Scalabilità organizzativa
Oltre alle sfide tecniche, l'adozione dell'RPA su larga scala presenta problemi organizzativi documentati dalla letteratura. La selezione dei processi candidati all'automazione richiede criteri sistematici: non tutti i processi ripetitivi sono buoni candidati per l'RPA, processi con troppe eccezioni, input altamente variabili o dipendenze da giudizio umano possono generare automazioni fragili il cui costo di manutenzione supera il beneficio [3, 4]. Van der Aalst [13] ha proposto il process mining come strumento per identificare oggettivamente i processi con il miglior rapporto tra volume di esecuzione, standardizzazione e impatto economico, applicando il principio di Pareto per concentrare gli investimenti di automazione sui processi che generano il massimo ritorno.
La governance dei bot in produzione richiede strutture organizzative dedicate, tipicamente un Center of Excellence (CoE), che gestiscano il ciclo di vita delle automazioni dalla progettazione al decommissioning, assicurino la conformità alle politiche di sicurezza e privacy, e mantengano un inventario aggiornato delle dipendenze tra bot e applicazioni [4].
Implicazioni pratiche e direzioni future
L'adozione dell'RPA in un contesto enterprise richiede decisioni architetturali che bilancino benefici immediati e sostenibilità nel medio periodo. L'approccio raccomandato dalla letteratura e dalle best practice delle piattaforme è stratificato: utilizzare API dove disponibili, ricorrere alla UI automation per i sistemi legacy che non offrono alternative programmatiche, e pianificare la migrazione progressiva delle automazioni GUI-based verso integrazioni API man mano che i sistemi sottostanti vengono modernizzati [8, 10].
L'integrazione con il process mining crea un ciclo virtuoso di miglioramento continuo: il process mining identifica i processi candidati all'automazione e quantifica il potenziale di miglioramento, l'RPA implementa l'automazione, e il monitoraggio continuo tramite process mining verifica l'impatto effettivo e identifica derive o anomalie [11, 13]. Questo ciclo è tecnicamente maturo e supportato dalle principali piattaforme, ma richiede investimenti in infrastruttura di data collection e competenze analitiche che molte organizzazioni non hanno ancora sviluppato.
La frontiera dell'agentic automation solleva questioni architetturali inedite. Il passaggio da bot deterministici che eseguono script a agenti che pianificano e decidono autonomamente richiede modelli di governance radicalmente diversi: come si definiscono i confini dell'autonomia di un agente? Come si garantisce l'auditabilità di decisioni prese da un LLM? Come si gestisce il rischio di azioni non previste in processi critici? Forrester [17] osserva che nel 2026 l'automazione non circonda più il business, è il business, una transizione che richiede maturità tecnologica e organizzativa che la maggior parte delle organizzazioni sta ancora costruendo.
Il futuro dell'RPA, in definitiva, non è un futuro di bot che cliccano su interfacce, ma di piattaforme di orchestrazione che coordinano componenti eterogenei, automazioni UI, integrazioni API, modelli ML, agenti AI, in workflow adattivi capaci di gestire la complessità e la variabilità dei processi aziendali reali. La sfida tecnica centrale rimane quella della composabilità: costruire architetture in cui ciascun componente possa essere sostituito, aggiornato o potenziato senza compromettere l'integrità del processo complessivo.
Riferimenti
[1] W.M.P. van der Aalst, M. Bichler, A. Heinzl, "Robotic Process Automation," Business & Information Systems Engineering, vol. 60, no. 4, pp. 269-272, 2018. https://doi.org/10.1007/s12599-018-0542-4
[2] J.G. Enriquez, A. Jimenez-Ramirez, F.J. Dominguez-Mayo, J.A. Garcia-Garcia, "Robotic Process Automation: A Scientific and Industrial Systematic Mapping Study," IEEE Access, vol. 8, pp. 39113-39129, 2020. https://ieeexplore.ieee.org/document/9001110
[3] M.C. Lacity, L.P. Willcocks, A. Craig, "Robotic Process Automation at Telefónica O2," MIS Quarterly Executive, vol. 15, no. 1, pp. 21-35, 2016. https://aisel.aisnet.org/misqe/vol15/iss1/4/
[4] R. Syed et al., "Robotic Process Automation: Contemporary Themes and Challenges," Computers in Industry, vol. 115, 103162, 2020. https://www.sciencedirect.com/science/article/abs/pii/S0166361519304609
[5] Gartner, "Forecast Analysis: Hyperautomation Enablement Software, Worldwide," 2024. https://www.gartner.com/en/documents/4019586
[6] UiPath, "Attended Vs Unattended Robots," UiPath Documentation, 2025. https://docs.uipath.com/robot/standalone/2023.4/admin-guide/attended-vs-unattended
[7] UiPath, "Orchestrator — How Is Unattended Automation Performed," UiPath Documentation, 2025. https://docs.uipath.com/orchestrator/automation-cloud/latest/user-guide/how-is-unattended-automation-performed
[8] Microsoft, "Introduction to Desktop Flows — Power Automate," Microsoft Learn, 2025. https://learn.microsoft.com/en-us/power-automate/desktop-flows/introduction
[9] Microsoft, "Reduce Infrastructure Challenges with Hosted RPA in Power Automate," Microsoft Learn, 2025. https://learn.microsoft.com/en-us/power-platform/architecture/reference-architectures/rpa-scale-operations
[10] P. Hofmann, D. Jost, D. Zerbato, "API as Method for Improving Robotic Process Automation," in Proc. BPM Forum, Springer, LNBIP vol. 459, pp. 275-290, 2022. https://link.springer.com/chapter/10.1007/978-3-031-16168-1_17
[11] V. Leno, A. Polyvyanyy, M. Dumas, M. La Rosa, F.M. Maggi, "Robotic Process Mining: Vision and Challenges," Business & Information Systems Engineering, vol. 63, pp. 301-314, 2021. https://link.springer.com/article/10.1007/s12599-020-00641-4
[12] C. Linn et al., "A Screenshot-Based Task Mining Framework for Disclosing the Drivers Behind Variable Human Actions," Data & Knowledge Engineering, vol. 149, 102247, 2024. https://www.sciencedirect.com/science/article/pii/S030643792300176X
[13] W.M.P. van der Aalst, "On the Pareto Principle in Process Mining, Task Mining, and RPA," RWTH Aachen University, 2022. https://www.vdaalst.rwth-aachen.de/publications/p1139.pdf
[14] S. Aguirre, A. Rodriguez, "Automation of a Business Process Using Robotic Process Automation (RPA): A Case Study," in Proc. Workshop on Engineering Applications, Springer, pp. 65-71, 2017. https://link.springer.com/chapter/10.1007/978-3-030-00353-1_7
[15] S. Chakraborti et al., "AI-Enhanced Robotic Process Automation: A Review of Intelligent Automation Innovations," IEEE Access, vol. 12, pp. 179530-179555, 2024. https://ieeexplore.ieee.org/document/10781408
[16] Automation Anywhere, "IQ Bot — Cognitive Automation and AI," Automation Anywhere Documentation, 2025. https://www.automationanywhere.com/products/iq-bot
[17] Forrester, "Predictions 2026: Automation at the Crossroads," Forrester Research, 2025. https://www.forrester.com/blogs/predictions-2026-automation-at-the-crossroads/
[18] S. Chakraborti, W. Iyengar, "Robotic Process Automation and Intelligent Automation Security Challenges: A Review," in Proc. IEEE ICCE, 2023. https://ieeexplore.ieee.org/document/10050996