Per oltre un decennio il software enterprise “as-a-service” (SaaS) ha potuto contare su una legge di gravità favorevole: crescita organica sostenuta, ricavi ricorrenti, espansione sull’installato, progressivo blocco tecnologico e contrattuale, e mercati che premiavano la prevedibilità.
Oggi quella gravità sta cambiando. Non per un singolo evento, ma per la convergenza di tre dinamiche: AI come discontinuità di modello, fusioni e acquisizioni come leva difensiva, asimmetria contrattuale crescente nei sistemi critici. Il punto non è se il cloud “convenga” (spesso conviene), ma se l’impresa stia costruendo autonomia decisionale nel tempo.
Perché quando i sistemi digitali diventano infrastrutture industriali, un cambiamento unilaterale di prezzo, condizioni o disponibilità non impatta “solo l’IT”: impatta la capacità dell’azienda di operare, pianificare e competere.
A questo punto va fatta una precisazione importante: nel rischio “di business” un’impresa può scegliere consapevolmente un compromesso (costi, time-to-market, dipendenze).
Nel rischio che riguarda dati personali, invece, non esiste una scorciatoia del tipo “accetto e vado avanti”: l’azienda non può trasferire sui clienti il rischio sui loro diritti e libertà. Deve dimostrare che il rischio residuo è governato con misure effettive e verificabili e, se non lo è, deve cambiare disegno (architettura, perimetro, fornitori), non limitarsi a dichiarare l’accettazione.
Indice degli argomenti
Perché il cloud e software enterprise entrano in una nuova fase di asimmetria contrattuale
Questa è la parte che molti manager sottovalutano: il rischio non è la migrazione in sé, ma la traiettoria dei rinnovi, dei riposizionamenti commerciali e dei cambi di metriche su cui sono costruiti i modelli di costo nel ciclo di vita.
Quando il software era un asset posseduto (licenze perpetue e manutenzione), l’asimmetria si manifestava soprattutto nei momenti di rinnovo delle licenze, negli aggiornamenti di versione o nei progetti di trasformazione.
Nel modello “diritto d’uso” in abbonamento, l’asimmetria si ripresenta con maggiore frequenza: si compra continuità operativa e spesso non si ha la libertà pratica di “non rinnovare”.
Da qui una conseguenza strategica: la Direzione IT non può più essere valutata solo su disponibilità e capacità di consegna. Il CIO deve essere garante di sostenibilità economica nel tempo, resilienza contrattuale e autonomia industriale rispetto a shock di mercato e di giurisdizione.
AI e cloud e software enterprise: la discontinuità che cambia il modello
Molti fornitori presentano l’AI come un’estensione dell’offerta. La discontinuità, però, non è “aggiungere un assistente”: è che l’AI riduce potenzialmente i tempi con cui si progettano soluzioni, si automatizzano attività e si porta valore in produzione.
Quando l’AI diventa l’interfaccia dei processi, vale a dire agenti che consultano dati e attivano azioni, con supervisione umana o in autonomia, la frontiera non è più la singola funzionalità ma l’affidabilità del sistema: dati, integrazioni, regole, tracciabilità (cioè la possibilità di ricostruire chi ha fatto cosa, quando e perché), sicurezza e governance.
In altre parole: se gli agenti “fanno”, il vero vantaggio competitivo si sposta su ciò che li rende controllabili e verificabili.
È qui che l’ondata di fusioni e acquisizioni cambia natura e diventa coerente con la premessa: se il valore dell’AI dipende da fondazioni (dati, integrazione, sicurezza, osservabilità) che richiedono tempo, competenze e massa critica, allora l’M&A diventa una scorciatoia industriale per comprare tempo e incorporare capacità già mature.
I casi
- I casi recenti sono indicativi (con status diversi: accordi, intenti, acquisizioni completate): ServiceNow ha annunciato l’accordo per acquisire Armis per circa 7,75 miliardi di dollari in contanti, con chiusura prevista nella seconda metà del 2026 [ServiceNow, 23 dic 2025; Reuters, 23 dic 2025].
- Workday ha annunciato di aver acquisito Flowise (strumenti per costruire agenti) e ha firmato un accordo definitivo per acquisire Pipedream (integrazione/automazione) [Workday, 14 ago 2025; Workday, 19 nov 2025].
- Salesforce ha comunicato di aver completato l’acquisizione di Informatica, enfatizzando proprio catalogo dati, integrazione, governance e metadati come fondazione per agenti AI in ambito enterprise [Salesforce, 18 nov 2025].
- Snowflake ha annunciato l’intento di acquisire Observe per portare capacità di osservabilità “AI-powered” a scala enterprise [Snowflake, 8 gen 2026].
Letti insieme, questi movimenti non sono semplici notizie: segnalano dove i fornitori stanno cercando di rafforzare il proprio “piano di controllo” sull’insieme di dati, integrazioni, sicurezza e monitoraggio che rende possibile orchestrare processi e decisioni in modo affidabile.
Qui sta un punto di attenzione che va trattato con rigore: questa corsa non implica automaticamente un peggioramento per i clienti. In molti casi, un’integrazione ben progettata può ridurre frammentazione, semplificare i controlli e accelerare risultati.
Ma lo stesso consolidamento può anche aumentare l’asimmetria nel tempo, perché concentra in un unico perimetro più dipendenze (dati + integrazioni + sicurezza + monitoraggio) e quindi rafforza la capacità del fornitore di incidere su prezzi, pacchetti e metriche di consumo.
Per un CIO, l’attività di M&A in atto va letta con attenzione: dove si concentra il controllo, lì tende a concentrarsi la negoziazione futura e quindi lì vanno rafforzate governance contrattuale e decisioni architetturali capaci di fornire scenari alternativi.
Broadcom-VMware: quando il cloud e software enterprise mostra il potere di mercato
Se serve un esempio per rendere tangibile il cambio di regime, il caso Broadcom-VMware è il più istruttivo.
Nei report legati a CISPE e all’European Cloud Competition Observatory vengono riportati aumenti di costo nell’ordine di 800%–1500% per alcuni clienti e partner, associati a riposizionamenti commerciali: passaggio a modelli in abbonamento, pacchetti più rigidi, vincoli pluriennali [ECCO/CISPE, maggio 2025; Heise, 23 mag 2025].
Su un piano istituzionale, CISPE ha portato la questione davanti al Tribunale dell’Unione Europea chiedendo l’annullamento della decisione della Commissione che aveva autorizzato la concentrazione; la traccia è pubblica su EUR-Lex e la vicenda è stata ripresa da Reuters [EUR-Lex, Case T-503/25; Reuters, 24 lug 2025; Reuters, 11 dic 2025].
Difficilmente si arriverà all’annullamento dell’acquisizione, ma più facilmente le autorità antitrust nazionali o la Commissione Europea potrebbero decidere di valutare se nella politica commerciale di Broadcom in relazione alla tecnologia VMware, stante il lock-in intrinseco e gli switching costs elevatissimi, si possa ravvisare un abuso di posizione di dominanza.
Quello che è certo è che si ha notizia dei primi contenziosi e altri seguiranno perché diverse imprese, soprattutto dimensionate, non hanno alcuna intenzione di sottostare senza reagire alle imposizioni unilaterali di Broadcom.
Asimmetria contrattuale, che possono fare i CIO
Perché questo caso è veramente indicativo? Perché mostra la meccanica che interessa davvero un CIO: i costi di cambiamento (tecnici, organizzativi, contrattuali) non sono una nozione teorica.
Sono una struttura economica che determina quanta libertà ha un’impresa nel negoziare. La letteratura economica lo spiega da tempo: quando i costi di cambiamento sono elevati, un fornitore può razionalmente scegliere tra investire per acquisire quota o “raccogliere” valore dalla base installata, perché il cliente catturato ha poche alternative reali nel breve periodo [Klemperer, Review of Economic Studies, 1995].
La traduzione per un decisore non tecnico è semplice: se un sistema è diventato infrastruttura di continuità (virtualizzazione, ERP, piattaforma dati, bus di integrazione), il cliente non sta più comprando solo software. Sta comprando la possibilità di non fermarsi.
E quando non puoi fermarti, la tua posizione negoziale cambia. Non è una questione morale (“fornitore buono/cattivo”), è una questione di incentivi e struttura di mercato.
Si deve anche considerare che se la politica commerciale di Broadcom non dovesse trovare ostacoli o se addirittura venisse considerata legittima in sede antitrust o dai giudici ordinari, tutti i fornitori che sul mercato sanno di avere una posizione di forza, stante la difficoltà per i clienti di sostituire la loro tecnologia in tempi brevi e a costi ragionevoli, potranno seguire la strada di Broadcom con un aumento vertiginoso dei prezzi sul mercato, potenzialmente insostenibili per moltissime aziende e pubbliche amministrazioni.
Dal possesso all’abbonamento nel cloud e software enterprise
Nel software enterprise si sta consolidando un passaggio che molti continuano a considerare un dettaglio commerciale, ma che in realtà è strutturale: si passa da asset posseduti a diritto d’uso.
Questo vuol dire che asset fondamentali come gli ERP non sono più elementi organici alla organizzazione aziendale. Sono invece oggetti di terzi su cui i clienti hanno un diritto d’uso temporaneo caratterizzati da lock-in tecnologici elevatissimi e da switching costs insostenibili.
Questo spostamento cambia tre elementi chiave, tutti strategici.
- Prima di tutto cambia l’orizzonte temporale del rischio: il rischio non è (solo) nel progetto di trasformazione iniziale, ma nella traiettoria dei rinnovi e delle ridefinizioni dei prezzi lungo l’intero ciclo di vita.
- In secondo luogo, cambia la dipendenza contrattuale ed economica: ciò che si acquista è continuità operativa e, nei fatti, spesso non è realisticamente possibile “non rinnovare” senza impatti gravi sul business se non a costi e con tempi tipicamente insostenibili.
- Infine, cambia la natura dell’offerta stessa, perché diventa più frequente il riconfezionamento: la stessa capacità può essere riproposta nel tempo sotto forma di edizione diversa, pacchetto diverso o metrica diversa, con conseguenze economiche significative anche a parità di “nome” del servizio.
Il regolatore europeo su asimmetria contrattuale cloud
Qui si innesta un segnale istituzionale che vale più di molte opinioni: la Commissione Europea ha aperto un’indagine formale su SAP e ha avviato un “market test” sugli impegni proposti, in un perimetro che riguarda manutenzione e supporto e quindi, in sostanza, la libertà del cliente di scegliere come gestire sistemi critici [Commissione Europea, 13 nov 2025; Reuters, 6 nov 2025; Reuters, 14 nov 2025].
Senza entrare nel merito di attribuire colpe o anticipare esiti, è rilevante che il regolatore europeo dica, con un atto formale, che i contratti sui sistemi core possono generare asimmetrie tali da giustificare una analisi sotto il profilo dell’abuso di posizione di dominanza.
Le pratiche commerciali sottoposte a valutazione, infatti, sono tutte relative a importi economici su cui la Commissione Europea vuole capire se si tratti di costrizioni ingiustificate, che i clienti non possono rifiutare, o se invece siano politiche ammissibili.
È chiave considerare che, se anche il procedimento valutativo riguarda SAP, di fatto tutto il mercato sarà impattato dalla decisione che verrà adottata. Quello che è sicuro è che se fino ad oggi le software house e i cloud provider non hanno mai avuto reale timore di una ingerenza delle autorità nelle proprie politiche commerciali, oggi sanno che può accadere.
A questo punto, va però fatta una precisazione importante: la regolazione è fondamentale, ma richiede tempo.
In uno scenario globale frammentato e sempre più conflittuale, l’impresa non può aspettare la “soluzione esterna”. Deve agire già ora sul piano operativo, con disciplina e tempestività.
Sovranità digitale nel cloud e software enterprise
Il dibattito sulla sovranità viene spesso ridotto a una mappa: data center in un Paese o in un altro. È rassicurante, ma incompleto.
Il caso OVHcloud, in cui un tribunale in Ontario ha emesso un ordine di produzione relativo a dati conservati anche su server fuori dal Canada, è diventato emblematico proprio perché mostra che la sovranità non coincide automaticamente con la geografia [Heise, 26 nov 2025; The Register, 27 nov 2025].
Il caso ha evidenziato, qualora fosse ancora necessario, che il cloud è un fenomeno industriale globale e la domanda fondamentale non è chiedersi dove risieda il data center che ospita i dati, ma quale entità è considerata in grado di controllare i dati e quali obblighi legali possono essere imposti lungo la catena societaria e operativa.
Questo è ancora più vero quando parliamo di dati personali. Qui la scelta non è “ideologica” né demandabile a una generica accettazione del rischio: è una verifica concreta di controllo effettivo, catena dei subfornitori, trasferimenti e capacità di resistere (o reagire) a ordini di accesso e conflitti di legge.
Se, dopo misure tecniche e contrattuali, resta un rischio non ragionevolmente mitigabile per i diritti degli interessati, la risposta corretta non è “accettarlo”, ma ridisegnare: segmentare i dati, cambiare perimetro, ridurre dipendenze e riportare sotto controllo i punti più sensibili.
Su questo fronte, è utile ricordare che esistono anche tentativi di fissare principi condivisi: l’OCSE ha adottato una dichiarazione con principi sul governo dell’accesso ai dati personali detenuti dal settore privato (trasparenza, salvaguardie, ricorsi, proporzionalità) [OECD, 14 dic 2022].
Questi principi non eliminano i conflitti di legge, ma aiutano a capire il criterio: quando le giurisdizioni si sovrappongono, la risposta non è un singolo requisito (“i dati stanno in Europa”), ma una combinazione di architettura, contratto, governance e procedure.
E qui entra un ulteriore elemento che i CIO europei non possono ignorare: dal 12 settembre 2025 è entrato in applicazione il Data Act, che include regole volte a ridurre barriere tecniche e contrattuali al cambio di fornitore per servizi cloud e di trattamento dati [Commissione Europea – Data Act explained].
Inoltre, alcune analisi evidenziano la traiettoria verso l’eliminazione delle spese di cambio fornitore entro il 12 gennaio 2027 secondo l’interpretazione dell’articolato sul tema [Deloitte, 12 set 2025].
Queste misure sono importanti, ma non sostituiscono il lavoro interno: anche con regole migliori, uscire resta un’operazione complessa se l’architettura e i processi sono stati progettati per dipendere da un singolo perimetro.
In altre parole: la norma può ridurre attriti, ma non può progettare al posto nostro.
Ma la domanda da farsi oggi è se la localizzazione geografica di dati, applicazioni e infrastrutture sia il tema più rilevante da affrontare o se invece il controllo sulle tecnologie, in un contesto geopolitico in evoluzione, sia il reale rischio ICT che oggi imprese e pubbliche amministrazioni devono valutare.
Certo, può preoccupare un Giudice canadese che chiede, nell’ambito di un procedimento penale, dei dati detenuti in un server.
Ma quanto preoccupa un fornitore strategico, o un suo sub-fornitore decisivo per la erogazione dei servizi, che è di casa madre estera e che alla scadenza di un contratto, con un sistema o un servizio insostituibile nel breve termine, moltiplica i corrispettivi senza alcuna possibile negoziazione?
Il CIO davanti al cloud e software enterprise: progettare opzioni
Quando il software diventa servizio e il servizio diventa infrastruttura critica, la disciplina del CIO deve spostarsi da “selezione tecnologica” a progettazione di opzioni.
Non basta scegliere bene oggi: serve costruire la capacità di scegliere anche domani. Per farlo, tre leve vanno trattate come un sistema unico, non come tre iniziative separate.
Governance contrattuale: controllo dei dati e continuità operativa
Molte organizzazioni dicono “i dati sono nostri”. È un principio, non una garanzia.
Per renderlo vero servono clausole e operatività che rendano esplicito: chi può accedere ai dati e in quali condizioni; chi decide su subfornitori e trasferimenti; quali sono condizioni di audit, trasparenza e notifica; cosa succede in caso di richieste delle Autorità, contenziosi e conflitti di legge.
E soprattutto: cosa significa portabilità in termini pratici, cioè poter uscire con dati e processi senza perdere continuità: formati, tempi, assistenza, costi.
Inoltre: quali informazioni e obblighi operativi il fornitore garantisce per la gestione dei dati personali (catena subfornitori, logging accessi, tempi di risposta, supporto a valutazioni e audit) e quali condizioni rendono sostenibile il trasferimento extra-UE (strumenti/garanzie, misure supplementari, diritto di sospensione + exit assistita).
Qui non c’è ideologia: il contratto è un componente dell’architettura. Lo è ancora di più nei settori regolati, dove linee guida e vigilanza spingono verso piani di uscita e gestione del rischio di terze parti come requisito di resilienza operativa [ECB, “Guide on outsourcing cloud services…”, luglio 2025].
Il problema che si pone è che i contratti con i cloud provider e i grandi fornitori di tecnologia sono sostanzialmente innegoziabili e quindi serve assolutamente che il legislatore e le autorità intervengano per riequilibrare il mercato imponendo contenuti contrattuali tassativi e inequivoci e possibilmente coerenti con una logica rispettosa di entrambe le parti contrattuali.
Architetture evolutive: ridurre dipendenze e concentrazione di potere
Questo è il punto a me più caro: il modo più efficace per non rimanere prigionieri della strategia dei fornitori non è “non usare i grandi fornitori” (spesso impossibile), ma evitare che una scelta diventi irreversibile.
Significa progettare architetture evolutive: architetture che cambiano nel tempo senza perdere governo, perché mantengono separati i punti di controllo e rendono praticabile un cambio di traiettoria.
Un’architettura evolutiva è come una filiera industriale progettata per sostituire un componente senza fermare l’impianto: non elimina la dipendenza (che nei sistemi enterprise spesso è inevitabile), ma la rende governabile.
Il punto centrale è evitare che un singolo fornitore concentri, senza contromisure, tutti i “punti di controllo” dell’organizzazione: identità, chiavi crittografiche, dati e ambiente di esecuzione.
Quando questi elementi finiscono nello stesso perimetro, la dipendenza smette di essere una scelta tecnica e diventa una condizione strutturale.
Per questo, dove possibile, l’impresa deve preservare un governo diretto, o almeno separato, delle chiavi e delle politiche di accesso: non come dettaglio di sicurezza, ma come leva di autonomia.
Allo stesso modo, serve costruire una modularità reale, basata su integrazioni e scambio dati governati, che non siano “cablati” nelle tecnologie di un unico ecosistema.
Se l’integrazione è proprietaria o opaca, ogni evoluzione futura diventa un progetto straordinario e ogni negoziazione contrattuale si sbilancia ulteriormente.
In un’architettura evolutiva, infine, l’uscita non è un documento che rassicura: è un percorso credibile, testato, con tempi e soglie realistici, perché solo ciò che è provato riduce davvero il rischio.
E tutto questo converge in un obiettivo pratico: ridurre il raggio di impatto. Progettare in modo che un cambio contrattuale, una variazione di metrica, o una discontinuità di servizio non producano un effetto domino sull’intera impresa, ma restino confinati.
Questo approccio è coerente con l’obiettivo di interoperabilità e portabilità indicato da anni in ambito standard e linee guida sul cloud [NIST, SP 500-291r2]. È coerente con il Data Act [Commissione Europea – Data Act explained]. Ed è coerente con ciò che i regolatori chiedono in termini di resilienza e piani di uscita per funzioni critiche [ECB, “Guide on outsourcing cloud services…”, luglio 2025].
Competenze e metodo: senza governance operativa anche il disegno fallisce
Il terzo pilastro è il più sottovalutato: oggi molte organizzazioni non hanno competenze adeguate per governare questo scenario.
Servono capacità che stanno a cavallo tra tecnologia, diritto, finanza e rischio operativo, perché il problema non è “solo” scegliere una piattaforma, ma saperne governare il ciclo di vita.
Questo significa avere un procurement strategico capace di negoziare contratti con alfabetizzazione tecnica, traducendo requisiti di controllo in clausole verificabili e misurabili.
Significa anche disporre di competenze robuste di architettura e modernizzazione applicativa, per progettare disaccoppiamenti, migrazioni progressive e componenti sostituibili, evitando che ogni evoluzione diventi un progetto eccezionale.
A queste si aggiunge la governance dei dati, intesa come qualità, tracciabilità e policy: perché l’AI vive sui dati e fallisce sui dati, e senza disciplina informativa qualsiasi promessa di automazione si trasforma in rischio.
Serve poi una gestione matura del rischio di terze parti, basata su controllo continuo e capacità di intervento, non su audit episodici che arrivano quando il rischio si è già manifestato.
Infine, occorrono competenze specifiche su AI e sicurezza operativa, non per inseguire l’etichetta “AI”, ma per costruire controlli, responsabilità e tracciabilità su sistemi che possono prendere decisioni ed eseguire azioni.
Per rendere questa parte davvero eseguibile, serve anche un principio organizzativo: assegnare ownership chiara.
In molte imprese funziona bene formalizzare (anche senza creare nuove “torri”) tre responsabilità trasversali: Contract & Vendor Architecture (contratti come componente dell’architettura), Exit & Resilience (piani di uscita e continuità sui sistemi core), AI Governance & Controls (policy, logging, audit e responsabilità sugli agenti). Senza ownership, la complessità non sparisce: cambia solo forma.
AI e autonomia applicativa: cosa riapre nel cloud e software enterprise
C’è una dinamica che sta cambiando la modernizzazione applicativa, ma va descritta con prudenza: l’AI sta mettendo sotto pressione anche il modello SaaS tradizionale.
Non perché il SaaS “finisca” o perda improvvisamente senso, anzi continuerà a essere la scelta naturale per moltissimi domini, ma perché l’AI sta rendendo potenzialmente più rapido ed economico costruire componenti software, automazioni e funzioni che fino a ieri richiedevano tempi lunghi e grandi team.
È un “potenzialmente” importante: i casi d’uso maturi sono ancora relativamente pochi e la variabilità dei risultati è alta.
Ma il segnale è chiaro: per alcune aree del portafoglio sta riemergendo l’interesse a riappropriarsi di pezzi costruendo componenti su misura in ambienti controllati, con dati e capacità di automazione sotto governo diretto.
Non è nostalgia dell’on-premise: è una strategia di autonomia decisionale, per ridurre le irreversibilità e recuperare margini di scelta nel tempo.
Detto in modo ancora più esplicito: questa non è una chiamata a “rifare tutto in casa”. È un invito a ragionare per portafoglio e per opzioni.
In un portafoglio applicativo maturo ci sono componenti che ha senso acquistare perché beneficiano di scala, supporto e aggiornamenti continui; componenti che ha senso sviluppare perché sono differenzianti o perché riducono dipendenze critiche.
E soprattutto componenti che ha senso mantenere sostituibili, cioè progettati per poter cambiare traiettoria senza traumi.
In questo quadro, l’AI può diventare una leva utile non tanto per “aggiungere un’interfaccia conversazionale”, quanto per accelerare la costruzione di quei “mattoni” controllabili che rendono l’architettura più evolutiva.
Ma è essenziale non confondere velocità con maturità: la trasformazione agentica è agli inizi, il valore vero deve ancora dispiegarsi in modo sistematico e realisticamente serviranno anni perché pratiche, strumenti, standard e responsabilità operative raggiungano una maturità paragonabile a quella del software enterprise tradizionale.
Proprio per questo è un fenomeno prospettico che non va né idolatrato né sottovalutato: va considerato nelle scelte di oggi, perché le scelte architetturali e contrattuali fatte ora determineranno quanto sarà possibile adottarlo domani in modo sicuro.
Qui entra il punto delicato: quando si parla di AI “agentica”, cioè di sistemi che non si limitano a suggerire, ma possono eseguire azioni, il rischio cresce più velocemente del valore se non esistono presidi.
Un’adozione realmente governata non si misura dalla presenza di un “assistente” in più, ma dalla capacità dell’impresa di definire chi decide cosa l’agente può fare e con quali limiti.
E di garantire tracciabilità: ogni azione rilevante deve essere registrata e ricostruibile, mantenendo il controllo dei dati e delle integrazioni che alimentano quelle azioni.
In assenza di questi tre pilastri, l’agente non è uno strumento di efficienza: è una nuova superficie di rischio e spesso una nuova forma di dipendenza.
Se invece policy, log e controllo dei dati restano in casa, o comunque sotto un controllo contrattuale forte e verificabile, allora l’AI può diventare una leva di autonomia: non perché elimina il lock-in, ma perché consente di sviluppare componenti chiave senza cedere interamente il governo a un perimetro esterno.
Dentro questa stessa dinamica si innesta un fenomeno correlato, già visibile sul campo e che merita attenzione proprio per i suoi effetti collaterali: l’AI sta abbassando la barriera tra “chi usa” e “chi costruisce”.
In molte aziende, funzioni non tecniche riescono a prototipare in tempi rapidi workflow e piccoli strumenti che fino a ieri avrebbero richiesto mesi di sviluppo.
Questo è un vantaggio competitivo reale: permette di sperimentare, chiarire bisogni, arrivare ai vendor con requisiti più maturi e spesso negoziare meglio.
Ma apre anche un rischio strutturale: la prototipazione non governata può diventare shadow IT, con dati che transitano dove non dovrebbero, logiche di business non versionate, controlli assenti e dipendenze non dichiarate.
La risposta non è vietare, perché sarebbe perdere la leva. La risposta è incanalare: creare un perimetro sicuro, definire regole minime e rendere “facile fare la cosa giusta”, così che la nuova capacità di costruire diventi modernizzazione governata e non scorciatoia fuori controllo.
In altre parole: se l’AI democratizza la capacità di costruire, l’impresa deve democratizzare, con metodo, anche la capacità di governare.
Dal quadro al piano operativo per cloud e software enterprise
Queste domande non sono un esercizio teorico: sono la diagnosi che consente di costruire un piano credibile e, soprattutto, ripetibile.
Le propongo in tre ambiti, perché il punto non è “capire se va tutto bene”, ma rendere misurabili le aree in cui, tipicamente, nasce l’asimmetria.
Il primo ambito è la governance contrattuale. Qui le domande sono dirette: abbiamo chiari i rischi sottesi alla fornitura anche in relazione alla continuità del servizio e di linearità del prezzo soprattutto in caso di way out anticipate e scadenze?
Abbiamo definito in modo non ambiguo cosa significa controllo (accessi, subfornitori, audit, notifiche)?
La portabilità è verificabile, cioè descritta in formati, tempi, assistenza e costi? Continuità e transizione sono coperte da condizioni realistiche e non da formule di principio (“best effort”)?
Esistono clausole operative per gestire richieste delle Autorità, contenziosi e conflitti di legge, senza improvvisazione?
Abbiamo valutato lock-in e switching costs? Quali sono le alternative in caso di discontinuità?
Quanto i nostri fornitori dipendono da potenze straniere e quanto da potenze extra europee?
Il secondo ambito riguarda le scelte architetturali e, in particolare, le architetture evolutive. Qui la domanda chiave è: qual è, per ciascun sistema critico, il nostro punto di non ritorno nell’orizzonte dei prossimi 24 mesi?
Subito dopo viene la mappa del potere: dove sono concentrati i punti di controllo quali identità, chiavi, dati, integrazioni, ambiente di esecuzione?
Abbiamo un piano di uscita testato, non soltanto scritto, per le funzioni realmente critiche? E abbiamo ridotto il “raggio di impatto” di un cambio di fornitore, di metrica o di condizioni, oppure basta una variazione contrattuale per produrre effetti a cascata?
Il terzo ambito è quello delle competenze, del governo e dell’AI. Chi ha accountability reale su contratti digitali, terze parti e piani di uscita?
Abbiamo competenze interne su modernizzazione applicativa e integrazione governata, oppure dipendiamo totalmente da perimetri esterni?
Per l’AI, le nostre policy e i nostri meccanismi di tracciabilità e auditabilità sono adeguati anche nel caso di sistemi che “fanno”, non solo che “rispondono”?
E, soprattutto, misuriamo costo e rischio nel ciclo di vita collegandoli alle scelte architetturali e contrattuali, oppure ci accorgiamo del problema solo quando arriva al rinnovo?
Sono stati posti in essere stress test sui fornitori di AI, soprattutto se di piccole dimensioni?
È calcolato l’impatto potenziale sui processi in caso di discontinuità, default o rischi geopolitici?
Infine, per i dati personali: abbiamo un perimetro con garanzie effettive e dimostrabili (misure tecniche, controlli, subfornitori, trasferimenti)? E il rischio residuo sui diritti e le libertà è davvero mitigato?
Dalle risposte discende un piano, in fasi molto concrete. Si parte mappando pochi sistemi davvero critici, quelli che impattano la continuità, e misurando i costi di cambiamento (tecnici, organizzativi, contrattuali) per capire dove si concentra il potere.
Poi si rinegoziano in modo mirato poche clausole “non negoziabili” sui sistemi core (accessi, subfornitori, audit/notifiche, portabilità, supporto all’uscita).
In parallelo si disegna l’architettura evolutiva: separazione dei piani di controllo, integrazioni governate, riduzione della concentrazione di dipendenza, limiti al raggio di impatto.
Su questa base si modernizza per componenti, decidendo cosa comprare, cosa costruire e cosa mantenere sostituibile; e, con cautela, si sperimentano capacità agentiche in modo governato su processi delimitati, con policy, logging, audit e controllo dei dati.
Così da usare l’AI come leva di autonomia e non come nuova dipendenza.
Il punto decisivo non è fare questo una volta. È trasformarlo in un ciclo stabile di governo: misura, clausole, architettura, competenze, verifica.
Quando lo fai, l’asimmetria non scompare, ma smette di essere un destino e diventa una variabile gestibile.
Conclusione: cloud e software enterprise come strategia industriale
Non siamo alla fine del cloud (anzi, forse siamo alla fine dell’on-premise visto che moltissime software house stanno abbandonando il software on-premise), ma in un momento evolutivo.
Siamo alla fine dell’idea che basti “spostare tutto” per risolvere complessità e rischio.
Cloud e software enterprise sono diventati il luogo dove si concentrano potere di mercato, asimmetria contrattuale e, in alcuni casi, tensione tra giurisdizioni [EUR-Lex, Case T-503/25; Commissione Europea, 13 nov 2025; Heise, 26 nov 2025].
In questo scenario, la domanda chiave è quale libertà preservare nel tempo: perché quando l’IT è infrastruttura industriale, la vera fragilità non è l’inefficienza, è l’irreversibilità.
Per questo la strategia IT deve evolvere verso una strategia industriale fondata su tre assi.
- Il primo è l’architettura come riduzione del rischio: modularità e architetture evolutive non sono un esercizio di stile, sono assicurazioni contro shock contrattuali e cambi di perimetro dei fornitori.
- Il secondo è il procurement come disciplina strategica: il contratto non è un allegato legale, è parte del sistema e ne determina continuità, portabilità e potere negoziale.
- La capacità di valutare i rischi, il lock-in, gli switching costs, le roadmap dei fornitori è essenziale.
- Il terzo è il portafoglio come opzioni nel tempo: non si tratta di evitare i grandi vendor, ma di evitare che una scelta diventi irreversibile senza condizioni e senza un’uscita praticabile.
La regolazione è necessaria e arriverà, ma le imprese non possono delegare a essa la propria autonomia.
Devono agire ora sul piano operativo: contratti verificabili, architetture progettate per evolvere, competenze per governare rischio, dati e automazione.
Il vero obiettivo, oggi, è preservare una cosa sola: la capacità di decidere domani.
Riferimenti
Commissione Europea, “Commission seeks feedback on commitments offered by SAP”, 13 novembre 2025.
EUR-Lex, “Action brought on 23 July 2025 – CISPE v Commission”, Case T-503/25 (Broadcom/VMware).
Reuters, copertura sul ricorso CISPE contro l’autorizzazione UE Broadcom/VMware, 24 luglio 2025 e 11 dicembre 2025.
ECCO/CISPE, report su Broadcom/VMware con evidenze su aumenti di costo (maggio 2025).
ServiceNow, press release “ServiceNow to acquire Armis…”, 23 dicembre 2025.
Workday, press release “Workday Acquires Flowise…”, 14 agosto 2025; e “Workday Signs Definitive Agreement to Acquire Pipedream”, 19 novembre 2025.
Salesforce, press release “Salesforce Completes Acquisition of Informatica”, 18 novembre 2025.
Snowflake, press release “Snowflake Announces Intent to Acquire Observe…”, 8 gennaio 2026.
Heise, articolo sul caso OVHcloud e ordine canadese, 26 novembre 2025; The Register, 27 novembre 2025.
OECD, “Declaration on Government Access to Personal Data Held by Private Sector Entities”, 14 dicembre 2022.
Commissione Europea, “Data Act explained” (applicazione dal 12 settembre 2025).
Deloitte, analisi su cloud switching e Data Act, 12 settembre 2025.
ECB, “Guide on outsourcing cloud services…”, luglio 2025.
NIST, SP 500-291r2 (cloud standards roadmap; interoperabilità e portabilità).
Klemperer, P. (1995), “Competition when Consumers have Switching Costs…”, Review of Economic Studies.
Shapiro, C. & Varian, H. (1999), Information Rules, Harvard Business School Press.
