PIM AI requirements: governance, review, audit, cost and accuracy

Which AI requirements belong in a PIM RFP?

AI requirements in a PIM RFP should cover governance, review, audit, accuracy and cost. Features alone say little, because most PIM vendors now offer some form of generation, extraction or translation. This page belongs to the PIM requirements guide, and the requirements it cites are part of the published checklist.

Eight of these requirements sit in the process domain, because the controls around AI matter more than the model behind it. The context for each is on process and governance requirements. The three platform requirements cover pricing and data location.

Where does AI in a PIM work, and where is it unreliable?

AI in PIM is useful and scalable for routine enrichment, and unreliable for regulatory data, cross-attribute consistency and end-to-end agentic workflows. Requirements should reflect that split instead of treating AI as one capability.

The table sets the default. Your own proof of concept may move a use case up or down. The wider AI landscape in PIM is covered in the AI in PIM pillar.

How do we keep AI in a PIM under governance?

Keep AI under governance by treating every AI value as a proposal that a named role accepts before it becomes master data. Governance requirements decide whether AI saves time or creates a new error source.

PR-048 is the core requirement. AI output lands in a review queue, and a named role accepts, edits or rejects it. Bulk acceptance is fine for low-risk attributes, provided the acceptance is recorded per value.

PR-050 lets administrators exclude attributes from AI generation entirely. Safety warnings, regulatory values and legal statements belong on that list. In PIMvendors selections, the exclusion list is agreed with the compliance owner before the demo.

Governance also covers permissions. AI jobs should run under the permissions of the user who starts them. A user without edit rights on an attribute group should not be able to fill it through AI. Ask the vendor to show this with a restricted user, in the same way field-level permissions are tested under PR-014.

What audit trail do AI-generated values need?

Every AI-generated value needs a provenance record that shows how it was produced and who accepted it. Without provenance, an AI error cannot be traced or corrected across the catalogue.

PR-049 asks for the model, the prompt or template version, the source inputs, the timestamp and the accepting user per value. When a prompt template is changed, that record shows which values came from the old version. When a model provider changes, it shows which values to review.

PR-053 adds the source location for extracted values. A reviewer checking an extracted voltage needs to see the page and position in the supplier datasheet. Without it, review turns into a second manual extraction.

Regulation adds a time dimension. The EU AI Act entered into force on 1 August 2024, and its Article 50 transparency obligations apply from 2 August 2026. Whether specific obligations apply to your product content depends on the use case. Provenance per value is the record you will need to answer that question.

How do we measure AI accuracy on our own data?

Measure AI accuracy by running the vendor's AI on your own products and recording how often editors accept, edit or reject each value. Vendor claims measured on demo data predict little about your catalogue.

A practical protocol has four steps.

1. Select 50 or more of your products across two or three families, with supplier documents where extraction is in scope.
2. Run the AI for the use cases you plan to use: extraction, translation, classification or descriptions.
3. Let your editors review every value and record accepted, edited or rejected per attribute.
4. Compare the rates per attribute, and set thresholds for which attributes go to production use.

PR-051 asks the PIM to report these rates itself, per attribute and per family, so the measurement continues after go-live. Accuracy varies by attribute: a colour may reach high acceptance while a technical dimension does not. The guide to evaluating AI claims gives a full test plan for the evaluation stage.

How do we control AI cost and data use?

Control AI cost with visible unit prices, cost estimates per job and a buyer-controlled cap. Control data use with contract terms on training and processing location.

PL-042 asks the pricing model to name every cost metric, including AI credits or tokens. PL-047 asks for a stated price per unit and a monthly cap that the buyer controls. PR-052 shows the expected cost of each job before it runs and reports monthly use. Together they prevent a successful pilot from becoming a budget problem once all editors use the feature.

Data use needs two contract terms. PR-055 excludes your product data from training shared third-party models unless you opt in. PL-015 keeps AI processing in the agreed region, or lists the exceptions in the contract. Unreleased products and supplier data are commercially sensitive, and AI features often call external model providers.

Compliance data itself has its own requirement set. Requirements for regulatory product data explains which attributes and evidence need human control regardless of AI quality.