Padrão arquitetural para integrar LLM e BRMS em precificação dinâmica: separação de camadas, auditabilidade e rastreabilidade para operações reguladas.
Tecnologia
# Como integrar LLM e BRMS em fluxos de precificação: padrão arquitetural para CTOs
O atuário define uma nova regra de fator regional para o ramo residencial. A mudança é pequena: ajuste de 8% no fator de risco para dois CEPs específicos, baseado em dados históricos de frequência de sinistros. Do ponto de vista do negócio, a decisão está tomada. Do ponto de vista da TI, é um ticket que vai entrar na fila, virar tarefa de sprint, passar por QA, e chegar em produção em algum momento entre 10 dias e 6 semanas, dependendo de qual engenheiro estava disponível e quantas urgências apareceram no meio do caminho.
Esse ciclo é o problema. A IA agêntica prometeu resolver a velocidade. O BRMS existe para resolver a governança. A tensão que a maioria dos CTOs vive hoje é que as duas abordagens estão sendo adotadas em paralelo, sem que ninguém tenha desenhado como elas se encaixam.
Este artigo documenta o padrão arquitetural que resolve essa tensão: como conectar um LLM na camada de interpretação, um motor de regras na camada de decisão, e um agente orquestrando o fluxo entre eles, com rastreabilidade em cada etapa.
A adoção de LLMs em fluxos de precificação costuma começar pelo caso mais óbvio: o modelo interpreta input não-estruturado, extrai variáveis, e devolve uma resposta. Funciona bem na demo. O problema aparece quando alguém pergunta como aquela decisão foi tomada.
LLMs inferem padrões a partir de dados históricos. Eles não executam regras explícitas, e por isso não são auditáveis da forma que o regulador exige. A Circular SUSEP 667 e a Resolução CNSP 395/2020 demandam explicabilidade de decisões automatizadas: qual critério foi aplicado, qual versão estava em vigor, quem autorizou. Um modelo de linguagem não responde a nenhuma dessas perguntas com precisão determinística.
Um motor de regras puro tem o problema inverso: executa com precisão cirúrgica aquilo que foi configurado, mas não sabe o que fazer com uma proposta que chegou por texto livre, uma cotação descrita via chatbot, ou uma variável extraída de um documento de apólice digitalizado. BRMS foi construído para lógica estruturada, não para interpretar linguagem natural.
A fronteira útil entre os dois é mais simples do que parece:
Essa separação é o que torna o sistema auditável em produção.
O LLM opera na fronteira entre o input do usuário ou sistema externo e o domínio estruturado da aplicação. Aqui ele faz o que faz bem: recebe texto livre, documentos, dados parcialmente formatados, e devolve um objeto JSON normalizado com as variáveis que o motor de regras precisa.
Em um fluxo de cotação de seguro residencial, essa camada recebe a proposta do corretor (que pode vir por formulário, API de multicálculo, ou interface conversacional) e retorna algo como:
```json { "cep": "01310-100", "tipo_construcao": "alvenaria", "area_m2": 87, "valor_bem": 420000, "coberturas_solicitadas": ["incendio", "roubo", "rcf"], "franquia_selecionada": "padrao", "canal": "corretor", "vigencia_meses": 12, "historico_sinistros_declarado": false } ```
Esse objeto normalizado é o que o agente usa para chamar o motor de regras. O LLM estrutura o contexto. Cálculo de prêmio, aplicação de fator de risco e decisão sobre elegibilidade de cobertura ficam fora do seu escopo.
O motor de regras recebe o payload estruturado e executa as regras de negócio configuradas pelo atuário: tabela de tarifas vigente, fatores de risco por CEP e tipo de construção, limites de cobertura por ramo, cálculo de prêmio puro e comercial, franquias aplicáveis, descontos por canal.
A chamada é uma requisição REST simples:
```http POST /api/v1/decisao/precificacao Content-Type: application/json X-Versao-Regras: 2026.09.1 X-Request-ID: req-7f3a1c9e-4b82-4d6f-a391-c2e85d04f1b7
{ "contexto": { "cep": "01310-100", "tipo_construcao": "alvenaria", "area_m2": 87, "valor_bem": 420000, "coberturas_solicitadas": ["incendio", "roubo", "rcf"], "franquia_selecionada": "padrao", "canal": "corretor", "vigencia_meses": 12, "historico_sinistros_declarado": false } } ```
A resposta do motor contém a decisão e o rastro completo de como ela foi tomada:
```json { "request_id": "req-7f3a1c9e-4b82-4d6f-a391-c2e85d04f1b7", "versao_regras": "2026.09.1", "timestamp_decisao": "2026-09-25T14:32:11Z", "resultado": { "elegivel": true, "premio_puro": 1847.60, "premio_comercial": 2214.12, "fator_risco_cep": 1.12, "fator_risco_construcao": 0.95, "desconto_canal_corretor": 0.08, "coberturas_aprovadas": ["incendio", "roubo", "rcf"], "franquia_aplicada": "padrao_residencial_v3" }, "regras_aplicadas": [ "TAB_TARIFAS_RESIDENCIAL_2026Q3", "FATOR_CEP_SP_2026.09", "DESCONTO_CANAL_CORRETOR_VIGENTE", "LIMITE_COBERTURA_RCF_ALVENARIA" ], "autor_ultima_alteracao": "equipe-atuarial@seguradora.com.br", "data_vigencia_tabela": "2026-09-01" } ```
O campo `regras_aplicadas` é o que responde à pergunta da fiscalização. Cada item é uma regra com identificador, versão e data de vigência. O motor não aproxima, não infere: executa a regra configurada e registra qual regra executou.
Uma cotação de seguro residencial envolve 30 a 50 variáveis em interação. Quando essa lógica vive hardcoded no serviço, um ajuste de fator regional exige engenharia, revisão e deploy, com risco de quebrar dependências invisíveis entre cálculos. Com o motor externalizado, o atuário configura o fator novo diretamente, sem abrir ticket, e a mudança entra em vigor na data configurada. O corretor que cota no dia seguinte já usa a tabela nova.
O agente conecta as duas camadas anteriores e mantém o estado da sessão. Ele decide quando chamar o LLM (input chegou desestruturado), quando chamar o motor (contexto já está normalizado), como tratar respostas de erro do motor (inelegibilidade, dados faltantes, regra de subscrição bloqueando cobertura específica), e o que registrar em cada etapa.
A função do agente é garantir que o fluxo aconteça na ordem certa, com o componente certo, e que cada chamada seja rastreável. O ponto de decisão humana fica explícito na configuração do agente: quais situações disparam revisão manual (proposta acima de determinado valor de bem, combinações de cobertura fora da faixa configurada, divergência entre dados declarados e scoring externo).
Isso é diferente de revisão no final do processo. O agente para antes de encaminhar para o motor quando as condições de exceção são atingidas, não depois de o motor já ter calculado o prêmio.
O motor de regras responde em milissegundos. A latência do fluxo completo (LLM extraindo contexto, agente orquestrando, BRMS calculando) é determinada principalmente pelo tempo de inferência do LLM, que em APIs de produção fica abaixo de 2 segundos para payloads do tamanho de uma proposta de cotação. Para plataformas de multicálculo, onde o corretor espera resposta em tempo real, esse número é viável.
Quando o atuário muda um fator de risco, a mudança entra em produção em minutos, configurada diretamente na interface do motor, sem ticket para TI, sem impacto no código do agente ou do serviço LLM. O fluxo de deploy não é alterado porque as regras de negócio estão separadas da lógica de orquestração.
Cada decisão do motor retorna com identificador de sessão, versão das regras aplicadas, timestamp e autor da última alteração de cada regra. Quando a SUSEP perguntar qual tabela estava vigente na cotação emitida em setembro de 2026, a resposta está no log estruturado da API.
O histórico de commits do repositório registra que o código mudou. O audit trail do motor registra que a decisão de negócio foi autorizada por quem tinha competência para autorizá-la, com data e identificação da regra vigente. Essa distinção é exatamente o que a Resolução CNSP 395/2020 explicitou ao estabelecer exigências de explicabilidade para decisões automatizadas.
Lançar um produto novo com lógica de cálculo acoplada ao código leva meses em muitas operações: especificação, desenvolvimento, testes de integração, QA, homologação, deploy. Com o motor externalizado, o atuário configura as fórmulas do novo produto diretamente, sem abrir ticket para TI. O agente já está preparado para chamar o endpoint correto com o contexto estruturado.
Em operações de seguro com as quais trabalhamos diretamente, o ciclo de ajuste de produto caiu de semanas para dias após a separação entre camada de regras e código de orquestração. O gargalo deixou de ser a fila de engenharia e passou a ser o tempo de validação atuarial, que é onde deveria estar.
O LLM na camada de interpretação extrai variáveis com erros quando o input é ambíguo ou incompleto. O agente precisa tratar esses casos: o que fazer quando o modelo de linguagem devolve um campo com baixa confiança, quando uma cobertura solicitada não está mapeada no vocabulário do motor, quando o CEP informado não tem fator de risco configurado na tabela vigente.
Essas condições de exceção precisam ser especificadas no design do agente, com comportamentos definidos explicitamente: solicitar dado complementar, escalar para subscrição manual, aplicar regra padrão com flag de revisão. O agente não resolve ambiguidade por conta própria. Quem define o que fazer em cada exceção é o time de negócio, e essa configuração precisa ser versionada com o mesmo rigor que as regras do motor.
Há outro limite: o motor executa as regras que foram configuradas. Se a tabela de tarifas tem um erro de configuração, o motor vai executar o erro com perfeição determinística. A governança da configuração das regras é tão crítica quanto a governança do código que as executa. Com o motor externalizado, esse processo fica rastreável por pessoas de negócio, sem depender de engenharia para revisar.
O motor de regras opera sobre o payload JSON estruturado que o agente envia, independente de o contexto ter sido extraído por GPT-4o, Claude, Gemini, ou um modelo open-source rodando on-premises. A camada de decisão não tem acoplamento com nenhuma implementação específica de LLM.
O ciclo de troca de modelos de linguagem está se acelerando. Uma arquitetura onde a camada de decisão depende de uma implementação específica de LLM cria um acoplamento que vai custar caro na próxima onda de modelos. O motor de regras opera sobre estrutura, não sobre o modelo que gerou essa estrutura.
Essa separação simplifica a estratégia de compliance de forma concreta: o LLM pode ser substituído, atualizado ou trocado sem impacto na auditabilidade das decisões. A rastreabilidade vive no motor, não no modelo.
O padrão acima não é automação completa. O agente está configurado para escalar para revisão humana em condições específicas: valor de bem acima de determinado threshold, combinações de cobertura fora da faixa normal de subscrição, divergência entre dados declarados e bases externas, proposta de pessoa jurídica no ramo residencial.
Essas condições não são tratadas no final do processo, depois que o motor calculou o prêmio. O agente para antes de invocar o motor quando os critérios de exceção são detectados no contexto extraído pelo LLM. A decisão de escalar acontece antes de a decisão de precificação ser tomada.
A diferença prática: revisão humana embutida no fluxo influencia a decisão antes de ela ser materializada. Revisão humana como passo final de checagem chega tarde e ainda assim consome o tempo que a automação deveria ter economizado.
Pegue a última semana de cotações que passaram por revisão manual na sua operação. Verifique em qual ponto do fluxo essa revisão foi acionada: antes do cálculo, depois do cálculo, ou depois da proposta já ter sido enviada ao cliente. Esse dado diz exatamente onde o humano está no seu fluxo hoje.
O padrão documentado aqui não é hipotético. Emerge de implementações em operações com volume real de cotações, onde a pressão de latência e a pressão de auditoria existem ao mesmo tempo. O detalhamento de como estruturar as regras no motor, versionar tabelas de tarifas com data de vigência, e configurar os critérios de exceção no agente está no guia de integração LLM e BRMS da Abaccus.
