Dipendente IA vs. RPA: Quale Si Adatta al Vostro Flusso?
L'RPA automatizza ciò che è già strutturato. Un dipendente IA legge ciò che non lo è. Dati McKinsey e Gartner su cosa funziona davvero nel 2026.
Due Scommesse Diverse sullo Stesso Problema
RPA e un dipendente IA promettono entrambi di togliere un compito ripetitivo dalla scrivania di una persona, ed è esattamente per questo che ai responsabili IT e operativi viene continuamente chiesto di scegliere tra i due nella stessa discussione di budget. Non sono implementazioni concorrenti della stessa idea. L'RPA automatizza un compito scriptando i clic e le battute esatte che una persona farebbe in un'interfaccia strutturata e immutabile. Un dipendente IA automatizza un compito leggendo l'input — un'email, un PDF, un messaggio WhatsApp, un modulo scansionato — e decidendo cosa farne. Lo strumento giusto dipende quasi interamente da quale dei due problemi presenta il vostro flusso di lavoro reale.
In Cosa l'RPA È Ancora Davvero Bravo
I bot RPA eccellono nel lavoro ad alto volume, basato su regole, a input strutturato, dove l'interfaccia e il formato dei dati non cambiano: spostare un valore da un campo di un sistema a un altro, eseguire lo stesso controllo di validazione su ogni riga di un foglio di calcolo, eseguire una sequenza fissa di azioni sull'interfaccia di un'applicazione legacy senza API. Quando l'input è sempre nello stesso posto, nello stesso formato, e la logica è un insieme fisso di regole se-questo-allora-quello, l'RPA è economico, veloce e verificabile — ogni passo che compie è scriptato e tracciabile.
In modo significativo, i tre maggiori fornitori di RPA dicono la stessa cosa sulle proprie roadmap di prodotto. UiPath descrive la sua piattaforma attuale come qualcosa che unisce "RPA consolidato, modelli IA ed esperienza umana in flussi di lavoro coerenti dove persone, robot e agenti IA lavorano in modo sinergico", con il suo livello di orchestrazione Maestro che coordina i tre invece che uno sposti l'altro (sala stampa UiPath). Automation Anywhere inquadra la sua "Agentic Process Automation" come una combinazione tra "l'affidabilità dell'automazione dei processi aziendali e l'adattabilità dell'IA", precisando che l'automazione tradizionale "resta intrinsecamente limitata da una programmazione statica e regole definite", ma non viene rimossa, solo estesa (Automation Anywhere). SS&C Blue Prism posiziona il suo nuovo livello agentico, WorkHQ, come qualcosa che funziona direttamente insieme ai suoi prodotti RPA esistenti e permette ai clienti di "iniziare a usare le nuove funzionalità... senza migrare tutto il proprio parco di automazione in una volta" (Blue Prism). Nessuna delle tre aziende che hanno costruito il mercato RPA dice ai propri clienti di eliminare i loro bot. Questo inquadramento conta perché significa che il confronto onesto di solito non è "sostituire l'RPA" — è "dove si rompe lo script RPA, e cosa lo sostituisce in quel punto?"
Dove l'RPA Si Rompe
Gli script RPA falliscono, o richiedono una reingegnerizzazione costante, in quattro punti precisi:
- Input non strutturato. Un PDF con layout variabile, un'email con una nota di pagamento in testo libero, un modulo scansionato — l'RPA ha bisogno che i dati siano già estratti in un campo strutturato prima di poterci agire sopra. Non può leggere e interpretare il documento stesso.
- Cambiamenti di interfaccia. Uno script RPA costruito su un layout di schermo specifico si rompe nel momento in cui quello schermo cambia, perché è stato scriptato contro pixel e campi, non contro l'intento sottostante del compito.
- Eccezioni. Quando un bot RPA incontra un input per cui non è stato scriptato, si ferma e instrada verso un umano. Non ragiona su cosa probabilmente dovrebbe succedere; non ha giudizio da applicare.
- Variabilità reale del compito stesso. Un compito con quaranta casi particolari che oggi un umano risolve con contesto e memoria è un compito che l'RPA può coprire solo per la maggioranza pulita, lasciando le eccezioni — spesso i casi più dispendiosi in termini di tempo — esattamente dove erano.
Cosa Fa Diversamente un Dipendente IA
Un dipendente IA è costruito per leggere direttamente input non strutturato e ragionare su cosa farne, che è la capacità che manca strutturalmente all'RPA. Dove un compito aziendale ripetitivo implica leggere un documento, un'email o un messaggio che varia in formato, e decidere l'azione giusta tra più risultati possibili, questo è decisamente territorio di un dipendente IA, non dell'RPA.
Una versione concreta di questa distinzione: il team commerciale di un produttore riceve ordini d'acquisto via email da decine di acquirenti, ognuno con il proprio modello di ordine — nomi di campo diversi, layout diversi, alcuni come PDF, alcuni come immagini scansionate. Uno script RPA può elaborare questo in modo affidabile solo se ogni acquirente invia lo stesso formato, cosa che non fanno e non faranno. Un agente di automazione degli ordini legge l'email e l'allegato indipendentemente dal layout, estrae acquirente, SKU, quantità e prezzi, e scrive un ordine strutturato nell'ERP — lo stesso risultato che promette l'RPA, ma partendo da un input che l'RPA non può analizzare in primo luogo. Una volta che l'ordine è in forma strutturata, un semplice passo basato su regole può completarne l'instradamento; questa seconda metà è esattamente dove l'RPA resta la scelta più economica e più verificabile.
La ricerca di McKinsey su questa divisione mette un numero su quanto del lavoro attuale rientra in ciascuna categoria. La sua analisi di novembre 2025 "Agents, robots, and us" stima che gli agenti IA possano già svolgere lavoro che occupa il 44% delle ore di lavoro statunitensi oggi, e i robot un ulteriore 13%, per circa il 57% delle ore di lavoro combinate sotto la tecnologia attualmente dimostrata (McKinsey, riportato da Robotics & Automation News). Quel 44% di quota agenti è il numero rilevante qui: rappresenta lavoro che dipende da lettura, interpretazione e decisione — il tipo di compito che l'RPA non è mai stato costruito per toccare, e quello per cui un dipendente IA è fatto.
Un Confronto Diretto per la Decisione Reale
| Domanda | Favorisce l'RPA | Favorisce un dipendente IA |
|---|---|---|
| Il formato di input è fisso e strutturato? | Sì — stessi campi, stesso layout, ogni volta | No — email, PDF, messaggi di chat in formati variabili |
| Il compito richiede giudizio su casi ambigui? | No — una logica pulita basata su regole basta | Sì — le eccezioni richiedono ragionamento, non solo instradamento a un umano |
| L'interfaccia cambia spesso? | No — un sistema o modulo legacy stabile | Meno importante — il ragionamento non dipende da una UI fissa |
| Il compito copre più canali (email, WhatsApp, voce)? | Raramente — l'RPA è di solito mono-sistema | Spesso — un agente può leggere attraverso i canali in un unico record |
| La verificabilità di ogni passo scriptato è la priorità? | Sì — gli script fissi dell'RPA sono completamente tracciabili | Richiede una progettazione esplicita di logging — il ragionamento è intrinsecamente meno tracciabile |
| Il compito è davvero automatizzabile end-to-end con regole fisse? | Sì | Se sì, l'RPA è probabilmente la risposta più economica |
La lettura onesta di questa tabella: la maggior parte dei processi aziendali reali è un mix. Un flusso di ordini di vendita potrebbe usare un dipendente IA per leggere l'ordine in arrivo e decidere come classificarlo, poi passare un record pulito, ora strutturato, a un passo semplice e più economico basato su regole per pubblicarlo effettivamente nell'ERP. Trattare RPA e dipendente IA come scelte mutuamente esclusive di solito significa sovra-costruire uno dei due per una parte del compito a cui non era mai stato adatto.
Perché Questa Decisione Sta Diventando Più Urgente, Non Meno
La previsione di dicembre 2025 di Gartner sulle operazioni infrastrutturali proietta l'adozione enterprise dell'IA agentica in crescita da meno del 5% nel 2025 al 70% entro il 2029, insieme a un parallelo declino della revisione umana nel ciclo dal 95% al 40% nei flussi operativi IT entro il 2028 (Gartner Predicts 2026: AI Agents Will Transform IT Infrastructure and Operations). La stessa previsione traccia una linea netta tra autonomia reale dell'agente e "assistenti rietichettati o RPA" — un avvertimento che un'interfaccia da chatbot incollata su uno script non è la stessa cosa di un sistema che ragiona davvero su input non strutturato, e gli acquirenti che valutano fornitori nel 2026 dovrebbero aspettarsi che entrambi vengano proposti con un linguaggio simile.
Questa distinzione è l'insegnamento pratico per chiunque calibri un progetto: chiedete cosa succede quando l'input non corrisponde al formato previsto. Uno strumento basato su RPA, comunque venga commercializzato, instrada quel caso verso un umano. Un dipendente IA dovrebbe ragionarci sopra. Se un fornitore non riesce a dimostrare questo secondo comportamento su un esempio reale tratto dai vostri documenti, state probabilmente guardando RPA con uno strato conversazionale sopra, non la categoria sotto cui viene venduto.
Da Dove Iniziare
Mappate il compito, non lo strumento. Elencate ogni formato di input che il compito riceve davvero oggi — incluse le versioni disordinate che nessuno vuole ammettere essere comuni — e i punti decisionali dove un umano applica oggi il giudizio invece di una regola fissa. I compiti con input 100% strutturato e logica 100% basata su regole sono candidati RPA, punto; costruire un dipendente IA per loro è sovra-ingegnerizzazione. I compiti con reale variabilità nel formato di input o reali chiamate al giudizio nei punti decisionali sono territorio del dipendente IA, e forzare uno script RPA su di essi sposta solo la pila di eccezioni da "un umano la gestisce" a "un umano la gestisce, dopo che il bot ha fallito per primo". Per come VoxDonna calibra questo esercizio di mappatura prima di raccomandare uno dei due approcci, vedi la consulenza di automazione IA di VoxDonna.