Leader di pensiero

Perché i progetti di IA agentica vengono cancellati e cosa fa bene un progetto pilota di otto settimane

mm
Aggiungi Unite.AI alle tue fonti preferite su Google
Punti chiaveMost agentic AI risk sits in the business processes the agent inherits rather than in…
Vedi di più
  • Most agentic AI risk sits in the business processes the agent inherits rather than in the model itself.
  • Value hinges on cost per completed task once human oversight is counted not on raw agent speed.
  • An eight-week pilot should end in a scale fix or stop decision grounded in baseline evidence.

Un cliente chiede un rimborso e l’agente trova l’ordine nel CRM, verifica la politica sui resi e prepara una risposta in meno di un minuto. Poi si blocca, perché l’approvazione del rimborso si trova in un sistema finanziario a cui non è mai stato collegato e l’indirizzo del cliente non coincide nei due database. Lacune di questo tipo raramente emergono durante una dimostrazione, eppure determinano quanto costa gestire un agente e se ci si può fidare di lui. Il rischio maggiore dell’IA agentica, quindi, risiede nell’azienda in cui viene inserito l’agente, non nel modello.

Gartner prevede che oltre il 40% dei progetti di IA agentica verrà cancellato entro la fine del 2027, indicando come cause l’aumento dei costi, il valore aziendale poco chiaro e controlli dei rischi insufficienti. A ben guardare, la previsione riguarda il modo in cui questi progetti vengono approvati sulla base di una dimostrazione, senza avere un quadro chiaro dei costi attuali del lavoro né di chi sia responsabile dei risultati.

La domanda che rivolgerei a qualsiasi gruppo dirigente è se l’azienda sia in grado di sostenere questo agente mentre svolge il lavoro ogni giorno, a un costo e con un livello di rischio accettabili. Per rispondere, occorre esaminare attentamente quello che chiamo il lavoro successivo all’automazione, cioè tutto ciò che le persone devono ancora fare una volta che l’agente ha completato la sua parte. Un progetto pilota di otto settimane è un modo pratico per misurarlo prima di impegnarsi in un’implementazione su vasta scala.

I problemi che un agente eredita dall’azienda

Raramente un agente lavora da solo: anche un’attività che sembra semplice coinvolge i dati dei clienti, un paio di applicazioni aziendali e, di solito, una fase di approvazione; inoltre, ogni collegamento limita ciò che l’agente può vedere e fare. Se i dati sono incoerenti o non è chiaro chi debba dare l’approvazione, l’agente eredita la confusione insieme all’attività.

I casi di routine raramente sono il problema: lo sono le eccezioni, perché è lì che si accumulano i costi operativi, ed è proprio la parte che una dimostrazione è concepita per evitare. La ricerca di Deloitte del 2026 ha rilevato che solo il 5% delle organizzazioni ritiene che i propri processi aziendali siano altamente pronti per gli agenti di IA. È un dato più rivelatore di qualsiasi benchmark dei modelli, perché suggerisce che l’IA è pronta molto prima della maggior parte dei processi.

Il business case deve includere il lavoro successivo all’automazione

Misurare quanto rapidamente un agente produce un risultato è il modo più semplice per sopravvalutarne il valore, perché ciò che conta è l’impegno necessario per portare a termine l’attività. Supponiamo che un dipendente impieghi 20 minuti per gestire una richiesta e che l’agente riduca la prima elaborazione a due minuti: sembra un risparmio di 18 minuti, finché qualcuno non ne impiega 15 per verificare il risultato e correggere gli errori. Risparmiare tre minuti offre un vantaggio esiguo quando si mette sull’altro piatto della bilancia il costo di gestione dell’agente.

L’analisi di McKinsey su un agente di assistenza clienti in ambito bancario mostra lo stesso schema su vasta scala: i token rappresentavano il 20–25% dei costi operativi variabili, mentre la supervisione umana ne rappresentava il 70–75%; la maggior parte dei costi, quindi, era al di fuori del modello. Se non si definisce un valore di riferimento prima che qualcuno scriva il codice, un progetto pilota può mostrare notevoli progressi tecnici e lasciare comunque senza verifica il business case dell’investimento. Come minimo, il responsabile aziendale deve avere una risposta chiara su ciascuno dei seguenti punti:

  • Volume: con quale frequenza viene eseguito il processo e quante persone vi partecipano.
  • Tempo di completamento: quanto tempo richiede l’intera attività, comprese verifiche e correzioni.
  • Accuratezza: con quale frequenza si verificano errori o è necessario ripetere il lavoro.
  • Costo per attività: quanto costa oggi completare correttamente un’attività.
  • Impatto aziendale: cosa cambierebbe, grazie a un miglioramento concreto, per i clienti, il personale o l’azienda.

Un agente deve dimostrare di meritare un posto nel flusso di lavoro

L’adozione viene di solito classificata come gestione del cambiamento, ma, nella mia esperienza, si decide molto prima, in base a dove viene collocato l’agente nel flusso di lavoro. Una società globale di servizi professionali aveva sviluppato agenti per le attività di assistenza e conformità. Il suo agente di assistenza era in grado di recuperare informazioni da diversi sistemi interni, ma per usarlo le persone dovevano aprire un’applicazione separata e, per lo più, non si prendevano la briga di farlo. Quando lo stesso flusso di lavoro è stato integrato nella piattaforma di assistenza già in uso, l’agente è comparso direttamente nel ticket su cui gli addetti stavano già lavorando. Anche l’agente di verifica della conformità è stato integrato in Salesforce, in modo da attivarsi ogni volta che veniva creato un caso.

Gli agenti non sono cambiati: è cambiata la loro posizione nel flusso di lavoro. Gli addetti avevano già un motivo per aprire un ticket o creare un caso, quindi raggiungerli in quel momento non richiedeva alcuno sforzo aggiuntivo. La collocazione è dunque una scelta architetturale tanto quanto una scelta relativa all’adozione, perché l’agente ha bisogno del contesto in cui si svolge il lavoro e il suo risultato deve alimentare il passaggio successivo senza che qualcuno debba copiarlo manualmente.

L’autonomia cambia il quadro della sicurezza

Un agente che può soltanto leggere informazioni comporta un tipo di rischio; un agente che può modificare dati o inviare e-mail ai clienti ne comporta uno del tutto diverso. I controlli devono quindi essere adeguati a ciò che l’agente è effettivamente autorizzato a fare. Permessi eccessivi e fughe di dati sensibili sono rischi ben noti, ma l’iniezione di prompt merita la massima attenzione: si tratta di istruzioni nascoste in un documento o in un’e-mail che l’agente intercetta mentre svolge un’attività del tutto legittima.

Le indicazioni di Gartner del maggio 2026 sulla governance degli agenti suddividono l’autonomia in quattro livelli e offrono un metodo pratico per decidere quanto rigorosi debbano essere i controlli:

  1. Osservare: l’agente recupera informazioni e individua schemi, con accesso in sola lettura.
  2. Consigliare: l’agente suggerisce un’azione e un dipendente prende la decisione.
  3. Agire previa approvazione: l’agente prepara o avvia un’azione che una persona deve autorizzare prima che venga eseguita.
  4. Agire in autonomia: l’agente esegue autonomamente le azioni approvate entro limiti prestabiliti, con monitoraggio e inoltro delle eccezioni ai livelli competenti.

A ogni livello, un agente deve disporre di una propria identità, di autorizzazioni limitate alle attività che svolge e di un registro di ogni azione intrapresa. Le organizzazioni devono inoltre stabilire regole per la gestione e la conservazione dei dati, chiarire quali informazioni vengono trasmesse ai fornitori esterni di modelli e individuare una persona autorizzata a sospendere l’agente e revocargli l’accesso non appena qualcosa sembra non andare.

Tutti questi controlli comportano costi ricorrenti: autorizzazioni più ampie, monitoraggio aggiuntivo e approvazioni frequenti, infatti, accumulano costi nel tempo. Il giusto livello di autonomia è quindi una scelta economica oltre che di sicurezza, e corrisponde al punto in cui l’agente produce un risultato vantaggioso a un livello di rischio accettabile per l’azienda.

Scegliere un processo che giustifichi l’impiego di un agente

Molti team partono dalla tecnologia e poi cercano un problema da risolvere, mentre sarebbe meglio cominciare da un processo i cui costi o ritardi siano già evidenti a chi se ne occupa.

Una società globale che opera nel settore delle reti di esperti con cui abbiamo collaborato rispondeva a questa descrizione: il suo team abbinava le richieste di partecipazione a sondaggi agli esperti consultando tre sistemi non collegati tra loro e verificava manualmente i profili, la partecipazione precedente e la conformità per ogni abbinamento. Abbiamo realizzato un agente che combinava la ricerca semantica con lo storico delle partecipazioni e le regole di conformità. Una volta entrato in produzione, il numero di ticket relativi ad abbinamenti errati è diminuito dell’80%, la precisione degli abbinamenti è aumentata del 40% e il team ha recuperato il 22% della propria capacità operativa.

Il progetto ha funzionato perché il problema era ben definito: le informazioni erano disperse, l’unione dei dati avveniva manualmente e la qualità degli abbinamenti si poteva misurare prima e dopo l’intervento. Una definizione precisa aiuta anche a capire se un processo abbia davvero bisogno di un agente. I compiti regolati da regole fisse sono di solito meno costosi da gestire con l’automazione convenzionale; per le attività che consistono soprattutto nel trovare e riassumere informazioni è spesso sufficiente un assistente IA. Gli agenti giustificano i costi e i rischi aggiuntivi quando il lavoro richiede di interpretare il contesto, scegliere tra azioni consentite e concatenare più passaggi per raggiungere un risultato.

Un progetto pilota di otto settimane con tappe decisionali chiare

L’intero progetto pilota ruota attorno a una domanda commerciale: questo agente può migliorare il processo abbastanza da giustificarne l’uso su larga scala? Otto settimane sono sufficienti per valutare il caso aziendale, la tecnologia e la capacità dell’organizzazione di gestire ciò che realizza.

Settimane 1–2: stabilire cosa deve migliorare

Per prima cosa, documentate il processo così com’è oggi, dal volume e dai tempi di completamento ai tassi di errore, alle rilavorazioni e ai costi. Annotate i sistemi coinvolti, chi è responsabile di ogni fase e quali eccezioni richiedono l’intervento di una persona; quindi, fate concordare al responsabile aziendale e al team tecnico un unico risultato che l’agente dovrà migliorare. Punto decisionale: procedete solo quando il problema, il valore di riferimento, il responsabile e le metriche di successo sono chiari.

Settimana 3: definire i limiti dell’agente

In questa fase si definiscono i limiti dell’agente: identità, autorizzazioni, accesso ai dati, strumenti approvati e grado di autonomia. Mettetelo alla prova contro prompt injection, accessi non autorizzati, esposizione di dati sensibili e uso improprio degli strumenti; predisponete inoltre la registrazione delle attività, la risposta agli incidenti e una procedura per sospendere l’agente o revocargli l’accesso. Punto decisionale: procedete solo dopo aver effettivamente testato i controlli e le misure di intervento e aver chiarito a tutti cosa può fare l’agente.

Settimane 4–6: mettere alla prova le condizioni che fanno fallire la dimostrazione

A questo punto, affidategli attività realistiche, che includano registri incompleti, informazioni contraddittorie, richieste insolite e occasionali malfunzionamenti del sistema. Monitorate il numero di attività completate, il livello di precisione e la quantità di correzioni necessarie da parte delle persone; poi calcolate il costo effettivo di ogni attività completata con successo, includendo l’uso dei modelli, le integrazioni, il monitoraggio e la revisione. Punto decisionale: passate ai test in ambiente reale quando l’agente raggiunge le soglie concordate e il team comprende sia i costi di gestione sia le modalità con cui può fallire.

Settimane 7–8: coinvolgere utenti reali

Mettetelo a disposizione di un piccolo gruppo di dipendenti e affidategli una parte circoscritta del lavoro reale, mantenendo il processo precedente per tutto ciò che l’agente non è in grado di gestire. Verificate se le persone lo usano davvero, se permette loro di risparmiare tempo e fatica e se si fidano dei risultati che produce.

Alla fine, confrontate i risultati con il valore di riferimento rilevato nella prima settimana e valutate la produttività, la precisione, l’adozione, la frequenza degli interventi umani, i costi operativi totali e gli eventuali rischi per la sicurezza ancora irrisolti. A quel punto, la decisione sarà se estendere l’uso, correggere problemi specifici e ripetere i test oppure fermarsi. Anche un progetto pilota che dimostra che l’agente è troppo costoso o inaffidabile per il compito ha raggiunto il suo scopo: ha evitato un investimento molto più consistente basato su supposizioni.

Misurare i risultati, poi decidere quanta autonomia concedere

Contare quante attività elabora un agente dice ben poco: un sistema può gestire migliaia di richieste e lasciare comunque ai dipendenti il compito di verificarne, correggerne o completarne la maggior parte. Il costo per attività completata correttamente, considerato insieme alla precisione e ai tassi di eccezione, offre un quadro molto più chiaro dell’effettivo miglioramento del processo nel suo complesso.

Queste stesse metriche giustificano la concessione di maggiore autonomia a un agente. Ci si può fidare di un agente che gestisce con affidabilità le richieste di routine entro i limiti concordati e lasciarlo agire senza supervisione; se invece continua a incontrare casi ambigui, una persona dovrà approvare quelle decisioni, mentre le autorizzazioni verranno riesaminate man mano che si raccolgono prove.

Ampliare l’impiego quando l’azienda può sostenere l’agente

Prima o poi, un agente che funziona bene per un team dovrà interagire anche con altri reparti, applicazioni e iter di approvazione. Per ampliarne l’impiego servono responsabilità ben definite, controlli degli accessi coerenti e una modalità per gestire le eccezioni, oltre a un budget per mantenerlo aggiornato quando cambiano i processi che lo circondano.

La decisione di fondo è quanta responsabilità l’organizzazione sia pronta a delegare: deve basarsi su prove tratte dal lavoro reale, non su una demo convincente. Al termine delle otto settimane, i responsabili dovrebbero sapere quali attività l’agente è in grado di gestire, in quali casi è ancora necessario l’intervento delle persone e quanto costerà mantenerlo operativo. Le aziende che si distingueranno nell’IA agentica saranno quelle che, fin dalla prima settimana, progetteranno tenendo conto del lavoro da svolgere dopo l’automazione e investiranno negli agenti per le attività che portano effettivamente a termine.

Bhupendra Chopra è Chief Revenue Officer e cofondatore di Kanerika, un’azienda che offre soluzioni per i dati e l’IA. Collabora con le aziende per modernizzare le piattaforme dati, adottare l’IA e portare i progetti di IA dalla fase pilota alla produzione. La sua esperienza comprende Microsoft Fabric, Databricks, le migrazioni a Power BI, la governance dei dati e l’IA agentica.

Prima di cofondare Kanerika, Bhupendra ha ricoperto diversi ruoli presso Informatica, Oracle e TCS. Ha completato lo Stanford Leadership Learning Program e un programma dirigenziale presso IIM Indore. Risiede ad Austin, in Texas.