L’AI sposta il budget IT dal software a server, storage, memoria e sicurezza. Il caso IBM rivela che cosa cambia per CIO, vendor e canale.

L’intelligenza artificiale sta ridisegnando i budget IT delle imprese. Nel 2026 server, storage, memoria, networking e cybersecurity vengono acquistati prima, spesso per assicurarsi capacità limitata ed evitare nuovi aumenti di prezzo; nello stesso momento progetti software, migrazioni applicative e programmi di trasformazione digitale già approvati vengono rinviati. L’AI non sta soltanto creando nuova spesa tecnologica. Sta decidendo quale parte della vecchia spesa può ancora aspettare.

Questa è la notizia: il denaro non si limita ad aggiungersi al budget IT, si sposta al suo interno. La capacità di calcolo, i dati, le reti, l’energia e la sicurezza necessarie a portare l’AI in produzione stanno occupando risorse che fino a pochi mesi fa erano destinate ad applicazioni, cloud, consulenza e modernizzazione. Il software non scompare, ma deve dimostrare di essere indispensabile prima che arrivi il conto dell’infrastruttura.

IBM è il caso che ha reso visibile questo movimento, non la notizia che lo esaurisce. Il 14 luglio 2026 l’azienda ha pubblicato in anticipo alcuni risultati preliminari del secondo trimestre e ha ammesso di non avere previsto la dimensione dello spostamento del CAPEX dei clienti verso server, storage e memoria. Numerosi grandi contratti non sono stati chiusi nei tempi attesi, i ricavi si sono fermati a 17,2 miliardi di dollari e il titolo IBM ha perso circa il 25% in una sola seduta. La lettera di Arvind Krishna agli investitori IBM, insieme alla ricostruzione di Reuters sul trasferimento della spesa dal software all’infrastruttura, offre la prova più evidente di un fenomeno più ampio. Il crollo in Borsa è il sintomo, il terremoto è avvenuto nei budget IT delle imprese.

Per anni l’intelligenza artificiale è stata presentata come una nuova voce di investimento, capace di allargare il mercato tecnologico e di aggiungere spesa a quella già destinata a cloud, applicazioni, trasformazione digitale e servizi. Oggi emerge una realtà più scomoda: almeno in questa fase, una parte dell’AI non sta creando nuovo budget, lo sta occupando. Quali progetti verranno rinviati nei prossimi dodici mesi per finanziare la capacità di calcolo, i dati, le reti e la sicurezza necessari a farla funzionare?

Il 25% perso da IBM è un sintomo, non la diagnosi

I numeri preliminari di IBM vanno letti con attenzione. I ricavi del secondo trimestre sono cresciuti dell’1%, quelli del software del 5%, la consulenza è rimasta sostanzialmente stabile e l’infrastruttura è scesa del 7%. La debolezza si è concentrata soprattutto nei sistemi Z e nel software collegato al transaction processing, mentre Red Hat ha accelerato all’11%. Nello stesso trimestre la Distributed Infrastructure di IBM è cresciuta del 37%, con risultati record in Power e storage e un portafoglio ordini di circa 500 milioni di dollari.

Non è dunque la storia semplice di un mercato che abbandona il software per tornare all’hardware. È una redistribuzione più selettiva: perde ciò che può aspettare, cresce ciò che serve immediatamente a costruire la nuova capacità.

IBM ha anche riconosciuto una propria responsabilità. Krishna ha scritto che l’azienda non si è adattata abbastanza rapidamente e che diversi grandi contratti non sono arrivati alla firma prevista. Questo impedisce di trasformare un singolo trimestre in una legge universale. I risultati completi saranno presentati il 22 luglio e potrebbero correggere alcuni dati preliminari. Tuttavia, la dimensione della reazione del mercato, che secondo Reuters avrebbe potuto cancellare circa 70 miliardi di dollari di capitalizzazione, indica che gli investitori hanno visto nel caso IBM qualcosa di più di un problema di execution.

Hanno visto il rischio che il vecchio equilibrio della spesa tecnologica si stia rompendo.

La lettera di Arvind Krishna di IBM: tre frasi che spiegano il caso

Il documento firmato da Arvind Krishna, Chairman, President e CEO di IBM, non è una normale lettera trimestrale. IBM ha diffuso risultati preliminari il 14 luglio, otto giorni prima della conference call programmata per il 22 luglio, mentre la chiusura formale dei conti era ancora in corso. Quando un CEO rompe il calendario ordinario delle comunicazioni finanziarie, non vuole soltanto informare il mercato: vuole provare a stabilire immediatamente come debba essere interpretato ciò che è accaduto.

La lettera completa di Arvind Krishna agli investitori IBM è costruita in quattro passaggi. Prima espone i numeri; poi descrive lo shock esterno, cioè il rapido spostamento degli acquisti verso infrastrutture difficili da reperire; subito dopo riconosce l’errore di esecuzione di IBM; infine riporta l’attenzione sui punti forti del portafoglio e sugli investimenti futuri. È una struttura difensiva, ma non elusiva: Krishna prova a proteggere la strategia senza nascondere che, nel trimestre, l’azienda non ha reagito abbastanza velocemente.

C’è anche una distinzione importante. Krishna non scrive testualmente che l’intelligenza artificiale ha sottratto budget al software. Scrive che, nelle ultime settimane di giugno, i clienti hanno spostato il CAPEX trimestrale verso server, storage e memoria per assicurarsi infrastrutture limitate prima di nuovi aumenti di prezzo. Il collegamento con l’AI nasce dal contesto industriale: è l’intelligenza artificiale ad avere accelerato la domanda di calcolo, memoria e rete e ad avere reso strategica la disponibilità di capacità. La lettera descrive il movimento del denaro; il mercato ne ha riconosciuto il motore.

Il budget non è sparito: ha cambiato priorità

“we did not anticipate the magnitude of the capex reprioritization”

Questa è la frase economicamente più importante. Krishna non parla di cancellazione del budget, ma di reprioritization: le risorse esistono, però vengono portate in avanti e assegnate a un altro livello dello stack. La differenza è decisiva. Una contrazione generale della spesa colpirebbe quasi tutti i fornitori; una ridefinizione delle priorità crea invece vincitori e perdenti nello stesso trimestre, perfino all’interno della stessa azienda.

IBM ne è l’esempio. L’infrastruttura complessiva arretra, ma Power e storage accelerano; alcuni contratti software slittano, mentre Red Hat continua a crescere. Non è il mercato IT che si spegne. È il cliente che decide che oggi la capacità vale più di un aggiornamento applicativo che può essere firmato fra tre mesi.

Per un CIO questa frase contiene un avvertimento operativo: il budget annuale non può più essere considerato una sequenza stabile di progetti. Scarsità e prezzo possono comprimere in poche settimane decisioni che erano state distribuite su dodici mesi. La capacità di calcolo diventa una sorta di opzione finanziaria: si compra prima per evitare di non poterla comprare dopo.

Il CEO riconosce l’errore di IBM

“this quarter we faltered”

Sono quattro parole, ma cambiano il tono dell’intero documento. Dopo avere descritto supply chain, rialzi di prezzo e preoccupazioni di cybersecurity, Krishna non usa questi elementi come alibi. Ammette che IBM ha vacillato, che non si è adattata e non si è mossa abbastanza velocemente. È il passaggio che impedisce di leggere la lettera come una semplice giustificazione macroeconomica.

L’analisi più equilibrata deve quindi tenere insieme due verità. Lo spostamento della spesa è reale e probabilmente riguarda molte imprese; l’entità del danno subito da IBM dipende anche dalla sua capacità di leggere il cambiamento, riposizionare l’offerta e chiudere i contratti. Un concorrente più rapido potrebbe subire meno lo stesso fenomeno o perfino beneficiarne.

Questa ammissione è rilevante anche per il canale. Quando il cliente cambia priorità, non basta avere a catalogo il prodotto che improvvisamente cerca. Bisogna riconfigurare la proposta, il finanziamento, le competenze e il progetto prima che il trimestre finisca. La domanda si può spostare più velocemente della macchina commerciale che dovrebbe intercettarla.

Il problema finanziario nasce dal calendario

“numerous large deals failed to close”

Krishna non dice che quei contratti siano stati definitivamente persi. Dice che non sono stati chiusi nei tempi attesi. Per un’azienda cliente può sembrare una differenza amministrativa; per un fornitore quotato è la differenza fra centrare e mancare il trimestre. Un progetto rinviato di tre settimane conserva forse tutto il proprio valore industriale, ma può scomparire completamente dal conto economico del periodo.

Qui si trova il punto più fragile dell’interpretazione. Se i contratti verranno recuperati nel trimestre successivo, il caso IBM sarà in parte una crisi di tempistica aggravata da un errore di esecuzione. Se continueranno a slittare perché il budget resta assorbito da infrastruttura e sicurezza, diventerà la prova di un cambiamento strutturale. La lettera non può ancora risolvere questo dubbio; indica però la misura da osservare nei prossimi risultati: non soltanto quanti accordi vengono firmati, ma quanto a lungo rimangono sospesi.

Che cosa la lettera dice davvero, e che cosa non dimostra

La lettera di Krishna è forte perché IBM si trova su entrambi i lati dello spostamento. Vende il software e i mainframe che hanno sofferto, ma vende anche Power, storage, Red Hat, consulenza e soluzioni AI che possono intercettare la nuova spesa. Nel trimestre il software è cresciuto del 5%, Red Hat dell’11% e la Distributed Infrastructure del 37%. IBM non è soltanto la vittima della corsa all’infrastruttura: è anche uno dei soggetti che avrebbero dovuto guadagnarci.

Per questo il crollo del titolo non dimostra che il software sia finito, né che ogni azienda stia tagliando gli stessi progetti. Dimostra qualcosa di più sottile: essere presenti in tutte le categorie non basta quando il valore si sposta rapidamente fra quelle categorie. Contano il mix dei prodotti, il momento in cui il cliente firma, la capacità di finanziare l’acquisto, la disponibilità dei componenti e la velocità con cui il canale traduce una nuova urgenza in un’architettura acquistabile.

Nella parte finale Krishna torna sulla strategia, cita la crescita di Red Hat, le acquisizioni, l’AI applicata alla cybersecurity e gli investimenti nel quantum computing. È il tentativo comprensibile di spostare lo sguardo dal trimestre al futuro. Ma non cancella la domanda aperta dalla prima metà del documento: se l’AI obbliga le imprese a scegliere, quali offerte IBM e quali progetti software continueranno a essere considerati indispensabili?

La risposta non arriverà da una sola trimestrale. La lettera, però, ha già reso pubblico il conflitto che fino a ieri restava nascosto nei fogli di pianificazione dei CIO: l’AI non compete soltanto con altre piattaforme di intelligenza artificiale. Compete con tutto ciò che l’azienda aveva già deciso di comprare.

AI e budget IT: la spesa aumenta oppure si sposta?

Le due cose possono essere vere contemporaneamente. A livello mondiale la spesa IT continua a crescere: Gartner stima 6.316 miliardi di dollari nel 2026, il 13,5% in più rispetto al 2025. Ma la crescita non è distribuita in modo uniforme. La spesa per i sistemi da data center è prevista in aumento del 55,8%, fino a quasi 788 miliardi di dollari; quella per il software del 15,1%; i servizi IT del 9%.

Il mercato complessivo si espande, quindi. Il problema nasce dentro la singola azienda, dove il budget non cresce necessariamente del 13,5% e quasi mai può essere ridisegnato in poche settimane. Se il consiglio di amministrazione chiede di portare l’AI in produzione, se il fornitore avverte che GPU e memoria costeranno di più, se il cloud propone un impegno pluriennale per riservare capacità, il CIO deve trovare rapidamente i soldi. E il posto più vicino in cui cercarli è il portafoglio di progetti già approvati.

È lo stesso meccanismo osservato quando le imprese hanno scoperto che i costi reali dell’AI enterprise non coincidevano con il prezzo della licenza di un chatbot: inferenza, integrazione, qualità dei dati, governance, competenze e sicurezza emergono soltanto quando si passa dal prototipo alla produzione.

L’AI non entra nel bilancio come un prodotto. Entra come una catena di dipendenze.

Che cosa compra davvero un’azienda quando compra l’AI

La parte visibile dell’intelligenza artificiale è il modello. La parte costosa è tutto ciò che deve accadere perché quel modello risponda con continuità, utilizzi i dati dell’impresa, rispetti i permessi e regga migliaia o milioni di richieste. Dal punto di vista tecnico, il budget si distribuisce almeno su sei strati.

1. Calcolo accelerato

L’addestramento dei modelli richiede cluster di GPU o acceleratori specializzati, ma anche l’inferenza aziendale può diventare onerosa. Un progetto pilota che produce qualche migliaio di token al giorno non dice quasi nulla sul costo di un servizio usato da migliaia di dipendenti, integrato nei processi o chiamato automaticamente da agenti software. Servono GPU, CPU, scheduler, sistemi di orchestrazione e capacità ridondante per gestire i picchi.

Il dimensionamento non può fermarsi al numero di utenti. Deve considerare token in ingresso e in uscita, dimensione del contesto, latenza accettabile, concorrenza delle richieste, precisione numerica del modello, tasso di utilizzo degli acceleratori e possibilità di batching. Una GPU acquistata e usata al 20% può costare più del cloud; una capacità stabile, sensibile e sfruttata in modo continuo può rendere conveniente l’on premise.

2. Memoria ad alta larghezza di banda

I modelli devono essere caricati in memoria e spostare grandi quantità di dati molto rapidamente. La HBM è diventata uno dei colli di bottiglia dell’intera filiera: la domanda cresce più velocemente dell’offerta e il costo della memoria si trasferisce sui server, sui servizi cloud e perfino sui dispositivi tradizionali. È una delle ragioni per cui le imprese anticipano gli acquisti: non stanno soltanto cercando prestazioni, stanno comprando prevedibilità.

3. Storage e infrastruttura del dato

L’AI enterprise non vive nei pesi del modello, ma nei dati che il modello deve interrogare. Dataset, documenti, log, immagini, backup, checkpoint, vector database, cache semantiche e pipeline RAG chiedono capacità, throughput e bassa latenza. Lo storage deve inoltre garantire versioning, tracciabilità, cifratura, immutabilità e separazione fra dati di produzione, dati di addestramento e informazioni personali.

È il motivo per cui il canale italiano sta costruendo competenze specifiche, come racconta il Competence Center IBM Fusion di Computer Gross: sopra si vede il modello, sotto servono gestione del dato, protezione, container e portabilità fra cloud e data center aziendale.

4. Networking ad alte prestazioni

Un cluster AI è efficace soltanto se gli acceleratori riescono a scambiarsi dati senza restare in attesa. Le reti Ethernet a 400 o 800 gigabit, InfiniBand, RDMA, gli switch a bassa latenza e la gestione del traffico est-ovest diventano parte del sistema di calcolo. Fuori dal cluster servono connettività verso storage, cloud, edge e fonti dati aziendali, con segmentazione e controllo degli accessi.

Il networking non è più il tubo che collega i server: è uno dei fattori che determinano quanti token il sistema riesce a produrre per unità di tempo e per watt.

5. Energia, raffreddamento e spazio fisico

Le densità dei rack AI possono superare di molte volte quelle dei data center tradizionali. Aumentano la potenza elettrica richiesta, la necessità di raffreddamento a liquido, la complessità degli UPS e i vincoli sulla collocazione delle macchine. Digitalic lo aveva già mostrato raccontando la fame di data center e di energia dell’AI: la competizione si è spostata dal modello al watt.

6. Sicurezza, osservabilità e gestione

Un sistema AI aggiunge API, identità non umane, prompt, plugin, dati vettoriali, modelli esterni e catene di agenti. Ogni elemento crea una superficie d’attacco e deve essere monitorato. Servono controllo degli accessi, gestione dei segreti, DLP, cifratura, logging, protezione delle API, valutazione dei modelli, monitoraggio dei costi, backup e incident response.

È qui che la promessa di risparmio dell’AI incontra il conto reale dell’AI.

Perché le aziende stanno anticipando gli acquisti hardware

Lo spostamento descritto da IBM non nasce soltanto dall’entusiasmo, nasce dall’incontro di quattro forze.

La prima è la scarsità. GPU, HBM, storage ad alte prestazioni e alcuni componenti di rete hanno tempi di consegna e disponibilità che non seguono i calendari dei progetti aziendali. A luglio Omdia ha rilevato come l’aumento dei costi di memoria e storage stia già comprimendo il mercato PC, segno che la tensione della filiera AI si propaga anche ad altri segmenti.

La seconda è il prezzo. Se i fornitori annunciano aumenti, acquistare prima significa proteggere il progetto da una variazione che potrebbe far saltare il business case sei mesi dopo.

La terza è il tempo. Un’applicazione può essere comprata quando il processo è pronto; la capacità infrastrutturale deve spesso essere prenotata prima. Anche nel cloud, i contratti di capacità riservata e i committed spend trasformano l’OPEX in un impegno che assomiglia molto a un CAPEX pluriennale.

La quarta è politica. Il consiglio di amministrazione non vuole sentirsi dire che il progetto AI promesso al mercato, ai clienti o ai dipendenti è fermo perché manca una GPU. Per il CIO, la disponibilità di calcolo diventa una forma di assicurazione strategica.

Questo spiega l’anticipo. Non dimostra, però, che ogni acquisto sia razionale. Il rischio opposto è costruire un’infrastruttura sovradimensionata per casi d’uso ancora immaturi, congelando capitale in macchine che invecchiano rapidamente e che richiedono competenze difficili da reperire.

I progetti software che rischiano di essere rinviati

Quando il budget si tende, non vengono tagliati necessariamente i progetti meno costosi, ma quelli la cui urgenza è più difficile da dimostrare. Sono esposti gli aggiornamenti ERP o CRM senza un ritorno vicino, le migrazioni applicative pensate come semplice sostituzione tecnologica, il consolidamento di piattaforme che non produce risparmi immediati, le nuove suite di collaborazione sovrapposte a strumenti già presenti e le iniziative di data analytics che non alimentano casi d’uso operativi.

Rischiano anche i grandi programmi di modernizzazione pluriennale. Sono importanti, ma chiedono denaro oggi per un beneficio distribuito nel tempo; un progetto AI sponsorizzato dal vertice promette invece produttività visibile in pochi mesi, anche quando quella promessa non è stata ancora dimostrata.

Rinviarli può essere ragionevole. Rinviarli tutti è pericoloso. Molti progetti AI falliscono precisamente perché applicazioni, processi e dati non sono stati modernizzati: si compra l’acceleratore, ma il dato resta intrappolato in sistemi incompatibili; si installa il modello, ma le API non esistono; si costruisce l’agente, ma i permessi aziendali non sono abbastanza granulari.

Il CIO deve quindi distinguere fra software sostituibile e software abilitante. Un aggiornamento puramente cosmetico può aspettare. Una piattaforma dati, un layer di integrazione, la gestione delle identità o la modernizzazione dell’applicazione da cui l’AI deve estrarre informazioni non sono alternative all’infrastruttura AI: ne fanno parte.

Il software non sta morendo: si sta dividendo

Gartner prevede per il software una crescita mondiale del 15,1% nel 2026 e IBM stessa ha registrato un aumento del 5%, con Red Hat all’11%. Se l’AI stesse semplicemente divorando tutto il software, questi numeri non esisterebbero.

La frattura è fra software collegato alla nuova priorità e software percepito come rinviabile. Crescono piattaforme dati, orchestrazione, sicurezza, MLOps, osservabilità, sviluppo AI, automazione dei processi e applicazioni capaci di dimostrare un risultato. Soffrono di più le licenze per posto di lavoro non utilizzate, gli strumenti duplicati, le suite che aggiungono un assistente AI senza cambiare il processo e i contratti pluriennali il cui valore si basa soprattutto sulla difficoltà di uscire.

L’AI esercita una doppia pressione sui vendor software. Sottrae budget alle offerte tradizionali e, nello stesso tempo, rende più facile scrivere codice, costruire alternative e automatizzare funzioni che prima giustificavano un abbonamento. Non basta aggiungere un pulsante “AI” all’interfaccia. Occorre dimostrare che quel software riduce il costo totale del processo più di quanto aumenti il costo della sua infrastruttura.

Che cosa cambia per system integrator, vendor e canale IT

Per il canale questa può sembrare una buona notizia: tornano server, storage e networking. Ma il fatturato hardware non coincide automaticamente con il valore. I componenti possono avere margini ridotti, prezzi instabili, tempi di consegna lunghi e un fabbisogno finanziario elevato. Il vero margine si sposta nella progettazione.

Come Digitalic ha raccontato analizzando l’AI industriale presentata al NVIDIA GTC 2026, un system integrator non deve più limitarsi a dimensionare server e storage: deve progettare AI factory, reti ad alta velocità, raffreddamento, pipeline dati, sicurezza e modelli operativi misurati in token per watt.

Per i diversi attori della filiera le conseguenze sono precise:

1. I distributori devono gestire disponibilità, credito, configurazioni complesse e laboratori dimostrativi. La logistica resta importante, ma senza competenze rischia di diventare il punto meno remunerativo della catena.
2. I system integrator devono unire architettura, dati, rete, sicurezza, cloud e FinOps. Il cliente non ha bisogno di una GPU: ha bisogno di sapere quale carico farle eseguire, con quale livello di utilizzo e con quale costo per risultato.
3. Gli MSP possono trasformare l’infrastruttura in servizio, occupandosi di osservabilità, patching, capacity planning, sicurezza e ottimizzazione continua. È un modello più difendibile della vendita una tantum.
4. I vendor software devono legare il rinnovo a un risultato misurabile, rendere flessibili le licenze e facilitare l’integrazione con modelli e agenti diversi. I contratti rigidi diventano il primo posto in cui il CIO cerca liquidità.
5. I vendor infrastrutturali devono evitare di vendere capacità senza adozione. Un cluster inutilizzato produce un cliente deluso, non un caso di successo.

Il canale che vincerà non sarà quello che vende più hardware durante la scarsità, ma quello che impedisce al cliente di comprarne troppo e riesce comunque a costruire un servizio redditizio intorno a ciò che serve davvero.

Perché la cybersecurity è una delle poche voci che non può aspettare

Nella lettera di IBM compare un secondo elemento: le aziende sono state assorbite da problemi di cybersecurity in rapida evoluzione. Non è una parentesi. È una delle ragioni per cui la sicurezza continua a difendere il proprio budget anche mentre altri progetti vengono rinviati.

Gartner prevede che la spesa mondiale per la sicurezza informatica raggiunga 244 miliardi di dollari nel 2026, con una crescita dell’11,6%. La cybersecurity è protetta da tre fattori: il rischio operativo, perché un attacco può fermare l’impresa; la pressione normativa, da NIS2 all’AI Act; la nuova superficie creata dall’intelligenza artificiale.

Portare l’AI in produzione significa autorizzare software a leggere documenti, interrogare applicazioni, generare codice e compiere azioni. Le identità non umane aumentano, i privilegi si moltiplicano e i dati possono uscire dal perimetro attraverso prompt, API o connettori. Servono segmentazione della rete, Zero Trust, gestione delle identità macchina, protezione delle API, controllo dei modelli, sicurezza dei dati e backup immutabili. La guida completa alla cybersecurity di Digitalic mostra perché la sicurezza non è più uno strumento aggiunto al progetto: è la condizione che permette al progetto di esistere. Tagliare cybersecurity per finanziare l’AI sarebbe come togliere i freni per pagare un motore più potente.

Budget IT 2027: che cosa dovrebbe fare oggi un CIO

La pianificazione 2027 non può limitarsi ad aggiungere una riga “intelligenza artificiale” al foglio dell’anno precedente. Occorre ridisegnare il portafoglio e rendere visibile il costo dell’intero stack. Otto decisioni possono evitare che l’urgenza diventi spreco.

1. Separare capacità e casi d’uso

Prima di comprare infrastruttura, il CIO deve mappare quali applicazioni useranno davvero l’AI, con quale frequenza e con quali requisiti di latenza, riservatezza e disponibilità. La capacità va collegata a carichi verificabili, non a una generica previsione di crescita.

2. Misurare il costo per risultato, non il costo per licenza

Per ogni processo servono indicatori come costo per pratica completata, token per transazione, tempo risparmiato, percentuale di intervento umano, accuratezza e costo degli errori. Il prezzo del modello è solo una frazione del TCO; vanno inclusi integrazione, dati, sicurezza, persone, infrastruttura e gestione.

3. Costruire tre scenari di capacità

Il budget dovrebbe contenere almeno uno scenario prudente, uno atteso e uno di forte adozione, con ipotesi esplicite su prezzi della memoria, disponibilità degli acceleratori, consumo cloud e crescita degli utenti. Questo permette di prenotare ciò che è necessario senza acquistare oggi tutto ciò che potrebbe servire fra due anni.

4. Usare cloud e on premise per carichi diversi

Il cloud è adatto a sperimentazione, picchi e modelli che cambiano rapidamente; l’on premise può essere competitivo per carichi stabili, sensibili e ad alto utilizzo. La scelta non deve essere ideologica. Un’architettura ibrida ben governata riduce il rischio di sovracapacità e quello di dipendenza da un solo fornitore.

5. Proteggere i progetti che rendono possibile l’AI

Data quality, API, identità, integrazione, modernizzazione applicativa e governance non devono essere tagliati perché classificati come “vecchia trasformazione digitale”. Se sono dipendenze del progetto AI, devono essere finanziati nello stesso business case.

6. Creare una riserva, non un assegno in bianco

Una quota del budget può essere destinata a variazioni di prezzo e capacità non previste, ma il suo utilizzo deve passare attraverso gate tecnici e finanziari. Ogni espansione dovrebbe richiedere dati su utilizzo, saturazione, domanda e beneficio prodotto.

7. Rinegoziare il software prima di cancellarlo

Il CIO può ridurre utenti inattivi, eliminare sovrapposizioni, passare a licenze modulari, introdurre clausole di flessibilità e collegare i rinnovi all’adozione effettiva. La razionalizzazione libera budget senza creare nuovo debito tecnico.

8. Tenere cybersecurity e resilienza fuori dalla lotteria dei tagli

La sicurezza deve essere una percentuale progettata dell’investimento AI, non ciò che resta alla fine. Ogni nuova piattaforma deve includere fin dall’inizio identità, logging, segmentazione, protezione dei dati, backup, test di risposta e responsabilità operative.