Trends in PIM, deel 2: AI-agents doen nu de verrijking, dus productdata heeft AI-governance nodig

Bepaal aan wie een AI-agent verantwoording aflegt voordat je er nog een aan je PIM koppelt. Bedrijven die agents op productdata laten werken, hebben AI-governance nodig: vastgelegd beleid dat zegt welke agents welke data mogen raken, wie de regels beheert die ze volgen, en wie hen kan overrulen. De PIM is de plek waar dat beleid wordt afgedwongen, en de meeste PIM's doen dat op dit moment met rechtenmodellen die voor mensen zijn gebouwd.

De MCP-gids van Bluestone bevat een prompt die zo uit de dinsdagmiddag van een willekeurige merchandiser kan komen: "Zet het attribuut Season voor deze producten op AW26." De MCP-documentatie van Akeneo gaat verder, met "Voeg mijn attribuut description toe aan al mijn families", een wijziging aan het datamodel, ingetypt als één zin in Claude Desktop of Cursor. Niemand logde in op de PIM. De PIM moet op het moment dat het verzoek binnenkomt alsnog beslissen of die wijziging mocht.

In deel 1 stelden we dat leveranciersonboarding zich losmaakt tot een eigen laag vóór de PIM, met eigen aanbieders en validatie. Bij verrijking gebeurt hetzelfde, maar dan aan de zijkant. Beschrijvingen, classificatie en vertaling lopen steeds vaker via API's en het Model Context Protocol (MCP), de open standaard waarmee een AI-client de tools van een systeem ontdekt en aanroept. Gebeurt dat, dan houden de mensen die vroeger de waarden intypten van buitenaf toezicht, en verschuift de waarde van de PIM naar de rechten en regels die hij bij elke schrijfactie afdwingt.

Agents erven rechten die voor mensen zijn bedacht

In de MCP-documentatie van PIM-leveranciers keert één patroon terug: de agent leent de identiteit van iemand anders. De MCP-server van Akeneo draait op de API-inloggegevens die in de verbinding zijn ingesteld, en de documentatie noemt het gevolg: iedereen met toegang tot de MCP-verbinding (via de AI-tool die die API-sleutel gebruikt) kan de acties uitvoeren die die API-sleutel toestaat, inclusief schrijven en bewerken als dat aanstaat. De server van Bluestone handelt met de rechten van de gebruiker die inlogt, en de documentatie is even onomwonden: een toegestane tool-aanroep heeft hetzelfde operationele effect als wanneer de gebruiker die actie zelf uitvoert. Pimcore 2026.3 maakt van het platform een OAuth 2.0-server die op de bestaande gebruikersaccounts draait, zodat externe agents zich authenticeren als Pimcore-gebruikers.

Eén rechtenmodel hergebruiken is logisch. Het probleem is wiens rechten worden hergebruikt. De persoon die Claude op een vrijdagmiddag aan de PIM koppelt, is meestal een ervaren beheerder of een admin, en de agent heeft daarna de volledige rechten van die persoon, in een tempo waarin geen beheerder ooit werkte. Akeneo en Bluestone raden allebei een aparte gebruiker met minimale rechten voor agents aan. Niets in de inrichting dwingt dat af.

AI-governance is een beleidslaag, en de PIM dwingt die af

Governance voor verrijkingsagents begint met beslissingen die iemand opschrijft vóór de ingebruikname. inriver baseert zich op PwC, het World Economic Forum en KPMG en beschrijft het onboarden van een agent als het aannemen van een nieuwe medewerker, met een eigen identiteit, een duidelijk afgebakende reikwijdte en taakgebonden rechten: "Een agent die productbeschrijvingen verrijkt, heeft toegang nodig tot contentvelden, niet tot prijsgoedkeuringen of kanaalgegevens."

Bij het afbakenen van rechten doet de PIM het echte werk. De rechten van Akeneo Enterprise Edition, die de REST-API voor de API-gebruiker afdwingt, kunnen hele categorieën, attribuutgroepen of talen voor een verbinding verbergen. Ze ondersteunen ook een modus die voor agents meer uitmaakt dan welke AI-functie ook: mag een verbinding producten in een categorie bewerken maar is ze er niet verantwoordelijk voor, dan worden haar wijzigingen concepten die de verantwoordelijken van de categorie goedkeuren of afwijzen. Dat zijn voorstelrechten zonder schrijfrecht, en precies zo hoort een nieuwe verrijkingsagent te starten. Een agent die Duitse marketingtekst voor één merk schrijft, heeft niets te zoeken bij Franse gevarenaanduidingen van een ander merk.

Rechten verschillen ook per soort data. De richtlijn van inriver over autonomie stelt dat veiligheidswaarschuwingen, conformiteitsmarkeringen en certificeringsclaims op elk kanaal altijd door een mens worden goedgekeurd, terwijl verrijking van long-tail-attributen kan draaien met automatische validatie en beoordeling van uitzonderingen. Dat werkt alleen als elke attribuutgroep een benoemde verantwoordelijke heeft. Het antwoord van inriver: de business is verantwoordelijk voor de agent, IT is verantwoordelijk voor identiteit, toegang en logging, en een verrijkingsagent valt onder degene die vóór zijn bestaan al voor de contentkwaliteit instond.

Dan de vraag wie mag ingrijpen. inriver citeert IBM-onderzoek waaruit blijkt dat 35% van de leidinggevenden niet kan zeggen wie de bevoegdheid heeft om een AI-aanbeveling te betwisten of terzijde te schuiven. In een productteam is die leemte concreet: een agent overschrijft een waarde, een categoriemanager is het er niet mee eens, en niemand weet wiens regel wint. Het beleid moet die persoon per attribuutgroep benoemen, en de workflow van de PIM moet het conflict naar die persoon sturen. AgentWorkx van Stibo, gelanceerd in september, laat agents draaien binnen de rollen, rechten en controles van STEP, en de hoogste productverantwoordelijke van Stibo formuleerde het doel als innoveren "binnen de gecontroleerde omgeving van MDM, in plaats van de volgende generatie schaduw-AI te maken." De Agent Bundle van Pimcore, nog in bèta, loopt inmiddels via de Workflow Engine, zodat agentwerk dezelfde goedkeuringen doorloopt als menselijk werk.

Terugdraaien is de zwakste schakel. Bluestone waarschuwt dat de wijzigingshistorie niet als een gegarandeerde ongedaanmaakfunctie moet worden gezien, en zegt teams een herstelbare kopie van de huidige waarden te bewaren vóór wijzigingen die moeilijk terug te draaien zijn. Het recente blogartikel van Akeneo over agentplatformen legt uit waarom dit erger wordt naarmate je opschaalt: zodra meerdere agents dezelfde producten bewerken, moet je de brondata, de aanbeveling van de agent, de toegepaste regel, de beoordelaar en de uiteindelijke wijziging kunnen volgen.

Wat dit betekent als je koopt

Behandel AI-governance als een eis in je PIM-selectie, met hetzelfde gewicht als het datamodel. Hoe die eis naast eigenaarschap, attribuutregels en beoordeling staat, lees je in productdatakwaliteit en governance, en welke leveranciers agentrechten, reviewstappen en MCP-servers documenteren, vergelijken we in PIM-systemen met de beste AI-functies in 2026. Drie praktische controles:

1. Geef elke agent een eigen identiteit en een eigenaar. Vraag of de PIM elke agent eigen toegangsgegevens kan geven, los van de persoon die hem koppelde, en of er een benoemde zakelijke eigenaar aan hangt. Een agent op een gedeelde API-sleutel laat geen spoor na van welke agent wat deed.
2. Beperk rechten tot de data, tot op attribuutgroep, locale en catalogus. Vraag om een agent te zien die beperkt is tot één categorieboom en één taal, met alleen voorstelrechten op gereguleerde attributen. Vraag daarna of de regels en goedkeuringsworkflows die in de interface gelden ook gelden bij een schrijfactie via MCP.
3. Maak elke schrijfactie van een agent herleidbaar en terug te draaien. Vraag hoe je een bulkwijziging van een agent op 5.000 records terugdraait, wat het auditlog over de agent vastlegt, en hoe snel je één agent kunt uitzetten zonder de workflow te stoppen waarin hij zit.

De keerzijde is snelheid. Alleen voorstelrechten en goedkeuring per attribuut bouwen de beoordelingswachtrij weer op, en inriver waarschuwt zelf dat goedkeurders die elke beslissing moeten aftekenen, snel gaan werken in plaats van zorgvuldig. Governance die alleen nee zegt, duwt teams terug naar het kopiëren van output uit een chatvenster, en dat is erger dan helemaal geen agent. Agents die in de PIM zelf zijn gebouwd, zoals AgentWorkx, houden identiteit, workflow en audit op één plek en binden je aan de agent-roadmap van die leverancier. Externe agents via MCP laten je het model kiezen, en laten het bouwen van de governance aan jou over. Duur wordt het als elk team zijn favoriete assistent met een admin-token aan de PIM hangt en dat een AI-strategie noemt.

Deel 3 volgt de data op het punt waar ze de PIM aan de andere kant verlaat. Publicatie schuift naar iPaaS, middleware en feedtools, zodat een marktplaats toevoegen of een kanaalformaat wijzigen geen PIM-project meer vraagt. De rechten en regels die bij het record horen, moeten nu met het record mee, naar systemen die de PIM niet beheert.