A verificação de conformidade comercial parece simples na teoria: extrair dados de um documento, conferir em bases governamentais oficiais e relatar os resultados. Na prática, essas "bases governamentais oficiais" são um conjunto fragmentado de sistemas antigos, APIs inconsistentes, disponibilidade pouco confiável e formatos de dados radicalmente diferentes.
No Atlas Verified, nos conectamos a dezenas de fontes governamentais e regulatórias para verificar documentos comerciais em tempo real. Cada integração foi uma lição de engenharia defensiva. Este artigo compartilha o que aprendemos ao construir sistemas confiáveis sobre infraestrutura governamental pouco confiável.
O panorama
A conformidade do comércio internacional envolve várias agências governamentais dos EUA, cada uma mantendo suas próprias bases com seus próprios padrões de acesso:
USDA Organic Integrity Database. A fonte de referência para o status de certificação orgânica nos Estados Unidos. Contém todas as operações orgânicas certificadas, seus agentes certificadores, escopos de certificação e status atuais. Não há API em tempo real. O USDA publica uma exportação CSV — um único arquivo enorme — que precisa ser baixado, analisado e carregado na sua própria base. As atualizações seguem a programação do USDA, não a sua.
Lista Specially Designated Nationals (SDN) do OFAC. Mantida pelo Office of Foreign Assets Control do Departamento do Tesouro dos EUA. Todas as empresas envolvidas no comércio internacional são legalmente obrigadas a fazer a triagem de contrapartes nessa lista. Disponível em downloads XML e por serviços de API de terceiros. A lista muda frequentemente conforme a situação geopolítica evolui.
Alertas de importação da FDA. A Food and Drug Administration publica alertas de importação que sinalizam produtos, empresas ou países específicos para inspeção reforçada ou retenção sem exame físico. Disponíveis pela API OpenFDA em JSON, mas o modelo de dados é complexo e a relação entre alertas, empresas e produtos nem sempre é evidente.
Consolidated Screening List (CSL). Mantida pelo Trade.gov, consolida 11 listas de triagem de várias agências — incluindo OFAC SDN, BIS Entity List, BIS Denied Persons e ITAR Debarred. Disponível como API JSON, mas cada lista subjacente tem estruturas de campos e critérios de correspondência diferentes.
Dados tarifários da OMC. A Tariff Download Facility da Organização Mundial do Comércio fornece alíquotas de Nação Mais Favorecida por país e código HS. Útil para validar alíquotas declaradas em faturas comerciais. Disponível como conjuntos de dados para download, não como API em tempo real.
Cada fonte usa formatos de dados diferentes, atualiza em cronogramas diferentes, tem características de confiabilidade diferentes e exige estratégias de consulta diferentes. Não existe uma API governamental unificada de conformidade. Você cria a sua ou fica sem uma.
O problema da atualização dos dados
Quando um profissional de conformidade verifica se uma empresa está em uma lista de sanções, precisa saber que a resposta é atual. Não atual na semana passada — atual neste momento.
Isso cria uma tensão de engenharia. Algumas bases, como o USDA Organic Integrity Database, estão disponíveis apenas como exportações periódicas. Outras, como o OFAC, têm serviços de API de terceiros que alegam acesso em tempo real, mas "tempo real" significa, na verdade, "sincronizamos a cada poucas horas".
Nossa abordagem é uma estratégia de atualização em níveis:
Nível 1: verificação por API em tempo real. Para verificações críticas de conformidade, como triagem de sanções e listas de partes proibidas, chamamos APIs externas no momento da consulta. O resultado é tão atualizado quanto os dados do provedor da API. Mantemos resultados em cache brevemente para consultas repetidas na mesma sessão de verificação, mas nunca fornecemos dados de sanções desatualizados entre sessões.
Nível 2: dados locais sincronizados. Para grandes conjuntos de referência, como operações orgânicas USDA, Consolidated Screening List e índices de portos, mantemos cópias sincronizadas na nossa própria base. Tarefas automatizadas de sincronização seguem cronogramas configuráveis, obtendo os dados mais recentes da fonte. Consultas locais são rápidas e não dependem da disponibilidade da fonte.
Nível 3: dados estáticos de referência. Para conjuntos que mudam raramente, como tabelas tarifárias da OMC, definições de códigos HS e características de portos, carregamos dados de referência e os atualizamos em ciclos mais longos. Esses conjuntos mudam trimestral ou anualmente, então atualização diária é excessiva.
Cada resultado de consulta inclui metadados sobre a atualização dos dados: quando a fonte subjacente foi sincronizada pela última vez e qual é a janela máxima de desatualização. Sistemas posteriores — e usuários — podem tomar decisões informadas com base nesses metadados.
O desafio da correspondência aproximada
As bases governamentais não sabem como seus documentos escrevem nomes de empresas. E seus documentos não sabem como a base governamental os escreve.
Esse não é um problema trivial. Uma mesma empresa pode aparecer como "Pearl White International Limited" em um conhecimento de embarque, "PEARL WHITE INTERNATIONAL LIMITED" em um registro do OFAC, "Pearl White Intl. Ltd." em um certificado de origem e "Pearl White Int'l" escrito à mão em uma lista de embalagem. Todos são a mesma entidade.
Uma correspondência eficaz de entidades em conformidade exige várias estratégias em conjunto:
Normalização. Antes de qualquer comparação, a consulta e os registros da base são normalizados: uniformização de maiúsculas e minúsculas, remoção de pontuação, expansão de abreviações e padronização de espaços. Isso resolve os casos simples.
Correspondência fonética. Nomes de empresas que soam semelhantes, mas têm grafias diferentes — comuns em nomes transliterados de escritas não latinas — exigem algoritmos fonéticos. Um nome transliterado de caracteres chineses ou árabes frequentemente tem várias grafias válidas em inglês.
Similaridade baseada em tokens. Em vez de comparar sequências completas, dividimos os nomes em tokens e medimos a sobreposição. "Pearl White International Limited" e "International Pearl White Ltd" são os mesmos tokens, apenas reordenados. Abordagens baseadas em tokens lidam bem com variações na ordem das palavras.
Desambiguação contextual. Quando a correspondência aproximada produz vários candidatos, o contexto do documento ajuda a desambiguar. Se o documento informa que a empresa está em Mumbai, Índia, e apenas uma de três correspondências de "Pearl White" está na Índia, essa é a correta.
O fluxo de correspondência pontua cada candidato em várias dimensões. Correspondências de alta confiança avançam automaticamente para verificação. Correspondências de baixa confiança são apresentadas ao usuário com evidências de cada candidato.
Construindo adaptadores para fontes pouco confiáveis
APIs governamentais não são desenvolvidas para uso comercial de alta disponibilidade. Ficam indisponíveis para manutenção sem aviso. Impõem limites de taxa agressivos. Mudam formatos de resposta em pequenas atualizações de versão. Retornam páginas HTML de erro em vez de respostas adequadas de erro.
Cada fonte externa de dados do nosso sistema é acessada por uma camada de adaptadores que lida com essas realidades:
Disjuntores de circuito. Se uma fonte falha repetidamente, o adaptador para de enviar solicitações por um período de recuperação. Isso evita falhas em cascata — se uma API estiver indisponível, não queremos que todas as verificações simultâneas fiquem travadas aguardando o tempo limite.
Degradação controlada. Quando uma fonte de dados está indisponível, a verificação continua com o que está disponível. O resultado indica claramente quais verificações foram concluídas e quais foram ignoradas por indisponibilidade da fonte.
Validação de respostas. Validamos cada resposta em relação aos esquemas esperados antes de processá-la. APIs governamentais às vezes retornam dados malformados, corpos vazios com códigos de status 200 ou JSON válido com estruturas inesperadas.
Novas tentativas com espera progressiva. Falhas transitórias acionam novas tentativas automáticas com espera exponencial. A estratégia é ajustada para cada fonte — algumas APIs governamentais se recuperam rapidamente, outras ficam indisponíveis por longos períodos.
A cadeia de verificação
Um único documento comercial pode acionar verificações em cinco ou mais fontes independentes de dados. Um conhecimento de embarque pode exigir triagem de sanções do OFAC para todas as partes, consultas a alertas de importação da FDA, consultas à Consolidated Screening List, verificação de posição de navios, rastreamento de contêineres e validação tarifária.
Essas verificações são independentes e executadas em paralelo. Mas todas precisam ser concluídas — ou falhar de forma controlada — antes que o resultado da verificação seja apresentado. Nosso sistema dispara todas as verificações aplicáveis simultaneamente, acompanha o status de conclusão e monta o resultado final conforme são concluídas. Verificações rápidas são entregues imediatamente ao usuário, e as mais lentas aparecem conforme terminam.
A camada de orquestração também trata dependências entre verificações. Se uma triagem de sanções retorna uma correspondência de alta confiança, o sistema sinaliza toda a verificação como exigindo análise humana — independentemente do que outras verificações encontrem.
De dados brutos a inteligência acionável
A forma mais bruta de um resultado de conformidade não é útil: "A API retornou um objeto JSON com 3 correspondências potenciais". Um profissional de conformidade precisa entender o que essas correspondências significam, qual confiança deve depositar nelas e qual ação tomar.
Nossa camada de processamento de resultados transforma respostas brutas de APIs em constatações estruturadas e acionáveis:
Pontuação. Cada correspondência é pontuada com base na similaridade de nomes, correlação geográfica e correspondência do tipo de entidade. Uma correspondência de nome de 97% com uma entidade sancionada no mesmo país é muito diferente de uma de 72% com uma entidade em outro continente.
Contextualização. Os resultados são apresentados no contexto do documento e da verificação específicos. As constatações incluem a parte específica conferida, os detalhes da entidade correspondente e por que a correspondência é relevante.
Priorização. Nem todas as constatações são iguais. Uma correspondência positiva de sanções é crítica. Uma certificação orgânica vencida é importante. Uma pequena discrepância tarifária é informativa. O sistema categoriza as constatações por gravidade.
Ações recomendadas. Quando possível, o sistema sugere próximas etapas: "Considere solicitar um certificado atualizado", "Verifique diretamente o número de registro da empresa", "Encaminhe para avaliação de devida diligência reforçada". Isso transforma uma consulta de dados em um fluxo de trabalho.
Engenharia para a confiança
O desafio fundamental de conectar IA a bases governamentais não é técnico — é a confiança. Profissionais de conformidade são legalmente responsáveis por suas decisões de verificação. Precisam confiar que os dados são atuais, a correspondência é precisa, os resultados são completos e o sistema é transparente sobre suas limitações.
Cada decisão de projeto na nossa camada de dados de conformidade atende a esse princípio. Mostramos registros de data e hora da atualização dos dados. Explicamos pontuações de correspondência. Informamos quando fontes estão indisponíveis. Nunca apresentamos resultados incompletos como completos.
Construir essa confiança exige rigor de engenharia além de acertar a resposta na maioria das vezes. Exige acertar sempre — e ser honesto quando a resposta é incerta.
O Atlas Verified se conecta a dezenas de bases governamentais e regulatórias para viabilizar a verificação de conformidade comercial em tempo real. Nossa camada de dados de conformidade lida com a complexidade da infraestrutura governamental fragmentada para que profissionais de conformidade se concentrem nas decisões, não na coleta de dados.