Per i CIO il Cloud è entrato in una nuova fase: non è più una scelta di adozione tecnologica, ma una questione di governo del portafoglio applicativo.
Ecco qual è la vera priorità, mentre si va verso una Cloud governance incorporata nelle piattaforme.
Indice degli argomenti
Dal Cloud First alla Cloud Governance selettiva
Il mercato italiano continua a crescere a ritmi sostenuti: secondo l’Osservatorio Cloud Transformation del Politecnico di Milano, nel 2025 la spesa ha raggiunto un valore stimato di 8,13 miliardi di euro (+20%), quasi il doppio dei 4,62 miliardi del 2022.
Ma il contesto è molto diverso da quello dei primi anni di adozione: geopolitica, regolazione, pressione sui costi, cyber security e sovranità del dato impongono scelte più selettive e misurabili, e non a caso cresce con forza anche il Cloud privato, spinto dalla domanda di controllo sulle informazioni.
Il focus non è più decidere se andare in Cloud, ma stabilire dove crea valore, dove aumenta la complessità e come governarlo senza compromettere sicurezza, sostenibilità economica e capacità di innovazione.
Ed i numeri confermano il cambio di passo, visto che tra le grandissime imprese rilevate dall’Osservatorio, le strategie Cloud First e Cloud Only per i nuovi progetti digitali passano in un anno rispettivamente dal 51% al 43% e dal 19% all’11%, mentre la strategia selettiva cresce di dieci punti, dal 26% al 36%.
L’Hybrid Cloud è ormai una configurazione strutturale e il Multi Cloud un’opzione per ridurre la dipendenza dal fornitore. Più aumentano però ambienti e piattaforme, più cresce il costo della complessità.
La selettività è una griglia decisionale condivisa con business, CISO, procurement e finance.
Criticità del processo supportato, vincoli regolatori, frequenza di evoluzione, costo del debito tecnico e possibilità di esporre dati e servizi all’AI orientano il trattamento di ciascuna applicazione, dal mantenimento al SaaS fino a replatforming, refactoring o ricostruzione.
Con questa disciplina, il Cloud libera risorse oggi assorbite dal legacy; senza, rischia di diventare un ulteriore livello di complessità.
La vera priorità: modernizzare il portafoglio applicativo
La spinta verso il Cloud si intreccia con un problema più profondo e radicato nelle aziende italiane ossia l’obsolescenza del patrimonio applicativo. Secondo le rilevazioni dell’Osservatorio, in media quasi il 40% del portafoglio delle grandi aziende richiede un qualche intervento di modernizzazione.
Le cause principali sono comuni: tecnologie fuori supporto, rigidità funzionale, difficoltà di integrazione, criticità di sicurezza e costi crescenti di manutenzione.
A queste motivazioni se ne aggiunge una nuova: la difficoltà di utilizzare dati e funzionalità presenti nei sistemi legacy all’interno di iniziative di Intelligenza Artificiale.
L’AI, soprattutto nelle forme generative e agentiche, ha bisogno di informazioni affidabili, servizi ben esposti e processi governati: quando il patrimonio applicativo è frammentato, la sua adozione rimane confinata a sperimentazioni isolate.
Per questo la modernizzazione non può ridursi a una migrazione infrastrutturale.
Il lift and shift resta utile quando serve velocità o l’applicazione è ancora adeguata sul piano funzionale, ma non è una strategia trasformativa.
Il SaaS è efficace per processi standard e poco differenzianti, a fronte di minore personalizzazione e maggiore dipendenza dal vendor.
Invece, la modernizzazione profonda, attraverso replatforming, refactoring o ricostruzione, ha senso quando il sistema supporta processi distintivi: è la strada più onerosa, ma anche quella capace di generare il maggiore valore in
flessibilità, integrazione e time to market.
Le imprese sembrano averlo compreso, tanto che oggi il 51% del portafoglio legacy analizzato è indirizzato verso percorsi di application modernization, sedici punti in più rispetto al 2023. Invece il puro lift and shift arretra di diciassette punti.
La scelta corretta non è quindi unica: è una decisione di portafoglio, applicazione per applicazione.
L’AI come acceleratore della modernizzazione
C’è un elemento nuovo che cambia l’economia di questa decisione: l’AI non è soltanto il consumatore che chiede sistemi migliori, è anche uno strumento per costruirli.
Nelle fasi iniziali può aiutare a recuperare conoscenza da sistemi poco documentati, analizzando codice, dipendenze, configurazioni, log, documentazione tecnica e ticket storici per ricostruire logiche applicative, processi supportati e aree di rischio: i team partono così da una comprensione più solida del patrimonio esistente, riducendo la dipendenza da conoscenze tacite concentrate in poche persone.
Nelle fasi successive il contributo diventa operativo: documentazione, individuazione di codice obsoleto o duplicato, suggerimento di refactoring, produzione di test, analisi degli impatti, supporto alla migrazione verso architetture più modulari.
Il valore non sta nell’automatizzare integralmente la modernizzazione, ma nel rendere più rapida e verificabile l’azione dei team, riducendo tempi di assessment e incertezza sulle priorità.
Il ruolo dell’AI nella zona grigia
Lo stesso effetto si osserva sulle decisioni make or buy. Agli estremi la scelta resta chiara: buy per processi standard già ben coperti dal mercato, make quando sono in gioco processi distintivi, dati proprietari o requisiti di controllo stringenti.
È nella zona grigia — applicazioni non pienamente core ma troppo specifiche per soluzioni standard, automazioni interne, integrazioni complesse — che l’AI può rendere più conveniente il make, abbassando i costi di prototipazione, sviluppo, test e manutenzione.
La domanda non è però soltanto «possiamo costruirlo?», ma «ha senso possederlo e governarlo nel tempo?».
Resta il vincolo del business case, che deve essere difendibile davanti a CEO e CFO: non basta stimare il costo del progetto, occorre confrontarlo con il costo di run del legacy, il debito tecnico accumulato, la prevedibilità della spesa Cloud e il rischio di lock-in. FinOps e application modernization, in questa prospettiva, non sono ambiti separati.
E il successo va misurato con pochi indicatori che parlino anche al business: lead time di rilascio, change failure rate, quota di spesa Cloud governata con logiche FinOps, riduzione del debito tecnico.
Cloud Native non significa adottare una tecnologia
In questa evoluzione il Cloud Native rappresenta un paradigma, non un prodotto. Non coincide necessariamente con microservizi, container o Kubernetes, anche se queste tecnologie ne sono spesso componenti importanti.
Il principio di fondo è progettare applicazioni capaci di sfruttare scalabilità, automazione, resilienza, osservabilità e rapidità di rilascio.
Tra chi lo ha adottato i benefici percepiti sono netti: il 95% delle aziende indica la semplicità di deployment, l’86% la velocità di sviluppo, l’80% la manutenibilità.
Il caso dei microservizi è istruttivo proprio per comprendere questa distinzione.
Il passaggio da architetture monolitiche a servizi più modulari aumenta l’autonomia dei team e consente di scalare solo le componenti necessarie, ma introduce nuovi costi: più integrazioni, più dipendenze e maggiore necessità di monitoraggio e sicurezza distribuita.
Nei sistemi semplici un’architettura monolitica ben progettata può essere più efficiente; il vantaggio dei microservizi emerge quando crescono complessità, frequenza dei rilasci e numero di team.
Per questo l’automazione, dalle pipeline di Continuous Integration e Delivery all’Infrastructure as Code, è ciò che rende governabili le architetture distribuite.
C’è poi una ragione ulteriore, meno discussa, per cui la modularità conta: un’applicazione ben segmentata espone funzioni e dati attraverso interfacce esplicite, ed è proprio questa proprietà che la rende utilizzabile da iniziative AI senza interventi invasivi. La modularità, nata come risposta a esigenze di delivery, diventa oggi un prerequisito di accessibilità.
Dalle regole alle piattaforme: la Cloud governance cambia forma
Il passaggio più rilevante riguarda il modello di governo. La Cloud Governance tradizionale si è spesso concentrata su policy, processi autorizzativi e controlli ex post.
In un contesto Cloud Native questo approccio non basta: quando team e servizi aumentano, governare manualmente ogni progetto rallenta l’innovazione e rende difficile mantenere coerenza.
La risposta sta nella costruzione di piattaforme comuni che incorporano standard architetturali, servizi riutilizzabili, controlli di sicurezza e strumenti di gestione dei costi.
La Platform Engineering porta questa logica a livello operativo, offrendo ai team percorsi standardizzati e self-service per sviluppare e rilasciare più rapidamente e in sicurezza.
La governance non scompare: cambia forma e diventa governance by design, incorporata in template, pipeline, API e guardrail tecnologici anziché in procedure e approvazioni ex post.
GDPR, NIS2, DORA e AI Act spingono nella stessa direzione, verso sistemi tracciabili e verificabili in cui accessi, modifiche, configurazioni e flussi dati possano essere dimostrati: la governance incorporata è quindi anche una leva di compliance operativa, non soltanto una scelta architetturale.
Il vantaggio è aumentare la velocità riducendo la variabilità delle soluzioni. Il rischio, se la piattaforma è progettata male, è introdurre un nuovo livello di rigidità o una dipendenza eccessiva dai platform team: la standardizzazione deve essere abbastanza forte da garantire sicurezza ed efficienza, ma non
tanto prescrittiva da limitare l’autonomia.
EInoltre, richiede competenze adeguate, che le imprese indicano tra i fattori più critici del percorso.
Per questo la piattaforma non va intesa come un prodotto tecnico del solo team infrastrutturale, ma come un servizio interno a supporto della capacità realizzativa dell’intera organizzazione IT: con owner, roadmap, catalogo dei servizi, SLA, metriche di adozione e meccanismi di feedback dai team applicativi. È la differenza tra un abilitatore e un collo di bottiglia.
Agenti AI e governo della modernizzazione
L’evoluzione dell’AI rende questa trasformazione ancora più urgente, perché i consumatori dei servizi aziendali non sono più soltanto persone o applicazioni tradizionali: gli agenti software possono interrogare dati, invocare strumenti, orchestrare attività e supportare decisioni operative.
Se il patrimonio applicativo resta frammentato, l’AI amplifica complessità, esposizione al rischio e costi non controllati; se dati, API, identità e controlli sono progettati in modo coerente, diventa una componente affidabile del sistema informativo.
Standard emergenti come il Model Context Protocol facilitano il collegamento tra agenti e strumenti aziendali, ma non sostituiscono la governance: al contrario ne aumentano la necessità, perché impongono di decidere quali dati e quali azioni esporre, a quali condizioni e con quali autorizzazioni, log, limiti di costo e responsabilità operative.
La posta in gioco non è dunque adottare nuove tecnologie, ma costruire un sistema informativo capace di evolvere alla velocità richiesta dal business senza perdere controllo su costi, sicurezza, compliance e dati.
Quattro domande per il futuro della Cloud governance
Il futuro della Cloud Governance sarà selettivo, automatizzato e incorporato nelle piattaforme: il vantaggio competitivo non nascerà dal numero di applicazioni migrate, ma dalla capacità di trasformare la governance in piattaforma, riducendo la distanza tra strategia ed esecuzione.
Chi rimanderà questa scelta rischia di moltiplicare frammentazione e debito tecnico proprio quando l’AI richiede sistemi più aperti, integrati e affidabili.
La verifica può partire da quattro domande, ciascuna con la sua misura:
- Quali applicazioni sono davvero differenzianti, e quanta parte del portafoglio è già classificata per criticità?
- Quali dati e API vanno resi disponibili all’AI in modo sicuro, e quanti di questi controlli sono automatizzati nelle pipeline?
- Quali componenti conviene comprare o costruire nella zona grigia resa accessibile dall’AI, e con quale effetto atteso sul lead time?
- Quanta spesa Cloud è governata con logiche FinOps, e quanto debito tecnico si è ridotto nell’ultimo esercizio?
Rispondendo a queste quattro domande, si evita di rinviare la scelta della Cloud governance.
Partecipa alla community