RPA: cos'è la robotic process automation e quando serve
Cos'è la RPA, come funzionano i robot software che imitano l'uso di un'interfaccia, quando conviene rispetto alle API e i limiti da conoscere prima.
In molte aziende esistono attività che nessun software gestisce: prendere un dato da un gestionale vecchio, incollarlo in un portale, salvare un PDF, aggiornare un foglio di calcolo. Ore di lavoro umano spese a spostare informazioni tra sistemi che non si parlano. La RPA nasce esattamente per quello — con un limite importante di cui si parla poco.
Cos'è la RPA
La robotic process automation è l'automazione di attività ripetitive tramite programmi che imitano le azioni di una persona su un'interfaccia: cliccano, digitano, leggono valori dallo schermo, copiano e incollano tra applicazioni.
Il "robotic" del nome è fuorviante: non c'è nulla di fisico. Si tratta di software che usa altro software dal davanti, come farebbe un utente.
In cosa differisce dalle altre automazioni
È la distinzione che chiarisce tutto il resto.
Un'automazione tradizionale collega i sistemi dal retro, attraverso le loro API: parla direttamente con il servizio, in un linguaggio pensato per lo scambio di dati. È il modello di Zapier, Make e n8n.
La RPA agisce dal davanti, sull'interfaccia. Non chiede il permesso a nessuno: apre il programma e lo usa.
| API / automazione | RPA | |
|---|---|---|
| Punto di contatto | Il retro del sistema | L'interfaccia |
| Serve collaborazione del fornitore | Sì | No |
| Stabilità | Alta | Fragile ai cambi grafici |
| Velocità | Alta | Lenta (simula azioni umane) |
| Funziona su software chiusi | No | Sì |
Da qui la conseguenza pratica più importante: la RPA è la soluzione quando l'integrazione vera non è possibile. Non è un'alternativa migliore alle API — è un ripiego che funziona.
Quando serve davvero
I casi in cui è la scelta giusta:
Software legacy senza API. Gestionali aziendali di vent'anni fa, applicazioni interne che nessuno mantiene più, terminali di sistemi storici. Non hanno modo di integrarsi e nessuno li riscriverà.
Portali esterni obbligatori. Siti di enti, portali di fornitori, sistemi di clienti su cui devi inserire dati manualmente e che non ti daranno mai un accesso programmatico.
Applicazioni desktop chiuse. Programmi installati che non espongono nulla.
Quando modificare il sistema non è un'opzione. Per costi, vincoli contrattuali o semplicemente perché l'azienda che l'ha fatto non esiste più.
Casi tipici concreti: riconciliare fatture tra due sistemi, inserire ordini ricevuti via email in un gestionale, estrarre dati da portali per un report, apertura di posizioni in software amministrativi.
Quando NON serve
Vale la pena essere netti, perché la RPA viene venduta più di quanto serva.
Se esiste un'API, usa quella. È più veloce, più stabile e non si rompe quando il fornitore cambia un pulsante di posto.
Se i due sistemi hanno già un'integrazione o un connettore in una piattaforma di automazione, il problema è risolto senza RPA.
Se il processo è confuso o cambia spesso. La RPA automatizza sequenze rigide: se ogni caso è diverso, la costruzione diventa un incubo di eccezioni.
Se il volume è basso. Il calcolo è quello che faccio in automazioni per freelance e PMI: un'attività da 5 minuti fatta due volte al mese non giustifica la costruzione e la manutenzione.
Se il vero problema è il processo. Automatizzare un passaggio inutile lo rende solo più veloce. Spesso la domanda giusta non è "come lo automatizzo" ma "perché lo stiamo facendo".
Il limite serio: la fragilità
Questo è il punto che va conosciuto prima di investirci.
Un robot RPA dipende dall'aspetto dell'interfaccia. Se il fornitore sposta un pulsante, aggiunge un campo, cambia grafica o introduce una finestra di conferma, il robot smette di funzionare — o peggio, fa la cosa sbagliata.
Le conseguenze pratiche:
La manutenzione non è occasionale, è strutturale. Ogni aggiornamento dei sistemi coinvolti è un rischio. Chi valuta la RPA guardando solo il costo di costruzione sottostima il totale in modo sistematico.
I fallimenti possono essere silenziosi. Un robot che clicca nel posto sbagliato può inserire dati errati senza segnalare nulla. Serve verifica sui risultati, non solo sul fatto che il processo sia terminato.
Serve un ambiente stabile. Aggiornamenti automatici del sistema operativo, risoluzioni dello schermo diverse, finestre che si aprono sopra: tutto può interferire.
Ed è il motivo per cui gli strumenti moderni cercano di ancorarsi a elementi strutturali dell'interfaccia invece che alle coordinate sullo schermo — più robusto, ma non immune.
Gli aspetti da non trascurare
Le credenziali. Un robot RPA opera con un'utenza che ha accessi ai sistemi. Quelle credenziali vanno gestite come qualunque altra credenziale sensibile, non scritte in un file di configurazione.
La tracciabilità. Le azioni compiute dal robot devono essere registrate e attribuibili. In ambito amministrativo e contabile è spesso un requisito, non un'opzione.
I dati personali. Se il robot movimenta dati di clienti o dipendenti, è un trattamento a tutti gli effetti — vale il quadro del GDPR.
I termini d'uso dei portali esterni. Automatizzare l'accesso a un portale altrui può essere vietato dalle sue condizioni. È lo stesso terreno che descrivo in cos'è il web scraping: tecnicamente possibile non significa contrattualmente permesso.
RPA e AI
Un'evoluzione che vale la pena conoscere, senza entusiasmi eccessivi.
Gli strumenti recenti aggiungono componenti che leggono documenti non strutturati (fatture, contratti) ed estraggono i dati, gestendo anche variazioni di formato. Riducono la rigidità della RPA classica, che richiedeva documenti sempre identici.
Ma introducono un problema nuovo: un componente che interpreta può sbagliare, e su dati amministrativi un errore silenzioso costa. Servono soglie di confidenza e passaggio a verifica umana sui casi incerti.
E in prospettiva, gli agenti AI capaci di usare interfacce sono, concettualmente, RPA più flessibile — con gli stessi rischi amplificati, come descrivo in guardrail e prompt injection.
In sintesi
La RPA automatizza attività ripetitive facendo usare a un programma le interfacce pensate per le persone. La sua ragione d'essere è una: funziona dove l'integrazione vera non è possibile — software legacy, portali esterni, applicazioni chiuse.
Non è un'alternativa migliore alle API: se un'API esiste, quella è sempre la strada giusta. La RPA è un ripiego efficace, non una scelta preferibile.
Il limite da mettere in conto prima di investirci è la fragilità: dipende dall'aspetto delle interfacce, quindi si rompe agli aggiornamenti, e la manutenzione è un costo ricorrente, non un imprevisto.
E la domanda da farsi prima di tutto il resto: quel processo va automatizzato, o va eliminato? Automatizzare un passaggio inutile lo rende solo più veloce.
Se hai processi manuali che consumano ore e vuoi capire cosa conviene automatizzare davvero, la consulenza business online parte da questa analisi.