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

## 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.

<figure><img src="https://2538031102-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FXfrDexGOLMin51pAiWkq%2Fuploads%2Fhg3VMIt0sbpyEyV2jJC6%2FUntitled%20Diagram.drawio%20(2).png?alt=media&#x26;token=d3f071ca-fc9c-47e8-9bfb-5aa5b4ed6880" alt=""><figcaption></figcaption></figure>

## 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:

{% code overflow="wrap" expandable="true" %}

```json
{
  "claim": {
    "claim_id": "CLM-2024-12345",
    "policy_id": "POL-AUTO-98765",
    "policyholder": {
      "name": "Maria Silva",
      "customer_id": "CUST-001",
      "contact": {
        "email": "maria@example.com",
        "phone": "+5511999998888"
      }
    },
    "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
    }
  }
}

```

{% endcode %}

### 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](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/tools/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](https://docs.digibee.com/documentation/resources/pt-br/quickstarts/turn-ai-into-structured-output).

{% code overflow="wrap" expandable="true" %}

```
{
  "$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" }
      }
    }
  }
}

```

{% endcode %}

#### 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.

{% hint style="info" %}
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.
{% endhint %}

**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:**

{% code overflow="wrap" expandable="true" %}

```json
{
  "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."
    }
  }
}

```

{% endcode %}

#### Decisão de roteamento

Use um [conector **Choice**](https://app.gitbook.com/s/SKBJ6ZiEWBU93x170HH4/connectors/logic/choice) para determinar o próximo caminho com base na avaliação de risco de fraude:

```json
{
  "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.

{% stepper %}
{% step %}

### 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:**

{% code overflow="wrap" %}

```
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.
```

{% endcode %}

**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"}
]
```

{% hint style="info" %}
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.
{% endhint %}

**Exemplo de saída:**

{% code overflow="wrap" expandable="true" %}

```json
{
  "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
  }
}

```

{% endcode %}
{% endstep %}

{% step %}

### 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:**

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

```

{% hint style="info" %}
**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.
  {% endhint %}
  {% endstep %}

{% step %}

### 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:**

{% code overflow="wrap" fullWidth="true" %}

```
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>

```

{% endcode %}

**User Message:**

```
{{ message.$ }}
```

**Exemplo de saída:**&#x20;

{% code overflow="wrap" %}

```
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

```

{% endcode %}
{% endstep %}

{% step %}

### 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.
  {% endstep %}
  {% endstepper %}

## 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.

{% stepper %}
{% step %}

### 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:**

{% code overflow="wrap" %}

```
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>

```

{% endcode %}

**User Message:**

```
{{ message.body }}
```

{% endstep %}

{% step %}

### 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.
  {% endstep %}
  {% endstepper %}

## 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.