Um programa de fechamento pode ter décadas de existência e continuar cumprindo exatamente o que o banco precisa: processar volumes elevados, conciliar valores e permitir a recuperação de uma falha dentro da janela operacional. Sua idade, sozinha, diz pouco sobre a qualidade desse serviço.
É por isso que a permanência do COBOL nos bancos merece uma discussão mais cuidadosa. Há aplicações que continuam economicamente e tecnicamente adequadas. Há outras cujo custo, dependências ou dificuldade de alteração já limitam o negócio. Distinguir essas situações exige conhecer o sistema por dentro.
A pesquisa da OpenAI publicada em 19 de outubro (em inglês) acrescenta uma variável a essa decisão: modelos melhores em compreender e converter programas COBOL. O avanço pode reduzir uma parte importante do trabalho de modernização. Para os bancos, o valor estará em transformar essa capacidade em mudanças que preservem a operação e resolvam problemas concretos.
Por que COBOL continua fazendo sentido
Em uma aplicação bancária, o patrimônio acumulado vai além dos programas. Inclui estruturas de dados, regras de cálculo, integrações, procedimentos de recuperação e decisões de negócio incorporadas ao longo dos anos. Uma exceção aparentemente estranha pode existir porque um produto, um contrato ou uma situação operacional exigiu aquele tratamento.
Isso não torna todo código antigo correto. Significa que uma reescrita precisa distinguir o comportamento que deve ser preservado dos defeitos e das regras que precisam mudar. A documentação gerada por IA pode ajudar a localizar essa diferença; a validação continua dependendo de evidências e de quem responde pelo processo.
O Banco do Brasil oferece um exemplo concreto de adequação técnica. Em um caso de engenharia sobre sua carteira de investimentos, publicado em 2022 (em inglês), a instituição descreveu um ambiente com COBOL, JCL e DB2 que recebia grandes arquivos de sistemas internos. O processamento em massa aproveitava mecanismos especializados de carga no banco de dados. A eficiência vinha dessa combinação de aplicação, dados e plataforma.
Para incorporar informações do Open Banking, a solução adicionou Quarkus e Kafka. A nova capacidade foi integrada à arquitetura existente, aproveitando o que ela fazia bem. É um caso específico, documentado naquele momento, mas ilustra uma escolha que costuma desaparecer das discussões sobre substituição de linguagens: evoluir o serviço sem reconstruir todas as suas partes.
Também convém separar COBOL de mainframe. A linguagem, a plataforma e a arquitetura da aplicação são decisões relacionadas, mas diferentes. Colocar uma API diante de um programa não elimina suas dependências; mudar seu ambiente de execução não exige, em todos os casos, reescrevê-lo. O benefício precisa ser medido no conjunto.
Os bancos já estão mudando. A transição tem uma conta própria
A confiabilidade do ambiente atual pesa a favor de sua permanência, mas precisa ser comparada com o custo de continuar operando e evoluindo. Se uma mudança de produto exige atravessar dependências demais, se a janela de processamento se esgota ou se a equipe não consegue testar alterações com segurança, há um problema a resolver mesmo quando o fechamento de ontem terminou corretamente.
O programa de modernização do Bradesco, documentado em 2026 (em inglês), expõe outra parte dessa conta. O piloto priorizou aplicações de menor complexidade funcional e com custos de mainframe que justificavam a intervenção. A migração gradual, porém, prolongou a convivência entre ambientes e exigiu trabalho adicional de documentação, sincronização de dados e governança.
Esse é um custo que a conversão automática de código não elimina. Durante a transição, alguém precisa definir qual sistema responde por cada informação, detectar divergências, sustentar a operação e estabelecer as condições para desligar a funcionalidade anterior. Manter duas versões indefinidamente pode consumir parte do ganho que motivou o projeto.
No Itaú, a GFT descreve uma iniciativa de migração de sistemas batch com o Batch2Cloud e a plataforma Wynxx. A IA apoia a análise do legado, a geração de código e as validações; especialistas do banco e da parceira continuam responsáveis pela arquitetura e pelas decisões técnicas. A GFT relata redução de até 70% no tempo de migração na fase inicial, resultado que precisa ser entendido no escopo daquele projeto.
A direção estratégica antecede esse anúncio. Na apresentação de resultados do primeiro trimestre de 2025, o Itaú já tratava o desligamento do mainframe como objetivo de sua transformação tecnológica. Isso registra uma intenção de evolução da plataforma, não comprova que o desligamento tenha sido concluído nem que toda migração envolva abandonar COBOL.
Os casos apontam para decisões por aplicação e por capacidade de negócio. O histórico de funcionamento merece peso; o investimento feito no passado, isoladamente, não paga a operação futura. A comparação relevante inclui manutenção, prazo para alterar produtos, disponibilidade de profissionais, testes, transição e custo do ambiente de destino.
O que a IA precisa provar
No teste de migração divulgado pela OpenAI, o GPT-6.1 Sol chegou a 97,9% de acerto com maior esforço de raciocínio. A aprovação exigia passar todos os testes ocultos, com igualdade das saídas observáveis, byte a byte. É um resultado do fornecedor em uma avaliação controlada, que não equivale a validar um sistema bancário em produção.
O critério de equivalência, entretanto, toca no problema certo. A própria OpenAI destaca a aritmética de ponto fixo: descartar ou arredondar casas decimais de maneira diferente pode alterar o resultado financeiro sem impedir a execução do programa. Uma conversão aparentemente bem-sucedida pode, portanto, introduzir uma diferença que o negócio não autorizou.
A medida de uma modernização bem-sucedida é o serviço que o banco consegue operar e evoluir depois da mudança.
Na análise da MnzAI Labs, a oportunidade mais imediata da IA está em diminuir o esforço de compreender o legado e construir evidências para decidir. Mapear dependências, explicar rotinas e propor casos de teste pode tornar viável uma intervenção antes cara demais para ser avaliada. Essa investigação também pode demonstrar que manter e melhorar uma aplicação COBOL é a opção mais adequada.
Uma prova útil precisa atravessar o fluxo operacional. Além de comparar os resultados de cálculo, deve verificar o reinício de um job interrompido, o risco de processar uma operação duas vezes, a consistência dos dados e o comportamento na janela de maior carga. Uma implantação piloto também precisa de critérios para retornar ao ambiente anterior e de uma conta de operação que sobreviva ao fim da demonstração.
O conhecimento de quem mantém os copybooks, as malhas e as exceções de produção deve orientar essa avaliação. É essa experiência que permite questionar uma regra, reconhecer uma dependência e identificar o teste que faltou. Com IA, esse profissional pode ganhar instrumentos melhores para investigar e transformar o sistema.
Para os bancos, a oportunidade de repensar o modelo atual existe. Ela começa quando se consegue apontar qual limitação precisa ser removida, quanto custa removê-la e como demonstrar que o serviço resultante continua correto. Essa é uma discussão em que o conhecimento de COBOL tem muito a contribuir.