Análise de sinistros de seguro com IA usando uma arquitetura multiagente

Aprenda como construir um fluxo de trabalho de IA multiagente para análise de sinistros de seguros.

Visão geral

O processamento de sinistros de seguro é desafiador. Revisões manuais consomem muito tempo, pois os reguladores passam horas analisando narrativas, verificando fatos, buscando indícios de fraude e estimando custos de reparo.

O que você vai construir

Um sistema multiagente que auxilia na revisão de sinistros de seguro e melhora a precisão da detecção de fraudes.

Principais capacidades

• Valida os dados do sinistro e identifica riscos de fraude usando IA.

• Estima automaticamente os custos de reparo para sinistros válidos.

• Encaminha sinistros de alto risco para investigação de fraude e sinistros de baixo risco para aprovação.

• Gera relatórios estruturados e notifica os reguladores por e-mail.

Padrões relacionados

Esse padrão de detecção de fraude com múltiplos agentes pode ser aplicado em diferentes indústrias:

• Processamento de solicitações de empréstimo: O sistema verifica os dados do solicitante, avalia a capacidade de crédito, checa fraudes e encaminha a solicitação para um analista de crédito.

• Revisão de reembolsos na área da saúde: O sistema valida códigos médicos, verifica elegibilidade de cobertura, identifica padrões incomuns e encaminha o pedido para aprovação.

• Garantias (warranty claims): O sistema analisa falhas de produtos, verifica a legitimidade da compra, detecta padrões de abuso e aprova o pedido ou o escala para análise.

Configuração do pipeline

Trigger

Use um REST Trigger para receber os dados do sinistro por meio de uma requisição POST. Mantenha as demais configurações como padrão.

Entrada esperada: Um objeto de sinistro com informações sobre o segurado, o incidente, o ativo, a narrativa e os consentimentos.

Veja um exemplo de payload:

{
  "claim": {
    "claim_id": "CLM-2024-12345",
    "policy_id": "POL-AUTO-98765",
    "policyholder": {
      "name": "Maria Silva",
      "customer_id": "CUST-001",
      "contact": {
        "email": "[email protected]",
        "phone": "[phone]"
      }
    },
    "incident_datetime": "2024-12-20T14:30:00Z",
    "incident_location": {
      "address": "Av. Paulista, 1000, São Paulo, SP",
      "country": "Brazil"
    },
    "incident_type": "auto",
    "narrative": "I was driving when another car ran a red light and hit my front left side...",
    "assets": [
      {
        "make": "Honda",
        "model": "Civic",
        "year": 2022
      }
    ],
    "consents": {
      "data_processing": true,
      "fraud_analytics": true
    }
  }
}

Validação

Use o conector Validator V2 para verificar se todos os campos obrigatórios estão presentes. Dados ausentes podem desperdiçar tokens de IA e reduzir a qualidade da análise.

O design de schemas é importante para pipelines em produção, mas não é abordado neste guia. Para mais detalhes, consulte a documentação do conector Validator V2.

Arquitetura multiagente

A integração utiliza três tipos de agentes especializados. Um deles, o Claim Reporter, é utilizado em ambos os caminhos:

• Claim Analyst: Analisa o risco de fraude e identifica inconsistências.

• Damage Analyst: Estima os custos de reparo para sinistros com baixo risco de fraude.

• Claim Reporter: Gera relatórios legíveis para humanos e se adapta conforme o caminho de fraude.

Por que usar agentes separados

• Menor custo: Usar o modelo adequado para cada tarefa reduz de 40% a 60% os custos de tokens em comparação com o uso de um único agente.

• Maior precisão: Prompts especializados e responsabilidades claras aumentam a precisão de cada etapa.

• Roteamento mais inteligente: Sinistros com alto risco de fraude pulam a estimativa de custos e são enviados diretamente para escalonamento.

Agente 1: Analista de sinistros

Objetivo: Avaliar o risco de fraude, identificar inconsistências e recomendar os próximos passos.

Configuração:

• Modelo: GPT-4o (uso de ferramentas é obrigatório)

• Temperatura: 1.0 (para fins de teste)

  • Temperaturas mais altas permitem um raciocínio mais refinado durante a avaliação de fraude. Isso significa que a mesma entrada pode gerar pontuações de fraude ligeiramente diferentes a cada execução. Em ambientes de produção, considere reduzir a temperatura para 0.2 para obter resultados mais consistentes e determinísticos.

• Número máximo de tokens de saída: 10000

• JSON Schema: veja o JSON schema abaixo. Saiba mais sobre como estruturar sua saída.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["fraud_assessment", "recommendation"],
  "properties": {
    "fraud_assessment": {
      "type": "object",
      "required": ["score_0_100"],
      "properties": {
        "score_0_100": { "type": "integer", "minimum": 0, "maximum": 100 },
        "signals": { "type": "array" },
        "explanation": { "type": "string" }
      }
    },
    "recommendation": {
      "type": "object",
      "required": ["action"],
      "properties": {
        "action": { "type": "string" },
        "conditions": { "type": "array" },
        "rationale": { "type": "string" }
      }
    }
  }
}

Ferramentas MCP

Adicione a ferramenta de busca Tavily, que pode:

• Verificar endereços, identificando localizações falsas.

• Verificar consistência climática ao comparar a narrativa com as condições reais.

Sem o MCP configurado, o agente se baseia apenas em análise de padrões para detecção de fraude. A verificação de endereço e clima aumenta a precisão, mas não é obrigatória para o funcionamento do pipeline.

System Message:

Você é um analista de sinistros de seguros.
Analise o sinistro e produza um parecer estruturado contendo:
- Resumo do incidente
- Inconsistências e informações faltantes
- Avaliação de fraude com indícios explícitos
- Ação recomendada com evidências

Regras:
- Cite os campos exatos do JSON para todas as afirmações
- Marque dados desconhecidos explicitamente em "missing_information"
- Use a Tavily para verificar a localização e as condições climáticas
- Siga rigorosamente o JSON Schema fornecido

User Message:

PACOTE DE CONTEXTO DO SINISTRO
{{ message.claim }}

Exemplo de saída:

{
  "body": {
    "fraud_assessment": {
      "score_0_100": 30,
      "signals": [
        {
          "name": "Verificação da data do incidente",
          "direction": "unknown",
          "weight": 0.5,
          "evidence_refs": []
        },
        {
          "name": "Condições meteorológicas",
          "direction": "unknown",
          "weight": 0.5,
          "evidence_refs": []
        }
      ],
      "explanation": "The claim indicates...driver"
    },
    "recommendation": {
      "action": "approve_with_conditions",
      "conditions": [
        "Submeter boletim de ocorrência para validação"
      ],
      "rationale": "Não há indícios claros de fraude, porém faltam documentos corroborativos."
    }
  }
}

Decisão de roteamento

Use um conector Choice para determinar o próximo caminho com base na avaliação de risco de fraude:

{
  "when": [
    {
      "target": "low-fraud",
      "jsonPath": $.body.fraud_assessment[?(@.score_0_100 < 40)]
    }
  ],
  "otherwise": "high-fraud"
}

Lógica de threshold:

• Pontuação de fraude abaixo de 40: o sinistro é de baixo risco e inclui análise de estimativa de danos.

• Pontuação de fraude igual ou superior a 40: o sinistro é de alto risco. A análise de danos é ignorada e o caso é escalado imediatamente.

Caminho de baixo risco (low-fraud): fluxo completo

Sinistros com pontuação de fraude abaixo do threshold passam por análise de danos, geração de relatório e notificação do regulador.

1

Etapa 1: Agente Analista de danos

Objetivo: Estimar os custos de reparo associando os componentes danificados a uma base de preços.

Configuração:

• Modelo: GPT-4o-mini (eficiente em custo para correspondências simples)

• Temperatura: 0.7

• Número máximo de tokens de saída: 1024

System Message:

Analisar custos de reparo. Comparar as peças danificadas identificadas no resumo da solicitação com a lista de preços fornecida. Retornar somente JSON válido.

User Message:

CONTEXTO DO SINISTRO:
{{ message.body }}

CUSTOS DE REPARO DE PEÇAS AUTOMOTIVAS
[
  {"part": "door", "cost": 1000, "currency": "BRL"},
  {"part": "mirror", "cost": 2500, "currency": "BRL"},
  {"part": "head lights", "cost": 3000, "currency": "BRL"}
]

Para simplificar, a tabela de custos de reparo está incorporada diretamente no prompt neste exemplo. Em cenários de produção, esses dados devem vir de uma fonte externa, como um banco de dados.

Exemplo de saída:

{
  "body": {
    "involved_parts": [
      {
        "part_name": "door",
        "estimated_cost_to_repair": 1000
      },
      {
        "part_name": "mirror",
        "estimated_cost_to_repair": 2500
      },
      {
        "part_name": "head lights",
        "estimated_cost_to_repair": 3000
      }
    ],
    "estimated_total_cost_to_repair": 6500
  }
}

2

Etapa 2: JSON Generator (combinar resultados)

Objetivo: Combinar a análise do sinistro com a análise de danos para criar um pacote de dados abrangente.

Configuração:

{
  "claim": {{ step.claim-analyst.body }},
  "damage": {{ message.body }}
}

Por que esta etapa? O Agente de reclamações precisa de ambas as saídas:

• Avaliação de fraude, verificações de consistência e recomendação do Analista de sinistros.

• Detalhes de custos de reparo do Analista de danos.

3

Etapa 3: Agente de reclamações

Objetivo: Converter a saída JSON estruturada em um relatório de sinistro legível para humanos.

Configuração:

• Modelo: GPT-3.5-turbo (apenas formatação de texto, com custo mínimo)

• Temperatura: 0.7

• Número máximo de tokens de saída: 1024

System Message:

Você é um analista de resumos de sinistros. 
Sua função é consolidar as informações sobre um sinistro em um formato legível para humanos.
Você receberá uma estrutura JSON e deve gerar um relatório no seguinte formato:

RELATÓRIO DE SINISTRO
RESUMO: <versão resumida da narrativa, consulte o resumo na estrutura JSON> 

VERIFICAÇÕES DE CONSISTÊNCIA: <consulte consistency_checks na estrutura JSON>

AVALIAÇÃO DE FRAUDE: <consulte fraud_assessment na estrutura JSON>

RECOMENDAÇÃO: <um resumo do que o agente de sinistros deve fazer em seguida; consulte a recomendação na estrutura JSON>

ANÁLISE DE CUSTO DOS DANOS: <uma lista de todas as peças potencialmente envolvidas no incidente e uma estimativa dos custos de reparo; consulte cost_estimate na estrutura JSON>

User Message:

{{ message.$ }}

Exemplo de saída:

RELATÓRIO DE SINISTRO

RESUMO:
O Honda Civic de Maria Silva foi atingido...

VERIFICAÇÕES DE CONSISTÊNCIA:
Nenhuma inconsistência relevante foi identificada...

AVALIAÇÃO DE FRAUDE:
Índice de Risco de Fraude: 15/100 (Baixo Risco)
- Localização verificada como endereço legítimo
- Condições climáticas compatíveis com a narrativa
- Nenhum padrão suspeito detectado

RECOMENDAÇÃO:
Aprovar o sinistro com a condição de...

ANÁLISE DE CUSTO DOS DANOS:
- Porta: 1.000 BRL
- Retrovisor: 2.500 BRL
- Faróis: 3.000 BRL

Custo Total Estimado: 6.500 BRL

4

Etapa 4: Formatar e entregar o relatório

Converta o relatório de sinistro para o formato de entrega necessário e envie-o às partes interessadas.

• Entrega por e-mail: Envie o relatório aos peritos para revisão.

• Evento para pipeline: Acione um pipeline subsequente para processamento desacoplado.

• Arquivo para bucket: Faça o upload do PDF para o armazenamento para fins de auditoria e arquivamento.

Caminho de alto risco (high-fraud): fluxo completo

Sinistros com pontuação de fraude igual ou superior a 40 pulam a análise de danos e são enviados diretamente para escalonamento. Esse caminho economiza recursos ao evitar etapas desnecessárias para sinistros de alto risco.

1

Etapa 1: Agente de denúncia de fraude (Alerta de fraude)

Configuração:

• Modelo: GPT-3.5-turbo

• Temperatura: 0,7

• Número máximo de tokens de saída: 1024

System Message:

Você é um analista de resumos de sinistros. 
Sua função é consolidar as informações sobre um sinistro em um formato legível para humanos.

Você receberá uma estrutura JSON e deve gerar um relatório no seguinte formato:
RELATÓRIO DE SINISTRO

RESUMO: <versão resumida da narrativa, consulte o resumo na estrutura JSON> 

VERIFICAÇÕES DE CONSISTÊNCIA: <consulte consistency_checks na estrutura JSON>

AVALIAÇÃO DE FRAUDE: <consulte fraud_assessment na estrutura JSON>

RECOMENDAÇÃO: <um resumo do que o agente de sinistros deve fazer em seguida; consulte a recomendação na estrutura JSON>

ANÁLISE DE CUSTO DOS DANOS: <uma lista de todas as peças potencialmente envolvidas no incidente e uma estimativa dos custos de reparo; consulte cost_estimate na estrutura JSON>

User Message:

{{ message.body }}

2

Etapa 2: Formatar e entregar o relatório

• Envio por e-mail: Envie o alerta de fraude aos analistas para escalonamento imediato.

• Fluxo de eventos: Acione o fluxo de trabalho de investigação de fraude.

• Arquivar em um bucket: Arquive o relatório para fins de conformidade e análise de padrões.

Extensões

• Armazenamento para análises: Insira sinistros em um banco de dados para análise de padrões de fraude.

• Análise de fotos: Adicione um agente para verificar se as fotos danificadas correspondem à descrição narrativa.

• Detecção de padrões: Consulte o histórico de sinistros do segurado antes da análise para identificar sinistros recorrentes e padrões de abuso.

Principais conclusões

Este guia prático demonstra como uma arquitetura multiagente simplifica a análise de sinistros de seguros, combinando detecção de fraudes, estimativa de custos e tomada de decisões estruturadas em um único fluxo escalável.

Ao separar as responsabilidades entre agentes especializados e aplicar roteamento condicional, o sistema melhora a precisão, mantendo os custos operacionais sob controle.