Como documentar sistemas legados com I.A.: a engenharia reversa que trabalha a favor da empresa

O sistema que ninguém sabe explicar

Quase toda empresa com alguns anos de estrada tem um: o sistema feito sob medida há quinze anos, a planilha cheia de macros que fecha o mês, o banco Access que alimenta o faturamento, o script que integra o ERP ao e-commerce. Funciona, mas quem escreveu já saiu, a documentação nunca existiu e ninguém quer mexer.

Esse sistema vira um obstáculo silencioso. Ele trava a migração para uma plataforma nova, impede automações e concentra risco: se quebrar, ninguém sabe consertar. A boa notícia é que a mesma tecnologia que colocou a engenharia reversa com I.A. nas manchetes em outubro de 2026 pode trabalhar a favor da empresa nesse caso.

Engenharia reversa a favor da empresa

Engenharia reversa é partir de um software pronto para entender como ele funciona. Quando o sistema é da própria empresa, não existe a discussão jurídica que cerca a análise de programas de terceiros: o objetivo é recuperar um conhecimento que se perdeu.

Há dois cenários. No mais comum, o código-fonte existe, mas ninguém o entende: um agente de I.A. lê o repositório inteiro e explica o que cada parte faz. No mais difícil, só sobrou o programa compilado: ferramentas como o REA coordenam programas de análise, como o Ghidra, para reconstruir o comportamento a partir do arquivo.

O que dá para extrair de um sistema legado

Uma boa documentação gerada com I.A. responde a seis perguntas:

• ✓Mapa do sistema: quais módulos existem, o que cada um faz e como se conectam.
• ✓Regras de negócio: cálculos de comissão, descontos, prazos e validações que só existem no código.
• ✓Dicionário de dados: o que significa cada tabela e cada campo do banco.
• ✓Mapa de integrações: com quais sistemas ele troca dados, em que formato e com que frequência.
• ✓Código morto: partes que não são mais usadas e podem ficar de fora de uma migração.
• ✓Riscos: senhas escritas no código, dependências sem suporte e pontos sem tratamento de erro.

Passo a passo

O caminho que costuma funcionar tem seis etapas:

• ✓Inventariar: onde está o código, o banco de dados, quem usa o sistema e para quê.
• ✓Extrair: um agente lê o código e a estrutura do banco e gera uma primeira descrição de módulos, regras e fluxos.
• ✓Traduzir para o negócio: as regras viram texto em português, que pessoas de fora da TI conseguem ler.
• ✓Validar com quem usa: os usuários-chave confirmam ou corrigem cada regra. É a etapa que separa documentação de ficção.
• ✓Registrar o comportamento atual em testes: testes de caracterização gravam o que o sistema faz hoje, para que uma migração possa provar que nada mudou sem querer.
• ✓Planejar o próximo passo: migrar, integrar com agentes de I.A., automatizar ou aposentar.

O cuidado principal: a I.A. erra com confiança

Um modelo de linguagem descreve código com fluência, e fluência não é garantia de acerto. Um estudo publicado no arXiv em setembro de 2026, "When LLM Decompilers Recompile More and Preserve Less", mostrou o problema na reconstrução de código: com refinamento por I.A., a taxa de funções que compilam subiu de 75% para 90%, mas a de funções que se comportam como o original caiu de 74% para 62%.

Na documentação acontece o mesmo: uma descrição plausível pode estar errada justamente no detalhe que importa, como um arredondamento ou uma exceção para um tipo de cliente. As defesas são três:

• ✓Evidência: toda afirmação da documentação aponta para o arquivo e o trecho de código que a sustentam. O REA, por exemplo, devolve cada conclusão com a evidência e as limitações.
• ✓Testes: o que foi documentado vira teste executável contra o sistema real.
• ✓Validação humana: quem usa o sistema no dia a dia confirma as regras de negócio.

Segurança e confidencialidade

O código de um sistema interno costuma conter informação sensível: regras comerciais, credenciais e, no banco, dados de clientes. Antes de começar:

• ✓Use planos de I.A. cujos termos garantam que os dados enviados não são usados para treinar modelos, ou modelos rodando em ambiente próprio.
• ✓Remova senhas e chaves do código antes da análise, e troque as que estavam expostas.
• ✓Trabalhe com amostras anonimizadas do banco, em conformidade com a LGPD.
• ✓Se a análise for feita por terceiros, formalize um acordo de confidencialidade.

Quando vale a pena

Documentar um sistema legado com I.A. costuma se pagar nestes momentos:

• ✓Antes de migrar para um ERP ou uma plataforma nova.
• ✓Antes de conectar o sistema a agentes de I.A. ou a automações.
• ✓Quando a pessoa que conhecia o sistema está de saída.
• ✓Em auditorias e adequações que exigem saber o que o sistema faz com os dados.

Como a SINOON trabalha

Na nossa consultoria em I.A., o mapeamento de processos inclui esses sistemas: é comum que a maior oportunidade de automação esteja justamente presa dentro de um deles. Depois de documentado, o sistema pode ser integrado a agentes personalizados sem precisar ser substituído de uma vez.

• ServiçoConsultoria em I.A. para EmpresasMapeamento de processos, identificação de oportunidades e roadmap de implementação de I.A. no seu negócio, com estratégia antes da execução.
• ServiçoAgentes PersonalizadosDesenvolvemos agentes de I.A. sob medida para o seu processo: atendimento, qualificação, follow-up, cobrança ou o que seu negócio precisar.
• BlogEngenharia reversa com I.A.: o guia completo sobre o REA, os clones da Adobe e o que muda de verdadeO que é engenharia reversa com I.A., o que o REA e os apps do ArtCraft realmente entregam, o que diz a lei brasileira e o que muda para a sua empresa.