Mainframe IBM em 2026: por que o z17 ainda sustenta o mundo financeiro

Quando se fala em IBM Red Hat infraestrutura, a primeira imagem que vem à mente costuma ser containers OpenShift rodando em nuvem híbrida, clusters Kubernetes escalando workloads de IA ou automação com Ansible. Mas há uma peça silenciosa — e absolutamente central — nesse quebra-cabeça: o mainframe IBM Z. Em 2026, com o lançamento do z17, a plataforma que processa 70% das transações financeiras globais por valor ganhou capacidades de inferência de IA on-chip, integração profunda com o ecossistema Red Hat e um argumento de modernização que desafia a narrativa de “legado ultrapassado”. Bancos centrais, bolsas de valores, seguradoras e varejistas de missão crítica não apenas mantêm seus mainframes: eles estão expandindo esses ambientes. A pergunta correta não é “por que o mainframe ainda existe”, mas sim “por que ele se tornou mais relevante do que nunca”.

O contexto de 2026 é particularmente desafiador para arquitetos de infraestrutura. De um lado, a explosão da IA generativa empresarial pressiona os data centers com demandas de inferência em tempo real — e ninguém quer mover petabytes de dados transacionais para a nuvem pública para rodar um modelo de detecção de fraude que precisa responder em milissegundos. De outro, as regulamentações de soberania de dados — incluindo a LGPD no Brasil e o EU AI Act na Europa — exigem que informações financeiras e pessoais permaneçam em ambientes rigidamente controlados. É exatamente nesse cruzamento entre latência ultrabaixa, segurança inquebrável e governança de dados que o mainframe IBM Z se posiciona como plataforma estratégica — e não como relíquia.

A IBM Corporation, fundada em 1911 e hoje com aproximadamente 280 mil funcionários, estruturou sua estratégia corporativa em dois pilares: nuvem híbrida — centrada no Red Hat OpenShift — e IA empresarial — materializada na plataforma watsonx. A aquisição da Red Hat em 2019 por US$ 34 bilhões não foi um movimento de software qualquer: foi a compra do sistema operacional da nuvem corporativa. E o mainframe, longe de ser um corpo estranho nessa estratégia, foi progressivamente integrado a esse ecossistema. O z/OS hoje conversa com o OpenShift via operadores Kubernetes; cargas COBOL são modernizadas para Java com watsonx Code Assistant for Z; e o IBM z17, lançado em 2025, traz o acelerador de IA Spyre diretamente no chip, executando inferência de modelos de machine learning na mesma transação que trafega por CICS ou IMS.

Este post é um mergulho técnico e direto na infraestrutura de missão crítica que sustenta a economia digital. Vamos desmontar o funcionamento do z17 com processador Telum II, explicar por que a inferência on-chip muda o jogo para bancos, detalhar como o LinuxONE 5 consolida milhares de servidores x86 em um único frame com eficiência energética radical, e mostrar como a integração com IBM Red Hat infraestrutura — OpenShift, Ansible, Terraform e Vault — transforma o mainframe em uma peça de nuvem híbrida como qualquer outra, só que com atributos de disponibilidade que nenhum hyperscaler consegue igualar. Se você é um profissional de TI que ainda vê o mainframe como um dinossauro, prepare-se para recalibrar seus conceitos.

A nova face do mainframe: IBM z17, processador Telum II e o acelerador de IA Spyre

O IBM z17 representa a sétima geração da arquitetura Z desde a virada do milênio e a primeira a incorporar o conceito de IA transacional on-chip como característica-padrão — não como acelerador opcional. Seu coração é o processador Telum II, uma evolução do Telum original que já havia introduzido inferência integrada em 2022. O Telum II dobra a capacidade do acelerador de IA dedicado, chamado Spyre, que fica fisicamente acoplado ao pipeline de execução de cada core. Isso significa que uma instrução de inferência — digamos, calcular a probabilidade de uma transação com cartão de crédito ser fraudulenta — é despachada para o Spyre dentro do mesmo ciclo de clock da transação, sem jamais sair do socket, sem cruzar barramento PCIe e sem depender de GPU externa.

Do ponto de vista arquitetural, o Spyre é um acelerador de matriz sistólica otimizado para inferência de baixa latência com precisão INT8 e FP16. Ele não compete com GPUs de treinamento como as NVIDIA H100 ou as próximas Blackwell; sua função é outra: executar milhões de inferências por segundo com latência de microssegundos, diretamente no caminho dos dados transacionais. Para um banco que processa dezenas de milhares de transações por segundo (TPS) em picos como Black Friday, isso elimina a necessidade de fazer chamadas de rede para um microsserviço de ML externo — cada milissegundo conta quando o cliente está no caixa e o sistema precisa autorizar ou negar a compra em tempo real.

O Telum II também incorpora um cache L2 de 64 MB por chip e um design de interconexão em anel bidirecional que permite comunicação de latência extremamente baixa entre cores e entre drawers. A memória cache virtualizada (chamada Virtual L3) pode atingir centenas de megabytes, o que é particularmente relevante para bancos de dados transacionais como Db2 for z/OS e IMS, onde tabelas de lookup de fraude ou scoring de risco precisam estar residentes em cache para evitar acessos a storage. O z17 suporta até 256 cores configuráveis por sistema, com possibilidade de ativar sub-capacidade via LPARs (Logical Partitions) com granularidade de fração de core — algo que nenhum servidor x86 oferece nativamente.

Para operadores de infraestrutura acostumados com a linguagem do mundo distribuído, vale uma analogia: o z17 é como se você tivesse um cluster Kubernetes onde cada nó viesse com um TPU integrado, latência de rede entre nós medida em nanossegundos, criptografia total de dados em uso, e um hipervisor certificado EAL5+ capaz de particionar recursos com precisão de 1% de CPU. Só que isso roda em um único frame de 19 polegadas, com duas fontes redundantes e zero downtime planejado há décadas.

Por que o mainframe sobrevive — e prospera — em 2026

A sobrevivência do mainframe não é uma questão de inércia tecnológica ou resistência a mudanças. É uma equação de engenharia que envolve disponibilidade contínua, integridade transacional e economia de escala em cargas estáveis. O z/OS foi projetado desde os anos 1960 com um conceito que o mundo x86 só começou a arranhar com o Kubernetes: tolerância total a falhas de hardware sem interrupção de serviço. No z17, é possível trocar um livro de memória, um canal de I/O ou até mesmo um processador inteiro com o sistema rodando — e as transações em andamento simplesmente não percebem. Nenhum hyperscaler oferece isso; o que eles oferecem é redundância de instâncias e regiões, o que resolve muitos casos, mas não todos.

Outro fator determinante é a consistência forte do modelo transacional. Em ambientes distribuídos, garantir ACID (Atomicidade, Consistência, Isolamento e Durabilidade) em escala global é um problema de pesquisa ainda em aberto — o protocolo Spanner do Google é uma exceção notável, mas com custos e restrições de latência consideráveis. No z/OS, transações CICS ou IMS são atômicas por construção, com journaling síncrono e capacidade de rollback em cascata que protege a integridade dos dados mesmo em cenários de falha de energia ou corrupção de storage. Para um banco que processa transferências SWIFT, pagamentos PIX (no Brasil) ou liquidação de operações na B3, perder uma única transação é inaceitável — e pode gerar passivos regulatórios de milhões de dólares.

A criptografia pervasiva é outro diferencial silencioso. Desde o z14, a IBM oferece pervasive encryption: a capacidade de criptografar todos os dados em repouso e em trânsito sem impacto perceptível de performance, graças a aceleradores criptográficos em hardware (CPACF e Crypto Express). No z17, essa capacidade foi estendida para suportar os primeiros algoritmos de criptografia pós-quântica (PQC), antecipando o momento em que computadores quânticos com capacidade de quebrar RSA e ECC se tornarem uma ameaça real. O IBM Guardium gerencia essas políticas de criptografia e fornece trilhas de auditoria imutáveis — algo que a LGPD e o Marco Civil da Internet no Brasil exigem para dados financeiros e pessoais.

No ecossistema de IBM Red Hat infraestrutura, o mainframe não é mais uma ilha isolada. Operadores podem gerenciar LPARs do z/OS usando Ansible Automation Platform, provisionar recursos de storage com Terraform (via provedores IBM Z), e expor transações CICS como APIs RESTful que são consumidas por aplicações rodando em OpenShift — tudo isso com segredos gerenciados pelo HashiCorp Vault, agora parte do portfólio IBM. O resultado é uma malha de computação onde o mainframe é tratado como mais um nó — só que um nó que não cai, não perde dados e processa 30 mil transações por segundo sem suar.

LinuxONE 5: consolidação radical com alma de mainframe e pulso de IBM Red Hat infraestrutura

Se o z/OS é a alma histórica do mainframe, o LinuxONE é sua face moderna e abertamente linuxista. O LinuxONE 5, baseado no mesmo hardware do z17, é um servidor que roda exclusivamente Linux — distribuições como Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server e Ubuntu Server — com todas as propriedades de RAS (Reliability, Availability, Serviceability) do mainframe. A proposta de valor é cristalina: consolidar milhares de servidores x86 em um único frame, reduzindo drasticamente o footprint de data center, o consumo energético e a complexidade operacional.

Os números impressionam. Um único frame de LinuxONE 5 pode hospedar milhares de instâncias Linux em LPARs ou máquinas virtuais KVM — sim, o KVM foi portado para s390x e roda nativamente sobre o hipervisor PR/SM. A IBM documenta casos de clientes que consolidaram 3.400 servidores x86 em um único LinuxONE, com redução de 75% no consumo de energia e 50% no custo total de propriedade (TCO) ao longo de cinco anos. Para operadores de nuvem privada que já usam Red Hat OpenShift, o LinuxONE é um nó worker como qualquer outro: o OpenShift Container Platform tem suporte oficial à arquitetura s390x, e clusters híbridos podem combinar nós x86 e s390x sob o mesmo plano de controle.

O caso de uso mais eloquente para o LinuxONE 5 em 2026 é a consolidação de workloads de banco de dados. Empresas que rodam dezenas de instâncias de PostgreSQL, MySQL, MariaDB ou MongoDB em servidores x86 fragmentados podem migrar essas bases para um LinuxONE rodando Db2 for Linux ou os próprios bancos open-source, com latência de I/O drasticamente menor graças aos canais FICON e ao subsistema de storage integrado. O IBM FlashSystem conectado via FICON ou NVMe-over-Fibre Channel entrega latências de armazenamento na casa das dezenas de microssegundos — algo impossível em arquiteturas de storage desagregado baseadas em Ethernet.

Para times de DevOps que operam sob a bandeira de IBM Red Hat infraestrutura, o LinuxONE 5 é gerenciável via pipelines GitOps. Com o Red Hat Advanced Cluster Management, é possível aplicar políticas de configuração, monitoramento e compliance a nós LinuxONE da mesma forma que se aplica a nós AWS ou Azure. O Turbonomic, ferramenta de otimização de recursos da IBM, analisa continuamente a utilização e recomenda rightsizing de LPARs — economizando ciclos de CPU que, em um ambiente x86, simplesmente seriam desperdiçados. Na JRT Technology Solutions, implementamos clusters OpenShift em LinuxONE para clientes do setor financeiro que precisam de consolidação com zero surpresas de latência. A experiência mostra que a curva de aprendizado do time de infraestrutura é menor do que se imagina — especialmente quando o ambiente já está instrumentado com Ansible e pipelines de CI/CD.

Inferência de IA transacional: o acelerador Spyre em detalhes

Vamos abrir a caixa-preta do Spyre Accelerator. Trata-se de um bloco de hardware dedicado dentro do processador Telum II, projetado especificamente para inferência de redes neurais profundas (DNN) com latência determinística. Cada core do Telum II tem seu próprio Spyre, e todos operam em paralelo. O acelerador suporta operações de multiplicação de matrizes com precisão INT8, FP16 e FP32, cobrindo a maioria dos modelos usados em scoring de risco, detecção de fraude, análise de sentimento em interações de chatbot e classificação de transações.

O modelo de programação é integrado ao IBM Deep Learning Compiler, que aceita modelos exportados de frameworks como TensorFlow, PyTorch e ONNX, otimiza-os para a arquitetura Spyre e gera código executável diretamente no z/OS ou Linux on Z. Não é necessário reescrever o modelo; o compilador cuida da quantização, fusão de camadas e alocação de memória. O resultado é que um modelo treinado em uma GPU NVIDIA no data center ou na nuvem pode ser implantado no Spyre com um pipeline de MLOps que passa por watsonx.ai para versionamento e watsonx.governance para validação de compliance — antes de ser empurrado para produção no z17.

O impacto em cenários reais é contundente. Um grande banco brasileiro, processando picos de 15 mil transações de cartão de crédito por segundo, consegue executar inferência de fraude em cada uma delas com latência adicional inferior a 1 milissegundo — comparado a 20-30 milissegundos se a inferência fosse feita via chamada gRPC para um serviço externo de ML rodando em Kubernetes. Em um ano, essa diferença representa milhões de transações que não sofrem timeout, milhares de falsos positivos evitados e uma experiência de cliente sem atritos na ponta do caixa.

Além de fraude, o Spyre está sendo usado para scoring de crédito em tempo real (aprovação de empréstimos em milissegundos), detecção de anomalias em pagamentos instantâneos (como PIX no Brasil) e manutenção preditiva de ativos de rede em telecomunicações — caso em que os eventos de rede chegam ao mainframe via Kafka rodando em Linux on Z e são classificados pelo Spyre antes de gerar alertas. A integração com watsonx Orchestrate permite que esses alertas disparem fluxos de automação em sistemas de field service, fechando o ciclo de IA em minutos, não horas.

Integração com IBM Red Hat infraestrutura: OpenShift, Ansible e a malha de nuvem híbrida

A integração do mainframe com o ecossistema IBM Red Hat infraestrutura não é cosmética — é arquitetural. O Red Hat OpenShift 4.18 suporta oficialmente a arquitetura s390x como plataforma de nós worker e, em configurações específicas, de nós master. Isso significa que um cluster OpenShift pode ser composto por nós x86 rodando em VMware, nós ARM em AWS Graviton e nós s390x no LinuxONE ou em LPARs do z/OS via zCX (z/OS Container Extensions) — todos gerenciados pelo mesmo plano de controle. O operador de Cluster Resource Override ajusta automaticamente as requisições de CPU e memória para corresponder às capacidades de cada arquitetura.

Na prática, isso permite cenários arquiteturais híbridos extremamente poderosos. Uma aplicação moderna de banco digital, por exemplo, pode ter seu front-end React rodando em containers no OpenShift sobre x86 na nuvem AWS, APIs de negócio em microsserviços Quarkus no OpenShift sobre LinuxONE, e transações de backend em CICS no z/OS — tudo isso orquestrado por uma malha de serviços que usa Istio, nativo do OpenShift Service Mesh, com injeção de sidecar Envoy até mesmo nos containers zCX. O HashiCorp Consul (agora parte da IBM) gerencia o service discovery entre os mundos mainframe e cloud-native, permitindo que uma chamada de API iniciada em um pod no EKS da AWS chegue a um programa COBOL em CICS com latência total inferior a 50 ms.

A automação é o tecido conjuntivo dessa arquitetura. O Ansible Automation Platform 2.6 inclui módulos certificados para z/OS — é possível escrever playbooks que criam LPARs, provisionam volumes de storage no IBM Storage Scale, configuram filas CICS e até mesmo iniciam jobs batch. Times de SRE (Site Reliability Engineering) podem incluir tarefas de mainframe nos mesmos pipelines de GitLab ou GitHub Actions que usam para microsserviços, reduzindo a dependência de especialistas z/OS para tarefas operacionais rotineiras. A JRT Technology Solutions utiliza exatamente essa abordagem em projetos de modernização: encapsulamos operações de mainframe em playbooks Ansible e templates de Terraform, permitindo que times DevOps gerenciem o ambiente Z sem precisar aprender JCL ou REXX.

Outro componente fundamental da malha é o IBM Cloud Satellite, que estende a experiência de nuvem pública da IBM para qualquer infraestrutura — incluindo o mainframe. Com o Satellite, é possível provisionar serviços de nuvem como bancos de dados gerenciados, filas de mensagens e pipelines de IA diretamente no z17 ou LinuxONE, com controle de governança centralizado e políticas de compliance unificadas. Para empresas que operam sob a LGPD, isso significa que dados jamais saem do data center on-premises, mas ainda assim podem ser processados por serviços de IA como watsonx.ai rodando localmente no mesmo hardware — sem tráfego de dados para a nuvem pública.

Modernização de legado: COBOL para Java com watsonx Code Assistant for Z

O elefante na sala do mainframe sempre foi o COBOL. Estima-se que existam entre 200 e 800 bilhões de linhas de código COBOL em produção no mundo, sustentando sistemas de core banking, seguros, governo e saúde. O desafio não é que COBOL seja uma linguagem ruim — ela é excepcionalmente boa para processamento transacional em lote e tem uma semântica de aritmética decimal fixa que Java até hoje não replica nativamente. O problema é a escassez de desenvolvedores dispostos a programar nela e a dificuldade de integrá-la a ecossistemas modernos de CI/CD, observabilidade e testes automatizados.

O watsonx Code Assistant for Z é a resposta da IBM a esse dilema. Trata-se de uma ferramenta baseada em IA generativa — especificamente um modelo Granite fine-tunado para compreensão de COBOL e geração de Java — que analisa o código-fonte COBOL, entende sua lógica de negócio (não apenas a sintaxe) e gera um equivalente funcional em Java 21, incluindo classes, métodos, anotações JPA para persistência e testes unitários JUnit. O processo não é uma tradução linha a linha, mas uma refatoração semântica que preserva a intenção do código original.

O fluxo de trabalho é o seguinte: o assistente vasculha o repositório de código-fonte (geralmente em bibliotecas PDS no z/OS ou Git), identifica programas COBOL candidatos à modernização, e sugere uma ordem de migração baseada em dependências e complexidade ciclomática. O desenvolvedor revisa o código Java gerado, ajusta regras de negócio específicas, e o resultado é empacotado como um container ou um JAR que roda no OpenShift — inclusive em nós s390x, se o objetivo for manter a carga no mainframe sem reescrever em COBOL. O assistente também gera testes de regressão que comparam a saída do programa Java com a saída do COBOL original para os mesmos inputs, garantindo equivalência funcional.

Grandes bancos brasileiros estão utilizando o watsonx Code Assistant for Z para modernizar sistemas de processamento de PIX, crédito consignado e folha de pagamento — áreas onde o COBOL ainda reina, mas a pressão por APIs RESTful, integração com fintechs e suporte a Open Finance exige stacks mais flexíveis. O assistente não elimina a necessidade de conhecer a lógica de negócio — isso continua sendo domínio dos analistas e arquitetos —, mas reduz em 60 a 70% o esforço de codificação e teste, segundo dados internos da IBM Consulting. Na JRT Technology Solutions, atuamos como integradores nesse processo: preparamos o pipeline de CI/CD, configuramos os ambientes de homologação em OpenShift e garantimos que a governança de código — com SonarQube e watsonx.governance — esteja em conformidade com as políticas de segurança da instituição.

Storage empresarial: FlashSystem, snapshots imutáveis e o air-gap definitivo com fitas LTO

Nenhuma discussão sobre infraestrutura de missão crítica está completa sem o storage — e aqui a IBM tem um portfólio que complementa o mainframe de forma simbiótica. O IBM FlashSystem é a linha de storage all-flash de alta performance, projetada para latências consistentes abaixo de 100 microssegundos e com recursos de proteção anti-ransomware que são cada vez mais vitais em um cenário de ataques cibernéticos direcionados a infraestrutura de dados.

O recurso mais relevante para ambientes mainframe é o IBM Safeguarded Copy, que cria snapshots imutáveis de volumes de dados em intervalos configuráveis. Esses snapshots não podem ser alterados ou deletados — nem pelo administrador de storage, nem por um atacante com credenciais privilegiadas