DPP Series | Part 2: DPP Deep Dive: Wie Unternehmen ihn nutzen, die Nutzung planen und ihn integrieren

Der Digital Product Passport (DPP) wird häufig als Anforderung an Produktinformationen vorgestellt. Für Unternehmen, die sich darauf vorbereiten, regulierte Produkte in der Europäischen Union zu verkaufen, ist diese Beschreibung unvollständig. Ein tragfähiges DPP-Programm muss gesteuerte Produktdaten mit Produktkennungen, verantwortlichen Organisationen, Zugriffskontrollen, überprüfbaren Einreichungen und den Systemen verbinden, die den Datensatz langfristig pflegen.

Dieser zweite Artikel der eSign.AI DPP-Reihe geht von der regulatorischen Sensibilisierung zum Betriebsdesign über. Er erklärt, wo Unternehmen einen DPP einsetzen können, wie sie entscheiden, welche Teams und Systeme welche Verpflichtung verantworten sollten, und wo elektronische Signaturen, elektronische Siegel und die Aufbewahrung von Nachweisen einen vertrauenswürdigen Prozess unterstützen können.

Mit dem Geschäftsereignis beginnen, nicht mit dem QR-Code

Ein QR-Code oder ein anderer Datenträger ist der sichtbare Einstiegspunkt zu einem Pass, aber er ist nicht das Betriebsmodell des Passes. Die erste Designfrage lautet, welches Geschäftsereignis den Produktdatensatz erstellt oder ändert. Je nach Produkt und anwendbarer Gesetzgebung kann dieses Ereignis das Inverkehrbringen eines Produkts auf dem EU-Markt, die Registrierung eines Wirtschaftsakteurs, die Ausstellung eines Konformitätsdokuments, die Aktualisierung von Reparaturinformationen oder die Erfassung eines Lebenszyklusereignisses sein.

Jedes Ereignis benötigt einen verantwortlichen Eigentümer. Produktteams können technische Attribute verantworten, Compliance-Teams können regulierte Erklärungen freigeben, Betriebsteams können Kennungen verwalten, und IT-Teams können Quellsysteme anbinden. Wenn niemand das Ereignis verantwortet, kann der Pass zu einer statischen Veröffentlichungsübung werden statt zu einem gepflegten Compliance-Datensatz.

Der ESPR-Arbeitsplan der Europäischen Kommission hilft Unternehmen, vorrangige Produktgruppen zu identifizieren, aber produktspezifische delegierte Rechtsakte werden die detaillierten Daten-, Zeit- und Betriebsverpflichtungen festlegen.

Die vier Ebenen der DPP-Bereitschaft abbilden

Unternehmen können ihre Vorbereitung entlang von vier verbundenen Ebenen strukturieren:

1. Produktdaten: erforderliche Attribute, Quellen, Datenverantwortliche, Aktualisierungsregeln und Qualitätskontrollen identifizieren.
2. Produktidentität: die eindeutige Produkt-, Chargen- oder Artikelkennung definieren und sie mit dem richtigen physischen Datenträger verbinden.
3. Organisation und Befugnis: festlegen, welche juristische Person Informationen einreicht, welche Personen oder Systeme für sie handeln dürfen und wie diese Rechte verifiziert werden.
4. Vertrauen und Kontinuität: Nachweise darüber aufbewahren, wer Informationen freigegeben oder eingereicht hat, Integrität schützen, Zugriff steuern und Datensätze für den erforderlichen Zeitraum verfügbar halten.

Dieses Modell verhindert einen häufigen Planungsfehler: ein Frontend-Pass-Tool zu kaufen, bevor bestätigt ist, ob das Unternehmen die zugrunde liegenden Informationen zuverlässig erzeugen, freigeben und pflegen kann.

Szenario 1: Onboarding eines Wirtschaftsakteurs

Bevor eine Organisation regulierte Daten einreichen kann, muss das relevante System möglicherweise ihre rechtliche Identität und die Befugnis der Person oder des Systems feststellen, die bzw. das für sie handelt. Der genaue Weg hängt von der maßgeblichen Gesetzgebung und dem Plattformdesign ab. Er kann ein elektronisches Identifizierungsmittel, eine elektronische Bescheinigung, dokumentarische Nachweise oder ein qualifiziertes elektronisches Siegel umfassen, das durch ein qualifiziertes Zertifikat gestützt wird.

Die wichtige Unterscheidung liegt zwischen Identität und Berechtigung. Der Nachweis, dass ein Unternehmen existiert, beweist nicht automatisch, dass ein bestimmter Mitarbeiter, ein Dienstkonto oder ein externer Vertreter Daten für dieses Unternehmen einreichen darf. Ein robuster Onboarding-Prozess erfasst sowohl die Organisationsidentität als auch die Delegation oder Rolle, die eine Handlung autorisiert.

Die Durchführungsverordnung (EU) 2026/1778 der Kommission bietet ein konkretes Beispiel für das EU-DPP-Register. Sie legt Identitäts- und Zugangsregelungen für Wirtschaftsakteure und andere Akteure fest, einschließlich hochsicherer Pfade für natürliche Personen und qualifizierter elektronischer Siegel oder elektronischer Bescheinigungen für juristische Personen. Der verifizierte Wirtschaftsakteur bleibt für die von ihm eingereichten Daten verantwortlich.

Szenario 2: DPP-Informationen freigeben und einreichen

Produktinformationen entstehen in der Regel in mehreren Systemen: Product Lifecycle Management, Enterprise Resource Planning, Manufacturing Execution, Qualitätsmanagement, Lieferantenportale und Dokumentenablagen. Ein DPP-Workflow sollte Nutzer nicht auffordern, diese Informationen manuell in einer weiteren Oberfläche neu zu erstellen, wenn bereits eine maßgebliche Quelle existiert.

Stattdessen kann das Betriebsdesign den erforderlichen Datensatz zusammenstellen, Pflichtfelder validieren, Ausnahmen an den richtigen Eigentümer weiterleiten und vor der Einreichung eine Freigabe erfassen. Wenn eine Signatur oder ein Siegel erforderlich ist, sollte der Workflow den passenden Vertrauensdienst aufrufen, ohne eine geschäftliche Freigabe mit einer rechtlich qualifizierten Signatur oder einem rechtlich qualifizierten Siegel zu verwechseln.

eSign.AI kann die Workflow-Ebene unterstützen, indem es Quellsysteme verbindet, Freigabeaufgaben weiterleitet, den erforderlichen Signatur- oder Siegelpfad anwendet und die daraus entstehenden Transaktionsnachweise erfasst. Über seinen Registration Authority-Service und die Integration mit ANF AC kann eSign.AI den QSeal-Antrags- und Ausgabepfad als Teil der Kundenlösung bereitstellen, statt den Kunden einen separaten ausländischen Anbieter koordinieren zu lassen.

Szenario 3: Überprüfbarkeit langfristig bewahren

DPP-Verpflichtungen sind nicht auf den Moment der Veröffentlichung beschränkt. Produktinformationen müssen möglicherweise über lange Produktlebenszyklen, Eigentümerwechsel und Systemmigrationen hinweg verfügbar, verständlich und vertrauenswürdig bleiben. Unternehmen sollten daher dauerhafte Nachweise einplanen, statt eine erfolgreiche API-Antwort als Ende des Prozesses zu behandeln.

Das Nachweisdesign kann den eingereichten Datensatz oder dessen kanonische Darstellung, Zeitstempel, Validierungsmaterial für Signaturen oder Siegel, Kontext zum Unterzeichner oder Betreiber, Autorisierungsdatensätze, Zustellbestätigungen, Versionshistorie und Systemprotokolle umfassen. Aufbewahrungsfristen und Validierungsmethoden müssen auf die anwendbaren Produktregeln und die Richtlinie für Aufzeichnungen abgestimmt werden.

Der EU-Rahmen verleiht qualifizierten elektronischen Siegeln eine gesetzliche Vermutung der Datenintegrität und der Richtigkeit der Herkunft, während qualifizierte Zeitstempel den Nachweis unterstützen können, dass Daten zu einem bestimmten Zeitpunkt existierten. Nur Dienste, die in einer nationalen EU-Vertrauensliste als qualifiziert aufgeführt sind, haben qualifizierten Status.

Planungshinweis: Diese Abbildung aus der Word-Quelle stellt eine Sektor- und Zeitplan-Roadmap zur Diskussion dar. Sie ist kein rechtlicher Zeitplan für jedes dargestellte Produkt. Verbindlicher Geltungsbereich, Identitätspfade, Nachweisformate, Datenanforderungen und Anwendungsdaten werden durch die relevante EU-Produktgesetzgebung, produktspezifische delegierte Rechtsakte und das endgültige Systemdesign festgelegt.

Fünf Planungsfragen für jede Produktlinie

1. Fällt das Produkt in den Geltungsbereich?

Erstellen Sie ein Produkt-zu-Regel-Register, das die relevante EU-Gesetzgebung, den aktuellen Status, den erwarteten delegierten Rechtsakt und die verantwortliche juristische Person identifiziert. Gehen Sie nicht davon aus, dass ein unternehmensweites DPP-Programm bedeutet, dass jedes Produkt demselben Zeitplan folgt.

2. Wer verantwortet jedes erforderliche Datenelement?

Weisen Sie jedem Pflichtattribut ein Quellsystem und einen geschäftlichen Eigentümer zu. Wenn ein Wert von einem Lieferanten stammt, definieren Sie Validierungs-, Eskalations- und Änderungssteuerungsregeln, statt ungeprüfte Dateien per E-Mail zu akzeptieren.

3. Wie wird das Produkt eindeutig identifiziert?

Entscheiden Sie, ob die Regel auf Modell-, Chargen- oder Artikelebene gilt. Bestätigen Sie, wie Kennungen erzeugt werden, wie Duplikate verhindert werden und wie der physische Datenträger mit dem richtigen digitalen Datensatz verbunden bleibt.

4. Wer darf freigeben und einreichen?

Dokumentieren Sie die juristische Person, die verantwortliche Rolle, das Delegationsmodell und die beteiligten Maschinenanmeldedaten. Trennen Sie interne Freigabe von externer Einreichung und von jedem gesetzlich erforderlichen qualifizierten Vertrauensdienst.

5. Welche Nachweise müssen einen Systemwechsel überstehen?

Definieren Sie das Nachweispaket vor der Implementierung. Die Antwort bestimmt Speicherarchitektur, Exportformate, Validierungsabhängigkeiten und Migrationskontrollen.

Ein Integrationsbauplan für die praktische Implementierung

Eine praktische Architektur beginnt normalerweise mit Quellsystemen statt mit einer neuen eigenständigen Datenbank. Ein Datendienst ruft freigegebene Produktattribute ab, ein Workflow-Dienst validiert Vollständigkeit und leitet Ausnahmen weiter, eine Identitäts- und Autorisierungsebene verifiziert den Akteur, und eine API-Ebene übermittelt die richtige Nutzlast an das relevante Register oder den relevanten Passdienst.

Die Nachweisebene sollte jedes wesentliche Ereignis erfassen, ohne unnötige personenbezogene Daten zu speichern. Sie sollte außerdem die Abfrage nach Produkt, Transaktion, juristischer Person und Zeitraum unterstützen, damit Compliance-Teams effizient auf Prüfungen oder Streitigkeiten reagieren können.

Die Implementierung ist in Phasen meist sicherer. Wählen Sie eine Produktfamilie aus, ordnen Sie deren Daten- und Rechtsanforderungen zu, testen Sie den vollständigen Workflow mit repräsentativen Nutzern und erweitern Sie anschließend. So entstehen wiederverwendbare Kontrollen, während produktspezifische Unterschiede sichtbar bleiben.

Zwei Signaturspuren in der eSign.AI DPP-Lösung

Die erste Spur ist die Verifizierung von Wirtschaftsakteuren. eSign.AI unterstützt QSeal-Antragstellung, Koordination der Identitätsprüfung und Abgleich von Organisationsdaten über seine Registration Authority-Fähigkeit und ANF AC-Integration. Dies ist besonders relevant für Nicht-EU-Hersteller, die ein in einer EU-Vertrauensliste geführtes qualifiziertes elektronisches Siegel für einen registry-facing Identitätsprozess benötigen.

Die zweite Spur ist der wiederkehrende Produktdaten-Workflow. eSign.AI unterstützt PAdES für PDF-Dokumente und XAdES- oder JAdES-Langzeitsignaturprofile für XML- und JSON-Datensätze, einschließlich qualifizierter Zeitstempel und Nachweisaufbewahrung. Das genaue Format und das Sicherungsniveau sollten sich nach der produktspezifischen Regel, der Registerschnittstelle und der rechtlichen Bewertung des Kunden richten; nicht jedes DPP-Ereignis verwendet dieselbe Signatur.

Für höhere Volumina können Kunden über SDK oder API anbinden, statt jeden Datensatz manuell zu signieren. Wenn der empfangende Prozess Batch-Einreichungen unterstützt, kann ein Vorgang mehrere DPP-Datensätze bündeln und zugleich Kennungen und Nachweise auf Datensatzebene bewahren. eSign.AI unterstützt außerdem SaaS-Workflows für Teams, die eine operative Oberfläche benötigen, bevor die Systemintegration abgeschlossen ist.

Wo eSign.AI passt

eSign.AI unterstützt Workflows für elektronische Signaturen und digitale Signaturen, Freigabeorchestrierung, API-Integration und Nachweisaufbewahrung. Für ein DPP-Programm können diese Fähigkeiten helfen, Geschäftssysteme mit Signatur- oder Siegelschritten zu verbinden, Betreiberereignisse zu erfassen und einen nachvollziehbaren Datensatz des Workflows aufzubewahren.

Der Bereitstellungsumfang von eSign.AI kann QSeal-Antragstellung und Ausgabesupport, Anleitung beim Register-Onboarding, PAdES/XAdES/JAdES-Signaturen, qualifizierte Zeitstempel, SaaS- und API-Integration sowie langfristige Nachweise umfassen. Die Product Data Governance bleibt in der Verantwortung des Kunden, während eSign.AI die Vertrauens- und Ausführungsebene bereitstellt, die erforderlich ist, um die richtigen Daten durch den richtigen Signaturpfad zu bewegen und Nachweise für spätere Verifizierung aufzubewahren.

Die DPP-Reihe fortsetzen

Lesen Sie Part 1: Warum chinesische Exporteure sich auf den EU Digital Product Passport vorbereiten müssen für den regulatorischen und sektoralen Kontext.

Part 2: DPP Deep Dive: Wie Unternehmen ihn nutzen, die Nutzung planen und ihn integrieren (dieser Artikel)

Weiter zu Part 3: Von eCoC zu QSeal: Wie eSign.AI die DPP-Bereitschaft unterstützt für einen genaueren Blick auf vertrauenswürdige Workflows, QSeal-Integration und die Rolle von eSign.AI.