Automação de análise de sinistros com OCR e LLM.

Uma seguradora não perde margem apenas quando paga um sinistro indevido. Ela perde quando um processo simples fica parado por dias, quando documentos chegam incompletos sem triagem, quando a decisão depende de leitura manual e quando ninguém consegue explicar por que uma recomendação foi gerada. A automação de análise de sinistros com OCR + LLM e sugestão de decisão ataca esse gargalo, mas só produz resultado quando é tratada como um sistema crítico de dados, não como uma demonstração de inteligência artificial.

OCR extrai conteúdo de boletins, notas fiscais, laudos, fotos convertidas em PDF, apólices e formulários. Um LLM interpreta contexto, compara informações e organiza evidências para apoiar o analista. A sugestão de decisão prioriza casos, aponta inconsistências e propõe o próximo passo. A decisão final, especialmente nos eventos de maior impacto financeiro ou regulatório, continua sob governança humana e regras auditáveis.

Onde a automação de análise de sinistros com OCR e LLM falha

O erro mais comum é conectar um modelo a uma caixa de entrada, demonstrar que ele resume documentos e chamar isso de automação. Em produção, um sinistro envolve dados cadastrais, coberturas contratadas, vigência, franquia, histórico do segurado, regras antifraude, documentos externos, integrações com parceiros e prazos regulatórios. Uma leitura aparentemente correta, associada à apólice errada, pode produzir uma decisão operacionalmente perigosa.

Também existe a questão da qualidade de entrada. OCR não elimina documentos desfocados, campos manuscritos ilegíveis, layouts variáveis ou arquivos duplicados. Ele transforma imagem em dado com uma taxa de confiança. Esse indicador precisa acompanhar cada campo extraído. Sem isso, o sistema pode apresentar um CPF, placa, valor ou data incorretos como se fossem fatos confirmados.

LLMs adicionam uma camada distinta de risco. Eles são eficientes para classificar intenção, resumir evidências, identificar ausência documental e explicar regras em linguagem natural. Porém, podem inferir informações inexistentes, confundir versões de uma apólice ou responder com excesso de confiança. Por isso, o modelo não deve ser a fonte de verdade. A fonte de verdade é a base transacional governada, com dados versionados, regras explícitas e trilha de auditoria.

A pergunta correta não é se OCR e LLM conseguem analisar um sinistro. A pergunta é: como garantir que cada sugestão possa ser reproduzida, contestada e corrigida sem comprometer disponibilidade, segurança ou integridade dos dados?

A arquitetura que sustenta sugestões de decisão confiáveis

Uma operação séria separa ingestão, extração, validação, decisão e observabilidade. Essa separação reduz acoplamento, facilita auditoria e impede que uma falha em um componente paralise toda a fila de sinistros.

Na entrada, documentos e metadados devem receber identificação única, classificação de origem, controle de duplicidade e retenção conforme a política da empresa. O arquivo original precisa ser preservado. O texto extraído pelo OCR, suas coordenadas quando relevantes e os níveis de confiança devem ser armazenados como evidência técnica, e não apenas como texto solto em uma aplicação.

Na etapa de validação, campos extraídos são confrontados com dados já existentes: número da apólice, CPF ou CNPJ, placa, datas de vigência, tipo de cobertura, valor segurado e registros anteriores. Regras determinísticas são indispensáveis aqui. Se a apólice não estava vigente na data do evento, não é papel do LLM relativizar essa condição. A regra deve bloquear, encaminhar ou exigir revisão conforme a política definida.

O LLM entra após essa base estar estruturada. Sua função é interpretar documentos não padronizados e produzir saídas delimitadas: resumo factual, lista de documentos faltantes, divergências encontradas, categoria provável do sinistro, justificativa da recomendação e grau de confiança. A saída deve obedecer a um esquema validável, com campos obrigatórios. Texto livre sem estrutura é inadequado para alimentar uma decisão operacional.

Por fim, um motor de decisão combina regras de negócio, indicadores de risco, validações cadastrais e a análise contextual do modelo. O resultado não precisa ser binário. Em muitos fluxos, as melhores saídas são encaminhar para pagamento simplificado, solicitar documento adicional, priorizar perícia, direcionar à análise antifraude ou escalar para um especialista.

O banco de dados define a confiabilidade do processo

A camada de dados é onde projetos de automação deixam de ser promessas e passam a operar com controle. É necessário manter a relação entre o sinistro, os documentos recebidos, as extrações realizadas, as versões de regras usadas, os prompts aprovados, as respostas do modelo e a decisão humana posterior. Sem essa linhagem, não há explicação confiável para auditoria, contestação ou melhoria contínua.

Em ambientes de alto volume, o desenho também exige atenção a concorrência, índices, particionamento, retenção e isolamento de cargas. Consultas analíticas pesadas não podem degradar o banco transacional que sustenta abertura de sinistros, pagamentos e atendimento ao segurado. Filas, armazenamento de objetos e réplicas de leitura podem ser necessários, mas a escolha depende de volume, RPO, RTO e criticidade do processo.

A LGPD amplia a responsabilidade. Documentos de sinistro podem conter dados pessoais, informações financeiras, imagens, dados de saúde ou relatos sensíveis. O pipeline precisa aplicar controle de acesso por função, criptografia em trânsito e em repouso, mascaramento em ambientes não produtivos, registro de acessos e políticas claras de retenção. Enviar documentos completos para serviços externos sem classificação de dados e sem base contratual é uma decisão de risco, não uma inovação.

É nesse ponto que a especialização em dados faz diferença. A HTI Tecnologia atua em ambientes críticos com a disciplina exigida para sustentar disponibilidade, performance, backup, recuperação e monitoramento da infraestrutura que apoia operações sensíveis. Um modelo pode mudar em semanas. Uma base de dados mal governada cria passivo operacional por anos.

Quando automatizar e quando exigir revisão humana

Nem todo sinistro deve seguir o mesmo nível de automação. Casos de baixa complexidade, com documentação padronizada, valores dentro de faixas conhecidas e forte aderência às regras, são candidatos à triagem ou à decisão simplificada. Isso reduz fila e libera especialistas para situações que realmente exigem julgamento.

Já eventos com valor elevado, indícios de fraude, documentos conflitantes, cobertura ambígua, dados de saúde, risco reputacional ou possível impacto judicial devem receber revisão humana obrigatória. A automação ainda agrega valor nesses casos ao organizar evidências, destacar lacunas e reduzir o tempo de preparação da análise. Ela não deve criar uma falsa sensação de certeza.

A política de exceção precisa ser definida antes da entrada em produção. Quais níveis de confiança aceitam processamento automático? Quais divergências bloqueiam uma recomendação? Quem pode alterar regras? Como uma decisão é revertida? Qual é o prazo para reprocessar uma fila após indisponibilidade? Essas perguntas são operacionais e precisam de respostas documentadas.

Métricas que mostram resultado real

A avaliação não deve se limitar à acurácia do OCR ou à qualidade percebida do texto gerado. Uma operação madura acompanha tempo médio entre recebimento e triagem, percentual de documentos extraídos sem intervenção, taxa de encaminhamento correto, volume de retrabalho, taxa de exceções, tempo de resposta das integrações e custo por sinistro processado.

Também é necessário medir a qualidade da recomendação contra o desfecho real. Se o sistema sugere pagamento simplificado e o caso retorna por inconsistência, a regra, o dado ou o modelo precisam ser investigados. Se recomenda revisão para quase todos os casos, a automação não está reduzindo atrito. O objetivo é aumentar velocidade sem deslocar risco para outra etapa.

A observabilidade deve incluir métricas técnicas e de negócio. Latência de OCR, falhas de fila, indisponibilidade de APIs, crescimento de tabelas, lentidão de consultas e falhas de backup merecem o mesmo nível de atenção que a taxa de aprovação ou a fila de documentos pendentes. Em sinistros, uma degradação silenciosa rapidamente se transforma em atraso visível para cliente, corretor e regulador.

Implementação sem colocar a operação em risco

O caminho mais seguro começa por um recorte controlado: um tipo de sinistro, um conjunto limitado de documentos e um fluxo com regras bem conhecidas. Primeiro, a solução trabalha em modo de recomendação, sem execução automática. Analistas comparam a sugestão à decisão adotada e registram causas de divergência.

Depois, as regras e os limites de confiança são calibrados com base em dados reais. Só então alguns casos de baixo risco podem avançar para automação parcial. A expansão deve ocorrer por critérios objetivos, com testes de carga, planos de rollback, monitoramento contínuo e responsáveis definidos para incidentes técnicos e operacionais.

A melhor automação não é a que toma mais decisões sozinha. É a que reduz o tempo de análise, protege a base de dados, preserva a explicabilidade e deixa claro quando deve parar para que um especialista assuma. Em um processo de sinistros, velocidade sem controle apenas faz o erro chegar primeiro.