RPA automatizza un compito guidando gli schermi che una persona utilizzerebbe: accede con il proprio account, trova il pulsante tramite un selettore o la sua posizione, digita nel campo e clicca su Salva. Un agente AI automatizza lo stesso compito chiamando uno strumento che il sistema espone per i chiamanti macchina, con un nome, un input digitato e un controllo di autorizzazione dietro di esso. La differenza è l'interfaccia, e l'interfaccia decide come si comporta l'automazione quando qualcosa cambia.
RPA rimane la scelta giusta quando il sistema non ha affatto un'interfaccia per le macchine: un'applicazione desktop legacy, un emulatore di terminale, un portale fornitori che non controlli. Dove un sistema espone le sue azioni come strumenti, un agente che le chiama è meno fragile, agisce sotto le autorizzazioni della persona che rappresenta e può gestire variazioni per cui un bot dovrebbe essere programmato. Gli stessi fornitori di RPA ora descrivono i robot come uno strato di esecuzione su cui gli agenti fanno affidamento, che è l'immagine accurata.
Cosa fa realmente un bot
Inizia con l'architettura, perché il confronto tra agenti AI e RPA è definito da essa. UiPath, il più grande fornitore di RPA, descrive i suoi robot software come "che imitano le azioni umane nell'interazione con schermi e sistemi" per gestire "compiti ripetitivi e basati su regole come l'inserimento di dati, il trasferimento di file o l'elaborazione di transazioni". I flussi desktop di Microsoft, il suo prodotto RPA all'interno di Power Automate, dicono la stessa cosa in termini meccanici: puoi "interagire con la macchina utilizzando elementi dell'interfaccia utente dell'applicazione, immagini o coordinate", contro "applicazioni legacy, come emulatori di terminale, applicazioni web e desktop moderne, file Excel e cartelle". Un bot può funzionare in presenza, accanto a una persona alla scrivania, o non presidiato, su una macchina propria.
Prendi un compito concreto: registrare una ricevuta di beni in un sistema di magazzino più vecchio che non ha API. Il bot apre l'applicazione, si sposta nel menu fino al modulo delle ricevute, cerca l'ordine di acquisto, si sposta nel campo quantità per ogni riga, digita il numero e preme il tasto Salva. Una persona ha registrato quei passaggi una volta; il bot li riproduce migliaia di volte, più velocemente e senza trasporre le cifre. Per un'applicazione stabile con un alto volume e senza altre modalità di accesso, questo è un buon scambio, e si è ripagato in molti team di finanza e operazioni.
I fornitori dicono dove si inserisce, e hanno ragione. La definizione di UiPath è "compiti ad alto volume, ripetitivi e basati su regole, specialmente quelli che attraversano più sistemi": volume, determinismo e accesso a sistemi che non offrono nient'altro. Un confronto onesto mantiene questi elementi sul tavolo.
Perché si rompe e perché questo non è un difetto
Uno schermo è un contratto con una persona. Il suo layout, le etichette, l'ordine delle schede e la posizione del pulsante Salva sono promesse fatte agli occhi e a un puntatore, e nessuna di esse è promessa a una macchina. Quando il fornitore sposta il campo quantità in una nuova scheda, aggiunge un pop-up di conferma o rinomina un menu, la persona si adatta in secondi senza accorgersene. Il bot fallisce, o peggio, inserisce la quantità nel campo sbagliato e salva. Quel fallimento non dice nulla sulla competenza del fornitore RPA; l'interfaccia che è stata data al bot sta emergendo.
La stessa limitazione segue un modello linguistico quando viene utilizzato per gestire schermi. L'uso del computer di Anthropic dà a Claude "screenshot, controllo del mouse e della tastiera di un ambiente desktop", ed è genuinamente utile dove non esiste nient'altro. Ma la documentazione di Anthropic ti allontana da esso ogni volta che è disponibile un'interfaccia più stretta, raccomandando il suo strumento per browser per lavori che rimangono all'interno di una pagina web, e richiede "una persona per confermare decisioni che potrebbero avere conseguenze significative nel mondo reale", nominando tra queste le transazioni finanziarie. Un modello che guida uno schermo eredita la fragilità dello schermo e aggiunge la propria variabilità sopra. Questa è la combinazione meno attraente delle due categorie, ed è ciò a cui si riducono molte proposte di "RPA alimentata da AI".
Cosa chiama un agente invece
Un agente che opera un sistema aziendale costruito per agenti non vede mai uno schermo. Chiede al sistema cosa può fare e riceve un elenco di strumenti, ognuno con un nome, una descrizione scritta per il modello, uno schema per i suoi input e annotazioni opzionali che indicano se legge solo, se può distruggere dati e se chiamarlo due volte è sicuro. Il Model Context Protocol standardizza questo scambio: il cliente invia una richiesta per elencare gli strumenti, il modello ne sceglie uno, il cliente lo chiama con argomenti digitati, e il server lo esegue e restituisce un risultato. La specifica richiede ai server di "validare tutti gli input degli strumenti" e "implementare controlli di accesso adeguati", e dice ai clienti di "registrare l'uso degli strumenti per scopi di audit". Ecco la forma di uno di questi strumenti, utilizzando la ricevuta di beni di prima.
{
"name": "receiveStock",
"description": "Book goods received against a purchase order into a warehouse location. Fails if the order is closed or the caller cannot receive at that location.",
"inputSchema": {
"type": "object",
"properties": {
"order_ref": { "type": "string", "description": "Purchase order reference" },
"location_id": { "type": "string", "description": "Warehouse location to receive into" },
"lines": {
"type": "array",
"items": {
"type": "object",
"properties": {
"sku": { "type": "string" },
"quantity": { "type": "integer", "minimum": 1 }
},
"required": ["sku", "quantity"]
}
}
},
"required": ["order_ref", "lines"]
},
"annotations": { "readOnlyHint": false, "destructiveHint": false, "idempotentHint": false }
}Una definizione di strumento MCP nella forma che la specifica descrive, per la stessa ricevuta di beni in cui il bot stava digitando in un modulo. I nomi dei campi sono illustrativi; il punto è che uno strumento è un contratto, e un contratto può essere versionato, validato e autorizzato in modi che uno schermo non può.
Confronta cosa succede al cambiamento. Il fornitore ridisegna lo schermo delle ricevute: il bot si rompe, lo strumento rimane intatto. Il fornitore aggiunge un campo obbligatorio allo strumento: questo è un cambiamento versionato a un contratto pubblicato, annunciato nell'elenco degli strumenti, e l'agente legge il nuovo schema alla sua prossima chiamata. Confronta l'identità. Il bot accede come un account di servizio con qualsiasi accesso qualcuno gli abbia dato anni fa. L'agente chiama lo strumento come la persona che rappresenta, e il controllo dei permessi viene eseguito all'interno dello strumento, ad ogni chiamata, contro il ruolo di quella persona.
Deterministico contro probabilistico: il trade che nessuno dovrebbe nascondere
C'è un costo dal lato dell'agente, e i fornitori RPA lo dichiarano accuratamente nella loro documentazione per agenti: i robot "seguono logiche strutturate e regole fisse", mentre gli agenti adottano "un approccio probabilistico per prendere decisioni basate su modelli e dati in tempo reale". Un bot che ripete gli stessi passaggi dà lo stesso risultato per lo stesso input, e può essere dimostrato. Un agente dato lo stesso intento segue un percorso difendibile, di solito lo stesso, non sempre. Per un passaggio regolamentato in cui deve essere dimostrata la ripetibilità, o per un milione di transazioni identiche al mese, l'opzione deterministica è la scelta migliore, e dire il contrario sarebbe vendere.
Il vantaggio dell'agente è limitato alla variazione. Quando la ricevuta non corrisponde all'ordine, quando il fornitore ha inviato due consegne contro una linea, quando la quantità è plausibile ma l'unità è sbagliata, il bot non ha un ramo per questo e si ferma, o fa la cosa sbagliata con sicurezza. L'agente legge la discrepanza, controlla l'ordine, prenota ciò che corrisponde e chiede a una persona riguardo al resto. Questo è il lavoro che un tempo era una coda di eccezioni sulla scrivania di qualcuno, ed è il lavoro per cui esiste un agente.
Rivolgiti a RPA quando, rivolgiti a un agente quando
| Domanda | Raggiungi RPA | Raggiungi un agente |
|---|---|---|
| Il sistema espone azioni alle macchine? | No: solo schermi, un'applicazione desktop legacy, un terminale | Sì: un'API o un server MCP con strumenti tipizzati |
| Controlli il sistema? | No, e non cambierà per lei | Sì, o il fornitore pubblica e versiona i suoi strumenti |
| Quanto varia il compito? | Molto poco: gli stessi campi nello stesso ordine | Ogni caso richiede lettura e giudizio |
| L'input deve sempre dare lo stesso output? | Sì, e deve essere in grado di dimostrarlo | Un risultato difendibile con un log completo è sufficiente |
| Chi rappresenta? | Un account di servizio con il proprio accesso | La persona che rappresenta, secondo le sue autorizzazioni |
| Cosa lo interrompe? | Un campo spostato, un menu rinominato, un pop-up inaspettato | Un contratto dello strumento modificato, che è versionato e annunciato |
| Volume e costo per esecuzione | Volume molto elevato a costo quasi zero per esecuzione | Volume moderato con una chiamata al modello per esecuzione |
| Dove vanno le eccezioni | A una persona, come un'esecuzione non riuscita | L'agente riconcilia ciò che può e chiede riguardo al resto |
La prima riga decide la maggior parte dei casi. Tutto il resto nella tabella dipende dal fatto che il sistema sia stato costruito tenendo presente un chiamante automatico.
Utilizzando entrambi, e cosa decide il sistema sottostante
Il modello che i fornitori descrivono ora, e quello che funziona nella pratica, è che l'agente decide e il bot esegue su sistemi che non hanno nient'altro. UiPath lo esprime dicendo che i robot svolgono "un ruolo complementare nello stack di esecuzione" accanto agli agenti. In quel contesto, il bot è uno degli strumenti dell'agente: un'azione deterministica incapsulata contro uno schermo legacy, con l'agente responsabile della scelta di quando chiamarlo e della gestione di ciò che il bot restituisce. Col tempo, i bot si ritirano uno dopo l'altro man mano che i sistemi dietro di loro acquisiscono strumenti propri, e nulla sul lato dell'agente deve cambiare quando ciò accade.
Questo riporta la decisione al sistema aziendale. Sois è costruito in modo che il bot non sia mai necessario contro di esso: uno spazio di lavoro è un server MCP, ogni azione che una persona può compiere è esposta come uno strumento nominato, e l'agente che già utilizzi, Claude, ChatGPT o qualsiasi client MCP, si connette aggiungendo l'indirizzo dello spazio di lavoro e accedendo una volta. Gli strumenti sono filtrati in base al ruolo della persona prima che l'agente li veda e controllati di nuovo quando vengono eseguiti, quindi l'accesso fallisce in modo chiuso; la spesa è limitata per integrazione; ogni chiamata è registrata con i suoi input e il suo risultato. Dove continui a utilizzare un sistema legacy accanto ad esso, il bot rimane su quel sistema e l'agente lo tratta come uno strumento in più.
Se il tuo sistema principale ha solo schermi, l'RPA è il ponte e non c'è nulla di cui vergognarsi. La decisione importante è se il prossimo sistema che acquisti avrà bisogno di uno.
Domande che le persone pongono
L'RPA è obsoleto ora che esistono agenti AI?
No. Per lavori ad alto volume e basati su regole contro sistemi che espongono solo uno schermo, un bot è ancora l'opzione deterministica più economica, e i fornitori di RPA ora posizionano i loro robot come lo strato di esecuzione su cui gli agenti fanno affidamento. Ciò che è cambiato è che i sistemi costruiti con strumenti tipizzati non hanno più bisogno di un bot.
Un agente AI può controllare uno schermo come fa un bot RPA?
Sì. L'uso del computer di Anthropic fornisce a Claude il controllo dello schermo, del mouse e della tastiera, ed è utile dove non esiste un'interfaccia più stretta. Eredita la fragilità dello schermo e aggiunge la variabilità del modello, e le indicazioni di Anthropic sono di preferire strumenti più stretti dove disponibili e di avere una persona che confermi azioni significative.
L'RPA è più economico di un agente AI?
Per esecuzione, di solito: un bot riproduce passaggi registrati a costo marginale quasi zero, mentre un agente costa una chiamata al modello ogni volta. Il confronto cambia quando si considera la manutenzione che ogni cambiamento dello schermo impone al bot e le eccezioni che il bot non può gestire, che ricadono comunque su una persona.
I bot RPA e gli agenti AI possono lavorare insieme?
Sì, e questo è il modello che i fornitori descrivono. L'agente legge, decide e chiama strumenti; dove un sistema non ha strumenti, un bot incapsulato come un'azione deterministica esegue l'operazione su quello schermo. Man mano che i sistemi acquisiscono strumenti propri, i bot si ritirano senza cambiare l'agente.
- UiPath: cos'è l'automazione dei processi robotici la definizione di RPA fornita dal fornitore, i compiti a cui si adatta e i robot come un livello di esecuzione complementare per gli agenti
- Microsoft Learn: introduzione ai flussi desktop RPA in Power Automate: elementi UI, immagini o coordinate, contro applicazioni legacy e moderne
- Anthropic: strumento per l'uso del computer controllo dello schermo per Claude, i suoi limiti dichiarati e le indicazioni per confermare azioni consequenziali
- specifica del Model Context Protocol: strumenti definizioni degli strumenti, annotazioni, scoperta e messaggi di chiamata, e i requisiti di sicurezza su server e client
Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.