Trends im PIM, Teil 2: KI-Agenten übernehmen die Anreicherung, Produktdaten brauchen KI-Governance

Bevor Sie einen weiteren KI-Agenten an Ihr PIM anbinden, legen Sie fest, wem er Rechenschaft schuldet. Unternehmen, die Agenten auf Produktdaten loslassen, brauchen eine KI-Governance: eine schriftliche Richtlinie, die festlegt, welche Agenten welche Daten bearbeiten dürfen, wem die Regeln gehören, denen sie folgen, und wer sie übersteuern kann. Das PIM ist der Ort, an dem diese Richtlinie durchgesetzt wird, und die meisten PIM-Systeme tun das heute mit Berechtigungsmodellen, die für Menschen gebaut wurden.

Der MCP-Leitfaden von Bluestone enthält einen Prompt, der aus dem Arbeitsalltag jedes Merchandisers stammen könnte: „Setze das Attribut Season für diese Produkte auf AW26.“ Die MCP-Dokumentation von Akeneo geht weiter, mit „Füge mein Attribut ‚description‘ allen meinen Familien hinzu“, einer Änderung am Datenmodell, eingetippt als ein einziger Satz in Claude Desktop oder Cursor. Niemand hat sich im PIM angemeldet. Das PIM muss trotzdem in dem Moment, in dem die Anfrage eintrifft, entscheiden, ob diese Änderung erlaubt war.

In Teil 1 haben wir gezeigt, dass sich das Lieferanten-Onboarding als eigene Schicht vor dem PIM ablöst, mit eigenen Anbietern und eigener Validierung. Die Anreicherung löst sich nun von der Seite. Beschreibungen, Klassifizierung und Übersetzung laufen zunehmend über APIs und das Model Context Protocol (MCP), den offenen Standard, mit dem ein KI-Client die Tools eines Systems erkennen und aufrufen kann. Sobald das passiert, überwachen die Menschen, die früher die Werte eingetippt haben, das Geschehen von außen, und der Wert des PIM verlagert sich auf die Rechte und Regeln, die es bei jedem Schreibvorgang durchsetzt.

Agenten erben Rechte, die für Menschen gedacht waren

Die MCP-Dokumentationen der PIM-Anbieter folgen einem wiederkehrenden Muster: Der Agent leiht sich die Identität eines anderen. Der MCP-Server von Akeneo läuft mit den API-Zugangsdaten, die in der Verbindung hinterlegt sind, und die Dokumentation benennt die Folge klar: Jeder mit Zugriff auf die MCP-Verbindung (über das KI-Tool, das diesen API-Schlüssel nutzt) kann alle Aktionen ausführen, die dieser API-Schlüssel erlaubt, „einschließlich Schreiben und Bearbeiten, falls aktiviert“. Der Server von Bluestone handelt mit den Berechtigungen des Nutzers, der sich anmeldet, und die Dokumentation sagt ebenso unverblümt, dass „ein erlaubter Tool-Aufruf dieselbe operative Wirkung hat, als würde der Nutzer die Aktion selbst ausführen“. Pimcore 2026.3 macht die Plattform zu einem OAuth-2.0-Server auf Basis der bestehenden Nutzerkonten, sodass sich externe Agenten als Pimcore-Nutzer authentifizieren.

Ein einziges Berechtigungsmodell weiterzuverwenden ist vernünftig. Das Problem ist, wessen Berechtigungen weiterverwendet werden. Die Person, die Claude an einem Freitagnachmittag mit dem PIM verbindet, ist meist ein erfahrener Data Steward oder ein Admin, und der Agent trägt dann die vollen Rechte dieser Person, in einem Tempo, in dem nie ein Steward gearbeitet hat. Akeneo und Bluestone empfehlen beide einen eigenen Nutzer mit minimalen Rechten für Agenten. Nichts in der Einrichtung erzwingt das.

KI-Governance ist eine Richtlinienebene, und das PIM setzt sie durch

Governance für Anreicherungsagenten beginnt mit Entscheidungen, die jemand vor dem Einsatz schriftlich festhält. Inriver beschreibt, gestützt auf PwC, das World Economic Forum und KPMG, das Onboarding eines Agenten wie das eines neuen Mitarbeiters, mit eigener Identität, klar definiertem Umfang und aufgabenbezogenen Rechten: „Ein Agent, der Produktbeschreibungen anreichert, braucht Zugriff auf Content-Felder, nicht auf Preisfreigaben oder Zugangsdaten für Kanäle.“

Beim Umfang leistet das PIM die eigentliche Arbeit. Die Berechtigungen der Enterprise Edition von Akeneo, die die REST-API für den API-Nutzer durchsetzt, können ganze Kategorien, Attributgruppen oder Sprachen vor einer Verbindung verbergen. Sie unterstützen außerdem einen Modus, der für Agenten wichtiger ist als jede KI-Funktion: Wenn eine Verbindung Produkte in einer Kategorie bearbeiten darf, diese Kategorie aber nicht besitzt, werden ihre Änderungen zu Entwürfen, die die Verantwortlichen der Kategorie freigeben oder ablehnen. Das ist ein reiner Vorschlagszugriff, und genau so sollte ein neuer Anreicherungsagent starten. Ein Agent, der deutsche Marketingtexte für eine Marke schreibt, hat an französischen Gefahrenhinweisen einer anderen Marke nichts zu suchen.

Die Rechte hängen außerdem von der Art der Daten ab. Die Empfehlungen von Inriver zur Autonomie besagen, dass Sicherheitswarnungen, Konformitätskennzeichnungen und Zertifizierungsangaben in jedem Kanal auf der Stufe menschlicher Freigabe bleiben, während die Anreicherung von Long-Tail-Attributen mit automatischer Validierung und Prüfung von Ausnahmen laufen kann. Das funktioniert nur, wenn jede Attributgruppe einen benannten Verantwortlichen hat. Die Antwort von Inriver: Der Fachbereich verantwortet den Agenten, die IT verantwortet Identität, Zugriff und Protokollierung, und ein Anreicherungsagent gehört demjenigen, der schon vor seiner Existenz für die Content-Qualität geradestand.

Dann kommt die Übersteuerung. Inriver zitiert eine Studie von IBM, nach der 35 % der Führungskräfte nicht sagen können, wer befugt ist, eine KI-Empfehlung infrage zu stellen oder zu übersteuern. In einem Produktteam ist diese Lücke sehr konkret: Ein Agent überschreibt einen Wert, ein Kategoriemanager ist anderer Meinung, und niemand weiß, wessen Regel gilt. Die Richtlinie muss diese Person für jede Attributgruppe benennen, und der Workflow des PIM muss den Konflikt an sie weiterleiten. AgentWorkx von Stibo, im September vorgestellt, lässt Agenten innerhalb der Rollen, Berechtigungen und Kontrollen von STEP laufen, und der Produktchef von Stibo beschrieb das Ziel so: Innovation „innerhalb der gesteuerten Umgebung des MDM, statt die nächste Generation von Schatten-KI zu schaffen“. Das Agent Bundle von Pimcore, noch in der Beta, läuft inzwischen über die Workflow Engine, sodass die Arbeit von Agenten dieselben Freigaben durchläuft wie die von Menschen.

Die Umkehrbarkeit ist das schwächste Glied. Bluestone warnt, dass die Änderungshistorie „nicht als garantierte Rückgängig-Funktion betrachtet werden sollte“, und rät Teams, vor schwer umkehrbaren Änderungen einen wiederherstellbaren Stand der aktuellen Werte zu sichern. Der aktuelle Beitrag von Akeneo zu Agentenplattformen nennt den Grund, warum das mit wachsender Größe schlimmer wird: Sobald mehrere Agenten an denselben Produkten arbeiten, müssen Sie die Quelldaten, die Empfehlung des Agenten, die angewandte Regel, den Prüfer und die endgültige Änderung nachverfolgen können.

Was das für Ihre Softwareauswahl bedeutet

Behandeln Sie KI-Governance bei der Auswahl Ihres PIM als Anforderung, mit demselben Gewicht wie das Datenmodell. Drei praktische Prüfpunkte:

1. Geben Sie jedem Agenten eine eigene Identität und einen Verantwortlichen. Fragen Sie, ob das PIM jedem Agenten eigene Zugangsdaten ausstellen kann, getrennt von der Person, die ihn verbunden hat, und ob es dazu einen benannten fachlichen Verantwortlichen speichert. Ein Agent, der mit einem geteilten API-Schlüssel läuft, hinterlässt keine Spur davon, welcher Agent was getan hat.
2. Beschränken Sie die Rechte auf die Daten, bis hinunter zu Attributgruppe, Sprache und Katalog. Lassen Sie sich einen Agenten zeigen, der auf einen Kategoriebaum und eine Sprache beschränkt ist und bei regulierten Attributen nur Vorschläge machen darf. Fragen Sie dann, ob die Regeln und Freigabe-Workflows, die in der Oberfläche gelten, auch bei einem Schreibvorgang über MCP greifen.
3. Machen Sie jeden Schreibvorgang eines Agenten nachvollziehbar und umkehrbar. Fragen Sie, wie Sie eine Massenänderung eines Agenten an 5.000 Datensätzen rückgängig machen, was das Audit-Log über den Agenten festhält und wie schnell Sie einen einzelnen Agenten abschalten können, ohne den Workflow anzuhalten, in dem er arbeitet.

Der Preis dafür ist Geschwindigkeit. Reine Vorschlagsrechte und Freigaben pro Attribut bauen wieder eine Prüfwarteschlange auf, und Inriver warnt selbst, dass Freigabepflichten für jede Entscheidung dazu führen, dass Prüfer schnell statt sorgfältig arbeiten. Eine Governance, die nur Nein sagt, treibt Teams zurück zum Kopieren von Ergebnissen aus einem Chatfenster, und das ist schlimmer als gar kein Agent. Agenten, die im PIM selbst gebaut sind, wie AgentWorkx, halten Identität, Workflow und Audit an einem Ort und binden Sie an die Agenten-Roadmap dieses Anbieters. Externe Agenten über MCP lassen Ihnen die Wahl des Modells, überlassen Ihnen aber den Aufbau der Governance obendrauf. Teuer wird es, wenn jedes Team seinen Lieblingsassistenten mit einem Admin-Token an das PIM anschließt und das KI-Strategie nennt.

Teil 3 folgt den Daten auf der anderen Seite aus dem PIM hinaus. Die Veröffentlichung wandert zu iPaaS, Middleware und Feed-Tools, sodass ein neuer Marktplatz oder ein geändertes Kanalformat kein PIM-Projekt mehr erfordert. Die Rechte und Regeln, die den Datensatz steuern, müssen nun mit ihm reisen, in Systeme, die das PIM nicht kontrolliert.