Como a separação entre regras de negócio e código transforma agilidade regulatória em vantagem competitiva durável no mercado de seguros brasileiro.
Seguros
# Agilidade regulatória como moat competitivo no mercado de seguros brasileiro
Três meses para lançar um produto novo. Seis meses. Um ano. Em algumas seguradoras brasileiras, o tempo entre a decisão comercial de lançar um produto e a primeira apólice emitida ainda é medido em trimestres.
No mesmo período, uma concorrente com arquitetura diferente já ajustou a tabela de tarifas duas vezes, respondeu a uma mudança de mercado com endosso relâmpago e lançou cobertura adicional que a primeira ainda não tinha aprovado internamente.
Esse gap existe, tem causa identificável e está se tornando irreversível para quem não age agora.
A discussão sobre time-to-market em seguros costuma ser tratada como problema de processo: fluxo de aprovação, alinhamento entre atuária e produto, ciclo de homologação junto à SUSEP. Esses fatores importam. Mas nenhum deles é o principal gargalo.
O principal gargalo é arquitetural. As regras de negócio vivem dentro do código do sistema. Quando o negócio precisa mudar um critério de subscrição, ajustar uma franquia, criar um desconto por canal ou alterar uma fórmula de cálculo de prêmio, a mudança precisa passar por desenvolvimento de software: ticket para TI, especificação técnica, desenvolvimento, revisão, ambiente de homologação, deploy.
Esse ciclo leva de 15 a 30 dias para uma mudança de regra simples. Para mudanças que tocam múltiplos ramos ou integram com plataformas de multicálculo, o ciclo ultrapassa 60 dias. Há casos documentados em que mudanças de tabela de tarifas aguardaram 3 sprints antes de entrar em produção porque a engenharia estava comprometida com desenvolvimento de produto.
Em seguradoras com regras externalizadas adequadamente, a mesma mudança leva minutos. O atuário ou o gestor de produto acessa a interface de gestão de regras, altera o parâmetro, versiona com data e responsável, e a nova lógica entra em vigor sem envolver nenhum engenheiro.
Semanas de espera de um lado, minutos do outro. Essa é a dimensão real da diferença.
A referência europeia vale pela escala do experimento. Com a implantação do Solvência II, o mercado segurador europeu foi forçado a estruturar de forma muito mais rigorosa a governança sobre suas regras de decisão: quem autorizou, quando entrou em vigor, qual fórmula foi aplicada em cada apólice, como as mudanças foram documentadas.
O resultado foi uma aceleração involuntária da separação entre regras de negócio e código. Seguradoras que já tinham essa separação responderam às exigências regulatórias com custo operacional significativamente menor. As que tinham regras embutidas no código gastaram ciclos enormes reconstruindo audit trail a partir de histórico de commits, que não é a mesma coisa que uma trilha de decisão governável.
O paralelo com o Brasil não é perfeito, mas é próximo o suficiente para ser instrutivo. A Resolução CNSP 395/2020 e a Circular SUSEP 667 apontam na mesma direção que o Solvência II apontou anos antes: a fiscalização vai perguntar como a decisão foi tomada, quem autorizou e qual regra estava vigente no momento do sinistro ou da recusa. Seguradoras sem resposta estruturada para essa pergunta estão correndo um risco que ainda não apareceu no balanço.
Coloque em termos financeiros. Uma seguradora lança um produto de seguro residencial. A tabela de tarifas precisa de ajuste após os primeiros 90 dias porque o perfil de risco observado em sinistros reais está desalinhado com a premissa atuarial original. Situação normal, previsível, esperada em lançamentos.
Com regras no código: o gestor de produto abre ticket, a engenharia prioriza na próxima sprint, a mudança entra em desenvolvimento, passa por homologação, vai a produção. Seis semanas depois, a tabela está atualizada. Enquanto isso, todas as cotações feitas via plataforma de multicálculo estão usando o prêmio desalinhado. Parte da produção está sendo precificada abaixo do risco real.
Com regras externalizadas: o atuário ajusta o parâmetro diretamente na interface de gestão, a mudança entra em vigor no mesmo dia, todas as cotações subsequentes refletem a tabela correta.
Seis semanas de diferença multiplicadas pelo volume de cotações do período. O impacto na margem é real e calculável.
O padrão que se observa em operações que fizeram essa transição aponta para redução expressiva de tickets urgentes de TI, porque uma parcela relevante do backlog de engenharia nas operações que não fizeram a separação é preenchida por mudanças de regra disfarçadas de desenvolvimento. Esse volume tem custo direto e custo de oportunidade: cada sprint consumido por mudança de regra é um sprint que não entregou feature de produto.
Há um ângulo competitivo que vai além do custo operacional e que costuma ser subestimado: a capacidade de diferenciar por critério de underwriting com velocidade.
A guerra de preço em seguros tem limite. Margens já comprimidas limitam quanto uma seguradora pode reduzir o prêmio comercial sem comprometer o prêmio puro. A competição por critério de subscrição abre espaço diferente: quem consegue criar coberturas mais granulares, responder a segmentos específicos com produtos customizados e ajustar rapidamente a política de franquia por canal ou região conquista uma posição que não é facilmente copiável por preço.
O problema é que criar essa granularidade exige mudar regras, frequentemente. E mudar regras embutidas no código é lento e caro.
Uma seguradora que em um trimestre consegue lançar três variantes de produto residencial para perfis distintos de cliente, ajustar a política de subscrição para regiões com histórico de sinistro elevado e criar um desconto específico para canal digital sem afetar o canal de corretores está operando em velocidade que uma concorrente com regras no código simplesmente não alcança.
Esse diferencial de velocidade vira barreira de entrada, por capacidade de executar a estratégia de negócio mais rápido do que o mercado consegue copiar.
A SUSEP tem avançado em exigências de explicabilidade sobre decisões automatizadas. A pergunta que fiscalizações e auditorias fazem é objetiva: qual regra estava vigente quando essa decisão foi tomada, quem autorizou essa versão da regra, e onde está o registro disso.
Uma operação com gestão de regras externalizada acessa o sistema, localiza a versão ativa na data do evento, visualiza o autor da alteração, o timestamp da aprovação e a fórmula exata aplicada. Resposta disponível em minutos, sem envolver engenharia.
Uma operação sem essa estrutura precisa reconstruir o estado do sistema na data do evento a partir de histórico de commits no repositório de código, que não foi desenhado para ser audit trail regulatório. O processo leva dias, envolve a área de TI, e a resposta muitas vezes tem lacunas que a fiscalização não aceita como suficientes.
Essa diferença já chegou ao bolso de operações no mercado europeu, em forma de multa e exigência de retrabalho retroativo. No Brasil, o movimento regulatório indica que a mesma pressão está chegando. A questão é se a operação vai estar preparada antes ou depois da pergunta ser feita.
Um case de fora do setor ilustra o argumento de forma concreta. Uma locadora com centenas de lojas físicas distribuídas pelo Brasil precisava que a política de preço de cada loja respondesse às condições locais de mercado: sazonalidade, concorrência regional, disponibilidade de frota. Com regras de precificação dentro do sistema central, qualquer ajuste exigia envolver TI. O ritmo de mudança era de semanas. A loja que precisava ajustar preço para responder a uma promoção de um concorrente local ficava sem capacidade de reação.
Após a separação, o gestor regional atualiza a regra de precificação localmente, a mudança entra em vigor na loja em minutos, com rastreabilidade completa de versão e autorização.
O paralelo em seguros é direto: a corretora que cotou ontem pode estar usando uma tabela que foi atualizada hoje. Com motor externalizado, todas as cotações refletem a regra atual. Com lógica no código, a janela entre uma mudança de produto e sua chegada ao canal de distribuição pode ser de semanas, durante as quais o corretor está vendendo com critérios desatualizados.
Moat competitivo em seguros costuma ser discutido em termos de base de dados atuariais, relacionamento com corretores e escala de capital. Esses fatores são reais. Mas existe uma barreira operacional que não aparece nos slides de estratégia e que está se tornando mais relevante com a aceleração regulatória e a pressão por personalização de produto.
A capacidade de mudar critério de negócio em horas, com trilha de auditoria embutida, demora anos para ser construída. Uma vez construída, é difícil de ser replicada por um entrante que ainda não fez essa transição.
Seguradoras que tratam essa capacidade como detalhe de TI vão continuar medindo o tempo de mercado em trimestres, respondendo a mudanças regulatórias com esforço retroativo caro e pagando o custo de oportunidade de uma engenharia que deveria estar construindo produto mas está gerenciando mudança de regra.
Pega os lançamentos de produto do último ano na sua operação. Conta quantos atrasaram por causa de ajuste de regra de subscrição ou tabela de tarifas que precisava passar por TI. Esse é o custo de oportunidade real da arquitetura atual, e ele tende a crescer conforme o ritmo de mudança regulatória e competitiva aumenta.
