Product data enrichment with AI: what we learned building a flow that works at catalogue scale

Product data enrichment is the work of turning minimal product data into complete, sales-ready listings: populating attributes, writing descriptions, adding imagery, and meeting each channel's field requirements. In ecommerce it covers the distance between what a supplier sends you and what Amazon, eBay, or your own webshop demands. Guides often split the data into technical, marketing, and logistical types. Useful enough, but the split matters less than where the values come from and who vouches for them.

That is the definition, and it is not where quality is decided.

When AI enrichment disappoints, the instinct is to blame the model. In our experience, the outcome was decided earlier, by two things the team controls. The first is the attribute structure the AI works against. Structured properties feed AI and human content writers alike, and the quality ceiling of generated content is set by the property data underneath it, not by prompt sophistication. We have written about that first lever before, in Your AI content tool is not the problem. Your attributes are.

The second lever is the one this post is about: the enrichment skill, the specification that tells the AI what to do. It gets far less attention than model choice. It could be deciding more of your output quality than the model is.

You write an enrichment skill: a specification of which attributes to populate, from which sources, and what to do when unsure, and you run the model against your structured attributes rather than against a blank page.

Before the how, the honest nuance. If you run a few hundred products and the fields at stake are low-risk, a loose prompt in a chat window often does the job. Paste the supplier text, ask for a description, sanity-check it, move on. That works, and it gives fine-grained control. The trouble starts when one instruction runs thousands of products across an ecommerce catalogue. A prompt runs a document. A skill runs a catalogue.

The version that worked for us reasons schema-first. The skill starts from the attribute schema and the values that already exist, and works outward: which fields are empty, which of those this product type actually requires, and what is available to fill them. That is the reverse of ad-hoc prompting, which starts from a source document and asks the model what it can extract.

Written down, the skill makes four decisions explicit:

1. Which attributes it may populate, per product type.
2. Which sources it may draw on, and in what order. The set: image metadata, supplier documents, and online research when it is a known product with a public record. The order is the skill designer's choice, but working cheapest-first is a sound strategy for keeping token spend down: what the schema already holds, then images and documents, reaching for online research only when the answer is not already in hand. And online research earns its place only for products the wider world has already described; an own-label item nobody has written about yet gives the model nothing to find.
3. When it may add a value the schema does not yet hold: only when certain.
4. What it must do when unsure: stop and flag, never guess.

Written out, three lines of a skill might read: populate colour, material and season for apparel; consult the schema's allowed values first, then images, then the supplier sheet; if a garment could be filed under two categories, stop and flag it. Plain rules, and they govern every product that passes through.

Just as important is what the skill does not ask the model to do. Attributes that are absolute and known at purchase-order time (size, colour, material as bought) can be frontloaded into the schema before any AI runs. The working rule: if a value is absolute, frontload it; if it is conditional, that is what the model is for. Every field you frontload is a field the model cannot get wrong and never bills you for. The model's job is the conditional layer: classifications, channel-specific expressions, fields that need judgement.

Note the phrase "against your structured attributes". The skill does not ask the model to write listings freestyle. It asks it to fill a schema, field by field, with the allowed values in view. The narrower the question, the easier certainty becomes.

Then the gate, the design principle the whole skill hangs on: whatever the model decides, it must be certain before committing new data. Certain is not a mood, and it is not the model grading its own confidence. It is defined by the skill's rules: the value is present in a named source, or it follows from an inference rule the skill explicitly permits (a product photographed in black may carry Black into the eBay colour field). Everything else counts as unsure, and unsure means stop and flag. We will not claim the rule as an invention; other writing in this space lands on versions of it, usually phrased as "flag what you can't confirm". What we can add is what happens when you run it across a catalogue, which is the rest of this post. The rule also settles an argument that runs through most enrichment guides, completeness scores on one side, gap-flagging on the other. Both are right. Completeness is the goal, certainty is the gate. An empty field is a task someone can pick up. An invented value is a defect that ships.

In practice, the product data enrichment workflow we landed on looks like this:

1. Frontload the absolutes: values known at order time go straight into the schema.
2. Run the skill against the attribute schema, drawing on its named sources.
3. Commit only what passes the certainty gate.
4. Route everything else to attribute review, flagged with the reason it stopped.
5. Generate channel content from reviewed attributes only.

You may notice what is missing: the audit-your-data, define-your-standards, validate-and-publish checklist that most guides open with. Nothing wrong with it. It just never says what the AI is actually told to do in the middle steps, and that instruction is where the quality is won or lost.

The review gate sits between attribute population and content generation on purpose. An attribute error caught at review costs one correction. The same error caught after content generation has already been written into every description that used it, and costs far more to unwind.

A note on where all of this runs, because the approach assumes a substrate: something has to hold the attribute schema, the allowed values, the media and documents, and the state of the work itself, all readable by a model. That is the shape we built OneSila to be: a PIM for multichannel catalogues with the structure an enrichment skill pushes against, built-in AI for content writing and auto-mapping, and an MCP integration for teams that prefer to bring their own agent and write their own skills. Whether you build on OneSila or on something else, the requirement does not change: the skill needs structure to work against. Enrichment without a schema is prompting with extra steps.

A certainty-gated flow is selective. Absolutes never reach the model, settled fields are not re-decided, and model time concentrates on the conditional attributes where it adds something. A brute-force bulk pass, by contrast, sends every product, with all its source material, through the model on every run, whether anything needed deciding or not. Teams that build their own agentic enrichment pipelines tend to raise token cost unprompted, and at catalogue scale it is a fair concern. We will not pretend to give you a cost formula; catalogues, models, and source material vary too much for that. But the mechanism points one way: paying for judgement calls tends to be a smaller bill than paying to re-read your whole catalogue.

That is also the honest answer to bulk product data enrichment. The goal is not the biggest possible pass. It is the smallest pass that moves the catalogue forward.

In our experience it often fails at one of two opposite poles, and they look identical in the output.

Too strict, from a real case: a product had Colour set to "Black", and the Colour (eBay) field stayed empty. The model knew the answer. It was sitting one field away. But the skill never said it was allowed to infer across channel fields, so it withheld a value it effectively already had. Marketplaces often want slightly different expressions of the same value, and carrying a known value into each channel's variant is exactly the kind of work AI handles well, when the skill permits it.

Too loose, also real: an item with ambiguous source data was classified as for children when it was for adults. The model committed a guess it should have flagged.

Both poles surface the same way: someone spots a wrong or missing value and concludes the AI got it wrong. But the fixes point in opposite directions. One needs the skill loosened at a specific point, the other tightened. Treating them as one problem ("the model isn't good enough") fixes neither.

The threshold between the poles is a calibration problem, not a dial you set once. A pattern we see on first high-certainty runs: the pass comes back with far fewer fields filled than expected. Item condition blank. Dangerous-goods flags blank. Classifications any human would call obvious, blank. The first instinct is to loosen the threshold. The better fix is often global defaults, applied before the AI runs, so the model only spends its caution on genuine uncertainty. Expect the first run to be conservative either way. That is the gate doing its job on day one, before calibration has caught up.

It is worth diagnosing before fixing, because bad attribute data comes from three sources with three different fixes. A wrong inference means revisiting the skill and reviewing known error patterns. Missing supplier data is a chase process, a supplier data management problem rather than an AI problem. And an incomplete skill definition, a field the skill never knew to populate, stays invisible until someone asks why it is always empty. All three produce the same symptom in the catalogue.

The stakes compound downstream. Once an attribute is committed, downstream AI treats it as truth: one wrong upstream value gets written into titles, bullet points, and descriptions on every channel at once, and whoever checks content at the end inherits the full correction bill. That is what the certainty gate is buying you.

The useful split follows error clusters, not volume percentages.

"AI handles volume, humans handle judgement" is the stock answer, and it is not wrong. It is just unusable, because it does not tell you where to point the humans.

What we have seen is that AI attribute errors are not random hallucinations scattered across the catalogue. They cluster, predictably, in two places: classification ambiguity (is this theme Christmas or generic winter, is this garment a tailcoat or a jumpsuit) and un-inferable data (a colour that simply is not visible in any input). Because errors cluster, review can be a bounded, targeted job aimed where the errors live, rather than a blanket pass over everything the model touched. And it shrinks over time, as each cluster gets addressed in the skill.

If you are running the numbers on a first pass across a large catalogue: the review queue is bounded by the error clusters, not the catalogue size. The flags concentrate where ambiguity lives, and they shrink as the skill closes each gap.

Review also turns out to be two different jobs that look identical in the queue. One is correcting a wrong guess: the model chose, the human overrides, done. The other is a research trigger: the data does not exist in any source, and someone has to chase a supplier or a colleague to get it. A workflow that records why a field is incomplete lets reviewers triage between the two instead of guessing.

The contrast case is enrichment run as an invisible background job, with no gate between generation and publish. Errors then surface by accident, sometimes as physically impossible values sitting live on a storefront. In those setups the missing piece is rarely a better model. It is validations, and a visible trail of what the AI did.

One accountable owner, in our experience. A group can work too, but only if everyone in it thinks in abstract, catalogue-wide terms.

The reason is blast radius. A skill change is not like editing one product; it changes behaviour for every product that runs through the skill from that moment on. Loosen an inference rule to fix the eBay colour case and you may also have changed how the model behaves on a category you were not thinking about. The risk being guarded against is one change quietly breaking something else across the catalogue. That is why skill definition is specialist work, closer to writing policy than to writing copy, and not something everyone edits on the side.

A skill is also a living artefact, not a one-off setup. First versions are a starting point; teams iterate on thresholds, add default lists, and encode platform rules as errors surface. Which means months of accumulated refinement can end up embodied in one file. We have seen that go badly: skills living on a single machine, no backup, no version history, and a rebuild measured in months if that machine dies. Infrastructure-grade care (versioning, backups, a record of what changed and when) could be the cheapest insurance in your whole enrichment setup.

It also suggests treating write access to skills the way you treat admin rights elsewhere in the stack: not everyone who uses the skill needs the ability to change it. How you arrange that will depend on your team and your stack. That you decide it deliberately, rather than by default, is the point. Where a skill runs depends on whose agent does the work: a platform's built-in features, or your own scripts connected over MCP, a boundary we unpack in What is an agentic PIM?

The market seems to be arriving at the same conclusion. Dedicated product data specialist roles, distinct from channel managers and marketing, are starting to appear in operator teams. The skill owner is a role being invented in real time. And there is a further shift on the horizon: enrichment aimed at AI shopping agents rather than human shoppers. Structured attributes first serves both audiences; the skill simply gains a new channel to reason about.

So: two levers. The attribute structure the AI works against, and the skill that tells it what to do. If your enrichment output disappoints, it could be worth checking both before checking the model benchmarks. The model is rented. The levers are yours.