Should AI Ever Guess Your Product Data?

Here's a question that sounds technical but is really about liability: when AI touches your product data, what exactly is it allowed to do?

Because there are two very different operations hiding under the phrase "AI-enriched product data," and the market increasingly sells them as if they were the same thing.

One is structuring: taking meaning the merchant already published — in descriptions, titles, pages — and expressing it in the explicit, machine-readable form platforms need. The category resolved. The use cases the description implies, made into fields. The attributes the page states, structured.

The other is inventing: filling gaps with plausible guesses. Estimating a specification the page never states. Inferring a material. Completing a field because a model predicts what probably belongs there.

The first makes your data legible. The second makes it fiction with good grammar.

Why invented data is the merchant's problem, not the tool's

A product feed is not a creative document. It's a statement of record about someone else's products — yours. Every value in it is something a platform, a shopper, or an AI assistant may treat as fact and act on.

Now walk the failure through. A model estimates a dimension, a material, a compatibility, a safety-adjacent attribute. It's wrong — models are, some fraction of the time, by nature. The listing that carried the guess wasn't the tool's listing. It was yours. The disappointed customer, the return, the platform flag for misrepresentation, the review that says "not as described" — all of it lands on the merchant. The vendor that generated the guess is nowhere in that conversation.

Some competitors describe estimation as a feature — coverage!, completeness! We consider it a liability the merchant would ultimately carry. A gap in your data is a visible, honest problem. A confident guess in your data is an invisible one, wearing your name.

The principle: verified, never invented

This is a line worth being absolutist about, and it's one of the principles this product family is built on: the enrichment structures what the merchant published. It does not manufacture claims the merchant never made.

If the product page doesn't support a value, the feed doesn't contain it. No estimated specs, no inferred claims, no plausible filler. Measured, not estimated.

Notice what this costs: sometimes a field stays empty because your source data genuinely doesn't answer it. We think that's the correct price. An empty field tells you where your catalog needs work — useful information. A fabricated field hides exactly that, while adding risk.

The question to ask any vendor

If someone enriches, "optimizes," or "completes" your product data, ask them one question: "Where does each value come from?"

If every value traces back to something you published, you're looking at structuring. If the answer includes "the model infers…" or "we estimate based on similar products…" — understand that you're the one signing that statement of record.

Your catalog should say more than it used to. It should never say more than you did.

(So what does the machine on the other end actually see when it reads all this — structured or not? That's Article 5, and it's the most direct way to understand everything this series has argued.)

Find out where your catalog stands

→ Run the free Agentic Catalog Readiness Audit™ — see, on a real product from your catalog, what your published data actually supports.

→ Read the complete Pillar — AI-Ready Commerce Feeds™, the full picture behind this series.

Continue the series

← Previous: I Sell on Three Platforms and My Product Data Never Matches. Does It Matter? · ⌂ AI-Ready Commerce Feeds™ (Pillar) · → Next: What Does a Machine Actually See in Your Feed?

Series: AI-Ready Commerce Feeds™ (PI-PL002) · Knowledge Domain: Product Intelligence

NSOLVIA Intelligence — Products generate knowledge. Knowledge generates authority.