Writing product descriptions with AI across thousands of SKUs without shipping an invented specification

A catalog of three thousand SKUs arrives with a title, a handful of attributes and no descriptions. Somebody runs each row through a language model, reads twenty results, finds them fluent and better than anything the supplier sent, and imports the lot. The problems appear later and somewhere else: in the returns queue, in a marketplace policy notice, and on a search results page where the same product appears eleven times.

We have generated descriptions for catalogs at this scale and cleaned up after other people's attempts. The output can be good. Whether it is depends almost entirely on what the model is allowed to see, and on how the review is organised.

The model fills every gap with a plausible fact

Give a model a row that says 'steel water bottle, 750 ml, blue' and ask for a description. You will get the bottle. You may also get 'food-grade 304 stainless steel', 'double-wall vacuum insulated', 'keeps drinks cold for 24 hours' and 'BPA-free lid'. None of that was in the row. Each phrase is what a bottle like this usually is, and that is what a language model produces by construction: the likely continuation, not the checked one.

Materials, dimensions, capacities, weights, care instructions and certifications are the attributes it invents most readily, because they appear in almost every description it has seen. The invented ones read identically to the true ones. A reviewer skimming for fluency will not catch them, and a reviewer checking every claim against the row is doing the work the model was supposed to save.

An invented spec is a return and a compliance exposure, not a copy error

A description is part of the offer a buyer accepts. When the bottle arrives single-walled and the listing said insulated, the return reason is 'not as described', the reverse shipping is yours, and on a marketplace the return counts against the account whoever wrote the sentence. Multiply that across a product line, and the copy that saved a week of writing has bought months of returns.

The compliance side is sharper in India. The Consumer Protection (E-Commerce) Rules require the information on a listing to be accurate, and Legal Metrology declarations such as net quantity and country of origin have defined meanings. A generated line claiming BIS certification, an ISI mark or FSSAI approval for a product that has none is a false claim in a regulated space. The model does not know which of those are legally protected marks. It has only seen them printed next to similar products.

Variants collapse into near-duplicates, and search punishes it

The second failure is quieter. A shirt in six sizes and five colours becomes thirty rows, and a per-row prompt produces thirty descriptions that differ by one adjective. On your own store, if each variant has its own URL, you have thirty near-identical pages competing for the same query, and Google will index one of them, not necessarily the one you would choose. Your on-site search returns the same shirt over and over, pushing every other product below the fold.

On a marketplace the variants sit under one parent, so the duplication shows up differently: as thirty listings with the same keyword density, which does nothing for ranking and reads as padding to a policy reviewer. Amazon and Flipkart both have rules against duplicate listings of one product, and a stack of variants with independently generated copy is how sellers create them by accident.

Generate at the product level. One description per parent, and for each variant only the sentence that is true of that variant alone: this colour, this size, this pack count. The Text Compare tool shows in seconds whether two variant descriptions differ by more than the attribute that separates them.

Marketplace rules apply to the text, not to how it was produced

Amazon.in, Flipkart and Meesho each accept generated content and each hold the seller responsible for it. Their content rules were written for humans and catch model output just as well: no promotional language in the description, no claims about shipping or price, no comparison with other sellers, no contact details, no text copied from a brand's own site. Generated copy is drawn to superlatives, so 'best', 'premium quality' and 'guaranteed' need stripping before upload. Field limits are mechanical too. A title over the marketplace's character cap is rejected whoever wrote it, and the Word Counter gives you a length before the bulk upload does.

Show the model the row and nothing else

The prompt that works is boring. It receives the structured attributes as a labelled list, states which fields must appear, states that no attribute outside the list may be mentioned, and asks for output in fixed fields with length limits. Anything the model might want to embellish, such as brand story or use cases, is either a column you supply or is left out.

sku,title,material,capacity_ml,colour,lid_type,dishwasher_safe
BTL-0142-BLU,Steel water bottle,stainless steel,750,blue,screw,no

Rules given to the model:
1. Use only the fields above. Do not add materials, grades, insulation,
   temperatures or certifications.
2. Output: short_description (max 160 chars), bullets (3, max 90 chars each).
3. If a field is empty, omit the sentence. Do not guess.

Notice what the row does not say: no steel grade, no insulation, no BPA claim. With this prompt, the description does not say them either. If you want insulation mentioned, add an insulated column, fill it from the supplier spec sheet, and the sentence appears only on the rows where it is true.

Review per product line, not per SKU

Reading three thousand descriptions is not a review; it is a second job. Reviewing by product line is. The prompt and the attribute set are shared across a line, so if twenty descriptions from the steel bottles pass a claim-by-claim check against their rows, the pattern that produced them is sound for that line. Sign off the line, then spot-check a few per batch afterwards.

1. Pick the product line and confirm every attribute column it needs is filled from a source you trust.
2. Generate for the whole line. Take a sample across sizes, colours and price points, not the first twenty rows.
3. Check every factual phrase in each sample against its row. A single invented attribute fails the line, not the SKU.
4. Fix the prompt or the source data, regenerate the whole line, and sample again.
5. Sign off the line by name and date. Record the model version and the prompt used.
6. When you regenerate later, diff the new output against the signed-off version and read only what changed.

The Product CSV Validator belongs at the end of this chain. Generated copy has a habit of carrying stray quotes, line breaks and commas that break an import, and the validator finds them before the marketplace's error report does.

Keep generated copy in its own column, and never let it overwrite data

Store descriptions in a field marked as generated, with the model version and the date beside it. Never let a pipeline write model output back into an attribute column. The attribute is the source and the description is a rendering of it. The moment a rendering is treated as source, you have lost the ability to say which of your facts were checked. When a better model comes along, or the prompt improves, you regenerate from the attributes and the whole catalog moves together.

Can you use AI to write product descriptions for an ecommerce catalog?

Yes, provided the model only sees structured attributes and is forbidden from adding any it was not given. Generate one description per product with a variant-specific line, strip promotional language to satisfy marketplace rules, review by product line with a claim-by-claim check against the source row, and store the output separately from your attribute data.