São 16h40 de quinta-feira. O e-mail da área atuarial tem assunto marcado como urgente: a tabela de agravamento por CEP para seguro residencial precisa entrar em produção até sexta à noite. Reajuste aprovado pela diretoria. Prazo não negociável.

Você abre o repositório e confirma o que já sabia. A lógica está num switch-case dentro do serviço de precificação, sem cobertura de teste unitário para aquele bloco. Dois engenheiros seniores vão parar o que estão fazendo. O pipeline de homologação vai ficar ocupado. Há risco real de regressão em coberturas adjacentes. Custo estimado: entre R$ 9.000 e R$ 14.000 em horas de engenharia, mais o custo de oportunidade de duas features que não vão sair nessa sprint.

O atuário que pediu a mudança poderia ter feito isso sozinho em 20 minutos — se a regra estivesse em uma tabela DMN.

Esse é o problema que DMN resolve. Não é ferramenta de workflow. Não exige Camunda instalado. É uma especificação para externalizar lógica de decisão da camada de aplicação — com ciclo de vida próprio, versionamento nativo e legibilidade para quem entende do negócio, não apenas para quem lê código.

A causa raiz não é a regra — é onde ela vive

O problema não é que a tabela de agravamento mudou. Tabelas mudam o tempo todo em seguros: frequência de sinistros, perfil de risco por região, reajuste de custo de reposição. O problema é que a lógica de negócio e a lógica de aplicação estão fundidas na mesma unidade de deploy.

Quando uma regra de aceitação de risco ou de cálculo de prêmio vive dentro de um serviço Java, qualquer alteração — por mais trivial que seja para o negócio — exige o ciclo completo de engenharia: branch, code review, build, teste, homologação, aprovação, deploy. Não porque TI seja burocrática. Porque o processo existe para proteger um sistema onde a regra está acoplada a código que tem outras responsabilidades.

Essa decisão fazia sentido quando o produto era estável e as regras mudavam uma vez por ano. Deixa de fazer sentido quando o negócio opera com ajustes frequentes de critério, múltiplos canais de distribuição e pressão regulatória que não respeita roadmap de sprint.

DMN — Decision Model and Notation — é o padrão OMG que formaliza essa separação. Existe desde 2015, está na versão 1.4, e resolve exatamente esse acoplamento: as tabelas de decisão são artefatos independentes, com ciclo de vida próprio, consumidos pelo serviço via chamada de motor — não embutidos no código do serviço.

O que esse acoplamento custa, em números

Uma mudança em regra de franquia de auto embutida em código Java envolve tipicamente dois engenheiros seniores por três dias, mais pipeline de CI/CD e ciclo de homologação — custo na faixa de R$ 12.000 e dez dias corridos. A mesma mudança numa tabela DMN: um analista de negócio, duas horas.

Regras no código são dívida. Cada mudança vira sprint. Cada sprint vira trimestre.

Seguradoras que operam com regras embutidas em código ou stored procedures acumulam, em média, três a cinco anos de débito técnico não mapeado antes de iniciar qualquer migração. Nesse período, os tickets de "ajuste de regra de negócio" consomem tipicamente 30 a 40% dos esforços de manutenção em seguradoras mid-size.

O custo que ninguém coloca na planilha é o custo de oportunidade: as features de produto que não saíram porque o sprint estava ocupado com uma mudança de alíquota. Cada regra que entra como ticket é uma feature que entra como dívida.

O risco regulatório adiciona outra camada. A SUSEP, nas Circulares 621/2021 e nas normas de conduta vigentes, exige rastreabilidade de critérios de aceitação e precificação. Quando a fiscalização pergunta qual regra gerou aquela decisão de subscrição naquela data, a resposta não pode ser "preciso verificar o commit do repositório". Um deploy emergencial para adequação a circular SUSEP, sem camada de decisão externalizada, custa na prática entre R$ 25.000 e R$ 80.000 em horas extras, testes de regressão e risco de multa por atraso. Com DMN versionado, o mesmo ciclo cai para menos de um dia útil.

O que muda estruturalmente — e o que não é gratuito

DMN introduz uma camada de decisão com ciclo de vida próprio. As tabelas são artefatos versionáveis, testáveis e deployáveis independentemente do serviço que as consome. Quando o atuário precisa atualizar a tabela de agravamento por CEP, ele abre a tabela, altera os valores, valida contra os casos de teste cadastrados e publica a nova versão. O serviço de precificação não muda. O pipeline de homologação de software não é acionado.

Uma apólice de auto com coberturas adicionais aciona dezenas de nós de decisão distintos entre emissão, sinistro e renovação. Manter essa lógica em código imperativo não escala — não porque seja impossível, mas porque torna a leitura e a manutenção progressivamente inviáveis para qualquer pessoa que não seja o engenheiro que escreveu o bloco original.

Um detalhe técnico que frequentemente gera resistência: DMN não exige infraestrutura adicional. Motores como Drools e Camunda DMN Engine são bibliotecas embarcáveis que rodam dentro de qualquer serviço Java ou Node. Não é uma plataforma de BPM. Não é uma camada de workflow. É uma dependência que você adiciona ao projeto e chama localmente — ou expõe como microsserviço se quiser consumo por múltiplos domínios.

O trade-off real é governança. Externalizar decisões cria um ativo que precisa de ownership claro: quem aprova uma nova versão, quem define os casos de teste de regressão de negócio, quem garante que a versão em produção corresponde ao que foi aprovado. Sem esse processo, DMN vira um segundo repositório de caos — só que mais visível. O trabalho de implementação técnica é menor do que parece. O trabalho de definir o processo de governança em torno do ativo é onde a maioria dos projetos subestima esforço.

Há também um limite de performance a considerar: motores DMN adicionam latência de 2 a 15ms por decisão complexa. Para subscrição batch ou emissão assíncrona, irrelevante. Para APIs de cotação com SLA abaixo de 200ms, é um parâmetro de design que precisa ser considerado — não um impedimento, mas uma variável.

O que a adoção parece na prática

Uma seguradora de médio porte com 34 ramos ativos iniciou a externalização das regras de subscrição do ramo residencial após um incidente de produção causado por uma mudança de critério que criou uma inconsistência entre o serviço de emissão e o serviço de renovação. A regra estava replicada em dois serviços distintos — e as versões tinham divergido silenciosamente durante uma manutenção seis meses antes. Ninguém havia detectado porque o efeito só aparecia em contratos com vigência superior a 18 meses.

Após a migração da lógica de subscrição para tabelas DMN versionadas consumidas por ambos os serviços via API interna, o Gerente de Engenharia relatou redução de aproximadamente 65% nos tickets categorizados como "ajuste de regra" nos três trimestres seguintes. O efeito colateral que ninguém havia antecipado: as regras externalizadas ficaram legíveis o suficiente para que o time de negócio identificasse duas inconsistências que existiam no código havia anos — critérios contraditórios entre faixas de CEP que nunca tinham sido detectados porque ninguém conseguia ler a lógica.

---

Seguradoras que resolvem esse acoplamento ganham velocidade regulatória concreta: quando a SUSEP publica uma circular com prazo de 90 dias, elas implementam em uma semana e usam os 83 dias restantes para testar. As que não resolvem usam 70 dias para implementar e os 20 restantes para torcer para que não haja regressão.

Pega os tickets de ajuste de regra dos últimos três sprints. Soma as horas de engenharia sênior. Esse é o custo recorrente de manter a decisão dentro do código — calculado, visível e evitável.