1. Introduzione

L’automazione robotica dei processi fece una promessa modesta e, per un certo tempo, la mantenne. Là dove una persona spostava dati tra sistemi che non sapevano comunicare tra loro, accedendo a un portale, copiando cifre in un foglio di calcolo, digitandole in un ERP, si poteva insegnare a un bot RPA a fare lo stesso, cliccando gli stessi pulsanti nello stesso ordine, più velocemente e senza stancarsi. Il bello era che non richiedeva alcuna modifica ai sistemi sottostanti: il bot pilotava le schermate esistenti esattamente come faceva una persona, così un reparto poteva automatizzare un processo in poche settimane senza attendere che l’IT costruisse un’interfaccia. Su queste basi l’RPA divenne una delle tecnologie aziendali adottate più rapidamente dell’ultimo decennio.

Il problema sta nella parola robotica. Un bot RPA non comprende il compito; ripete una registrazione. Sa che il totale della fattura si trova nella terza casella della seconda scheda, non che cosa sia un totale di fattura, per cui quando il portale viene ridisegnato e la casella si sposta, il bot non si adatta, fallisce, e se fallisce in silenzio continua a registrare il numero sbagliato finché qualcuno non se ne accorge. Ogni processo che un’organizzazione esegue si colloca in un ambiente che cambia: il software viene aggiornato, i moduli vengono ridisegnati, i fornitori inviano un nuovo formato, una normativa aggiunge un campo, arriva un caso limite che la registrazione non aveva mai visto. Di fronte a un ambiente in deriva, un insieme di regole congelate è un bene che si svaluta. Il nome che il settore dà a questa conseguenza è manutenzione dei bot, ed è lo scandalo silenzioso del campo: in un programma RPA maturo una larga parte dello sforzo non va nell’automatizzare nuovo lavoro ma nel riparare automazioni che il mondo ha rotto, cosicché il costo di esercizio cresce nel tempo e il business case si erode da sotto.

Questo articolo tratta di ciò che sostituisce l’RPA, e del perché la sostituzione sia una cosa di natura diversa e non un bot più veloce. Un agente IA capace, un modello in grado di leggere una schermata o un documento, di ragionare sul suo scopo, di invocare strumenti e di controllare il proprio lavoro, può svolgere il compito impiegatizio che l’RPA svolgeva, ma non è questa l’affermazione interessante, perché fare la stessa cosa fragile con un motore più costoso non è un progresso. L’affermazione interessante è che un agente può fare ciò che un bot strutturalmente non può: può migliorare l’automazione a partire dal proprio funzionamento. Ogni volta che gestisce un caso genera prove, ciò che ha fatto, se il risultato è stato accettato, dove ha esitato o è stato corretto, e quelle prove possono essere reimmesse per rivedere il modo in cui l’automazione si comporterà la volta successiva. L’automazione smette di essere una registrazione fatta una sola volta e poi in decadimento e diventa un anello che migliora quanto più viene eseguito. Noi la chiamiamo automazione ricorsiva, ed è la prima delle due fondamenta dell’articolo.

La seconda fondamenta è quella che rende sicura la prima, e senza di essa la ricorsione è un rischio anziché una risorsa. Un anello che modifica il proprio comportamento a partire dai propri output è, in termini di controllo, un sistema di retroazione, e i sistemi di retroazione possono convergere oppure sfuggire al controllo. Un agente lasciato a regolarsi su un segnale rumoroso inseguirà il rumore, ottimizzerà la misura che gli è stata assegnata anziché il risultato che doveva servire, e regredirà in modi che nessuno ha scelto. La disciplina che trasforma un anello auto-migliorante da pericolo in un motore affidabile di miglioramento non è nuova; il settore ce l’ha fin dagli anni 1920 e l’ha formalizzata negli ultimi trent’anni come Six Sigma, il cui nucleo operativo è il ciclo DMAIC: Define, definire l’obiettivo e le tolleranze, Measure, misurare ciò che accade realmente, Analyse, analizzare le fonti di errore e di variazione, Improve, migliorare con un cambiamento deliberato, e Control, controllare affinché il guadagno sia mantenuto e non perduto. Letto come una metodologia di progetto, il DMAIC è familiare. Letto come la struttura di controllo di un’automazione auto-migliorante, eseguito di continuo anziché una sola volta, è esattamente il regolatore di cui l’anello ricorsivo ha bisogno, e questo accostamento è l’oggetto del presente articolo.

Il contributo è un ragionamento e un piccolo modello, non un benchmark. La Sezione 2 colloca la tesi a fronte della letteratura su RPA, automazione intelligente, miglioramento continuo e agenti IA. La Sezione 3 espone perché un bot a regole fisse si deteriora, con un modello di deriva e manutenzione. La Sezione 4 descrive l’anello ricorsivo che un agente rende possibile. La Sezione 5 è il cuore dell’articolo: il DMAIC come la struttura di controllo che fa convergere l’anello, con la fase di Control come meccanismo a cricchetto di non-regressione. La Sezione 6 ricava la condizione di sostituzione, un singolo numero che dice quando l’agente supera il bot. La Sezione 7 ripercorre un caso costruito di contabilità fornitori; le Sezioni da 8 a 11 traggono le conseguenze su come gestire una funzione di automazione, rispondono alle obiezioni, dichiarano i limiti e concludono. La domanda che attraversa tutto è: una volta che l’automazione può imparare dalla propria esecuzione, che cosa fa sì che impari la cosa giusta, e quando ciò rende obsoleto il bot registrato?

2. Contesto

2.1 L’RPA e il suo limite

Nella letteratura dei sistemi informativi l’RPA è stata caratterizzata come automazione “leggera”: software che opera sullo strato di presentazione dei sistemi esistenti anziché sui loro dati o sulla loro logica, cosicché viene messa in opera dal business, al di fuori del tradizionale progetto IT, su back end immutati (van der Aalst, Bichler & Heinzl, 2018; Hofmann, Samp & Urbach, 2020). Le prime evidenze sui casi erano genuinamente positive quanto a costi e rapidità (Lacity & Willcocks, 2016; Willcocks, Lacity & Craig, 2015). La stessa letteratura, man mano che il campo maturava, ne ha indicato il limite. Syed et al. (2020), passando in rassegna lo stato della ricerca e della pratica sull’RPA, identificano la dipendenza da input stabili e strutturati e la fragilità dei bot di fronte al cambiamento delle interfacce e dei processi come temi ricorrenti e irrisolti, e collocano la manutenzione e la governance tra le sfide centrali del campo; Wewerka e Reichert (2023), mappando il campo in modo sistematico, catalogano la gestione limitata delle eccezioni e lo sforzo di manutenzione tra i suoi problemi persistenti. Il limite non è un difetto di un particolare prodotto; è intrinseco all’automatizzare per imitazione della superficie. Un bot codifica come una persona competente ha cliccato, non ciò che il compito richiede, e lo scarto tra i due è esattamente lo spazio di manovra che l’ambiente ha per romperlo.

2.2 Dall’RPA all’automazione intelligente e agentica

I professionisti hanno risposto innestando intelligenza sul bot: riconoscimento ottico dei caratteri per leggere i documenti, un classificatore per smistarli, un modello per gestire l’input non strutturato che l’RPA non sapeva trattare. Questa automazione intelligente, o iper-automazione, ha ampliato la gamma di input che una pipeline poteva accettare, ma ha lasciato immutata la struttura di controllo, un’orchestrazione fissa con componenti più intelligenti cablati in posizioni fisse, e così ha ereditato la medesima fragilità un livello più in alto. Lo spostamento più recente è di tipo diverso. Un agente IA non occupa una posizione fissa in un flusso disegnato a mano; gli si assegna un obiettivo e un insieme di strumenti ed esso decide i passi, il che gli consente di assorbire variazioni che avrebbero mandato in crisi un’orchestrazione fissa e, poiché ragiona sul compito anziché riprodurre una registrazione, gli si può chiedere di spiegare, controllare e rivedere ciò che ha fatto. La letteratura sugli agenti nel machine learning ne fornisce i meccanismi, l’alternanza di ragionamento e uso degli strumenti (Yao et al., 2023), la riflessione sui tentativi falliti per far meglio al successivo (Shinn et al., 2023), e la rassegna più ampia sugli agenti autonomi (Wang et al., 2024). Il nostro interesse non è il meccanismo in astratto ma una sua conseguenza operativa: l’esecuzione di un agente produce prove ispezionabili, e le prove sono ciò di cui un anello ha bisogno per migliorare.

2.3 Il miglioramento continuo è più antico della macchina

L’idea che un processo debba essere misurato e migliorato a partire dal proprio output non è un’idea dell’IA; è il fondamento della gestione della qualità del Novecento, e l’articolo vi si appoggia deliberatamente. Shewhart (1931) distinse la variazione inerente a un processo stabile, la causa comune, da quella assegnabile, la causa speciale, la variazione che segnala che qualcosa è cambiato, e fornì la carta di controllo come lo strumento che le distingue, così da reagire agli spostamenti reali e non al rumore, esattamente la modalità di fallimento di un anello di apprendimento non governato; la trattazione statistica moderna è Montgomery (2024). Deming (1986) costruì intorno a essa il sistema di gestione e rese popolare il ciclo Plan–Do–Study–Act di miglioramento iterativo. Il Six Sigma (Harry & Schroeder, 2000; Pyzdek & Keller, 2023) impacchettò la pratica nel DMAIC e la legò a un tasso di difettosità quantificato; le trattazioni accademiche gliene danno una teoria (Linderman et al., 2003) e un resoconto schietto della sua tensione con l’innovazione (Benner & Tushman, 2003). Un filone è particolarmente vicino a questo articolo: l’evolutionary operation di Box (1957), che conduceva un processo produttivo come un esperimento lento e continuo, ritoccandone le impostazioni e conservando ciò che in modo misurabile ne migliorava la resa, è auto-miglioramento ricorsivo sotto controllo statistico, decenni prima del termine, ed è il giusto antenato di ciò che un agente fa oggi alla velocità del software.

2.4 Retroazione, varietà e i limiti di una regola fissa

La cibernetica fornisce la ragione per cui un bot fisso deve soccombere a un mondo che varia. La legge della varietà richiesta di Ashby (1956) afferma che un regolatore può assorbire il disturbo solo in proporzione alla varietà che esso stesso è in grado di produrre: solo la varietà può distruggere la varietà. Un bot RPA ne possiede, per costruzione, quasi nessuna, una risposta per ogni percorso registrato, perciò può regolare soltanto un ambiente che non esce mai da quei percorsi, e ogni ambiente reale prima o poi ne esce. Un agente governato da un anello di apprendimento fabbrica varietà su richiesta, generando una risposta a un caso per cui non era stato esplicitamente costruito, ed è questo che gli consente di inseguire un bersaglio mobile che una regola fissa non può inseguire. Wiener (1948) diede il resoconto fondativo del controllo mediante retroazione, e la tradizione del machine learning di apprendere da un segnale di ricompensa (Sutton & Barto, 2018) e quella delle organizzazioni che apprendono correggendo l’errore (Argyris & Schön, 1978) sono lo stesso principio ad altre scale. Il contributo qui è mettere insieme questi due antichi corpi di conoscenza su un oggetto nuovo: l’agente fornisce la varietà, e il DMAIC fornisce il controllo che mantiene la varietà puntata sull’obiettivo.

3. Perché un bot a regole fisse si deteriora

L’accusa contro l’RPA non è che fallisce il primo giorno; è che è costruita per essere ottimale il primo giorno e per degradare ogni giorno successivo. Si fissi un processo e si metta in opera un bot che gestisce correttamente una parte dei suoi casi. L’ambiente poi deriva, a un certo ritmo, allontanandosi dallo stato rispetto al quale il bot è stato registrato: i moduli cambiano, i sistemi vengono aggiornati, arrivano nuove varianti degli input, le politiche aggiungono un passaggio. Ogni incremento di deriva trasforma alcuni casi che il bot era solito gestire in casi che ora gestisce male, cosicché il tasso di errore del bot sale all’incirca in proporzione alla deriva accumulata. Tra un intervento e l’altro,

dove $\varepsilon_0$ è il tasso di errore al momento della messa in opera, $t$ è il tempo e $\delta$ è il tasso di deriva, il ritmo al quale il mondo si lascia alle spalle la registrazione. L’unica cosa che abbassa $\varepsilon^{\mathrm{rpa}}$ è una persona: un ingegnere si accorge della rottura, registra di nuovo il percorso e riporta il tasso di errore verso $\varepsilon_0$, a un costo, e fino alla deriva successiva. Il bot traccia dunque un dente di sega, salendo con la deriva e scendendo a ogni riparazione manuale, senza mai migliorare rispetto al suo progetto originario, perché nulla al suo interno apprende. Il suo errore medio sull’intero ciclo di vita è determinato da quanto velocemente il mondo si muove ($\delta$) e da quanto spesso l’organizzazione può permettersi di mandare qualcuno a ripararlo.

Due tratti di questo quadro contano. In primo luogo, la manutenzione è reattiva e illimitata: man mano che un parco di bot cresce, la deriva che essi accumulano collettivamente cresce con esso, cosicché lo sforzo di manutenzione sale con il numero delle automazioni anziché con il nuovo lavoro che si automatizza, ed è questo il meccanismo per cui il costo di esercizio di un programma RPA sopravanza i suoi risparmi. In secondo luogo, il fallimento è spesso silenzioso: un bot che registra un valore dal campo sbagliato non solleva un errore, produce un risultato plausibile e sbagliato, e il costo di ciò è limitato soltanto da quanto a lungo passa inosservato. Una regola fissa in un mondo che si muove non è semplicemente limitata; è un rischio la cui entità l’organizzazione non controlla.

4. Automazione ricorsiva: l’anello che un bot non può chiudere

Un agente cambia il quadro perché la sua esecuzione è una fonte di informazione che può essere rivolta sull’automazione stessa. Quando un agente elabora un caso lascia una traccia: l’input che ha visto, i passi che ha scelto, le chiamate agli strumenti che ha effettuato, l’output che ha prodotto e, soprattutto, il segnale a valle del fatto che quell’output sia stato accettato, corretto o annullato. Quella traccia è una prova di dove l’automazione è forte e dove è debole e, poiché il comportamento dell’agente è espresso in cose che possono essere modificate, le sue istruzioni, gli esempi che gli vengono forniti, gli strumenti e i controlli che deve usare, l’instradamento dei casi difficili, quella prova può essere reimmessa come una revisione. L’automazione migliora a partire dal proprio funzionamento. Là dove l’equazione (1) dispone solo di una mano esterna per abbassare l’errore, l’anello ricorsivo lo abbassa dall’interno, a ogni ciclo:

Qui $\varepsilon_k$ è il tasso di errore dopo $k$ cicli, $g \in (0,1)$ è il guadagno di miglioramento, la frazione dell’errore rimediabile che un ciclo rimuove, e $\varepsilon_\ast$ è il limite inferiore irriducibile, il residuo di cui il processo non può liberarsi perché riflette un’ambiguità genuina, un’informazione mancante o un giudizio irriducibile, la difficoltà essenziale anziché accidentale del compito. Iterando l’equazione (2) si ottiene la forma chiusa

un calo geometrico dall’errore iniziale fino al limite inferiore. È la forma a cui la tradizione della qualità ha sempre mirato e la forma che un bot non può mai tracciare, perché un bot non ha alcun $g$: il suo guadagno di miglioramento è zero, e l’equazione (2) si riduce a una costante interrotta soltanto da azzeramenti manuali. La differenza tra RPA e automazione agentica, in questo modello, è la differenza tra $g = 0$ e $g > 0$: tra un’automazione che può essere riparata solo dall’esterno e una che migliora sé stessa dall’interno.

Tre condizioni rendono $g$ positivo e lo mantengono tale, e tutte e tre sono cose che l’esecuzione dell’agente fornisce e quella di un bot no. Ci deve essere un segnale: un esito misurabile per ciascun caso, così da poter distinguere il meglio dal peggio. Ci devono essere prove attribuibili: tracce abbastanza ricche da individuare perché un caso sia andato storto, non soltanto che sia andato storto. E ci deve essere una superficie modificabile: leve, prompt, esempi, strumenti, instradamento, che una revisione possa effettivamente muovere. Un agente produce tutte e tre come sottoprodotto del lavorare; un bot registrato non ne produce nessuna, ed è questa la ragione più profonda per cui non può apprendere. Ma un $g$ positivo non è ancora un $g$ sicuro. Un anello che si rivede su un segnale può con altrettanta facilità alzare l’errore quanto abbassarlo, se il segnale è rumoroso, l’attribuzione è errata o il cambiamento è una regressione. Rendere $g$ in modo affidabile positivo, ciclo dopo ciclo, è il compito della struttura di controllo, e questa è il DMAIC.

5. Il DMAIC come struttura di controllo

L’affermazione centrale dell’articolo è che la disciplina che trasforma un anello auto-migliorante da pericolo in un motore affidabile esiste già, pienamente elaborata, nel ciclo DMAIC del Six Sigma, a patto che la si legga non come un progetto di miglioramento una tantum ma come la struttura di controllo permanente dell’automazione, eseguita di continuo. Ciascuna fase fornisce qualcosa di cui l’anello ricorsivo della Sezione 4 ha bisogno per mantenere positivo il proprio guadagno e vera la propria direzione; la Figura 1 disegna il ciclo e la Tabella 3 mappa ciascuna fase sul suo ruolo.

Define. L’anello ha bisogno di un obiettivo che non sia il surrogato che sarà tentato di inseguire. Define enuncia l’esito che l’automazione serve, le tolleranze che contano come successo e una stima onesta del limite inferiore $\varepsilon_\ast$ al di sotto del quale ogni ulteriore sforzo è spreco, così che l’anello ottimizzi il risultato di business e non un suo comodo surrogato. La maggior parte dei fallimenti da retroazione fuori controllo sono fallimenti di Define: l’anello ha migliorato esattamente ciò che gli era stato detto, che era la cosa sbagliata.

Measure. Non c’è guadagno di miglioramento senza un segnale, e Measure è la fase che ne fabbrica uno, strumentando ogni caso affinché l’esito, le correzioni e i punti di esitazione siano registrati, non campionati per aneddoti. È la forma moderna dell’intuizione di Shewhart secondo cui non si può migliorare ciò che non si misura, ed è anche il punto in cui il process mining (van der Aalst, 2016) si guadagna il suo posto, ricostruendo ciò che il processo ha realmente fatto a partire dai propri log di eventi anziché da come lo si immaginava funzionare.

Analyse. L’errore caratteristico di un anello di apprendimento è reagire al rumore come se fosse segnale, riregolandosi sulla normale dispersione di un processo stabile e andando in sovraccarico. Analyse è la sentinella: separa la variazione da causa comune, da lasciare in pace, dalla variazione da causa speciale, su cui agire, e attribuisce l’errore su cui si può intervenire a una causa abbastanza specifica da poter essere corretta. È la distinzione di Shewhart (1931) che fa esattamente il lavoro per cui fu inventata, ora a protezione di un’automazione dal rincorrere la propria coda.

Improve. Solo ora si opera un cambiamento: una revisione alle istruzioni dell’agente, ai suoi esempi, ai suoi strumenti, ai suoi controlli, oppure all’instradamento che invia una classe di casi difficili a una persona o a un percorso specializzato. Improve è il passo di mutazione dell’anello, il luogo in cui il guadagno $g$ si realizza effettivamente, ed è deliberatamente a valle della misurazione e dell’analisi, così che il cambiamento risponda a una causa diagnosticata anziché a un’intuizione.

Control. Control è la fase che rende sicuro il tutto, ed è là dove l’automazione ricorsiva si distingue più nettamente sia da un bot sia da un sistema di apprendimento non governato. Un cambiamento proposto non viene adottato perché sembra migliore; viene adottato solo se, misurato su casi tenuti da parte, risulta non peggiorare l’esito, e in caso contrario viene respinto e si conserva la versione precedente. Formalmente, scrivendo $\widehat{\varepsilon}(m)$ per l’errore misurato di una revisione candidata $m$,

dove $\gamma \ge 0$ è un margine di confidenza che impedisce alla barriera di essere ingannata dal rumore. La barriera ha un effetto preciso sull’anello: rende la successione degli errori monotòna in valore atteso,

così il miglioramento si accumula e non viene mai restituito. È questo che converte la ricorsione grezza dell’equazione (2) da una passeggiata aleatoria che potrebbe derivare ovunque in un meccanismo a cricchetto che si stringe soltanto, ed è la disciplina che il controllo statistico di processo ha dato alla manifattura un secolo fa, ora applicata a un’automazione che riscrive sé stessa. Control svolge anche l’altra, poco appariscente, metà del proprio compito: standardizza e consolida il guadagno, fissando la versione migliorata al suo posto con i propri guardrail così che il ciclo successivo parta dal nuovo limite inferiore e non dal vecchio.

L’accostamento è il punto. La ricorsione senza il DMAIC è un anello che può migliorare o rovinare con uguale facilità; il DMAIC senza la ricorsione è il progetto di miglioramento periodico che i team qualità hanno sempre condotto a mano, vincolato dalla frequenza con cui le persone possono riunirsi. Un agente che esegue il DMAIC come propria struttura di controllo permanente ottiene entrambe le cose: la rapidità e la portata del miglioramento software e la garanzia di convergenza del controllo statistico.

6. La condizione di sostituzione

Possiamo ora dire con precisione quando l’agente supera il bot. Le due automazioni affrontano lo stesso mondo in deriva, allo stesso tasso di deriva $\delta$. Il bot non ha alcun guadagno interno e perciò, per l’equazione (1), il suo errore sale con la deriva finché una persona non lo azzera. L’agente esegue il proprio anello DMAIC con tempo di ciclo $\tau$, il tempo per misurare, analizzare, proporre e sottoporre a barriera una revisione, e con guadagno per ciclo $g$, mentre la stessa deriva $\delta$ ne spinge l’errore verso l’alto. Nel tempo continuo le due forze si combinano:

un termine di apprendimento che tira l’errore verso il basso in direzione del limite inferiore e un termine di deriva che lo spinge verso l’alto. Il suo stato stazionario, dove l’anello tiene esattamente il passo del mondo, è

così l’automazione si mantiene a una distanza limitata al di sopra del limite inferiore, fissata dal rapporto tra quanto velocemente il mondo deriva e quanto velocemente l’anello apprende. Il bot, con $g \to 0$, non ha alcuno stato stazionario finito: il suo errore è limitato soltanto dal calendario di manutenzione. Si definisca il numero di sostituzione adimensionale

il rapporto tra l’errore che un ciclo rimuove e l’errore che la deriva aggiunge nel corso dello stesso ciclo. Quando $\Sigma > 1$ l’anello rimuove l’errore più velocemente di quanto l’ambiente lo inietti e l’automazione converge a una banda stretta al di sopra del limite inferiore; quando $\Sigma \gg 1$ essa si colloca essenzialmente sul limite inferiore. L’agente sostituisce il bot precisamente quando può eseguire un anello governato con $\Sigma > 1$, il che è un’affermazione su tre grandezze controllabili: si innalzi il guadagno $g$ con una migliore misurazione e attribuzione, si accorci il ciclo $\tau$ automatizzando l’anello stesso, e l’agente batte qualsiasi bot fisso in qualsiasi ambiente la cui deriva $\delta$ sia finita. La Figura 2 contrappone le due traiettorie. La lettura pratica è che la sostituzione non è una questione di se l’agente sia più abile del bot il primo giorno, spesso non lo è, ma di se il suo anello giri, sotto controllo, più velocemente di quanto giri il mondo; e una volta che ciò accade, il dente di sega del bot e la discesa dell’agente divergono per sempre.

7. Un caso costruito: contabilità fornitori

Il caso è costruito, non osservato: le sue cifre sono illustrative e internamente coerenti, ed è pensato per mostrare le grandezze del modello mentre assumono valori plausibili, non per riportare un risultato. Si consideri la funzione di contabilità fornitori di un gruppo di medie dimensioni che riceve le fatture dei fornitori in molti formati attraverso diversi portali e deve abbinare ciascuna a un ordine di acquisto e a una ricevuta di merce, codificarla e registrarla per il pagamento. È il bersaglio archetipico dell’RPA, ad alto volume, descrivibile per regole, noioso, ed è l’archetipica delusione dell’RPA, perché i formati derivano di continuo e ogni fornitore è un’eccezione pronta a verificarsi.

Il parco RPA del gruppo gestisce i layout dei fornitori più puliti e instrada tutto il resto alle persone. Al momento della messa in opera registrava direttamente circa il 55 per cento delle fatture, ma nell’arco di diciotto mesi tre aggiornamenti dei portali e un’ondata di nuovi fornitori hanno fatto scendere il tasso di elaborazione diretta e salire il tasso di errore silenzioso, cosicché un team permanente trascorre buona parte della settimana a registrare di nuovo i bot rotti e a rincorrere le registrazioni errate, la Tabella 1 fornisce la colonna del prima. Sostituire i bot registrati con un agente che legge ogni fattura per ciò che è, la abbina ragionando anziché per coordinate fisse e instrada le vere eccezioni a una persona, e avvolgere quell’agente in un anello DMAIC permanente, con il tasso di elaborazione diretta come la cosa che Measure traccia, le correzioni di ogni settimana come la prova su cui Analyse lavora, i prompt, gli esempi e i controlli di abbinamento dell’agente come ciò che Improve rivede, e un campione tenuto da parte come la barriera che Control applica, cambia sia il livello sia la sua direzione. L’agente parte solo di poco migliore del bot ma, poiché il suo anello gira più velocemente di quanto derivino i portali ($\Sigma > 1$), il suo tasso di eccezioni cala ciclo dopo ciclo verso il limite inferiore fissato dalle fatture che hanno genuinamente bisogno del giudizio umano, mentre il carico di manutenzione si inverte: invece di ingegneri che riparano registrazioni, il lavoro diventa esaminare i cambiamenti proposti dall’anello alla barriera di Control. La Tabella 1 ripercorre le grandezze del modello attraverso il caso.

8. Che cosa cambia per il modello operativo

Sostituire un bot con un agente non è uno scambio alla pari di motori sotto lo stesso cofano; cambia ciò che la funzione di automazione fa e in che cosa deve essere brava. La Tabella 2 pone le due cose fianco a fianco. Il cambiamento più grande è dove va lo sforzo umano. Con l’RPA il lavoro umano ricorrente è la riparazione: trovare e registrare di nuovo i bot che il mondo ha rotto, un compito reattivo che scala con la dimensione del parco e non produce nulla di nuovo. Con un agente governato dal DMAIC il lavoro umano ricorrente è la barriera di Control: esaminare le revisioni proposte dall’anello e decidere che cosa adottare, un compito che scala con il ritmo del miglioramento anziché con la dimensione del parco e che produce un’automazione migliore ogni volta che lo si svolge. Le competenze cambiano di conseguenza, dallo scrivere script di robot contro le schermate al definire esiti, strumentare processi e giudicare prove, vale a dire dall’ingegneria dell’automazione verso la disciplina della gestione della qualità, ora svolta alla velocità del software.

C’è un secondo cambiamento, nella governance. Un sistema che riscrive il proprio comportamento è più potente di una registrazione e richiede più responsabilità, non meno, e il DMAIC fornisce la pista di controllo come sottoprodotto: ogni cambiamento adottato risponde a una causa misurata, ha superato una barriera registrata e può essere attribuito e annullato, cosicché un’automazione auto-migliorante è, se ben condotta, più ispezionabile del bot opaco che sostituisce, non meno. La fase di Control è tanto uno strumento di conformità quanto uno strumento di qualità. Ciò conta soprattutto là dove l’automazione tocca il lavoro regolamentato, ed è la stessa disciplina, il cambiamento misurato dietro una barriera, che abbiamo sostenuto altrove nella nostra ricerca sull’IT regolamentato.

9. Obiezioni e risposte

Un agente è molto più costoso per caso di un bot. Per caso, oggi, spesso sì, e per un compito circoscritto, stabile, ad alto volume il cui ambiente genuinamente non deriva, un bot registrato può rimanere la scelta economica, e nulla qui dice il contrario. L’argomento morde là dove l’ambiente deriva, che è la maggior parte dei casi, perché lì il vero costo del bot non è il suo prezzo per caso ma la sua coda di manutenzione e i suoi errori silenziosi, e l’anello dell’agente ripaga il proprio costo unitario più alto eliminando entrambi. Il confronto da fare è il costo sull’intero ciclo di vita a fronte di un ambiente in deriva, non il costo unitario del primo giorno.

Questo è solo RPA con un modello innestato sopra, che i fornitori già vendono. È l’opposto. Innestare un modello in un’orchestrazione fissa, l’automazione intelligente così come è comunemente venduta, mantiene la fragile struttura di controllo e ne rende più intelligenti i componenti, così alza di poco il limite ed eredita il deterioramento. L’affermazione qui riguarda la struttura di controllo stessa: sostituire l’orchestrazione fissa con un anello governato che riscrive l’automazione a partire dal proprio output. Il motore è la metà più piccola del cambiamento; l’anello è la più grande.

Un sistema auto-migliorante che modifica il proprio comportamento è un rischio che non si può governare. È un rischio, e non governato è un rischio serio, ed è proprio questa l’intera ragione per cui la seconda fondamenta dell’articolo è una disciplina di controllo e non un modello. Un agente che si riregola su un segnale rumoroso senza alcuna fase di Analyse e senza alcuna barriera di Control deriverà e regredirà davvero. La risposta non è vietare l’anello ma governarlo con il metodo che la manifattura ha usato per un secolo per governare i processi autoregolanti: misurare, separare il segnale dal rumore, cambiare a fronte di una causa diagnosticata e adottare soltanto ciò che una barriera dimostra non peggiorare le cose. Un anello governato è più responsabile di un bot, non meno.

Il vostro modello è troppo semplice; l’errore reale non cala geometricamente. Il modello è una semplificazione deliberata e le sue costanti non sono misurate; il suo scopo è rendere leggibile la struttura, che un bot ha $g = 0$ e un agente governato ha $g > 0$, e che la sostituzione dipende dal fatto che l’anello sopravanzi la deriva. La forma geometrica è il comportamento generico di un controllore proporzionale a fronte di un limite inferiore, non una legge empirica precisa, e la Sezione 10 lo dice. Il numero di sostituzione $\Sigma$ è inteso come un modo di pensare, non come una cifra da citare a tre decimali.

10. Limiti

Questo è un ragionamento rivolto ai professionisti con un modello deliberatamente semplice, e i suoi limiti dovrebbero essere evidenti. Il modello delle Sezioni da 3 a 6 è illustrativo: la deriva lineare dell’equazione (1), il guadagno costante dell’equazione (2) e il singolo limite inferiore $\varepsilon_\ast$ sono semplificazioni scelte per leggibilità, e la deriva reale è a sbalzi, il guadagno reale diminuisce man mano che il limite inferiore si avvicina, e il limite inferiore stesso si sposta al cambiare del compito; il numero di sostituzione $\Sigma$ è una lente, non una grandezza misurata, e non lo abbiamo stimato a fronte di dati di campo. Il ragionamento è circoscritto ai processi che derivano e che recano un segnale di esito utilizzabile; un compito genuinamente stazionario e ad alto volume può ancora favorire un bot registrato, e un processo privo di un esito misurabile priva l’anello del segnale da cui dipende l’intero meccanismo. L’affermazione riguarda una struttura di controllo, non un prodotto, e la specifica tecnologia degli agenti è agli inizi e si muove in fretta; un lettore dovrebbe tenere la struttura, un anello ricorsivo governato batte una regola congelata in un mondo in movimento, e riesaminare i componenti man mano che cambiano. Infine, il guadagno è onesto soltanto quanto lo sono le fasi di Measure e di Control: un’organizzazione che strumenta male, o che lascia la barriera decadere in un timbro di gomma, otterrà i rischi della ricorsione senza la sua convergenza, il che è una ragione per prendere sul serio la disciplina, non un difetto dell’idea.

11. Conclusione

L’automazione robotica dei processi fece qualcosa di utile registrando come una persona guida un sistema e riproducendolo, ma automatizzò la superficie di un compito e la congelò, e una regola congelata in un mondo in movimento si deteriora: il suo errore sale con la deriva, la sua spesa di manutenzione cresce con il suo parco, e i suoi fallimenti peggiori sono silenziosi. Gli agenti IA la sostituiscono non riproducendo le stesse regole con un motore più costoso ma chiudendo un anello che una registrazione non può chiudere, migliorando l’automazione a partire dalla propria esecuzione, ciclo dopo ciclo. Quella ricorsione è la prima fondamenta e, da sola, è pericolo tanto quanto aiuto. La seconda fondamenta è ciò che la rende affidabile: il ciclo DMAIC, inteso non come un progetto una tantum ma come la struttura di controllo permanente dell’automazione, Define, definire l’obiettivo e il limite inferiore, Measure, misurare ogni caso, Analyse, distinguere il segnale dal rumore, Improve, migliorare a fronte di una causa diagnosticata, e Control, controllare con una barriera che adotta soltanto ciò che in modo misurabile non peggiora le cose, così che il miglioramento diventi un meccanismo a cricchetto e non una scommessa. Nel modello dell’articolo la differenza è la differenza tra un guadagno di miglioramento pari a zero e un guadagno mantenuto in modo affidabile positivo, e l’agente supera il bot esattamente quando il suo anello governato rimuove l’errore più velocemente di quanto il mondo lo inietti. L’ingegneria che ne consegue riguarda meno il modello che legge la fattura che non l’anello costruito attorno a esso, e la disciplina di cui quell’anello ha bisogno è una che il settore possiede da un secolo e può ora eseguire alla velocità del software. Automatizza il compito, misura ciò che accade, migliora a fronte di ciò che misuri, e non lasciare che nulla cambi l’automazione che una barriera non abbia mostrato essere migliore. Un bot è una fotografia di un processo; un agente governato è il processo che apprende. Questa è la sostituzione, ed è tutta qui.

Appendice A. Esecuzione del DMAIC come anello di controllo di un’automazione

Le pratiche seguenti sono ciò che mantiene un’automazione ricorsiva in convergenza anziché in deriva. Nessuna è una novità per l’IA; ciascuna è la tradizione della qualità applicata a un’automazione che riscrive sé stessa.

Riferimenti bibliografici

Argyris, C., & Schön, D. A. (1978). Organizational learning: A theory of action perspective. Addison-Wesley. ISBN 978-0-201-00174-3.

Ashby, W. R. (1956). An introduction to cybernetics. Chapman & Hall. http://pcp.vub.ac.be/books/IntroCyb.pdf

Benner, M. J., & Tushman, M. L. (2003). Exploitation, exploration, and process management: The productivity dilemma revisited. Academy of Management Review, 28(2), 238–256. https://doi.org/10.2307/30040711

Box, G. E. P. (1957). Evolutionary operation: A method for increasing industrial productivity. Journal of the Royal Statistical Society: Series C (Applied Statistics), 6(2), 81–101. https://doi.org/10.2307/2985505

Deming, W. E. (1986). Out of the crisis. MIT Center for Advanced Engineering Study. ISBN 978-0-911379-01-0.

Harry, M. J., & Schroeder, R. (2000). Six Sigma: The breakthrough management strategy revolutionizing the world’s top corporations. Currency/Doubleday. ISBN 978-0-385-49437-3.

Hofmann, P., Samp, C., & Urbach, N. (2020). Robotic process automation. Electronic Markets, 30(1), 99–106. https://doi.org/10.1007/s12525-019-00365-8

Lacity, M., & Willcocks, L. P. (2016). Robotic process automation at Telefónica O2. MIS Quarterly Executive, 15(1), 21–35. https://aisel.aisnet.org/misqe/vol15/iss1/4/

Linderman, K., Schroeder, R. G., Zaheer, S., & Choo, A. S. (2003). Six Sigma: A goal-theoretic perspective. Journal of Operations Management, 21(2), 193–203. https://doi.org/10.1016/S0272-6963(02)00087-6

Montgomery, D. C. (2024). Introduction to statistical quality control (8th ed.). Wiley. ISBN 978-1-119-72309-7.

Pyzdek, T., & Keller, P. A. (2023). The Six Sigma handbook (6th ed.). McGraw-Hill. ISBN 978-1-26-514399-2.

Shewhart, W. A. (1931). Economic control of quality of manufactured product. D. Van Nostrand. ISBN 978-0-87389-076-2 (ASQ reprint).

Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., & Yao, S. (2023). Reflexion: Language agents with verbal reinforcement learning. In Advances in Neural Information Processing Systems 36 (NeurIPS 2023). https://arxiv.org/abs/2303.11366

Sutton, R. S., & Barto, A. G. (2018). Reinforcement learning: An introduction (2nd ed.). MIT Press. ISBN 978-0-262-03924-6.

Syed, R., Suriadi, S., Adams, M., Bandara, W., Leemans, S. J. J., Ouyang, C., ter Hofstede, A. H. M., van de Weerd, I., Wynn, M. T., & Reijers, H. A. (2020). Robotic process automation: Contemporary themes and challenges. Computers in Industry, 115, 103162. https://doi.org/10.1016/j.compind.2019.103162

van der Aalst, W. M. P. (2016). Process mining: Data science in action (2nd ed.). Springer. https://doi.org/10.1007/978-3-662-49851-4

van der Aalst, W. M. P., Bichler, M., & Heinzl, A. (2018). Robotic process automation. Business & Information Systems Engineering, 60(4), 269–272. https://doi.org/10.1007/s12599-018-0542-4

Wang, L., Ma, C., Feng, X., Zhang, Z., Yang, H., Zhang, J., Chen, Z., Tang, J., Chen, X., Lin, Y., Zhao, W. X., Wei, Z., & Wen, J.-R. (2024). A survey on large language model based autonomous agents. Frontiers of Computer Science, 18(6), 186345. https://doi.org/10.1007/s11704-024-40231-1

Wewerka, J., & Reichert, M. (2023). Robotic process automation: A systematic mapping study and classification framework. Enterprise Information Systems, 17(2), 1986862. https://doi.org/10.1080/17517575.2021.1986862

Wiener, N. (1948). Cybernetics: Or control and communication in the animal and the machine. MIT Press. ISBN 978-0-262-73009-9.

Willcocks, L. P., Lacity, M., & Craig, A. (2015). The IT function and robotic process automation (The Outsourcing Unit Working Research Paper Series). London School of Economics and Political Science, LSE Research Online item 64519. http://eprints.lse.ac.uk/64519/

Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., & Cao, Y. (2023). ReAct: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR 2023). https://arxiv.org/abs/2210.03629