The wrong argument, held loudly
The AI conversation in most commerce teams is about which model. The right answer in 2026 is roughly any of the credible ones, and it will be a different model in eighteen months. The choice does not warrant the airtime it gets.
The conversation that does warrant the airtime is the one nobody is having. The model is asked a question about a product. To answer it well, the model needs the product to exist in a form it can reason about. For most B2B catalogues, that form does not exist yet.
What a model actually needs
A useful answer to a buyer question depends on four things. A clean canonical record for the product. Structured attributes that match the way buyers actually ask. Relationships between products, accessories and alternatives that reflect how the business sells. And the operational data, stock, lead time and contract price, that lets the answer be specific to the buyer asking.
Most B2B PIMs hold the first one inconsistently, the second one partially, the third one as tribal knowledge and the fourth one in a different system entirely. That is the project. The model is the smaller part.
"You cannot build a credible AI layer on a thin data foundation. The model is interchangeable. The structured catalogue is not."
The work that actually pays off
Three pieces of work tend to return their cost inside a year.
Attribute normalisation against the way buyers actually search. The catalogue almost certainly has the data. It is in PDFs, in product names, in the descriptions written by the supplier. Pulling that data into structured attributes is unglamorous and it is the single highest-return data task most teams can run.
Relationship modelling for fits-with, replaces and accessory. This is the data that turns a question about a part into a useful answer about the whole job. Sales engineers carry it in their heads. Capture it in the PIM and the AI layer can begin to be useful.
A real-time bridge to stock and contract price. Without this, every answer the model gives is a marketing answer rather than a procurement answer. With it, the model can do work the trade desk used to do.
A pragmatic order of operations
Pick the category that drives the most search traffic and the most trade-desk calls. Fix the attributes and the relationships for that category only. Wire the operational data behind it. Put a small AI surface in front of it. Measure whether the trade desk gets fewer calls.
If the answer is yes, the data work is the project and the model is the supporting actor. If the answer is no, the data work was not deep enough, and switching models will not save it.
