Per anni abbiamo trattato il confronto tra Cloud e On-Premise come una scelta tecnologica, ponendo l’attenzione su aspetti quali la localizzazione, le piattaforme di hyperscaling, database, backup.
Nel 2026 la domanda che un’azienda dovrebbe porsi è:
Quale parte del mio rischio voglio possedere direttamente, quale voglio trasferire a un fornitore e, soprattutto, quale dipendenza sono disposto a rendere irreversibile?
Per me, oggi, il vero spartiacque è chi controlla piattaforma, roadmap, identità, dati, capacità di intervento ed uscita. Negli ultimi mesi questo è diventato molto più evidente.
Il Data Act europeo ha reso portabilità, switching e interoperabilità del cloud un tema regolatorio esplicito; DORA tratta ormai il rischio di concentrazione sui fornitori ICT come un rischio operativo vero; ENISA sottolinea l’aumento degli attacchi alle dipendenze e alla supply chain digitale. E la stessa Commissione, nel 2026, rileva che oltre il 70% del mercato cloud europeo è controllato da tre hyperscaler non UE, ponendo apertamente il tema della dipendenza strategica.
Il Cloud ha portato vantaggi enormi e difficili da contestare:
In particolare, nei contesti dove la differenza competitiva conta, l’effetto positivo del cosiddetto “time-to-capability”, ovvero la velocità di introdurre nuove capacità, posiziona il software SaaS come scelta prioritaria, se non naturale, rispetto ad una soluzione On-Premise che, per accrescere di funzionalità, può richiedere mesi o anni, per causa delle tante componenti frammentate (release, database, SO, personalizzazioni, etc.)
Con l’AI il divario tra i due modelli aumenta.
Dal 2 agosto 2026 sono diventati applicabili ulteriori obblighi dell’AI Act, inclusi obblighi di trasparenza per diversi sistemi AI e poteri di enforcement della Commissione sui GPAI. Questo significa anche che modelli, controlli, tracciabilità e componenti AI cambieranno rapidamente.
Per un vendor software mantenere tutto questo contemporaneamente su decine di installazioni On-Premise diventerà sempre meno conveniente.
E quindi qual è il vero punto da considerare?
Nel Cloud trasferiamo potere operativo al fornitore che controlla:
E questi fattori spesso sono concentrati in punti a poco o a zero visibilità per il cliente.
Nel Cloud posso non avere alcun problema infrastrutturale e, contemporaneamente, trovarmi in una condizione di forte dipendenza operativa:
Il sistema continua a funzionare ma io ho progressivamente perso la capacità di intervenire, con una percezione prevalente di inibizione all’azione.
Più che di generico “vendor lock-in”, preferisco distinguere e valutare la dipendenza in base alla componente impattata: dati, tecnologia, operatività, investimento.
Il “data lock-in” è probabilmente destinato a diminuire. Il Data Act, applicabile dal settembre 2025, impone regole proprio per facilitare il passaggio fra provider di data-processing services e ridurre le barriere allo switching. La Commissione UE sta anche lavorando agli standard di interoperabilità previsti dal regolamento.
Se il legislatore impone facilità nella portabilità e nelle modalità di uscita, posso quindi esportare dati, perdendo al tempo workflow, automazioni, logiche, mappature, conoscenza, storico comportamentale, personalizzazioni ed integrazioni che hanno un grande impatto sull'operatività. Perché di fatto l’azienda costruisce i processi attorno, sul e nel software SaaS.
Per questo preferisco parlare di agency (o agentività), cioè della capacità dell'azienda di agire autonomamente sul proprio sistema informativo ed in particolare sui sistemi che orchestrano processi.
Rispetto alla mia responsabilità di non perdere la possibilità di scelta e di controllo, di fronte ad una scelta Cloud vs On-Premise, ci sono 5 domande che considero fondamentali.
Se qualcosa non funziona, fino a dove posso arrivare?
In un ambiente On-Premise normalmente posso:
Nel SaaS questo livello di accesso spesso non esiste. Ed è giusto che sia così: fa parte del modello.
Ma significa anche accettare che, in determinate situazioni, il problema non sia più:
“Sappiamo risolverlo?”
ma:
“Il vendor è disposto e in grado di risolverlo nei tempi che servono a noi?”
Sono due rischi molto diversi.
Quando adottiamo una piattaforma Cloud, adottiamo implicitamente anche la visione del produttore.
Se il vendor decide che:
la nostra capacità di influenzare questa decisione può essere minima.
Per questo una piattaforma non dovrebbe essere valutata soltanto per quello che fa oggi.
Bisogna capire anche:
L'identità è ormai il vero perimetro di sicurezza dell'azienda. Accesso, ruoli, privilegi, service account, API, autenticazione machine-to-machine: tutto passa da lì. Una buona architettura dovrebbe evitare che ogni applicazione diventi una piccola isola proprietaria.
L'identità dovrebbe restare sotto il controllo dell'organizzazione, attraverso strumenti e standard coerenti.
Più il sistema dipende da utenti, credenziali e meccanismi proprietari del vendor, maggiore sarà il costo futuro della sostituzione.
È relativamente semplice esportare: utenti, ticket, asset, CI, anagrafiche, documenti.
Come posto sopra, è più il lock-in operativo a destare per me attenzione. Non dipendiamo dal software in sé, bensì dal modello operativo che abbiamo costruito dentro quel software.
Cambiare un software, significa riprogettare i processi, i flussi di lavoro, le automazioni, le regole, le configurazioni.
Ed è proprio qui che le aziende dovrebbero concentrare la governance architetturale.
Questa è probabilmente la domanda più importante di tutte. Ogni volta che adottiamo una piattaforma dovremmo sapere, già all'ingresso, come potremmo uscirne. Non perché vogliamo necessariamente farlo. Ma perché la possibilità di uscire determina il nostro potere negoziale.
Mi farei sempre queste domande e le porterei al tavolo di progettazione della soluzione:
Un hyperscaler o un grande vendor SaaS dispone normalmente di capacità superiori alla maggior parte delle aziende su sicurezza, patching, ridondanza, monitoraggio, disaster recovery, protezione DDoSM, gestione delle vulnerabilità.
Con un effetto collaterale: il rischio diventa più concentrato. Se migliaia di organizzazioni dipendono dalle stesse componenti (cloud provider, identity provider, servizi di sicurezza, piattaforme SaaS, etc.), un singolo problema può produrre conseguenze enormi.
Avere il software installato nel proprio datacenter non significa necessariamente essere indipendenti.
Un ambiente On-Premise può dipendere da sistemi operativi, DB, hypervsor, hardware, backup, specialisti con competenze molto verticali
E qui compare un altro rischio spesso sottovalutato: quello delle competenze. Se soltanto una persona conosce davvero una piattaforma, quella persona è un single point of failure.
Quali sono i costi reali?
Il confronto economico non può essere ridotto semplicisticamente a: licenza Cloud vs licenza On-Premise.
Per l'On-Premise bisogna considerare anche:
Per il Cloud bisogna invece considerare:
La formula che preferisco è:
Total Cost of Ownership (TCO) + costo della complessità + costo dei failure + costo di uscita
Il calcolo va effettuato separatamente per Cloud e On-Premise, sullo stesso orizzonte temporale, in modo da confrontare il costo complessivo delle due alternative.
L'intelligenza artificiale spingerà inevitabilmente moltissime organizzazioni verso servizi Cloud.
Modelli, capacità computazionale, agenti AI, database vettoriali sono disponibili e immediatamente fruibili, con un vantaggio enorme.
Ma man mano che incorporiamo l'AI nei processi aziendali stiamo creando una nuova forma di dipendenza. Iniziamo a esternalizzare una parte della capacità decisionale e cognitiva dell'organizzazione.
Per questo architettura, governance e capacità di uscita saranno ancora più importanti nei prossimi anni.
Non credo abbia senso difendere ideologicamente un modello rispetto all'altro. Ci sono applicazioni per cui continuare a gestire l'infrastruttura internamente è semplicemente inefficiente. Ce ne sono altre in cui cedere capacità di intervento, personalizzazione o controllo sui dati rappresenta un rischio strategico ben maggiore del beneficio ottenuto.
In linea generale:
La decisione deve partire dal tipo di sistema: più una capability è core, più l'azienda deve mantenere la propria agency (la capacità di agire, scegliere ed eventualmente cambiare).
È in questa prospettiva di scelta consapevole e governata che considero efficace l'approccio di SysAid.
La disponibilità della piattaforma sia in Cloud sia On-Premise consente all’azienda di decidere liberamente quali responsabilità mantenere direttamente e quali trasferire al fornitore.
Mentre il Cloud garantisce la massima esperienza di utilizzo delle capacità AI con oltre 100 Agenti AI pronti e delle novità funzionali mensilmente rilasciate, la modalità On-Premise resta fruibile per chi necessita di elevate misure di riservatezza e di un livello di personalizzazione estremo.
A questa flessibilità, si affiancano elementi concreti di responsabilità: architettura aperta alle integrazioni, massima trasparenza sulle release, un canale diretto per proporre nuove funzionalità e certificazioni indipendenti a tutela della sicurezza e della compliance.
Vendor che tengono aggiornato il cliente sulla roadmap, considerano i casi d’uso reali e lo mettono nelle condizioni di conoscere e governare le dipendenze, anziché crearle deliberatamente, saranno i veri partner strategici nell'era dell'Intelligenza Artificiale.
Scegliere tra Cloud e On-Premise nel 2026 non significa schierarsi per una fazione tecnologica, ma dotarsi degli strumenti e dei modelli di governance necessari per guidare il cambiamento in modo consapevole, sicuro e orientato al valore sostenibile.