06.05.2026: Nicht der Architekten-Blick von oben, sondern die Sicht von unten: Welche Commerce-Entscheidungen hängen konkret an der Qualität der Produktdaten - und was heißt das für die Schicht zwischen PIM und KI-Agent? Die produktdaten-zentrierte Ergänzung zu unseren bestehenden StoriesDecision-Ready Data LayerundArchitektur für Enterprise-Entscheidungen.
Das typische Problem
Die IT hat eine KI-Initiative gestartet. Der Chatbot auf der Website funktioniert „irgendwie", aber die Antworten stimmen nicht immer. Die Recommendation-Engine empfiehlt gelegentlich Produkte, die gar nicht mehr im Sortiment sind. Der Einkaufs-Agent eines Großkunden findet unsere Produkte über die strukturierte API nicht, obwohl sie dort hinterlegt sind. Alles deutet darauf hin, dass die Daten das Problem sind - aber niemand kann genau sagen, welche Daten fehlen oder wo.
Vier konkrete Commerce-Entscheidungsmuster
Die Anforderung „der Agent soll gute Commerce-Entscheidungen treffen" ist zu abstrakt, um konkrete Datenarbeit abzuleiten. Sobald wir vier konkrete Entscheidungsmuster ansehen, wird klar, welche Datenqualität wo fehlt.
MUSTER 1 - DYNAMISCHE PREISE
Der Agent entscheidet, zu welchem Preis ein Produkt einem bestimmten Kunden in einem bestimmten Moment angezeigt wird. Inputs: Listen- oder Rahmenpreis (aus ERP), Rabattmatrix pro Kundengruppe (ERP oder Pricing-Engine), Lagerbestand und Liefersituation (ERP / WMS), Attribute wie Materialien, Hersteller, Qualitätsstufe (PIM), und Kontextfaktoren wie Saisonalität oder Wechselkurse (Analytics).
Was der Agent produktdaten-seitig braucht: eindeutige Produktidentität, korrekte und aktuelle Attributwerte, konsistente Einheiten, Zuordnung zu Preis-Kategorien. Wenn ein Produkt im PIM unter zwei unterschiedlichen SKUs existiert (weil aus Übernahmen zwei Stämme zusammengelegt wurden) oder wenn die Qualitätsstufe freitextlich statt strukturiert gepflegt ist, kann der Agent keine konsistente Preisentscheidung treffen.
MUSTER 2 - SEMANTISCHE SUCHE UND EMPFEHLUNG
Der Agent findet ein Produkt, das zum Suchbegriff passt - nicht nur dem wörtlichen Match, sondern der Bedeutung. Ein Installateur sucht „staubdichte Außensteckdose" - der Agent soll IP65- oder höher-klassifizierte Outdoor-Steckdosen vorschlagen, unabhängig davon, ob im Produkttext „staubdicht" oder „IP65" steht.
Was der Agent produktdaten-seitig braucht: klassifizierte Merkmale (aus ETIM oder eCl@ss - siehe Deep Dive 03 zu Klassifikationen), normierte Wertbereiche, Ontologien für Synonyme, und Vektor-Embeddings, die Ähnlichkeit zwischen Produkten messbar machen. Die semantische Suche funktioniert nur, wenn Produktdaten über klassifizierte Klassen und Merkmale verbunden sind - nicht nur über Volltext.
MUSTER 3 - BUNDLE- UND ERSATZTEIL-VORSCHLÄGE
Der Agent schlägt bei einem Produkt passende Ergänzungen vor: zum ausgewählten Server die kompatiblen RAM-Module, zur gekauften Leuchte das passende Vorschaltgerät, zum Ersatzteil die verträglichen Modell-Generationen.
Was der Agent produktdaten-seitig braucht: strukturierte Produkt-Relationen, nicht nur Freitext-Hinweise „siehe auch". Diese Relationen müssen typisiert sein (Zubehör vs. Alternative vs. Ersatzteil vs. Bundle-Partner) und bidirektional gepflegt. In der Praxis lebt das in vielen Unternehmen heute als Excel-Liste im Hilfe-Ordner oder als implizite Information im Kopf einiger weniger Produktmanager. Für einen Agent ist das unbrauchbar – er muss die Relationen aus strukturierten PIM-Daten ziehen können.
MUSTER 4 - COMPLIANCE-FILTER BEIM KAUF
Der Agent verhindert Käufe, die aus regulatorischen Gründen nicht zulässig sind. Ein Produkt mit Exportbeschränkung darf nicht an Empfänger in bestimmten Ländern verkauft werden. Ein Gefahrstoff darf nur an Kunden mit entsprechender Berechtigung gehen. Sobald die ersten ESPR-Produktkategorien greifen, muss bei diesen Produkten geprüft werden, ob die DPP-Daten vollständig vorliegen, bevor der Verkauf zustande kommt.
Was der Agent produktdaten-seitig braucht: regulatorische Attribute als Pflicht-Felder, nicht als optionale Marketing-Hinweise. Kennzeichnungen für Exportbeschränkung, Gefahrstoffklassen, DPP-Compliance-Status als strukturiertes Datum. Der Compliance-Filter ist der deutlichste Fall, wo unstrukturierte Freitext-Daten den Agenten versagen lassen: Ein Agent kann „enthält Stoff XY, nicht in Land Z verkaufen" aus Marketing-Beschreibungen nicht zuverlässig extrahieren.
WAS DAS FÜR DIE DATENARCHITEKTUR BEDEUTET
Die vier Muster haben eine Gemeinsamkeit: Sie lassen sich nicht direkt auf ein klassisches PIM aufsetzen, so wie es für Shops gebaut ist. Shops fragen Produktdaten in einem menschlichen Takt ab - Agent-Workloads sind tausendfach schneller, mit anderer Lastkurve, mit anderer Erwartung an Antwortzeiten und Strukturierung.
Daraus ergibt sich eine zusätzliche Schicht zwischen PIM und Agent - der Decision-Ready Data Layer. Er leistet drei Dinge: Erstens stellt er eine semantische Sicht bereit - Ontologien, Klassifikations-Hierarchien, normierte Merkmalsbeziehungen, Vektor-Repräsentationen. Zweitens liefert er Echtzeit-APIs mit Agent-tauglicher Latenz über GraphQL- und REST-Endpunkte, zum Beispiel auf Basis von Pimcore DataHub als Fundament. Drittens implementiert er Governance - welcher Agent darf welche Daten sehen, welche Abfragen sind erlaubt, was wird protokolliert.
Der Layer entsteht nicht als eigenes Produkt. Er ist eine Architekturschicht, die auf Pimcore (oder einem vergleichbaren PIM-Fundament) aufsetzt und projektbezogen erweitert wird.
EIN KONKRETER WALKTHROUGH
Wie das in der Praxis abläuft - am Beispiel eines KI-Einkaufs-Agenten, der für einen Großkunden ein passendes Vorschaltgerät zu einer LED-Einbauleuchte sucht:
-
Anfrage. Der Agent stellt eine GraphQL-Anfrage an den Data Layer mit dem Produkt-Identifier (SKU der LED-Einbauleuchte), dem Kunden-Kontext (Vertragsklasse, Region, Berechtigungs-Token) und der gewünschten Antwort-Form (Top-N Kompatibilitäts-Treffer mit Preis und Verfügbarkeit).
-
Anreicherung im Layer. Der Data Layer prüft die Agent-Identität, greift auf das semantische Modell zu, zieht die typisierten Produkt-Relationen aus dem PIM (Bundle-Partner, Zubehör, Alternative), reichert sie über die Ontologie mit Synonymen und Merkmals-Hierarchien an, holt Lagerbestand aus dem ERP in Echtzeit und wendet die kunden-spezifische Preis-Kurve an.
-
Antwort. Der Agent erhält in einem Aufruf das gefilterte Ergebnis: drei kompatible Vorschaltgeräte mit aktueller Verfügbarkeit, kunden-spezifischem Preis, einer kurzen Kompatibilitäts-Begründung und einer Konfidenz-Bewertung pro Treffer. Die ganze Anfrage - inklusive der Berechtigungs-Prüfung und der konkreten Datenpunkte - wird im Audit-Trail protokolliert.
Was den Walkthrough trägt: das PIM ist Single Source of Truth für die Stammdaten, der Layer ergänzt um Semantik und Echtzeit-Joins, der Agent muss keine Geschäftslogik selbst implementieren.
WAS WIR KONKRET LIEFERN
Unser Beitrag zu dieser Schicht fällt in vier Teile: das semantische Datenmodell (Ontologie, Synonyme, Hierarchien - aufgebaut auf bestehenden Klassifikationen wie ETIM oder eCl@ss und unternehmensspezifischen Begriffen), die Vektor-Repräsentationen (Embeddings pro Produkt, gespeichert in einer Vektor-Datenbank als Ergänzung zum relationalen PIM-Kern), die API-Schicht (GraphQL über Pimcore DataHub plus Caching, Rate Limits pro Agent-Identität, Batch-Abrufe), und die Governance-Implementierung (Token-Authentifizierung, Berechtigungsmatrix, Audit-Trail).
Ein wichtiger Punkt: Diese Schicht ist kein Standard-Feature einer PIM-Plattform. Pimcore liefert das strukturelle Fundament (Datenmodell, Classification Store, DataHub). Die semantische Anreicherung und Vektor-Anbindung bauen wir projektbezogen obendrauf. Ein „KI-Ready PIM out of the box" gibt es nicht – diese Schicht entsteht im Projekt.
ARCHITEKTUR-FRAGEN, DIE DAS PROJEKT KLÄREN MUSS
An vier Stellen entstehen Entscheidungen, die nicht aus der Standard-PIM-Installation fallen. Sie haben keine pauschale Antwort, sollten aber früh benannt sein. Welche Konstellation die richtige ist, klären wir pro Projekt nach Volumen, Sensibilitäts-Profil und Operations-Bereitschaft.
Wo liegen die Vektor-Repräsentationen? Eine Erweiterung der bestehenden Pimcore-Datenbank (MySQL bzw. MariaDB) oder ein dediziertes Vektor-System? Die Wahl hängt davon ab, wie viele Produkte indexiert werden, welche Latenz die Agent-Workloads brauchen und ob das Team ein zusätzliches System operativ tragen will.
Welches Embedding-Modell? Closed-Source-APIs liefern Qualität bei einfacher Anbindung, lassen aber Daten in Drittsysteme fließen. Selbst gehostete Open-Source-Modelle bewahren Datenhoheit, brauchen aber Operations-Kompetenz und passende Hardware. In DACH-B2B-Projekten sehen wir häufig eine hybride Konstellation - die genaue Aufteilung klären wir pro Sensibilitäts-Profil.
Sync oder async? Ein Agent, der einem Chat-Stream antwortet, braucht andere Antwortzeiten als ein Marktplatz-Crawler, der nächtlich indexiert. Die API-Schicht muss beide Profile bedienen - nicht über ein Einheits-Interface, sondern über getrennte Endpunkte mit unterschiedlichen Cache-Strategien.
Wann werden Embeddings erneuert? Vollständiges tägliches Re-Embedding ist teuer, ereignisbasiertes Re-Embedding macht die Konsistenz schwerer zu garantieren. Pragmatisch: Triggern auf Änderung der relevanten Felder (Beschreibung, Klassifikation, Hauptmerkmale), dazu ein periodischer Konsistenz-Audit.
ANTI-PATTERNS, DIE DATA-LAYER-INITIATIVEN SCHEITERN LASSEN
Sechs Muster, die wir in Projekten regelmäßig sehen - und die sich vermeiden lassen, wenn sie früh benannt sind:
-
Data Layer auf nächtlichem ETL aufsetzen. Klingt einfach, liefert aber Architektur-konforme Entscheidungen auf veralteter Basis. Echtzeit ist kein Nice-to-have - sie ist die Definitionsgrenze.
-
Vektor-Storage ohne Re-Embedding-Strategie. Embeddings veralten unbemerkt, wenn niemand definiert hat, wann sie erneuert werden. Agenten suchen dann gegen Repräsentationen, die mit der Realität nichts mehr zu tun haben.
-
KI-Initiative isoliert von den Stammdaten starten. Der Layer macht Datenprobleme maschinenlesbar, löst sie aber nicht. Ohne saubere Stammdaten-Basis liefert er konsistent falsche Antworten.
-
Governance erst nach Go-live nachziehen. Ohne Token-basierte Authentifizierung und Audit-Trail von Anfang an hat man keine belastbare Antwort, wenn Daten an unautorisierte Konsumenten leaken oder ein Agent halluziniert.
-
Vollständige Ontologie aufbauen, bevor erste Use-Cases laufen. Sechs Monate Vorbereitung ohne produktiven Nutzen. Stattdessen: Ontologie inkrementell mit den Use-Cases wachsen lassen.
-
Den Layer für eine einzige KI-Initiative bauen. Unterinvestition in die Infrastruktur, die das nächste Projekt überfordert. Layer ist Infrastruktur, kein Feature.
ABGRENZUNG - WAS EIN DATA LAYER NICHT IST
Der Begriff „Decision-Ready Data Layer" wird aktuell von vielen Anbietern besetzt. Nicht alles, was so heißt, ist auch eines. Drei Abgrenzungen.
Ein Data Layer ist kein weiteres Data-Warehouse. Warehouses sind für Analytik gebaut - Batch-Verarbeitung, retrospektive Auswertung, lange Antwortzeiten sind dort zulässig. Ein Data Layer für Agenten braucht Echtzeit, niedrige Latenz und lebende Konsistenz mit den operativen Systemen. Wer den Data Layer auf einem nächtlichen ETL-Prozess aufsetzt, bekommt Architektur-konforme Entscheidungen auf veralteter Datenbasis.
Ein Data Layer ist auch kein ausschließliches KI-Projekt. Die gleiche Schicht bedient Shops mit personalisierten Empfehlungen, Marktplatz-Crawler mit maschinenlesbaren Feeds, interne Tools mit semantischer Suche. Der KI-Agent ist nur einer von mehreren Konsumenten - mit besonders anspruchsvollem Lastprofil. Wer den Data Layer isoliert für eine einzelne KI-Initiative baut, unterinvestiert in die Infrastruktur und überfordert das nächste Projekt.
Und schließlich: Ein Data Layer ist kein Ersatz für gutes Stammdaten-Management. Er lebt obendrauf. Wenn die Produktdaten im PIM inkonsistent, unvollständig oder widersprüchlich sind, macht der Data Layer diese Probleme maschinenlesbar - aber er löst sie nicht. Die Reihenfolge bleibt: zuerst die acht Bereiche der Produktdaten-Zentralisierung - dazu auch Deep Dive 01 zur PIM-Migration in 90 Tagen - und dann der Data Layer obendrauf.
WAS NACH DEM ERSTEN LAYER-AUFBAU KOMMT
Der Data Layer ist kein einmaliger Bau - er entwickelt sich mit den Use-Cases weiter. Drei Pfade, die in der Regel als Folge-Schritte greifen:
-
Mehr Konsumenten anschließen. Was zunächst für einen Pricing-Agent oder eine semantische Suche gebaut wurde, bedient bald auch andere Konsumenten – Marktplatz-Crawler mit maschinenlesbaren Feeds, interne Analytics-Tools, Recommendation-Engines, Compliance-Checker. Jeder zusätzliche Konsument validiert das Modell und liefert Anforderungen, die die Architektur weiterentwickeln.
-
Embedding- und Ontologie-Reife. Mit den ersten produktiven Workloads kommen Erkenntnisse: welche Klassen schlecht klassifiziert sind, welche Produkt-Relationen fehlen, wo das Embedding-Modell schwächelt. Wir betreuen diese kontinuierliche Optimierung – inklusive Re-Embedding bei Modell-Updates und Ontologie-Erweiterungen für neue Domänen oder Sprachen.
-
Erweiterung in Richtung Compliance und Compliance-by-Design. Sobald die ersten ESPR-Produktkategorien greifen, wird der Data Layer auch zum Compliance-Filter: er weiß, welche Produkte vollständige DPP-Daten haben und welche nicht. Das ist eine natürliche Erweiterung – das Datenmodell trägt die regulatorischen Attribute, der Layer macht sie für Agenten und Kanäle abrufbar.
-
Ergebnis: Produktdaten, die als Fundament für KI-gesteuerten Commerce funktionieren – nicht nur als Shop-Content. Die vier Entscheidungsmuster laufen zuverlässig, weil die Datenschicht sie trägt: strukturiert, semantisch angereichert, echtzeit-abrufbar, governed.
Welches der vier Entscheidungsmuster ist in Ihrem Unternehmen am dringendsten - und welche Produktdaten stehen dafür heute nicht in der richtigen Form bereit?