Agentic PIM: een realiteitscheck op AI-agents in productdata

Wat is agentic PIM precies?

Agentic PIM staat voor AI-agents die binnen een PIM taken met meerdere stappen plannen en uitvoeren. Een agent krijgt een doel mee, bijvoorbeeld de ontbrekende attributen van een productfamilie aanvullen. Daarna bepaalt de agent zelf welke records hij leest, welke tools hij aanroept en welke waarden hij schrijft.

Eerdere AI-functies in een PIM pakken telkens één taak op: haal dit attribuut uit een document, vertaal deze tekst. Een agent rijgt zulke taken aan elkaar en kiest zelf de volgorde. Daar zit de waarde van agents, en daar zit ook het risico.

In de volwassenheidstabel voor AI in PIM geeft PIMvendors volledige agent-workflows het oordeel nog niet klaar. Dat oordeel geldt voor agents die zonder goedkeuring een workflow doorlopen van input tot gepubliceerde data. Smallere agenttaken leveren vandaag al op, en de secties hieronder houden die twee gescheiden.

Leveranciers springen ruim om met het woord agent. De een noemt elke AI-functie een agent. De ander bedoelt een chatassistent die vragen over data beantwoordt. Een kleinere groep bedoelt software die zelf handelingen op records uitvoert. Vraag elke leverancier welke betekenis hij hanteert, en vraag om een lijst van alle acties die de agent kan uitvoeren.

Ook aan de commercekant gebeurt veel. Protocollen voor agents die zelf zoeken en kopen, zoals het Universal Commerce Protocol van Google, koppelen agents aan de systemen van webwinkels. De pagina over productdata voor AI-shopping behandelt die naar buiten gerichte kant.

Wat kunnen AI-agents vandaag veilig met productdata?

AI-agents kunnen veilig analyseren, sorteren en concepten opstellen zolang ze niet naar goedgekeurde records kunnen schrijven. Elke taak in de tabel bespaart specialistentijd, terwijl de beslissing bij een mens blijft.

Het patroon is steeds hetzelfde. De agent leest breed, werkt snel en schrijft uitsluitend naar een tussenomgeving. Een steward keurt de wijzigingsset als geheel goed of af.

Kies als eerste een taak met een duidelijke eigenaar en een meetbaar volume, zoals de wekelijkse triage van leveranciersbestanden. Meet tijdwinst en foutpercentage voordat je de reikwijdte verruimt. In PIMvendors-selecties bouwen teams die met agents met alleen leesrechten beginnen het bewijs op dat ze later nodig hebben om over ruimere rechten te beslissen.

Wat kunnen AI-agents nog niet veilig?

AI-agents horen zonder goedkeuring niet te schrijven naar gepubliceerde records, compliancedata, het datamodel of andere systemen. Deze acties hebben veel impact en zijn lastig terug te draaien.

• Productdata publiceren of syndiceren naar kanalen, retailers of datapools.
• Regelgevings- en compliance-attributen invullen, zoals verpakkingssamenstelling of veiligheidswaarschuwingen.
• Producten en varianten verwijderen, samenvoegen of splitsen.
• Het datamodel aanpassen: attributen, classes, validatieregels of workflows.
• Via integraties schrijven naar ERP, commerceplatform of DAM.
• Namens het bedrijf verzoeken of toezeggingen naar leveranciers sturen.

Bij elk van deze acties verspreidt een fout zich verder dan het record waarin hij ontstond. Een foute waarde in een concept kost een reviewer een minuut. Een foute waarde die naar een datapool gaat, bereikt elke retailer die de feed ontvangt. Een verkeerde samenvoeging wist historie die je alleen met veel moeite herstelt.

Bij compliancedata komt juridische aansprakelijkheid erbij. Waarden onder de PPWR, de GPSR of het Digitaal Productpaspoort moeten herleidbaar zijn naar verklaringen en testrapporten. Een agent die zulke velden invult op basis van patronen in vergelijkbare producten, produceert precies de stellige maar onjuiste waarden waar toezichthouders en klanten vragen over stellen.

Waarom gaan AI-agents de mist in met productdata?

Agents maken fouten in productdata doordat fouten zich over stappen opstapelen, input te manipuleren is en rechten vaak te ruim staan. Voor elke oorzaak bestaat een eigen controle.

De eerste oorzaak is opstapeling. Als illustratieve rekensom: een keten van tien stappen die elk in 95 procent van de gevallen kloppen, levert in ongeveer 60 procent van de gevallen een correct eindresultaat. Echte agenttaken bevatten veel opzoekacties, beslissingen en schrijfacties. Kleine foutpercentages per stap worden zo grote foutpercentages per taak.

De tweede oorzaak is gemanipuleerde input. OWASP zet prompt injection als LLM01 bovenaan de risico's voor LLM-toepassingen. Een pdf of spreadsheet van een leverancier kan tekst bevatten die een model opdraagt waarden te wijzigen of regels te negeren. Een agent die leveranciersbestanden leest en tegelijk data mag schrijven, maakt van die zwakte een daadwerkelijke actie.

De derde oorzaak is excessive agency. LLM06 van OWASP beschrijft schade door te veel functionaliteit, te veel rechten en te veel autonomie. Een agent die een beheerdersaccount krijgt om tijd te besparen op configuratie, heeft alle drie.

Daaronder ligt confabulatie. NIST AI 600-1 noemt met stelligheid gebrachte maar onjuiste inhoud als risico van generatieve AI. In een agent kan een verzonnen waarde vervolgens de volgende stap voeden alsof het een feit is.

Welke controles heeft een agentic PIM nodig?

Een agentic PIM heeft minimale rechten, gefaseerde wijzigingen, menselijke goedkeuring, auditlogs en rollback nodig voordat een agent data schrijft. De eerste drie volgen de maatregelen van OWASP tegen excessive agency. De laatste twee zijn basisvoorwaarden voor productdata.

OWASP adviseert ook om autorisatie af te dwingen in de achterliggende systemen, in plaats van te vertrouwen op het model. Voor een PIM betekent dat: de kanaalconnector controleert zelf de publicatierechten, wat de agent ook vraagt.

Neem deze controles op in je eisen voor AI-functies als harde eisen voor elke agent-functie die je wilt gebruiken.

Hoe test je agent-functies vóór de aankoop?

Test agent-functies met een scenario op je eigen data waarin een valkuil zit, en let net zo scherp op de controles als op het resultaat. De scenariomethode van PIMvendors is hier direct toepasbaar. De pagina over scenariodemo's legt het format uit.

Een goed agentscenario bestaat uit vier onderdelen:

1. Een realistisch doel, zoals de kanaalattributen van 50 producten aanvullen uit leveranciersbestanden.
2. Een conflict, zoals twee leveranciersbestanden met verschillende waarden voor hetzelfde attribuut.
3. Een manipulatie, zoals een instructie die in een leveranciersdocument verstopt zit.
4. Een grens, zoals een compliance-attribuut dat de agent ongemoeid moet laten.

Beoordeel hoe de agent met het conflict omging, of hij de verstopte instructie opvolgde en of hij de grens respecteerde. Vraag de leverancier daarna de wijzigingsset, het auditlog en een rollback te tonen.

Sommige antwoorden zijn waarschuwingssignalen. Een agent die beheerdersrechten nodig heeft, zijn log niet kan tonen of alleen op demodata van de leverancier draait, hoort in het Red Flag Register. Gebruik voor extractietaken binnen de agent de meetwaarden uit AI-attribuutextractie.