AI in eCommerce: Turning Fragmented Product Data into a Catalogue You Can Trust

AI can produce a product description in seconds.

The harder part is making sure it does not invent a missing specification, assign the wrong category or return data in a format the catalogue cannot use.

Product data rarely arrives ready for publication. It may come from supplier feeds, internal systems, web sources and existing catalogues. The same property can have several names, appear in different formats or sit somewhere inside an unstructured description.

Language models are useful in this environment because they can interpret text that would otherwise require a growing collection of rules and exceptions.

Their output still needs to be checked before it can be trusted.

Where AI adds value

Rule-based logic works well for predictable operations. It can validate a date format, convert a value, check a required field or match an input against a controlled list.

The problem becomes harder when the meaning depends on context.

One supplier may provide a product material as a dedicated attribute. Another may mention it only in the description. A third may use an abbreviation or its own naming convention.

Each variation can be handled with another rule. As the number of sources grows, however, that approach becomes difficult to maintain.

AI can help with tasks such as:

• extracting attributes from unstructured text;
• mapping different expressions to a common internal model;
• converting descriptions into a defined set of fields;
• suggesting or ranking categories from an existing taxonomy;
• preparing and adapting product content.

These use cases do not apply to every online store. If product data already arrives in a stable structure, adding a language model may offer little value. It is most useful when the same information appears in many forms and maintaining a complete set of deterministic rules becomes impractical.

Suggesting a category or attribute value is also only part of the job. The result still needs to be mapped to the actual catalogue model of the commerce platform.

Even after the mapping is resolved, the system still needs to check whether the model interpreted the source data correctly.

In one eCommerce project we worked on, a separate platform collected, processed and enriched product information from external sources. OpenAI functionality formed part of a wider backend process alongside integrations, APIs and business logic, without writing directly to the storefront.

The model’s output therefore remained an intermediate result. The surrounding system still had to decide whether the data was suitable for further use.

Suppose a model receives a product description and returns fields for material, colour and closure type. Checking that the response follows the expected structure is only the first step.

The system also needs to establish whether:

• the fields exist in the internal data model;
• the values belong to the permitted vocabularies;
• the attributes are valid for that product type;
• the source data supports the model’s conclusion.

That final check matters. Leather may be a valid option in the material dictionary, but its presence in the dictionary does not prove that the product is made of leather.

For factual attributes, the model can return the proposed value together with the exact source passage or the field from which it was extracted. This does not automatically prove that the interpretation is correct, but it makes the result traceable to the source data.

When the source is missing, ambiguous or inconsistent with other data, the safest outcome may be an empty field or an additional review step.

Why model output should not go straight into the catalogue

A language model does not guarantee factual accuracy. It can return a convincing, well-structured answer even when the input contains too little information.

It may:

• fill in a specification that was never provided;
• return a plausible but incorrect value;
• choose an unsuitable category;
• understand the text but place the result in the wrong field;
• break the structure expected by the receiving system;
• handle similar descriptions inconsistently.

Malformed data is usually easy to reject. Plausible errors are more dangerous because they can move through the pipeline without attracting attention.

The cost of an error also depends on the field.

An awkward sentence in a draft description can be edited. A wrong compatibility attribute or mandatory technical specification may affect filtering, product selection and the customer’s decision.

Fields such as price, SKU and stock availability should generally come from the systems that own that data rather than be inferred from free text by a generative model.

The quality of the prompt still matters, but control comes from the process around the model rather than wording alone.

Making AI part of a controlled system

A simplified workflow looks like this:

Before the request is sent, the system should define:

• which data the model receives;
• which operation it should perform;
• which fields it may change;
• which values are permitted;
• which response format is required;
• how missing information should be handled.

The model does not need to see the entire product record for every task. A focused context reduces irrelevant interpretation and makes the output easier to evaluate.

Smaller operations are also easier to test and debug than a single request that extracts attributes, detects duplicates, selects a category and writes marketing copy at once.

Structured output helps the receiving system validate the response programmatically. It can enforce required fields, data types and permitted formats.

Schema compliance, however, says nothing about whether the answer is factually correct. The validation stage therefore needs several layers.

A failed validation should lead to a defined outcome. The system might retain the original value, apply a deterministic rule, retry with adjusted context or send the record for human review.

Once the data has passed these checks, it can move on to the commerce platform. The next question is how those updates should reach Magento and how the integration should account for the structure of the catalogue.

The integration approach depends on the wider architecture, but the model still handles only one stage of the workflow.

Test the AI workflow before it reaches a live catalogue

Runtime validation protects individual records. It does not show whether the overall AI use case performs well enough for production.

A few successful examples are not sufficient.

The workflow should be tested against a representative set of real product data with known correct results. The evaluation can measure:

• how often the model returns the correct value;
• how many valid attributes it misses;
• how often it introduces unsupported values;
• which product categories produce weaker results;
• which source formats or expressions cause failures.

Attribute extraction often involves a trade-off. A conservative model may leave too many fields empty. A more aggressive configuration may increase the number of unsupported values.

The acceptable balance depends on the task. Draft copy can tolerate more automation than compatibility data or mandatory technical attributes.

The evaluation should also be repeated after meaningful changes to the model, prompt, input structure or business rules. A workflow that performed well under one configuration may behave differently after an update.

These checks help establish whether the AI output is suitable for a production workflow. After that, the remaining questions concern the commerce architecture: what Magento should receive, which system owns each part of the data and where transformation logic should sit.

This is where Foxycom’s Magento expertise comes in.

What happens after AI: Foxycom’s Magento perspective

What data should Magento receive?

Ideally, interpretation should already be finished by the time data reaches Magento. Magento should receive a product record expressed in its own catalogue model: the canonical SKU, explicit product type and attribute set, category assignments, attribute codes, resolved values for select and multiselect attributes, and the correct store-view context for scoped fields.

For configurable products, the child SKUs, configurable attributes and their option values should also already be known. At this stage, common failures are usually mapping failures rather than AI failures: an option value that does not exist, an attribute that is not part of the assigned attribute set, an invalid category ID, incomplete product identifiers, or a store-scoped value written in the wrong context.

Magento should validate and persist the product record. It should not have to work out what the incoming data was intended to mean.

Where should the boundary sit between Magento and the external layer?

We draw the boundary so that interpretation, enrichment and normalisation happen outside Magento, while Magento enforces commerce-specific catalogue rules when the data is persisted. The external layer can extract attributes, normalise terminology, resolve categories and attribute options, deduplicate source records and prepare a canonical product payload. Magento then applies the platform rules around products, categories, relationships, scope and catalogue integrity.

Just as importantly, ownership of each field should be explicit. An external content pipeline may own AI-enriched descriptions, while pricing and inventory may be owned by an ERP or by Magento depending on the wider architecture. The important principle is that each field has a clearly defined source of truth and update direction.

The same applies to mapping logic. Category, attribute and value mappings should exist in one place. If the same rules are independently implemented in middleware and Magento import scripts, they will eventually drift, leading to conflicting updates, synchronisation failures and feedback loops between systems.

Questions to answer before introducing AI

Before adding a model to a product-data workflow, the team should be able to answer several questions.

Without clear answers, it is probably too early to introduce AI into the catalogue workflow.

AI should have a specific job

The value of AI in eCommerce goes beyond writing product descriptions.

It can help turn fragmented, unstructured information into data that a catalogue can use, especially where deterministic rules become difficult to maintain.

In practice, the model works best when its role is limited to a specific operation and the surrounding system remains responsible for the final result. The model can extract, structure or suggest a value, but the rules that determine whether it becomes part of the catalogue should remain controlled.