Qualidade de dados para IA no varejo: como prepará-los

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.

Uma camada de integração entre seu ERP, e-commerce, CRM e PDV pode ajudar a executar esses fluxos, mas não demonstra por si só que os dados estejam corretos.

Por que os dados travam (ou viabilizam) a IA generativa no varejo

A IA generativa já tem usos concretos no varejo: assistentes conversacionais que reduzem o tempo de atendimento, modelos que geram descrições de produto em escala e sistemas que recomendam combinações de compra. O que costuma travar a passagem dos pilotos para a produção está em outro lugar.

Uma análise do Google Cloud sobre como construir bases de dados sólidas para IA generativa cita a McKinsey: 70% das organizações que adotam IA generativa enfrentam dificuldades com a governança de dados, com a integração dos dados aos modelos e com a falta de dados de treinamento suficientes. O obstáculo não costuma ser o modelo, mas o dado e a forma como ele está conectado.

Em um varejista de médio ou grande porte, os sintomas costumam ser conhecidos:

o ERP mostra um estoque e o e-commerce, outro;
o CRM tem clientes duplicados e segmentos incompletos;
o PDV registra devoluções que nunca chegam à equipe de e-commerce;
o sistema de gestão de armazéns (WMS) usa códigos e localizações que não existem no catálogo online.

Um assistente generativo montado sobre esse cenário pode recomendar produtos sem estoque, ignorar compras feitas na loja física ou aplicar promoções que já não estão vigentes. Por isso, o que costuma ser chamado de data readiness não consiste em acumular dados, mas em contar com fontes conectadas, regras claras de governança, uma visão coerente de clientes e catálogo e controles de segurança consistentes.

Para ver casos de uso concretos, confira nosso guia sobre IA generativa no varejo: exemplos reais e requisitos de integração para colocá-la em produção.

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:

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.
Quais decisões dependerão dos seus resultados. Uma resposta informativa tem um impacto diferente de uma recomendação que altera uma operação.
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.
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.
Que frequência de atualização cada dado precisa. Não todos os fluxos exigem uma modalidade chamada tempo real.
O que aconteceria se o dado estivesse incorreto, incompleto ou antigo.
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.

Inventário de fontes: quais domínios mapear

Para responder aos pontos 3 e 4, não comece pelo modelo: faça um inventário das fontes de dados que participam do caso de uso. No varejo, convém mapear pelo menos estes domínios:

Catálogo e atributos de produto: PIM, ERP e e-commerce (SKU, descrições, variantes, imagens, categorias, preços e kits).
Vendas por canal: pedidos e itens de pedido no e-commerce, PDV, marketplaces e social commerce.
Logística e estoque: estoque por loja e centro de distribuição, movimentações, rupturas e pedidos pendentes.
Devoluções, reclamações e pós-venda: tickets de suporte, chats, e-mails, NPS e motivos de devolução.
Clientes e fidelidade: perfis, consentimentos, histórico de compras, pontos e cupons.
Campanhas e comportamento digital: newsletters, jornadas do cliente, eventos de navegação e carrinhos abandonados.

O inventário não é uma planilha para arquivar. Ele serve para decidir quais domínios são críticos para o primeiro caso de uso, qual sistema funciona como referência de cada um e como eles serão conectados antes que a aplicação os consulte.

Checklist de qualidade de dados para IA: 13 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. O mesmo acontece quando as regras de promoção estão divididas entre o e-commerce, o ERP e o PDV.

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 (por exemplo, SKU versus Item ID) 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, formatos de endereços, telefones e e-mails, e listas de valores controlados para atributos como cores, tamanhos ou categorias.

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, versão do processo e quais dados foram entregues a cada aplicação ou modelo.

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 aplicações de IA leem os dados por um caminho comum e governado?

Por que importa: se cada projeto de IA “descobre” os dados por conta própria com plugins ou conectores ad hoc, não há garantia de que leia a versão vigente do catálogo ou do estoque, fica difícil auditar por que respondeu algo errado e cada novo caso de uso obriga a repetir remendos.

O que revisar: como cada aplicação acessa cada fonte, quais conectores ou plugins participam, se todas as aplicações recebem as mesmas regras e transformações e se existem contratos de dados ou APIs documentadas.

Sinal de alerta: o assistente de atendimento consulta o estoque por um plugin do e-commerce, um assistente interno o lê de uma exportação do ERP e ninguém consegue explicar por que respondem de forma diferente.

A mesma análise do Google Cloud propõe reunir os dados em uma plataforma unificada que funcione como fonte única da verdade e adverte que copiar ou migrar todos os dados para um só lugar muitas vezes não é prático. No varejo, isso costuma significar manter o ERP, o e-commerce, o CRM, o WMS e o PDV onde estão e orquestrar os dados a partir de uma camada de integração que exponha visões consistentes.

11. 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.

12. O acesso, a retenção e a anonimização dos dados estão definidos?

Por que importa: à medida que você conecta mais dados a aplicações de IA, crescem os riscos de vazamentos, acessos indevidos, usos não autorizados de dados pessoais e retenção excessiva. O controle anterior trata de para que um dado pode ser usado; este, de quem acessa esse dado e por quanto tempo ele é mantido.

O que revisar: políticas de acesso por função de negócio e técnica (RBAC), quais dados cada aplicação pode ler, gestão de credenciais e segredos, criptografia em trânsito e em repouso, prazos de retenção e regras de anonimização ou mascaramento de dados sensíveis.

Sinal de alerta: a aplicação usa uma conta técnica com acesso total ao CRM, ou os registros de clientes ficam copiados em índices, logs ou prompts sem um prazo de retenção definido.

Você pode se aprofundar nessas práticas no nosso guia de cibersegurança em integrações e boas práticas para proteger seus dados.

13. 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, promoções, 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, por exemplo para normalizar taxonomias ou validar formatos;
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 diferença em relação a somar plugins e desenvolvimentos pontuais está no reaproveitamento: os conectores, regras e alertas que você configura para um caso de uso podem servir ao próximo, e diferentes aplicações podem consumir a mesma versão dos dados de negócio. Essa base comum também é o que permite, mais adiante, orquestrar agentes de IA sobre seu ERP e e-commerce: agentes que consultam e atuam sobre os sistemas por meio da mesma camada de integração, com rastreabilidade e supervisão humana.

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

Por onde começar a preparar os dados para IA generativa?

Pelo caso de uso, não pelo modelo. Defina o que a aplicação fará, faça um inventário das fontes que participam (catálogo, vendas, estoque, pós-venda, clientes e campanhas), identifique o sistema de referência de cada dado crítico e aplique os controles do checklist. A escolha do modelo vem depois.

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. Em outras palavras: integração primeiro, algoritmos depois.

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!

Qualidade de dados para IA no varejo: como preparar seus dados e checklist de integração