I risultati dei progetti AI rilevati da IDC finiscono sotto la lente dei CIO
Una ricerca IDC ha acceso un dibattito su Google News riguardo al fallimento dei progetti AI, con un titolo che afferma che il 45% dei progetti non produce risultati.
Le prove alla base richiedono una lettura più attenta. Una ricerca collegata a IDC afferma che, in media, solo il 45% delle iniziative AI produce risultati misurabili. A seconda di come le organizzazioni definiscono il successo, il dato implica un divario di valore più ampio di quanto suggerisca il titolo.
La distinzione è importante perché i CIO non vengono più giudicati in base al numero di progetti pilota AI avviati. I consigli di amministrazione ora si aspettano ritorni misurabili, implementazioni sicure e una governance capace di controllare gli agenti autonomi dopo il loro ingresso in produzione.
Questo è il vero conflitto dietro il titolo. I leader aziendali vogliono sistemi AI in grado di svolgere più lavoro con maggiore autonomia. Eppure, la stessa autonomia rende più difficili da contenere costi, decisioni, autorizzazioni e fallimenti.
IDC sta quindi descrivendo più di un altro deludente ciclo tecnologico. Sta documentando un trasferimento di responsabilità dai team AI sperimentali ai CIO, che devono difendere risultati aziendali e rischi operativi.
Cosa afferma realmente il dato IDC su Google News
Il dato riportato del 45% misura le iniziative che producono risultati misurabili, non un tasso universale di fallimento per ogni progetto AI aziendale.
Il titolo originale su Google News presenta il 45% dei progetti AI come incapace di fornire risultati. Tuttavia, il materiale di supporto collegato a IDC presenta la statistica in modo diverso.
Un'analisi Fujitsu cita il Technology Investment and Innovation Monitor di IDC del settembre 2025. Afferma che, a livello globale, il 45% delle iniziative AI raggiunge in media risultati misurabili.
Secondo la citazione di Fujitsu, la ricerca ha coinvolto 894 rispondenti. Ha inoltre rilevato che solo l'11% delle organizzazioni ha segnalato successo in oltre tre quarti dei propri progetti AI.
Queste misurazioni non dimostrano che esattamente il 45% sia fallito. Mostrano che il 45% ha prodotto risultati misurabili, lasciando il 55% senza un risultato dimostrato secondo l'approccio di misurazione del sondaggio.
Questo divario può includere diverse situazioni. Un progetto potrebbe essere ancora in fase di test, raggiungere la produzione senza valore misurabile, non centrare l'obiettivo iniziale o non disporre di dati sufficienti per una valutazione.
Si tratta di esiti diversi. Riunirli in un unico tasso di fallimento crea un titolo più efficace, ma un quadro meno preciso delle performance aziendali.
Le prove disponibili non dimostrano inoltre che i modelli AI sottostanti abbiano causato ogni risultato debole. Adozione aziendale, progettazione dei flussi di lavoro, qualità dei dati, costi operativi e metriche poco chiare possono ciascuno impedire la realizzazione del valore.
Questa distinzione separa il fallimento tecnico da quello organizzativo. Un modello può generare output accettabili mentre il progetto che lo circonda manca comunque il proprio obiettivo aziendale.
Un assistente interno, per esempio, potrebbe rispondere accuratamente alle domande dei dipendenti. Fallisce comunque sul piano commerciale se i lavoratori lo evitano, le risposte arrivano troppo lentamente o i costi di supporto superano i risparmi.
Anche un modello di previsione può funzionare bene in test controllati. Offre poco valore se i manager continuano a prendere decisioni attraverso un vecchio processo che ignora le sue raccomandazioni.
La ricerca più ampia di IDC supporta questa interpretazione. L'azienda afferma che le organizzazioni faticano a collegare la sperimentazione a risultati aziendali misurabili, soprattutto quando non sono mai state definite metriche di riferimento.
Ecco perché il titolo merita attenzione senza essere liquidato. La percentuale precisa resta dipendente dalle definizioni, ma il problema di valore sottostante è ben documentato.
Altre ricerche indicano la stessa direzione. L'indagine 2026 di CIO.com ha rilevato che solo il 19% dei rispondenti ha dichiarato che le proprie iniziative AI hanno raggiunto o superato gli obiettivi aziendali.
La ricerca State of the CIO ha coinvolto 662 leader IT e 249 utenti aziendali. Ha rilevato che il 18% ha dichiarato che meno di un terzo dei propri casi d'uso soddisfaceva le aspettative.
Gli studi usano campioni e definizioni diversi, quindi le loro percentuali non dovrebbero essere trattate come confronti diretti. Insieme, mostrano che il valore aziendale misurabile resta poco comune.
La conclusione responsabile è più circoscritta dell'affermazione virale. Molte organizzazioni non riescono a dimostrare ritorni costanti dalla maggior parte delle iniziative AI, e i CIO devono ora spiegare il perché.
Questa conclusione è abbastanza seria senza forzare il dato.
La sperimentazione AI lascia il posto a un mandato sul ROI
Il cambiamento centrale non è un calo dell'interesse per l'AI. È la fine del finanziamento di esperimenti privi di proprietari definiti, parametri di riferimento e risultati aziendali.
Gli investimenti aziendali nell'AI continuano anche se i ritorni restano difficili da dimostrare. Questa apparente contraddizione riflette la pressione competitiva piuttosto che la fiducia in ogni singolo progetto.
I consigli di amministrazione temono che ridurre gli investimenti lasci indietro le loro aziende. Vogliono inoltre che i CIO dimostrino come la spesa esistente migliori ricavi, costi, servizio clienti, resilienza o velocità decisionale.
Questo crea un percorso più stretto per i leader tecnologici. Devono mantenere lo slancio dell'adozione, chiudendo al contempo i progetti che non riescono a giustificare il proprio onere operativo.
IDC riporta che il 42% delle organizzazioni trova difficile o impossibile valutare il ROI degli investimenti digitali e AI. L'azienda identifica parametri di riferimento incoerenti e una limitata visibilità a lungo termine come ostacoli principali.
Il suo framework sul ROI agentico sostiene che i sistemi agentici rendano questi problemi più difficili. Il loro valore e i loro costi cambiano con l'evoluzione di flussi di lavoro, modelli e schemi di utilizzo.
Il software tradizionale spesso supporta un business case relativamente stabile. Prima dell'implementazione, gli acquirenti stimano costi di implementazione, esigenze di licenza, utenti previsti e risparmi di processo.
L'AI agentica si comporta diversamente. Un agente è un software che può pianificare passaggi, usare strumenti e intraprendere azioni verso un obiettivo con un intervento umano limitato.
Il suo costo operativo può variare in base a chiamate al modello, dimensione del contesto, utilizzo degli strumenti, tentativi ripetuti e revisioni umane. Le sue prestazioni possono anche cambiare quando mutano le condizioni aziendali o i dati di origine.
Un progetto pilota di successo offre quindi prove incomplete. Il pilota potrebbe usare dati curati, un gruppo ridotto di utenti e un'ampia supervisione tecnica che i team di produzione non possono sostenere.
Una volta implementato su larga scala, lo stesso sistema affronta input incoerenti, restrizioni di accesso, casi poco comuni e dipendenti che lo usano in modi inattesi.
Il dirigente di TIAA Sastry Durvasula ha descritto questa tensione nel rapporto di CIO.com. Ha affermato che un progetto pilota di successo può comunque faticare a produrre un ROI reale una volta che le organizzazioni considerano i costi operativi.
Questi costi includono consumo di token, gestione del traffico, manutenzione delle integrazioni, valutazioni, revisioni di sicurezza e supporto. Raramente compaiono in una dimostrazione iniziale.
Il nuovo mandato dei CIO inizia definendo il valore prima di costruire. Un progetto necessita di un parametro di riferimento misurabile che mostri come funziona il processo senza AI.
Ha inoltre bisogno di un responsabile aziendale che benefici del risultato. I team tecnici non possono certificare autonomamente il valore aziendale quando un altro reparto controlla adozione e modifiche ai flussi di lavoro.
CIO.com ha rilevato che l'83% dei leader IT intervistati disponeva di strutture AI interfunzionali o prevedeva di implementarle nel corso dell'anno. Tuttavia, approvazione e misurazione formali restavano meno mature.
Solo il 53% disponeva di un processo ufficiale di approvazione dei progetti AI. Un altro 28% prevedeva di introdurne uno entro i successivi 12 mesi.
Metriche formali esistevano nel 47% delle organizzazioni rispondenti, mentre il 34% prevedeva di definirle. Questo divario aiuta a spiegare perché implementazioni e ritorni misurabili spesso divergono.
Le organizzazioni non possono dimostrare un miglioramento se non hanno mai registrato il costo del processo originale, il tasso di errore, il tempo di completamento o il risultato per il cliente.
Il risultato è un ribaltamento della responsabilità. I precedenti programmi AI premiavano il volume dei progetti pilota e la sperimentazione visibile. La prossima fase premia una selezione disciplinata e un valore ripetibile.
Questo cambiamento modifica anche le conversazioni con i fornitori. Le affermazioni sulla qualità dei modelli contano meno quando un acquirente non riesce a collegare quella qualità a un risultato operativo.
I CIO hanno sempre più bisogno di prove sull'intero flusso di lavoro. Devono misurare se i dipendenti usano il sistema, se la qualità dell'output resta stabile e se i costi rimangono entro i limiti.
Hanno inoltre bisogno di una regola di interruzione. I progetti che non raggiungono ripetutamente soglie di adozione, qualità o performance finanziaria dovrebbero perdere i finanziamenti prima di diventare infrastrutture permanenti.
Questa pratica non rappresenta ostilità verso l'AI. Tratta la spesa per l'AI con la stessa disciplina applicata ad altri investimenti strategici.
Il conflitto principale è tra promessa dell'AI e realtà operativa
I progetti AI aziendali spesso falliscono al confine tra una dimostrazione convincente e l'ambiente complesso in cui si svolge il lavoro reale.
Il principale avversario in questa storia non è un fornitore AI contro un altro. È la promessa di un rapido valore dall'AI contro la realtà delle operazioni aziendali.
Le dimostrazioni di solito isolano un compito ristretto. I sistemi di produzione devono gestire autorizzazioni, record obsoleti, policy in conflitto, dati incompleti e diverse applicazioni dipendenti.
Ogni dipendenza aggiuntiva crea un ulteriore percorso di fallimento. Il modello può fornire una risposta ragionevole mentre uno strumento non disponibile, un record non aggiornato o un'autorizzazione errata impediscono l'azione richiesta.
La qualità dei dati presenta un problema simile. I sistemi AI possono riassumere, classificare o recuperare informazioni, ma non possono correggere ogni contraddizione nascosta nei repository aziendali.
Un agente di supporto può imbattersi in tre versioni della stessa politica di rimborso. Senza una fonte autorevole e una cronologia delle versioni, può selezionare con sicurezza la regola sbagliata.
Il lavoro della conoscenza crea un'altra sfida di misurazione. Una redazione più rapida non crea automaticamente valore finanziario se i dipendenti impiegano il tempo risparmiato a revisionare output inaffidabili.
Il progetto deve misurare l'intero processo. Ciò include preparazione, generazione, revisione, correzione, escalation ed eventuali errori a valle.
È qui che un approccio di knowledge blending può diventare rilevante. Combinare fonti approvate con il contesto di lavoro può ridurre le lacune nel recupero delle informazioni, ma la governance continua a determinare quale materiale sia considerato affidabile.
Anche l'adozione dei flussi di lavoro conta. I dipendenti spesso aggirano un nuovo sistema quando aggiunge passaggi, richiede interfacce non familiari o fallisce nei casi poco comuni.
Questo comportamento può rimanere invisibile durante un progetto pilota sponsorizzato. I partecipanti ricevono formazione e supporto, mentre gli utenti ordinari affrontano priorità concorrenti.
Un'adozione di successo richiede quindi la riprogettazione del processo, non il semplice accesso a un modello. I team devono decidere quali attività cambiano, quali approvazioni rimangono e chi gestisce le eccezioni.
La differenza tra assistenza e autonomia alza ulteriormente la posta. Un assistente di scrittura propone testo affinché una persona lo riveda. Un agente può creare ticket, modificare record, contattare clienti o attivare transazioni.
Un suggerimento inesatto costa tempo di revisione. Un'azione autonoma inesatta può modificare sistemi reali prima che una persona se ne accorga.
La ricerca di IDC sostiene che le organizzazioni non dovrebbero applicare la tecnologia agentica a ogni attività. L'automazione deterministica resta più adatta a processi stabili con regole chiare.
I sistemi agentici hanno più senso quando il lavoro richiede più passaggi, contesto variabile, giudizio e orchestrazione tra strumenti. Anche in quel caso, l'autonomia deve generare valore sufficiente a giustificare il rischio aggiuntivo.
Questa disciplina nella scelta dei casi d’uso aiuta a spiegare il dibattito di IDC sui fallimenti dei progetti AI. Alcuni progetti deboli iniziano con una tecnologia alla ricerca di un problema.
I team scelgono prima un modello o una piattaforma per agenti. Poi cercano un flusso di lavoro che possa giustificare l’acquisto.
Questa sequenza produce spesso prototipi interessanti ma di limitata rilevanza operativa. Nessuna business unit si assume la responsabilità del risultato perché il progetto non è nato da un’esigenza misurata.
Una sequenza più solida parte da un flusso di lavoro costoso o soggetto a vincoli. I team ne documentano la base di riferimento, individuano le decisioni coinvolte e verificano se l’AI migliora il risultato complessivo.
Il confronto dovrebbe includere software convenzionale e modifiche dei processi. L’AI dovrebbe prevalere perché si adatta al problema, non perché i dirigenti hanno richiesto un’iniziativa AI.
Le organizzazioni devono inoltre distinguere tra produttività e valore effettivamente catturato. Far risparmiare a un dipendente qualche minuto non ha automaticamente un significato finanziario.
L’azienda cattura valore solo quando quel tempo migliora l’output, riduce i tempi di risposta ai clienti, aumenta la capacità o riduce una spesa identificata.
Anche l’esperienza dei dipendenti e la resilienza possono essere importanti. Tuttavia, i leader devono definire come misurare tali benefici invece di trattarli come comode spiegazioni dopo il mancato raggiungimento degli obiettivi finanziari.
Per questo IDC propone una mappatura del valore più ampia. Il suo framework include fiducia dei clienti, resilienza, sostenibilità e orizzonti temporali accanto alle misure finanziarie convenzionali.
Questo modello più ampio non dovrebbe diventare una scusa per vaghe affermazioni di successo. Ogni dimensione necessita comunque di un responsabile, una base di riferimento, un metodo di misurazione e una data di revisione.
La realtà operativa è quindi meno drammatica di un collasso dei modelli, ma più difficile da correggere. Richiede coordinamento tra team tecnologici, finanziari, di sicurezza, legali e aziendali.
Nessun aggiornamento del modello può creare automaticamente tale coordinamento.
La governance dell’AI agentica trasforma la sicurezza in un vincolo aziendale
La governance dell’AI agentica determina se l’autonomia può scalare in sicurezza, perché gli agenti trasformano output incerti in azioni attraverso sistemi connessi.
La sicurezza ha sempre influenzato le decisioni tecnologiche aziendali. I sistemi agentici cambiano il problema combinando l’incertezza dei modelli con credenziali, strumenti, memoria e accesso operativo.
Un chatbot convenzionale di solito restituisce informazioni. Un agente può interpretare una richiesta, costruire un piano, richiamare applicazioni e continuare ad agire dopo aver ricevuto nuovi risultati.
Questa capacità amplia la superficie di attacco. Contenuti malevoli possono influenzare le istruzioni di un agente, mentre autorizzazioni eccessive possono trasformare una decisione errata in un incidente più grave.
Il prompt injection è un esempio. Un aggressore inserisce istruzioni nei contenuti letti dal modello, tentando di reindirizzare il sistema dal suo compito autorizzato.
Il pericolo aumenta quando un agente può inviare messaggi, modificare database, recuperare record riservati o eseguire codice. Una risposta fuorviante diventa solo uno dei possibili fallimenti.
IDC mette in guardia da cascate decisionali incontrollate, comportamenti opachi ed escalation frammentate. La sua analisi sulla governance descrive la governance come infrastruttura operativa anziché come una revisione finale di conformità.
La società prevede che fino al 20% delle organizzazioni Global 1000 potrebbe affrontare cause legali, sanzioni o licenziamenti di CIO entro il 2030. IDC collega questo rischio a gravi disservizi causati da una debole governance degli agenti AI.
Si tratta di una previsione, non di un tasso di fallimento osservato. Indica la portata della potenziale responsabilità, non un esito garantito.
IDC raccomanda tracciabilità, governance integrata e cicli di responsabilità definiti. Questi controlli aiutano i team a ricostruire le decisioni e a interrompere le azioni prima che superino i confini stabiliti.
Tracciabilità significa registrare dati, modello, istruzioni, chiamate agli strumenti e output coinvolti in una decisione autonoma. Senza tali registrazioni, i team non possono indagare sugli errori né difendere gli esiti.
La governance integrata riunisce sicurezza, dati, area legale, rischio e responsabilità aziendale lungo l’intero ciclo di vita del sistema. Un comitato che esamina solo il modello non può governare il flusso di lavoro completo.
I cicli di responsabilità definiscono quando una persona deve approvare, rivedere o interrompere un’azione. La soglia dovrebbe dipendere dalle possibili conseguenze, non solo dal livello di fiducia del modello.
Le azioni a basso rischio possono ricevere maggiore autonomia. Inviare un promemoria interno comporta conseguenze diverse rispetto all’approvazione di un pagamento o alla modifica dell’account di un cliente.
I controlli di identità sono altrettanto importanti. Ogni agente necessita di una propria identità, autorizzazioni, responsabile e finalità, anziché prendere in prestito credenziali senza restrizioni da uno sviluppatore o da un servizio condiviso.
Le autorizzazioni dovrebbero seguire il principio del privilegio minimo. Un agente riceve solo l’accesso necessario per il flusso di lavoro assegnato e nessuna autorità più ampia.
Le organizzazioni necessitano inoltre di un inventario affidabile. I team di sicurezza non possono proteggere gli agenti di cui non conoscono l’esistenza, soprattutto quando i reparti possono configurarli all’interno delle applicazioni aziendali.
L’inventario dovrebbe registrare responsabilità, sistemi connessi, dati approvati, fornitori di modelli, risultati delle valutazioni e controlli di emergenza.
Dopo il lancio diventa necessaria una valutazione continua. Il comportamento degli agenti può cambiare quando i modelli vengono aggiornati, i prompt evolvono, gli strumenti connessi cambiano o i dati aziendali sviluppano nuovi schemi.
IDC osserva che le prestazioni possono degradarsi con il mutare del contesto e l’accumularsi di casi limite. Questo rende un agente un servizio gestito continuativo anziché un’implementazione completata.
Sicurezza e ROI convergono quindi. Monitoraggio, valutazioni, controlli di accesso, risposta agli incidenti e revisione umana aggiungono tutti costi operativi.
Un business case che esclude tali controlli presenta un rendimento artificialmente favorevole. Rimuoverli per proteggere le previsioni trasferisce la pressione finanziaria nell’esposizione alla sicurezza.
Questo è il compromesso centrale che i CIO devono gestire. Una maggiore autonomia può aumentare velocità e capacità, ma accresce anche il costo delle garanzie.
La risposta non è una revisione illimitata di ogni azione. Ciò annullerebbe l’efficienza che giustificava l’agente.
Le organizzazioni hanno bisogno di un’autonomia basata sul rischio. Possono automatizzare azioni reversibili e osservabili, richiedendo al contempo l’approvazione umana per decisioni con conseguenze legali, finanziarie o di sicurezza.
La governance dell’AI agentica deve includere anche procedure di arresto. I team devono poter revocare le credenziali, fermare i flussi di lavoro, isolare la memoria e preservare le prove durante un incidente.
Senza queste capacità, un agente può rimanere operativo mentre diversi team discutono su chi ne sia responsabile. Si tratta di un fallimento del controllo organizzativo, anche se il modello si è comportato come progettato.
Ciò che i numeri non possono ancora dimostrare
Le statistiche disponibili mostrano un ampio problema di valore, ma non supportano un unico tasso universale di fallimento dei progetti AI.
L’impostazione delle notizie Google incoraggia una lettura binaria. Un progetto ha successo o fallisce, con una sola percentuale che riassume l’intero mercato.
Le implementazioni aziendali raramente rientrano in questo modello. Un progetto può raggiungere un benchmark tecnico, mancare un obiettivo di adozione, rimanere nel budget e non produrre comunque ricavi misurabili.
Un altro progetto può superare i costi inizialmente previsti creando però conoscenze o benefici per i clienti strategicamente importanti. Il fatto che sia considerato di successo dipende dal framework di valutazione.
Anche la formulazione delle indagini modifica i risultati. “Ha prodotto risultati misurabili” è diverso da “ha soddisfatto le aspettative”, “è entrato in produzione” o “ha generato un ritorno finanziario”.
Anche la selezione del campione conta. Un’indagine tra leader tecnologici può produrre risultati diversi da uno studio su utenti aziendali, team finanziari o singoli progetti.
Il denominatore crea un altro problema. Alcuni studi conteggiano ogni prototipo. Altri includono solo implementazioni in produzione o iniziative note ai dirigenti senior.
Anche gli orizzonti temporali differiscono. Un sistema AI potrebbe richiedere diversi trimestri di riprogettazione del flusso di lavoro e di adozione prima che emergano i benefici.
Dichiararlo un fallimento dopo un trimestre può essere prematuro. Continuare indefinitamente senza prove può sprecare ulteriore capitale.
Queste limitazioni non invalidano i risultati di IDC. Definiscono ciò che i lettori possono concludere responsabilmente da essi.
La conclusione più solida è che le imprese faticano a misurare e replicare il valore dell’AI. La conclusione più debole è che una percentuale fissa di tutti i progetti sia definitivamente fallita per lo stesso motivo.
La distinzione influenza anche la responsabilità. Se si attribuisce automaticamente la colpa al modello, le organizzazioni potrebbero sostituire i fornitori mantenendo al contempo i problemi di flusso di lavoro, dati e governance che hanno causato risultati deboli.
Se ogni problema viene attribuito alla preparazione organizzativa, i fornitori possono evitare la responsabilità per prodotti inaffidabili. Entrambe le narrazioni meritano attenzione critica.
La qualità del modello continua a essere importante. Allucinazioni, ragionamento incoerente, latenza, contesto limitato ed errori nell’uso degli strumenti possono rendere un’applicazione inadatta alla produzione.
Anche la progettazione del fornitore è importante. Gli acquirenti necessitano di log di audit utilizzabili, controlli delle autorizzazioni, avvisi sulle modifiche ai modelli, strumenti di valutazione e un comportamento del servizio prevedibile.
Le organizzazioni rimangono responsabili della selezione di casi d’uso appropriati e della configurazione sicura degli accessi. I fornitori rimangono responsabili di descrivere accuratamente capacità e limitazioni.
La discussione di IDC sui fallimenti dei progetti AI dovrebbe quindi produrre domande migliori, non un unico colpevole conveniente.
Quale base di riferimento il progetto intendeva migliorare? Quale responsabile aziendale ha accettato l’obiettivo? I costi di sicurezza e operativi erano inclusi prima dell’approvazione?
I dipendenti hanno usato il sistema quando è terminato il supporto al pilota? La qualità dell’output è rimasta accettabile nei casi non comuni e con dati in evoluzione?
I team potevano ricostruire le azioni di un agente dopo un errore? Potevano interrompere immediatamente il flusso di lavoro senza disabilitare sistemi non correlati?
Queste domande trasformano un titolo controverso in una revisione operativa. Sono anche più difficili a cui rispondere rispetto alla domanda se un pilota sia stato avviato nei tempi previsti.
Un confronto indipendente rafforza la necessità di cautela. Gartner ha riferito che il 45% delle organizzazioni ad alta maturità ha mantenuto operativi i progetti AI per almeno tre anni.
La sua indagine sulla maturità AI ha collegato la longevità a pratiche mature, ma la sola longevità non dimostra il valore aziendale.
Un progetto può rimanere operativo per ragioni strategiche o politiche. Un progetto può anche terminare dopo aver trasferito con successo la propria capacità in un’altra piattaforma.
Nessuna singola misura cattura l’intero risultato. Le organizzazioni necessitano di una visione di portafoglio che separi prestazioni tecniche, adozione, impatto finanziario, rischio e valore strategico.
Il portafoglio dovrebbe includere anche i progetti non riusciti. Nascondere i piloti abbandonati crea un quadro fuorviante e impedisce ai team di riconoscere cause ricorrenti.
Dovrebbe inoltre distinguere una cancellazione sana da un fallimento incontrollato. Terminare in anticipo un progetto debole può dimostrare una governance disciplinata anziché prestazioni scarse.
Una fonte di CIO.com ha descritto come salutare l’interruzione di circa un terzo dei progetti avviati. L’organizzazione ha utilizzato finanziamenti con gate di fase e checkpoint sui risultati per evitare che lavori deboli consumassero risorse permanenti.
Questo approccio ridefinisce il fallimento. Il progetto pericoloso non è sempre quello che si ferma. Può essere quello che continua senza prove perché nessuno si assume la responsabilità della decisione.
Tre segnali che i CIO dovrebbero osservare in seguito
Il prossimo test è se le organizzazioni sostituiranno il conteggio dei piloti con report sui risultati, autonomia controllata e prove che i dipendenti usano l’AI nei flussi di lavoro reali.
Il primo segnale è l’adozione di playbook formali sul valore dell’AI. IDC prevede che entro il 2027 al 60% dei CIO dell’Asia-Pacifico 500 verrà affidato il compito di crearli.
Un playbook del valore standardizza la selezione dei casi d’uso, le baseline, i modelli di costo, la responsabilità e le soglie di revisione. Consente ai dirigenti di confrontare i progetti sulla base di evidenze coerenti.
Questo segnale rafforzerebbe l’argomentazione di IDC se le organizzazioni iniziassero a chiudere i progetti privi di risultati misurabili. La indebolirebbe se la misurazione formale si espandesse senza migliorare le performance del portafoglio.
La metrica chiave non è il numero di playbook pubblicati. È la quota di iniziative in produzione con responsabili nominati, baseline, costi operativi completi e revisioni programmate dei risultati.
I consigli di amministrazione dovrebbero inoltre osservare come le organizzazioni rendicontano i benefici indiretti. La fiducia dei clienti, la resilienza e decisioni più rapide possono essere importanti, ma ciascuno richiede un metodo di misurazione osservabile.
Il secondo segnale è l’implementazione di controlli sugli agenti effettivamente applicabili. Le sole policy non possono governare software che agisce in modo continuo attraverso i sistemi aziendali.
I CIO dovrebbero monitorare quanti agenti dispongono di identità dedicate, autorizzazioni limitate, registri completi delle azioni, regole di escalation umana e procedure di arresto testate.
I team di sicurezza dovrebbero inoltre segnalare gli incidenti per gravità e causa principale. Un aumento del numero di incidenti può riflettere sia un peggioramento della sicurezza sia una maggiore visibilità su attività prima nascoste.
La tendenza più significativa è se gli incidenti gravi diminuiscono man mano che aumenta l’uso degli agenti. Le organizzazioni dovrebbero confrontare i tassi di incidente con le azioni degli agenti, i sistemi connessi e i livelli di rischio.
Le previsioni IDC per l’Asia-Pacifico indicano conseguenze gravi in caso di controlli inadeguati sugli agenti, incluse l’esposizione legale e la responsabilità dei dirigenti. Questa previsione diventa più credibile se le implementazioni autonome si espandono più rapidamente della supervisione tecnica.
Diventa meno credibile se le organizzazioni dimostrano che i controlli basati sul rischio scalano con l’utilizzo. Le evidenze dovrebbero includere risultati degli audit, tempi di contenimento, violazioni delle autorizzazioni e interventi umani riusciti.
Il terzo segnale è l’adozione in produzione collegata ai risultati dei flussi di lavoro. L’accuratezza dei progetti pilota e l’entusiasmo dei dipendenti non possono sostituire un utilizzo continuativo nelle operazioni quotidiane.
I CIO dovrebbero monitorare l’utilizzo attivo, i tassi di completamento, la frequenza delle eccezioni, il tempo di revisione e la percentuale di lavoro generato che raggiunge un risultato utile.
Dovrebbero inoltre misurare cosa accade quando il supporto dopo il rilascio diminuisce. Un sistema che dipende da interventi costanti dei suoi creatori non ha ancora raggiunto una produzione ripetibile.
Le unità aziendali devono segnalare se l’AI riduce i tempi di ciclo, aumenta la capacità, diminuisce gli errori o migliora i risultati per i clienti. I team finanziari dovrebbero verificare eventuali risparmi dichiarati.
Questo segnale rafforzerebbe la narrazione di google news se l’utilizzo crescesse mentre il valore misurabile rimanesse debole. Dimostrerebbe che la sola adozione non può risolvere il problema del ROI.
Indebolirebbe tale narrazione se i programmi maturi dimostrassero miglioramenti ripetibili in diversi flussi di lavoro dopo aver incluso tutti i costi di sicurezza e operativi.
Questi tre segnali sono collegati. Modelli di valore migliori selezionano casi d’uso più solidi, controlli più efficaci consentono un’autonomia sicura e l’adozione continuativa dei flussi di lavoro produce evidenze misurabili.
La rimozione di un elemento crea un risultato fragile. Un sistema redditizio privo di controlli comporta un’esposizione nascosta. Un sistema sicuro senza utenti non crea valore.
Un sistema popolare senza misurazioni di baseline produce un’attività impressionante ma rendimenti incerti.
I CIO dovrebbero resistere alla pressione di rispondere al dibattito con un’altra percentuale generica. I loro portafogli offrono evidenze più utili di un titolo aggregato.
Possono iniziare selezionando un piccolo numero di flussi di lavoro rilevanti e documentandone le prestazioni attuali. Ogni progetto dovrebbe ricevere un responsabile aziendale, un responsabile tecnico, una classificazione del rischio e un calendario di revisione.
I team dovrebbero calcolare i costi oltre lo sviluppo iniziale. Tali costi includono l’utilizzo dei modelli, la manutenzione delle integrazioni, il monitoraggio, le valutazioni, la sicurezza, il supporto e la revisione umana.
Dovrebbero definire gli esiti inaccettabili prima di concedere autonomia. Tali limiti possono riguardare l’esposizione dei dati, i limiti finanziari, l’impatto sui clienti e le azioni sugli strumenti vietate.
Infine, dovrebbero pubblicare i risultati interni, incluse le cancellazioni. Una rendicontazione trasparente rende più difficile che progetti deboli sopravvivano soltanto grazie all’entusiasmo.
La contestata affermazione del 45% è quindi utile come avvertimento, non come valutazione universale. Mostra quanto facilmente una misurazione imprecisa possa trasformarsi in un titolo sicuro di sé sull’AI.
La risposta migliore non è discutere di un’unica percentuale di google news. È pretendere prove che ogni sistema di AI crei valore dopo aver considerato tutti i suoi costi e rischi.
Quali progetti supererebbero questo test nella vostra organizzazione e quali restano finanziati perché nessuno ha definito cosa significhi il successo?
