Validação de dados de produto: IA onde é necessária, regras no restante

Dados de produto parecem ideais para IA: inputs desorganizados e output estruturado. Mas um modelo capaz de ler ou redigir não deve decidir conformidade. Separamos interpretação probabilística de controlo determinístico: modelos extraem e formulam; regras rastreáveis validam e decidem.

Dados de produto são um sistema de controlo

Um registo une evidência do fornecedor, requisitos comerciais e legais, especificações de canal e master data. Um atributo afeta pesquisa, logística, imposto, segurança ou expectativa. O workflow recebe evidência, identifica entidades, aplica política, encaminha exceções, regista aprovações e publica uma versão autorizada.

Interpretação: ler documentos, imagens ou texto variável; mapear termos; redigir.
Controlo: verificar campos, tipos, valores, unidades, dependências, evidência, direitos e estado.

Modelos ajudam na interpretação; regras controlam sempre que a política é exprimível.

Definir o registo canónico antes da IA

Precisamos de IDs estáveis, campos tipados e owners. Para cada atributo definimos significado, unidade, cardinalidade, fontes, evidência, âmbito e autoridade. Evidência bruta permanece imutável e candidatos ficam separados de valores aprovados.

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Como num catálogo B2B com páginas de certificação, claims permanecem ligados à evidência.

Onde os modelos acrescentam valor

Extrair candidatos de evidência não estruturada

Formulários, fichas, rótulos e imagens exprimem atributos de formas diferentes. O modelo devolve candidato e referência; sem evidência deve devolver null. Região, página ou trecho ficam preservados. Confiança encaminha trabalho, não substitui evidência.

Mapear linguagem para vocabulário controlado

O modelo propõe conceito e justificação; regra ou revisor autorizado aceita. Sinónimos exatos são resolvidos primeiro de forma determinística.

Formular texto para clientes

Títulos, bullets, resumos e traduções usam apenas atributos aprovados. Regras verificam comprimento, claims proibidos, qualificadores, terminologia e valores sem suporte. O modelo não julga o próprio texto.

Onde as regras devem decidir

Tipo	Controlo de exemplo
Presença	Atributo obrigatório preenchido
Tipo e formato	Valor compatível com o tipo
Intervalo	Número no limite autorizado
Enumeração	Valor no vocabulário atual
Unidade	Unidade permitida e conversão aprovada
Entre campos	Campo dependente presente
Evidência	Claim com fonte válida e atual
Consistência	Quantidades, dimensões e totais conciliam
Âmbito	Válido para língua, mercado e canal
Autoridade	Ator autorizado a publicar

Cada regra tem ID, versão, owner, severidade e mensagem. Ingestão, interface, batch, API e publicação usam o mesmo serviço. Isso torna mais segura a automação flatfile multidestino: o formato muda sem enfraquecer a política.

Um workflow de referência

Ingest: registar ficheiros, checksums, origem e receção.
Preprocess: classificar e associar identidades.
Extract: parsers primeiro; modelos para campos por resolver.
Normalise: converter formatos e unidades sem alterar sentido.
Validate: executar regras versionadas.
Review: enviar exceções a pessoas autorizadas.
Approve: registar valor, evidência e identidade.
Publish: escrever por adaptadores controlados.
Observe: captar rejeições, correções e outcomes.

Cada transição gera evento e permite revalidar. Uma arquitetura de comércio multilingue trata traduções como outputs derivados e versionados, partilhando factos e evidência.

Confiança encaminha; não concede verdade

Confiança alta não prova correção, atualidade ou autorização. Risco, regras e confiança escolhem a rota. Claims sensíveis exigem aprovação; sem evidência há abstenção. Limiares são calibrados por atributo e documento, medindo precisão, recall, abstenção e overrides.

Exceções fazem parte do produto

Bundles, substitutos, variantes, legacy e documentos contraditórios são normais. Cada exceção tem código, severidade, owner, prazo e resolução. O revisor vê candidato, evidência, regras e impacto. Overrides são explícitos e limitados; repetição sinaliza política ou taxonomia a corrigir.

Medir da baseline ao outcome

Antes medimos completude, validação inicial, ciclos, tempo, rejeições e defeitos graves. Relatórios confidenciais usam Baseline = 100; absolutos ficam autorizados internamente.

exatidão e cobertura de evidência por atributo;
aprovação de regras e abstenção;
overrides e correções humanas;
idade da fila e tempo até aprovação;
rejeições e correções pós-publicação;
guardrails para erros graves.

Modelos, prompts, taxonomias e regras são versionados separadamente. Replays comparam novos aceites e rejeitados; piora de guardrail bloqueia o release mesmo com média melhor.

Governar mudanças como política

Regras exigem owner, motivo, data, testes e aprovação proporcional. Modelos são testados em casos rotulados, adversariais e fracos; campos desconhecidos, tipos inválidos e evidência ausente devem falhar com segurança. Shadow mode, coorte limitada e rollout gradual precedem escala. O adaptador impõe idempotência, menor privilégio e rollback.

A divisão do trabalho que escala

Não é “IA contra regras”. Modelos transformam evidência variável em candidatos e factos aprovados em linguagem; regras exprimem política repetível; pessoas resolvem ambiguidade e risco. Eventos ligam decisão, evidência e versão. IA onde interpretar é necessário; regras onde a organização consegue formular a decisão.