INTELIGÊNCIA ARTIFICIAL • SOFTWARE • BANCOS
Modelos de IA melhoram a tradução de COBOL, mas modernizar um sistema inteiro continua sendo outra tarefa
Novos testes indicam avanço na conversão de programas escritos em COBOL para linguagens modernas. A oportunidade é grande para bancos, governos e empresas; o risco também. Código traduzido precisa preservar regras de negócio, integrações e resultados com precisão.
Atualizado em 27 de outubro de 2026. Os resultados são promissores, mas não demonstram que sistemas críticos possam ser substituídos de forma autônoma.
Por que COBOL ainda importa em 2026
COBOL nasceu em 1959, mas continua presente em sistemas de bancos, seguradoras, companhias aéreas e órgãos públicos. A longevidade não é simples atraso tecnológico: muitos desses programas foram ajustados durante décadas, processam enormes volumes e incorporam regras que raramente estão documentadas em outro lugar.
Trocar esse software significa preservar cálculos, calendários, arredondamentos, formatos de arquivo, filas de processamento, controles de acesso e integrações. Um erro pequeno pode alterar saldos, pagamentos ou benefícios. Por isso, empresas frequentemente preferem manter um sistema antigo conhecido a substituí-lo por uma plataforma nova cujo comportamento ainda não foi provado.
1959
ano de criação do COBOL
98%
melhor resultado reportado no teste de preservação
0%
tolerância aceitável para erros em rotinas críticas
O que os novos testes de IA mostram
A OpenAI informou avanços na migração de programas antigos para C++, Java, Kotlin, Python e Rust. Conforme os resultados divulgados e relatados pelo The Verge, o GPT-6.1 Sol preservou o comportamento esperado em 87% dos casos com baixo esforço de raciocínio e chegou a 98% quando recebeu mais capacidade para analisar a tarefa.
O indicador mede se o programa convertido passa pelos testes usados na avaliação. Essa condição é fundamental: uma tradução que apenas compila ou parece semelhante não basta. O novo código precisa produzir as mesmas saídas para as mesmas entradas, inclusive em situações incomuns.
A Anthropic também apresenta o Claude Code como ferramenta para analisar bases antigas, mapear dependências, gerar testes e preservar regras de negócio. Em seus materiais de modernização, a empresa recomenda começar por uma parte isolada, executar o sistema antigo e o novo em paralelo e comparar resultados antes de ampliar a migração.
Traduzir código não é substituir um sistema
O principal limite está na escala. Um teste pode apresentar ao modelo funções relativamente autocontidas. Um sistema real reúne milhões de linhas, programas em diferentes linguagens, bancos de dados, arquivos VSAM, rotinas JCL, transações CICS e interfaces construídas em épocas distintas.
Especialistas ouvidos pelo The Verge destacam que a dificuldade decisiva é dividir o sistema em partes que possam ser compreendidas e substituídas sem interromper o restante. Reescrever um módulo é diferente de descobrir todas as dependências invisíveis que o conectam à operação.
- Regras não documentadas: exceções podem existir somente no código ou na memória dos funcionários.
- Precisão numérica: arredondamento e casas decimais podem mudar valores financeiros.
- Dados históricos: formatos antigos precisam ser lidos sem perda ou ambiguidade.
- Desempenho: uma versão funcional pode não suportar o volume de produção.
- Segurança: o processo pode introduzir falhas ou expor dados sensíveis.
Um estudo acadêmico recente sobre migração de COBOL para Java ilustra o desafio. Pesquisadores produziram 849 casos sintéticos e encontraram 61 defeitos no gerador. Ao inserir deliberadamente 450 erros, o método de validação detectou 47,6%. A taxa foi melhor para chamadas e gravações removidas, mas fraca para defeitos de arredondamento e precisão — justamente os que podem ser críticos em finanças.
O ponto central: 98% é um avanço expressivo para uma avaliação, mas 2% de comportamento divergente ainda é inaceitável em uma rotina que movimenta dinheiro ou calcula benefícios.
Como usar IA em uma migração com segurança
- Inventariar: mapear programas, dados, filas, interfaces e responsáveis.
- Documentar: usar IA para explicar fluxos, mas revisar com especialistas no negócio.
- Criar testes: cobrir situações normais, limites, erros, datas e precisão monetária.
- Migrar em partes: escolher componentes pequenos e reversíveis.
- Executar em paralelo: comparar o legado e a versão moderna com os mesmos dados.
- Observar produção: medir desempenho, segurança e divergências antes de desligar o antigo.
O papel mais produtivo da IA é acelerar a arqueologia de código, a documentação, a criação de testes e a tradução inicial. Engenheiros continuam responsáveis pela arquitetura, pelos critérios de aceite e pela decisão de colocar um componente em produção.
Impacto para bancos, governos e empresas de tecnologia
Se essas ferramentas reduzirem o tempo de análise, projetos antes adiados podem se tornar viáveis. Bancos podem conectar sistemas centrais a aplicativos e agentes de IA; governos podem modernizar benefícios e arrecadação; seguradoras podem simplificar produtos escritos em plataformas antigas.
Para consultorias e fornecedores de mainframe, a mudança tende a alterar o trabalho em vez de eliminá-lo. Menos horas podem ser gastas em leitura manual e conversão repetitiva; mais esforço será necessário em arquitetura, validação, segurança e gestão da transição.
O que acompanhar nos próximos meses
Os melhores sinais serão projetos reais com métricas auditáveis: porcentagem de regras preservadas, cobertura de testes, defeitos encontrados antes da produção, tempo de migração, custo total e reversibilidade. Demonstrações com poucos arquivos não substituem evidência em sistemas completos.
Também será importante observar como reguladores tratam código gerado por IA em operações críticas. Empresas precisarão registrar quais modelos foram usados, quais dados entraram no processo, quem revisou as mudanças e como uma decisão pode ser revertida.
