Autonomia in prestito: perché gli agenti di IA aziendale non possono semplicemente essere attivati
C'è una differenza tra un sistema che funziona in una dimostrazione e uno che non distrugge valore quando nessuno sta guardando. Con gli agenti di IA, quella differenza si misura in registrazioni modificate, pagamenti elaborati e decisioni prese senza intervento umano. Il problema non è tecnologico. È di governance.
Un'analisi pubblicata nel Forbes Technology Council da un senior manager di IA generativa di Amazon Web Services colloca il dibattito esattamente dove dovrebbe stare: non nelle capacità del modello, ma nell'architettura di supervisione che circonda l'agente. La domanda operativa che propone è brutalmente semplice. Prima di dispiegare un sistema agenticow, occorre sapere se la propria organizzazione è in grado di rilevare i suoi errori dopo che si sono verificati, e se tale rilevamento può modificare ciò che il sistema fa. Se la risposta a una delle due domande è no, la decisione di concedere autonomia è prematura, indipendentemente dai benchmark che il modello ha superato.
Potrebbe sembrare conservativo in un mercato in cui Grand View Research stima che il segmento globale dell'IA agentica raggiungerà i 22,9 miliardi di dollari nel 2026 e proietta 224,5 miliardi per il 2033. Ma la dimensione del mercato non è un argomento di sicurezza. È un argomento di urgenza per costruire bene.
Il modello di rimborso che rivela il problema di fondo
L'analisi utilizza un esempio che sembra banale ma si rivela preciso: un agente che gestisce i rimborsi ai clienti. La prima distinzione che stabilisce è tra la redazione di una risposta e l'emissione del rimborso. La prima produce testo che un essere umano può esaminare. La seconda modifica lo stato di un conto bancario.
Questa distinzione non è semantica. Definisce il tipo di errore possibile, la sua reversibilità e il costo di rilevamento. Un testo mal redatto genera attrito. Un pagamento errato genera perdita finanziaria, esposizione normativa e, a seconda del settore, conseguenze legali. La velocità con cui un agente può generare errori è esattamente proporzionale alla velocità con cui può operare.
L'approccio proposto consiste nel strutturare l'approvazione umana attorno a definizioni preventive: quali casi l'agente può gestire, quali prove deve avere prima di agire. Registrazioni di ordini incomplete, politiche ambigue o condizioni non specificate devono innescare un'escalation automatica, non una risposta improvvisata dal modello. Questo trasforma la supervisione umana da concetto vago in un controllo operativo con criteri espliciti.
Ciò che rende interessante questa architettura è ciò che rivela sull'errore più frequente nelle implementazioni agentiche: dare per scontato che un alto tasso di completamento equivalga a risultati corretti. Un sistema può completare il 95% dei casi e produrre comunque errori sistematici nel restante 5% senza che nessuno lo sappia, perché nessuno sta guardando i casi apparentemente riusciti. La raccomandazione è di campionare anche le risoluzioni prive di incidenti, non solo le escalation. Altrimenti, è l'agente stesso a decidere quali parti del proprio lavoro ricevono scrutinio, il che è esattamente l'opposto della supervisione.
Uno studio del 2026 che ha valutato 15 modelli su due benchmark distinti ha rilevato che i miglioramenti in termini di capacità si sono accompagnati a guadagni modesti in affidabilità. Il dato è rilevante perché rompe l'intuizione più comune: che un modello più potente sia proporzionalmente più sicuro da dispiegare. Potenza e consistenza non scalano alla stessa velocità.
L'economia che i report tendono a nascondere
L'analisi propone un calcolo ipotetico con 1.000 casi di rimborso: 850 risolti dall'agente senza correzione umana, 100 risolti da persone, 50 irrisolti. Il software e l'infrastruttura costano 400 dollari; la validazione, la revisione e il recupero costano 1.600 dollari. Il risultato: 950 casi verificati per 2.000 dollari, circa 2,11 dollari per caso. Il calcolo esclude i costi di implementazione iniziale e le conseguenze degli errori non rilevati.
L'aritmetica sembra favorevole. Ma la presentazione abituale dello stesso caso sarebbe quella di riportare il 95% di completamento e attribuire il risparmio all'agente. Ciò che quel report omette è il contributo del lavoro umano, che nell'esempio rappresenta l'80% del costo totale del processo. Se quel costo è assorbito da un altro team o da un'altra voce di bilancio, la decisione di scalare può essere presa su una base di costi artificialmente ridotta.
Esiste una ricerca del 2024, "AI Agents That Matter", che sostiene esattamente questo: la maggior parte delle pratiche di valutazione degli agenti si concentra troppo sulla precisione grezza e ignora il costo. Per una decisione di dispiegamento, il calcolo corretto deve includere il tempo che le persone dedicano a rivedere, correggere e completare il lavoro dell'agente. Quel tempo può essere invisibile nel budget ingegneristico se il team operativo assorbe le eccezioni senza riportarle come costo associato al sistema.
Il problema si amplifica con la scalabilità. I casi facili, che sono i primi a essere automatizzati, generano l'economia più favorevole. Estendere l'autonomia a transazioni contestate o a casi complessi richiede una valutazione separata, perché l'economia dei casi semplici non predice il tempo che quelli difficili consumeranno. Un agente che elabora 850 rimborsi standard a 0,47 dollari ciascuno può generare eccezioni che costano 60 dollari in revisione umana per caso. Il tasso di completamento aggregato continua ad apparire buono. Il margine operativo reale no.
C'è un costo aggiuntivo che l'analisi menziona e che tende a sparire dai modelli di business: la coda di revisione ha bisogno di un responsabile. I revisori necessitano di prove sufficienti per capire cosa è accaduto e di un modo per completare il caso senza ripetere tutto il lavoro precedente. Se questa capacità non è prevista nel piano di dispiegamento, i casi attendono l'approvazione mentre l'agente continua a operare, e il cliente attende ugualmente, indipendentemente dalla velocità con cui il sistema ha generato la sua risposta iniziale.
La catena che trasforma gli errori in vincoli
Il 27 ottobre 2026 IBM ha annunciato aggiornamenti alla propria piattaforma watsonx Orchestrate che includono simulazione utente, valutazione deterministica, analisi dei guasti in produzione, generazione di casi di test e un "AgentOps Agent" progettato per migliorare la qualità dell'agente prima della sua promozione in produzione. La direzione del prodotto è esattamente quella che l'analisi di Forbes descrive dal lato della governance: collegare ciò che accade in produzione con il comportamento del sistema prima che venga autorizzata un'espansione dell'autorità.
Questa architettura — test prima del dispiegamento, più osservazione in produzione, più aggiornamento dei vincoli — è il ciclo che trasforma un agente in qualcosa che un'azienda può gestire invece di semplicemente monitorare. La differenza è che il monitoraggio rileva i guasti. La gestione li converte in aggiustamenti di policy, limiti di autorizzazione o nuovi casi di test che prevengono la recidiva.
L'approccio proposto dall'analisi ha una sequenza concreta: iniziare con azioni proposte, passare all'approvazione umana, consentire l'esecuzione entro limiti definiti una volta che i risultati la giustificano. Alcuni casi potrebbero richiedere l'approvazione in modo permanente. Un cambiamento di policy, un backlog crescente o errori scoperti a posteriori devono innescare una revisione dei permessi già concessi, non una revisione di quelli futuri.
L'ultimo passaggio di questa catena è quello che più facilmente viene omesso nelle implementazioni reali: chiedere al responsabile del processo aziendale di esaminare i casi irrisolti e gli errori rilevati durante la revisione, e domandare cosa è cambiato come risultato di quell'analisi. La decisione successiva sull'autonomia dovrebbe dipendere dal fatto che quei problemi siano stati risolti e che il team che gestisce le eccezioni abbia la capacità di assorbire lavoro aggiuntivo. Se non c'è risposta a nessuna delle due domande, ampliare l'autorità dell'agente è una scommessa, non una decisione.
Prima di concedere permessi, definisci chi assorbe il costo dell'errore
Il modello che emerge da questa analisi non è nuovo nella storia dell'automazione aziendale. Ogni ondata tecnologica, dall'ERP all'RPA, è passata attraverso una fase in cui la promessa di efficienza veniva valutata sui casi che il sistema gestiva bene, e il costo reale emergeva nei casi che non gestiva. La differenza con gli agenti linguistici è che la loro flessibilità — che è esattamente ciò che li rende attraenti — rende anche i loro errori meno prevedibili rispetto a quelli di una regola deterministica.
Un agente che opera con un'istruzione in linguaggio naturale può variare il proprio comportamento in base al contesto, ai dati ambigui, agli aggiornamenti del modello o agli strumenti che rispondono diversamente a seconda dello stato del sistema. Ciò significa che validarlo rispetto a un benchmark finito in pre-produzione non garantisce la consistenza in produzione. Garantisce che ha superato quel benchmark.
La domanda che qualsiasi responsabile operativo dovrebbe porsi prima di approvare l'espansione dell'autorità di un agente non è quanti casi ha completato. È quanti dei casi che ha completato sono stati esaminati da qualcuno in grado di rilevare un errore, e cosa ha fatto l'organizzazione con gli errori trovati. Se nessuno ha esaminato i casi riusciti, se gli errori trovati non hanno modificato le regole del sistema, o se il team di revisione non ha visibilità sul ragionamento dell'agente, il tasso di completamento non misura ciò che sembra misurare.
I mercati dell'IA agentica cresceranno con o senza governance. Ciò che determinerà quali organizzazioni scalano con controllo e quali accumulano passività silenziose è esattamente questo: se il costo dell'errore è visibile nel budget corretto, se i revisori dispongono degli strumenti per completare il lavoro che l'agente non ha terminato, e se qualcuno è responsabile di trasformare ogni guasto in un vincolo che prevenga il successivo. L'autonomia non si concede. Si costruisce con evidenza operativa, e quel processo richiede più tempo di quanto il calendario di dispiegamento tenda ad ammettere.
