Scegliere tra RPA e intelligenza artificiale come se fossero prodotti alternativi porta spesso a progettare male il processo. La RPA è adatta a eseguire passaggi stabili. L’AI è adatta a interpretare informazioni variabili. Un agente AI può decidere quale azione intraprendere, ma deve farlo entro permessi, policy e controlli definiti.
La domanda utile, quindi, non è semplicemente RPA o AI?. La domanda è: quali parti del processo devono restare deterministiche, quali richiedono interpretazione e quali azioni possono essere delegate senza aumentare il rischio operativo?
RPA, AI e agenti: tre componenti diversi
I termini vengono spesso usati come sinonimi, ma descrivono responsabilità differenti all’interno di un sistema di automazione.
RPA: esecuzione ripetibile
La Robotic Process Automation replica una sequenza di azioni su applicazioni esistenti. Può aprire un programma, copiare un valore, compilare un campo, scaricare un file o avviare una procedura. A parità di input, esegue lo stesso percorso.
È efficace quando interfacce, regole e dati sono stabili. Diventa fragile quando una schermata cambia, un campo scompare o il processo incontra un caso che non è stato previsto.
AI: interpretazione di input variabili
Un componente AI classifica, estrae, confronta o interpreta informazioni. Può riconoscere i dati di una fattura con layout variabile, comprendere l’intento di una email o associare una descrizione libera a un’anagrafica. Il risultato non va trattato come una certezza implicita: servono controlli coerenti con il rischio del campo e dell’azione successiva.
Agente AI: scelta delle azioni
Un agente AI riceve un obiettivo, usa il contesto disponibile e sceglie tra strumenti autorizzati. Per esempio può consultare l’ERP, verificare un ordine, chiedere un’informazione mancante e preparare una registrazione. La capacità di scegliere un percorso lo distingue da un singolo modello di estrazione e da un robot RPA.
L’agente non coincide però con l’intero processo. Code, stati, timeout, autorizzazioni, approvazioni, retry e audit trail appartengono al livello di orchestrazione che lo circonda.
La matrice per scegliere l’architettura
La scelta dipende da quattro variabili: struttura degli input, stabilità delle regole, rischio dell’azione e qualità dell’integrazione. La tabella seguente è un punto di partenza, non una scorciatoia per evitare l’analisi del processo.
| Situazione | Componente prevalente | Motivo |
|---|---|---|
| Input strutturati e regole stabili | API o RPA | Il percorso può essere descritto e verificato in modo deterministico. |
| Documenti, email o descrizioni variabili | AI più regole | Serve interpretazione, ma l’esito deve superare controlli espliciti. |
| Più sistemi e percorso dipendente dal contesto | Agente più orchestratore | Occorre scegliere strumenti e passaggi in base allo stato del caso. |
| Azione irreversibile o ad alto impatto | Workflow con approvazione | L’AI può preparare la decisione, non necessariamente eseguirla. |
| Sistema legacy senza API affidabili | RPA come adattatore | Il robot collega il workflow a un’interfaccia che non espone servizi. |
Quattro domande prima di scegliere
Le regole possono essere scritte senza ambiguità? Se sì, una componente deterministica deve rimanere centrale.
Quanto variano gli input? Layout, linguaggio e completezza determinano il bisogno di interpretazione.
Che cosa accade se il sistema sbaglia? Il costo dell’errore definisce soglie, controlli e approvazioni.
Come raggiunge i sistemi aziendali? API, RPA e protocolli come MCP hanno profili diversi di robustezza e manutenzione.
Perché il workflow ibrido è spesso la scelta giusta
Nei processi reali, la parte interpretativa e quella operativa raramente coincidono. Un ordine può arrivare in forma libera, ma la creazione nell’ERP deve rispettare campi, autorizzazioni e regole precise. Una fattura può richiedere AI per leggere le righe, ma il controllo dei totali deve essere deterministico.
Un’architettura ibrida separa le responsabilità:
AI per comprendere documenti, testo e contesto;
regole di business per vincoli, tolleranze e controlli obbligatori;
agente AI per scegliere il prossimo passo tra azioni consentite;
API o RPA per eseguire operazioni sui sistemi;
orchestratore per governare stati, errori, retry, SLA e approvazioni;
persone per eccezioni e decisioni che richiedono responsabilità.
Questa separazione evita due estremi: usare RPA per interpretare casi che non possono essere codificati con regole rigide, oppure lasciare a un modello probabilistico operazioni che richiedono un esito ripetibile.
Cinque livelli di autonomia
Un progetto non deve scegliere tra controllo umano totale e autonomia totale. È più utile definire un livello di delega per ogni azione.
Livello 1, assiste. L’AI cerca informazioni, riassume il caso o evidenzia anomalie. La persona compie ogni azione.
Livello 2, propone. L’AI suggerisce una classificazione, un abbinamento o una risposta, poi attende la decisione dell’operatore.
Livello 3, prepara. Il sistema completa una bozza di transazione e raccoglie le evidenze, ma non modifica il sistema di record.
Livello 4, esegue con approvazione. L’agente avvia l’azione solo dopo un controllo umano o una policy autorizzativa esplicita.
Livello 5, esegue entro limiti definiti. Il sistema completa autonomamente casi a basso rischio che rispettano soglie e controlli, mentre devia gli altri verso una coda di eccezione.
Lo stesso workflow può usare livelli diversi. Per esempio, può registrare automaticamente una fattura che supera tutti i controlli e richiedere approvazione quando cambiano le coordinate bancarie o manca il riferimento all’ordine.
Come governare un agente AI
La governance non è una revisione da aggiungere dopo il prototipo. È parte dell’architettura e stabilisce ciò che l’agente può vedere, decidere ed eseguire.
Identità e permessi minimi
Ogni strumento deve applicare i permessi del ruolo e limitare dati e azioni al minimo necessario. L’agente non dovrebbe utilizzare credenziali condivise o ottenere accesso più ampio rispetto alla persona o al servizio per cui opera.
Policy traducibili in controlli
Una frase come “verifica che la fattura sia corretta” non è una policy operativa. Occorre definire campi obbligatori, tolleranze, fonti autorevoli, condizioni di blocco e soglie che richiedono approvazione.
Audit trail e motivazione
Per ogni caso devono essere ricostruibili input, versione del workflow, dati consultati, strumenti invocati, controlli eseguiti, decisioni, approvazioni e risultato. Il log deve spiegare il percorso operativo, non soltanto conservare una risposta testuale del modello.
Fallimento sicuro
Se un sistema non risponde, un dato è incoerente o l’agente non possiede sufficiente evidenza, il workflow deve fermarsi, riprovare in modo controllato o creare un’eccezione. Inventare il valore mancante non è una strategia di recupero.
MCP e accesso agli strumenti
Il Model Context Protocol può standardizzare l’accesso degli agenti a dati e strumenti. Non sostituisce però autenticazione, autorizzazione, validazione degli input e logging. Questi controlli restano responsabilità dell’architettura aziendale e dei server che espongono le operazioni.
Tre casi d’uso concreti
1. Inserimento degli ordini cliente
L’AI interpreta email e allegati, identifica cliente, articoli, quantità e date. Le regole verificano anagrafica, codici, disponibilità e campi obbligatori. Un agente può chiedere i dati mancanti o selezionare il flusso corretto. API o RPA preparano l’ordine nell’ERP. Se il cliente non è riconosciuto o una condizione commerciale è anomala, il caso passa a un operatore.
2. Fatture passive e matching
Il componente documentale estrae intestazione e righe. Il workflow recupera ordine e ricezione, applica i controlli di two way o three way matching e classifica le discrepanze. I casi coerenti possono avanzare, mentre variazioni di importo, duplicati o dati bancari nuovi richiedono il livello di approvazione previsto. Per il processo completo, consulta la guida alla fatturazione passiva.
3. Email operative
L’AI classifica il messaggio e raccoglie il contesto dai sistemi autorizzati. L’agente prepara una risposta, apre una pratica o assegna il caso. Le comunicazioni informative e a basso rischio possono seguire regole automatiche; reclami, modifiche contrattuali e richieste ambigue vengono sottoposti a revisione. Un approfondimento specifico è disponibile nell’articolo sull’automazione delle email con AI.
Gli errori di progettazione più comuni
Automatizzare il processo così com’è. Le inefficienze vengono rese più veloci invece di essere eliminate.
Usare un agente per ogni passaggio. Regole semplici, calcoli e vincoli obbligatori restano più affidabili se deterministici.
Confondere confidenza e correttezza. Un punteggio del modello non sostituisce i controlli sul risultato.
Trattare le eccezioni come casi marginali. Proprietario, priorità e tempo di risoluzione devono essere progettati prima del go live.
Concedere permessi troppo ampi. La comodità del prototipo può trasformarsi in rischio operativo.
Misurare solo il modello. Il risultato conta quando l’intero processo arriva all’esito corretto.
Come impostare un progetto pilota
Il pilota deve verificare un processo reale con input rappresentativi, integrazioni vere e criteri di successo definiti prima del test.
Delimita il processo. Indica inizio, fine, sistemi coinvolti e risultato atteso.
Classifica le decisioni. Separa regole deterministiche, interpretazioni e azioni che richiedono responsabilità umana.
Assegna il livello di autonomia. Definisci quali casi possono avanzare, quali richiedono conferma e quali devono essere bloccati.
Progetta le eccezioni. Ogni deviazione deve avere categoria, proprietario, priorità e tempo obiettivo di risoluzione.
Misura il risultato operativo. Controlla esito corretto, tempo di ciclo, interventi umani, errori successivi e qualità dell’audit trail.
Se il pilota funziona solo sui casi selezionati per la demo, non ha ancora verificato l’architettura. La prova utile comprende anche input incompleti, sistemi non disponibili e condizioni che devono produrre un rifiuto sicuro.
Domande frequenti
Qual è la differenza tra RPA e agente AI?
L’RPA esegue una sequenza predefinita. Un agente interpreta il contesto e seleziona azioni consentite. Spesso lavorano insieme: l’agente sceglie il percorso, la RPA esegue un passaggio su un sistema legacy.
Quando conviene usare RPA invece dell’intelligenza artificiale?
Quando regole, input e interfacce sono stabili e le eccezioni possono essere codificate. Se occorre interpretare testo, documenti o situazioni variabili, serve una componente AI inserita in un workflow controllato.
Che cosa significa intelligent automation?
È la combinazione di AI, regole, orchestrazione, API o RPA e controllo umano. Ogni componente svolge il compito per cui è più adatto, mantenendo verificabile il processo complessivo.
Un agente AI può operare senza controllo umano?
Solo per azioni delimitate e governate da policy. Le operazioni ad alto impatto richiedono autorizzazioni, tracciamento e, quando necessario, approvazione prima dell’esecuzione.
Come si sceglie tra RPA, agente AI e workflow ibrido?
Valutando variabilità degli input, chiarezza delle regole, rischio delle azioni e integrazioni disponibili. Un processo end to end richiede spesso una combinazione, non un solo strumento.
Quali metriche usare in un progetto pilota?
Esito corretto, tempo di ciclo, quota di casi completati senza intervento, tempo sulle eccezioni, errori dopo l’esecuzione e qualità dell’audit trail. L’accuratezza del modello è soltanto una delle misure.
La scelta riguarda l’architettura, non l’etichetta
RPA e agenti AI non sono due generazioni tra cui scegliere una volta per tutte. Sono componenti con caratteristiche diverse. Un’automazione affidabile mantiene deterministici i controlli che devono esserlo, usa l’AI dove serve interpretazione e concede autonomia in proporzione al rischio.
Il punto di partenza è un processo delimitato, con regole esplicite, sistemi identificati e responsabilità chiare. Solo dopo questa analisi ha senso decidere quali strumenti utilizzare.