RPA, workflow e agenti AI: come automatizzare i processi

Conviene mantenere i passaggi fissi nelle automazioni già in uso, dalla RPA ai workflow. L'automazione agentica dei processi trova il suo spazio quando un'eccezione richiede un'indagine: interpretare dati poco ordinati, decidere quali informazioni cercare e proporre una soluzione. Confrontando 3 approcci allo stesso problema di fatturazione, emerge un confine utile: delegare prima l'indagine, poi l'autorità di agire.

Che cos'è l'automazione agentica dei processi?

L'automazione agentica dei processi, o APA, affida a un agente AI la scelta di alcuni passaggi necessari per raggiungere un risultato aziendale. L'agente interpreta il caso, sceglie uno strumento tra quelli consentiti, esamina il risultato e decide come proseguire. Le attività che precedono e seguono questo intervento possono continuare a essere svolte da bot, integrazioni tra applicazioni e persone.

La differenza è quella tra un impiegato che segue una lista di controllo e chi conduce un'indagine. La lista indica all'impiegato quale documento aprire dopo. Chi indaga sceglie invece il prossimo documento in base a ciò che ha scoperto nel precedente. Entrambi devono poter accedere ai documenti; nessuno dei due riceve poteri di firma illimitati.

Questa distinzione conta più della presenza della parola «agentic» nel nome di un prodotto.

Come definisce l'APA Automation Anywhere?

Automation Anywhere, fornitore di soluzioni di automazione aziendale, definisce l'APA a partire da workflow adattabili eseguiti da agenti AI, capaci di pianificare e prendere decisioni lungo più passaggi. La sua definizione presenta inoltre l'APA come un'estensione delle automazioni esistenti. La piattaforma combina agenti, automazione robotica dei processi, API e competenze umane. Un'API è l'interfaccia con cui un software richiede dati o azioni a un'altra applicazione. La definizione di APA di Automation Anywhere, panoramica della piattaforma.

Per chi dirige le operations, la conseguenza è concreta: il bot già in uso può continuare a eseguire nel sistema contabile le azioni approvate. Il nuovo agente può intervenire prima, per capire perché il caso non ha superato i controlli ordinari.

Come definisce l'automazione agentica UiPath?

UiPath, un altro fornitore di automazione aziendale, usa il termine automazione agentica. Descrive agenti che interpretano l'ambiente in cui operano, ragionano sulle informazioni disponibili e pianificano azioni per raggiungere un obiettivo. La sua spiegazione distingue questo approccio sia dai robot basati su regole sia dalle funzionalità AI inserite in processi i cui passaggi sono già stati stabiliti da persone. Mantiene inoltre un ruolo esplicito per la RPA. La definizione di automazione agentica di UiPath.

Il punto in comune è il cambiamento di chi sceglie l'azione successiva. Questo non dimostra che un agente sappia risolvere ogni eccezione, né che debba poter autorizzare l'esito.

Le definizioni e la documentazione tecnica citata sono state verificate il 26 ottobre 2026. L'esempio sulla fattura che segue illustra una possibile progettazione del processo: non descrive un'implementazione reale né un benchmark delle prestazioni.

RPA, workflow e APA: che cosa cambia?

La scelta dipende da come viene deciso il passaggio successivo e da come si può accedere all'applicazione.

Sono modelli progettuali utili, non categorie di prodotto chiuse. Una piattaforma RPA può includere integrazioni API; un workflow può chiamare un bot; un agente può usare entrambi. La stessa architettura di Automation Anywhere combina RPA, API, AI e orchestrazione, cioè il coordinamento delle attività tra questi componenti. Panoramica di Automation 360.

Aggiungere l'AI a un passaggio fisso non rende automaticamente agentico il processo. Un sistema di estrazione documentale può restituire numero della fattura, fornitore e totale, lasciando poi a regole prestabilite la scelta di ogni passaggio successivo. La documentazione tecnica di UiPath chiarisce questa distinzione: i workflow possono includere modelli linguistici mantenendo un flusso di controllo predefinito. Gli agenti introducono invece una pianificazione e una scelta degli strumenti che dipendono dal contesto. La documentazione di UiPath su agenti e workflow.

Zapier, un servizio di automazione tra applicazioni, offre un esempio familiare di flusso fisso: un evento attiva uno Zap, che esegue le azioni configurate. La domanda da porsi in fase di progettazione è se quelle azioni esprimano già la regola aziendale. Se è così, serve a poco introdurre un agente che le scelga di nuovo. La documentazione di Zapier sui trigger.

Una fattura non torna: tre modi per gestire l'eccezione

Una discrepanza in fattura è un buon caso d'uso per un agente solo se risolverla richiede un'indagine. Individuare la discrepanza e calcolare la differenza possono restare compiti dell'automazione ordinaria.

Consideriamo sempre lo stesso caso ipotetico: la fattura di un fornitore non corrisponde all'ordine di acquisto. Un'email del fornitore cita una modifica, mentre il sistema di ricevimento merci registra una consegna parziale. L'obiettivo è ricostruire l'accaduto e preparare l'azione corretta, senza modificare i dati di pagamento né disporre il pagamento.

Supponiamo che i campi del documento siano già stati estratti e verificati. Se il collo di bottiglia è quello, l'elaborazione intelligente dei documenti si occupa della lettura e della strutturazione del contenuto. Decidere quali riscontri cercare è un problema distinto.

RPA: seguire lo script a schermo e inoltrare l'eccezione

Il bot apre l'applicazione contabile, cerca l'ordine di acquisto, legge il documento di ricevimento e confronta i campi estratti dalla fattura secondo le regole programmate. Una discrepanza nota può attivare un percorso di eccezione già predisposto: allegare i documenti a una pratica e assegnarla a un addetto alla contabilità fornitori.

Una fattura insolita non deve necessariamente mandare in errore il bot. Lo sviluppatore può prevedere nuovi tentativi, controlli di validità e diverse diramazioni per le eccezioni. Il limite emerge quando l'indagine necessaria esce dai percorsi previsti.

In questo caso, «il fornitore dice che l'ordine è cambiato» non dimostra che la modifica sia stata autorizzata. Qualcuno deve trovare l'approvazione pertinente e verificare come si concili con la consegna parziale. Se lo script non prevede una regola per questa indagine, passa il caso a una persona.

Questo schema resta valido quando le schermate sono stabili e l'eccezione è prevedibile. Se gli addetti fanno sempre la stessa ricerca e applicano sempre la stessa regola, può bastare aggiungere quella diramazione al bot.

Workflow: interrogare i sistemi via API e applicare regole note

Il workflow riceve un evento relativo alla fattura, recupera l'ordine di acquisto e il documento di ricevimento tramite le API supportate, verifica i campi e invia la discrepanza a una coda di eccezioni. Si può aggiungere un passaggio di estrazione o classificazione dell'email del fornitore mantenendo fisse le decisioni successive.

Questa soluzione evita le specifiche interazioni con le schermate usate nell'esempio RPA. Richiede comunque una regola esplicita per il caso. Se esiste una modifica autorizzata all'ordine di acquisto, si segue la diramazione corrispondente. Altrimenti, la fattura resta sospesa e si chiede un chiarimento al responsabile.

Un workflow può essere sofisticato senza essere agentico. Un lungo albero di diramazioni resta un albero di diramazioni. Il limite rilevante è lo sforzo necessario per elencare e mantenere tutti i percorsi, non il numero di sistemi collegati.

Questo schema è preferibile quando le evidenze necessarie e le regole decisionali sono note. Cercare ogni volta un ordine di acquisto e un documento di ricevimento non richiede un agente solo perché i due si trovano in applicazioni diverse.

Approccio agentico: indagare sulla discrepanza e proporre una soluzione

Il workflow predefinito passa il caso irrisolto a un agente con un obiettivo circoscritto: spiegare la discrepanza, individuare le evidenze mancanti e raccomandare un'azione successiva tra quelle consentite.

Un'indagine entro limiti definiti potrebbe svolgersi così:

1. Leggere la fattura, l'ordine di acquisto e il documento di ricevimento allegati alla pratica.
2. Interpretare l'email del fornitore come un'affermazione su una modifica, poi cercare nella corrispondenza dell'ufficio acquisti autorizzata alla consultazione una prova dell'approvazione.
3. Usare il risultato della ricerca per decidere se esaminare una modifica all'ordine, un documento di consegna o una registrazione di approvazione interna.
4. Formulare una raccomandazione con link ai documenti di supporto e un'indicazione chiara dei punti ancora irrisolti.
5. Inoltrare l'azione proposta al percorso di approvazione ed esecuzione già esistente.

Il contributo dell'agente consiste nello scegliere la prossima ricerca utile. Non può far esistere un'approvazione mai concessa. Se le evidenze restano contraddittorie, il risultato utile è una sospensione motivata, accompagnata da una domanda mirata al responsabile acquisti.

In questo progetto pilota, l'agente non deve poter modificare le coordinate bancarie del fornitore, cambiare l'ordine di acquisto o disporre il pagamento. Dopo che un addetto ha autorizzato una soluzione specifica, un workflow predefinito o un bot può eseguire l'aggiornamento consentito.

Quando la capacità di valutazione di un agente giustifica il costo

Un agente è utile dove raccogliere e interpretare le evidenze richiede più lavoro che applicare la regola finale. Il suo valore deve compensare le chiamate aggiuntive al modello, i tempi di esecuzione, il lavoro di verifica e la manutenzione che introduce.

Eccezioni: un ufficio acquisti riceve segnalazioni di discrepanze dovute a cause diverse. Alcune richiedono una modifica all'ordine, altre un documento di consegna, altre ancora un chiarimento dal responsabile acquisti. Un agente può aiutare a scegliere come indagare. Una differenza ricorrente di arrotondamento, con una tolleranza esplicita, va invece gestita con una regola.

Dati non strutturati: un team che gestisce un servizio riceve email che mescolano una richiesta, un reclamo e riferimenti ad attività precedenti. Il contesto può determinare quale documento esaminare. Un modulo standard con campi obbligatori, di solito, fornisce già informazioni sufficienti a un workflow predefinito.

Ricerche su più sistemi: una contestazione relativa a un conto può richiedere una sequenza variabile di ricerche tra ordini, consegne e corrispondenza. È diverso da una riconciliazione programmata che unisce sempre gli stessi record tramite lo stesso identificativo. Quest'ultima deve restare deterministica, cioè basare le proprie decisioni su regole esplicite.

Sono ipotesi progettuali da valutare, non promesse di risparmio. Occorre misurare se gli addetti impiegano meno tempo per arrivare a una decisione corretta, includendo il lavoro necessario per le correzioni. Una spiegazione scorrevole che costringe comunque a ripetere ogni ricerca ha eliminato ben poco lavoro.

Quali controlli servono quando interviene un agente?

I limiti devono riguardare ciò che l'agente può effettivamente fare, non soltanto ciò che gli viene chiesto nel prompt. Una proposta utile e un'azione aziendale autorizzata sono due eventi distinti.

Approvazioni: autorizzare l'azione specifica

L'approvazione deve arrivare prima dell'operazione di scrittura protetta. Chi verifica deve vedere il record interessato, le modifiche proposte, le evidenze e gli eventuali punti irrisolti. «Approva questa fattura» è troppo vago se lo strumento può anche cambiarne il fornitore, l'importo o la destinazione del pagamento.

L'approvazione va legata all'esatta azione proposta e allo stato rilevante del record. Se uno dei due cambia mentre la richiesta è in attesa, occorre ripetere la validazione e, dove necessario, ottenere una nuova approvazione. L'agente non deve poter sostituire il contenuto approvato della richiesta con uno nuovo.

n8n, una piattaforma di automazione dei workflow con strumenti per agenti AI, documenta una realizzazione concreta di questo schema: le chiamate a determinati strumenti possono essere sospese per una verifica umana. Il revisore vede lo strumento e i suoi parametri; l'approvazione ne avvia l'esecuzione con quei dati, mentre il rifiuto annulla l'azione. La documentazione di n8n sulla verifica umana.

Per configurare questo meccanismo, si apre il connettore Tools del nodo AI Agent, si sceglie e configura un canale Human review e si collegano al passaggio di verifica gli strumenti che richiedono approvazione. Poi si provano sia l'accettazione sia il rifiuto. Il meccanismo della piattaforma richiede comunque una politica aziendale: quali modifiche vanno verificate, chi può approvarle e che cosa succede quando queste persone non sono disponibili.

La guida all'AI con supervisione umana approfondisce la progettazione delle verifiche e dei passaggi ai responsabili. Una pausa senza un revisore responsabile diventa un processo bloccato.

Permessi: separare lettura e scrittura

Il passaggio di indagine deve poter accedere ai soli record necessari. Vanno esposti strumenti circoscritti, per esempio per leggere un ordine o preparare una nota sulla pratica, anziché consentire un accesso illimitato al database o al browser.

Le scritture protette devono passare da un servizio o da una fase di esecuzione separati, che verifichino direttamente l'autorizzazione. Nell'esempio della fattura, l'agente può richiedere un aggiornamento; prima di applicarlo, l'esecutore controlla i campi approvati, l'identità del record e il suo stato corrente.

Le email e gli allegati dei fornitori vanno trattati come evidenze, non come istruzioni. Un testo che chiede all'agente di cambiare le coordinate bancarie non deve poter prevalere sui suoi permessi o sulle regole del processo.

Log: conservare le evidenze e la traccia delle azioni

Occorre conservare informazioni sufficienti a ricostruire la decisione aziendale: identificativo della pratica, record recuperati, versioni pertinenti dei documenti, richieste e risposte degli strumenti, raccomandazione, approvazione o rifiuto, risultato dell'esecuzione e indicazioni temporali. Vanno registrate anche le versioni del modello, del prompt e delle politiche utilizzate, così da poter ricondurre una modifica successiva ai casi interessati.

Una spiegazione concisa della decisione, con riferimenti alle evidenze, è utile. Una trascrizione di ragionamenti ipotetici non sostituisce la prova di quale record sia stato letto e di quale azione sia stata eseguita. I contenuti sensibili nei log vanno protetti con regole adeguate di accesso e conservazione.

Per chi verifica la fattura, il criterio è semplice: può aprire la modifica all'ordine citata e vedere che cosa è stato effettivamente approvato?

Limiti: ogni indagine deve avere una fine

Servono limiti espliciti per il tempo trascorso, le chiamate agli strumenti, i nuovi tentativi, il materiale recuperato e l'utilizzo del modello. Vanno definiti i sistemi e i tipi di azione consentiti. Al raggiungimento di un limite, il caso e le evidenze raccolte fino a quel momento devono tornare a una persona.

Non esiste un valore numerico universale per questi limiti. Occorre stabilirli in base alle scadenze del processo, al carico di verifica accettabile e al comportamento osservato nel progetto pilota. Deve essere il motore di esecuzione del workflow a farli rispettare: non possono restare suggerimenti nascosti in un prompt.

Un'azione rifiutata non deve poter rientrare attraverso un altro strumento. Se lo strumento per aggiornare i dati del fornitore è bloccato, un browser privo di restrizioni non deve offrire una via alternativa per effettuare la stessa modifica.

Recupero dagli errori: verificare prima di ripetere una scrittura

Quando l'esito di uno strumento è incerto, occorre controllare lo stato. Se la connessione cade dopo un aggiornamento, il sistema potrebbe averlo completato anche se l'agente non ha ricevuto conferma.

Dove il sistema di destinazione lo consente, va usata una chiave di idempotenza: un identificativo stabile che impedisce di applicare due volte la stessa azione autorizzata. Altrimenti, bisogna progettare un controllo equivalente contro i duplicati e un percorso di riconciliazione. Devono restare disponibili un comando di arresto per l'operatore e una procedura per rimediare alle operazioni completate solo in parte.

Sono requisiti di implementazione da verificare, non funzionalità che ogni prodotto APA offre automaticamente. A chi realizza il sistema va chiesto di dimostrare come gestisce un'approvazione rifiutata, un record non più aggiornato, una richiesta ripetuta, una fonte mancante e il raggiungimento di un limite.

Quali promesse sono esagerate?

L'autonomia dell'intero processo è una cattiva specifica di partenza. Il processo di gestione di una fattura comprende lettura dei documenti, calcoli, raccolta delle evidenze, autorizzazione e registrazione contabile. Non tutti questi passaggi traggono vantaggio dallo stesso modello di esecuzione.

«Impara nel tempo» non è un piano operativo. Bisogna chiedere che cosa cambia: la memoria dei casi, un prompt, una fonte consultabile, un modello o una regola aziendale. Prima di introdurre modifiche in produzione serve una valutazione controllata. Ripetere un processo non dimostra, da solo, che le sue decisioni migliorino.

Gli agenti non eliminano il lavoro di integrazione. Servono comunque identificativi affidabili, permessi, interfacce adatte e un modo per verificare se un'azione è riuscita. Un agente capace di descrivere l'aggiornamento corretto ha ancora bisogno di un percorso controllato per eseguirlo.

La sicurezza con cui si risponde non è una prova. Una risposta categorica non dimostra che la modifica dichiarata dal fornitore sia stata autorizzata. Occorrono documenti di supporto e, se mancano, il caso deve poter restare irrisolto.

Il limite da considerare nella progettazione è la distanza tra individuare una soluzione plausibile e avere l'autorità per eseguirla. Una maggiore capacità di ragionamento, da sola, non colma questa distanza.

Chi dovrebbe iniziare subito, aspettare o mantenere i flussi attuali?

Chi dirige le operations e gestisce una coda di eccezioni può iniziare subito dall'indagine. Conviene scegliere una coda in cui gli addetti raccolgono ripetutamente informazioni di contesto, gli esiti consentiti sono chiari e si possono confrontare le raccomandazioni con le decisioni umane. Si parte con accesso in sola lettura.

CTO e sviluppatori dovrebbero rimandare un'autonomia estesa se mancano i controlli. Se non è possibile identificare i record in modo affidabile, verificare le chiamate agli strumenti o assegnare a qualcuno la responsabilità dei casi inoltrati, occorre prima sistemare queste basi. Per un confronto concreto a livello di piattaforma, si veda agenti e workflow in n8n a confronto.

Chi acquista software e chi guida una startup può mantenere i flussi fissi che funzionano. Una sequenza di onboarding affidabile o una sincronizzazione ordinaria non richiedono una migrazione solo perché una piattaforma ha introdotto gli agenti. Prima di ampliare l'ambito del progetto o acquistare un nuovo sistema, deve esserci una decisione specifica ancora irrisolta.

Domande frequenti su APA e RPA

Come si automatizza un processo?

Si parte dalla mappatura dell'evento di avvio, dei record necessari, delle decisioni, delle azioni consentite e del responsabile delle eccezioni. Per le regole esplicite si usa un'automazione predefinita, aggiungendo l'estrazione documentale dove serve. Un agente va sperimentato solo nel punto che richiede un'indagine. Quando le evidenze non bastano, il passaggio a chi deve occuparsene deve essere chiaro.

A che cosa serve UiPath?

UiPath serve ad automatizzare le attività aziendali, con robot per i compiti ripetibili e funzionalità agentiche per quelli che richiedono contesto e pianificazione. Una progettazione utile può combinare questi strumenti con l'intervento umano, anziché affidare ogni passaggio a un agente.

L'AI sostituisce la RPA?

No. UiPath descrive esplicitamente un ruolo duraturo per la RPA accanto agli agenti. Nell'esempio della fattura, un agente può condurre l'indagine mentre un bot esegue un aggiornamento autorizzato attraverso l'interfaccia dell'applicazione esistente.

Quali sono i 5 migliori strumenti RPA?

Non esiste una classifica universale dei cinque migliori strumenti per qualsiasi processo. La selezione va fatta in base alle applicazioni da controllare, alle integrazioni supportate, ai requisiti di distribuzione, al monitoraggio e alla gestione delle approvazioni. Il confronto tra strumenti di automazione AI presenta opzioni per l'automazione aziendale e dei workflow: queste categorie non sono intercambiabili.

La RPA serve ancora?

Sì. Svolgere attività ripetibili attraverso le schermate delle applicazioni esistenti resta un modello utile di automazione, soprattutto quando non è disponibile un'API adatta. Un compito prevedibile non diventa più adatto a un agente soltanto perché esiste da tempo.

Meglio la RPA o Selenium?

Selenium è un progetto di automazione del browser comunemente usato per testare i siti web, come spiega la sua documentazione. Se il risultato da ottenere è una suite di test, servono strumenti per il testing del browser. Per un processo aziendale vanno valutate esigenze più ampie: copertura delle applicazioni, pianificazione delle esecuzioni, credenziali, responsabilità delle eccezioni e gestione delle approvazioni.

La RPA è superata?

Un'implementazione va giudicata per affidabilità e carico di manutenzione. Un bot stabile può restare l'esecutore giusto. Uno script fragile che opera sulle schermate può trarre vantaggio da una sostituzione con API, ma è una scelta di integrazione che non richiede automaticamente una pianificazione agentica.

Qual è il principale concorrente di UiPath?

Automation Anywhere è un'alternativa diretta per il caso d'uso di automazione aziendale discusso qui. Per definire un fornitore come il principale occorrono un mercato delimitato e una misura aggiornata. Ai fini di questa scelta, conviene confrontare come ciascuno gestirebbe i requisiti relativi a eccezioni, approvazioni e recupero dagli errori.

Quali sono i tre tipi di RPA?

La panoramica sulla RPA di Automation Anywhere li distingue in attended, unattended e ibrida. L'automazione attended assiste una persona, quella unattended parte da eventi o pianificazioni programmati, quella ibrida combina le due modalità. Sono categorie che descrivono come il lavoro si svolge insieme alle persone; non stabiliscono se sia un agente a pianificare il passaggio successivo.

La documentazione di Selenium aiuta a tenere distinto il testing del browser dalla scelta sull'automazione dei processi aziendali descritta sopra.

Da dove cominciare lunedì

Si sceglie una coda di eccezioni relative alle fatture e si mettono per iscritto le azioni che l'addetto alla verifica può autorizzare. Il primo agente deve produrre una raccomandazione fondata su evidenze, senza il permesso di effettuare registrazioni contabili o pagamenti.

1. 1

   Documentare come si decide oggi

   Registrare quali fonti consultano gli addetti, perché scelgono la fonte successiva e quali casi restano irrisolti. Separare le ricerche ripetitive che potrebbero diventare regole fisse dalle indagini che dipendono da nuovo contesto.

2. 2

   Confrontare le raccomandazioni con gli esiti verificati

   Valutare evidenze mancanti, conclusioni prive di riscontro, casi non inoltrati quando necessario e lavoro di correzione richiesto agli addetti. Includere documenti contraddittori e ricerche fallite, non solo casi lineari. Misurare il tempo di lavoro che resta all'addetto dopo aver controllato la raccomandazione.

3. 3

   Aggiungere un'azione consentita alla volta

   Introdurre un'operazione di scrittura solo dopo aver dimostrato il funzionamento di approvazione, registrazione nei log, prevenzione dei duplicati e recupero dagli errori. Mantenere disponibile il percorso di esecuzione predefinito originale e assegnare a qualcuno la responsabilità delle eccezioni quando l'agente si ferma.

Per indicazioni pratiche su dove introdurre l'AI nelle attività aziendali, iscriviti alla newsletter.