Differenza tra RPA e intelligenza artificiale: quale dei due ti serve davvero
La differenza tra RPA e intelligenza artificiale è che la RPA esegue una regola scritta prima da una persona, mentre un modello di intelligenza artificiale produce una risposta che nessuno ha scritto prima. Detta così sembra una distinzione da manuale. In pratica è la riga che decide quanto costa la tua automazione, perché una regola si paga una volta sola mentre un modello si paga a ogni singola esecuzione.
La domanda con cui la gente arriva è quasi sempre sbagliata. Non è quale delle due tecnologie sia migliore: dentro un sistema che gira davvero ci sono quasi sempre tutte e due, e l'unica cosa che conta è dove passa il confine fra la parte che segue una regola e la parte che decide. Sbagliare quel confine è il modo più rapido per costruire qualcosa che costa dieci volte tanto e si rompe di più.
Differenza tra RPA e intelligenza artificiale: regola contro giudizio
La RPA, sigla di robotic process automation, è software che ripete azioni umane dentro le interfacce dei programmi. UiPath, il fornitore più diffuso della categoria, la descrive sul proprio sito come l'uso di "software robots to automate repetitive, rule-based tasks like entering data, moving files, or processing transactions", e precisa che quei robot "mimic human actions in interacting with screens and systems". Sono programmi che cliccano al posto tuo, dentro schermate pensate per un essere umano.
Un modello di intelligenza artificiale non ripete azioni, produce un output a partire dai dati che riceve. La pagina che IBM dedica alla RPA riassume la distinzione in una riga che vale la pena rubare: "The critical difference is that RPA is process-driven, whereas AI is data-driven". Sempre IBM mette per iscritto il limite che nella pratica conta di più, cioè che "RPA bots can follow only the processes defined by an end user".
Il confronto si fa sul dato in ingresso, non sulla tecnologia
Il criterio che separa davvero i due mondi è la forma del dato che entra nel processo. Se quel dato ha sempre la stessa forma, una regola vince su tutto: è più veloce, non costa niente a esecuzione e quando sbaglia sbaglia sempre nello stesso modo, quindi l'errore si trova in mezz'ora. Se il dato cambia forma ogni volta, la regola diventa un albero di eccezioni che dopo sei mesi non mantiene più nessuno, ed è lì che il modello si guadagna il posto. Il resto del confronto sono dettagli commerciali.
RPA e AI a confronto: la tabella con cui decido
| RPA | Modello AI | |
|---|---|---|
| Cosa esegue | una regola scritta prima | un giudizio prodotto sul momento |
| Dato in ingresso | strutturato, forma fissa | anche non strutturato |
| Esito a parità di input | sempre identico | può variare |
| Quando si paga | una volta, allo sviluppo | a ogni esecuzione, a token |
| Dove si rompe | quando cambia la schermata | quando l'input esce dai casi previsti |
| Come si corregge | si riscrive la regola | si cambiano prompt, contesto o modello |
La riga che decide quasi sempre è la quarta. Un robot RPA che gira diecimila volte al mese costa uguale a uno che gira dieci volte, mentre diecimila chiamate a un modello si vedono in fattura il mese stesso. Chi ha già fatto il conto per un sistema completo lo trova spiegato voce per voce nell'articolo su quanto costa un agente AI in azienda.
La riga sull'esito è la seconda per importanza e viene sottovalutata sempre. Un processo che a parità di input può dare risposte diverse non è un processo che puoi certificare, e questo esclude il modello da tutti i passaggi dove serve dimostrare che due pratiche identiche sono state trattate in modo identico.
Come si sceglie: se la regola sta in una frase, non serve un modello
Il criterio che uso è meccanico: prova a scrivere la regola in una frase sola, senza usare la parola "dipende". Se ci riesci, quel passaggio è RPA e va scritto come codice normale, che sia uno script o uno strumento tipo quelli che ho confrontato in n8n o Make, quale scegliere. Se la frase ti viene lunga tre righe e piena di "tranne quando", quel passaggio è il punto in cui serve un modello.
Anthropic dà la stessa indicazione dal lato di chi costruisce agenti. Nel documento Building effective agents, pubblicato il 19 dicembre 2024, l'azienda distingue i workflow, definiti "systems where LLMs and tools are orchestrated through predefined code paths", dagli agenti, cioè "systems where LLMs dynamically direct their own processes and tool usage". E raccomanda in modo esplicito di "finding the simplest solution possible, and only increasing complexity when needed", arrivando a scrivere che questo può voler dire non costruire affatto un sistema agentico. I passaggi che restano dopo questa sfoltitura sono quelli descritti in come creare un agente AI in azienda.
Il costo che si scopre dopo
Il costo di un modello non è solo la bolletta a fine mese. Anthropic lo mette nero su bianco nello stesso documento: "Agentic systems often trade latency and cost for better task performance". Nella pratica di tutti i giorni vuol dire che ogni passaggio affidato a un modello aggiunge secondi di attesa, una tariffa a token e un esito che domani non riprodurrai identico. Chi vuole capire da dove nasce quella variabilità trova la meccanica spiegata in come funziona un modello di linguaggio.
Dove ho messo il confine nella mia automazione
Il sito marcomasut.com ha un'automazione che scrive articoli, e in quella pipeline il confine fra regola e giudizio si vede a occhio nudo. Nella cartella automazione-blog del repository c'è un sistema che ogni giorno recupera una trascrizione, ne ricava una bozza e apre una Pull Request. Di tutti quei passaggi uno solo usa un modello, la scrittura. Il recupero della trascrizione è una chiamata HTTP a un endpoint protetto da token, il commit è git, la pubblicazione è una build, la notifica ai motori di ricerca è uno script che si lancia con npm run seo:indexnow e vive in scripts/indexnow.ts.
Il recupero della trascrizione, il commit, la build e la notifica ai motori non meritavano un modello, perché ognuno di quei quattro passaggi si scrive in una frase senza dipende. Il README di quella cartella è esplicito anche su cosa resta fuori dall'automazione: in quel flusso la pubblicazione non è automatica, l'ultimo anello è una revisione umana. Il punto meno deterministico della catena è quello dove è stata messa la persona, non quello dove era più comodo metterla.
Come si trova il confine nel tuo processo, in dieci minuti
La cosa concreta da fare oggi, se stai valutando un progetto, è questa: prendi il processo che vuoi automatizzare, scrivi i passaggi in colonna e segna ognuno con una R o una M. Se le M sono più di una su cinque, quasi sempre hai messo il modello dove bastava una regola. Se ti accorgi che il processo non lo sai scrivere in colonna, il problema non è scegliere fra RPA e intelligenza artificiale, è che il processo non è ancora definito: è la fase che copro con la consulenza sull'automazione dei processi, e viene prima di qualsiasi acquisto di licenze.
La posizione, in una riga: la RPA non è morta e il modello non è un aggiornamento della RPA. Sono due strumenti che rispondono a due domande diverse, e il valore di chi costruisce sta tutto nel decidere quale domanda ha davanti, prima di aprire l'editor. Sulla differenza fra un sistema che risponde e uno che agisce ho scritto anche la differenza tra chatbot e agente AI.
Fonti primarie: la definizione di RPA di UiPath, la pagina di IBM sulla robotic process automation e il documento di Anthropic Building effective agents.
Domande frequenti
La RPA è una tecnologia superata dall'AI?
No, e i fornitori stessi non la presentano così. La RPA resta il modo più economico di far ripetere a una macchina un'operazione che ha sempre la stessa forma, e continua a essere l'unico modo di pilotare programmi vecchi che non espongono nessuna API. Quello che è cambiato è il perimetro: la RPA ha smesso di essere la risposta a tutto ed è tornata a essere la risposta a una parte.
Un agente AI può usare i programmi aziendali che non hanno API?
Sì, ma il modo in cui lo fa somiglia molto alla RPA e ne eredita la fragilità. Un agente che clicca dentro un'interfaccia dipende dalla posizione dei pulsanti esattamente come un robot RPA, con in più il costo di una chiamata al modello a ogni passaggio. Quando il programma espone un'API, anche minima, conviene sempre passare da lì e lasciare al modello solo la decisione.
Come si misura se un passaggio conviene affidarlo a un modello?
Si misura su tre numeri, e vanno presi prima di costruire: quante volte al mese quel passaggio viene eseguito, quanti casi diversi deve gestire e quanto costa un errore singolo. Un passaggio eseguito mille volte al mese su due soli casi possibili è quasi sempre una regola. Un passaggio eseguito venti volte al mese su input che non si somigliano mai è quasi sempre un modello.
Chi risponde se un'automazione sbaglia?
Risponde sempre l'azienda che la usa, non il fornitore del modello né quello della piattaforma RPA. È il motivo per cui i passaggi irreversibili, come un pagamento o l'invio di un documento a un cliente, non vanno lasciati all'ultimo anello della catena. La revisione umana si mette dove l'errore non si può annullare, non dove è più comoda.
Si può partire dalla RPA e aggiungere l'AI dopo?
È l'ordine che funziona meglio, perché costringe a mappare il processo prima di comprare qualcosa. Automatizzare per prima la parte deterministica rende visibili i punti in cui il processo si ferma davvero, e quei punti sono esattamente quelli in cui vale la pena mettere un modello. Il percorso inverso, cioè partire dal modello, di solito produce un sistema che indovina cose che erano già scritte da qualche parte.