Data quality for AI in retail: an integration checklist before using generative models

An artificial intelligence agent or application can query products, inventory, orders or customers and still work with an incomplete picture of the operation. The problem can start before the model: incompatible identifiers, late updates, duplicates or transformations with no traceability.

Data quality for AI in retail depends on the intended use. Before connecting a generative model, you need to check whether your catalogue, stock, order and customer data have stable identifiers, compatible meanings, appropriate update frequency, known provenance, and controls over errors and permissions.

Integration can help run those flows, but on its own it does not prove the data is correct.

What does “data quality” mean for AI in retail?

Quality is not an absolute property. A piece of data can be good enough for a monthly report and inadequate for an application answering availability questions during a purchase.

The UK Government’s Government Data Quality Framework, for example, distinguishes dimensions such as completeness, uniqueness, consistency, timeliness, validity and accuracy. Each one surfaces different problems:

• Completeness: the necessary fields are present.
• Uniqueness: the same entity is not represented by improper duplicates.
• Consistency: systems and records do not contradict each other.
• Timeliness: the data is available at the frequency and within the window the use case requires.
• Validity: the value respects the defined format, range or rule.
• Accuracy: the data correctly represents what it claims to describe.

These dimensions are not interchangeable. A hypothetical example: a product can have every attribute filled in and still be assigned to the wrong category. The record is complete, but not accurate.

Another: a price can respect the decimal format and fall within the allowed range, yet not match the current price. The data is formally valid, but it may be inaccurate or out of date.

It is also worth separating quality, integration and governance. Integrating systems lets you move, transform and coordinate information. On its own it does not determine which data is correct, who may use it, or which rules should apply. You can explore these differences further in our guide on the differences between integrating, unifying and deduplicating data.

The AI Risk Management Framework 1.0 from the United States National Institute of Standards and Technology (NIST) includes data quality problems among the factors that can affect the trustworthiness of an AI system.

That does not mean every error necessarily produces a wrong answer, nor that data is the only source of risk. It does justify reviewing the flows before feeding operational information into a generative application.

• We also recommend reading: “Data integration: what it is and how to unify data across systems without duplicating it”

Before the checklist: bound the use case and the critical data

Do not evaluate all your data as a single set. Start with the task and with the information that shapes its results.

Define first:

1. What the application will do. Answering questions about products is not the same as summarizing interactions or explaining the status of an order.
2. Which decisions will depend on its results. An informational answer has a different impact from a recommendation that changes an operation.
3. Which systems will supply information. For example, ERP, e-commerce, CRM, point of sale (POS), warehouse management or supply chain.
4. Which fields are critical. Identifiers, prices, availability, statuses, dates, permissions or contact details can carry different levels of importance.
5. What update frequency each piece of data needs. Not every flow requires what is described as real time.
6. What would happen if the data were wrong, incomplete or stale.
7. Who can define the correct meaning and approve the controls.

The NIST profile for generative AI recommends evaluating data against the task, the context, the limitations and the expected impacts. That is why the goal of this checklist is not to certify a complete dataset, but to find specific gaps within a defined use case.

Data quality checklist for AI: 11 cross-cutting controls

1. Is the source system identified for every critical piece of data?

Why it matters: if the same value appears in several systems, the application needs to know which one acts as the reference, and under what conditions.

What to review: source system, owner, the process that creates the data, and precedence rules.

Warning sign: the team cannot explain whether the current price comes from the ERP, the e-commerce store, a spreadsheet or a manual update.

2. Is there a stable key across systems?

Why it matters: without a stable identifier or a governed mapping, the same product, customer or order can be treated as different entities.

What to review: internal keys, shared identifiers and lookup tables.

Warning sign: systems relate records through names, free-text descriptions or fields that change often.

3. Are the mandatory fields defined?

Why it matters: a record can exist and still be useless for a specific task if it lacks the necessary information.

What to review: minimum fields per entity, and how unknown values are handled.

Warning sign: an empty field, a zero, “no data” and a not-applicable value are all interpreted the same way.

4. Are the accepted formats and values documented?

Why it matters: differences in units, dates, currencies, codes and structures can produce incompatible interpretations.

What to review: types, ranges, units, time zones, currencies and value catalogues.

Warning sign: one system uses “shipped”, another “dispatched” and a third “closed”, but nobody can explain whether they represent the same point in the process.

5. Do the systems interpret the data the same way?

Why it matters: two fields with the same name can represent different concepts, and two different names can refer to the same concept.

What to review: definitions, calculation rules, granularity and scope.

Warning sign: “available stock” includes reservations in one channel and subtracts them in another.

6. Does the update frequency match the intended use?

Why it matters: data can be correct at the moment it was generated and still be too old for a later query.

What to review: source frequency, tolerated latency and behaviour when there are delays.

Warning sign: the team demands “real time” without defining what delay is acceptable or which decision needs that speed.

The UK framework ties the timeliness of data to its purpose: a weekly summary and an availability query can require different frequencies.

7. Are the applied transformations recorded?

Why it matters: when data changes name, format, unit, structure or value along the flow, you have to be able to explain which rule produced the result.

What to review: mappings, versions, conversions, default values and how missing data is handled.

Warning sign: a value appears corrected or combined, but there is no record of how it was obtained.

The NIST profile for generative AI recommends documenting provenance, transformations and relevant limitations. Datasheets for Datasets proposes also recording motivation, composition, collection, uses and maintenance. Documenting does not prove accuracy.

8. Can you tie a result to a specific execution?

Why it matters: to investigate a discrepancy, knowing the general design of the flow is not enough. You need to identify which process ran, when, with which inputs, and what output it produced.

What to review: identifier, timestamps, status, inputs, outputs and process version.

Warning sign: the team knows how the integration is supposed to work, but cannot reconstruct what happened in a specific run.

OpenLineage distinguishes between dataset, job and run. In this checklist, that separation lets you investigate both the design and what happened in a specific execution. A run finishing without technical errors does not prove the quality of the result.

9. Are there rules for errors, retries and reconciliations?

Why it matters: when a system does not respond, rejects a record or processes only part of a batch, the flow needs a defined behaviour.

What to review: retries, rejected records, alerts, reconciliations and the owner.

Warning sign: retries duplicate orders, updates or movements because the process cannot recognize that the previous operation was already applied.

10. Are the applicable restrictions and preferences preserved?

Why it matters: integrating customer data does not remove the conditions under which it may be used.

What to review: purpose, authorizations, preferences, destinations and propagation of changes where applicable.

Warning sign: a preference is updated in the CRM but stays active in other tools working from an older copy.

The NIST Privacy Framework 1.0 recommends inventorying personal data, purposes, systems and responsibilities. Protecting a flow against unauthorized access does not determine whether the use of the data is appropriate.

11. Was the flow tested with representative scenarios?

Why it matters: a test with clean, complete records may not reproduce the conditions of the actual operation.

What to review: missing values, duplicates, delays, unexpected formats, interruptions and partial loads.

Warning sign: validation uses only a sample prepared for the demo.

The qualitative study Data Cascades in High-Stakes AI observed that certain problems could accumulate downstream effects, and that controlled conditions did not always reflect the real operation. It was not carried out in retail, so its contribution here is limited.

• You may also find our article useful: “7 mistakes when integrating your e-commerce with your invoicing system (and how to avoid them)”

Specific controls for catalogue, stock, orders and customers

Catalogue: identity, variants and attributes

GS1’s official material on data quality ties the quality of product master data to processes and controls, not just to field validation.

Separately, the GS1 Global Data Model promotes shared definitions and attributes to make product information easier to exchange. These contributions do not replace your internal rules, nor do they make GS1 a universal requirement.

Review:

• a stable key for the product;
• the separation between product, variant, presentation and packaging;
• mandatory attributes per category;
• units of measure and formats;
• rules for creating, changing and discontinuing items;
• mappings between ERP, e-commerce, POS and other systems;
• the validity of prices, descriptions and images.

A hypothetical example would be a t-shirt that appears as a single product in the ERP, while every size and colour combination is managed as a separate variant in the e-commerce store. The application needs to know that difference before answering about availability.

A Global Trade Item Number (GTIN) can make mapping easier in certain contexts, but it is not a universal requirement and does not automatically remove duplicates.

Stock: location, status and movements

“Stock” can refer to physical inventory, units available for sale, reservations, commitments, goods in transit or expected quantities. Define which state the application needs.

Review location, product or variant, physical quantity, available quantity, reservations, receipts, issues, adjustments, counts, update time, and the relationship between the balance and the movements that explain it.

GS1’s Electronic Product Code Information Services (EPCIS) standard distinguishes master data, transactions and events. You do not need to implement it to apply the principle: the distinction helps you see that a current balance does not always let you reconstruct how it was reached.

You can explore this problem further in our analysis of why inventory can drift between channels.

Orders: statuses, payments and operational events

An order usually passes through several systems and moments: creation, validation, payment, picking, dispatch, delivery, cancellation or return.

Review the shared identifier, the meaning of each status, the system responsible for changing it, the mapping between commercial status and operational event, the change history, partial or rejected payments, and the retries that could duplicate actions.

Hypothetical example: an order shows as “shipped” because a label was generated, but the package has not left the warehouse yet. The administrative status does not by itself prove that the physical movement happened.

Customers: identity, duplicates and permissions

Before deduplicating, define which entity you want to identify: person, account, household, company or organization.

Review identifiers, matching rules, the differences between observed, declared and inferred data, contact sources, preferences, permissions, who approves merges, and the propagation of corrections or deletions where applicable.

Two separate records can represent the same person, but a partial match does not always justify merging them.

Integrating records can contribute to a more complete view of the customer. On its own it does not produce a governed, trustworthy Customer 360. You also need definitions of identity, purpose, permissions, quality and accountability.

How to prioritize the gaps without a universal score

Do not count boxes to produce a readiness percentage. One gap in a critical piece of data can matter more than ten minor documentation problems.

Classify each finding by its impact:

• Critical: it prevents identifying or interpreting essential data.
• Relevant: it can produce contradictions or out-of-date information.
• Manageable: it needs documentation, monitoring or clearer accountability.
• Outside the scope of integration: it depends on the model, the business context, governance or a legal assessment.

Prioritize by considering the data affected, the task that depends on it, the impact of a wrong answer, your ability to detect the problem, the possibility of correcting it before it reaches the application, and the owner who can approve the fix.

Passing these controls does not guarantee that the AI application will be trustworthy. The model, the instructions, the behaviour in context and the results obtained still have to be evaluated.

• You may also be interested in: “When automation is no longer enough: Weavee vs. Zapier”

What can an integration layer contribute?

When the data you need is spread across several systems, an integration layer can help build and control the flows that make it available to an application.

At Weavee we offer an integration platform as a service (iPaaS) for configuring integrations between the systems used in retail operations, such as e-commerce, ERP, CRM, POS, supply chain and payment gateways.

Depending on the scope of the project, we can configure:

• connections to source and destination systems;
• transformations over certain formats, structures and values;
• routing rules;
• manual, automated, batch or so-called real-time executions;
• monitoring and alerts for the configured flows.

These capabilities can help move operational data under defined rules and surface certain technical incidents. They do not guarantee accuracy, consistency or AI readiness.

Integration alone does not define which data is correct, who may use it, or whether it is suitable for the AI use case. Nor does it replace governance decisions, quality controls, model validation or accountability for the source systems.

You can read what an iPaaS is and what role it plays in retail or look at our approach to omnichannel integration for retail.

Frequently asked questions

Which retail data is worth reviewing before using generative AI?

Start with the data involved in the task: products, variants, prices, stock, orders, customers, preferences and operational statuses. For each critical piece of data, identify its source, meaning, update frequency, transformations, owner and restrictions. You do not need to review the whole ecosystem in the same depth.

Does all data have to be updated in real time?

No. The right frequency depends on the use case. An availability query may demand a different latency from a periodic summary. Define how much delay each flow tolerates, and what should happen when the information exceeds that limit.

Does integrating systems automatically improve data quality?

No. Integration can make connections, transformations, execution rules and monitoring easier. However, an incorrect rule can propagate an error, and a successful run can carry incomplete or out-of-date data. Quality requires additional controls and owners.

How do you know which gap to fix first?

Prioritize the gap that affects critical data, could change an important answer or decision, and is hard to detect afterwards. Also consider whether there is an owner able to validate the fix, and whether the problem can be contained before it reaches the application.

Turn the gaps into an integration scope

The goal of this checklist is not to declare your data “AI ready”. It is to identify which sources, rules, controls and responsibilities the use case needs before it operates on real information.

Does your application depend on data spread across several systems? Tell us which sources are involved and which gaps you found with the checklist. At Weavee we can assess with you the scope of the integration flows required.

Request a trial!