Il sondaggio AI di Google Cloud rileva che la modernizzazione è frenata dal software esistente

Google Cloud ha pubblicato il 9 novembre risultati secondo cui il 49% dei decisori intervistati ha collegato il software on-premises a iniziative tecnologiche ritardate o ridimensionate. Tali iniziative includevano l'AI, sebbene il dato non isoli i progetti AI. Il sondaggio AI di Google Cloud attribuisce un valore concreto a un conflitto noto nelle imprese: mantenere le operazioni esistenti compete con la creazione di nuove capacità.

La ricerca, condotta con Hypothesis Group, ha intervistato 1.250 decisori IT e aziendali di imprese negli Stati Uniti. Google usa i risultati per sostenere una maggiore scelta architetturale e una minore dipendenza dai fornitori consolidati. La sua preoccupazione centrale è comprensibile: gli agenti AI, software in grado di perseguire compiti attraverso azioni successive, ereditano i limiti dei sistemi a cui accedono.

Microsoft offre un confronto utile. La sua ricerca sottolinea la preparazione organizzativa insieme all'adozione da parte dei dipendenti, invece di considerare la sostituzione dell'infrastruttura come la risposta principale. La tensione che attraversa entrambe le analisi riguarda l'espansione dell'accesso all'AI e la preparazione dei processi aziendali a utilizzarla. Per i leader tecnologici, ciò sposta la discussione verso integrazione, responsabilità operativa e la verifica che la nuova spesa liberi davvero una capacità ingegneristica limitata.

Cosa ha effettivamente misurato il sondaggio AI di Google Cloud

Il sondaggio misura i vincoli dichiarati dai decisori, anziché dimostrare che una particolare strategia di modernizzazione li elimini.

Jeanette Manfra, responsabile del rischio e della conformità di Google Cloud, ha presentato i risultati in un annuncio sul sondaggio sul software legacy. Il rapporto allegato è datato ottobre 2026, mentre la metodologia colloca il lavoro sul campo in agosto. La pubblicazione fornisce quindi un resoconto recente di esperienze raccolte in precedenza, piuttosto che una misurazione in tempo reale delle implementazioni di novembre.

Una definizione importante influenza l'interpretazione. Lo studio classifica come legacy il software aziendale ospitato localmente o on-premises, contrapponendolo al software ospitato e gestito nel cloud. Questa definizione riguarda le modalità di implementazione e gestione. I lettori dovrebbero evitare di presumere che ogni sistema incluso sia obsoleto, non supportato o tecnicamente inadatto all'AI.

La distinzione è importante perché ubicazione e condizione rispondono a domande diverse. Un'applicazione gestita localmente può avere interfacce chiare e una manutenzione rigorosa. Un'applicazione cloud può comunque contenere record confusi, autorizzazioni incoerenti o regole aziendali strettamente accoppiate. Nessuna delle due osservazioni contraddice le esperienze degli intervistati, ma entrambe limitano le conclusioni che gli acquirenti dovrebbero trarre.

Il 49% riportato raggruppa inoltre diversi esiti: ritardi, riduzioni di portata, sospensioni e cancellazioni. Questi rappresentano diversi gradi di interruzione. Un adeguamento temporaneo della pianificazione non comporta le stesse conseguenze aziendali dell'abbandono di un progetto. Allo stesso modo, l'inclusione di altre iniziative tecnologiche significa che il risultato non può diventare un tasso di cancellazione dei progetti AI.

Questa precisazione lascia intatto un dato significativo. Gli intervistati associano le loro configurazioni software esistenti a ostacoli al cambiamento pianificato. Per gli acquirenti aziendali, questa è un'indicazione che l'ambiente circostante merita attenzione insieme al prodotto AI in fase di valutazione.

Tuttavia, una risposta a un sondaggio non può stabilire l'intera catena delle responsabilità. Un'iniziativa bloccata potrebbe coinvolgere limiti applicativi, restrizioni negli acquisti, competenze mancanti, priorità concorrenti o un business case poco chiaro. Diverse cause possono coesistere nello stesso progetto.

Di conseguenza, il sondaggio AI di Google Cloud è più utile come diagnosi dell'attrito organizzativo percepito. Offre ai leader una ragione per esaminare le proprie dipendenze. Non dice loro quale applicazione sostituire, quale fornitore scegliere o se la migrazione debba precedere una specifica implementazione.

Questa differenza separa un utile segnale di ricerca da una conclusione d'acquisto eccessivamente ampia. La domanda successiva è chi debba risolvere l'attrito e quale lavoro farebbe altrimenti.

La pressione della manutenzione ricade sui team che devono fornire AI

La pressione immediata ricade sui team responsabili sia della continuità operativa sia della fornitura di nuove soluzioni AI.

Un'organizzazione ingegneristica non può trattare il proprio carico di lavoro esistente come facoltativo solo perché i dirigenti introducono una scadenza per l'AI. Correzioni di sicurezza, modifiche degli accessi, risposta agli incidenti e supporto applicativo restano necessari. Assegnare un obiettivo aggiuntivo non crea automaticamente la capacità necessaria per raggiungerlo.

Ciò produce un problema di budget che le sole cifre dell'organico possono nascondere. Un team può apparire adeguatamente dimensionato mentre gli specialisti restano occupati con sistemi che richiedono le loro conoscenze specifiche. Il vincolo rilevante è spesso la competenza disponibile durante la finestra di consegna, piuttosto che il numero totale di dipendenti.

Si consideri un esempio illustrativo di agente interno di assistenza che aiuta i dipendenti a risolvere problemi relativi agli account. Produrre una risposta plausibile è solo una parte dell'incarico. Il processo circostante deve identificare il dipendente, stabilire gli accessi consentiti, recuperare informazioni aggiornate e indirizzare le eccezioni a una persona responsabile.

Se l'agente può modificare un account, l'organizzazione necessita anche di regole di approvazione e di una registrazione dell'azione. Una dimostrazione efficace può evitare gran parte di questo lavoro operativo. Un servizio in produzione non può dipendere da qualcuno che corregga manualmente ogni caso insolito in seguito.

Queste esigenze spiegano perché sviluppatori e team di sicurezza subiscono pressioni da direzioni diverse. I leader aziendali desiderano progressi visibili. I team operativi devono preservare la disponibilità. I revisori della sicurezza necessitano di prove sufficienti per approvare l'accesso. Senza priorità esplicite, il lavoro di integrazione può diventare una dipendenza senza proprietario tra questi gruppi.

La manutenzione influisce anche sulla sequenza delle attività. Sostituire un'applicazione potrebbe alla fine ridurre lo sforzo di supporto, ma richiedere un lavoro sostanziale prima che tale beneficio emerga. Durante la transizione, i team potrebbero dover supportare i processi esistenti mentre apprendono il sistema sostitutivo. Una proposta di modernizzazione necessita quindi di una descrizione del carico di lavoro temporaneo.

È qui che le ampie promesse di liberare gli ingegneri meritano attenzione. La domanda rilevante è quali attività ricorrenti scompaiano, chi le svolga attualmente e quando tali persone diventino disponibili. Trasferire la responsabilità a un fornitore può aiutare, ma anche il lavoro residuo di integrazione e supervisione necessita di un responsabile.

I team di procurement affrontano una sfida correlata. Devono distinguere la comodità di acquisire un prodotto dallo sforzo necessario per gestirlo. Un contratto noto può semplificare l'acquisto senza risolvere l'accesso ai dati. Un fornitore poco familiare può offrire capacità interessanti aggiungendo al contempo un altro insieme di responsabilità operative.

Per i knowledge worker, le conseguenze si manifestano come disponibilità disomogenea. Un assistente potrebbe riassumere con successo i documenti, pur rimanendo incapace di utilizzare i record necessari per una decisione significativa. L'interfaccia AI visibile avanza quindi più rapidamente del workflow che la sostiene.

La pressione è dunque organizzativa quanto tecnica. La leadership deve decidere quali dipendenze meritino investimenti e quali progetti proposti debbano attendere. Altrimenti, ogni nuovo progetto pilota compete per le stesse persone senza modificare le condizioni che hanno rallentato i precedenti.

Aggiungere un agente non elimina il lavoro sottostante

L'automazione amplia l'importanza di interfacce aziendali affidabili perché le azioni richiedono confini più chiari dei suggerimenti.

L'argomentazione di Google diventa più persuasiva quando applicata a un workflow specifico che quando applicata alla sola ubicazione del software. Un sistema che produce consigli può lasciare l'esecuzione a una persona. Un sistema autorizzato ad agire deve affrontare regole che l'organizzazione ha reso esplicite.

Si consideri una richiesta d'acquisto illustrativa. Un dipendente potrebbe chiedere a un agente di preparare un ordine utilizzando un fornitore approvato. Il compito linguistico è semplice da descrivere. Il compito aziendale include la verifica dell'autorizzazione, la selezione dell'account corretto, l'applicazione della politica di acquisto e la gestione degli articoli non disponibili.

Ogni fase introduce una domanda che un testo fluente non può risolvere autonomamente. Quale record è autorevole? Il richiedente dispone dell'autorizzazione? L'acquisto proposto rispetta la politica? Cosa accade se l'ordine riesce ma la conferma fallisce?

Queste domande rivelano una distinzione tra generare una risposta e completare una transazione. L'organizzazione deve sapere cosa è accaduto nei propri sistemi, incluso il completamento parziale. Una risposta conversazionale sicura di sé non può sostituire questa evidenza.

Le applicazioni esistenti talvolta codificano regole che i dipendenti comprendono attraverso l'esperienza anziché tramite documentazione. L'implementazione di un agente può far emergere questa conoscenza nascosta. Quello che sembra un problema di integrazione può in realtà coinvolgere decisioni irrisolte su politiche, eccezioni o responsabilità.

Sostituire l'applicazione non risolverà necessariamente tali decisioni. Può creare un luogo migliore per esprimerle, ma qualcuno deve comunque determinare il comportamento previsto. Per questo le proposte di modernizzazione dovrebbero identificare il confine aziendale che migliorano, anziché fare affidamento sull'età del software sottostante.

Il resoconto di Google sulla propria implementazione nel servizio clienti fornisce un esempio concreto. Nell'aprile 2025, l'azienda ha descritto Wendy’s FreshAI mentre gestiva gli ordini drive-through e si espandeva in 24 Stati. Si tratta di affermazioni di implementazione riportate dall'azienda, piuttosto che di una prova indipendente dell'affidabilità generale degli agenti.

L'esempio illustra comunque il valore di un compito definito. Ordinare cibo presenta input riconoscibili, vincoli del menu e una transazione che deve raggiungere le operazioni del ristorante. La sua utilità dipende dalle connessioni con il processo di servizio effettivo, piuttosto che dalla sola qualità della conversazione.

Un workflow aziendale interno necessita di chiarezza comparabile, anche quando i suoi confini sono meno visibili. Una richiesta di analizzare un contratto, preparare un rinnovo o risolvere un problema di accesso richiede una destinazione concordata. Altrimenti, un team può dichiarare successo quando l'agente produce testo mentre i dipendenti a valle completano ancora il lavoro sostanziale.

Ciò rende l'integrazione una questione di responsabilità. Qualcuno deve assumere la responsabilità della transizione dalla raccomandazione all'azione approvata e dall'azione al risultato verificato. Senza tale responsabilità, l'automazione può ridistribuire lo sforzo lasciando il processo aziendale in gran parte invariato.

Il caso di modernizzazione più solido identifica tali transizioni e dimostra che migliorano. Le sue evidenze dovrebbero mostrare meno passaggi di consegne irrisolti, completamento affidabile e un recupero gestibile quando qualcosa va storto.

Google e Microsoft sottolineano percorsi diversi verso la preparazione

I fornitori differiscono nell'enfasi, ma entrambe le analisi rendono la preparazione organizzativa centrale per un'implementazione AI utile.

La posizione di Google attribuisce un ruolo di primo piano alla libertà architetturale. La ricerca di Microsoft sulla preparazione organizzativa all'AI pone maggiore enfasi sulla gestione, sulla progettazione del lavoro e sulla valutazione. Il suo rapporto di maggio 2026 si basa su un sondaggio condotto su 20.000 lavoratori che utilizzano l'AI in 10 mercati.

Microsoft afferma che le condizioni organizzative sono fortemente associate al valore che i rispondenti dichiarano di ottenere dall'AI. La sua metodologia distingue esplicitamente l'associazione statistica dalla causalità. Questa cautela è importante nel confrontare i risultati con la posizione di Google: nessuno dei due sondaggi stabilisce una formula universale per un'implementazione di successo.

Il confronto riflette inoltre differenti posizioni commerciali. Google ha interesse a incoraggiare gli acquirenti a riconsiderare relazioni aziendali consolidate. Microsoft ha interesse a rendere gli ambienti di lavoro esistenti contesti produttivi per l'AI. Questi incentivi aiutano a spiegare le rispettive enfasi senza invalidare automaticamente i risultati di nessuna delle due aziende.

Per gli acquirenti, la scelta comporta compromessi pratici. Estendere un ambiente consolidato può preservare un'amministrazione familiare e ridurre parte del lavoro di transizione. Introdurre un'alternativa può aumentare le opzioni negoziali o soddisfare un requisito specifico del flusso di lavoro. Entrambe le strade possono deludere se l'organizzazione salta la valutazione dell'integrazione.

Il sondaggio Google Cloud AI dovrebbe quindi spingere a esaminare attentamente la dipendenza, anziché al rifiuto automatico di un fornitore consolidato. La dipendenza diventa rilevante quando modificare un componente richiede un'interruzione inaccettabile, comporta la perdita di informazioni essenziali o lascia l'azienda incapace di operare in modo indipendente.

Questa preoccupazione si applica a un nuovo fornitore con la stessa facilità che a uno esistente. Un'impresa può sostituire un vincolo noto con uno meno familiare. Un contratto diverso non dimostra di per sé una maggiore libertà.

Una scelta significativa richiede prove operative. Un acquirente deve capire se i record restano utilizzabili al di fuori del prodotto, se le autorizzazioni possono essere ricostruite e se il lavoro completato rimane verificabile. Queste domande sono più rivelatrici del numero di nomi di modelli disponibili in un menu.

C'è inoltre una differenza tra scegliere un modello AI e sostituire una piattaforma di workflow. Il modello genera o interpreta informazioni. La piattaforma può contenere istruzioni, connessioni, record e cronologia delle approvazioni. Cambiare il primo può essere relativamente circoscritto, mentre cambiare la seconda influisce sull'intero processo.

Ciò rende la discussione sugli acquisti più impegnativa. Gli acquirenti dovrebbero valutare l'intero assetto operativo, compresi gli obblighi residui e le condizioni di uscita. Una dimostrazione pratica offre informazioni limitate su ciò che accade quando una connessione critica si interrompe o un'unità aziendale modifica il proprio processo.

La gestione della conoscenza offre un parallelo più circoscritto. Una base di conoscenza ricercabile è utile quando le persone possono recuperare materiale pertinente nel contesto. L'automazione aziendale aggiunge ulteriori requisiti perché le informazioni recuperate possono influenzare azioni con conseguenze organizzative.

Il confronto più solido tra Google e Microsoft riguarda quindi il modo in cui ciascun ambiente proposto supporta il lavoro effettivo. La preferenza per un marchio è un debole sostituto dell'esame dello stesso processo, delle stesse autorizzazioni e degli stessi criteri di accettazione tra approcci concorrenti.

Il sondaggio lascia aperte importanti questioni causali e di sicurezza

La frizione di manutenzione riportata giustifica un'indagine, ma non dimostra che la migrazione al cloud produca risultati migliori per ogni carico di lavoro.

L'enterprise readiness report allegato descrive un sondaggio online di 20 minuti, integrato da interviste qualitative. Il suo campione statunitense di decisori offre una prospettiva definita. I lettori dovrebbero mantenere presente questo perimetro quando discutono di imprese in altri contesti o di dipendenti al di fuori degli acquisti e della leadership tecnologica.

Il rapporto afferma inoltre che il 78% dei rispondenti ritiene che la manutenzione tecnologica sottragga risorse all'AI, mentre il 48% considera il proprio stack pronto per un'implementazione su scala. Si tratta di valutazioni sulla capacità e sulla preparazione. Non sono misurazioni dirette delle ore di ingegneria recuperate dopo una migrazione.

I rispondenti possono descrivere con precisione la frustrazione senza identificare il rimedio migliore. Un team in difficoltà per le esigenze di supporto potrebbe beneficiare di una sostituzione, di una configurazione migliore, di competenze aggiuntive o di un ambito AI più ristretto. Scegliere tra queste risposte richiede prove dall'ambiente interessato.

La sponsorizzazione commerciale merita attenzione per la stessa ragione. Google vende servizi allineati alla direzione proposta. La risposta appropriata consiste nell'esaminare le definizioni e confrontare le alternative, preservando al contempo i risultati che restano utili dopo un'attenta verifica.

La definizione basata sull'implementazione adottata dal sondaggio è particolarmente rilevante. Considerare il software gestito localmente come legacy rende centrale fin dall'inizio il confronto con il cloud. Gli acquirenti necessitano comunque di una valutazione separata della manutenibilità, della sicurezza, della qualità dell'integrazione e dell'idoneità aziendale.

La sicurezza introduce un altro limite a una semplice narrazione della migrazione. Un servizio gestito può cambiare chi si occupa della manutenzione dell'infrastruttura. Non elimina la necessità di decidere a quali informazioni un agente possa accedere o quali azioni richiedano una revisione.

Il framework di governance degli agenti di Gartner affronta questa distinzione. L'analista Shiva Varma sostiene che controlli uniformi possono limitare eccessivamente gli agenti semplici, lasciando al contempo insufficientemente limitati quelli più autonomi. Il framework distingue tra osservazione, consulenza e azione che richiede approvazione.

Questa prospettiva complica l'assunto secondo cui aumentare l'autonomia rappresenti sempre un progresso. Un agente limitato alla preparazione di una raccomandazione può essere appropriato per un workflow con conseguenze rilevanti. Richiedere l'approvazione è una decisione progettuale il cui valore dipende dall'azione e dai suoi potenziali effetti.

Un acquirente aziendale prudente dovrebbe di conseguenza distinguere il miglioramento dell'infrastruttura dal miglioramento delle autorizzazioni. Un hosting migliore può favorire disponibilità e manutenzione. Autorizzazioni migliori definiscono ciò che il sistema è autorizzato a fare. Entrambi meritano attenzione e nessuno dei due dovrebbe sostituirsi all'altro.

Il sondaggio Google Cloud AI non risolve l'equilibrio tra questi investimenti. Identifica vincoli percepiti che i leader possono esaminare. L'errore analitico sarebbe trasformare quel segnale nella prova che un'architettura, un fornitore o un livello di autonomia sia intrinsecamente preferibile.

Esiste un ulteriore problema di misurazione dopo l'implementazione. I dipendenti potrebbero dedicare meno tempo ad avviare il lavoro, ma più tempo a verificare risultati incerti. Un'affermazione sulla produttività deve tenere conto di questo sforzo di revisione, insieme al supporto e al ripristino. Altrimenti, un'automazione apparente può nascondere lavoro trasferito a un altro team.

Osservare i workflow completati, le prove di passaggio e il ripristino

Le prossime prove utili collegheranno le decisioni di modernizzazione ai risultati operativi che gli acquirenti possono esaminare.

Nei prossimi mesi, il primo segnale da osservare è la rendicontazione dei clienti sui workflow completati. Le comunicazioni utili distingueranno una dimostrazione dall'uso ricorrente e spiegheranno cosa costituisce un completamento riuscito. Dovrebbero inoltre identificare dove resta necessario l'intervento umano.

Queste prove rafforzerebbero l'argomento di Google se la modernizzazione eliminasse vincoli identificabili e producesse miglioramenti operativi ripetibili. Indebolirebbero un'ampia tesi sulla migrazione se i progetti richiedessero ancora un'estesa correzione manuale nonostante la sostituzione dell'ambiente sottostante.

Il completamento da solo è insufficiente quando il processo produce errori inaccettabili. Gli acquirenti hanno bisogno di prove sulla correttezza e sullo sforzo necessario per risolvere le eccezioni. Un workflow che termina rapidamente ma crea controversie a valle ha spostato il problema anziché risolverlo.

Il secondo segnale è il passaggio dimostrato. Gli annunci di prodotto su connettori o scelta del modello meritano un esame più attento quando i clienti mostrano che un processo operativo sopravvive al cambiamento di un componente. Preservare autorizzazioni, criteri di valutazione e record utilizzabili fornirebbe prove significative di flessibilità.

Un passaggio che richiede un'ampia ricostruzione racconta una storia diversa. Suggerisce che esista una scelta nominale accanto a una sostanziale dipendenza operativa. Questa distinzione sarà importante quando gli acquirenti confronteranno piattaforme di lavoro consolidate con ambienti alternativi per agenti.

Il terzo segnale è il ripristino in caso di guasto controllato. I resoconti dei clienti e le valutazioni tecniche dovrebbero spiegare cosa accade quando l'accesso scade, un'applicazione connessa diventa indisponibile o un'azione viene completata solo parzialmente. Le prove di ripristino rivelano come il sistema si comporta oltre la dimostrazione favorevole.

Una chiara attribuzione di responsabilità rafforzerebbe la fiducia. Un team dovrebbe poter identificare l'ultimo stato verificato, determinare quali azioni si sono verificate e decidere come riprende il lavoro. Se queste risposte richiedono ogni volta un'indagine informale, il carico operativo resta irrisolto.

Questi segnali aiutano anche a separare i vincoli dell'infrastruttura dai vincoli del processo. Una connessione fallita può indicare una dipendenza tecnica. Una controversia di approvazione irrisolta indica un problema di governance. Entrambi possono bloccare la consegna, ma richiedono risposte diverse.

Il sondaggio Google Cloud AI offre ai leader aziendali una ragione per esaminare dove viene impiegata la capacità ingegneristica. I suoi risultati sono più preziosi quando vengono tradotti in domande su uno specifico servizio, sulle sue dipendenze e sulle persone responsabili di mantenerlo utile.

Per i lettori che pianificano un investimento in AI, seguite il lavoro oltre la risposta dell'assistente. Chiedete quale risultato aziendale debba verificarsi, quali record stabiliscano il completamento e chi gestisca le eccezioni. Confrontate le proposte rispetto allo stesso risultato, includendo lo sforzo di migrazione e la revisione continua. Mantenete coerenti i criteri di accettazione quando valutate una piattaforma consolidata o un'alternativa. Pretendete che le affermazioni sulla manutenzione ridotta identifichino le attività eliminate e le responsabilità mantenute. Cercate poi prove fornite dai clienti che questi cambiamenti persistano durante le normali operazioni e i guasti controllati. Quale dipendenza impedisce attualmente al vostro team di completare un lavoro di valore e quali prove dimostrerebbero che l'investimento proposto la elimina davvero?