Usuário enviou o documento errado: classificar o tipo antes de extrair

Existe uma falha de verificação que quase nunca aparece nos relatórios de fraude e mesmo assim aparece todo dia na fila de suporte: a pessoa enviou um documento diferente daquele que a tela pediu. O fluxo pede a frente do RG, o Registro Geral, e ela fotografa a CNH, a Carteira Nacional de Habilitação, que estava mais à mão na carteira. Ou manda o verso no lugar da frente. Ou, quando o menu fala genericamente em "documento", anexa o comprovante de residência, que para ela também é um documento.

O que acontece depois é mecânico. O extrator foi configurado para o leiaute que a tela declarou e vai procurar campos nas posições daquele leiaute. Como os campos não existem ali, ele devolve valor vazio ou, pior, devolve valor trocado, porque encontrou alguma coisa parecida em outro canto da imagem. A decisão recebe dado ruim e reprova. Do lado de fora, um cliente legítimo levou uma reprovação técnica que nada tem a ver com risco.

A correção é anterior à extração: classificar, no servidor, qual documento de fato chegou, antes de tentar ler qualquer campo dele. Este artigo trata de por que o tipo importa tecnicamente, do que fazer quando o tipo detectado diverge do tipo declarado, e de onde essa classificação erra de forma previsível.

O tipo não é um rótulo, é o que define quais checagens existem

Cada documento tem leiaute, campos e regras próprias, e a conferência que faz sentido num não faz no outro. A Carteira de Identidade Nacional segue o Decreto 10.977, de 23 de fevereiro de 2022, cujo artigo 11 amarra a zona de leitura mecânica ao padrão estabelecido pela OACI, a Organização Internacional da Aviação Civil. A CNH segue outra norma: a Resolução CONTRAN nº 886, de 13 de dezembro de 2021, do Conselho Nacional de Trânsito, que define modelo único, expedido em meio físico e/ou digital, e no artigo 4º descreve três numerações, entre elas o Número do Registro Nacional, com nove caracteres mais dois dígitos verificadores, e o Número do Formulário RENACH, do Registro Nacional de Condutores Habilitados, com onze caracteres cujas duas primeiras posições são a sigla da unidade federativa expedidora. O parágrafo 1º do mesmo artigo manda calcular esse dígito por módulo 11.

Vale desfazer um engano comum de quem monta essa esteira: a CNH atual também tem zona de leitura mecânica, listada no item 21 dos Anexos III e IV da própria resolução, entre os elementos do documento. O que ela não tem é vínculo normativo com o Doc 9303: a resolução não cita a OACI nem o Doc 9303 em ponto nenhum. Presumir o leiaute da OACI ao enxergar uma faixa de caracteres monoespaçados erra por excesso; rodar a aritmética de dígito verificador num RG legado, que não tem faixa alguma, erra por falta. Conferir o módulo 11 do Registro Nacional num documento que não carrega esse número é igualmente vazio. Antes de escolher a conta, é preciso saber o que cada documento é e o que ele prova.

Por que a classificação tem que acontecer no servidor

O tipo que a página declara é insumo do usuário, não fato. Ele chega de um menu que a pessoa escolheu, ou de uma etapa do fluxo que o front-end informou, e nos dois casos vem do lado de fora. A regra geral de engenharia é antiga e não muda por ser um problema de imagem: o requisito 1.5.3 do OWASP ASVS 4.0, o Application Security Verification Standard do Open Web Application Security Project, pede que a validação de entrada seja imposta numa camada de serviço confiável, e o próprio padrão define camada de serviço confiável como qualquer ponto de execução confiável, onde quer que ele rode. O requisito 5.1.4 completa: dado estruturado precisa ser fortemente tipado e validado contra um esquema definido, com caracteres, tamanho e padrão permitidos.

O rótulo pode estar errado por engano, que é o caso comum, e pode estar errado de propósito, que é a minoria que importa. Quem estuda a esteira sabe que nem todo documento é conferido com o mesmo rigor, e declarar o tipo cujo extrator é mais permissivo é uma forma barata de escolher qual checagem enfrentar. Se o servidor só confia no rótulo, quem escolhe o caminho da análise é quem está sendo analisado.

Divergência entre declarado e detectado é sinal fraco

Aqui está o ponto central, e é onde muito produto erra a mão. Detectar que o documento enviado não é o documento declarado não é detectar fraude. Na prática, quase sempre é erro honesto de menu, pressa, ou uma tela cuja instrução não ficou clara. Tratar essa divergência como motivo de recusa automática é fabricar falso positivo em escala, e o custo cai inteiro sobre clientes legítimos.

O desfecho correto tem duas saídas. A primeira é recapturar com instrução específica, dizendo o que foi visto: "parece uma CNH, quer enviar como CNH?" resolve o caso em um toque, enquanto "documento inválido" só produz a mesma foto de novo. A segunda é encaminhar para revisão humana quando a recaptura já falhou ou quando o caso tem outros sinais. Vale desenhar essa saída de recaptura com limite e motivo explícito, porque pedir foto nova indefinidamente é outra forma de reprovar sem dizer.

O peso do sinal tem que ser proporcional ao que ele descreve. A divergência de tipo só cresce quando se soma a indícios independentes, como sinais de adulteração na imagem, dado que não fecha com a base cadastral ou reincidência do mesmo dispositivo. Sozinha, ela descreve um engano de preenchimento, não uma intenção, e engano de preenchimento não é motivo de recusa. Na leitura de documento da UNIFOKAL, o tipo detectado no servidor é comparado com o tipo declarado, e a divergência entra como sinal fraco, que sozinho nunca reprova.

Os dois usos rotineiros: roteamento e evidência

Classificar não serve só para pegar o erro de menu. O primeiro uso, e o mais frequente, é o roteamento: o tipo detectado escolhe qual extrator recebe a imagem, quais campos ele deve procurar, e quais checagens fazem sentido rodar em seguida. Um pipeline que decide isso pelo tipo real, e não pelo declarado, extrai melhor mesmo quando os dois coincidem, porque para de aplicar regra genérica a documento específico.

O segundo uso é o registro. Guardar o tipo detectado, o grau de confiança e o motivo da divergência transforma a análise em evidência auditável: fica documentado o que foi analisado, com que leiaute, e por que aquela conferência foi ou não executada. Meses depois, é isso que permite responder a uma contestação sem depender da memória de quem operou.

As bordas honestas, e a métrica que ninguém mede

Classificador de documento erra em situações reconhecíveis. Documento gasto ou com laminação refletindo perde as marcas visuais que sustentam a decisão. Foto cortada come justamente a faixa que identificaria o formato, e o enquadramento que sacrifica o rodapé derruba a pista mais barata do classificador. O RG legado é o caso mais duro. Como o artigo 25 do Decreto 10.977/2022 deu dez anos de validade aos padrões anteriores, contados da entrada em vigor, o classificador vai conviver por anos com uma família inteira de leiautes estaduais, emitidos em épocas diferentes, sem faixa de leitura mecânica e sem numeração nacional comum. Não existe "o RG" para reconhecer: existem dezenas de documentos que só se parecem de longe.

A última recomendação é uma medição, não um ajuste de modelo. Um classificador pode ir bem na média e mal num subconjunto, reprovando mais quem usa um tipo de documento do que outro, e a taxa média de acerto esconde exatamente isso. A métrica que interessa é a taxa de divergência aberta por tipo de documento, por estado emissor no caso do RG legado, e por canal de captura. Se um recorte diverge muito acima dos outros, o problema não é o usuário: é o classificador, ou a instrução da tela que veio antes dele.

Fontes citadas

• Decreto 10.977, de 23 de fevereiro de 2022, artigos 11 e 25, no portal do Senado Federal: legis.senado.leg.br
• Resolução CONTRAN nº 886, de 13 de dezembro de 2021, artigos 2º e 4º, no portal do Ministério dos Transportes: gov.br
• Anexos III e IV da mesma resolução, item 21, que lista a zona de leitura mecânica (MRZ) da CNH; publicados à parte pela SENATRAN e alterados pela Deliberação CONTRAN nº 259, de 2022
• OWASP ASVS 4.0, requisito 1.5.3 e a definição de camada de serviço confiável, na seção V1.5: github.com/OWASP/ASVS
• OWASP ASVS 4.0, requisito 5.1.4, na seção V5.1: github.com/OWASP/ASVS
• Doc 9303 da OACI, Machine Readable Travel Documents, padrão da zona de leitura mecânica que o artigo 11 do Decreto 10.977/2022 adota para a Carteira de Identidade Nacional