Triagem inteligente de sinistros para plataforma de seguros

O desafio

A plataforma processava cerca de 1.400 sinistros por mês, majoritariamente de seguros de vida, saúde e acidentes pessoais. O fluxo era: o segurado ligava ou enviava e-mail, um analista abria manualmente a apólice no sistema legado, avaliava a cobertura, classificava a natureza do sinistro e devolvia uma resposta inicial.

Esse processo levava, em média, 72 horas - não porque era complexo, mas porque a fila era grande e o número de analistas era fixo. A maior parte das reclamações no Procon não era sobre negativa de sinistro: era sobre ausência de resposta dentro de um prazo razoável.

Três complicadores tornavam a automação não trivial:

1. Documentação desestruturada: os clientes enviavam boletins de ocorrência, laudos médicos e fotos pelo WhatsApp em formatos variados - JPEGs de baixa qualidade, PDFs escaneados com orientação incorreta, áudios descrevendo o incidente.

2. Lógica de cobertura complexa: a mesma apólice podia ter coberturas distintas para o mesmo tipo de evento dependendo da data de adesão, cláusulas específicas e histórico de uso.

3. Sistema legado sem API: o sistema de gestão de apólices tinha API documentada apenas para consulta de dados básicos. A leitura de cláusulas de cobertura exigia acesso à base de dados diretamente via SQL.

A solução

O projeto foi dividido em duas frentes independentes que se integraram na terceira semana.

Ingestão e extração multimodal

Todo documento recebido via WhatsApp entra num pipeline de pré-processamento antes de chegar ao modelo. Para imagens e PDFs: normalização de orientação, aumento de contraste, e extração de texto via OCR (Tesseract com pós-processamento por LLM para correção de erros típicos de OCR em documentos médicos).

O Claude 3.5 recebe o documento pré-processado e extrai um JSON estruturado com os campos relevantes para triagem:

class SinistroExtract(BaseModel):
    tipo_sinistro: Literal["acidente", "doença", "morte", "invalidez", "outro"]
    data_ocorrencia: date | None
    descricao_resumida: str  # max 200 chars
    documentos_presentes: list[str]
    documentos_ausentes: list[str]
    urgencia_flags: list[str]  # ex: ["internação_ativa", "menor_de_idade"]
    confiança: float  # 0-1

Quando confiança < 0.7, o sistema solicita automaticamente o documento faltante antes de prosseguir. Isso elimina um ciclo inteiro de ida-e-volta com o analista.

Classificação de cobertura

Com o sinistro extraído, o sistema consulta a base de apólices (acesso SQL direto com permissão de leitura) e monta um contexto de cobertura específico para aquele segurado. Esse contexto vai para um segundo prompt que faz a classificação:

• Cobertura confirmada: segue para fila de aprovação automatizada
• Cobertura provável: vai para fila de analista com resumo e recomendação
• Cobertura negada: gera rascunho de carta de negativa com fundamento contratual específico para revisão humana
• Indefinido: escala para analista sênior com flag de complexidade

O analista nunca começa do zero. Recebe o sinistro extraído, a análise de cobertura e, em casos de cobertura confirmada ou provável, uma minuta de resposta para o segurado.

Comunicação com o segurado

Toda comunicação saí pelo WhatsApp Business com templates aprovados pela Meta. O segurado recebe:

• Confirmação de recebimento em até 5 minutos com número de protocolo
• Status da triagem quando concluída
• Solicitação de documentos faltantes com orientações específicas
• Resultado final (ou encaminhamento para analista identificado)

A linguagem foi cuidadosamente calibrada para seguros: formal, clara, sem promessas de cobertura antes da análise completa.

Resultados

O ganho de 61% em reclamações de tempo de resposta veio não só da velocidade, mas da previsibilidade. O segurado sabe, em 5 minutos, que o sinistro foi recebido e em qual prazo terá uma resposta. Isso por si só elimina boa parte das reclamações.

Os analistas passaram a trabalhar exclusivamente nos casos classificados como “cobertura provável” e “indefinido” - casos que genuinamente precisam de julgamento humano. Os casos de “cobertura confirmada” e “cobertura negada” seguem para revisão de rotina, não para análise completa.

O deploy em 6 semanas foi possível porque não tocamos no sistema legado. A integração foi exclusivamente de leitura, sem nenhuma escrita no sistema de origem.