São 14h de uma terça-feira e o gerente de produtos está olhando para um relatório de conciliação que ninguém queria ver: 1.200 apólices de auto emitidas nas últimas 48 horas com prêmio entre R$ 3 e R$ 11 abaixo da tarifa registrada na SUSEP. O LLM interpretou uma promoção de marketing como regra de desconto vigente e aplicou no cálculo. Sistematicamente. Em cada emissão.

O CTO tem duas opções. Suspender emissão (com impacto estimado em R$ 180 mil por dia em vendas paralisadas). Ou manter a operação com carteira já exposta a autuação. A pergunta não é se há problema regulatório. É quanto vai custar resolvê-lo.

Dois engenheiros seniores entram em modo de guerra. O hotfix vai exigir, em implementações similares, entre 12 e 16 horas de trabalho concentrado, janela de manutenção e reprocessamento manual de centenas de endossos. Com motor de cálculo externo, essa correção seria uma alteração de configuração. Sem deploy. Sem janela. Sem modo de guerra.

Essa é a tese: usar LLM como camada de cálculo em precificação de seguros não é uma aposta técnica arrojada. É uma decisão arquitetural com custo regulatório mensurável e auditoria impossível de produzir.

O Problema Não Está no Prompt

O erro arquitetural central é tratar o LLM como camada de negócio em vez de camada de linguagem. Não é falha de qualidade de prompt. É uma propriedade estatística do modelo.

LLMs são otimizados para coerência textual. Não para invariância numérica. Com temperatura maior que zero(configuração padrão em praticamente toda implementação conversacional) a mesma entrada pode produzir saídas numericamente distintas entre chamadas consecutivas. Não é bug. Esse é o comportamento esperado do modelo. Em geração de texto, é uma vantagem. Em cálculo de prêmio, é uma exposição direta.

O anti-pattern mais perigoso em produção é o que a indústria chama de "prompt engineering como substituto de regra de negócio": instruir o LLM a "nunca aplicar desconto acima de X%" ou "respeitar a margem mínima de 3%". Essa instrução não é uma restrição técnica. É uma sugestão probabilística. O modelo vai respeitar o critério na maioria das execuções até que o contexto da conversa, uma variação de temperatura ou uma combinação de coberturas que o modelo nunca viu no treino produza um resultado fora da faixa.

O mercado tende a acreditar que um range check resolve: "se o prêmio calculado estiver entre R$ X e R$ Y, valida e emite". Não resolve. Range check não detecta violações de regra de margem que ainda caem dentro do intervalo esperado. Não detecta combinações de cobertura inválidas com prêmio aparentemente correto. Não detecta desconto não registrado que, por coincidência de arredondamento, produziu número dentro da banda de sanidade. O que estava fora da faixa nas 1.200 apólices do exemplo acima poderia, em outro cenário, estar dentro do range e passar pelo filtro — com a seguradora igualmente exposta e sem saber.

‍ O Que Está em Jogo Quando o Cálculo Erra

Seguros de automóvel no Brasil tipicamente operam com margem técnica na faixa de 2 a 5% sobre o prêmio puro. Um desconto espúrio de 3% aplicado pelo modelo não reduz a margem, mas a elimina totalmente. Em produtos massificados com ticket médio de R$ 80 por mês, uma variação de R$ 4 no prêmio calculado incorretamente em 10 mil apólices representa exposição de ordem de R$ 480 mil anuais antes de qualquer sinistro ser registrado.

O custo do incidente de terça-feira: reprocessamento manual de 1.200 endossos em backoffice supera R$ 40 mil por evento. O deploy emergencial, com três engenheiros seniores e janela de manutenção, acrescenta entre R$ 15 mil e R$ 22 mil em custo direto. O risco regulatório: multa SUSEP por comercialização fora da tarifa registrada parte de R$ 10 mil e pode chegar a 1% do prêmio total emitido no período. Em carteiras médias, isso representa entre R$ 200 mil e R$ 800 mil por autuação.

Um incidente descoberto pelo cliente custa, em média, 8 a 12 vezes mais do que o mesmo erro detectado internamente antes da emissão. A diferença está no custo reputacional, no tempo de gestão e no precedente que abre para contestação de toda a carteira no período.

A Separação de Camadas Que Torna a Inovação Segura

A solução não é eliminar LLM do processo de precificação. É colocá-lo no lugar certo.

Seguradoras que operam com motor de cálculo externalizado tratam o LLM como acelerador de front-end: o modelo interpreta a intenção do corretor ou do cliente em linguagem natural, monta o contexto da proposta, identifica coberturas e perfil do risco. A partir daí, uma API de cálculo determinístico recebe os parâmetros validados, executa a matemática com as tabelas tarifárias vigentes e retorna o prêmio. Auditável linha a linha. Com versão de tabela persistida. Com data e autorização de cada alteração registradas.

O trade-off real é latência: uma chamada adicional de API acrescenta entre 80 e 150 milissegundos ao tempo de resposta. Com a SUSEP exigindo que cada versão da tabela de cálculo seja auditável (fórmula exata aplicada, data de vigência, quem autorizou a alteração) esse trade-off não é negociável.

O que muda operacionalmente: atualização tarifária deixa de ser projeto de TI. Com cálculo embutido no código, alterar uma tabela exige especificação técnica, desenvolvimento, QA de cada combinação de variáveis e deploy. Com motor externalizado, o atuário configura a nova fórmula diretamente, com versionamento automático e vigência programada. Em mercados com reajuste frequente como auto e saúde, isso representa capacidade de responder a uma mudança regulatória de precificação em menos de 24 horas. O ciclo alternativo, em implementações sem essa separação, leva de duas a seis semanas entre análise, desenvolvimento, teste e deploy.

Como Fica em Operação Real

Uma seguradora de médio porte com portfólio diversificado em ramos de danos implementou separação estrita entre camada de linguagem e motor de cálculo após um incidente de prêmio incorreto detectado na conciliação. O Coordenador de TI de Desenvolvimento descreveu o resultado com a precisão que importa: o negócio passou a ter controle total sobre as alterações de tabela sem abrir ticket para engenharia, com audit trail completo e fórmulas versionadas por vigência.

O que mudou nos números: aprovação de nova tabela de precificação caiu de quinze dias úteis para dois dias. Simulações de cenário de preço (que o time de produtos evitava fazer porque cada hipótese virava solicitação para TI) saltaram de menos de dez por semana para mais de cento e cinquenta. O atuário passou a testar hipóteses de precificação sem intermediário. A engenharia parou de receber tickets de manutenção de tabela e voltou a entregar produto.

---

Seguradoras que mantêm cálculo de prêmio acoplado ao código estão, neste momento, a um evento de alucinação de distância de uma conciliação como a de terça-feira.

Hoje custa no backoffice. Em 3 meses custa no balanço. Em 2026 custa na auditoria.

A pergunta não é se LLM pode participar do processo de cotação. Pode, e há vantagem competitiva real em usá-lo bem. A pergunta é quem executa a matemática — e se essa execução produz evidência auditável ou apenas um número que ninguém consegue reconstituir quando a SUSEP perguntar de onde veio.