Qualidade de dados para IA no varejo: checklist de integração antes de usar modelos generativos

Um agente ou aplicação de inteligência artificial pode consultar produtos, estoque, pedidos ou clientes e trabalhar com uma representação incompleta da operação. O problema pode começar antes do modelo: identificadores incompatíveis, atualizações tardias, duplicidades ou transformações sem rastreabilidade.

A qualidade de dados para IA no varejo depende do uso previsto. Antes de conectar um modelo generativo, você deve verificar se os dados de catálogo, estoque, pedidos e clientes têm identificadores estáveis, significados compatíveis, uma atualização adequada, origem conhecida e controles sobre erros e permissões.

A integração pode ajudar a executar esses fluxos, mas não demonstra por si só que os dados estejam corretos.

O que significa “qualidade de dados” para IA no varejo?

A qualidade não é uma propriedade absoluta. Um dado pode ser suficiente para um relatório mensal e ser inadequado para uma aplicação que responde consultas sobre disponibilidade durante uma compra.

O Government Data Quality Framework do Governo do Reino Unido, por exemplo, distingue dimensões como completude, unicidade, consistência, oportunidade, validade e exatidão. Cada uma permite detectar problemas diferentes:

• Completude: os campos necessários estão presentes.
• Unicidade: uma mesma entidade não aparece representada por duplicidades indevidas.
• Consistência: os sistemas e registros não se contradizem.
• Oportunidade ou atualização: o dado está disponível com a frequência e dentro do prazo que o caso de uso exige.
• Validade: o valor respeita o formato, a faixa ou a regra definidos.
• Exatidão: o dado representa corretamente aquilo que pretende descrever.

Essas dimensões não são intercambiáveis. Um exemplo hipotético poderia ser: um produto pode ter todos os seus atributos completos, mas estar atribuído a uma categoria incorreta. O registro está completo, mas não é exato.

Outro: um preço pode respeitar o formato decimal e estar dentro da faixa permitida, mas não coincidir com o preço vigente. O dado é válido do ponto de vista formal, mas pode ser inexato ou estar desatualizado.

Também convém separar qualidade, integração e governança. Integrar sistemas permite transportar, transformar e coordenar informação. Não determina por si só qual dado está correto, quem pode utilizá-lo ou quais regras devem ser aplicadas. Você pode ampliar essas diferenças no nosso guia sobre as diferenças entre integrar, unificar e deduplicar dados.

O AI Risk Management Framework 1.0 do Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) inclui os problemas de qualidade dos dados entre os fatores que podem afetar a confiabilidade de um sistema de IA.

Isso não significa que cada erro produza necessariamente uma resposta incorreta nem que os dados sejam a única fonte de risco. Mas justifica revisar os fluxos antes de incorporar informação operacional a uma aplicação generativa.

• Também recomendamos a leitura: “Integração de dados: o que é e como unificar dados entre sistemas sem duplicá-los”

Antes do checklist: delimite o caso de uso e os dados críticos

Não avalie todos os dados como um único conjunto. Comece pela tarefa e pela informação que influencia seus resultados.

Defina primeiro:

1. O que a aplicação fará. Não é o mesmo responder perguntas sobre produtos que resumir interações ou explicar o estado de um pedido.
2. Quais decisões dependerão dos seus resultados. Uma resposta informativa tem um impacto diferente de uma recomendação que altera uma operação.
3. Quais sistemas fornecerão informação. Por exemplo, ERP, e-commerce, CRM, ponto de venda (PDV), gestão de armazéns ou cadeia de suprimentos.
4. Quais campos são críticos. Identificadores, preços, disponibilidade, estados, datas, permissões ou dados de contato podem ter níveis de importância diferentes.
5. Que frequência de atualização cada dado precisa. Não todos os fluxos exigem uma modalidade chamada tempo real.
6. O que aconteceria se o dado estivesse incorreto, incompleto ou antigo.
7. Quem pode definir o significado correto e aprovar os controles.

O perfil do NIST para IA generativa recomenda avaliar os dados conforme a tarefa, o contexto, as limitações e os impactos previstos. Por isso, o objetivo do checklist não é certificar um conjunto de dados completo, mas encontrar lacunas concretas dentro de um caso de uso definido.

Checklist de qualidade de dados para IA: 11 controles transversais

1. O sistema de origem de cada dado crítico está identificado?

Por que importa: se o mesmo valor aparece em vários sistemas, a aplicação precisa saber qual funciona como referência e em que condições.

O que revisar: sistema de origem, responsável, processo que cria o dado e regras de precedência.

Sinal de alerta: a equipe não consegue explicar se o preço vigente vem do ERP, do e-commerce, de uma planilha ou de uma atualização manual.

2. Existe uma chave estável entre os sistemas?

Por que importa: sem um identificador estável ou uma correspondência governada, o mesmo produto, cliente ou pedido pode ser tratado como entidades diferentes.

O que revisar: chaves internas, identificadores compartilhados e tabelas de equivalência.

Sinal de alerta: os sistemas relacionam registros por nomes, descrições livres ou campos que mudam com frequência.

3. Os campos obrigatórios estão definidos?

Por que importa: um registro pode existir e continuar inútil para uma tarefa concreta se lhe faltar a informação necessária.

O que revisar: campos mínimos por entidade e tratamento de valores desconhecidos.

Sinal de alerta: um campo vazio, um zero, “sem dados” e um valor não aplicável são interpretados da mesma forma.

4. Os formatos e valores aceitos estão documentados?

Por que importa: as diferenças de unidades, datas, moedas, códigos e estruturas podem produzir interpretações incompatíveis.

O que revisar: tipos, faixas, unidades, fusos horários, moedas e catálogos de valores.

Sinal de alerta: um sistema usa “enviado”, outro “despachado” e um terceiro “fechado”, mas ninguém consegue explicar se representam o mesmo momento do processo.

5. Os sistemas interpretam os dados da mesma forma?

Por que importa: dois campos com o mesmo nome podem representar conceitos distintos, e dois nomes diferentes podem se referir ao mesmo conceito.

O que revisar: definições, regras de cálculo, granularidade e abrangência.

Sinal de alerta: “estoque disponível” inclui reservas em um canal e as desconta em outro.

6. A frequência de atualização corresponde ao uso previsto?

Por que importa: um dado pode estar correto no momento em que foi gerado e ser demasiado antigo para uma consulta posterior.

O que revisar: frequência de origem, latência tolerada e comportamento diante de atrasos.

Sinal de alerta: a equipe exige “tempo real” sem definir qual atraso é aceitável nem qual decisão precisa dessa velocidade.

O framework britânico vincula a oportunidade do dado à sua finalidade: um resumo semanal e uma consulta de disponibilidade podem exigir frequências distintas.

7. As transformações aplicadas são registradas?

Por que importa: quando um dado muda de nome, formato, unidade, estrutura ou valor durante o fluxo, você deve poder explicar qual regra produziu o resultado.

O que revisar: mapeamentos, versões, conversões, valores padrão e tratamento de ausências.

Sinal de alerta: um valor aparece corrigido ou combinado, mas não existe registro de como foi obtido.

O perfil do NIST para IA generativa recomenda documentar a origem, as transformações e as limitações relevantes. O Datasheets for Datasets propõe registrar também a motivação, a composição, a coleta, os usos e a manutenção. Documentar não demonstra exatidão.

8. Você consegue relacionar um resultado com uma execução concreta?

Por que importa: para investigar uma discrepância, não basta conhecer o desenho geral do fluxo. Você precisa identificar qual processo foi executado, quando, com quais entradas e qual saída produziu.

O que revisar: identificador, marcações de tempo, estado, entradas, saídas e versão do processo.

Sinal de alerta: a equipe sabe como a integração deveria funcionar, mas não consegue reconstruir o que ocorreu em uma execução específica.

O OpenLineage distingue conjunto de dados, processo e execução. Neste checklist, a separação permite investigar o desenho e o que ocorreu em uma execução concreta. Que ela termine sem erros técnicos não demonstra qualidade do resultado.

9. Existem regras para erros, novas tentativas e reconciliações?

Por que importa: quando um sistema não responde, rejeita um registro ou processa apenas parte do lote, o fluxo precisa de um comportamento definido.

O que revisar: novas tentativas, registros rejeitados, alertas, reconciliações e responsável.

Sinal de alerta: as novas tentativas duplicam pedidos, atualizações ou movimentos porque o processo não consegue reconhecer que a operação anterior já foi aplicada.

10. As restrições e preferências aplicáveis são conservadas?

Por que importa: integrar dados de clientes não elimina as condições sob as quais eles podem ser utilizados.

O que revisar: finalidade, autorizações, preferências, destinos e propagação de mudanças quando for o caso.

Sinal de alerta: uma preferência é atualizada no CRM, mas continua ativa em outras ferramentas que usam uma cópia anterior.

O NIST Privacy Framework 1.0 recomenda inventariar dados pessoais, propósitos, sistemas e responsabilidades. Proteger um fluxo contra acessos não autorizados não determina se o uso do dado é apropriado.

11. O fluxo foi testado com cenários representativos?

Por que importa: um teste com registros limpos e completos pode não reproduzir as condições da operação.

O que revisar: ausências, duplicidades, atrasos, formatos inesperados, interrupções e cargas parciais.

Sinal de alerta: a validação usa apenas uma amostra preparada para a demonstração.

O estudo qualitativo Data Cascades in High-Stakes AI observou que certos problemas podiam acumular efeitos posteriores e que as condições controladas não sempre refletiam a operação. Não foi realizado no varejo, portanto sua contribuição aqui é limitada.

• Talvez também lhe seja útil ler nosso artigo: “7 erros ao integrar seu e-commerce com seu sistema de faturamento (e como evitá-los)”

Controles específicos para catálogo, estoque, pedidos e clientes

Catálogo: identidade, variantes e atributos

A informação oficial da GS1 sobre qualidade de dados vincula a qualidade dos dados mestres de produto a processos e controles, não apenas à validação de campos.

Por outro lado, o GS1 Global Data Model promove definições e atributos compartilhados para facilitar a troca de informação de produto. Essas contribuições não substituem as regras internas nem transformam a GS1 em um requisito universal.

Revise:

• uma chave estável para o produto;
• a separação entre produto, variante, apresentação e embalagem;
• atributos obrigatórios por categoria;
• unidades de medida e formatos;
• regras para inclusões, mudanças e descontinuações;
• correspondências entre ERP, e-commerce, PDV e outros sistemas;
• vigência de preços, descrições e imagens.

Um exemplo hipotético poderia ser considerar uma camiseta que aparece como um único produto no ERP, mas cada combinação de tamanho e cor é gerenciada como uma variante independente no e-commerce. A aplicação precisa conhecer essa diferença antes de responder sobre disponibilidade.

Um número global de item comercial (GTIN) pode facilitar a correspondência em determinados contextos, mas não é um requisito universal nem elimina automaticamente as duplicidades.

Estoque: localização, estado e movimentos

“Estoque” pode se referir a existências físicas, unidades disponíveis para venda, reservas, compromissos, trânsito ou quantidades esperadas. Defina qual estado a aplicação precisa.

Revise localização, produto ou variante, quantidade física, quantidade disponível, reservas, entradas, saídas, ajustes, contagens, momento de atualização e relação entre o saldo e os movimentos que o explicam.

O padrão Electronic Product Code Information Services (EPCIS) da GS1 distingue dados mestres, transações e eventos. Você não precisa implementá-lo para aplicar o critério: a distinção ajuda a entender que um saldo atual não sempre permite reconstruir como se chegou a ele.

Você pode ampliar esse problema em nossa análise sobre por que o estoque pode ficar defasado entre canais.

Pedidos: estados, pagamentos e eventos operacionais

O pedido costuma atravessar vários sistemas e momentos: criação, validação, pagamento, preparação, despacho, entrega, cancelamento ou devolução.

Revise o identificador compartilhado, o significado de cada estado, o sistema responsável por modificá-lo, a correspondência entre estado comercial e evento operacional, o histórico de mudanças, os pagamentos parciais ou rejeitados e as novas tentativas que poderiam duplicar ações.

Exemplo hipotético: um pedido aparece como “enviado” porque uma etiqueta foi gerada, mas o pacote ainda não saiu do depósito. O estado administrativo não demonstra por si só que o movimento físico ocorreu.

Clientes: identidade, duplicidades e permissões

Antes de deduplicar, defina qual entidade você quer identificar: pessoa, conta, domicílio, empresa ou organização.

Revise identificadores, regras de correspondência, diferenças entre dados observados, declarados e inferidos, fontes de contato, preferências, permissões, responsáveis por aprovar fusões e propagação de correções ou exclusões quando for o caso.

Dois registros distintos podem representar a mesma pessoa, mas uma correspondência parcial não sempre justifica fundi-los.

Integrar registros pode contribuir para uma visão mais completa do cliente. Não produz por si só um Customer 360 governado e confiável. Também são necessárias definições de identidade, propósito, permissões, qualidade e responsabilidade.

Como priorizar as lacunas sem usar uma pontuação universal

Não conte caixas para produzir uma porcentagem de preparação. Uma lacuna em um dado crítico pode ser mais importante do que dez problemas menores de documentação.

Classifique cada achado conforme seu impacto:

• Crítico: impede identificar ou interpretar um dado essencial.
• Relevante: pode produzir contradições ou informação desatualizada.
• Controlável: exige documentação, monitoramento ou uma responsabilidade mais clara.
• Fora do escopo de integração: depende do modelo, do contexto de negócio, da governança ou de uma avaliação jurídica.

Priorize considerando o dado afetado, a tarefa que depende dele, o impacto de uma resposta incorreta, a capacidade de detectar o problema, a possibilidade de corrigi-lo antes que chegue à aplicação e o responsável que pode aprovar a solução.

Superar esses controles não garante que a aplicação de IA seja confiável. Ainda devem ser avaliados o modelo, as instruções, o comportamento em contexto e os resultados obtidos.

• Talvez também possa lhe interessar: “Quando automatizar deixa de ser suficiente: Weavee vs. Zapier”

O que uma camada de integração pode contribuir?

Quando os dados necessários estão distribuídos entre vários sistemas, uma camada de integração pode contribuir para construir e controlar os fluxos que os disponibilizam para uma aplicação.

Na Weavee oferecemos uma plataforma de integração como serviço (iPaaS) para configurar integrações entre sistemas utilizados em operações de varejo, como e-commerce, ERP, CRM, PDV, cadeia de suprimentos e gateways de pagamento.

Conforme o escopo do projeto, podemos configurar:

• conexões com sistemas de origem e destino;
• transformações sobre determinados formatos, estruturas e valores;
• regras de roteamento;
• execuções manuais, automatizadas, em lote ou em uma modalidade chamada tempo real;
• monitoramento e alertas para os fluxos configurados.

Essas capacidades podem contribuir para transportar dados operacionais sob regras definidas e dar visibilidade a determinadas incidências técnicas. Não garantem exatidão, consistência nem preparação para IA.

A integração não define por si só qual dado está correto, quem pode utilizá-lo nem se ele é adequado para o caso de IA. Também não substitui as decisões de governança, os controles de qualidade, a validação do modelo ou a responsabilidade sobre os sistemas de origem.

Você pode consultar o que é uma iPaaS e qual função ela cumpre no varejo ou conhecer nossa proposta de integração omnicanal para o varejo.

Perguntas frequentes

Quais dados de varejo convém revisar antes de usar IA generativa?

Comece pelos dados que participam da tarefa: produtos, variantes, preços, estoque, pedidos, clientes, preferências e estados operacionais. Para cada dado crítico, identifique sua origem, significado, atualização, transformações, responsável e restrições. Você não precisa revisar todo o ecossistema com a mesma profundidade.

Todos os dados devem ser atualizados em tempo real?

Não. A frequência adequada depende do caso de uso. Uma consulta sobre disponibilidade pode exigir uma latência diferente de um resumo periódico. Defina quanto atraso cada fluxo admite e o que deve acontecer quando a informação supera esse limite.

Integrar sistemas melhora automaticamente a qualidade dos dados?

Não. A integração pode facilitar conexões, transformações, regras de execução e monitoramento. No entanto, uma regra incorreta pode propagar um erro, e uma execução bem-sucedida pode transportar dados incompletos ou desatualizados. A qualidade exige controles e responsáveis adicionais.

Como saber qual lacuna corrigir primeiro?

Priorize a lacuna que afeta um dado crítico, pode mudar uma resposta ou decisão importante e é difícil de detectar depois. Considere também se existe um responsável capaz de validar a correção e se o problema pode ser contido antes de chegar à aplicação.

Converta as lacunas em um escopo de integração

O objetivo do checklist não é declarar que seus dados estão “prontos para IA”. É identificar quais fontes, regras, controles e responsabilidades o caso de uso precisa antes de operar com informação real.

Sua aplicação depende de dados distribuídos entre vários sistemas? Conte-nos quais fontes participam e quais lacunas você detectou com o checklist. Na Weavee podemos avaliar com você o escopo dos fluxos de integração necessários.

Peça uma demonstração!