Digitaler Produktpass: Umsetzung, Datenarchitektur und AI-Readiness

Wer betroffen ist und warum der Zeitplan taeuscht

Die ESPR betrifft grundsaetzlich viele physische Produkte im EU-Binnenmarkt. Die konkreten Pflichten entstehen aber nicht für alle Produktgruppen gleichzeitig, sondern ueber delegierte Rechtsakte. Priorisierte Gruppen wie Textilien, Eisen und Stahl, Aluminium, Reifen, Möbel, Matratzen und mehrere energiebezogene Produkte stehen früh im Fokus. Batterien laufen ueber eine eigene, bereits sehr konkrete Regulierung: Für relevante Batterieklassen wird der Batteriepass ab dem 18. Februar 2027 verpflichtend.

Für Geschaeftsführung, COO, CIO und CDO ist wichtig: Das eigentliche Risiko liegt selten im finalen QR-Code. Es liegt in Produktdaten, die heute noch in Excel-Dateien, Lieferanten-PDFs, E-Mail-Anhaengen, ERP-Freitexten oder isolierten PIM-Attributen verteilt sind. Wenn diese Daten nicht eindeutig einem Produkt, einer Variante, Charge oder Seriennummer zugeordnet werden können, wird der DPP zum manuellen Compliance-Prozess.

Ein sinnvoller Startpunkt ist deshalb eine Betroffenheitsmatrix: Produktgruppen, EU-Marktbezug, Rolle als Hersteller, Importeur, Händler oder Marktplatz, vorhandene Identifikatoren, Datenquellen, Datenluecken, Lieferantenabhaengigkeiten und erwartete Änderungsfrequenz. Diese Matrix ist weniger spektakulär als eine Demo, aber sie spart später viel Geld.

Die Datenarchitektur: vom Produktdatensatz zum Passport-Layer

In reifen DPP-Architekturen ist der Produktpass nicht die Quelle aller Produktdaten. Er ist eine kuratierte, versionierte und zugriffsfähige Schicht ueber bestehenden Systemen. Das PIM bleibt stark für marketing- und kanalnahe Produktinformationen. Das ERP bleibt stark für kaufmaennische und logistische Stammdaten. PLM, QM, LIMS, Lieferantenportale und Dokumentenmanagement liefern technische, qualitative und regulatorische Nachweise.

Der Passport-Layer führt diese Informationen nicht beliebig zusammen, sondern nach klaren Regeln: Welche Quelle ist führend? Welche Daten sind statisch, welche ändern sich ueber den Lebenszyklus? Welche Felder dürfen öffentlich sichtbar sein? Welche sind nur für Behörden, Geschäftspartner oder Recyclingbetriebe gedacht? Welche Nachweise müssen unverändert archiviert werden?

Eine belastbare Architektur trennt deshalb fuenf Ebenen: Identitaet, Datenmodell, Quellenanbindung, Freigabe und Auslieferung. Identitaet meint Produkt-, Modell-, Varianten-, Chargen- oder Seriennummern. Datenmodell meint Pflichtfelder, optionale Felder, Nachweise, Einheiten und Semantik. Quellenanbindung meint ERP, PIM, PLM, Shopware, Lieferantendaten und Dokumente. Freigabe meint Verantwortlichkeiten, Vier-Augen-Prinzip, Audit Trail und Versionen. Auslieferung meint QR-Code, Resolver, API, Webansicht und rollenbasierte Zugriffe.

Wenn du nicht beantworten kannst, welches System für ein DPP-Feld führend ist, hast du kein Toolproblem. Du hast ein Datenverantwortungsproblem.

Wie PIM, ERP, Shopware und DPP zusammenspielen

In vielen DACH-Unternehmen wird der DPP zuerst im E-Commerce sichtbar, weil der QR-Code auf Produktseiten, Verpackungen und Datenblaettern auftaucht. Trotzdem sollte der Shop nicht zum Master-System für DPP-Daten werden. Shopware oder andere Commerce-Systeme sind gute Ausspielkanaele, aber selten die richtige Quelle für Konformitaet, Materialzusammensetzung, Reparierbarkeit oder Lieferantennachweise.

Pragmatisch ist meist ein Integrationsmuster mit drei Rollen: Das ERP liefert kaufmaennische Stammdaten und eindeutige Artikelbeziehungen. Das PIM liefert gepflegte Produktattribute, Medien und kanalrelevante Informationen. Der DPP-Service verwaltet Passversionen, Nachweise, Zugriffsrechte, Öffentlichkeit, maschinenlesbare Endpunkte und die Verknuepfung zum physischen Produkt.

Shopware kann dann gezielt nutzen, was der DPP-Service bereitstellt: Produktseiten können auf den Passport verlinken, B2B-Kunden können Dokumente automatisiert abrufen, und interne Teams müssen nicht dieselben regulatorischen Daten mehrfach pflegen. Genau hier entsteht der Unterschied zwischen Compliance-Kostenstelle und Produktdaten-Infrastruktur.

Wenn du diese Abhaengigkeiten erst sortieren willst, bevor du ein größeres Projekt startest, passt die Potenzial-Analyse besser als ein fertiges Toolversprechen. Wenn intern Know-how aufgebaut werden soll, können Workshops helfen, Produktdaten, AI-Readiness und technische Umsetzung zusammenzubringen.

AI-Readiness: warum der Produktpass auch für Maschinen geschrieben wird

Die naheliegende DPP-Frage lautet: Welche Daten verlangt die Regulierung? Die strategisch bessere Frage lautet: Welche Produktdaten müssen künftig von Maschinen korrekt verstanden werden? Denn Einkauf, Vergleich, Compliance-Prüfung, After-Sales, Reklamation, Reparatur, Ersatzteilidentifikation und Recycling werden zunehmend durch Software und KI-Assistenten vorbereitet.

AI-Readiness bedeutet hier nicht, ein Sprachmodell ueber alle Produktdaten zu legen. Es bedeutet: Produktinformationen sind eindeutig identifizierbar, versioniert, strukturiert, maschinenlesbar, mit Quellen belegbar und ueber stabile Schnittstellen erreichbar. Ein KI-Agent darf nicht raten müssen, ob ein Attribut für die ganze Produktfamilie, eine Variante, eine Charge oder ein konkretes Exemplar gilt.

Für C-Level ist das der eigentliche Hebel. Der DPP zwingt Unternehmen, Datenqualität nicht mehr als internes Hygieneproblem zu behandeln. Er macht sie markt- und compliance-relevant. Wer die Architektur sauber aufsetzt, schafft neben der Pflicht auch Grundlagen für bessere Produktberatung, automatisierte B2B-Datenbereitstellung, schnellere Audits und weniger manuelle Arbeit in Produktmanagement, Vertrieb und Service.

Governance: der Teil, der in Tool-Demos fast immer zu kurz kommt

Ein DPP-Projekt scheitert selten daran, dass niemand JSON ausliefern kann. Es scheitert daran, dass niemand verbindlich entscheidet, wer für ein Feld verantwortlich ist, wann ein Nachweis als gueltig gilt, wie Lieferantendaten geprüft werden und was passiert, wenn sich Daten nach dem Inverkehrbringen ändern.

Deshalb braucht der Digitale Produktpass ein Betriebsmodell. Dazu gehoeren Rollen für Datenverantwortung, fachliche Freigabe, technische Freigabe, Rechts- oder Compliance-Prüfung, Lieferantenkommunikation und Incident Handling. Es braucht ausserdem Regeln für Versionierung: Ein Passport muss zeigen können, was zu welchem Zeitpunkt veröffentlicht war, warum es geändert wurde und welche Produkte davon betroffen sind.

Besonders wichtig ist die Trennung zwischen aktuellen Daten und historischen Nachweisen. Marketingtexte dürfen sich ändern. Konformitaetsnachweise, Prüfberichte oder freigegebene Materialangaben brauchen andere Lebenszyklen. Wer alles gleich behandelt, baut entweder ein starres System oder eines, dem später niemand vertraut.

Ein pragmatischer Start ohne Overengineering

Der beste erste Schritt ist nicht die perfekte Zielplattform. Der beste erste Schritt ist ein ehrlicher DPP-Datenaudit für eine relevante Produktlinie. Nimm eine Produktgruppe mit absehbarer Regulierung oder hoher strategischer Bedeutung. Sammle alle heutigen Datenquellen. Markiere Pflichtdaten, wahrscheinliche Pflichtdaten und freiwillige Zusatzdaten. Prüfe für jedes Feld: Quelle, Verantwortlicher, Aktualitaet, Nachweis, Qualität, Zugriff und technische Ausspielbarkeit.

Danach sollte ein kleiner Pilot folgen: ein Produkt oder eine Produktfamilie, ein sauberer Identifikator, ein erster Passport-Datensatz, eine öffentliche Ansicht, eine maschinenlesbare Ausgabe, ein Audit Trail und ein definierter Freigabeprozess. Erst wenn dieser Durchstich funktioniert, lohnt es sich, Skalierung, Automatisierung, Lieferantenportale und tiefe Systemintegration größer zu planen.

Das klingt weniger glamourös als "DPP in 30 Tagen". Es ist aber näher an der Realität gewachsener IT-Landschaften. Und genau darum geht es: nicht ein neues Datensilo mit schoener Oberfläche bauen, sondern eine robuste Produktschicht, die bestehende Systeme respektiert und trotzdem langfristig anschlussfähig bleibt.