Gli investimenti crescono, l’adozione si estende, i ritorni economici restano concentrati in una minoranza di imprese. Il divario emerge con chiarezza dai dati richiamati dall’Harvard Business Review: secondo il BCG AI Radar 2026, le aziende prevedono di portare la spesa per l’intelligenza artificiale dallo 0,8% all’1,7% dei ricavi nel corso dell’anno.
Allo stesso tempo, la 29th Global CEO Survey di PwC rileva che appena il 12% dei 4.454 amministratori delegati intervistati in 95 Paesi ha ottenuto dall’AI sia una crescita dei ricavi sia una riduzione dei costi.
Il problema, secondo Masha Shunko e Serguei Netessine, autori dell’analisi Stop Automating Old Processes. Design New Ones Instead pubblicata recentemente dall’Harvard Business Review, riguarda il modo in cui le organizzazioni impostano i progetti. Molte iniziative applicano l’AI a singole attività all’interno di procedure già esistenti. Il risultato è un guadagno locale di velocità o produttività, che fatica a tradursi in un miglioramento dell’intero servizio, dell’esperienza del cliente o del conto economico.
Indice degli argomenti
La trappola della produttività locale
Automatizzare un’attività offre un vantaggio immediatamente visibile. Un sistema genera una bozza in pochi secondi, classifica una richiesta, aggiorna una scheda prodotto o suggerisce una risposta. Questi miglioramenti sono facili da dimostrare e da misurare durante un progetto pilota. Il valore aziendale, però, nasce dalla sequenza completa che conduce a un esito riconoscibile per il cliente o per l’organizzazione.
L’HBR individua quattro errori ricorrenti.
- Il primo consiste nel confondere la velocità di esecuzione con il valore prodotto. Se una fase accelera mentre le verifiche, le approvazioni o la lavorazione a valle restano immutate, il tempo risparmiato si accumula davanti al passaggio successivo. Il collo di bottiglia cambia posizione e il ciclo complessivo conserva gran parte della sua durata.
- Il secondo errore riguarda le eccezioni. Una dimostrazione viene costruita spesso sul percorso lineare, con dati completi e casi facili da interpretare. L’operatività quotidiana comprende invece informazioni mancanti, richieste ambigue, conflitti tra regole e situazioni che esigono giudizio. Un sistema efficace sul percorso standard può quindi generare lavoro aggiuntivo proprio nei casi più delicati, trasferendo agli addetti il compito di individuare e correggere gli errori.
- Il terzo nasce dall’ottimizzazione di una singola funzione. Un reparto può aumentare il volume trattato, mentre l’unità successiva riceve più pratiche di quante riesca a gestire oppure deve dedicare tempo a controllarne la qualità. L’analisi dell’HBR invita perciò a osservare dipendenze, passaggi di consegna e responsabilità lungo l’intero flusso.
- Il quarto errore è una misurazione troppo vicina alla tecnologia. Numero di contenuti prodotti, pratiche elaborate o minuti risparmiati descrivono l’attività del sistema. Dicono poco, da soli, sulla qualità dell’esito, sulla fiducia del cliente, sui ricavi, sui costi complessivi e sul rischio. Una metrica operativa può migliorare mentre la prestazione aziendale rimane stabile o peggiora.
Deloitte Australia e Wayfair, due approcci a confronto
La differenza tra automazione puntuale e riprogettazione emerge nei due casi utilizzati dall’HBR. Nel primo (noto) caso, Deloitte Australia ha impiegato l’AI generativa nella preparazione di un rapporto destinato al governo australiano. Il documento conteneva riferimenti inesistenti e informazioni inventate. La vicenda mostra l’effetto di un processo in cui la generazione del contenuto è stata accelerata senza una verifica capace di intercettare in modo affidabile gli errori prima della consegna.
La lezione riguarda la struttura del flusso. Se l’AI aumenta rapidamente la quantità di testo prodotta, anche il fabbisogno di controllo cambia. La verifica deve disporre di fonti identificabili, criteri di attendibilità, responsabilità assegnate e condizioni che impediscano l’uscita di un documento ancora incerto. L’automazione della produzione amplia il rischio quando il processo di validazione conserva regole e capacità pensate per un ritmo precedente.
Wayfair ha seguito una strada diversa nella gestione del catalogo prodotti. Secondo la ricostruzione dell’Harvard Business Review, l’azienda ha ridisegnato il processo introducendo soglie di confidenza, intervento umano per i casi dubbi e un meccanismo di apprendimento continuo. L’AI gestisce le situazioni che rientrano nei parametri stabiliti; l’incertezza attiva un passaggio verso una persona; le decisioni prese alimentano il miglioramento successivo.
Il confronto mette in evidenza l’unità minima di progettazione. Nel caso Deloitte l’intervento si concentra sul compito di produrre un testo. Nel caso Wayfair comprende classificazione, valutazione della confidenza, instradamento delle eccezioni, decisione umana e apprendimento. Il workflow viene costruito intorno al risultato richiesto e incorpora fin dall’inizio il comportamento da adottare quando il modello non offre una risposta sufficientemente affidabile.
Prima decisione: scegliere che cosa ridisegnare
Per l’HBR, la valutazione deve precedere il pilot. La disponibilità di un modello capace di svolgere un’attività rappresenta soltanto uno degli elementi. Il CIO, insieme ai responsabili delle funzioni coinvolte, deve capire quale risultato meriti di essere migliorato, perché il processo abbia assunto la forma attuale e se il nuovo disegno possa produrre conoscenza riutilizzabile.
Partire dal risultato apprezzato dal cliente
L’Outcome Test proposto dagli autori porta l’attenzione sull’esito che crea valore. In un servizio di assistenza, per esempio, la velocità della prima risposta conta nella misura in cui contribuisce a risolvere il problema. Se una maggiore rapidità genera risposte incomplete e più contatti successivi, la metrica locale descrive un progresso apparente.
Questo test richiede un confronto con il process owner e con chi ne riceve l’output. Il caso d’uso va formulato attraverso il risultato da migliorare, accompagnato da una misura osservabile. Questa impostazione consente anche di distinguere i passaggi davvero decisivi da quelli ereditati nel tempo e ormai privi di una funzione utile.
Verificare il vincolo che ha creato la procedura
Il Constraint Test ricostruisce la ragione per cui il processo è organizzato in un certo modo. Alcuni passaggi esistono perché le persone potevano esaminare soltanto un numero limitato di casi, perché i dati erano dispersi o perché una valutazione richiedeva molto tempo. L’AI può rimuovere uno di questi vincoli e rendere possibile un flusso differente.
Altri passaggi derivano da obblighi normativi, separazione dei compiti, sicurezza o necessità di responsabilità formale. In questi casi la tecnologia modifica gli strumenti, mentre il vincolo continua a operare. La mappatura evita di digitalizzare una sequenza obsoleta e, allo stesso tempo, impedisce di eliminare controlli che conservano una funzione essenziale.
Costruire un processo che impari
Il Compounding Test valuta se ogni esecuzione produce informazioni capaci di migliorare quelle successive. Correzioni umane, motivi di escalation, errori ricorrenti e variazioni dell’esito possono alimentare dati di feedback, nuove regole o un aggiornamento dei modelli. Il beneficio si accumula quando questa conoscenza entra stabilmente nel sistema.
L’HBR collega così il ridisegno alla capacità di apprendimento organizzativo. Un progetto isolato consegna una funzionalità; un processo progettato per apprendere crea un circuito tra operatività, controllo e miglioramento. Per l’IT ciò comporta la tracciabilità delle decisioni e la disponibilità dei dati necessari a capire dove il flusso perde efficacia.
Seconda decisione: assegnare il livello di autonomia fra persone e sistemi
Una volta scelto il processo, occorre definire chi possiede il potere decisionale in ogni passaggio. Shunko e Netessine sintetizzano le possibilità nel framework delle 4A: Assist, Approve, Audit e Automate. Le quattro modalità descrivono livelli diversi di autonomia e di controllo umano.
- Nella modalità Assist, l’AI formula un suggerimento e la persona decide. È adatta alle situazioni in cui contesto, esperienza e responsabilità umana hanno un peso elevato.
- Con Approve, il sistema prepara l’azione o l’output e l’essere umano ne autorizza l’esecuzione. Il controllo resta sistematico, mentre una parte rilevante del lavoro preparatorio viene automatizzata.
- Audit assegna alla macchina l’esecuzione e prevede controlli a campione o successivi. Questa configurazione richiede registri affidabili, criteri di campionamento e capacità di correzione.
- Automate consente invece al sistema di agire autonomamente entro confini definiti. Soglie, permessi, monitoraggio e meccanismi di arresto diventano parte del disegno operativo.
La reversibilità e la gravità dell’errore guidano la scelta. Una decisione dal basso impatto, facilmente annullabile e sostenuta da un’elevata confidenza può ricevere maggiore autonomia. Un esito capace di incidere su diritti, denaro, sicurezza, reputazione o relazione con il cliente richiede un presidio umano più forte. Lo stesso processo può combinare più modalità: automazione dei casi ordinari, approvazione per determinate soglie e assistenza nelle situazioni ad alta complessità.
Per il CIO, il framework offre un linguaggio comune con business, risk management, compliance e funzioni legali. L’architettura applicativa deve rendere effettiva la distribuzione dell’autorità attraverso ruoli, permessi, registrazione delle decisioni ed escalation. Una dichiarazione generale sulla supervisione umana acquista valore soltanto quando viene tradotta in punti di controllo verificabili.
Terza decisione: progettare le eccezioni prima del percorso standard
I progetti partono spesso dal cosiddetto happy path, la sequenza in cui ogni informazione è disponibile e ciascun passaggio produce l’esito previsto. L’Harvard Business Review sposta la progettazione verso la realtà operativa, dove incertezza e ambiguità sono componenti ordinarie del lavoro.
Il sistema deve anzitutto riconoscere quando la propria risposta è poco affidabile. Questa capacità richiede segnali misurabili: confidenza inferiore a una soglia, dati obbligatori mancanti, conflitto tra fonti o richiesta fuori dal perimetro autorizzato. Il riconoscimento deve poi attivare un percorso preciso, con un destinatario competente e tempi compatibili con il servizio.
L’escalation ha bisogno di un owner. In assenza di una responsabilità assegnata, i casi anomali si accumulano in code parallele e il beneficio ottenuto sul flusso ordinario viene assorbito dal lavoro manuale. Anche la possibilità di annullare un’azione o correggerne gli effetti deve essere prevista nel processo, soprattutto quando l’AI interagisce con sistemi transazionali.
Infine, ogni eccezione può diventare una fonte di apprendimento. La classificazione delle cause consente di distinguere un problema nei dati, un limite del modello, una regola incompleta o un caso realmente nuovo. La gestione delle anomalie diventa così parte del prodotto digitale, con requisiti, responsabilità e metriche propri.
Dalle metriche tecniche al valore aziendale
Il ridisegno richiede una catena di misurazione che colleghi la prestazione del modello al risultato di business. Accuratezza, latenza e costo per inferenza restano necessari per governare la componente tecnica. A questi indicatori vanno affiancati adozione, percentuale di casi gestiti, tasso di escalation, qualità dell’output, rilavorazioni, durata complessiva del ciclo e impatto economico.
Il tema coincide con il divario rilevato da McKinsey QuantumBlack nell’analisi From promise to impact: How companies can measure—and realize—the full value of AI. Quasi otto organizzazioni su dieci impiegano AI generativa in almeno una funzione, ma il 60% degli intervistati dichiara ancora di non vedere un impatto sull’Ebit a livello aziendale. McKinsey collega il superamento della fase pilota alla definizione iniziale del valore, alla misurazione incorporata nel rollout e a verifiche periodiche che consentano di scalare soltanto i casi sostenuti da risultati dimostrabili.
L’HBR arriva allo stesso nodo attraverso il process design. Una maggiore produttività in un singolo punto ha rilievo se migliora l’outcome finale e se il beneficio sopravvive ai costi di integrazione, supervisione, gestione delle eccezioni e correzione. Il cruscotto del progetto deve seguire l’intero flusso e rendere visibile l’eventuale trasferimento di costi o problemi da una funzione all’altra.
Questa impostazione cambia anche la valutazione del pilot. La prova tecnica verifica se l’AI sa svolgere un compito; la prova operativa osserva il comportamento del processo in presenza di volumi reali, anomalie e passaggi tra unità diverse; la verifica economica stabilisce se il risultato produce un valore superiore al costo totale. Le tre dimensioni devono convergere prima della diffusione su larga scala.
Il mandato operativo per le direzioni IT
L’analisi dell’Harvard Business Review porta a una domanda di ammissione per ogni iniziativa. Prima dell’approvazione, il team dovrebbe saper indicare quale risultato aziendale intende migliorare, quale processo end-to-end verrà riprogettato, quale ruolo avrà l’AI, quali decisioni resteranno sotto autorità umana, come saranno trattate le eccezioni e con quali metriche verrà misurato il successo.
Questa formulazione assegna al CIO una responsabilità che attraversa tecnologia e organizzazione. La funzione IT deve collegare dati, applicazioni e modelli, ma anche rendere attuabili le regole concordate con il business. Soglie di confidenza, diritti di approvazione, audit trail, rollback e feedback continuo diventano requisiti del workflow, al pari di prestazioni e disponibilità.
Il portafoglio dei casi d’uso può essere riletto con lo stesso criterio. I progetti che accelerano una singola attività e lasciano invariati outcome, vincoli e responsabilità promettono vantaggi circoscritti. Quelli che ridisegnano il flusso completo, assegnano l’autorità e incorporano la gestione dell’incertezza hanno le condizioni per produrre un impatto misurabile e duraturo.
Partecipa alla community