Como extraio as regras de negócio do meu sistema antigo com IA?

Você extrai as regras de negócio do seu sistema antigo em 3 passos: a IA lê o código e redige cada regra como uma frase clara ligada à linha de onde ela veio; o responsável pelo processo revisa e confirma ou corrige; e você compara a regra com o que o sistema realmente faz em notas fiscais reais. Uma ferramenta como o AWS Transform para mainframe redige as regras como requisitos revisáveis, e no anúncio da Thought Machine com a Amazon em 29 de setembro de 2026 a extração passa por 4 etapas que terminam com uma aprovação humana. Não escreva código novo até que as regras estejam confirmadas.

Na parte 3 você saiu com um inventário e uma decisão provisória para cada sistema. Os sistemas que você decidiu reconstruir ou converter são os que precisam primeiro desta etapa.

Por que as regras de negócio são o que há de mais valioso no seu sistema antigo

Uma regra de negócio é a forma como sua empresa calcula ou decide algo: como é calculado o desconto de um cliente atacadista, quando entra uma multa por atraso, quem aprova um pedido de compra acima de certo limite, como é arredondado o valor de uma parcela. Essas regras se acumularam ao longo de anos de mudanças, e muitas nunca foram escritas em nenhum documento.

• No código: condições e cálculos que um programador escreveu anos atrás a pedido de um gestor que já saiu da empresa.
• No banco de dados: tabelas de preços, taxas e limites que alguém altera à mão sem saber o que depende deles.
• Na cabeça das pessoas: as exceções que o contador trata à mão porque o sistema não trata.
• Em planilhas: fórmulas que cobrem o que falta no sistema, como explicamos em qual planilha é o sistema.

Se você reconstruir o sistema sem essas regras, vai construir um sistema novo que calcula de outro jeito, e só vai descobrir quando um cliente contestar uma nota fiscal. O que precisa migrar são as regras; a linguagem de programação antiga é só o recipiente.

Como a IA lê o código e redige as regras

Extrair regras era um trabalho manual longo: um programador lia o código linha por linha e anotava o que entendia. As ferramentas de hoje leem todo o código, seguem de onde vem cada número e para onde vai, e redigem o que encontram em linguagem clara. Um exemplo: a Amazon diz na página do AWS Transform para mainframe que o serviço extrai cada regra de negócio do código-fonte e a liga à sua origem, depois gera requisitos prontos para desenvolvimento que sua equipe pode revisar, cada um rastreável até o código de onde veio. Essa é a descrição que a Amazon faz do seu serviço, não um resultado garantido.

O formato em que a regra é escrita importa. Um formato conhecido é o EARS, o Easy Approach to Requirements Syntax, desenvolvido por Alistair Mavin e colegas na Rolls-Royce e publicado pela primeira vez em 2009. A ideia é que cada regra seja escrita em ordem fixa: o estado, depois o gatilho, depois o que o sistema deve fazer. Ele tem 5 padrões básicos; aqui estão exemplos empresariais ilustrativos:

O valor desse formato é que o responsável pelo processo consegue ler e julgar sem saber programar. Uma frase por regra, e ele responde sim, não ou incompleta.

Um exemplo bancário: intenção de negócio, não tradução linha por linha

O exemplo recente mais claro vem dos bancos, onde regras de juros, tarifas e amortização vivem há décadas em código COBOL em mainframes. COBOL é uma linguagem de programação antiga que ainda roda muitos sistemas em bancos e seguradoras. Em seu anúncio de 29 de setembro de 2026, a Thought Machine, empresa de tecnologia bancária, disse que trabalha com a Amazon em um fluxo que não traduz o código linha por linha, mas extrai a intenção de negócio pura. Segundo o anúncio, o fluxo tem 4 etapas:

1. Extração: o AWS Transform lê as aplicações legadas e extrai a lógica de negócio em especificações escritas em EARS.
2. Consolidação: centenas de variações redundantes do mesmo produto são fundidas em especificações modernas e enxutas.
3. Síntese: agentes de IA geram os produtos financeiros e seus testes em Python.
4. Validação: revisão humana em que as equipes de engenharia e de risco do banco têm autoridade explícita de aprovação.

Repare nas duas lições: a consolidação mostra que um sistema antigo carrega muitas cópias da mesma regra, e a última etapa é totalmente humana. São afirmações das duas empresas sobre o seu fluxo, e o exemplo delas é um banco, mas o método serve para qualquer empresa: extrair, fundir as duplicatas e depois construir, sem aprovar nada antes da assinatura de quem decide.

Por que o responsável pelo processo deve confirmar cada regra

A IA lê o que o código faz, não o que a empresa quer. A distância entre as duas coisas é onde acontecem os erros de modernização:

• Código morto: ela pode extrair uma regra de uma parte que não é usada há anos, fazendo-a parecer uma regra viva.
• Um bug antigo que virou hábito: o sistema arredonda um valor de forma errada e a equipe corrige à mão. A regra extraída vai levar o bug junto, a menos que alguém diga que é um bug.
• Uma regra fora do código: a exceção que o contador trata à mão nunca vai aparecer na extração.
• Regras conflitantes: duas versões do cálculo de desconto em dois lugares diferentes. Qual é a correta é uma decisão de negócio, não técnica.

Por isso, dê a cada regra um responsável de negócio que a assine: o diretor comercial para as regras de desconto, o diretor financeiro para multas e aprovações. As regras confirmadas viram a base do documento de requisitos do novo sistema, e explicamos como escrevê-lo no nosso guia para escrever requisitos de software. Lembre-se de que o código e os bancos de dados podem conter dados de clientes ou funcionários, então qualquer ferramenta que os leia fora do Reino precisa da revisão que vimos na parte 3, junto com as orientações da Autoridade Saudita de Dados e Inteligência Artificial (SDAIA).

A visão da Origami

Quando modernizamos um sistema antigo, tratamos suas regras de negócio como o que há de mais importante a levar, não o código. Usamos ferramentas de IA para ler o código e redigir as regras como frases claras numa velocidade que antes não era possível, mas não consideramos nenhuma regra definitiva até que o responsável pelo processo a tenha lido e assinado.

Depois testamos cada regra confirmada com dados reais do sistema antigo antes de construir o novo em torno dela, para que o novo sistema calcule como a empresa espera, e não como uma ferramenta supõe. Se quiser ver como trabalhamos, conheça nossos serviços.

O exercício da semana: uma regra, três notas fiscais

Você não precisa esperar uma ferramenta para começar. Escolha uma regra que gera discussão com frequência, como um desconto ou uma multa por atraso, e siga estes passos:

1. Peça ao responsável pelo processo que escreva a regra em uma frase, no formato: Quando..., o sistema deve...
2. Puxe do sistema 3 notas fiscais reais em que a regra foi aplicada: uma comum, uma no limite e uma com exceção.
3. Calcule cada nota à mão usando a frase escrita e compare o resultado com o que o sistema produziu.

Se as três conferem, a regra está documentada. Se uma diverge, você encontrou uma regra oculta ou um bug antigo, e é exatamente isso que precisa saber antes de qualquer modernização.

Na próxima parte

Agora você tem regras confirmadas para o seu sistema. Vem então a grande decisão: mover o sistema como está, converter o código para uma plataforma moderna, reconstruí-lo em torno das regras extraídas ou substituí-lo por um produto pronto e manter só os dados? Na parte 5 comparamos esses caminhos em uma tabela: quando cada um se encaixa, o que preserva, o que arrisca e quem precisa participar.

Fontes

• AWS Transform para mainframe: página oficial — extração de regras de negócio ligadas ao código original, requisitos revisáveis e testes de equivalência.
• Thought Machine e AWS: anúncio de 29 de setembro de 2026 — as quatro etapas: extração em EARS, consolidação, síntese e validação humana.
• EARS: o guia oficial de Alistair Mavin — o formato, seus cinco padrões e sua primeira publicação em 2009.
• SDAIA: proteção de dados pessoais.