L’84% dei progetti di AI enterprise non supera la fase pilota, secondo McKinsey. Non per mancanza di tecnologia, per mancanza di metodo; si parte dalla soluzione prima di aver capito il problema, si implementano agenti su processi che non si conosce, si automatizza il rumore invece del segnale.
C’è qualcosa di strutturalmente sbagliato nel modo in cui il mercato sta affrontando l’agentizzazione. E il problema non è tecnico. Lo conferma, indirettamente, anche Microsoft: con il lancio di Frontier Company e Copilot Cowork, Redmond ha spostato esplicitamente il proprio obiettivo dalla qualità dei modelli alla capacità di produrre valore dentro i processi reali di un’organizzazione: non è un dettaglio di prodotto è un segnale di mercato.
Indice degli argomenti:
Prediction e judgement: due cose diverse ma che vengono confuse.
Partiamo da un concetto che sembra banale ma non lo è: ogni processo aziendale è, in fondo, una macchina per prendere decisioni. Non importa se parliamo di supply chain, assistenza clienti, onboarding commerciale o gestione documentale: sotto la superficie operativa c’è sempre una sequenza di atti decisionali.
Ogni decisione si compone di due elementi distinti: la prediction, ovvero usare le informazioni disponibili per stimare ciò che non si sa ancora, e il judgement, ovvero determinare il valore, la ricompensa, associata a un’azione in un determinato contesto.
Storicamente questi due momenti erano e sono fusi nell’azione umana. Ad esempio un responsabile acquisti valutava un fornitore usando sia la sua capacità di prevedere comportamenti futuri sia la sua esperienza nel pesare le variabili in gioco. Impossibile distinguerli, impossibile delegare solo uno dei due.
L’AI ha cambiato questa equazione in modo radicale. Il costo della prediction è crollato, esattamente come il costo dell’aritmetica è collassato con i semiconduttori negli ultimi settant’anni. Ciò che prima richiedeva analisi umane intensive oggi può essere eseguito da sistemi agentici in pochi secondi, su volumi impensabili. E questo ha una conseguenza precisa: prediction e judgement si possono finalmente disaccoppiare.
Questo decoupling è il cuore teorico dell’agentizzazione: l’AI si occupa della prediction, l’uomo presidia il judgement. Ma per eseguire questo disaccoppiamento correttamente, bisogna prima sapere dove avviene ogni decisione all’interno del processo. E qui la maggior parte delle aziende si perde.
Il mercato compra la risposta prima di capire la domanda
Tre conversazioni su cinque che ho in questo momento con aziende enterprise italiane seguono lo stesso copione: l’IT o il board ha già scelto la piattaforma, a volte ha già avviato una PoC, e quando si entra nel merito dei processi si scopre che sono mal documentati, non standardizzati, oppure già efficienti al punto che l’agentizzazione non genererebbe valore misurabile.
Il mercato spinge verso la tecnologia prima della diagnosi. I vendor promuovono piattaforme, isystem integrator propongono implementazioni. Nessuno fa la domanda giusta: quali decisioni prendete in questo processo, chi le prende, con quale frequenza e con quale costo di errore?
La direzione che sta prendendo il mercato è chiara: Microsoft ha dichiarato esplicitamente che Copilot Cowork non è un’interfaccia di domanda e risposta: analizza il compito, lo suddivide in fasi operative e utilizza gli strumenti necessari per completarlo (Il Sole 24 Ore, luglio 2026). Frontier Company nasce proprio con questa missione: aiutare le aziende a progettare, distribuire e governare sistemi AI complessi. L’infrastruttura agentica sta diventando commodity: il problema è che nessuno sta risolvendo la domanda a monte: su quali processi la installi? E con quale mappa decisionale?
Secondo IDC, il 61% delle aziende europee che ha avviato progetti di AI generativa in ambito enterprise non ha condotto una mappatura formale dei processi prima dell’implementazione. Il risultato è prevedibile: automazione di processi che non dovevano essere automatizzati, o agenti posizionati su momenti sbagliati del flusso.
Tre layer: come si legge un processo prima di toccarlo
Guardando il workflow da una prospettiva agentica, la struttura si legge su tre livelli sovrapposti.
Al livello più alto ci sono le task, le unità di lavoro che compongono il processo dall’input all’output. Al livello intermedio ci sono le decision, i momenti in cui il sistema, umano o artificiale, deve scegliere tra alternative. Al livello base ci sono i job, le responsabilità umane che il processo sostiene o riorganizza.
L’errore classico è agentizzare le task senza capire le decision: si automatizza il gesto senza toccare la logica e il risultato è più velocità nello svolgere le cose sbagliate.
Il lavoro corretto è il contrario:
- identificare prima le decision critiche
- valutare quali possono essere assorbite dall’AI attraverso la prediction
- ridisegnare i job umani attorno al judgement che rimane.
Non è un’analisi che si fa guardando una slide di processo in una riunione di kick-off. Richiede tempo, immersione, conoscenza diretta di chi lavora su quel flusso ogni giorno.
Vale la pena notare che anche Microsoft, nella strategia multi-model di Copilot Cowork, ha scelto di non legare la piattaforma a un unico modello: oggi supporta Anthropic Opus 4.8 e Sonnet 4.6, domani aggiungerà Cowork 1, il proprio modello proprietario. Questa scelta architetturale ha un’implicazione diretta per chi deve decidere dove investire: il modello non è il punto di partenza. Il processo lo è. E l’assessment che precede qualsiasi implementazione deve essere indipendente dalla scelta tecnologica.
L’assessment dei processi: il metodo che il mercato continua a saltare
La letteratura sul tema è chiara da anni, ma il mercato continua a ignorarla: nessun progetto di agentizzazione dovrebbe partire dalla scelta della piattaforma. Dovrebbe partire da un assessment strutturato dei processi decisionali. Non un’analisi generica dei flussi operativi, ma una mappatura specifica di dove, come e con quale frequenza vengono prese le decisioni che reggono quel processo.
Un assessment ben strutturato ha un obiettivo preciso: mappare i processi candidati all’agentizzazione a livello decisionale, non operativo. Significa capire quali decisioni vengono prese, con quale frequenza, con quale base informativa e con quale impatto sull’output finale. E distinguere le decisioni che già si basano su pattern riconoscibili, aggredibili dalla prediction AI, da quelle che richiedono contesto, etica, relazione, responsabilità: il territorio del judgement umano.
Il risultato non è un documento da archiviare ma è una mappa operativa (o documento di progettio che dir si voglia) che determina l’architettura degli agenti, i punti di human-in-the-loop, i trigger di escalation e i KPI di successo. Da quella mappa discende tutto il resto: la scelta della piattaforma, il design dell’orchestrazione, la gestione del rischio.
Uno scenario applicativo ricorrente in ambito manifatturiero: un’azienda con tremila addetti, processi di quality control distribuiti su più stabilimenti, decisioni di scarto prese da operatori con livelli di expertise molto variabili. La prediction AI, addestrata su storico di difettosità, può standardizzare e velocizzare la fase di classificazione. Ma la decisione finale su un lotto con parametri ambigui resta un atto di judgement, che un operatore esperto deve poter esercitare con informazioni migliori di prima, non con informazioni sostituite dall’algoritmo. Identificare questo confine con precisione chirurgica è l’obiettivo dell’assessment.
Il consiglio da dare a qualsiasi CEO prima di firmare un contratto per l’AI agentica
Non partire dalla tecnologia, partire dalla domanda: quali decisioni prendono le tue persone ogni giorno, e quale costo ha prenderle male? Quella domanda orienta tutto: quale processo toccare per primo, con quale architettura, con quale livello di autonomia degli agenti, con quale presidio umano sul judgement. La risposta alla domanda sbagliata, anche se ben eseguita tecnicamente, è un progetto che non produce valore misurabile.
Diffida di chi ti propone un’architettura agentica prima di aver analizzato i tuoi processi. Un agente ben costruito su un processo mal capito produce danni più sofisticati di una semplice automazione sbagliata: è più difficile da individuare, più costoso da correggere, e nel frattempo ha già preso decisioni che qualcuno ha creduto affidabili.
L’assessment non è un’attività di pre-vendita da chiudere in mezza giornata. È il progetto dentro il progetto, quello che determina se tutto il resto ha senso. Nella mia esperienza, saltarlo o comprimerlo è la causa più frequente di failure nelle implementazioni AI enterprise, molto più dei limiti tecnologici dei modelli.
Agentizzare un processo funziona: il problema arriva dopo, quando il board chiede: bene, ora lo facciamo anche sugli altri venti processi. E lì la maggior parte delle organizzazioni scopre di non avere né il metodo né la struttura per rispondere.
Passare da un progetto pilota a un’adozione estesa non è una questione di licenze o di capacità computazionale. È una questione di governance. Chi decide quali processi agentizzare e in quale ordine? Chi ha l’autorità di mettere un agente in produzione su un flusso che tocca dati sensibili, clienti o decisioni regolamentate? Chi monitora che l’agente stia ancora facendo quello per cui è stato progettato, tre mesi dopo il go-live?
Secondo Gartner, entro il 2027 oltre il 50% delle imprese Global 2000 avrà almeno un agente AI in produzione su processi core. Ma la stessa ricerca stima che meno del 15% di queste avrà una struttura di governance agentica formalizzata. Il gap tra deployment e controllo è già oggi il rischio principale, non la tecnologia.
Quello che serve, e che poche organizzazioni stanno costruendo, è quello che chiamo un control plane aziendale per gli agenti. Non è un tool. È un livello decisionale: un insieme di regole, ruoli e processi che stabilisce quali agenti possono operare in autonomia, su quali decisioni serve human-in-the-loop, dove si posizionano i trigger di escalation e chi ha visibilità sull’output degli agenti nel tempo.
In termini operativi, questo si traduce in tre scelte che un’organizzazione deve fare prima di scalare.
La prima è definire una mappa di priorità dei processi candidati. Non tutti i processi agentizzabili hanno lo stesso valore strategico o lo stesso profilo di rischio. Alcuni hanno alto volume decisionale e basso impatto in caso di errore: sono i candidati ideali per la prima ondata. Altri toccano compliance, relazioni con clienti chiave o dati regolamentati: richiedono un livello di controllo umano che deve essere progettato prima, non aggiunto dopo.
La seconda è assegnare ownership chiara per ogni agente in produzione. Un agente senza un owner umano identificato è un rischio aperto. L’owner non è chi lo ha sviluppato tecnicamente: è chi risponde del suo comportamento davanti al business, chi riceve l’escalation quando l’agente incontra un caso fuori dal suo perimetro, chi decide se aggiornarlo o spegnerlo.
La terza è costruire un sistema di monitoraggio sull’output, non solo sul processo. La maggior parte degli strumenti di osservabilità per gli agenti monitora latenza, token usage, errori tecnici. Quasi nessuno monitora la qualità delle decisioni nel tempo. Se un agente che gestisce la classificazione dei ticket di supporto comincia a sbagliare il 12% dei casi dopo un aggiornamento del modello sottostante, chi se ne accorge e in quanto tempo? Senza risposta a questa domanda, scalare è un rischio che il business non ha ancora quantificato.
Un assessment ben condotto non produce un documento da archiviare. Produce una mappa operativa che include, per ogni processo candidato, il profilo di rischio, il livello di autonomia raccomandato per gli agenti e i criteri di escalation verso il giudizio umano. È quella mappa che determina l’architettura del sistema agentico, non il contrario. Chi parte dal contratto con il vendor e costruisce la mappa dopo, nella migliore delle ipotesi perde tempo. Nella peggiore, costruisce un sistema che ottimizza le decisioni sbagliate.
Il valore dell’AI agentica non sta negli agenti: sta nel capire dove metterli e come tenerli sotto controllo mentre scalano. Microsoft lo ha capito a livello di prodotto, spostando il focus dal benchmark al valore operativo.
La domanda che rimane aperta, per la maggior parte delle organizzazioni, è quella che viene prima: quale processo, quale decisione, quale confine tra prediction e judgement. E subito dopo: chi governa tutto questo quando smette di essere un pilota e diventa infrastruttura.
Senza rispondere a questa domanda, si finisce per costruire efficienza su fondamenta che non la reggono. E quando un progetto AI fallisce, raramente fallisce per la tecnologia. Fallisce per aver automatizzato la risposta sbagliata alla domanda sbagliata.
Partecipa alla community