Sebastien Rousseau
Contattami ›

Cloud Native Banking in 2026: Kubernetes, DORA, Sovereignty, and the End of the VM vs Container Divide

Cloud native for banks has matured from container adoption to regulated platform engineering: Kubernetes, VM coexistence, data portability, DORA supervision, cloud dependency reviews, and operational resilience now define the architecture.

8 min di lettura

Banca cloud nativa nel 2026: Kubernetes, DORA, sovranità e la fine della divisione tra VM e container

La banca cloud nativa nel 2026 non è più un dibattito sulla possibilità per le banche di usare il cloud. È una disciplina regolamentata di ingegneria di piattaforma: come far funzionare servizi critici tra container, macchine virtuali, data fabric, carichi di lavoro di AI e fornitori cloud, dimostrando al tempo stesso resilienza operativa ai sensi del Digital Operational Resilience Act (DORA) e di regimi analoghi. IBM definisce il 2026 come il primo vero banco di prova della supervisione DORA, con revisioni delle dipendenze cloud, ispezioni di cybersecurity, test di penetrazione orientati alle minacce e supervisione diretta dei fornitori terzi critici (IBM).

Sintesi esecutiva / Punti chiave

  • DORA ha cambiato la conversazione sul cloud. Il 2026 porta la supervisione diretta dell'UE sui fornitori terzi critici e revisioni mirate delle dipendenze delle banche dai cloud service provider (IBM).
  • Kubernetes è il livello di piattaforma, non l'intera risposta. Le banche hanno bisogno di Kubernetes per elasticità, automazione e carichi di lavoro di AI/ML (intelligenza artificiale e machine learning), ma hanno anche bisogno della coesistenza con le VM (macchine virtuali) perché core banking, pagamenti, trading e sistemi di rischio continuano a girare su patrimoni virtualizzati e induriti (Red Hat).
  • La divisione tra VM e container si sta chiudendo. Red Hat posiziona OpenShift e Portworx come un modello unificato in cui VM e container condividono policy, dati, backup, disaster recovery e controlli di governance (Red Hat).
  • La sovranità cloud è ormai un vincolo progettuale. Le banche usano la sovranità per gestire controllo giurisdizionale, autonomia operativa, controllo delle chiavi, localizzazione dei dati e rischio di concentrazione cloud (Red Hat).
  • L'AI ha reso il cloud nativo urgente. Rilevamento frodi, analisi di liquidità, personalizzazione in tempo reale e reportistica regolamentare richiedono sempre più calcolo elastico in prossimità di dati sensibili (Red Hat).
  • La strategia di uscita (exit strategy) non è un PDF. Secondo le aspettative supervisive moderne, le banche hanno bisogno di portabilità testata, mappatura delle dipendenze, evidenza contrattuale, procedure di recupero e percorsi di migrazione realistici per le funzioni critiche.
  • L'obiettivo architetturale è il cloud nativo controllato. La piattaforma bancaria vincente offre agli sviluppatori una delivery self-service, mentre applica automaticamente audit, cifratura, residenza dei dati, test di resilienza, separazione dei compiti e controlli del rischio di terzi.

Perché il 2026 è l'anno della supervisione cloud-nativa #

Il DORA si applica da gennaio 2025, ma è nel 2026 che il muscolo supervisivo diventa visibile. IBM osserva che il primo elenco di Critical Third-Party Providers è stato designato a novembre 2025 e che il 2026 porta interazione diretta con le Autorità Europee di Vigilanza, revisioni contrattuali, ispezioni in loco e analisi delle dipendenze cloud (IBM).

Questo cambia l'onere della prova. Una banca non può più sostenere che un'interruzione cloud sia un semplice problema del fornitore. L'istituzione finanziaria resta responsabile della resilienza delle funzioni critiche, anche quando quelle funzioni dipendono da hyperscaler, fornitori SaaS (Software as a Service), piattaforme dati e servizi di sicurezza gestiti.

La baseline della banca cloud-nativa per il 2026 #

1. Kubernetes come livello operativo #

Kubernetes offre alle banche automazione del deployment, elasticità, enforcement delle policy, orchestrazione dei container e un'astrazione comune tra cloud privato, cloud pubblico e ambienti sovrani. Per i nuovi carichi di lavoro, in particolare rilevamento frodi guidato dall'AI, personalizzazione in tempo reale, analisi di liquidità e reportistica regolamentare, è diventato il control plane naturale (Red Hat).

L'errore è trattare Kubernetes come destinazione. Per le banche è il substrato sotto a una piattaforma per sviluppatori governata.

2. Convergenza tra VM e container #

La maggior parte delle banche non può riscrivere rapidamente il patrimonio core. Motori di pagamento, sistemi di trading, scoring del credito, modelli di rischio e piattaforme core banking continuano a dipendere da patrimoni VM induriti. Red Hat sostiene che le banche hanno bisogno di una piattaforma unificata in cui VM e container possano operare insieme, riducendo l'architettura duplicata e allineando i controlli di policy, storage, backup e recupero (Red Hat).

È il ponte pratico tra resilienza legacy e velocità cloud-nativa. Consente alle banche di spostare per primi i servizi adiacenti, co-localizzare i workload di AI dipendenti dai dati ed evitare di forzare riscritture fragili nei sistemi critici.

3. Resilienza operativa pronta per DORA #

IBM indica che le priorità supervisive 2026 includono il follow-up sulle carenze di sicurezza ICT (Information and Communication Technology) e outsourcing, ispezioni in loco su cybersecurity e rischio di terzi, test di penetrazione orientati alle minacce, revisioni del change management ICT e analisi delle dipendenze cloud (IBM).

Significa che la resilienza deve essere verificabile. I diagrammi architetturali non bastano. Le banche hanno bisogno di evidenza derivante da esercitazioni di failover, simulazioni di incidente, ripristini da backup, mappe di dipendenza, test del tempo di recupero e flussi di governance.

4. La sovranità come capacità di piattaforma #

La sovranità cloud non è solo residenza dei dati. Include controllo legale, controllo operativo, controllo delle chiavi di cifratura, giurisdizione del personale di supporto, collocazione dei workload e la capacità di proseguire i servizi critici se un fornitore globale o un processo geopolitico crea disservizio. Red Hat inquadra la sovranità come controllo giurisdizionale e autonomia operativa per le banche che affrontano regolamenti divergenti come GDPR (General Data Protection Regulation), DORA e regole cloud nazionali (Red Hat).

L'implicazione cloud-nativa è che routing dei workload, gestione dei segreti, controllo delle chiavi, classificazione dei dati ed enforcement delle policy devono essere programmabili.

Lo stack di piattaforma bancaria #

Livello di esperienza per gli sviluppatori #

Una piattaforma cloud-nativa di grado bancario deve esporre paved road: golden path, template, cataloghi di servizi, pipeline di deployment automatizzate, default di osservabilità, policy-as-code, integrazione standard dei segreti e percorsi dati approvati. Gli sviluppatori non dovrebbero negoziare con ogni control owner per ogni rilascio.

La piattaforma deve rendere il percorso conforme il percorso più veloce. È l'unico modello che scala su migliaia di servizi.

Livello di controllo #

Il livello di controllo comprende identità, gestione degli accessi, separazione dei compiti, cifratura, custodia delle chiavi, policy di rete, firma delle immagini, software bill of materials, vulnerability gate, sicurezza runtime, logging e generazione di evidenza. È il luogo in cui DORA, NIS2 (Network and Information Security Directive 2), GDPR, regole di esternalizzazione (outsourcing) e policy interne di model risk diventano controlli eseguibili.

È qui che molte banche falliscono. Adottano i container ma lasciano i controlli come approvazioni manuali fuori dalla piattaforma.

Livello dati #

I carichi di lavoro stateful sono la parte più difficile della banca cloud-nativa. L'argomento di convergenza VM/container di Red Hat dipende fortemente da un data fabric unificato e da backup, replica, failover e recupero guidati da policy attraverso VM e container (Red Hat).

Per le banche, il livello dati deve rispondere a tre domande: dove si trovano i dati, chi controlla le chiavi e come si riprende il servizio se l'infrastruttura cade?

Tabella architetturale: cloud nativo per le banche #

Capacità Pattern cloud-nativo Requisito di controllo bancario Modalità di fallimento
Application delivery Kubernetes, GitOps, template Separazione dei compiti, evidenza del cambiamento, rollback Rilasci veloci ma non auditabili
Coesistenza legacy Piattaforma unificata VM/container Coerenza delle policy e controllo della migrazione Doppi patrimoni con rischio duplicato
Servizi dati Operator stateful e data fabric Residenza, backup, immutabilità, restore testato Piattaforma stateless con fragilità stateful
Resilienza Multi-zona, multi-regione, failover Evidenza DORA e mappatura delle funzioni critiche Interruzione cloud trattata come scusa del fornitore
Sovranità Collocazione dei workload basata su policy Evidenza giurisdizionale e di controllo delle chiavi Residenza senza autonomia operativa
Carichi di lavoro AI Calcolo elastico vicino ai dati Governance dei modelli, minimizzazione dei dati, audit Dati sensibili spostati su servizi AI non approvati

Cosa significa per tipo di istituzione #

Banche universali di prima fascia #

Le banche di prima fascia devono costruire piattaforme interne controllate su più cloud, con policy-as-code stringente, classificazione dei dati e collocazione dei workload. Hanno scala sufficiente a giustificare l'ingegneria di piattaforma e i regolatori si aspetteranno da loro evidenza più approfondita.

Banche di fascia intermedia #

Le banche di fascia intermedia devono standardizzare anziché personalizzare. Una solida piattaforma Kubernetes gestita, una selezione disciplinata dei fornitori cloud, strategie di uscita chiare e generazione automatizzata dell'evidenza valgono più di un'ambizione multi-cloud diffusa che l'istituzione non può operare.

Infrastrutture dei mercati finanziari #

Le FMI (Financial Market Infrastructures) hanno bisogno soprattutto della prova di resilienza. Devono trattare il cloud nativo come un modo per migliorare recupero, osservabilità e cambiamento controllato, non come una pura leva di velocità.

Fintech e PSP #

Le fintech e i PSP (Payment Service Providers) possono muoversi rapidamente, ma devono evitare di superare la capacità del proprio modello di controllo. Man mano che diventano sistemicamente rilevanti, arriveranno le stesse aspettative su resilienza, rischio di terzi, segnalazione degli incidenti e sovranità dei dati.

Conclusione #

La banca cloud nativa nel 2026 è un'architettura di governance. Kubernetes è essenziale, ma non è sufficiente. Le istituzioni che avranno successo faranno convergere VM e container dove necessario, useranno pattern cloud-nativi per i nuovi workload, dimostreranno resilienza ai sensi del DORA, controlleranno la sovranità dei dati al livello di piattaforma e renderanno la conformità automatica al punto da consentire agli sviluppatori di muoversi rapidamente senza creare rischio non governato.

Il vecchio dibattito riguardava se le banche potessero passare al cloud. Il nuovo dibattito riguarda se le banche possano rendere il cloud nativo sufficientemente sicuro, sufficientemente portabile e sufficientemente documentato per gestire i servizi che contano.

Domande frequenti #

Il DORA impedisce alle banche di usare il cloud?

No. Il DORA non vieta l'uso del cloud. Rende le istituzioni finanziarie responsabili del rischio ICT, della dipendenza da terzi, della segnalazione degli incidenti, dei test di resilienza e della governance dei servizi critici che si appoggiano a cloud e ad altri fornitori ICT (IBM).

Perché le banche hanno ancora bisogno delle VM se Kubernetes è il futuro?

Le banche continuano a far girare sistemi critici su patrimoni basati su VM, inclusi motori di pagamento, sistemi core banking, applicazioni di trading e piattaforme di rischio. Un modello unificato VM/container riduce la duplicazione consentendo una migrazione graduale (Red Hat).

Cos'è una vera strategia di uscita dal cloud?

Una vera strategia di uscita comprende inventario delle dipendenze, procedure di esportazione dei dati, opzioni runtime alternative, diritti contrattuali, test di recupero, piani di controllo delle chiavi e un calendario realistico per spostare o ripristinare i servizi critici.

Qual è il più grande errore cloud-nativo che le banche commettono?

Il più grande errore è adottare i container senza controlli di piattaforma. Se Kubernetes aumenta la velocità di deployment ma non impone identità, policy, audit, residenza dei dati, recupero e controlli di vulnerabilità, accelera il rischio anziché ridurlo.

Riferimenti #

Ultima revisione .

Ultima revisione .