Onde IA pode operar em seguros e onde decisão probabilística cria exposição regulatória frente à SUSEP. Distinção arquitetural essencial.
Seguros
# IA no fluxo de decisão em seguros: o que pode e o que não pode ser probabilístico
Você recebe o relatório do modelo. A acurácia em validação é de 91%. O time de dados está orgulhoso. O produto quer colocar isso em produção na próxima sprint.
A pergunta que ninguém faz nessa reunião: acurácia de 91% significa que 9% das decisões estão erradas. Em triagem de e-mails de marketing, isso é irrelevante. Em decisão de aceitação de risco ou pagamento de sinistro, isso é uma decisão regulatória incorreta a cada 11 casos.
O setor de seguros vai enfrentar esse problema em escala nos próximos 18 meses. O ponto de falha não é a qualidade dos modelos de IA. O ponto de falha é a ausência de uma distinção arquitetural clara entre onde probabilidade é aceitável e onde determinismo é obrigatório.
Modelo de IA aprende padrão. Dado input novo, ele infere a saída mais provável com base no que aprendeu. Isso funciona extraordinariamente bem quando o espaço de variação é vasto, o input é não-estruturado e erros isolados têm baixo custo marginal.
Motor de regras executa lógica. Dado input definido, ele aplica critério explícito e retorna resultado idêntico toda vez, em qualquer instância, auditável com data, hora e autoria.
A fronteira entre os dois não é uma escolha de preferência arquitetural. Em seguros, ela é determinada em parte por requisito regulatório. A Resolução CNSP 395/2020 e a Circular SUSEP 667 avançam na direção de exigir que decisões automatizadas sejam explicáveis: qual critério foi aplicado, quando entrou em vigor, quem autorizou. Um modelo probabilístico não responde a essa pergunta de forma satisfatória. Ele responde com "a probabilidade de aprovação foi 73% com base nos padrões históricos". Isso não é uma resposta regulatória.
A consequência prática: há categorias de decisão no fluxo de uma seguradora onde IA pode e deve operar, e há categorias onde decisão probabilística cria exposição regulatória direta.
Um corretor envia e-mail com "quero alterar o beneficiário da apólice 847392 do cliente João". Um segurado pede cotação por WhatsApp com texto livre. Um sinistro chega com três parágrafos descrevendo o ocorrido sem seguir formulário padrão.
Interpretar isso, classificar a intenção, extrair entidades (número de apólice, tipo de solicitação, dados do segurado) e encaminhar para o fluxo correto: IA faz com muito mais escala e velocidade do que regras baseadas em palavras-chave. Se ela classificar errado em 2% dos casos, o impacto é operacional, não regulatório. Um ser humano corrige no próximo passo.
Antes de uma regra de subscrição executar, ela precisa de dados completos: histórico de sinistros, score de risco, perfil do CEP, dados do bem. Parte desses dados vem de fontes externas, parte pode precisar de normalização ou inferência quando há lacunas.
IA opera bem nesse enriquecimento. O que ela produz não é a decisão, é o conjunto de variáveis que alimenta a decisão. A decisão em si fica na camada determinística.
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. Modelo treinado em histórico de cotações pode sugerir faixas de prêmio, identificar outliers, alertar o atuário quando um perfil se distancia significativamente da base histórica.
Isso é suporte à decisão. O prêmio final é calculado pelo motor de cálculo com as fórmulas explícitas da nota técnica atuarial. O modelo sugere, o motor executa.
Identificar padrões que historicamente correlacionam com sinistros fraudulentos é tarefa para IA. Volume alto, variáveis múltiplas, padrões não-lineares: exatamente onde modelo probabilístico ganha de qualquer conjunto de regras manuais.
O resultado disso é um score de risco ou um alerta para revisão humana. A decisão de negar o sinistro não pode ser tomada pelo modelo. Ela precisa ser tomada por regra explícita executada sobre o conjunto de variáveis que inclui o score, ou por um profissional que assina a decisão.
Aceitar ou recusar uma proposta de seguro é uma decisão regulada. Os critérios de subscrição fazem parte da nota técnica atuarial aprovada pela SUSEP. Se um modelo decide recusar uma proposta com base em padrão inferido de dados históricos, e não com base nos critérios explícitos da nota técnica, a seguradora está tomando decisão fora do que aprovou junto ao regulador.
Quando a SUSEP perguntar "por que essa proposta foi recusada?", a resposta precisa ser: "porque o perfil do bem atende ao critério X com valor Y, conforme nota técnica aprovada em data Z". Essa resposta só existe se a decisão foi tomada por regra determinística.
Uma negativa de sinistro que um segurado conteste abre processo regulatório. A SUSEP vai querer saber qual cláusula foi aplicada, qual versão das condições gerais estava vigente na data do sinistro, qual regra executou a decisão.
"O modelo identificou que a probabilidade de elegibilidade era 34%" não é uma resposta para isso. Existe um critério explícito de elegibilidade nas condições gerais. Esse critério precisa ser executado por lógica determinística com versão, vigência e rastreabilidade.
Mais de 70% das reclamações de segurados que chegam à SUSEP envolvem contestação de negativa de sinistro. Esse é exatamente o fluxo onde decisão probabilística cria o maior passivo regulatório.
O prêmio comercial que vai para o segurado não pode resultar de um modelo que inferiu um valor "razoável" com base em histórico. Ele precisa ser calculado com a fórmula exata da nota técnica atuarial: prêmio puro, carregamento, despesas e lucro, com os fatores de risco aplicados conforme tabela vigente.
Quando o motor de cotação responde a uma plataforma de multicálculo em milissegundos com o prêmio correto, ele precisa estar executando essa fórmula exata. Uma mudança de parâmetro atuarial precisa ter data de vigência, autor e aprovação registrados. Com cálculo hardcoded no serviço, isso não existe. Com motor externalizado, é o padrão de operação.
Regra de comissão tem implicação contratual e fiscal. Um corretor que recebe comissão diferente do que está no seu contrato de representação vai reclamar. Uma auditoria que encontrar variação de comissão sem critério explícito vai questionar. Se a lógica de comissionamento estiver num modelo que aprendeu padrões históricos de pagamento, explicar de onde veio um valor específico se torna impossível.
Regra de comissão precisa ser determinística, versionada e auditável.
A distinção fica mais operacional quando você mapeia por fase do fluxo:
Captação e cotação:
Subscrição:
Sinistro:
Comissão e financeiro:
O padrão que emerge: IA opera na entrada do fluxo, interpretando, classificando, enriquecendo. Motor de regras opera na saída, decidindo com critério explícito e auditável. A camada de integração entre os dois é onde a maioria das arquiteturas falha.
O pilot de IA normalmente funciona bem porque opera isolado. O modelo recebe inputs limpos, retorna outputs que um analista valida manualmente, e os números de acurácia são bons.
O problema aparece quando esse modelo precisa alimentar uma decisão automatizada em produção. A pergunta passa a ser: onde vai morar a regra que diz "se o score de fraude do modelo for maior que 0.7, encaminhar para revisão humana; se for menor que 0.3, aprovar automaticamente; entre 0.3 e 0.7, aplicar as regras secundárias de elegibilidade"?
Essa lógica precisa de versão. Precisa de audit trail. O limiar de 0.7 foi definido por quem, quando, com qual aprovação? Quando esse limiar mudar para 0.65 por ajuste de política de risco, isso precisa ser registrado como alteração de regra, com data e autor, não como commit de código que ninguém fora da engenharia consegue interpretar.
Numa seguradora com ramo residencial em que atuamos, a equipe externalizou exatamente essa camada de orquestração: o modelo de IA executa, mas as regras que decidem o que fazer com o output ficam no motor. O resultado foi rastreabilidade de ponta a ponta pela primeira vez. Antes disso, reconstruir a decisão de um sinistro negado dois anos atrás levava três dias úteis de busca em logs e código.
Quando a integração entre IA e motor de regras está mal feita, qualquer ajuste de política vira dependência de engenharia outra vez. O benefício de ter IA no fluxo some porque o gargalo migra de "quem treina o modelo" para "quem codifica a orquestração". Regra muda. Sprint enche. Feature não sai.
A SUSEP não vai esperar. A tendência regulatória é de exigência crescente de explicabilidade, e "o modelo decidiu" não vai ser resposta aceita para decisão de sinistro ou aceitação de risco.
Seguradoras que chegarem em 2026 com IA no fluxo de decisão sem camada determinística auditável vão enfrentar uma escolha ruim: remover a IA do fluxo crítico às pressas, ou correr risco regulatório enquanto tentam refatorar a arquitetura sob pressão.
As que chegarem com a fronteira clara, IA onde o trabalho é interpretar e classificar, motor onde o trabalho é decidir com critério explícito, vão ter velocidade de processamento sem abrir mão de rastreabilidade regulatória.
Pega os últimos três sinistros negados automaticamente pelo seu sistema. Para cada um, tenta reconstituir: qual critério exato foi aplicado, em qual versão, com qual vigência, com qual aprovação. Se essa resposta existe em menos de 10 minutos, a arquitetura está no lugar certo. Se não existe, o risco regulatório já está acumulando.
