Um pipeline de LLM para sinistros, tickets e documentos de KYC dentro da sua própria infraestrutura: extração, validação, revisão e auditoria

Processos de sinistro, tickets de suporte e documentos de KYC têm o mesmo problema em comum: pessoas os leem para preencher campos de que outro sistema precisa. Um sinistro vira um número de apólice, uma data do sinistro e itens da fatura; um ticket, uma categoria e um cliente; um documento de identidade, um nome, uma data de nascimento e uma data de validade. O requisito que vem com o trabalho costuma ser declarado antes de qualquer outra coisa: os documentos não podem ir para a OpenAI nem para qualquer outro provedor externo de modelos.

Onde o modelo roda é uma decisão à parte, comparada em um artigo anterior deste blog. Este artigo parte de um modelo de pesos abertos servido dentro da sua infraestrutura e descreve o pipeline ao redor dele, da ingestão ao registro que outro sistema consome. Ele explica a mecânica; não é um estudo de caso.

Sete etapas, e todas ficam dentro

Manter os dados longe de provedores externos é uma propriedade do pipeline inteiro, não da chamada ao modelo: o motor de OCR, a ferramenta de revisão, o conjunto de avaliação, o armazenamento de auditoria e os logs guardam todos o documento ou algo derivado dele, como o artigo anterior sobre pilotos lista na íntegra.

Ingestão: classifique o documento antes que qualquer coisa o leia

Todas as etapas seguintes dependem do tipo de documento: o schema, as regras, os revisores e o prazo de retenção, então a classificação vem primeiro e decide a rota. Um processo de sinistro que chega por e-mail pode conter um formulário de aviso de sinistro, faturas, fotos e um laudo médico; cada anexo é classificado separadamente e vinculado ao mesmo processo.

• Registre o canal, o remetente e um hash do conteúdo na chegada, para que um documento enviado duas vezes seja reconhecido antes de virar dois processos
• Classifique a partir de uma lista fechada de tipos; a documentação do vLLM sobre structured outputs lista um parâmetro choice, com o qual a saída será exatamente uma das opções, então o classificador não consegue inventar um tipo
• Envie para uma pessoa, e não para o schema mais próximo, um documento que não corresponde a nenhum tipo ou que corresponde com baixa concordância

Primeiro texto e layout, depois o modelo de linguagem

Um PDF gerado por software traz uma camada de texto que pode ser lida diretamente. Uma digitalização ou uma foto de celular traz apenas pixels, e algo precisa transformá-los em caracteres com posições.

Os motores open source para esta etapa rodam localmente. A documentação de linha de comando do Tesseract mostra saída TSV com uma coluna de confiança para cada palavra e saída hOCR com um atributo de confiança por palavra, um sinal por palavra que a etapa de roteamento pode usar. O Docling, uma biblioteca de conversão open source sob a licença MIT, lista entre os seus recursos para PDF o layout da página, a ordem de leitura e a estrutura de tabelas, além de suporte a OCR para PDFs digitalizados e imagens e execução local para dados sensíveis e ambientes isolados (air-gapped).

• Leia a camada de texto onde ela existir e use OCR só onde não existir, para que documentos limpos não ganhem erros de reconhecimento
• Guarde o número da página e a caixa delimitadora (bounding box) de cada palavra, para que cada campo extraído possa ser mostrado depois a um revisor na página de onde veio
• Preserve tabelas como tabelas: uma fatura cujas colunas são achatadas em uma única linha de texto perde qual valor pertence a qual item

Um modelo de visão e linguagem pode ler a imagem da página em vez disso: a documentação do vLLM sobre entradas multimodais afirma que a entrada de imagens é suportada de acordo com a OpenAI Vision API. O que funciona melhor é medido nos seus documentos, lembrando que uma etapa de OCR separada devolve as posições das palavras e a confiança delas, e um modelo que lê uma imagem não.

Saída restrita por schema: o formato é garantido, o conteúdo não

Cada tipo de documento recebe o seu próprio schema de saída, versionado como código. A documentação do vLLM sobre structured outputs lista cinco tipos de restrição: choice, regex, um JSON schema, uma gramática livre de contexto e uma structural tag, com backends que incluem xgrammar, guidance, outlines e lm-format-enforcer, e um padrão, auto, que tenta escolher um backend adequado com base nos detalhes da requisição.

• Torne “não encontrado” um valor explícito para cada campo, para que uma data do sinistro ausente seja registrada como ausente em vez de adivinhada
• Use enumerações para tudo aquilo com base no qual outro sistema vai ramificar a sua lógica: tipo de sinistro, categoria do ticket, tipo de documento, código do país
• Adicione a cada campo uma referência de origem, a página e as palavras de onde ele foi tirado, para que a validação e a revisão possam conferi-lo com o documento

Valide a saída de novo no código da aplicação com um validador de JSON Schema comum. Os backends diferem: a mesma página observa que xgrammar, guidance e outlines usam expressões regulares no estilo do Rust, enquanto o lm-format-enforcer usa o módulo re do Python, e que, para modelos Qwen3 Coder com raciocínio (reasoning) habilitado, as structured outputs podem ficar desabilitadas se o conteúdo do raciocínio não for separado em um campo próprio. Uma geração interrompida pelo limite de tokens também termina no meio do registro. A segunda verificação é barata.

Validação: as regras de negócio que já existem, escritas como código

Um registro que se encaixa no schema ainda pode estar errado. As verificações que pegam isso são as que o back-office aplica hoje à mão, escritas como código por tipo de documento:

• Sinistros: o número da apólice existe no sistema de apólices, a data do sinistro cai dentro do período de cobertura e os itens da fatura somam o total da fatura
• Tickets: o identificador do cliente corresponde a uma conta real, e o produto citado é um que o cliente de fato tem
• KYC: os dígitos verificadores da zona de leitura mecânica estão corretos, a data de validade não passou, e o nome e a data de nascimento na zona de leitura mecânica batem com os mesmos campos lidos na zona de inspeção visual

Documentos de identidade vêm com o seu próprio validador. O ICAO Doc 9303, a especificação de documentos de viagem de leitura mecânica, define dígitos verificadores na zona de leitura mecânica calculados em módulo 10 com uma ponderação 7, 3, 1 que se repete continuamente, com as letras de A a Z contando como 10 a 35 e o caractere de preenchimento como zero, e afirma que os dígitos verificadores permitem que os leitores verifiquem se os dados foram interpretados corretamente.

Roteamento: regras e sinais decidem quais campos uma pessoa vê

O roteamento é decidido por campo, não por documento: um sinistro cujo total da fatura falha enquanto todo o resto passa envia um campo para uma pessoa, não o processo inteiro. Os sinais:

• Qualquer falha de validador, incluindo um campo que o schema exige e que o modelo marcou como não encontrado
• Baixa confiança do OCR nas palavras a partir das quais o campo foi montado, com o limiar definido por campo no conjunto de avaliação
• Duas fontes que divergem, como a zona de leitura mecânica e a zona de inspeção visual de um mesmo passaporte
• Campos que, por decisão, nunca são automatizados, como um valor reclamado acima de um limite definido
• Uma amostra aleatória de campos que passaram em tudo, para que a taxa de erros que ninguém sinalizou seja medida, e não presumida

A declaração de certeza do próprio modelo fica de fora de propósito; um artigo anterior deste blog explica por que ela é um filtro fraco.

A tela de revisão mostra a página com as palavras citadas destacadas ao lado do valor proposto, para que o revisor confira em vez de reler. Cada correção é armazenada por campo com o valor antigo, o valor novo, o revisor e um motivo escolhido de uma lista curta. Depois que uma segunda pessoa a confirma, ela entra no conjunto de avaliação, mas nunca na parte congelada com base na qual as decisões de release são tomadas.

Avaliação por tipo de documento e por campo, não uma nota global única

Um único número de acurácia para o pipeline esconde o resultado que importa, como datas de validade falhando nas carteiras de identidade de um país enquanto todos os outros campos passam. Meça pelos mesmos eixos que o roteamento usa:

• Por campo: correspondência exata após a normalização e, separadamente, com que frequência o campo foi omitido ou inventado quando o documento o contém ou não o contém
• Por tipo de documento e por tipo de entrada, como PDF digital, digitalização e foto de celular, porque cada um tem o seu próprio padrão de erros
• Por rota: a parcela de campos automatizados e a taxa de erro na amostra tirada deles
• Ponderado pelo custo: um número de conta bancária errado e um nome de rua com erro de digitação não são o mesmo erro

Uma release, seja um novo modelo, prompt, schema, versão de OCR ou validador, é pontuada no conjunto congelado antes de entrar em produção, e o critério de aprovação é por campo: nenhum campo de nenhum tipo de documento fica abaixo da sua nota de corte, mesmo que a média suba. A construção do primeiro conjunto rotulado é tratada no artigo anterior sobre pilotos que nunca chegaram à produção.

Trilha de auditoria: qual modelo e qual prompt produziram cada campo

Um sinistro contestado ou a pergunta de um auditor sobre uma identidade aceita diz respeito a um campo em um documento. O registro que responde a isso é gravado enquanto o pipeline roda, uma entrada por campo, em um armazenamento append-only:

• O identificador do documento e o hash do conteúdo, a página e as palavras que o campo cita
• A versão do motor de OCR ou de layout e a confiança dele para essas palavras
• O nome do modelo e o checksum dos pesos, a versão do template do prompt e a versão do schema
• O resultado de cada validador, a rota seguida e o motivo dela
• O revisor, o valor antes e depois, e o horário, se uma pessoa o alterou

O AI Act da UE estabelece um requisito de registro de eventos para os sistemas que trata como de alto risco: o artigo 12(1) determina que os sistemas de IA de alto risco devem permitir tecnicamente o registro automático de eventos (logs) ao longo da vida útil do sistema. O anexo III lista os usos de alto risco, entre eles avaliar a capacidade de crédito de pessoas físicas, exceto para detectar fraude financeira, e a avaliação de riscos e a precificação em seguros de vida e de saúde; o artigo 6(3) define quando um sistema da lista ainda assim não é considerado de alto risco, por exemplo quando executa uma tarefa processual restrita. Se um determinado pipeline está no escopo é uma questão para o time jurídico do cliente; um registro por campo gravado em tempo de execução é útil de qualquer forma.

Dados pessoais: cada etapa vê só o que a sua tarefa exige

Um pipeline copia dados pessoais para mais lugares do que a pasta original. O artigo 5(1)(c) do GDPR exige que os dados pessoais sejam adequados, pertinentes e limitados ao que é necessário em relação às finalidades para as quais são tratados. O artigo 25(2) pede medidas que assegurem que, por padrão, só sejam tratados os dados pessoais necessários para cada finalidade específica, e aplica isso à quantidade de dados coletados, à extensão do tratamento, ao prazo de conservação e à acessibilidade. Em termos de pipeline:

• O modelo recebe as páginas de que o seu schema precisa, não o processo inteiro
• Os revisores veem os campos da sua fila, e o acesso aos documentos completos é concedido por papel e registrado em log
• Os logs da aplicação registram identificadores de documentos, nomes de campos e resultados, não valores de campos nem prompts
• Traces de prompts e de saídas, quando mantidos para depuração, ficam no mesmo armazenamento restrito que os documentos, com um prazo de retenção curto próprio
• O conjunto de avaliação é uma cópia de documentos reais e recebe os mesmos controles de acesso

O OWASP Logging Cheat Sheet inclui dados pessoais sensíveis e algumas formas de informação de identificação pessoal, como dados de saúde e identificadores governamentais, entre os dados que normalmente não devem ser registrados diretamente em logs, e diz que esses dados devem, em vez disso, ser removidos, mascarados, sanitizados, convertidos em hash ou criptografados.

A retenção varia por tipo de documento e, para KYC na UE, é definida pela legislação de prevenção à lavagem de dinheiro. O artigo 77 do Regulamento (UE) 2024/1624, aplicável a partir de 10 de julho de 2027, exige que as entidades obrigadas conservem uma cópia dos documentos e das informações obtidos na diligência devida em relação ao cliente e garantam que esses registros não tenham trechos suprimidos. Ele fixa um prazo de conservação de cinco anos, contados a partir do fim da relação de negócio ou da data de uma transação ocasional, após o qual os dados pessoais devem ser apagados, ressalvadas as exceções previstas no mesmo artigo. O registro de KYC original permanece completo no sistema de registro oficial; as cópias do próprio pipeline, dos traces aos snapshots de revisão, são minimizadas e apagadas em um cronograma próprio mais curto.

Throughput: uma fila para o pico, capacidade para o regime estável

O volume do back-office é irregular: um único evento pode afetar muitos segurados de uma vez, e uma indisponibilidade enche a fila de tickets. Filas, backpressure e um fallback manual são tratados no artigo anterior sobre pilotos; o que é específico de um pipeline de documentos auto-hospedado:

• Separe as filas por urgência: uma verificação de KYC pela qual um cliente está esperando durante o onboarding não fica na fila atrás de um lote de sinistros históricos
• Escale os workers de OCR em CPU e os servidores de modelo em aceleradores de forma independente, porque eles saturam em volumes diferentes
• Observe a fila do próprio motor de serving: o vLLM expõe métricas do Prometheus no endpoint /metrics, incluindo o número de requisições esperando para serem processadas e a fração de blocos do cache de chave-valor em uso
• Escale os workers pela profundidade da fila, e não pela carga de CPU; a documentação do KEDA descreve o escalonamento de qualquer contêiner no Kubernetes com base no número de eventos que precisam ser processados, com scalers para sistemas de mensageria, entre outros, e escala a zero (scale-to-zero)

A capacidade de aceleradores dentro da sua própria infraestrutura é fixa no curto prazo, então a ordem em que as filas cedem é decidida com antecedência, não durante o pico.

Sinistros, tickets e KYC: o mesmo esqueleto, regras diferentes

• Sinistros: muitos documentos por processo, tabelas em faturas e muitas vezes dados relativos à saúde, que o artigo 9 do GDPR inclui entre as categorias especiais cujo tratamento é proibido, a menos que se aplique uma exceção do mesmo artigo. O artigo 22 dá à pessoa o direito de não ficar sujeita a nenhuma decisão tomada exclusivamente com base no tratamento automatizado que produza efeitos na sua esfera jurídica ou que a afete significativamente de forma similar, com exceções no artigo 22(2). Por isso, se o pipeline apenas extrai e verifica enquanto um regulador de sinistros decide é uma decisão de design tomada com o encarregado de proteção de dados do cliente, não um padrão de engenharia
• Tickets: textos curtos, volume alto e alguém esperando uma resposta, então a latência importa mais; a saída é principalmente uma categoria, uma prioridade e alguns identificadores. O texto dos tickets é escrito por pessoas de fora da empresa e é entrada não confiável para o modelo, um risco discutido no artigo anterior sobre pilotos
• KYC: poucos tipos de documento com formatos rígidos, como passaportes e carteiras de identidade, o que torna forte a validação baseada em regras. Uma selfie comparada com a foto do documento acrescenta dados biométricos, que o artigo 9 do GDPR também inclui como categoria especial quando tratados para identificar uma pessoa de forma inequívoca. A retenção segue a legislação de prevenção à lavagem de dinheiro, e o resultado alimenta uma decisão de compliance tomada por uma pessoa ou por uma regra documentada

Manter os documentos longe de um provedor externo de modelos é decidido por onde o modelo roda. Se o pipeline merece confiança para lidar com eles é decidido por tudo o que está ao redor do modelo: o schema, as regras, a fila de revisão e o registro de quem produziu cada campo.

Quais empresas de engenharia constroem isso dentro da sua própria infraestrutura?

A pergunta tem três tipos de resposta, e eles vendem coisas diferentes. Fornecedores de processamento de documentos vendem uma plataforma, às vezes instalável on-premises, que você configura para os seus documentos. Provedores de nuvem vendem serviços gerenciados que rodam na infraestrutura deles. Empresas de engenharia constroem o pipeline no seu ambiente a partir de componentes abertos e das suas regras.

Seja qual for o tipo com que você fale, estas perguntas mostram se um time já construiu isso antes:

• Quais etapas chamam algum serviço fora da sua rede, incluindo OCR, monitoramento, rastreamento de erros e a ferramenta de anotação?
• Como é o schema de saída de um dos seus tipos de documento, e como “não encontrado” é representado?
• Quais sinais enviam um campo para revisão, e como os limiares foram escolhidos?
• Como as correções dos revisores chegam ao conjunto de avaliação sem contaminar a parte usada para as decisões de release?
• Eles conseguem mostrar, para um campo em um documento, o modelo, o prompt, o schema e o revisor que produziram o valor dele?
• Quem é o dono do código do pipeline, dos schemas e do conjunto de avaliação quando o trabalho termina, e quais partes continuam sendo componentes reutilizáveis do fornecedor?

Uma resposta que fica no genérico na primeira e na quinta pergunta significa que o caminho de dados e a trilha de auditoria ainda não foram projetados.

O que a amBrain pode dizer sobre o trabalho para clientes nesta área

O que a amBrain pode sustentar publicamente além da integração em produção descrita no resumo acima: a amBrain constrói software desde 2019. Trabalhamos em três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time. O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.

Este artigo explica como um pipeline desse tipo funciona; ele não é um estudo de caso, não cita clientes e não afirma que a amBrain construiu um sistema de sinistros, de tickets ou de KYC. O trabalho em produção citado acima é a extração de avisos de corretoras e de venues para um sistema de trading.

Então o primeiro passo não é escolher um modelo. É registrar por escrito, para um tipo de documento, o schema, as regras que o verificam e os campos que uma pessoa sempre precisa ver, antes que qualquer documento chegue ao pipeline.