bubblesbubbles
Agenti AI
  • 5 gennaio 2026
  • 5 minuti

RPA o agente AI? Il problema che risolvono è diverso

Un robot che segue un copione contro un sistema che ragiona sul contesto: come scegliere tra RPA e agenti AI, quando combinarli e cosa costa mantenerli nel tempo.

Giulio Dell'Oro
Giulio Dell'OroHead of technology

Ogni mattina, in migliaia di uffici italiani, un software si collega al portale di una banca, scarica un estratto conto, lo incolla in un foglio Excel e lo carica sul gestionale. Funziona da anni, finché un giorno la banca cambia la grafica del portale, e il software smette di funzionare senza preavviso. È il ritratto perfetto di cosa sa fare bene, e di cosa non sa fare, la Robotic Process Automation: il punto di partenza per capire quando conviene, e quando invece serve un agente AI.

Un robot che esegue, non che capisce

L'RPA automatizza compiti ripetitivi eseguendo sulle interfacce dei programmi le stesse azioni che farebbe una persona: clicca pulsanti, copia dati, compila moduli, scarica file. Il robot non capisce cosa sta facendo, esegue un copione, individuando gli elementi sullo schermo esattamente come farebbe chi lo usa ogni giorno.

Questo approccio funziona anche su software senza API, si configura in tempi brevi su processi stabili e riduce gli errori delle operazioni manuali ripetitive. Il limite, però, è strutturale: se cambia l'interfaccia, se si sposta un campo, se si aggiunge un passaggio al processo, il robot si ferma o sbaglia. Serve manutenzione continua, ed è un costo che cresce con il numero di automazioni attive: nelle aziende che ne hanno molte, i team IT passano ore a riparare bot rotti da un aggiornamento di routine. L'RPA eccelle su riconciliazioni contabili, estrazione da PDF sempre uguali, aggiornamenti massivi in gestionali datati: processi che un nuovo assunto imparerebbe in un pomeriggio e che non cambiano mai.

Un sistema che decide, non che ripete

Un agente AI parte da un obiettivo, non da un copione: usa un modello linguistico insieme a strumenti e integrazioni per pianificare ed eseguire i passi necessari, gestendo le eccezioni e adattandosi al contesto man mano che emerge. Può leggere un'email di reclamo, capirne il tono e il contenuto, recuperare dal CRM la storia del cliente, controllare lo stato della spedizione e scrivere una risposta su misura, senza istruzioni per ogni singolo passaggio.

Il suo punto di forza è gestire la variabilità: non tutti gli ordini sono uguali, non tutti i reclami seguono lo stesso schema, e davanti a un imprevisto l'agente valuta invece di bloccarsi. È adatto a documenti non strutturati, qualificazione dei contatti, assistenza complessa, flussi che toccano più sistemi con logiche diverse.

Le due tecnologie messe a confronto

L'RPA lavora su input strutturati e prevedibili, l'agente gestisce anche testi liberi. L'RPA è fragile ai cambiamenti, l'agente si adatta. L'RPA non capisce il contesto, l'agente sì. L'RPA richiede una regola esplicita per ogni eccezione, l'agente ragiona caso per caso. Costa meno avviare un RPA, ma mantenerlo nel tempo costa di più, perché ogni cambiamento di interfaccia richiede una revisione; l'agente costa di più all'avvio, ma resta più stabile perché lavora tramite API e non sull'aspetto dello schermo. L'RPA scala linearmente, aggiungendo bot per più volume; l'agente scala in modo più flessibile. E solo l'agente, se progettato per raccogliere feedback, può migliorare nel tempo: l'RPA fa oggi esattamente quello che faceva ieri.

Un terzo caso: la fatturazione fornitori

C'è un terzo scenario che aiuta a capire la differenza più della teoria. Un'azienda riceve fatture fornitori sempre nello stesso formato, da un numero fisso di fornitori, con importi da registrare secondo regole note: qui un RPA legge il PDF con un modello fisso, estrae gli importi e li carica in contabilità, senza bisogno di capire il contenuto. Ma se le fatture arrivano in formati diversi, alcune scritte a mano, altre con voci ambigue da interpretare, il compito richiede comprensione, non solo estrazione: è il terreno di un agente, che legge il documento, riconosce cosa manca o non torna, e chiede conferma prima di procedere.

Un esempio per tipo di processo

Un'azienda che ogni mattina scarica dati da un portale bancario, li inserisce nel gestionale e produce un report Excel ha un processo fisso, ad alto volume, senza variabilità: è il terreno naturale dell'RPA. Un'azienda che riceve ogni giorno richieste di offerta scritte liberamente via email, e deve capire cosa serve al cliente, recuperare le informazioni da catalogo ed ERP e preparare una risposta su misura, ha un processo con input non strutturato e decisioni legate al contesto: qui serve un agente.

Le domande da farsi, per decidere in un caso reale: l'input arriva sempre nello stesso formato? Se no, l'RPA non basta. Il processo ha eccezioni frequenti? Se sì, l'RPA richiederà manutenzione continua. I sistemi coinvolti cambiano spesso? Più cambiano, più l'RPA costa nel tempo. Il valore sta nell'eseguire meccanicamente o nel decidere? Nel primo caso RPA, nel secondo un agente.

Perché spesso conviene usarli insieme

Nella pratica, molte implementazioni efficaci non scelgono l'una o l'altra tecnologia, ma le combinano: l'agente si occupa della parte cognitiva, cioè capire, decidere, gestire le eccezioni, e affida a un robot RPA le operazioni meccaniche sui sistemi datati privi di API. L'agente orchestra, l'RPA esegue.

È lo schema tipico in banche, assicurazioni e manifattura, dove convivono molti sistemi vecchi senza interfacce moderne: l'agente porta l'intelligenza, l'RPA la compatibilità con il passato. Gli agenti collegati tramite API, che lavorano sul contenuto e non sull'aspetto dell'interfaccia, sono molto meno sensibili ai cambiamenti che mandano in crisi l'RPA, anche se portano altre sfide da presidiare, come l'affidabilità del modello e i costi di esecuzione.

Il punto di partenza, comunque, non è la tecnologia ma la mappa dei processi: quali costano più tempo, quali hanno input variabili, quali toccano più sistemi.

Un ultimo avvertimento, spesso trascurato: non tutti i processi meritano un agente solo perché è la tecnologia più discussa del momento. Un processo semplice, stabile e ad alto volume automatizzato con un agente costa di più e non rende meglio di un buon RPA; il contrario vale per un processo pieno di eccezioni forzato dentro le regole rigide di un robot. Non ogni processo merita un agente, né ogni processo si presta all'RPA. Se vuoi analizzare i tuoi processi prima di scegliere, parliamone.