Validação de dados de produto: IA onde necessário, regras nas demais etapas

Dados de produto são um caso de uso atraente para IA empresarial porque as entradas são desorganizadas e a saída desejada parece estruturada. Mas um modelo capaz de ler um documento ou redigir uma descrição não deve decidir se um registro está em conformidade. Separamos interpretação probabilística de controle determinístico: modelos extraem e formulam; regras rastreáveis validam e decidem.

Dados de produto são um sistema de controle, não uma tarefa de redação

Um registro de produto está na interseção entre evidências do fornecedor, requisitos comerciais, obrigações legais, especificações dos canais e dados mestres internos. Um atributo pode afetar busca, logística, impostos, análise de segurança, embalagem ou expectativas do cliente. Uma edição aparentemente pequena pode se propagar por muitos sistemas posteriores.

Por isso, “gerar o conteúdo do produto” é um limite de sistema inadequado. A geração é apenas uma atividade. O fluxo real recebe evidências, identifica entidades e atributos, aplica políticas, encaminha exceções, registra aprovações e publica uma versão autorizada. A confiabilidade depende de toda a cadeia.

Começamos, portanto, com duas categorias de trabalho:

Interpretação: ler documentos, imagens ou textos livres variáveis; mapear linguagem desconhecida para um conceito conhecido; redigir uma descrição concisa.
Controle: verificar campos obrigatórios, tipos de dados, valores permitidos, unidades, dependências entre campos, requisitos de evidência, permissões e estado de publicação.

A interpretação é probabilística e se beneficia dos modelos. O controle deve ser determinístico sempre que a política puder ser formulada. Combinar ambos em um único prompt dificulta auditar, testar e contestar a saída.

Definir o registro canônico antes de adicionar IA

O modelo canônico de produto precisa de identificadores estáveis, campos tipados e responsabilidades explícitas. Para cada atributo, documentamos definição, unidade, cardinalidade, fontes permitidas, evidências obrigatórias, escopo de mercado ou canal e autoridade para aprovar mudanças.

As evidências brutas permanecem imutáveis. Armazenamos candidatos extraídos separadamente dos valores aprovados. Isso impede que um valor gerado pelo modelo se torne um fato silenciosamente e permite que revisores comparem o candidato com sua fonte. Um registro mínimo de linhagem inclui:

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

O registro de produção contém apenas valores que passaram pelas regras pertinentes e pelo caminho de aprovação. Isso é coerente com a arquitetura de um catálogo B2B com páginas de certificação: as alegações sobre produtos devem continuar ligadas às evidências, em vez de serem tratadas como textos comerciais intercambiáveis.

Onde os modelos agregam valor

Os modelos são úteis nas partes variáveis do fluxo de trabalho.

Extrair candidatos de evidência não estruturada

Formulários de fornecedores, fichas técnicas, rótulos e imagens frequentemente expressam o mesmo atributo em formatos ou palavras diferentes. Um modelo pode localizar valores prováveis, normalizar o texto ao redor e devolver um candidato estruturado com uma referência à evidência. O contrato de saída deve exigir null quando faltarem evidências; adivinhar não é concluir a tarefa.

Em tarefas de visão, o sistema deve preservar a região da imagem ou a página que sustenta a extração. Para texto, deve preservar um trecho curto da fonte ou sua coordenada. A confiança ajuda a encaminhar o trabalho, mas não é evidência e nunca deve substituir a referência à fonte.

Mapear linguagem para vocabulário controlado

Um termo da fonte pode não corresponder exatamente à taxonomia da organização. O modelo pode propor o conceito controlado mais próximo e explicar o mapeamento. A aceitação final continua sendo decidida por uma regra ou por um revisor autorizado. Se a taxonomia tiver uma tabela de sinônimos exatos, a correspondência determinística deve ser aplicada primeiro; o modelo trata o que restar sem resolução.

Formular texto para clientes

Modelos podem redigir títulos, listas de características, resumos ou traduções a partir dos atributos aprovados. O prompt deve usar apenas o registro aprovado e identificar claramente as instruções opcionais de estilo. O texto gerado passa então por regras de comprimento, alegações proibidas, qualificadores obrigatórios, terminologia e valores sem respaldo.

Não se pede ao modelo que decida se o próprio texto está em conformidade: isso colocaria o mesmo componente probabilístico nos papéis de autor e juiz.

Onde as regras devem decidir

As regras são adequadas quando uma condição de falha pode ser formulada e testada. As categorias típicas incluem:

Tipo de regra	Exemplo de controle
Presença	Atributo obrigatório preenchido para esta classe de produto
Tipo e formato	Valor interpretável conforme o tipo e a codificação declarados
Intervalo	Valor numérico dentro do intervalo autorizado
Enumeração	Valor pertencente ao vocabulário controlado atual
Unidade	Unidade permitida e conversão sem perda ou aprovada
Entre campos	Campo dependente presente quando o valor de gatilho se aplica
Evidência	Alegação com documento de origem elegível e atual
Consistência	Quantidade da embalagem, dimensões e totais derivados conciliados
Escopo	Valor válido para o idioma, mercado e canal de destino
Autoridade	Responsável autorizado a aprovar ou publicar este campo

Cada regra precisa de identificador, versão, responsável, gravidade e mensagem compreensível para uma pessoa. A mensagem importa: “a validação falhou” gera um chamado de suporte; “a quantidade líquida exige uma unidade aprovada e uma referência à fonte” gera uma tarefa de correção.

Essa separação também torna a automação de arquivos de catálogo para múltiplos destinos mais segura: a formatação específica do destino pode mudar sem enfraquecer a política de validação canônica.

As regras devem ser executadas em vários pontos: na ingestão, após a extração, após edições humanas, antes da exportação e antes da publicação. Interface, pipeline de processamento em lote e API devem usar o mesmo serviço de validação versionado. Duplicar a lógica das regras entre sistemas gera resultados contraditórios.

Um fluxo de trabalho de referência

Implementamos o processo como uma série de transições explícitas de estado:

Ingerir: registrar arquivos de origem, somas de verificação, proveniência e horário de recebimento.
Pré-processar: classificar documentos e associá-los a identidades candidatas de produto.
Extrair: usar primeiro analisadores determinísticos e, depois, modelos para campos ainda não resolvidos.
Normalizar: converter formatos e unidades sem mudar o significado.
Validar: executar o conjunto versionado de regras aplicável.
Revisar: encaminhar apenas exceções ou mudanças de alto risco a uma pessoa autorizada.
Aprovar: registrar o valor aceito, as evidências e a identidade de quem aprovou.
Publicar: gravar em cada destino por meio de um adaptador controlado.
Observar: capturar rejeições nos sistemas posteriores, correções e sinais de resultado.

Cada transição gera um evento. Esse registro de eventos permite reproduzir o processamento: quando uma taxonomia ou regra muda, os registros afetados podem ser identificados e revalidados sem extrair tudo novamente.

O mesmo princípio vale para variantes linguísticas. Uma arquitetura disciplinada de comércio multilíngue trata a tradução como uma saída derivada e versionada, enquanto os fatos aprovados e as evidências continuam compartilhados.

O fluxo também evita uma prática cara: enviar cada campo ao maior modelo disponível. Identificadores exatos, datas, unidades conhecidas e códigos enumerados devem seguir caminhos determinísticos. Os modelos ficam reservados aos campos ambíguos. Isso reduz custo e latência e torna mais significativa a avaliação do trabalho restante dos modelos.

A confiança encaminha o trabalho; não comprova a veracidade

Pontuações de confiança são frequentemente mal interpretadas. A alta confiança de um modelo não prova que a fonte é correta, atual ou autorizada. Apenas descreve a avaliação do modelo segundo determinado método.

Usamos confiança, risco e resultados das regras para escolher o encaminhamento. Um candidato de baixo risco, com evidência direta e aprovado em todas as regras, pode entrar em uma fila de revisão simplificada. Uma alegação regulada ou comercialmente sensível pode exigir aprovação humana independentemente da confiança. Evidência ausente leva à abstenção, não à redução do limite de aceitação.

Os limites devem ser calibrados em dados representativos por atributo e tipo de documento. Um limite global esconde diferenças importantes: extrair um identificador padrão não equivale a interpretar uma alegação sobre material. Acompanhamos precisão, capacidade de recuperar os valores relevantes (recall), abstenção e decisões dos revisores que substituem as propostas do modelo em cada segmento relevante.

Exceções fazem parte do produto

Catálogos reais contêm conjuntos de produtos, itens de reposição, variantes regionais, registros legados e documentos contraditórios de fornecedores. Um sistema projetado apenas para o caminho sem falhas cria trabalho manual em locais não observáveis.

Cada exceção precisa de código do motivo, gravidade, responsável, prazo e resolução permitida. Revisores devem ver candidato, evidências da fonte, regras reprovadas e impacto nos sistemas posteriores em uma única tela. Devem poder aceitar, corrigir, rejeitar ou pedir novas evidências sem editar os dados brutos da fonte.

Exceções às regras devem ser explícitas e delimitadas. Um revisor pode ignorar um aviso para um produto e destino específicos, mas não deve desativar globalmente a regra subjacente. Exceções repetidas indicam que a regra, a taxonomia, o processo de origem ou o modelo de produto pode precisar de revisão.

Os níveis de serviço devem refletir o risco para o negócio, e não a ordem de chegada. Um campo comercial opcional ausente e um atributo de segurança contraditório não pertencem à mesma fila.

Medir da linha de base ao resultado

Antes da automação, medimos completude dos campos, validação na primeira passagem, ciclos de correção, tempo de revisão, taxa de rejeição nos destinos e taxa de defeitos graves. Para relatórios internos confidenciais, cada série pode ser expressa como um índice com Baseline = 100, mantendo volumes absolutos e valores comerciais no ambiente autorizado.

Após o lançamento, separamos qualidade da extração de desempenho operacional. Uma extração pode estar tecnicamente correta e chegar tarde demais para a publicação. Um fluxo pode reduzir o tempo de revisão e aumentar os defeitos graves. Por isso, o painel de indicadores inclui:

exatidão dos candidatos e cobertura de evidências por atributo;
taxas de aprovação nas regras e de abstenção;
taxas de intervenções humanas que substituem decisões e de correções;
idade da fila e tempo até o registro aprovado;
rejeições nos destinos e correções após a publicação;
limites de controle para erros de alta gravidade.

Mudanças em modelos, prompts, taxonomias e regras são versionadas separadamente. Os conjuntos de avaliação incluem registros comuns e exceções conhecidas. Antes da implantação, reproduzimos o processamento com a versão proposta e comparamos tanto registros recém-aceitos quanto recém-rejeitados. O lançamento é bloqueado se um limite de controle piorar além da tolerância acordada, mesmo que a precisão média melhore.

Tratar mudanças como alterações de política

Regras representam políticas operacionais. Atualizá-las pode mudar quais produtos podem ser publicados, quais alegações são permitidas e quais equipes recebem trabalho. Mudanças de regras precisam, portanto, de responsável, justificativa, data de vigência, testes e aprovação proporcionais ao impacto.

Mudanças de modelo exigem disciplina semelhante, mas testes diferentes. Avaliamos extração e formulação em casos rotulados, incluindo entradas adversariais e de baixa qualidade. Também testamos o contrato de saída estruturada: campos desconhecidos, tipos inválidos e evidências ausentes devem causar falhas seguras.

A implantação deve ser gradual. O modo de avaliação paralela compara o novo caminho sem alterar registros. Depois vem um grupo limitado e, se os limites de controle se mantiverem, a expansão. O adaptador de escrita garante idempotência, privilégio mínimo e reversão. Nenhum modelo recebe acesso direto e irrestrito ao sistema oficial de registro.

A divisão do trabalho que permite ganhar escala

A arquitetura duradoura não é “IA versus regras”. É uma divisão deliberada do trabalho.

Modelos transformam evidências variáveis em candidatos e fatos aprovados em linguagem útil. Regras expressam políticas repetíveis. Pessoas resolvem ambiguidades, aprovam mudanças de alto impacto e aprimoram políticas quando exceções revelam lacunas. Registros de eventos ligam cada decisão a evidências e lógica versionada.

Esse desenho é mais fácil de explicar a executivos porque o risco é delimitado por ações e evidências. É mais fácil de construir porque os componentes têm contratos testáveis. E é mais fácil de operar porque as falhas são específicas: a extração não captou um valor, a fonte não era elegível, uma regra rejeitou uma combinação ou um revisor autorizado ignorou um aviso.

Os dados de produto empresariais nunca serão perfeitamente limpos ou uniformes. Não precisam ser. O sistema precisa saber o que foi observado, o que foi inferido, o que é permitido e quem decidiu. Use IA onde a interpretação é necessária. Use regras onde a organização já sabe formular a decisão.