Sexta-feira, 17h23. O product owner manda mensagem no canal do time: "Urgente! O comercial precisa mudar o critério de franquia do produto residencial para segunda de manhã, tem proposta grande na mesa." Você abre o repositório. A lógica está no meio de um serviço de subscrição, num bloco de condicionais aninhadas que ninguém toca desde 2021. Mudar aquilo exige o contexto que só um engenheiro sênior tem na cabeça. Ele está em trânsito. O deploy exige aprovação de dois gerentes e uma janela que fecha às 18h.

‍

A proposta não saiu na segunda.

‍

Esse momento tem um custo precioso: dois engenheiros interrompidos por dois dias são horas de desenvolvimento. Mais o sprint comprometido. Mais a feature que escorregou para o próximo ciclo. Mais a oportunidade que foi embora. Não é má gestão. É consequência direta de uma decisão arquitetural que fez sentido até o momento em que deixou de fazer.

‍

A tese é direta: regra de negócio acoplada ao código é dívida técnica com juros compostos, e o mercado de seguros paga os juros mais altos do setor.

## O problema não é o ticket. É onde a regra mora.

‍

A decisão original foi racional. Quando o sistema foi construído, as regras estavam estáveis, o time entendia o domínio, e colocar a lógica direto no código era o caminho mais rápido. O problema não está na decisão, está no fato de que ela nunca foi revisitada quando as condições mudaram.

‍

Seguradoras brasileiras com dezenas de ramos ativos operam critérios de subscrição, precificação e sinistro que mudam com frequência: resposta à sinistralidade, ajuste regulatório, reposicionamento comercial. Cada mudança deveria ser uma decisão de negócio. Virou evento de engenharia.

‍

O padrão técnico que causa isso tem nome: *business logic leakage*. As regras, que pertencem ao domínio do negócio, vazam para a camada de aplicação e ficam distribuídas entre serviços, stored procedures, planilhas de configuração e documentos internos sem versão. Ninguém sabe com certeza qual versão está em produção. O time de engenharia não consegue responder "qual critério de franquia valeu entre março e junho do ano passado?" sem fazer arqueologia no histórico de commits.

‍

Quando a SUSEP fizer essa pergunta, e vai fazer, a ausência de audit trail vira risco regulatório com nome e endereço.

‍

## O que custa manter as coisas como estão

‍

Quarenta por cento do backlog de engenharia em seguradoras são, na prática, mudanças de regras de negócio disfarçadas de desenvolvimento. Esse número vem de padrão consistente em implementações, não é estimativa teórica.

‍

Cada ticket carrega um custo de composição: tempo de engenheiro sênior para mapear impacto, desenvolvimento, QA, aprovação, deploy. O ciclo completo de uma mudança simples como ajustar uma alíquota ou mudar um critério de elegibilidade, raramente leva menos de três dias. Frequentemente consome uma sprint inteira quando cai no meio de outras prioridades.

‍

Multiplique por volume. Uma seguradora de médio porte com vários ramos ativos recebe múltiplas solicitações de ajuste por mês. O custo acumulado não é só o tempo de engenharia. É o tempo que o produto chega ao mercado com a tabela errada, a receita que vaza porque ninguém sabia qual versão da regra de comissão estava ativa, o risco de uma auditoria encontrar decisões automatizadas sem rastreabilidade.

‍

A SUSEP a cada dia coloca mais e mais exigências de explicabilidade sobre decisões automatizadas. Seguradoras que chegam a 2026 sem audit trail de decisões vão precisar reconstruir retroativamente o que nunca foi registrado, e nenhum regulador aceita reconstrução retroativa sem ceticismo.

‍

## O que muda quando a regra sai do código

‍

A solução arquitetural não é nova, é a aplicação do princípio de *separation of concerns* à camada de decisão. Um motor de regras externo (BRMS) funciona como repositório versionado das regras de negócio, desacoplado da aplicação que o consome.

‍

Na prática, o fluxo de mudança de uma regra passa de:

‍

`spec no Confluence → ticket no Jira → sprint de engenharia → code review → QA → aprovação → janela de deploy → produção (3 dias úteis, no melhor caso)`

‍

Para:

‍

`analista de negócio edita a regra no motor → valida em sandbox → publica (10 minutos, sem envolver engenharia)`

‍

A aplicação consome as regras via chamada ao motor, não as implementa. O motor mantém histórico de versões com data, hora e autor de cada alteração. Rollback é desfazer uma publicação, não reverter commit e reimplantar serviço.

‍

Modelos de DMN (Decision Model and Notation) representam as regras em formato que tanto engenheiros quanto analistas de negócio conseguem ler e validar. O negócio para de depender de interpretação técnica para verificar se a regra implementada é a regra que foi especificada.

‍

## O que os números de uma implementação real mostram

‍

Uma seguradora de médio porte com produtos no ramo residencial centralizou as regras de subscrição e precificação em um motor externo. Antes: critérios distribuídos em planilhas, documentos e código. O time de negócios não conseguia responder qual versão estava ativa sem consultar três fontes. Qualquer ajuste passava pela fila de desenvolvimento.

‍

Resultado após a migração: 70% de redução no tempo de revisão de regras. O time de negócios passou a alterar critérios sem abrir ticket, com audit trail completo. O volume de tickets de manutenção de regras caiu para próximo de zero neste domínio.

‍

No fim, o gerente do time de negócios resumiu de forma direta: "agora temos controle total sobre as alterações sem depender de TI."

‍

Setenta por cento de redução não é ganho marginal. É a diferença entre a proposta que sai na segunda e a que não saiu.

‍

Quem resolve isso para de perder sprints em tickets que não são desenvolvimento. Quem não resolver vai continuar acumulando dívida técnica que ficou mais cara a cada ciclo regulatório, e vai chegar em 2026 sem conseguir responder a pergunta mais simples que uma auditoria pode fazer: qual critério produziu essa decisão, quando ele foi aprovado e por quem.

‍

Nenhuma resposta aceitável vive dentro de um bloco de `if-else` sem versão e sem dono.

‍