Quanto custa manter regras de negócio no código? Um cálculo direto de custo de engenharia, dívida técnica e ROI para CIOs de seguradoras.
Seguros
# O custo real de manter regras de negócio acopladas ao código: um cálculo para CIOs de seguradoras
Toda conversa sobre externalizar regras de negócio começa no mesmo lugar: a justificativa técnica. Acoplamento, manutenibilidade, separação de responsabilidades. O arquiteto apresenta o argumento, o CIO ouve, concorda em tese e pergunta o que pergunta sempre: "Qual é o retorno disso?"
A resposta costuma vir em forma de slide. Fala de agilidade, de autonomia do negócio, de tempo de deploy. Bonito. Ninguém discute. O projeto vai pra fila.
Vai pra fila porque a pergunta certa não foi respondida. A pergunta certa é: quanto custa, por ano, manter as regras de negócio onde estão? Custo direto, custo de oportunidade, custo de risco. Três números que, somados, mudam a conversa de priorização.
A maioria dos orçamentos de TI de seguradoras contabiliza o custo de engenharia como produção de software. Recursos, sprints, entregas. O que raramente aparece nessa conta é o custo de manutenção de critério, que é diferente de manutenção de código.
Manutenção de critério é o que acontece quando o produto quer ajustar o fator de risco de um CEP específico. Ou quando o atuário precisa mudar a fórmula de prêmio puro por conta de atualização de frequência de sinistros. Ou quando o comercial pede desconto por canal que não estava previsto na tabela original. Nenhuma dessas mudanças é desenvolvimento de software, conceitualmente. Com as regras embutidas no código, todas elas viram tickets para engenharia.
O problema real de mensuração começa aqui. Esses tickets raramente são classificados como "manutenção de regra de negócio" no backlog. Aparecem como bug, melhoria, ajuste de comportamento. O custo se esconde na categorização errada.
O ponto de partida é mecânico. Um ticket típico de mudança de regra de negócio em uma seguradora de médio porte envolve:
Com custo médio de hora de engenheiro sênior no Brasil em 2026 na faixa de R$ 120 a R$ 180, um ticket desse tipo sai entre R$ 11.500 e R$ 17.000 quando você contabiliza as horas totais do par, não só quem "fez" a tarefa.
Agora conta a frequência. Em implementações que acompanhamos em seguradoras com 20 ou mais ramos ativos, 40% do backlog de engenharia são, na prática, mudanças de regras de negócio disfarçadas de desenvolvimento. Para uma equipe que fecha 50 tickets por mês, isso são 20 tickets de regra todo mês. O equivalente a um time de 4 pessoas trabalhando exclusivamente nesse tipo de demanda, sem gerar uma linha de feature nova.
A conta anual: 240 tickets de regra por ano, a R$ 14.000 cada (ponto médio), resulta em R$ 3,36 milhões de custo direto de engenharia só pra manter critérios que o negócio precisaria mudar de qualquer forma.
Esse número quase nunca aparece no orçamento consolidado porque está diluído em sprints, categorizado como "desenvolvimento" e distribuído entre diferentes times.
Mudança de tabela de tarifas antes de um fechamento de produto. Atualização de fator regional por conta de evento climático que afeta o risco. Ajuste de cobertura por mudança regulatória com prazo curto da SUSEP. Qualquer um desses cenários transforma o ticket padrão em ticket urgente, e ticket urgente tem custo diferente.
Urgência em engenharia significa interromper o que estava planejado, remanejar o sprint, colocar alguém em regime de atenção dividida e aceitar o risco de regressão por mudança feita com pressa.O custo efetivo de um ticket urgente fica entre 1,8x e 2,5x o custo do ticket planejado, porque carrega o overhead de interrupção e o risco de retrabalho posterior.
Esse é o número que os CIOs mais resistem a calcular, porque exige atribuir valor a algo que não aconteceu. É exatamente o exercício que muda a conversa de priorização.
Uma seguradora que precisa lançar um produto novo, ajustar a precificação de um produto existente para um canal específico, ou adaptar coberturas para uma parceria com uma plataforma de multicálculo, passa por um ciclo que, com regras embutidas no código, raramente é menor do que 60 dias. Spec com o atuário, tradução para desenvolvimento, QA de cálculo, validação de compliance, deploy. Sessenta dias em que o produto novo não está no mercado.
Quanto vale 60 dias de produto parado? O exercício é direto: qual é o prêmio médio por apólice do produto em questão, multiplicado pela estimativa de apólices por mês naquele canal? Se o produto residencial projeta 500 apólices por mês com prêmio médio de R$ 800, o custo de dois meses de atraso é R$ 800 mil em receita que não entrou, ou entrou mais tarde do que poderia ter entrado.
Com motor de regras externalizado, o atuário configura a fórmula diretamente. O ciclo vai de 60 dias para menos de uma semana em operações maduras que acompanhamos, para produtos que reutilizam componentes de cálculo existentes. Ajustes em tabelas vigentes ficam abaixo de 24 horas.
O custo de oportunidade não é hipotético. É receita com endereço que ficou na fila porque a arquitetura não permitia velocidade de critério.
Seguradoras que distribuem via broker ou plataforma de multicálculo têm um problema adicional que raramente aparece contabilizado: o corretor que cotou ontem pode estar usando tabela diferente da tabela que o sistema aplica hoje.
Com lógica de cálculo hardcoded no serviço, uma mudança de produto exige re-deploy. Enquanto o deploy não aconteceu, o motor responde com os parâmetros antigos. A cotação aprovada pelo corretor não reflete o prêmio que o sistema vai calcular no momento da emissão. Isso gera retrabalho na emissão, insatisfação do corretor, às vezes reclamação do segurado e, dependendo da magnitude da diferença, exposição de margem que não estava prevista.
O custo desse desalinhamento é invisível no backlog porque aparece como "exceção de emissão" ou "ajuste manual", não como consequência de decisão arquitetural.
Essa é a linha com o maior valor absoluto e a menor probabilidade de aparecer na planilha de ROI de TI. O custo regulatório é incerto no momento, e incerteza tende a ser omitida de cálculos de aprovação de projeto.
A Resolução CNSP 395/2020 e a Circular SUSEP 667 avançam na direção de explicabilidade de decisão automatizada. A pergunta que a fiscalização já faz, e vai fazer com mais frequência, é direta: como essa decisão foi tomada e quem autorizou? Para subscrição, para cálculo de prêmio, para negação de sinistro.
Com regras embutidas no código, a resposta que o time consegue dar é o histórico de commit do repositório. Qual versão do código estava em produção naquela data, qual foi a última mudança relevante, quem aprovou o pull request. Isso é um histórico de alteração de código. Audit trail de decisão de negócio é outra coisa.
Audit trail de decisão de negócio registra: qual regra foi aplicada, qual versão dessa regra estava vigente naquela data, quem autorizou a publicação dessa versão, qual critério foi executado para aquele conjunto de variáveis específico.
Em caso de não conformidade identificada em processo de fiscalização da SUSEP, as penalidades variam de advertência até suspensão de operação em determinados ramos. O custo financeiro direto das penalidades é secundário frente ao custo de interrupção operacional e ao custo reputacional com parceiros e corretores.
Mas há um custo menor que é certo, e esse cabe na planilha: preparar resposta para uma auditoria com arquitetura que não foi desenhada para isso. Horas de engenheiro reconstituindo o estado do sistema em uma data específica, horas de área jurídica interpretando o que o código fazia naquele momento, horas de compliance tentando traduzir lógica de desenvolvimento em linguagem de critério de negócio. Em operações que passaram por esse processo, o custo de preparação de resposta para uma única auditoria técnica ficou entre R$ 150 mil e R$ 400 mil, dependendo da complexidade do ramo envolvido.
O framework é intencional na sua simplicidade. Três números, com os dados que o próprio CIO já tem ou pode levantar em 48 horas:
Soma as três. O resultado é o custo anual de manter as regras onde estão. Coloca ao lado o custo de mover as regras para uma camada separada. A comparação é o argumento.
Em implementações que acompanhamos em seguradoras com 15 ou mais ramos ativos, a diferença entre as duas colunas fechou a discussão de priorização em menos de uma reunião. Uma fintech de pagamentos com 200 tickets de TI por mês só para manutenção de preços reduziu esse número para menos de 20 após externalizar a camada de regras, redução de 90%. Uma locadora com 180 lojas ficou com a precificação unificada e atualizada em minutos, contra dias de ciclo anterior.
A mudança mais difícil de colocar no cálculo é comportamental, mas ela aparece nos números depois: quando o negócio sabe que pode mudar uma regra sem abrir ticket para TI, o volume de mudanças testadas aumenta. A seguradora que antes hesitava em ajustar o fator de risco de um CEP específico porque o ticket levaria duas semanas passa a fazer esse ajuste em horas, testando variações, medindo resultado, iterando. A capacidade de experimentação de critério, que é o que diferencia precificação competitiva de precificação estática, cresce com a separação de camadas.
Isso não aparece na planilha de ROI inicial. Aparece na comparação de resultado de produto depois de 6 meses.
A conversa sobre externalizar regras de negócio quase sempre começa no argumento técnico e fica presa nele. O arquiteto fala de acoplamento. O CIO ouve. Concorda. Aprova outra coisa.
O que muda a conversa é o número que o próprio CIO pode calcular com dados que já tem. Pega os tickets do último trimestre. Classifica, de forma honesta, quantos são mudança de regra de negócio disfarçada de desenvolvimento. Multiplica pelo custo real por ticket, incluindo interrupção de sprint. Coloca o ciclo de lançamento de produto em dias e o que ficou na fila esperando. Adiciona o que a área jurídica e de compliance gastou da última vez que precisou reconstituir uma decisão para uma fiscalização.
Esse número encerra a discussão de priorização.
O framework de custo se aplica a seguradoras de qualquer porte?
O modelo se aplica a qualquer operação onde mudanças de regra de negócio geram tickets para engenharia. O custo absoluto varia com o tamanho do time e o volume de mudanças, mas a estrutura das três linhas (custo direto, custo de oportunidade, custo de risco) é válida independente do porte. Seguradoras menores tendem a ter time de engenharia menor, o que torna cada ticket de regra proporcionalmente mais caro porque interrompe uma parcela maior da capacidade disponível.
Quanto tempo leva uma implementação de motor de regras externalizado?
Depende da complexidade dos ramos envolvidos e do estado atual da base de código, mas em implementações que acompanhamos o ciclo de implementação inicial ficou entre 4 e 12 semanas para os primeiros ramos em produção. A curva de retorno é progressiva: os primeiros produtos externalizados já geram redução de tickets, e a velocidade de publicação de regras melhora a cada novo ramo incorporado.
A separação de regras resolve o problema de conformidade com a SUSEP?
Resolve a parte arquitetural do problema. Um motor de regras externalizado gera naturalmente o audit trail que a fiscalização exige: versão da regra aplicada, data de vigência, quem autorizou a publicação. Conformidade plena também depende de processo: quem autoriza a publicação de uma nova versão de regra, qual o fluxo de validação antes de ir a produção, como o atuário e o compliance participam do ciclo. A arquitetura habilita a conformidade, o processo a garante.
O atuário consegue de fato operar o motor sem depender de TI?
Em implementações maduras, sim. O atuário configura fórmulas, publica versões e testa cenários sem abrir ticket para engenharia. A curva de aprendizado existe e varia com o perfil da pessoa e a complexidade das fórmulas envolvidas, mas o ganho de autonomia operacional é consistente. O papel de TI muda: em vez de executar mudanças de critério, passa a sustentar a infraestrutura do motor e integrar com os sistemas que consomem as regras.
Como tratar regras com dependências complexas entre coberturas e franquias?
Dependências entre reg
