Product data enrichment with AI agents: method, controls and limitations

Why product records are incomplete

Product data degrades at every link in the chain. The manufacturer publishes a rich data sheet, but as a PDF; the distributor copies part of it into its own format; every retailer rewrites the labels; and attributes that mattered to nobody yesterday become mandatory tomorrow because of a new sales channel, regulation or filtering requirement. At the scale of a catalogue containing hundreds of thousands of products, manual completion can never catch up.

The commercial impact is direct. An accurate, well-populated product page attracts and converts informed customers — those who compare, filter and read specifications before buying — and builds a website's reputation for quality. A poor page sends demanding buyers to a competitor that has done the work.

This matters even more as search shifts towards AI assistants. When a buyer asks an AI which product meets a need, it can only use the characteristics it can find and understand. A rich, structured and sourced product page provides more material for an accurate answer. This clarity contributes to GEO, but cannot guarantee a recommendation or citation on its own: indexation, source authority and context also matter.

There is also an organisational reality: in established retailers, the teams that need the data do not always control the central catalogue. It can be faster to source their own product pages — public and up to date on their own website — than to wait for an information-system export.

Start with the schema, not the AI

Serious enrichment begins with a business question: for each product category, which attributes are expected, in which units and with which permitted values? This category-specific schema is the enrichment contract — chemical-protection gloves and a radiator do not require the same fields. It also defines the scope: which attributes AI may complete and which remain untouchable reference data. The customer owns this scope, ideally configuring it directly in their catalogue management tool.

Product expertise is now within reach of AI models

What has changed in recent years is the level of domain expertise available to AI models. Knowledge of a product category — that of a category manager or product-listing expert — is now within their reach. Completing technical attributes, writing marketing copy and proposing a defensible equivalent no longer need to be done by hand. Expertise does not disappear; it moves to defining rules, supervising batches and resolving ambiguous cases.

Take categorisation. To classify a product, an agent does not simply read its label: it examines products already classified in the candidate categories to verify that the product genuinely belongs there. It can use the customer's taxonomy or generic classifications such as GS1 or ETIM for technical distribution. Working category by category opens up a new possibility: deriving schema templates — the attributes a product category should contain — instead of starting from a blank sheet.

Exhaust structured sources before crawling

The web is not the first source; it is the last. FAB-DIS files carry official manufacturer data — characteristics, documents and regulatory statements — expressed in the ETIM vocabulary. When a value is present there, it is authoritative. Shared content providers such as Icecat offer standardised records for millions of products — valuable when their coverage matches your range. Web research across manufacturer sites, PDF data sheets and photos completes what these sources do not cover. Combining all three delivers completeness.

Source hierarchy — and the rule that protects it

The manufacturer is authoritative; recognised retailers supplement the data. When a value exists only on retailer websites, a precautionary rule applies: if several sites agree, it may be retained; if it appears on only one, it is not. The field remains empty and the question goes to the manufacturer.

Two practical corollaries follow. A document is qualified by its content, never by where it is hosted: a 100% manufacturer data sheet hosted by a retailer remains a manufacturer document — it is often the only localised version available. And a value whose source was never actually opened does not exist: “seen in search results” is not a source.

The method: mechanical coverage, agent judgement

The architectural principle that changes everything is simple: code guarantees coverage, while the agent retains judgement. In practice, robust enrichment proceeds in five stages:

1. 1

   Identify the product by reading its existing record, searching for related products already processed and finding the manufacturer's page.

2. 2

   Collect documents as a closed set. All candidate data sheets and manuals are gathered, qualified by language, brand, reference and type, then presented as a closed list. The agent must use or reject every document; it cannot simply “miss” a source.

3. 3

   Process every source in both text and visual form. Some information exists only as an image — a row of standards pictograms on a data sheet cannot be read from extracted text.

4. 4

   Verify every value against its source before saving it, with an explicit verdict — see the table below. A value not found in its own source is corrected or cleared within the same session.

5. 5

   Save under safeguards. Valid values pass; invalid ones return to the agent with the exact reason for rejection.

Format matters as much as the value

“8.5 litres per minute”, “8.5 L/min” and “8,5 l/min” represent the same value, but only one format is expected by your catalogue. Normalisation handles French and English decimal separators, ranges and units, while validation against the catalogue schema runs in a loop: an out-of-list value returns with the nearest permitted options until it imports cleanly.

Inferences are useful — provided they are labelled

Not everything is stated explicitly. An inference may come from indirect reading — recognising the pull-out spray head in a photo — or reasoning between characteristics: if the cartridge measures 35 mm and installation uses a single hole, the expected drill diameter is 35 mm. Both are legitimate if the value is marked as inferred and the reasoning is recorded.

Some inferences must be rejected. Inferring a garment's gender from its size range is a guess, not a reading. Regulatory fields — standards, certifications and compliance — are never inferred: either a source attests them or they remain empty. An enrichment process that cannot say “I don't know” is not reliable.

The economic lever: variants

In most catalogues, a model comes in multiple sizes and colours, and about 90% of attributes are identical across variants: material, standards, description and media. Enriching every variant as an isolated product means paying for the same work ten times. Group them first using a parent/variant structure — a group is defined by its variation axes such as size, colour or several combined axes, and can be reconstructed even if the catalogue has no existing structure — then enrich the model and copy shared data to the variants. Each variant takes a few seconds instead of a full analysis, with guaranteed consistency where independent processing would eventually diverge.

This propagation also provides a free quality check: a shared characteristic that differs between two variants of the same model is an immediately visible anomaly. Grouping not only saves work; it checks the enrichment too.

What to demand from an enrichment process

• Every value linked to its source — URL, document and page — or marked as inferred with its reasoning.
• Systematic verification of values against their sources, not sample checking.
• Written, revisable schemas for each category — not an undefined promise to “complete everything”.
• Human control points on each batch: AI proposes, human oversight validates.
• The ability to leave a field empty rather than inventing — completeness is not an end in itself.

Related topics: FAB-DIS · ETIM · enriching an existing PIM · product matching