O ticket chegou na sexta à tarde: "alterar alíquota de comissão no ramo habitacional, urgente para fechar proposta segunda de manhã." Para quem não vive isso, parece simples. Para quem vive, a sequência é previsível: engenheiro interrompe o que estava fazendo, localiza o arquivo certo entre quatro candidatos, faz a mudança, abre PR, aguarda code review, aguarda aprovação de deploy, reza para não ter efeito colateral em outro ramo que compartilha a mesma lógica. Se correr tudo bem, são 2 dias. Se o ambiente de QA estiver ocupado, é na semana que vem.

A tese é direta: esse ticket não deveria existir. Não porque o negócio não possa pedir mudanças. Pode e deve. Mas porque uma alíquota de comissão não é código. É dado de negócio com estrutura lógica. A confusão entre os dois é o problema de arquitetura mais caro que seguradoras brasileiras carregam hoje.

Regra de negócio não é código, mas todo mundo trata como se fosse

O padrão se estabeleceu por razões técnicas legítimas: quando o sistema foi construído, externalizar regras era complexidade desnecessária. Colocar a lógica direto no código era mais rápido, mais simples de testar, mais fácil de versionar com o próprio Git. Faz sentido até certo ponto.

Onde deixa de fazer sentido: quando a frequência de mudança da regra é completamente diferente da frequência de mudança do código estrutural. Infraestrutura de pagamento muda uma vez por ano, se tanto. Critérios de subscrição do ramo residencial podem mudar toda semana durante um ciclo de ajuste de portfólio. Tratar os dois com o mesmo ciclo de deploy é o problema. É uma violação de separação de responsabilidades que fica invisível durante anos, e insuportável quando o negócio precisa de velocidade.

O padrão técnico tem nome: business logic acoplada à aplicação, sem camada de externalização. O sintoma operacional é o backlog de TI composto por tickets que, tecnicamente, não precisam nem passar pelo time de engenharia.

O que esse acoplamento custa por mês

Benchmark de implementações reais: 40% do backlog de engenharia em seguradoras de médio porte são, na prática, mudanças de regras disfarçadas de desenvolvimento. Não são features. São if-else com data de validade.

O custo por ticket não é trivial: dois engenheiros, dois dias, muitas horas de desenvolvimento. Some interrupção de sprint, context switching, custo de oportunidade da feature empurrada para a próxima release. Multiplique por 200 tickets por mês, número que não é extrapolação, é o volume documentado antes da separação de camadas em pelo menos uma fintech de pagamentos que fez esse movimento em 2024.

O risco regulatório adiciona outra dimensão. A SUSEP e as exigências de explicabilidade de decisões automatizadas que avançam para 2026 pedem audit trail: quem alterou qual critério, quando, com qual autorização. Em uma arquitetura onde a regra está no código, a resposta para essa pergunta passa pelo Git blame de um arquivo que três pessoas diferentes tocaram no último trimestre.

Isso não é audit trail. É investigação forense.

O que DMN muda estruturalmente

DMN (Decision Model and Notation) é o padrão OMG para modelar lógica de decisão separada do fluxo de processo. Não é ferramenta, é especificação. A implementação prática é uma tabela de decisão que o negócio consegue ler, versionar e alterar sem precisar entender Java ou Python.

O que muda para o time de engenharia: a aplicação para de conter a regra e passa a consumir o resultado de uma decisão externalizada. O motor de regras recebe os inputs, por exemplo, tipo de imóvel, faixa etária, histórico de sinistro, zona de risco, executa a tabela DMN configurada pelo negócio e devolve a decisão com rastreabilidade completa. O código da aplicação não sabe qual critério específico foi aplicado. Sabe o resultado e o identificador da versão da regra que o produziu.

Os trade-offs honestos: a curva de adoção existe. O negócio precisa aprender a modelar decisão em DMN, não é trivial nas primeiras semanas. A integração entre a aplicação e o motor de regras adiciona uma dependência de infraestrutura que precisa ser gerenciada. Rollback de regra fica mais simples do que rollback de código, mas exige disciplina de versionamento que precisa ser estabelecida. O ponto onde implementações mal feitas criam problemas novos: depurar uma decisão quando a regra está externalizada e o log do motor não está bem configurado.

O que fica consistentemente mais simples: o deploy de mudança de regra vai de dias para minutos. O negócio altera o critério, publica a nova versão da tabela, o motor passa a responder com novas configurações imediatamente. TI não precisa saber que aconteceu. O audit trail é gerado automaticamente, cada decisão registra a versão da regra que a produziu.

Em resumo, quem resolveu isso em 2025 chega em 2026 com audit trail automatizado, backlog de engenharia focado em produto e capacidade de ajustar critério de precificação no mesmo dia em que o mercado muda. Quem não resolveu, chega em 2026 com a mesma sexta-feira de sempre, mais um ticket urgente, mais um sprint interrompido, e a SUSEP fazendo a pergunta que ninguém vai conseguir responder bem: "mostre-me o histórico de decisões automatizadas do último trimestre, com data, versão e critério aplicado."

Git blame não é uma resposta aceitável para regulador.