RPA e automazione AI: che differenza c'è, e quale serve a una piccola impresa

La sigla RPA arriva in una piccola impresa quasi sempre da fuori: la porta un consulente, un fornitore di software, un articolo letto la sera. E porta con sé una promessa che suona bene, un robot che fa il lavoro d'ufficio al posto tuo. La promessa ha un fondo di verità e un contesto preciso, che è quello delle banche e delle assicurazioni di quindici anni fa. Fuori da quel contesto, la parola descrive quasi sempre lo strumento sbagliato per il problema giusto.

Cosa fa davvero una RPA#

Il nome trae in inganno due volte: non c'è nessun robot e non c'è nessuna intelligenza. C'è un programma che ripete, dentro le finestre di altri programmi, le mosse che una persona farebbe con mouse e tastiera. Apre il gestionale, clicca sul menu, incolla un numero nel campo, preme invio, passa alla finestra dopo.

La definizione di riferimento è quella che l'IEEE ha messo a standard nel 2017, nel documento 2755 sui termini dell'automazione dei processi: un'istanza software preconfigurata che usa regole di business e una coreografia di attività predefinita per eseguire in autonomia processi e transazioni «in uno o più sistemi software non collegati fra loro», con «gestione delle eccezioni affidata a una persona». Le parole che contano sono predefinita e non collegati: la sequenza è scritta prima, e i programmi in mezzo ai quali lavora non hanno un modo diretto per passarsi i dati.

Come faccia a lavorare dentro un programma senza esserci collegata lo dice bene Microsoft nella documentazione di Power Automate, dove i desktop flows sono la parte RPA dell'offerta: l'automazione interagisce con la macchina «usando gli elementi dell'interfaccia dell'applicazione, le immagini o le coordinate», e permette di automatizzare «anche applicazioni datate, come gli emulatori di terminale». Coordinate vuol dire: clicca nel punto dello schermo a 412 pixel da sinistra e 300 dall'alto, perché lì c'è il pulsante «Salva». Finché c'è.

Perché è nata, e per chi#

Immagina una banca nel 2012. Ha un sistema centrale scritto negli anni Novanta, che funziona benissimo e che nessuno oserebbe toccare, e intorno una dozzina di programmi più nuovi che hanno bisogno dei suoi dati. Il sistema vecchio non ha una porta di servizio, quella che in gergo si chiama API, l'interfaccia con cui un programma parla con un altro senza passare dallo schermo. L'unico modo per tirare fuori un dato è che un impiegato lo legga a video e lo ricopi.

Su quella scala, con centinaia di impiegati che ricopiano, la RPA ha senso: invece di rifare il sistema centrale, che costerebbe anni, si mette un software che ricopia al posto loro, alla stessa velocità di un impiegato veloce, senza pause. Non risolve il problema di fondo, che è l'assenza della porta. Lo aggira entrando dalla finestra.

Il modello di business dei fornitori è nato lì: licenze per robot, macchine dedicate su cui i robot girano con una sessione aperta, una squadra che li tiene in vita quando un programma cambia aspetto. È un impianto pensato per chi ha mille processi uguali e un reparto per gestirli.

Dove si rompe#

Il difetto della RPA è lo stesso della sua forza: guarda lo schermo, non capisce cosa c'è sopra. Ne discendono quattro modi tipici di rompersi.

Il pulsante si sposta. Il gestionale si aggiorna, il menu cambia ordine, una finestra di avviso compare dove prima non c'era. Il robot clicca dove cliccava e da quel momento fa una cosa diversa da quella per cui era stato scritto, oppure si ferma. Non sa che è cambiato qualcosa: sa solo che alle coordinate previste non c'è più quello che si aspettava.

Il documento non è nel formato previsto. La RPA legge campi, non testi. Una fattura in PDF con la tabella al posto giusto la gestisce; la stessa fattura impaginata in un altro modo, o un'email in cui il cliente scrive «ve ne servono quattro, come l'altra volta», no. È la ragione per cui i fornitori hanno cominciato ad aggiungere pezzi di intelligenza artificiale sopra: UiPath, il più noto di loro, la chiama AI automation e la descrive come RPA più apprendimento automatico per i processi «semi-strutturati» come l'elaborazione delle fatture e la classificazione delle email. Cioè: la RPA da sola non li sa fare.

Serve un computer acceso con una sessione aperta. Il robot lavora dentro un'interfaccia, quindi l'interfaccia deve esserci: un PC o un server dedicato, con l'utente collegato, il programma aperto, lo schermo alla risoluzione prevista. Ogni riavvio, ogni aggiornamento di sistema, ogni password scaduta è una mattina in cui il robot non ha lavorato e nessuno se n'è accorto.

Non spiega cosa ha fatto. Quando salta, il registro dice a che passo si è fermata. Non dice se i passi prima erano giusti, perché non aveva modo di saperlo. Un dato incollato nel campo sbagliato è un dato incollato, e resta lì finché qualcuno non lo trova.

Cosa fa invece un'automazione AI#

Un'automazione AI parte da un'altra domanda: non «come faccio a cliccare al posto di una persona», ma «dove stanno i dati e come li faccio passare da un programma all'altro senza toccare lo schermo».

La risposta oggi c'è quasi sempre, perché i programmi che una piccola impresa usa nel 2026 hanno la porta che al sistema della banca mancava. Il gestionale in cloud ha un'API. Il modulo del sito manda i dati in un formato leggibile da un altro programma. La fattura elettronica arriva già come file strutturato, non come immagine da ricopiare. La posta e il calendario si interrogano senza aprirli. Il foglio condiviso si legge e si scrive da fuori. Dove la porta manca del tutto, di solito c'è un'esportazione programmabile, e un'esportazione è una porta più lenta, ma è una porta.

Su questa base l'automazione fa quello che fa la RPA, spostare dati da un punto all'altro secondo una sequenza scritta prima, con una differenza che cambia tutto: passa dai dati, quindi non le importa dove sta il pulsante. Il gestionale può cambiare aspetto dieci volte, la porta resta la stessa.

Poi c'è la parola AI, che va presa alla lettera e non oltre: nella sequenza, uno o due passi vengono affidati a un modello linguistico, perché sono i passi che le regole non sanno fare. Leggere l'email del cliente e capire quale prodotto sta chiedendo. Prendere il PDF del fornitore, impaginato come gli pare, e tirarne fuori numero, data e importo. Scrivere una bozza di risposta che poi una persona rilegge. Il modello fa un mestiere dentro il giro, non decide il giro. Se decidesse il giro sarebbe un'altra cosa, e quell'altra cosa ha un articolo suo.

Un esempio montato per intero. Arriva una fattura da un fornitore, in PDF, per email. L'automazione la prende dalla casella, la passa a un modello che ne legge i quattro dati che servono, li confronta con l'ordine nel gestionale attraverso la sua API, e se tornano registra la fattura e la mette in coda al pagamento. Se non tornano, si ferma e avvisa una persona con i due documenti affiancati. Una RPA avrebbe fatto la stessa cosa solo con fatture tutte uguali, dentro una finestra che non deve mai cambiare, e senza il passo in cui il documento viene letto.