DPP-Dienstleister-Anforderungen: EU-Regeln für Plattformen

Warum die Dienstleister-Schicht wichtig ist

Viele Unternehmen denken beim Digitalen Produktpass immer noch an die sichtbare Ebene: Produktdaten, QR-Codes, Verbraucherseiten und Konformitätserklärungen.

Für die EU ist das jedoch nur ein Teil des Bildes. Es gibt auch eine Infrastrukturebene: die Systeme und Dienstleister, die DPP-Datensätze speichern, verwalten, bereitstellen, sichern und langfristig steuern.

Deshalb bereitet die Europäische Kommission einen delegierten Rechtsakt speziell für DPP-Dienstleister vor.

Für Softwareplattformen hat das direkte Bedeutung. Es deutet darauf hin, dass DPP-Anbieter mehr werden könnten als gewöhnliche SaaS-Anbieter. Sie könnten zu einem regulierten oder teilweise regulierten Teil des DPP-Ökosystems werden, von dem Portabilität, Governance, Kontinuität und zuverlässiger Datenzugang erwartet werden.

Was die Kommission regulieren möchte

Die Initiative der Kommission zu DPP-Dienstleistern erklärt, dass sie Feedback wünscht zu wie Daten von Dienstleistern gespeichert und verwaltet werden sollen und zum Bedarf eines Zertifizierungssystems.

Diese Fragestellung ist wichtig, weil sie zeigt, dass es nicht einfach um Frontend-Usability oder QR-Code-Generierung geht. Die echten Fragen sind architektonischer Natur:

• Wer kontrolliert die Daten?
• Wie werden sie gespeichert?
• Wer hat Zugriff?
• Wie bleibt die Verfügbarkeit über die Zeit erhalten?
• Brauchen Dienstleister eine formale Qualifikation oder Zertifizierung?

Der endgültige Rechtsakt ist noch nicht verabschiedet, aber die Governance-Fragen sind bereits klar umrissen.

Was bereits aus dem laufenden Prozess sichtbar ist

1. Die Dienstleisterrolle wird von der Produkteigentümerrolle getrennt

Hersteller, Importeure und andere Wirtschaftsakteure bleiben für die Produktkonformität verantwortlich. Die Dienstleisterrolle ist anders: sie betrifft die Infrastruktur, die DPP-Datensätze in der Praxis funktionieren lässt.

Diese Unterscheidung legt nahe, dass die EU klarere Grenzen wünscht zwischen:

• Compliance-Verantwortung
• Dateneigentum
• technischem Betrieb
• langfristiger Kontinuitätssicherung

2. Governance wird zur erstrangigen Anforderung

Die Initiative fragt nicht, ob Plattformen sich um Governance kümmern sollten. Sie setzt voraus, dass Governance wichtig ist, und fragt, welches Modell gelten sollte.

3. Portabilität entwickelt sich zu einer zentralen Designerwartung

Das Konsultationsprotokoll legt nahe, dass DPP-Systeme nicht auf dauerhafte Abhängigkeit von einem Anbieter ausgelegt sein sollten. Offene Strukturen, Exportfähigkeit und Anbieterwechsel-Logik werden als zentrale Plattformthemen sichtbar.

4. Backup und Kontinuität sind keine Nebensachen

Die langfristige Verfügbarkeit von DPP-Daten steht im Zentrum der Debatte. Plattformen, die nur auf aktive Produktanzeige fokussiert sind, könnten regulatorische Erwartungen verfehlen, wenn Backup-Kontinuität formalisiert wird.

Die vier Kernanforderungen, auf die Plattformen sich bereits einstellen sollten

Auch bevor der delegierte Rechtsakt endgültig ist, zeichnet sich bereits ein nützliches Vorbereitungsmodell ab.

1. Klares Dateneigentum und Governance-Grenzen

Die verteidigungsfähigste Architektur ist eine, bei der der Wirtschaftsakteur Eigentümer der Produktdaten bleibt und der Dienstleister die technische Serviceschicht bereitstellt.

Eine seriöse Plattform sollte erklären können:

• Wem die Daten gehören
• Wer sie bearbeiten darf
• Wie Änderungen nachverfolgt werden
• Wie Datensätze exportiert werden
• Was geschieht, wenn die Geschäftsbeziehung endet

Wenn eine Plattform das nicht klar erklären kann, ist sie aus Governance-Perspektive bereits schwach aufgestellt.

2. Interoperabilität und Anti-Lock-in

Dies ist der stärkste Konsensuspunkt im Konsultationsprotokoll.

Für Plattformen sollte Interoperabilität kein nettes Extra sein, sondern das zugrunde liegende Modell prägen:

• Identifikatoren sollten portabel bleiben
• Datensätze sollten in einem nutzbaren, strukturierten Format exportierbar sein
• Systeme sollten proprietäre Abhängigkeiten vermeiden, die Migration erschweren
• Ein Anbieterwechsel sollte Unternehmen nicht zwingen, ihre Produktdatenbasis von Grund auf neu aufzubauen

Die sicherste Annahme ist, dass die künftige EU-Governance Plattformen belohnt, die Lock-in reduzieren statt vertiefen.

3. Backup-Logik und Kontinuitätsplanung

Die DPP-Dienstleister-Debatte kehrt wiederholt zu Sicherungskopien, Kontinuität und der Frage zurück, was geschieht, wenn der ursprüngliche Betreiber oder Dienstleister verschwindet.

Plattformen sollten bereits in Kategorien denken wie:

• Aktives Hosting vs. reiner Backup-Dienst
• Snapshot- oder Kontinuitätskopie-Logik
• Bedingungen für die Datenfreigabe
• Nachvollziehbare Aufbewahrung des letzten gültigen Produktdatensatzes

Nicht jedes Detail ist bereits bekannt, aber die Anforderung, ernsthaft über Kontinuität nachzudenken, besteht bereits.

4. Zugriffskontrolle und Umgang mit vertraulichen Daten

DPP ist nicht nur eine öffentliche Webseite für Verbraucher. Viele DPP-Datensätze werden Datenschichten mit unterschiedlichen Zugriffsrechten enthalten.

Plattformen sollten daher erwarten, Folgendes zu unterstützen:

• öffentliche Verbraucherinformationen
• vertrauliche B2B-Daten
• Zugangsebenen für Behörden
• Auditierbarkeit von Zugriffen und Änderungen

Dies ist eines der deutlichsten Zeichen, dass DPP-Plattformen näher an regulierter Infrastruktur als an gewöhnlichen Content-Management-Tools sind.

Zertifizierung: Was bekannt ist und was nicht

Die Zertifizierung ist eine der größten offenen Fragen in der Debatte über Dienstleister.

Was bereits bekannt ist

• Die Kommission hat ausdrücklich gefragt, ob ein Zertifizierungssystem benötigt wird
• Einige Stakeholder unterstützen eine unabhängige Ex-ante-Zertifizierung nachdrücklich
• Andere bevorzugen flexiblere Modelle
• Sicherheits- und Governance-Reife sind als Haupterwartung sichtbar

Was noch nicht bekannt ist

• Ob die Zertifizierung für alle Dienstleister verpflichtend wird
• Welche Stelle Dienstleister bewerten würde
• Ob das endgültige Modell zwischen verschiedenen Anbieterrollen unterscheidet
• Wie aufwendig der Prozess für kleinere Softwareunternehmen sein könnte

Die praktische Schlussfolgerung: Bauen Sie so, als müssten Sie irgendwann strukturierte Governance, Auditierbarkeit, Zuverlässigkeit und Sicherheitsreife nachweisen.

Warum dezentrale Architektur immer wieder auftaucht

Eines der stärksten Design-Signale im Feedback ist die Unterstützung für dezentrale Governance. Stakeholder wollen vermeiden, dass ein Anbieter zum unvermeidlichen, intransparenten Eigentümer der Produktdaten eines Unternehmens wird.

Das bedeutet nicht, dass jeder DPP selbst gehostet oder technisch vollständig verteilt sein muss.

Für Plattformen deutet das auf einen resilienteren Ansatz hin:

• Der Kunde besitzt die Produktdaten
• Der Dienstleister betreibt die Serviceschicht
• Exporte und Portabilität sind normal, nicht die Ausnahme
• Backup-Kontinuität impliziert keine Dominanz des Anbieters über das gesamte Datenökosystem

Das passt gut zur breiteren EU-Präferenz für offene Standards und interoperable digitale Infrastruktur.

Was Plattformen 2026 aufbauen sollten — noch vor dem endgültigen Rechtsakt

Am nützlichsten sind jene Vorbereitungsschritte, die unter mehreren möglichen rechtlichen Endzuständen wertvoll bleiben.

1. Strukturierte Exporte

Wenn ein Kunde wechselt oder neue Governance-Anforderungen erfüllen muss, muss der Datensatz in der Praxis portabel sein — nicht nur in der Theorie.

2. Nachvollziehbare Audit-Historie

Plattformen sollten davon ausgehen, dass die Fähigkeit zu zeigen, wer was wann und auf welcher Grundlage geändert hat, wichtiger wird.

3. Rollenbasierte Zugriffslogik

Auch wenn der endgültige Rechtsakt das Modell verfeinert, ist differenzierter Zugriff bereits eine vernünftige Grunderwartung.

4. Klare Kontinuitätspolitik

Plattformen sollten definieren, was mit Datensätzen geschieht, wenn ein Kundenkonto geschlossen wird, die Dienstleisterbeziehung endet oder Kontinuitätspflichten ausgelöst werden.

5. Offene Architekturentscheidungen

Systeme, die auf offenen Identifikatoren, strukturierten Datensätzen und Migrationslogik basieren, sind besser positioniert als Systeme, die auf Abhängigkeit und Intransparenz setzen.

Was Unternehmen beim Kauf eines Zugangs zu einer DPP-Plattform fragen sollten

Dieser Artikel richtet sich nicht nur an Softwareentwickler. Er richtet sich auch an Hersteller, Importeure und Markeninhaber, die Anbieter bewerten.

Nützliche Fragen umfassen:

• Wie handhaben Sie Dateneigentum?
• Können Datensätze in strukturiertem Format exportiert werden?
• Was ist Ihr Ansatz für Backup und Kontinuität?
• Wie trennen Sie öffentliche und zugangsbeschränkte Daten?
• Wie gestalten Sie Interoperabilität?
• Was geschieht, wenn wir den Anbieter wechseln möchten?

Das sind keine Randfall-Beschaffungsfragen mehr. Sie gehen direkt an den Kern der Frage, wie glaubwürdig die DPP-Architektur eines Anbieters wirklich ist.

Strategische Schlussfolgerung

Der endgültige delegierte Rechtsakt für DPP-Dienstleister steht noch bevor. Aber die Design-Richtung ist bereits deutlich genug, um praktische Entscheidungen zu unterstützen.

Das wahrscheinlich resilienteste DPP-Plattformmodell basiert nicht auf Intransparenz, proprietären Ausstiegsbarrieren und schwacher Kontinuitätslogik. Das stärkere Modell baut auf:

• klarer Governance
• exportierbaren, strukturierten Datensätzen
• Interoperabilität
• rollenbasiertem Zugriff
• Backup- und Kontinuitätsdisziplin

Unternehmen müssen nicht warten, bis jedes technische Detail finalisiert ist, um diese Kriterien bereits anzuwenden.

Weiterlesen

• Wer darf einen DPP betreiben? EU-Regeln für Dienstleister
• Was ist ein Digitaler Produktpass (DPP)?
• DPP-Datenanforderungen: Welche Daten Sie wirklich brauchen
• ESPR-DPP-Umsetzungsstatus 2026

Offizielle Quellen

• Initiative der Europäischen Kommission: Digitaler Produktpass – Regeln für Dienstleister
• ESPR-Verordnung (EU) 2024/1781
• Have Your Say-Portal der Europäischen Kommission

---

Wenn DPP-Plattformen auf stärkere Governance-, Portabilitäts- und Kontinuitätsanforderungen zusteuern, ist es sinnvoll, mit einem Betreiber zusammenzuarbeiten, der diese Entwicklungen von Anfang an verfolgt. OriginPass behandelt Produktdaten als strukturierte, portable Infrastruktur — nicht nur als Frontend-Passseiten.