Trends in PIM, Part 2: AI agents now do the enrichment, so product data needs AI governance

Before you connect another AI agent to your PIM, decide who it answers to. Companies running agents on product data need AI governance: a written policy that says which agents may touch which data, who owns the rules they follow, and who can overrule them. The PIM is where that policy gets enforced, and most PIMs today enforce it with permission models built for people.

Bluestone's MCP guide includes a prompt that could come from any merchandiser's Tuesday afternoon: "Set the Season attribute to AW26 for these products." Akeneo's MCP documentation goes further with "Add my 'description' attribute to all my families", a change to the data model typed as one sentence into Claude Desktop or Cursor. Nobody logged into the PIM. The PIM still has to decide whether that edit was allowed, the moment the request arrives.

In Part 1 we argued that supplier onboarding is peeling off into its own layer in front of the PIM, with its own vendors and validation. Enrichment is peeling off from the side. Descriptions, classification and translation increasingly run through APIs and the Model Context Protocol (MCP), the open standard that lets an AI client discover a system's tools and call them. Once that happens, the people who used to type the values supervise from outside, and the PIM's value moves to the rights and rules it enforces on every write.

Agents inherit rights that were designed for people

The MCP documentation from PIM vendors repeats one pattern: the agent borrows someone else's identity. Akeneo's MCP server runs on the API credentials configured in the connection, and its docs spell out the consequence: "Anyone with access to the MCP connection (via the AI tool using that API key) can perform actions allowed by that API key, including write/edit if enabled." Bluestone's server acts with the permissions of the user who signs in, and its documentation is equally blunt that "a permitted tool call has the same operational effect as the user performing that action." Pimcore 2026.3 turns the platform into an OAuth 2.0 server built on its existing user accounts, so external agents authenticate as Pimcore users.

Reusing one permission model is sensible. The problem is whose permissions get reused. The person who connects Claude to the PIM on a Friday afternoon is usually a senior steward or an admin, and the agent then carries that person's full rights at a pace no steward ever worked. Akeneo and Bluestone both recommend a dedicated, least-privilege user for agents. Nothing in the setup forces it.

AI governance is a policy layer, and the PIM enforces it

Governance for enrichment agents starts with decisions someone writes down before deployment. Inriver, drawing on PwC, the World Economic Forum and KPMG, describes onboarding an agent like a new hire, with a unique identity, explicit scope and task-specific rights: "An agent enriching product descriptions needs access to content fields, not to pricing approvals or channel credentials."

Scope is where the PIM does the real work. Akeneo's Enterprise Edition permissions, which its REST API enforces for the API user, can hide whole categories, attribute groups or locales from a connection. They also support a mode that matters more for agents than any AI feature: when a connection may edit products in a category but does not own it, its updates become drafts that the category owners approve or reject. That is propose-only access, and it is exactly how a new enrichment agent should start. An agent writing German marketing copy for one brand has no business touching French hazard statements in another.

Rights also vary by the kind of data. Inriver's guidance on autonomy argues that safety warnings, compliance markings and certification claims stay at human-approved level on every channel, while long-tail attribute enrichment can run with automated validation and exception review. That only works if each attribute group has a named owner. Inriver's answer: the business owns the agent, IT owns the identity, access and logging, and an enrichment agent belongs to whoever answered for content quality before it existed.

Then comes override. Inriver cites IBM research that 35% of executives cannot say who holds authority to challenge or override an AI recommendation. In a product team that gap is concrete: an agent overwrites a value, a category manager disagrees, and nobody knows whose rule wins. The policy has to name that person per attribute group, and the PIM's workflow has to route the conflict to them. Stibo's AgentWorkx, launched in September, runs agents inside STEP's roles, permissions and controls, and Stibo's product chief framed the goal as innovating "within the governed environment of MDM, rather than creating the next generation of shadow AI." Pimcore's beta Agent Bundle now runs through its Workflow Engine, so agent work passes the same approvals as human work.

Reversibility is the weakest link. Bluestone warns that change history "should not be treated as a guaranteed undo function" and tells teams to keep a recoverable record of current values before changes that are hard to reverse. Akeneo's recent post on agent platforms adds the reason this gets worse with scale: once several agents act on the same products, you need to trace the source data, the agent's recommendation, the rule applied, the reviewer and the final change.

What this means when you buy

Treat AI governance as a requirement in your PIM selection, with the same weight as the data model. Three practical checks:

1. Give every agent its own identity and owner. Ask whether the PIM can issue each agent a separate credential, distinct from the person who connected it, and record a named business owner against it. An agent running on a shared API key leaves no trail of which agent did what.
2. Scope rights to the data, down to attribute group, locale and catalog. Ask to see an agent restricted to one category tree and one locale, with propose-only rights on regulated attributes. Then ask whether the rules and approval workflows that apply in the UI also fire on an MCP write.
3. Make every agent write traceable and reversible. Ask how you reverse a bulk agent change on 5,000 records, what the audit log records about the agent, and how fast you can switch one agent off without stopping the workflow it sits in.

The trade-off is speed. Propose-only rights and per-attribute approvals rebuild a review queue, and Inriver itself warns that requiring approval for every decision makes approvers move quickly instead of carefully. Governance that only says no will push teams back to copying output from a chat window, which is worse than no agent at all. Agents built inside the PIM, such as AgentWorkx, keep identity, workflow and audit in one place and tie you to that vendor's agent roadmap. External agents over MCP let you choose the model, and they leave you to build the governance on top. The expensive outcome is letting each team plug its favourite assistant into the PIM with an admin token and calling that an AI strategy.

Part 3 follows the data out the other side of the PIM. Publishing is moving to iPaaS, middleware and feed tools, so adding a marketplace or changing a channel format stops needing a PIM project. The rights and rules that govern the record now have to travel with it, into systems the PIM does not control.