Arquitetura de decisão em seguros: como separar regra de código sem parar o negócio

Toda seguradora chega a esse momento de formas diferentes, mas com o mesmo sintoma: o negócio quer mudar uma regra e a conversa inevitavelmente vira uma discussão sobre sprint. Um ajuste no critério de franquia do ramo residencial, uma atualização de fator de risco por CEP, uma mudança na política de descontos por canal de distribuição. Cada um desses pedidos entra na fila de TI, ganha um ticket, aguarda priorização, passa por QA, vai para aprovação e chega em produção semanas depois, às vezes com a regra original já desatualizada.

O custo disso raramente aparece em uma linha só do orçamento. Está distribuído: nas horas de engenharia consumidas por trabalho que não é desenvolvimento de produto, nas oportunidades que o negócio perdeu enquanto esperava, nos erros de precificação que passaram porque a tabela em produção tinha uma versão diferente do que estava na planilha do atuário. E está crescendo à medida que o volume de produtos, canais e variáveis regulatórias aumenta.

A separação de regras de negócio do código resolveria boa parte disso. Mas a decisão de fazer não é trivial. A migração envolve um sistema em operação, contratos ativos, equipes com ritmos diferentes e, em seguros, uma obrigação regulatória de rastreabilidade que não tem margem para erro. O que torna a transição segura é a governança do período de coexistência, não a velocidade com que se migra.

O que segue descreve como executar essa transição de forma controlada: as fases práticas, os riscos reais de cada uma, os erros mais comuns e o que define se o projeto vai gerar valor ou virar mais uma dívida técnica com nome diferente.

---

Parte 1: o problema que a separação resolve (e o que ela não resolve sozinha)

Quando se fala em "regras de negócio no código", a imagem que vem à cabeça é um bloco de `if/else` com critérios de subscrição. A realidade é mais dispersa. Em uma seguradora com oito a doze ramos ativos, as regras costumam estar espalhadas em camadas distintas: lógica de elegibilidade no serviço de cotação, parâmetros de cálculo de prêmio em configurações de banco de dados, critérios de bloqueio de emissão em microsserviços específicos, tabelas de comissão em arquivos de propriedades, regras de liquidação de sinistro em procedimentos armazenados.

Cada camada tem um dono diferente, um ciclo de deploy diferente e um nível diferente de documentação. Quando o atuário precisa ajustar o fator de risco para um CEP específico, ele não sabe ao certo onde isso está implementado. Abre um ticket. TI investiga, localiza, altera, testa, sobe para produção. O ciclo completo leva entre dois e cinco dias úteis para uma mudança simples, e duas a quatro semanas para uma mudança que atravessa mais de uma camada.

Um padrão que aparece com frequência nesse tipo de operação: uma fatia expressiva do backlog de engenharia em seguradoras é, na prática, mudança de regra disfarçada de desenvolvimento. O sprint enche com trabalho que não é produto novo. A equipe técnica fica ocupada com manutenção operacional. E o negócio aprende que pedir mudança de critério tem um custo político alto, então começa a acumular ajustes para fazer "de uma vez", o que aumenta o risco de cada deploy.

O que a SUSEP vai perguntar

A Circular SUSEP 667 e a Resolução CNSP 395/2020 avançaram na direção da explicabilidade de decisões automatizadas. O que isso significa na prática: quando uma cotação é recusada, quando um sinistro é negado, quando uma emissão é bloqueada por critério de subscrição, a seguradora precisa ser capaz de responder qual regra foi aplicada, qual versão estava vigente na data da decisão e quem autorizou a alteração que gerou aquela versão.

Histórico de commit no Git não responde a essa pergunta. Commit registra o que mudou no código, não qual regra de negócio estava em vigor em determinada data, quem aprovou a mudança do ponto de vista do negócio, nem o raciocínio por trás da alteração. Essa distinção tem consequência regulatória direta.

Seguradoras que entram em 2026 com regras embutidas no código ficam expostas a uma pergunta que não conseguem responder de forma auditável. A separação de camadas resolve isso: cada versão de uma regra passa a ter data de vigência, autor, justificativa e trilha de aprovação, disponíveis para consulta quando a fiscalização solicitar.

O paralelo com a adoção de IA

Existe uma segunda pressão que converge com essa. Seguradoras estão adotando modelos de IA generativa em processos de subscrição, triagem de sinistros e atendimento. O modelo aprende padrões históricos, reconhece correlações em dados massivos, processa texto livre com velocidade que nenhuma equipe humana replica. Ele faz muito bem o que regras determinísticas não fazem.

Mas o modelo de IA não executa regras explícitas, ele infere. Quando o regulador pergunta por que um sinistro foi negado e a resposta é "o modelo atribuiu baixa probabilidade de cobertura", isso não atende a exigência de explicabilidade. A arquitetura que funciona combina os dois: IA extrai, classifica e sumariza; a camada de regras de negócio decide com critérios determinísticos e auditáveis sobre o resultado dessa extração.

Para essa arquitetura funcionar, a camada de decisão precisa ser separada do código. Uma seguradora que está adotando IA sem ter externalizado as regras de negócio está construindo a integração sobre uma base que vai precisar ser refatorada de qualquer forma.

---

Parte 2: como executar a migração sem parar o negócio

Fase 1: identificação das regras candidatas

A primeira tentação é fazer um mapeamento completo antes de começar. Isso atrasa o projeto por meses e frequentemente o mata antes de gerar qualquer valor. A abordagem prática é diferente: identificar o subconjunto de regras com maior volatilidade e maior custo de mudança, e começar por elas.

Pega os tickets de TI dos últimos seis meses relacionados a mudanças de critério, parâmetro ou tabela. Classifica por frequência de mudança, tempo médio de ciclo (do pedido ao deploy em produção) e impacto em caso de erro. As regras que aparecem no topo dessas três dimensões são as candidatas prioritárias.

Em seguradoras, esse exercício costuma revelar categorias que concentram a maior parte do volume: critérios de precificação e tabelas de tarifas, regras de elegibilidade de subscrição por ramo, parâmetros de cálculo de prêmio e franquia, critérios de bloqueio de emissão. Cada uma tem características diferentes em termos de complexidade técnica e risco de migração.

Uma observação prática: algumas regras que parecem simples no ticket são complexas na implementação porque têm dependências invisíveis com outros cálculos. O mapeamento precisa incluir não só a regra em si, mas as entidades de dados que ela consome e os processos que dependem do resultado. Esse trabalho TI e negócio precisam fazer juntos, o que já é uma mudança de dinâmica relevante.

O erro mais comum nessa fase é documentar regras sem envolver quem as define no negócio. TI faz o levantamento técnico e descobre, na fase seguinte, que a regra implementada no código diverge do que o atuário ou o subscritor entende como política vigente. Essa divergência precisa ser resolvida antes da migração, não depois.

Fase 2: externalização incremental, começando pelas mais voláteis

A estratégia segura é migrar em fatias funcionais, não por camada técnica. Significa escolher um produto, um ramo ou um processo específico, migrar todas as regras daquele escopo para a camada externalizada, validar em produção com volume real e só então expandir.

Regras que mudam com frequência são as que mais custam quando estão no código, e são as que mais benefício imediato trazem quando externalizadas. Uma seguradora que ajusta tabelas de precificação do ramo residencial toda vez que o mercado de resseguros se move, ou toda vez que entra um novo canal de distribuição, vai sentir o resultado em semanas. O ciclo de mudança que levava dias passa a levar minutos. Esse resultado visível dentro do time é o que mantém o projeto vivo.

Em um caso que acompanhei de perto, uma seguradora de médio porte que passou por esse processo relatou redução expressiva no tempo de revisão de regras de subscrição e precificação residencial. O responsável pela área de TI descreveu que a equipe passou a ter controle direto sobre as alterações sem precisar abrir chamado para cada ajuste de tabela. Esse tipo de resultado no escopo piloto é o argumento interno mais eficaz para expandir a migração para outros ramos, e é também onde eu errei na primeira vez que conduzi uma migração desse tipo: subestimei quanto tempo levaria para a equipe de negócio se sentir confortável operando o motor sem intermediação técnica. O treinamento foi insuficiente e o piloto atrasou três semanas por isso.

Durante a migração, os dois sistemas precisam rodar em paralelo por um período de validação. O motor externalizado processa as mesmas entradas que o sistema legado, e os resultados são comparados automaticamente. Divergências são investigadas, mapeadas para diferenças de interpretação de regra ou bugs de migração, e corrigidas antes do corte.

Esse período de coexistência tem um custo operacional real: duas camadas para monitorar, duas fontes de verdade para reconciliar, risco de que uma mudança de emergência seja feita no sistema legado e não replicada para o motor. A governança desse período é o que determina se a migração vai ser segura ou caótica.

Fase 3: governança do período de coexistência

Essa é a fase que os projetos de migração costumam subestimar. A decisão técnica de externalizar as regras é relativamente direta. A gestão do período em que dois sistemas coexistem em produção é onde os projetos travam.

Antes do corte, três coisas precisam estar definidas.

Primeiro, uma política clara sobre onde as mudanças de regra são feitas durante a coexistência. A resposta certa é: somente no motor externalizado, com propagação para o legado se necessário. Quando a urgência decide, o legado recebe patches diretos, o motor fica desatualizado, e a divergência se acumula até que a validação paralela perde significado.

Segundo, um critério objetivo de saída: qual percentual de divergência entre os dois sistemas é aceitável antes do corte. Definir esse número antes de começar evita negociação sob pressão durante o projeto. Zero seria o ideal, mas a realidade operacional frequentemente exige um limiar explícito, e é melhor ter esse número acordado do que descobrir que cada área tem uma resposta diferente quando o projeto já está em andamento.

Terceiro, responsabilidade clara sobre quem opera o motor. O motor externalizado muda de dono em relação ao código: quem define as regras no negócio precisa ser capaz de operar a ferramenta. Isso implica treinamento, mas também mudança de processo. O atuário que antes enviava um e-mail para TI com o ajuste de tabela agora configura diretamente, com fluxo de aprovação interno ao motor. Essa mudança de hábito é subestimada nos planos de migração e é frequentemente o maior obstáculo operacional.

Quatro iniciativas que qualquer equipe pode estruturar nos primeiros noventa dias para manter o projeto com resultado visível:

Um painel de visibilidade das regras em produção. Mesmo antes de externalizar qualquer regra, documentar no motor as regras vigentes com data de última alteração e responsável já gera valor imediato: o negócio passa a ter visibilidade do que está em operação, e TI passa a ter um registro auditável que antes não existia.

Um fluxo de simulação. Uma vez que as primeiras regras estão no motor, o negócio pode simular o impacto de uma alteração antes de colocá-la em produção. Essa capacidade simplesmente não existe quando a regra está no código. Uma fintech de pagamentos que passou por esse processo saiu de menos de dez simulações de preço por semana para mais de 150, o que mudou a forma como a equipe comercial avaliava novas estratégias de precificação.

A rastreabilidade retroativa. Migrar as regras para o motor com data de vigência histórica, reconstruindo o versionamento que o commit não oferece. Não é obrigação imediata, mas é o que vai responder à pergunta da fiscalização sobre decisões tomadas antes da migração.

Um relatório de cobertura de migração. Um número simples, atualizado semanalmente: quantas regras identificadas já estão no motor versus quantas ainda estão no código. Esse indicador mantém o projeto visível para a liderança e cria pressão positiva para avançar.

O que não fazer: os erros mais comuns

Migrar tudo de uma vez. Projetos que tentam externalizar todas as regras em um grande corte invariavelmente encontram dependências inesperadas, travam em produção, geram pressão para reverter e terminam descreditados. A abordagem incremental é mais lenta no início e mais sustentável no total.

Deixar a governança para depois. A definição de quem pode mudar regras, qual fluxo de aprovação é necessário e como as versões são documentadas precisa existir antes do primeiro deploy em produção. Governança construída retroativamente não funciona porque os hábitos já foram formados sem ela.

Ignorar a camada de cálculo. Em seguradoras, separar as regras de elegibilidade e subscrição sem abordar o motor de cálculo de prêmio resolve metade do problema. Uma cotação de seguro residencial pode envolver 30 a 50 variáveis: perfil do bem, localização, histórico de sinistros, coberturas contratadas, franquias, descontos por canal, fator regional de risco, vigência. Quando essa lógica permanece hardcoded no serviço de cotação, o corretor que cotou usando uma plataforma de multicálculo pode estar operando com uma tabela desatualizada sem saber. A SUSEP exige que cada versão da tabela de cálculo seja auditável com data de vigência e fórmula exata aplicada. Histórico de commit não atende.

Tratar como projeto de TI. A externalização de regras só gera valor se o negócio assume responsabilidade pelas regras externalizadas. Se TI migra para o motor e o atuário continua enviando e-mail pedindo para TI fazer a alteração, o ciclo mudou de camada mas não mudou de velocidade. O objetivo é que o responsável pela regra no negócio possa alterá-la diretamente, com governança, sem intermediação técnica para mudanças operacionais