Product data is what your AI systems read
AI search, shopping agents and enrichment runs all read your product records. What an agent actually reads, and what the record needs: types, checks and a history.
On this page
Many AI-in-commerce projects hit the same wall. A team turns on AI enrichment and gets generic, invented copy. They launch AI-powered search and watch it surface the wrong products. They send product feeds to AI shopping channels and find their products left out of comparisons. They build a product assistant that recommends out-of-stock items, or cites specifications that don’t exist.
The cause is usually the same. The product data underneath was written for a page, not for a machine. It’s free text, spread across systems, without types and without a record of who set what.
AI commerce runs on product data that is typed, checked and kept current. Not “clean data.” Not “enriched content.” Records a machine can read: attributes with types and units, values that passed a check, and a history of who changed each one.
Product data is a system layer now.
For two decades, product data was a writing job. Teams wrote descriptions, uploaded images, filled in attribute fields and published to the webshop. The data existed to render a product page. A person read it on a screen.
That model no longer covers it. The things reading your product data now include:
- AI search engines such as Google AI Mode and Perplexity, which compare structured specifications across merchants and recommend from them
- AI shopping agents that read product feeds and check out through the Agentic Commerce Protocol (ACP) or the Universal Commerce Protocol (UCP)
- Enrichment runs that write content per locale, pull attributes out of supplier documents and check completeness on their own
- Compliance checks for the EU General Product Safety Regulation (GPSR) today, and for Digital Product Passports (DPP) as they phase in from 2027
- Personalization engines that match product attributes to buyer intent signals across sessions and channels
- Internal AI assistants that query catalog data to answer team questions, create tasks and start the next step of a workflow
- Feed builders that turn product data into a file per channel, against requirements that keep changing
Each of these needs typed attributes it can fetch over an interface. None of them works reliably from a free-text description, a spreadsheet export or a PDF spec sheet. Product data isn’t content a person reads. It’s the thing other systems run on.
Note
The infrastructure test
Infrastructure has properties you can check. It’s reliable, because values pass validation and rules decide who may change them. It’s reachable over an API, not locked inside a screen. It’s typed, not free text. It’s current, because it updates as the data changes rather than at export time. And it’s trusted, because each value records where it came from and changes can be checked after the fact. Product data missing any of these is content. AI systems can’t build reliable operations on content.
What an agent actually reads.
In an AI-native commerce architecture, product data has one job. It is the context an agent reads before it decides anything or writes anything. That is a different job from “a database that stores product information.”
A context layer carries:
- Facts an agent can reason over: typed attributes with units, validated values, and a record of where each value came from
- Links an agent can follow: “this product is a variant of X, compatible with Y, replaces Z, regulated under standard W”
- Completeness an agent can read: “this product is ready for Amazon DE except care_instructions and secondary images”
- Rules an agent respects: “this attribute requires senior approval, this field is locked after publish, this change triggers compliance review”
- Current state an agent can trust: approval status from the catalog, and price and stock from the systems that own them, not yesterday’s export
Whenever an agent works on your catalog, enriching, validating, recommending or publishing, it is reading this context layer. If the layer is incomplete, inconsistent or stale, what the agent does will be unreliable. That isn’t the model failing. It’s the context you handed it.
What depends on it.
This isn’t an isolated investment. The state of your product data is the foundation that decides whether each of these commerce capabilities works or fails.
Scroll sideways to see the whole table.
| Commerce capability | What it needs from product data | What happens when the data can’t supply it |
|---|---|---|
| AI shopping (product feeds, UCP or ACP checkout) | Typed attributes, availability that is current, and specs an agent can line up side by side | Shopping agents may not see the products, and comparisons may leave them out |
| Publishing to marketplaces | Completeness per channel, content per locale, the right format, and required fields that passed a check | Rejections come back round after round, and listings get suppressed while someone fixes them by hand |
| Regulatory compliance (DPP/GPSR) | Typed safety and sustainability attributes, and a record of where each value came from | A scramble through a manual audit, and regulatory exposure |
| AI content generation | Typed source attributes for the model to work from, and schemas to check what it writes | The model writes from nothing and invents specifications |
AI fails on thin context.
AI is only as good as the context it gets. That sounds obvious. Three failures follow from it.
A model with gaps fills them in.
Ask an AI to write a description for a wireless headphone. Suppose the source record holds only “Sony WH-1000XM5 - Black” and a price. The model invents the rest from its training data: battery life, driver size, codec support. Those may or may not be right for this model revision. You gave it a name and asked for a description, so it fills the gap with something that reads plausible.
Now give it structured attributes: noise_cancellation=true, battery_life_hours=30, weight_g=250, driver_size_mm=30, codecs=[LDAC, AAC, SBC], connectivity=bluetooth_5.2. The same model writes accurate, specification-grounded copy. It has facts to work from instead of gaps to fill.
Agents may skip what they can’t settle.
A purchasing agent compares headphones across three brands. Your product says “30hr battery” in one channel’s description and “up to 28 hours” in the marketplace listing, and your feed doesn’t carry a battery_life_hours attribute at all. The agent has three options: guess which is right, average them, or leave your product out of the comparison. An agent built to protect buyer trust may well take the third.
Unstructured input stops the run.
Take an enrichment run that should do this in order. Check the product against a marketplace’s requirements. List the attributes that are missing. Write the missing content. Send it for approval. Publish.
None of it executes if “marketplace compliance” isn’t defined as a structured set of requirements. The same holds if “missing attributes” can’t be computed from a typed schema, or if “publish” doesn’t have a completeness gate to pass. Every step needs machine-readable attributes. Free-text fields and untyped data halt the run at step one.
What the architecture needs.
Going from “catalog content management” to product data a machine can act on takes a few specific capabilities.
Every family has a schema.
A product family defines its attribute schema: required fields, data types, units, validation rules and the requirements of each channel. A “Laptop” family sets screen_size_inches (number, 10-18), ram_gb (select: 8, 16, 32, 64), storage_type (select: SSD, HDD, hybrid) and processor (text, required). That schema isn’t metadata decoration. It’s the interface contract that AI systems depend on.
Steps that run without a person in between.
A run should do several steps with less hand-coordination: supplier data comes in through a saved mapping, agents check it and draft what is missing, people handle the exceptions, approved products are published, and each step leaves a record. In CataZenta, agents can be chained into flows, and imports and publishing run as separate tracked jobs.
Check it before it lands.
Changes should pass validation before they reach the catalog. Type checking. Unit consistency. Business rules, such as price > cost and weight > 0. Schema conformance, so required fields are present. Cross-reference checks, so a supplied EAN has the right format.
AI-generated content needs more than that: a confidence score, a link to the source, and a person reading any claim that isn’t grounded in a source attribute. Ask every vendor which write paths skip these checks, including imports, API calls and AI assistants. In CataZenta, range and format checks run in the product editor, not on imports or the API; agent suggestions wait for review by default.
One family per product.
Classification isn’t a suggestion. Every product sits in exactly one family in one consistent hierarchy. The family decides which attributes are required, which validation rules apply and which completeness template scores the product. Move a product to another family and it is validated again. Change the taxonomy and the change reaches the products under it. The system holds that consistent, so it doesn’t rest on human discipline.
Who can change what, and the record of it.
Control over who can change what isn’t bureaucracy. It’s what makes AI output trusted across a large catalog. Role-based access decides who can edit what. By default, agent suggestions go to a reviewer before they apply. A record of changes and approvals is the trust layer that lets autonomous operations run more safely. In CataZenta, product edits save numbered versions with who and when, and each agent suggestion keeps who approved or rejected it.
Enrichment doesn’t end.
New products enter the catalog daily. New channels arrive with their own attribute requirements. Regulations change. AI capabilities improve. So enrichment isn’t a project with an end date. It has to keep running: find the gaps, draft the missing content, check it, and send it for review. People handle exceptions and policy changes.
Other systems have to reach it.
Your product data is only infrastructure if other systems can reach it. That means REST APIs for programmatic CRUD, Model Context Protocol (MCP) tools for AI agents, structured feeds for channels, trackable jobs for integrations, and OAuth-scoped access for third-party systems. If getting at your product data means logging into a screen or asking for a CSV export, what you have is a content management system, not infrastructure.
Start with an audit.
Before you build anything, measure where you are against what infrastructure requires.
- Audit attribute structure. Take your top 100 products by revenue. How many of their attributes are typed (number, select, boolean), and how many are free text? If most are free text, AI systems can’t reason reliably over your data.
- Count your sources of truth. How many systems hold product data? More than one means a synchronization problem, and it compounds with each AI system you add.
- Measure programmatic access. Can an outside AI system, Claude or a purchasing agent or your own enrichment run, query your catalog over the API or MCP and get structured responses back? If access takes a screen login or a CSV export, your data isn’t infrastructure.
- Check validation coverage. What share of product writes pass automated validation before they enter your catalog? If the answer is “none” or “only on manual publish,” nothing is holding data quality.
- Assess how much you can trace. For any product, can you answer “who changed this attribute, when, from what source, with what approval”? If not, you can’t trust your data, and neither can an AI system.
- Evaluate what runs unattended. Can a multi-step operation, import then validate then enrich then publish, run end to end without someone coordinating each step? If not, your operations scale linearly with headcount.
Score poorly on 4+ of these and the work is structural. Build the data model, settle where the authoritative record lives, and put validation in place before you invest in AI tooling. AI on top of untyped, unchecked data produces confident, wrong output across the catalog, which is worse than leaving the AI switched off.
When AI output goes wrong, the record the model read is often the problem, not the model.