RPA vs LLM Agent: Quando Usare Cosa per l'Automazione Aziendale

Cos'è un LLM Agent: definizione approfondita

A differenza di un chatbot tradizionale — che risponde a un messaggio e si ferma — un agente LLM ha quattro capacità distintive: percezione (legge input strutturati e non), pianificazione (decompone un obiettivo in passi), azione (chiama tool esterni), riflessione (valuta se il risultato è coerente e corregge se serve).

Cosa può fare un LLM Agent che un chatbot non può

• Eseguire azioni concrete su sistemi terzi: inserire un record in un CRM, inviare un'email, creare un appuntamento su un calendario, scaricare un file da un portale. Il chatbot risponde, l'agente fa.
• Pianificare task multi-step su obiettivi vaghi: dato un input come "controlla se Mario Rossi ha pagato la fattura di marzo e se no mandagli un sollecito", l'agente scompone l'obiettivo in sotto-task (cerca cliente → cerca fattura → verifica stato → se non pagata, componi messaggio → invia) senza che ogni passo sia stato programmato esplicitamente.
• Recuperare informazioni da fonti esterne (RAG): leggere documenti aziendali, knowledge base, archivi PDF e usarli come contesto per rispondere in modo accurato e ancorato a fatti specifici, non a conoscenza generale del modello.
• Gestire memoria di lungo termine: ricordare conversazioni precedenti con lo stesso cliente, preferenze emerse in interazioni passate, cronologia di interventi su un caso aperto.
• Coordinarsi con altri agenti specializzati: in architettura multi-agente, un agente "supervisore" delega a sub-agenti specializzati (es. agente fatturazione, agente logistica, agente customer care) e ricompone il risultato finale. Vedi sistemi multi-agente.

Limiti attuali degli agenti LLM (onestà intellettuale)

• Non-determinismo controllabile ma non eliminabile: lo stesso input può produrre output con piccole variazioni di formulazione o, raramente, di sostanza. Per task dove ogni esecuzione deve essere identica al bit, l'agente LLM non è la scelta giusta.
• Costo di inferenza per ogni esecuzione: ogni chiamata al modello ha un costo (token in input + token in output). Su volumi molto alti e task semplici, RPA puro è economicamente più sostenibile. Il break-even point dipende dal modello scelto e dal volume.
• Rischio di "allucinazioni" su dati assenti: se l'agente non trova un'informazione, può inventarla — soprattutto se il prompt non vieta esplicitamente di rispondere senza fonte. Per ridurre il rischio servono RAG ben configurato, validazioni a valle e (su decisioni critiche) Human-in-the-Loop.
• Latenza superiore a RPA: una chiamata a un modello cloud ha latenza tipicamente nell'ordine dei secondi. Per task real-time ad alta frequenza (es. tick-by-tick), l'agente non è adatto senza ottimizzazioni dedicate (modelli locali, caching aggressivo).

Cos'è RPA: definizione e tecnologie

RPA nasce per risolvere il problema dei sistemi che non hanno API: gestionali legacy, applicativi web senza endpoint, mainframe verdi su nero. Quando l'integrazione "pulita" non è possibile, RPA fa accedere il robot all'interfaccia grafica come farebbe un umano — solo molto più velocemente e senza errori di battitura.

Principali piattaforme RPA

Il mercato è dominato da alcuni vendor maturi. Senza endorsement, le piattaforme più diffuse a livello enterprise sono:

• UiPath: piattaforma con studio visuale, orchestratore, capacità di OCR e AI integrata. Ampia adozione enterprise.
• Automation Anywhere: piattaforma cloud-native, focus su bot riusabili e marketplace.
• Microsoft Power Automate (ex Power Automate Desktop): integrata in ecosistema Microsoft 365, accessibile a utenti non sviluppatori.
• Blue Prism: storica piattaforma RPA, forte su governance e compliance enterprise.
• Soluzioni open-source / custom Python: per processi mirati, librerie come Playwright, Selenium, PyAutoGUI permettono di realizzare RPA su misura senza licensing enterprise. Approccio tipico per integrazioni Synaptica quando il perimetro è circoscritto.

La scelta della piattaforma dipende da volumi, governance richiesta, ecosistema IT esistente e budget. Per processi singoli a budget contenuto, una soluzione custom Python è spesso più snella; per ecosistemi enterprise con decine di processi, una piattaforma con orchestratore centralizzato giustifica il costo licenziale.

Quando RPA mostra il suo limite

RPA è strumento eccellente — finché l'input rispetta le ipotesi. Ecco tre casi reali in cui il limite emerge in modo dirompente:

• Caso 1 — Il fornitore cambia il layout della fattura PDF. Il bot RPA che estraeva totale, IVA e scadenza basandosi sulle coordinate del PDF smette di funzionare. Ogni nuovo fornitore richiede un nuovo template. Con 50 fornitori che cambiano formato due volte all'anno, la manutenzione diventa più costosa del processo automatizzato.
• Caso 2 — Email del cliente con richiesta "mista". Un cliente scrive: "Mi mandate la fattura di marzo e mi spostate l'appuntamento del 15 a settimana prossima?". RPA non sa estrarre due intent diversi da una frase libera. Servirebbe un agente LLM che classifichi e ruoti.
• Caso 3 — Aggiornamento UI del gestionale. Il vendor del gestionale rilascia un update grafico: i pulsanti si spostano, alcune label cambiano. Tutti i workflow RPA che si basavano sulla posizione o sul testo dei controlli vanno rifatti. Su decine di processi, la finestra di disservizio si misura in settimane.

Confronto operativo: RPA vs LLM Agent

Questo confronto guarda ai criteri che contano in fase di progettazione tecnica — determinismo, latenza, audit trail, curva di apprendimento del team. Se ti serve prima un confronto a livello di business (che tipo di processo hai, quanto costa, quale ROI aspettarti), vedi RPA vs AI: la guida decisionale.

Quando usare RPA

RPA è la scelta giusta per:

• Data entry ad alto volume da fonti strutturate: caricare dati da un CSV in un gestionale, sincronizzare record tra due sistemi con mapping fisso, generare report da database.
• Automazione di interfacce legacy senza API: sistemi vecchi che non espongono API (gestionali DOS-era, applicativi web senza endpoint REST). Il robot usa l'interfaccia grafica come farebbe un umano — è spesso l'unica opzione.
• Processi con regole completamente definite e zero ambiguità: se puoi scrivere "se X allora Y" per ogni caso possibile, RPA è sufficiente e più economico di un agente AI.
• Compliance che richiede determinismo assoluto: processi finanziari, medicali o legali dove ogni esecuzione deve essere identica e verificabile. L'audit trail RPA è più semplice da certificare.
• Volume molto alto, variabilità molto bassa: mille bonificazioni al giorno con lo stesso formato, cento ordini identici, mille inserimenti di fatture standard.

Esempio Synaptica: SEPA Manager usa logica deterministica per la generazione di file XML SEPA — non c'è ambiguità, ogni campo ha una regola precisa. È più vicino all'approccio RPA che all'agente AI.

Quando usare un LLM Agent

Un agente LLM diventa necessario quando:

• L'input è linguaggio naturale: email di clienti, messaggi WhatsApp, form liberi, note vocali, documenti PDF non strutturati. RPA non può "capire" il testo — un agente LLM sì.
• Il processo ha alta variabilità e richiede judgment: ogni richiesta di cliente è leggermente diversa. L'agente gestisce le eccezioni senza che tu debba scrivere una regola per ogni caso.
• Serve orchestrazione multi-sistema con logica di routing: "se il cliente chiede X, vai su sistema A; se chiede Y, vai su sistema B; se non è chiaro, chiedi conferma" — questo richiede ragionamento, non scripting.
• Automazione di comunicazioni con clienti o fornitori: rispondere a FAQ, qualificare lead, prendere appuntamenti, inviare promemoria contestuali. SideMindBot è costruito su questa architettura: agenti LLM specializzati per canale, orchestrati centralmente.
• Analisi e classificazione di documenti non strutturati: fatture in formato diverso da fornitore a fornitore, contratti da estrarre, documenti medici, moduli cartacei scannerizzati.

L'approccio ibrido: agente che orchestra RPA

Il pattern più potente per processi complessi combina entrambe le tecnologie:

1. LLM Agent — livello di comprensione e decisione: legge l'input (email, documento, messaggio), capisce cosa viene richiesto, decide quale azione eseguire, gestisce ambiguità e chiede chiarimenti se necessario.
2. RPA — livello di esecuzione meccanica: esegue l'azione sul sistema target (inserisce dati nel gestionale, compila il form, scarica il documento), esattamente come programmato.

L'agente gestisce il cosa fare. Il robot gestisce il come farlo sul sistema. Il risultato: automazione flessibile con esecuzione affidabile.

Questo pattern è particolarmente efficace per: elaborazione di ordini da email con inserimento in ERP, gestione richieste fornitori con variazioni di formato, automazione di processi amministrativi misti (parte digitale strutturata + documenti liberi).

4 scenari reali: RPA, LLM o ibrido?

Quattro situazioni che incontriamo regolarmente in fase di discovery con PMI italiane. Le scelte raccontate qui sono indicazioni metodologiche basate su pattern ricorrenti, non promesse di risultato.

Human-in-the-Loop: quando è obbligatorio

Per quanto un'automazione sia ben progettata, esistono punti del processo in cui mantenere l'umano nel ciclo decisionale non è opzionale — è la differenza tra un sistema sostenibile e un disastro silenzioso. Per la definizione completa del pattern vedi Human-in-the-Loop.

I cinque casi tipici in cui il checkpoint umano è necessario:

• Decisioni con impatto economico rilevante: pagamenti sopra una soglia definita, contratti, sconti che incidono sul margine, ordini ad importo significativo. La soglia è una scelta di rischio aziendale: spesso si parte conservativi (es. tutto sopra X richiede approvazione) e si alza la soglia man mano che l'agente dimostra affidabilità.
• Eccezioni con bassa confidenza del modello: l'agente LLM espone un punteggio di confidenza sulla decisione. Sotto una soglia (configurabile per dominio), il caso esce dalla pipeline automatica e va in revisione umana. Pattern fondamentale per evitare che l'agente "tiri a indovinare" su casi ambigui.
• Processi soggetti a compliance regolatoria: sanitario (paziente, terapia), finanziario (antiriciclaggio, KYC), GDPR (decisioni automatizzate su dati personali con effetti significativi — art. 22 GDPR). In questi domini la presenza di un revisore qualificato è spesso requisito legale, non scelta architetturale.
• Comunicazioni in uscita verso clienti su tono delicato: solleciti, contestazioni, comunicazioni di disservizio, gestione di reclami. L'agente può preparare la bozza, ma l'invio passa per occhio umano fino a quando il volume e la fiducia consolidata non giustifichino l'automazione completa.
• Fasi iniziali di rollout: nei primi giorni/settimane di produzione di un nuovo agente, una percentuale alta (anche 100%) delle decisioni passa per revisione umana, sia per validare il comportamento sia per alimentare il dataset di feedback. La percentuale scende man mano che le revisioni confermano sistematicamente le decisioni dell'agente.

Principio guida: l'AI propone, l'umano approva quando il costo di un errore supera il costo della revisione. Un sistema ben progettato non rimuove l'umano — lo libera dai task ad alto volume e basso valore per concentrarlo dove conta davvero.

Framework di valutazione DAVAR

Per aiutare imprenditori e responsabili IT a scegliere rapidamente fra RPA, LLM Agent o approccio ibrido, abbiamo formalizzato in Synaptica Solution un framework mnemonico in cinque domande, chiamato DAVAR. Si applica in 5-10 minuti durante una discovery call e dà un indirizzo qualitativo prima di entrare in tecnicismi.

Come interpretare il risultato

• 4-5 risposte verso RPA: il processo è candidato a RPA puro. ROI rapido, manutenzione contenuta, costi prevedibili.
• 4-5 risposte verso LLM: serve un agente LLM. Tipicamente customer care, classificazione documenti, smistamento comunicazioni, qualificazione lead.
• Risposte miste (2/3 - 3/2): candidato a architettura ibrida. L'agente fa la parte cognitiva, RPA o API la parte esecutiva. È il caso più frequente nelle PMI italiane reali.
• Tutto su LLM ma con vincoli di compliance forti: agente LLM con Human-in-the-Loop sistematico sulle decisioni critiche. La piena automazione si alza nel tempo, mai dal giorno uno.

Il framework non sostituisce un'analisi tecnica seria — ma evita scelte sbagliate dal primo metro. In troppi progetti si parte con "facciamo tutto AI" o "facciamo tutto RPA" senza aver mai fatto questa domanda. DAVAR forza la conversazione giusta.

Roadmap tipica di adozione

Le PMI che adottano automazione in modo sostenibile seguono quasi sempre la stessa progressione, ed è una progressione che ha senso anche teorico: si parte da ciò che è certo, si aggiunge l'intelligenza dove serve, si orchestra solo quando i pezzi sono solidi. Saltare le fasi è la causa numero uno di progetti AI che muoiono in proof-of-concept eterno.

Tempi tipici: la Fase 1 si chiude in settimane su processi ben mappati; la Fase 2 richiede iterazione (settimane-mesi) per tuning prompt e dataset; la Fase 3 è continua, non ha un "fine" — è il modello operativo target.

Come scegliere nella pratica: il CRISP Framework

Synaptica ha sviluppato il CRISP Framework — una metodologia in 5 fasi per progettare sistemi AI aziendali in modo rigoroso. Nella fase di Requirements del CRISP, una delle prime valutazioni è proprio questa: il processo richiede comprensione (→ LLM) o esecuzione deterministica (→ RPA)? La risposta determina l'architettura dell'intero sistema. Il framework DAVAR descritto sopra è di fatto la check-list operativa che usiamo nel passaggio Requirements del CRISP.