AI now touches most of the work around product data. It reads supplier datasheets, fills attributes, writes and translates descriptions, and maps products to channel categories. The quality of the output depends less on the model than on the product data model around it. This article covers how product information management AI works in daily operations, where it fails, what AI shopping agents now demand from product data, and which decisions stay with people.
Key Takeaways
- Language models extract product attributes well when the prompt carries attribute definitions with allowed values, plus reviewed examples of similar products. Without that context, accuracy drops sharply.
- Unit conversion is the weakest step. Let the model find the value and the unit, and do the conversion in code.
- AI shopping surfaces read structured feeds with strict rules. A generated "n/a" or an invented part number breaks them.
- Every AI write should land in a draft state with a record of the model, the prompt version, the input data, and a timestamp.
- People own the attribute model, the reference examples, the review of claims with legal weight, and the decision to change models.
Where AI Sits In The Product Information Management Stack
A language model knows what product text usually looks like. Your specific product exists for it only through the data you pass in. Most AI failures in catalog work start there.
The product record lives in a system of record. For descriptive data, that is a PIM system or a master data platform. It holds the attribute model: names, definitions, data types, units, allowed value lists, required attributes per category and channel, and the change history of every value. Prices and stock usually come from the ERP. Images and documents sit in a DAM.
AI works as a processor on top of these records. It reads values and source documents, proposes new values, and writes them back. The system of record decides where the output lands and who checks it before anything reaches a channel. Teams that let a model write straight into a shop or a feed lose the ability to trace or roll back what it wrote. They usually find out during the first supplier dispute.
The Tasks AI Handles Today
Attribute Extraction From Supplier Data
Manufacturers and distributors receive product data as PDF datasheets, scanned catalogs, spreadsheets with free-text columns, and supplier web pages. For years, someone retyped weight, dimensions, material, voltage and connector type into structured fields. An LLM can read the source and return the values as JSON that matches your attribute schema. This is where AI removes the most manual work.
The most useful public evidence on accuracy comes from a University of Mannheim benchmark on attribute extraction and normalization. The researchers built a test set of 565 product offers from 59 websites, with 4,687 manually verified attribute values, and tested GPT-3.5 and GPT-4 with different prompt designs. With only the attribute schema in the prompt, GPT-4 reached an F1 score (a measure combining precision and recall) of 74%. Ten example values per attribute raised it to about 80%. Adding ten demonstrations, meaning similar products with correct answers, raised it to 91%. That beat fine-tuned BERT-based extractors by about 10 points.
The models in that study are now old, and newer ones score differently. The pattern is what transfers. Accuracy came from context that a well-run catalog already holds: attribute definitions with example values, and approved records of similar products.
In the same benchmark, 45% of the attribute slots had no value anywhere in the product title or description. A model that fills every field is guessing on almost half of them. So the prompt has to allow an explicit empty answer, and the pipeline has to accept empty as a valid result.
The context also costs money. The best GPT-4 extraction prompt was about five times longer than the zero-shot version, and token costs grow with it.
Teams usually pick the demonstrations by similarity. The system embeds the incoming product text, retrieves the 3 to 10 closest products that already passed review, and inserts them as examples. Each reviewed product improves the prompts for the next ones.
Normalization And Unit Conversion
Extraction finds "20-lb." in a supplier text. Normalization turns it into the kilogram value and number format your attribute expects. In the Mannheim tests, GPT-4 handled name expansion, such as "HP" to "Hewlett-Packard", at 98% F1, and cleanup of part numbers and similar strings at 95%.
Unit conversion was the weak spot. When the model had to extract and convert in one step, GPT-4 scored 62% without examples and 83.5% with examples and demonstrations. When it only converted values that a separate step had already extracted, it reached 98%. The authors name conversion functions that the model can call as a direction for further research.
So split extraction from conversion. The model returns the number and the unit as found in the source. Code converts it. A conversion function gives the same answer every time, which is more than anyone can promise for a language model doing arithmetic.
Classification And Taxonomy Mapping
Every channel wants its own category. A manufacturer may maintain ETIM or ECLASS classes for B2B partners, GS1 GPC bricks for retailers, the Google product taxonomy for shopping feeds, and a separate category tree for each marketplace. Mapping thousands of SKUs by hand is slow, and mapping errors hide products from filters.
The common pattern combines retrieval with an LLM. The system embeds the product data and the class descriptions, shortlists candidate classes, and asks the model to pick one. Self-reported confidence from LLMs is poorly calibrated, so mature setups use agreement checks. The model's pick must match one of the top retrieval candidates, or two differently phrased prompts must agree. Products that pass go through. The rest go to a review queue.
Where to set the bar is a business decision. In ETIM, the class defines which features a product must carry, so a wrong class produces a wrong feature set. A wrong marketplace category mostly costs visibility.
Generated Descriptions And SEO Fields
This is the most visible use and the one with the most legal exposure. Models write long descriptions, bullet points, short feed titles, and meta descriptions per channel and language.
One rule prevents most problems: generate from approved attributes only. The prompt gets the structured values of this specific variant, the brand voice guide, the termbase, and the channel's length limits. It does not get family-level marketing copy or competitor text. After generation, a check compares the text with the attributes. If the text says "waterproof" and the product has no IP rating, the check fails.
Our customers turn to us with a version of the same problem. Their first AI descriptions read well and claimed things the products did not have. A common case is a veneer variant described as "solid oak" because the prompt included family text written for the premium variant. The fix has two parts. Prompts receive only variant-level attribute values. A post-check compares material, certification, and safety terms in the generated text with the attribute values, then routes mismatches to a person.
Translation And Localization
LLM translation handles product copy well in common language pairs, and many teams now use it as the default.
It needs a termbase: approved translations of product names, technical terms, units, and attribute values, inserted into the prompt and checked after generation. In a PIM, translate value lists once at the attribute level. "Stainless steel" then gets translated a single time per language instead of in 5,000 descriptions, and stays consistent everywhere.
Regulated text needs a separate rule. Safety warnings and legally required labels need a qualified human reviewer per market. A mistranslated warning is a product safety issue.
Images And Digital Assets
Vision models now read product photos reliably enough for routine work. Teams use them to write alt text, tag color and pattern, check that the image shows the right variant, and flag images that break channel rules, such as text overlays or non-white backgrounds. The red shoe on the black SKU is a classic, and vision checks catch it in bulk.
Generated lifestyle images are a separate decision. They show a real product in a scene that never existed. Keep them labeled as generated in the DAM, and check the EU disclosure rules covered below before publishing them.
Data Quality Checks
Reviewers get tired. Checks don't. Useful checks include outliers within a category, such as a 350 ml mug with a weight of 350 kg, descriptions that contradict attribute values, near-duplicates created by different suppliers, and missing attributes that a channel requires. Rules and simple statistics catch most outliers cheaply. LLMs add value on contradictions between text and attributes, which rules cannot read.
How A Governed AI Workflow Runs
Most AI quality problems in catalogs turn out to be process problems. Workflows that hold up in production share these steps:
- Trigger. A new product, a supplier update, or a changed attribute starts the job. Rules decide which fields to regenerate, so a corrected weight does not regenerate the marketing copy in 30 languages.
- Context assembly. The system collects the variant's attribute values, attribute definitions, value lists, channel limits, termbase entries, and similar approved products.
- Versioned prompt. The prompt template has a version number and a change log, like code.
- Structured output. The model returns JSON against a schema. Free text goes only into text fields.
- Deterministic validation. Code checks data types, value lists, units, GTIN check digits, length limits, and forbidden claims.
- Draft with provenance. The output lands in a draft or "AI proposed" state. The record stores the model and its version, the prompt version, an input snapshot, and a timestamp.
- Risk-based review. Safety, compliance, and claim-related fields go to a named reviewer. Low-risk fields get sampled.
- Publish and learn. Approved values flow to channels. Rejection reasons feed back into prompts and examples.
Provenance looks like overhead until the first incident. A provider updates a model, and your titles change tone overnight. A market surveillance authority asks where a claim came from. With provenance, each of these becomes a query. Without it, someone digs through exports and email threads.
AtroPIM handles this through its AI Integration module, which connects language models such as ChatGPT and Gemini to product records, with prompts that teams adapt to their brand voice and use case. Generation runs in bulk or through workflow rules when product data changes, and users review and edit the generated content before it is saved and published. Switching the engine is a dropdown choice, so a team can run the same prompt against two models before committing to one.
Feeds For AI Shopping Agents
AI assistants from OpenAI and Google now show products inside conversations and, in some markets, let shoppers buy without visiting the shop. They read structured feeds and structured page data. For these channels, the feed is the storefront.
OpenAI's product feed specification for ChatGPT shows what this means in practice. Discovery needs nine fields: item ID, title, description, product URL, brand, seller name, image URL, availability, and price. The description has to be factual and in plain text. The spec asks for titles up to about 150 characters and descriptions up to 5,000. Several of its rules collide with careless AI enrichment:
- The spec says to omit unknown values and not to use placeholder strings such as "null", "unknown," or "n/a". The Mannheim research prompts, like many production prompts, return "n/a" for missing values, so map them to empty before export.
- GTINs need a valid check digit and their leading zeros. A spreadsheet that stored the GTIN as a number has already broken it.
- Dimensions must describe the product itself. Package dimensions belong elsewhere, and units are never inferred. Supplier data mixes both constantly.
- An item ID must never be reused for a different item, and offer IDs must not contain the price.
"Do not invent a value to replace a missing GTIN." OpenAI's note on the part number field reads like it was written with LLM enrichment in mind.
An LLM asked to complete missing identifiers will produce plausible part numbers. Identifier fields should be excluded from generation entirely.
The spec also expects current price and availability, updated when they change. Product data teams rarely own those values. The ERP does. So an agent-ready feed joins descriptive data from the PIM with commercial data from the ERP, on a refresh cycle that matches how fast stock moves.
Optional fields carry more weight with agents than with classic shopping ads. Return windows, shipping charges, materials, and product dimensions let an assistant answer "will it fit" and "can I send it back" without sending the shopper to your page. When those values are missing, the assistant guesses or moves on to a product whose data answers the question.
Each platform has its own schema, and the schemas change. The practical setup is one master record in the PIM and a channel mapping per platform. A new AI channel then becomes a mapping task. The standard OpenAI file upload currently targets the US market, so European manufacturers can read it as a preview of the data quality bar that AI channels set.
Risks That Need Attention Now
Invented Facts With Your Name On Them
Generated content is your product statement. Consumer protection and product liability rules do not ask which tool wrote it. The highest-risk fields are safety warnings, certifications, material claims such as "food-safe" or "BPA-free", compatibility statements, and performance values.
AI may phrase a fact. It should never create one.
Every value in these fields needs a source: a supplier document, a test report, a certificate, or a person who signs off.
Prompt Injection Through Product Data
Supplier files and scraped pages are untrusted input. A datasheet can contain text that a model reads as an instruction, hidden in white font or in a metadata field. The risk grows when AI agents get write access to the catalog through MCP servers or similar connectors.
Start agents read-only, with questions like "which SKUs in this line are missing a declaration of conformity". Grant write access per field group. Route agent writes through the same draft-and-review path as other AI output, and log every call.
Model Changes You Did Not Schedule
Providers update and retire models on their own timeline. The same prompt can produce different output after an update. Pin model versions in production. Keep a fixed evaluation set of a few hundred reviewed products with known correct attributes and approved texts, and run it before any switch. Compare results per field. An average accuracy number hides the one attribute that got worse.
Regulation In The EU
The transparency obligations in Article 50 of the EU AI Act have applied since 2 August 2026. The Digital Omnibus postponed most high-risk obligations to December 2027 and later, and left Article 50 unchanged.
A shopping assistant or chatbot on your storefront must make clear that users are talking to an AI, unless that is obvious. Machine-readable marking of generated content is mainly an obligation for providers of generative AI systems, with a grace period until 2 December 2026 for systems already on the market. Realistic generated images that show a product in an invented scene may count as deep fakes, which require disclosure. Ordinary product descriptions generally fall outside the disclosure rule for AI-generated text, which targets text published to inform the public on matters of public interest. Borderline cases need legal review.
The Digital Product Passport adds a second track. The battery passport becomes mandatory on 18 February 2027 for several battery categories, including EV batteries and industrial batteries above 2 kWh. Other product groups follow through delegated acts. Passport data is compliance data: material composition, recycled content, carbon footprint, and due diligence information. AI can extract it from supplier declarations and check completeness. It should not estimate a missing value. Each value needs a traceable source document, which is the provenance trail described above.
Data Exposure And Cost
Unreleased product data sent to an external API leaves the company. Check where the provider processes the data and whether it uses inputs for training. Some manufacturers route launch-sensitive products to a self-hosted model for this reason.
Cost scales with context and volume. Few-shot prompts run several times longer than zero-shot ones. A prompt tweak that triggers regeneration of 50,000 SKUs in 20 languages is a budget event. Regenerate only the fields a change affects.
Content That Sounds Like Everyone Else's
Competitors use the same few models with similar prompts. Their generated copy converges on the same phrasing, and so does yours. Differentiation has to come from data only you hold: test results, application notes, compatibility tables, and installation limits. Put those into the attribute model so the generator can use them.
What People Still Own
In the Mannheim tests, the context around the model moved accuracy more than anything else. That context is human work.
Someone defines each attribute and its allowed values. "Size" without a definition produces sizes in four systems. Someone curates the reference products that serve as examples and as the evaluation set. Someone decides which fields need review and signs off on claims with legal weight. Someone resolves conflicts between two suppliers who disagree about the same part, and handles the new product type that fits no existing class. And someone approves a model or prompt change after looking at the evaluation results. Each of these roles needs a named owner per field group.
Our customers turn to us with catalogs where the same property exists four times, as "Color", "Colour", "Main color" and "Farbe", each filled by a different supplier import. Adding AI to that catalog produces confident values in all four fields, often different ones. The work that pays off first is consolidating the attribute model. AI comes second.
AI scales whatever data model you give it. A clean model scales into consistent data. A messy one scales into faster mess.
The job of product data managers shifts accordingly. Less typing, more configuration and review: prompts, value lists, validation rules, and review checklists. Review needs structure too. A reviewer with a checklist per field group catches invented claims. A reviewer asked whether something looks fine approves it.
A Practical Starting Sequence
Start with one category that has good source documents and a clear attribute model. Build the evaluation set before writing the first prompt: 200 to 300 reviewed products with verified values. Run extraction into draft fields only, and measure accuracy per attribute and review time per product. Where the model fails, look at the attribute definition first. Vague definitions cause many errors.
Move to generated descriptions once extraction is reliable, because generated text is only as accurate as the attributes underneath it. Add translation after that, with the termbase in place. Map channel feeds last, including AI shopping feeds, and validate identifiers, units, and empty values in code before export. Give agents read access first. Write access comes after the draft-and-review path has handled a few thousand AI writes without surprises.