IA em sinistros: guia definitivo para o COO

A conversa que me fez escrever este artigo

Na semana passada, um Diretor de Operações de uma seguradora de médio porte me fez uma pergunta direta: "Já testei três ferramentas de IA no sinistro. Nenhuma entregou o que prometeu. O problema é o mercado ou sou eu?"

A resposta honesta é: os dois. Mas na proporção de 80/20, com o peso maior no mercado. O que tenho observado, conversando com COOs e heads de claims em 2026, é que o setor comprou a promessa da IA antes de entender o que a IA precisa para funcionar num ambiente de sinistro. E a conta desse equívoco aparece no sinistro combinado, não no orçamento de tecnologia.

Este artigo é minha tentativa de ser o consultor que eu gostaria de ter tido disponível quando comecei a trabalhar com essa questão. Não vou vender entusiasmo com a tecnologia. Vou mostrar onde ela funciona, onde não funciona, e o que você, como COO, precisa decidir antes de qualquer linha de código.

Por que a jornada de sinistro é o lugar certo para começar

Antes de entrar nos modelos, preciso convencer quem ainda está em dúvida de que claims é o campo de batalha principal para IA em seguros. Não subscrição. Não atendimento ao cliente. Sinistro.

A razão é simples: é onde o dinheiro vai embora mais rápido e onde a variação humana é maior. Um regulador sênior e um regulador júnior, diante do mesmo boletim de ocorrência e das mesmas fotos de avaria, podem tomar decisões completamente diferentes. Isso não é crítica aos profissionais. É a natureza de um processo que depende de julgamento sobre informação incompleta, sob pressão de tempo e volume.

A IA não elimina o julgamento humano. Ela estrutura o problema antes que o humano precise julgar. Essa distinção é fundamental e vou voltar a ela várias vezes.

O que "ponta a ponta" realmente significa em claims

Quando falo em jornada de ponta a ponta, estou falando de seis momentos distintos, cada um com dinâmica própria:

1. Abertura do sinistro: recebimento do aviso, coleta de documentação, triagem inicial
2. Enriquecimento de dados: cruzamento do veículo, histórico do segurado, contexto do evento
3. Análise técnica: avaliação da avaria, compatibilidade do dano, identificação de inconsistências
4. Decisão de regulação: cobertura, valor, encaminhamento para reparo ou indenização
5. Detecção de fraude: score de risco, gatilhos de investigação, priorização de casos
6. Pagamento e fechamento: liquidação, comunicação, retorno para o modelo

A maioria das iniciativas de IA que acompanhei ataca um ou dois desses pontos. O projeto de "chatbot de abertura" que reduz tempo de FNOL. O modelo de score de fraude que roda em batch uma vez por dia. A ferramenta de análise de imagens que o regulador usa às vezes.

O problema não é fazer isso. O problema é fazer isso sem conectar os pontos.

Por que o modelo isolado decepciona

Imagine que você contrata um analista de inteligência que só recebe informação às 9h da manhã, não fala com o regulador que processa o sinistro às 14h, e entrega o relatório quando o pagamento já foi aprovado. Inútil? Quase.

É exatamente assim que a maioria dos modelos de IA funciona hoje no sinistro brasileiro. A ferramenta existe. Os dados não chegam em tempo real. O alerta não integra com o sistema de regulação. O regulador não sabe o que o modelo disse. E o aprendizado de cada caso encerrado não alimenta o modelo seguinte.

Essa fragmentação é o motivo pelo qual o COO que me ligou na semana passada testou três ferramentas e não viu resultado.

O que a IA realmente consegue fazer em cada etapa

Com esse cenário em mente, a próxima questão é inevitável: o que, de fato, a IA entrega quando bem implementada? Vou ser específico, porque generalidade aqui não ajuda ninguém.

Na abertura: triagem inteligente, não só automação

Na abertura de sinistro, o ganho óbvio é automação de coleta. Formulários inteligentes, leitura de BO, extração de dados de documentos. Isso funciona e reduz custo de mão de obra em tarefas repetitivas.

Mas o ganho menos óbvio, e mais valioso, é a triagem de complexidade. Um modelo bem treinado consegue, no momento da abertura, classificar o sinistro em faixas de complexidade: rotina, atenção e investigação. Isso muda completamente a fila de trabalho do regulador.

Acompanhei uma operação que implementou esse modelo de triagem e relatou algo que, para mim, resume o valor: os reguladores pararam de tratar todos os sinistros com o mesmo nível de atenção. Antes, um sinistro de vidro e um sinistro suspeito de perda total fraudulenta disputavam o mesmo espaço na fila. Depois, não.

Na análise técnica: o assistente que não esquece nada

A análise de compatibilidade de dano é onde vejo o maior desperdício de potencial. Um regulador experiente carrega na cabeça padrões de avaria que levou anos para aprender: esse tipo de impacto não produz esse padrão de amassado; essa peça não quebra dessa forma nessa colisão. É conhecimento tácito, difícil de transferir, impossível de escalar.

Modelos de visão computacional, treinados com volumes adequados de casos reais e laudos técnicos, conseguem fazer esse cruzamento em segundos. Não para substituir o olho do regulador. Para dar ao regulador um segundo par de olhos que já viu mais casos do que qualquer humano conseguiria ver numa carreira inteira.

A analogia que uso: é como ter ao lado do médico um sistema que consultou todos os prontuários de todos os hospitais do país antes de sugerir o diagnóstico diferencial. O médico decide. Mas decide com mais contexto.

Na detecção de fraude: do reativo ao preditivo

Este é o ponto onde a maioria das seguradoras começa, e começa pelo motivo certo: fraude em sinistro de auto é um problema que corrói o resultado de forma silenciosa e sistemática. O que muda com IA não é apenas a velocidade de detecção. É a lógica da detecção.

O modelo tradicional de antifraude é reativo: o analista olha o sinistro, identifica algo estranho, abre investigação. O modelo com IA bem estruturado é preditivo: antes de o sinistro entrar na fila, o score já diz qual é a probabilidade de irregularidade, com quais sinais específicos sustentam esse score.

Já vi operações onde esse score preditivo mudou a proporção de casos investigados versus fraudes confirmadas de forma muito significativa. Não vou colocar número aqui porque cada base é diferente e número inventado é pior que nenhum número. Mas a direção é consistente: mais precisão, menos falso positivo, menos cliente legítimo sofrendo atraso desnecessário.

No fechamento: o ciclo que a maioria ignora

Aqui está o ponto que poucos falam e que, na minha opinião, separa implementações medianas de implementações que melhoram com o tempo: o retorno loop.

Um modelo de IA que não aprende com os casos encerrados é um modelo que fica obsoleto. O mercado de fraude evolui. Os padrões mudam. Novas mecânicas surgem. Se o modelo é treinado uma vez e nunca atualizado, em seis meses ele já perdeu parte da eficácia.

Implementar IA em claims sem desenhar o ciclo de retroalimentação é como contratar um analista excelente e proibir que ele aprenda com os erros. O modelo precisa saber, para cada caso encerrado, qual foi a decisão real, qual foi o desfecho, e onde seu score errou.

O que o mercado não vê, mas que quem opera enxerga

Tudo que falei até aqui está nos relatórios de consultoria e nas apresentações de fornecedores. Agora vou ao que só quem vive isso no dia a dia percebe.

O dado estruturado é o gargalo real, não o algoritmo

Discordo frontalmente de quem diz que o problema de IA em sinistros é a falta de modelos sofisticados. O mercado tem modelos. O que falta é dado estruturado e confiável para alimentá-los.

Uma parte significativa das seguradoras que converso em 2026 ainda registra sinistros em campos de texto livre, sem padronização, sem ontologia, sem dicionário de avarias consistente. O regulador escreve "bateu na frente" num sinistro e "colisão frontal" em outro. Para o modelo, são eventos diferentes.

Quando o COO me pergunta por que o modelo não performa, minha primeira pergunta é sempre: "Mostre-me como seu sinistro está estruturado no sistema". Em mais da metade dos casos, a resposta está ali.

A resistência interna é subestimada

O segundo ponto que raramente aparece nas conversas sobre IA é a gestão de mudança. Reguladores experientes, com 10 ou 15 anos de mercado, têm uma relação complicada com sistemas que sugerem o que eles deveriam pensar.

Em um caso que acompanhei de perto, a operação implementou um score de fraude tecnicamente bem construído. Nas primeiras semanas, os reguladores simplesmente ignoravam o score quando discordavam dele, sem registrar o motivo. O modelo ficava sem retorno real. A liderança ficava sem visibilidade sobre onde o modelo acertava e errava.

A solução não foi técnica. Foi de processo: tornar obrigatório registrar a razão da discordância sempre que o regulador divergia do score. Isso criou dados de retorno genuíno e, de quebra, começou a revelar padrões de casos onde o modelo realmente estava errado, permitindo ajuste dirigido.

O regulatório está chegando

A SUSEP tem movido peças em direção à transparência algorítmica em decisões de sinistro. A LC 213 já muda o jogo para as proteções veiculares, e a tendência regulatória global é de exigir explicabilidade: o segurado tem direito de entender por que seu sinistro foi negado ou flagrado para investigação.

Isso tem uma implicação direta para a escolha de modelos: "caixa preta" vai virar passivo regulatório. Modelos com boa explicabilidade, onde o sistema consegue dizer "flagrei por esses três sinais específicos", não são apenas tecnicamente mais responsáveis. São juridicamente mais defensáveis.

Se eu estivesse sentado na sua frente agora

COO, se você está pensando em iniciar ou reformular uma jornada de IA em claims, aqui está o que eu diria sem rodeios:

Comece pelo diagnóstico do dado, não pela escolha da ferramenta. Antes de contratar qualquer plataforma, mapeie como seu sinistro está estruturado hoje. Campos de texto livre, padronização de avarias, completude de dados de abertura. Esse diagnóstico leva de duas a quatro semanas e vai evitar que você descubra o problema depois de assinar contrato.

Depois, escolha um ponto de entrada onde você tem dado estruturado suficiente e onde o impacto é mensurável em menos de 90 dias. Triagem de complexidade ou score de fraude costumam ser boas portas de entrada porque têm métrica clara: tempo médio de regulação e taxa de fraude confirmada por investigação, respectivamente.

Não contrate IA isolada. Contrate IA conectada ao fluxo real de trabalho do regulador. Se o score de fraude não aparece na tela onde o regulador toma a decisão, ele não existe na prática. Integração não é detalhe técnico. É condição de uso real.

E, finalmente: desenhe o retorno loop antes de ligar o modelo. Decida hoje quem vai alimentar o modelo com os desfechos, em qual frequência e com qual nível de detalhe. Sem isso, você tem IA de prazo de validade.

A escolha que define tudo

No final, a discussão sobre IA em claims não é tecnológica. É estratégica. E a decisão que o COO precisa tomar não é "qual ferramenta escolher". É "quero construir uma operação de sinistro que aprende ou uma que apenas processa?"

As que aprendem constroem uma vantagem competitiva que não se copia comprando o mesmo software. As que apenas processam trocam um fornecedor de laudo por outro fornecedor de tecnologia e ficam no mesmo lugar, com custo diferente.

Se você quer conversar sobre onde sua operação está nesse espectro, esse diagnóstico é exatamente o ponto de partida certo.