Perché un’azienda che investe nell’AI, dispone delle competenze tecniche e avvia decine di sperimentazioni continua a faticare nel portarle in produzione? I motivi sono diversi: dati non coerenti, competenze insufficienti, resistenze interne.
Una ricerca pubblicata su Harvard Business Review, propone però di guardare qualche piano più in alto nell’organigramma, perché un altro possibile freno sono le decisioni che il top management preferisce non prendere. Già, dopo tre anni di lavoro i ricercatori della Cambridge Judge Business School hanno individuato un meccanismo che definiscono AI leadership drift: la deriva della leadership che si produce quando il management comprende le implicazioni dell’AI, ma non riesce a tradurle in decisioni. In altre parole: si parla sì di “change management”, ma il management a dover cambiare è quello top.
Il fenomeno emerge proprio mentre l’AI passa dai proof of concept all’integrazione nei processi. Ed è quando un sistema funziona che iniziano le decisioni più difficili: cosa fare quando funziona?
Il leadership drift: quando il management evita la decisione
I ricercatori della Cambridge Judge Business School hanno osservato una dinamica sottile. I top manager, quando intervistati individualmente, riconoscevano che l’AI avrebbe potuto richiedere modifiche profonde al business: pricing, composizione degli organici, servizi offerti, organizzazione, modelli. Nel confronto collettivo, però, quelle posizioni tendevano a essere abbandonate. Al loro posto emergevano interpretazioni più rassicuranti, più sfumate, più ambigue, capaci di rinviare le decisioni più scomode.
Il leadership drift non coincide quindi con l’opposizione dichiarata all’AI. Un executive team può essere favorevole agli investimenti, approvare piattaforme e progetti, finanziare programmi di formazione e – contemporaneamente – evitare di decidere che cosa debba cambiare nell’impresa.
Se l’AI riduce il tempo necessario per svolgere un’attività, l’azienda deve decidere come utilizzare la capacità liberata. Se automatizza una parte del customer service, deve stabilire se ridurre il dimensionamento del servizio, aumentare i volumi o migliorare la qualità dell’assistenza. Se rende più produttiva una funzione professionale, deve interrogarsi sul pricing, sulla composizione delle competenze e sul modello di offerta.
Sono decisioni che possono creare vincitori e perdenti tra funzioni, livelli gerarchici e linee di business.
Il risultato è una proliferazione di progetti, ciascuno con un proprio sponsor e una propria metrica, ma senza una decisione chiara sul modello operativo complessivo. L’azienda sperimenta molto, ma modifica poco.
Il leadership drift nasce proprio qui: il management riconosce individualmente la portata del cambiamento, ma nel momento in cui deve assumere una posizione collettiva tende a ricondurre l’AI a un progetto tecnologico, a un miglioramento incrementale o a una sperimentazione ancora da valutare. La decisione è quella di rinviare le decisioni, insomma.
Come uscirne? La ricerca HBR individua quattro possibili contromisure:
- portare nelle discussioni i dati dell’impresa anziché affidarsi prevalentemente a statistiche di mercato;
- osservare le risposte di aziende realmente comparabili;
- associare ogni iniziativa AI a una domanda strategica e a una data di revisione;
- attribuire esplicitamente a qualcuno la responsabilità di mantenere nell’agenda del management le questioni difficili.
Queste indicazioni sono importanti perché il leadership drift tende a prodursi proprio quando il tema viene discusso in modo astratto. Parlare di “adozione dell’AI” o di “innovazione” consente a tutti di dichiararsi favorevoli. Chiedere invece quali attività verranno eliminate, quali ruoli cambieranno, come verranno misurati i risultati e chi sarà responsabile degli errori rende inevitabile il confronto.
I dati degli Osservatori: l’adozione cresce, ma il valore resta da costruire
Secondo l’Osservatorio Artificial Intelligence del Politecnico di Milano, nel 2025 il mercato italiano dell’intelligenza artificiale ha raggiunto 1,8 miliardi di euro, con una crescita del 50% rispetto all’anno precedente. Le grandi imprese sono il principale motore dell’adozione, mentre nelle PMI l’utilizzo resta più limitato.
La crescita del mercato misura la velocità degli investimenti, non la profondità della trasformazione organizzativa.
È proprio su questa seconda dimensione che la lente del leadership drift diventa utile: permette di chiedersi se alla diffusione degli strumenti corrispondano decisioni altrettanto rapide su processi, responsabilità e modelli operativi. La tecnologia avanza, mentre le decisioni organizzative restano sospese. Il rischio è di parlare sempre più di “output” e non di “outcome”.
Le conseguenze per i CIO
Per il CIO, il leadership drift produce una situazione paradossale: la responsabilità tecnologica cresce, mentre il perimetro delle decisioni aziendali resta incerto.
Il CIO deve garantire integrazione, sicurezza, compliance, qualità dei dati, controllo dei costi e affidabilità dei sistemi. Tutto chiaro, peccato che le decisioni importanti non siano tecnologiche: riguardano il ridisegno dei processi, la distribuzione delle responsabilità, il rapporto tra automazione e lavoro umano, il pricing e l’organizzazione.
Se il vertice non prende queste decisioni, il rischio è che l’IT venga chiamato a governare conseguenze che non ha contribuito a definire o – peggio ancora – basate su decisioni mai prese.
La governance, per esempio, non può essere delegata interamente all’IT. Il CIO può stabilire standard di sicurezza, procedure di accesso, monitoraggio dei modelli, logging, architetture e controlli. Non può decidere da solo quanta autonomia attribuire a un agente nel processo commerciale, quali attività ridisegnare dopo un incremento di produttività o quale rischio reputazionale l’azienda sia disposta ad accettare in cambio di una maggiore automazione.
Sono decisioni che richiedono competenze tecnologiche, ma hanno natura aziendale.
Per questo il CIO deve usare la governance non soltanto per controllare i sistemi, ma anche per rendere esplicite le decisioni che il management tende a rimandare. La governance diventa così uno strumento per collegare tecnologia, responsabilità e risultati di business.
Cinque verifiche per CIO e leadership team
Contrastare il leadership drift non significa ovviamente che il CIO debba assumersi una responsabilità che appartiene al CEO. Significa rendere più difficile che le ambiguità strategiche vengano nascoste dietro problemi tecnici.
Chi è responsabile del risultato?
Per ogni iniziativa significativa deve esistere un responsabile del risultato di business, oltre al responsabile tecnologico.
Il CIO può essere accountable per l’implementazione della piattaforma, la sicurezza o l’integrazione con i sistemi esistenti. Ma qualcuno nel business deve rispondere dell’effetto prodotto: riduzione dei costi, aumento dei ricavi, miglioramento della qualità o riduzione dei tempi.
Se il progetto ha soltanto uno sponsor IT, probabilmente non è ancora una vera iniziativa di trasformazione.
Come viene misurato il valore?
Numero di utenti, licenze attivate, prompt utilizzati e casi d’uso descrivono l’adozione. Non dimostrano il valore.
Per decidere se scalare servono indicatori collegati a costi, ricavi, qualità, rischio, tempi di processo o capitale impiegato. Il business case deve chiarire quale risultato ci si aspetta, entro quando e rispetto a quale baseline.
Uno dei classici modi per dimostrare il ritorno di un progetto IT è: “quante persone usano lo strumento?”. In realtà dovrebbe essere “che cosa è cambiato nel modo di lavorare? Che outcome abbiamo ottenuto?”.
Che cosa succede alla capacità liberata?
Un progetto AI che promette un forte incremento di produttività deve spiegare come verrà utilizzata la capacità liberata.
Le alternative sono diverse: ridurre i tempi di risposta, aumentare i volumi, migliorare il servizio, spostare le persone verso attività a maggiore valore, finanziare nuove iniziative.
Lasciare questa domanda senza risposta significa rinviare proprio la decisione più importante. L’AI può aumentare la produttività, ma il valore economico emerge soltanto quando l’organizzazione decide come trasformare quella produttività in un risultato.
Quando verrà presa la decisione di scalare o fermarsi?
Ogni iniziativa dovrebbe avere una data di revisione e criteri espliciti per decidere se procedere, modificare l’approccio o interrompere il progetto.
Un pilot permanente smette di essere un esperimento e diventa un modo costoso per rinviare una scelta. La revisione deve riguardare non soltanto le prestazioni tecniche del modello, ma anche l’impatto sul processo, sui costi, sulle persone e sul rischio.
Il CIO può contribuire definendo le metriche e rendendo disponibili i dati. La decisione finale, però, deve appartenere al leadership team (dove il CIO dovrebbe entrare e dire la sua).
Chi ha il compito di porre domande scomode?
Se nessuno ha il compito esplicito di contestare le assunzioni condivise dal management, il consenso può diventare un indicatore molto debole della qualità della strategia.
Ogni iniziativa dovrebbe essere sottoposta a domande come: quale processo stiamo davvero cambiando? Quale attività non sarà più necessaria? Quale responsabilità verrà spostata? Che cosa succede se il modello sbaglia? Quale investimento siamo disposti a interrompere per finanziare questo progetto?
Se il leadership team evita di rispondere a queste domande l’azienda può continuare a fare AI senza diventare molto diversa da prima. Non basta una “pennellata” di AI per cambiare i processi.
Per il CIO, la verifica più utile da portare al prossimo steering committee non riguarda quanti progetti siano entrati in produzione. Riguarda le decisioni che quei progetti hanno costretto l’azienda a prendere.
Se la risposta è “nessuna”, il problema potrebbe trovarsi parecchio più in alto dello stack tecnologico.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Vincenzo Zaglio
Source link
