PDF é o formato favorito da indústria de seguros e o pesadelo favorito de qualquer engenheiro tentando automatizar extração no setor. Cada corretora tem o seu padrão. Cada cliente final tem o seu jeito de preencher o questionário.
Quando começamos a operação de extração da WIR, o pipeline naive — Tesseract OCR + regex pós-processamento + LLM para campos não estruturados — funcionava em algo como 60% dos casos. O dado importante é o complemento: 40% das submissões tinham algum campo crítico extraído incorretamente, ou não extraído.
Pipeline robusto valida coerência, dispara revisão quando dados não passam sanity check e nunca propaga incerteza como verdade.
Esse texto descreve três formatos específicos que quebravam o pipeline naive, qual era o modo de falha, e qual foi a virada técnica.
Formato 1: PDF escaneado de questionário antigo
O caso: corretoras tradicionais imprimem o questionário, pedem ao cliente que preencha à mão, escaneiam e enviam como PDF. O resultado é um PDF cujo conteúdo é, na prática, uma imagem.
O modo de falha: OCR comum lê a maior parte do texto impresso, mas falha consistentemente nos campos preenchidos à mão. CNPJ, faturamento, nome do segurado — saem com 30% a 50% de taxa de erro. Pior: quando o OCR confundia "1" com "I" em um CNPJ, o pipeline downstream assumia o CNPJ como string válida e seguia, gerando enriquecimento contra entidade errada.
A virada técnica: abandonamos a leitura linear e adotamos pipeline de duas camadas. Primeira: detecção da região do documento (form layout detection) que identifica onde estão os campos preenchidos. Segunda: modelo treinado especificamente para handwriting OCR, com pós-processamento contextual via LLM que valida coerência entre campos relacionados. Quando o CNPJ extraído não passa no dígito verificador, é flagado para revisão.
Resultado: taxa de erro em campos críticos caiu de ~40% para abaixo de 3%.
Formato 2: Tabela multi-coluna em layout complexo
O caso: questionários de risco industrial apresentam tabelas com 5 a 20 colunas que se estendem por múltiplas páginas. PDF não tem conceito nativo de "essa tabela continua na próxima página".
O modo de falha: OCR linear lê linha por linha, sem entender estrutura. Quando uma tabela quebra de página, a primeira linha da página seguinte é lida sem o cabeçalho, e o pipeline associa valores às colunas erradas. Em uma submissão real, um equipamento de R$ 2.4M na página 3 foi associado a "ano de fabricação" porque o OCR pegou só o valor da segunda coluna sem o cabeçalho.
A virada técnica: trocamos OCR puro por modelo layout-aware (família LayoutLM da Microsoft), que entende estrutura visual — onde está o cabeçalho, onde estão as colunas, qual valor pertence a qual campo, mesmo entre páginas. Para validação, LLM pós-processa checando coerência: faturamento consistente com porte, valores compatíveis com atividade.
Resultado: taxa de erro em extração de tabelas multi-página caiu de ~25% para menos de 2%.
Formato 3: PDF protegido ou com camada de assinatura digital
O caso: clientes corporativos em segmentos regulados exigem questionário com assinatura digital ICP-Brasil padrão. O PDF resultante tem camada criptográfica que, dependendo de como foi gerada, bloqueia OCR e até copy-paste.
O modo de falha: o pipeline simplesmente não conseguia abrir esses PDFs. Voltavam para fila manual, criando gargalo silencioso — em uma operação que recebia 800 submissões/mês, ~8% caíam nesse modo.
A virada técnica: fluxo de detecção de proteção que identifica o tipo aplicado e segue caminho específico. Para assinatura ICP-Brasil padrão, a camada de texto está acessível atrás da assinatura — basta ler com biblioteca correta. Para PDFs com password de leitura, automação que pede senha ao corretor de origem. Para PDFs que bloqueiam extração de texto mas não imagem, render para imagem + pipeline OCR + layout-aware.
Resultado: fila manual por "PDF não processável" caiu de 8% para abaixo de 0.5%.
O que isso significa
Três aprendizados consolidados.
Primeiro: pipeline de extração bem feito não é uma ferramenta — é uma cadeia. OCR é uma camada. Layout-aware é outra. Validação semântica via LLM é outra. Cada camada cobre os casos onde a anterior quebra.
Segundo: o valor está no long tail. Os 60% de PDFs simples que qualquer ferramenta resolve não são onde a tecnologia diferencia. A diferença está no 40% restante.
Terceiro: validação importa mais que extração. O custo de uma extração errada propagada é maior que o custo de uma extração que falha visivelmente. Pipeline robusto valida coerência, dispara revisão quando dados não passam sanity check e nunca propaga incerteza como verdade. Esse princípio se conecta diretamente à arquitetura de auditoria descrita em Explicabilidade que vai além do SHAP.