Sebastien Rousseau
Entrar em contato ›

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 read

Cloud-native banking em 2026: Kubernetes, DORA, soberania e o fim da divisão entre VM e contêiner

O cloud-native banking em 2026 não é mais um debate sobre se os bancos podem usar nuvem. É uma disciplina regulada de engenharia de plataforma: como operar serviços críticos entre contêineres, máquinas virtuais (VMs), data fabrics, cargas de trabalho de IA/ML (Inteligência Artificial / Aprendizado de Máquina) e provedores de nuvem, comprovando a resiliência operacional sob o DORA (Digital Operational Resilience Act) e regimes equivalentes. A IBM descreve 2026 como o primeiro teste supervisório real do DORA, com revisões de dependência de nuvem, inspeções de cibersegurança, testes de intrusão guiados por ameaças e supervisão direta de provedores terceiros críticos (IBM).

Resumo executivo / Principais conclusões

  • O DORA mudou a conversa sobre nuvem. 2026 traz supervisão direta da União Europeia sobre provedores terceiros críticos e revisões focadas nas dependências dos bancos em relação a seus provedores de serviços de nuvem (IBM).
  • Kubernetes é a camada de plataforma, não a resposta completa. Os bancos precisam de Kubernetes para elasticidade, automação e cargas de trabalho de AI/ML, mas também precisam de coexistência com VMs, porque core banking, pagamentos, trading e sistemas de risco continuam operando em parques virtualizados endurecidos (Red Hat).
  • A divisão entre VM e contêiner está se fechando. A Red Hat posiciona OpenShift e Portworx como um modelo unificado em que VMs e contêineres compartilham política, dados, backup, disaster recovery e controles de governança (Red Hat).
  • A soberania de nuvem agora é restrição de projeto. Os bancos usam soberania para gerenciar controle jurisdicional, autonomia operacional, controle de chaves, localização de dados e risco de concentração em nuvem (Red Hat).
  • A IA tornou o cloud-native urgente. Detecção de fraude, analítica de liquidez, personalização em tempo real e reporting regulatório exigem cada vez mais computação elástica próxima a dados sensíveis (Red Hat).
  • Estratégia de saída não é um PDF. Sob as expectativas supervisórias atuais, os bancos precisam de portabilidade testada, mapeamento de dependências, evidência contratual, procedimentos de recuperação e caminhos realistas de migração para funções críticas.
  • O alvo arquitetônico é cloud-native controlado. A plataforma bancária vencedora entrega self-service aos desenvolvedores enquanto impõe automaticamente auditoria, criptografia, residência de dados, testes de resiliência, segregação de funções e controles de risco de terceiros.

Por que 2026 é o ano da supervisão cloud-native #

O DORA passou a se aplicar a partir de janeiro de 2025, mas é em 2026 que o músculo supervisório se torna visível. A IBM observa que a primeira lista de provedores terceiros críticos foi designada em novembro de 2025 e que 2026 traz engajamento direto com as European Supervisory Agencies, revisões contratuais, inspeções in loco e análise de dependência de nuvem (IBM).

Isso muda o ônus da prova. Um banco não pode mais alegar que uma indisponibilidade de nuvem é meramente um problema de fornecedor. A instituição financeira permanece responsável pela resiliência de funções críticas, mesmo quando essas funções dependem de hyperscalers, provedores SaaS (Software-as-a-Service), plataformas de dados e serviços de segurança gerenciados.

A linha de base cloud-native banking 2026 #

1. Kubernetes como camada operacional #

O Kubernetes oferece aos bancos automação de implantação, elasticidade, imposição de políticas, orquestração de contêineres e uma abstração comum entre nuvem privada, nuvem pública e ambientes soberanos. Para novas cargas de trabalho, especialmente detecção de fraude orientada por IA, personalização em tempo real, analítica de liquidez e reporting regulatório, ele se tornou o plano de controle natural (Red Hat).

O erro é tratar o Kubernetes como destino. Para os bancos, ele é o substrato sob uma plataforma de desenvolvedor governada.

2. Convergência entre VM e contêiner #

A maioria dos bancos não consegue reescrever o parque core rapidamente. Motores de pagamento, sistemas de trading, credit scoring, modelos de risco e plataformas de core banking ainda dependem de parques de VMs endurecidos. A Red Hat argumenta que os bancos precisam de uma plataforma unificada na qual VMs e contêineres possam operar juntos, reduzindo arquitetura duplicada e alinhando controles de política, armazenamento, backup e recuperação (Red Hat).

Essa é a ponte prática entre a resiliência legada e a velocidade cloud-native. Permite que os bancos movam serviços adjacentes primeiro, co-localizem cargas de trabalho de IA dependentes de dados e evitem forçar reescritas frágeis em sistemas críticos.

3. Resiliência operacional pronta para o DORA #

A IBM afirma que as prioridades supervisórias de 2026 incluem acompanhamento de deficiências em segurança ICT (Information and Communications Technology) e terceirização, inspeções in loco sobre cibersegurança e risco de terceiros, testes de intrusão guiados por ameaças, revisões de gestão de mudanças ICT e análise de dependência de nuvem (IBM).

Isso significa que a resiliência precisa ser testável. Diagramas de arquitetura não bastam. Os bancos precisam de evidência proveniente de exercícios de failover, simulações de incidentes, restaurações de backup, mapas de dependências, testes de tempo de recuperação e fluxos de governança.

4. Soberania como capacidade de plataforma #

A soberania de nuvem não se resume à residência de dados. Inclui controle jurídico, controle operacional, controle de chaves de criptografia, jurisdição do pessoal de suporte, posicionamento de cargas de trabalho e a capacidade de manter serviços críticos se um provedor global ou processo geopolítico criar disrupção. A Red Hat enquadra a soberania como controle jurisdicional e autonomia operacional para bancos diante de regulações divergentes como GDPR (General Data Protection Regulation), DORA e regras nacionais de nuvem (Red Hat).

A implicação cloud-native é que roteamento de cargas de trabalho, gestão de segredos, controle de chaves, classificação de dados e imposição de políticas precisam ser programáveis.

A stack de plataforma do banco #

Camada de experiência do desenvolvedor #

Uma plataforma cloud-native de qualidade bancária deve expor caminhos pavimentados: golden paths, templates, catálogos de serviços, pipelines automatizados de implantação, padrões de observabilidade, policy-as-code, integração padrão de segredos e fluxos de dados aprovados. Os desenvolvedores não deveriam precisar negociar com cada responsável por controle a cada release.

A plataforma deve fazer do caminho conforme o caminho mais rápido. Esse é o único modelo que escala para milhares de serviços.

Camada de controle #

A camada de controle abrange identidade, gestão de acessos, segregação de funções, criptografia, custódia de chaves, política de rede, assinatura de imagens, software bill of materials, portões de vulnerabilidade, segurança em tempo de execução, logging e geração de evidência. É onde DORA, NIS2 (Network and Information Security Directive 2), GDPR, regras de terceirização e políticas internas de risco de modelo se tornam controles executáveis.

É onde muitos bancos falham. Adotam contêineres, mas deixam os controles como aprovações manuais fora da plataforma.

Camada de dados #

Cargas de trabalho com estado são a parte mais difícil do cloud-native banking. O argumento da Red Hat sobre convergência VM/contêiner depende fortemente de um data fabric unificado e de backup, replicação, failover e recuperação orientados por política entre VMs e contêineres (Red Hat).

Para os bancos, a camada de dados precisa responder a três perguntas: onde estão os dados, quem controla as chaves e como o serviço se recupera se a infraestrutura falhar?

Tabela de arquitetura: cloud-native para bancos #

Capacidade Padrão cloud-native Requisito de controle bancário Modo de falha
Entrega de aplicações Kubernetes, GitOps, templates Segregação de funções, evidência de mudanças, rollback Releases rápidas e não auditáveis
Coexistência com legado Plataforma unificada VM/contêiner Consistência de política e controle de migração Parques duplos com risco duplicado
Serviços de dados Operadores stateful e data fabric Residência, backup, imutabilidade, restauração testada Plataforma stateless com fragilidade stateful
Resiliência Multizona, multirregião, failover Evidência DORA e mapeamento de funções críticas Indisponibilidade de nuvem tratada como desculpa de fornecedor
Soberania Posicionamento de cargas por política Evidência jurisdicional e de controle de chaves Residência sem autonomia operacional
Cargas de IA Computação elástica próxima aos dados Governança de modelos, minimização de dados, auditoria Dados sensíveis movidos para serviços de IA não aprovados

O que isso significa por tipo de instituição #

Bancos universais de primeira linha #

Os bancos de primeira linha devem construir plataformas internas controladas entre múltiplas nuvens, com policy-as-code rigoroso, classificação de dados e posicionamento de cargas de trabalho. Têm escala suficiente para justificar engenharia de plataforma, e os reguladores esperarão deles evidência mais profunda.

Bancos de médio porte #

Os bancos médios devem padronizar em vez de customizar. Uma plataforma Kubernetes gerenciada robusta, seleção disciplinada de provedores de nuvem, estratégias de saída claras e geração automatizada de evidência valem mais do que uma ambição multinuvem dispersa que a instituição não consegue operar.

Infraestruturas de mercado financeiro #

As FMIs (Financial Market Infrastructures) precisam, acima de tudo, de comprovação de resiliência. Devem tratar o cloud-native como meio de melhorar recuperação, observabilidade e mudança controlada, em vez de uma aposta pura em velocidade.

Fintechs e PSPs #

As fintechs e PSPs (Payment Service Providers) podem se mover com rapidez, mas precisam evitar superar seu modelo de controle. À medida que se tornam sistemicamente relevantes, chegam as mesmas expectativas de resiliência, risco de terceiros, reporte de incidentes e soberania de dados.

Conclusão #

O cloud-native banking em 2026 é uma arquitetura de governança. O Kubernetes é essencial, mas não suficiente. As instituições que tiverem êxito convergirão VMs e contêineres onde necessário, usarão padrões cloud-native para novas cargas de trabalho, comprovarão resiliência sob o DORA, controlarão a soberania de dados na camada de plataforma e tornarão a conformidade automática o bastante para que os desenvolvedores avancem rápido sem criar risco não governado.

O debate antigo era se os bancos poderiam migrar para a nuvem. O debate novo é se os bancos conseguem tornar o cloud-native seguro, portável e evidenciado o suficiente para operar os serviços que importam.

Perguntas frequentes #

O DORA impede os bancos de usar nuvem?

Não. O DORA não proíbe o uso de nuvem. Ele torna as instituições financeiras responsáveis por risco ICT, dependência de terceiros, reporte de incidentes, testes de resiliência e governança de serviços críticos que dependem de nuvem e outros provedores ICT (IBM).

Por que os bancos ainda precisam de VMs se o Kubernetes é o futuro?

Os bancos ainda operam sistemas críticos em parques baseados em VM, incluindo motores de pagamento, sistemas de core banking, aplicações de trading e plataformas de risco. Um modelo unificado VM/contêiner reduz duplicação e permite migração gradual (Red Hat).

O que é uma estratégia de saída de nuvem real?

Uma estratégia de saída real inclui inventário de dependências, procedimentos de exportação de dados, opções alternativas de runtime, direitos contratuais, testes de recuperação, planos de controle de chaves e um cronograma realista para mover ou restaurar serviços críticos.

Qual é o maior erro cloud-native dos bancos?

O maior erro é adotar contêineres sem controles de plataforma. Se o Kubernetes aumenta a velocidade de implantação mas não impõe identidade, política, auditoria, residência de dados, recuperação e controles de vulnerabilidade, ele acelera o risco em vez de reduzi-lo.

Referências #

Última revisão .

Última revisão .