Das ESPR-Rahmenwerk: von der Verordnung zu delegierten und Durchführungsrechtsakten
Kernerkenntnis: Die ESPR ist die rechtliche Grundlage, aber sie delegiert das Was an delegierte Rechtsakte, das Wie an Durchführungsrechtsakte und die exakten Formate an EN-Normen. Ein Implementierer, der diese Hierarchie versteht, weiß, wo jede Anforderung lebt und wann sie sich ändern kann.
1. Verordnung vs. Richtlinie — warum das für die Architektur zählt
Die ESPR (Verordnung (EU) 2024/1781) ist eine Verordnung, keine Richtlinie. Eine Richtlinie verlangt von jedem Mitgliedstaat die Umsetzung in nationales Recht; eine Verordnung gilt unmittelbar in allen Mitgliedstaaten mit einheitlicher Wirkung. Für die DPP-Architektur entfällt damit eine ganze Klasse länderspezifischer Abweichungen in der Kernfunktionalität: Datenträger, Zugriffsregeln, Persistenz und Interoperabilität sind überall gleich.
Der eine Bereich, in dem Mitgliedstaaten weiterhin zählen, ist die Marktüberwachung und Durchsetzung — welche nationale Behörde Sie ansprechen und in welcher Sprache die verbraucherorientierte Oberfläche erscheinen muss. Die Kerndatenlogik ist einheitlich; die Ränder sind national.
| Ebene | Was sie tut | DPP-Beispiel |
|---|---|---|
| Verordnung (ESPR) | Allgemeine Pflichten, gilt unmittelbar | DPP erforderlich; Datenträger; Zugänglichkeit; Persistenz |
| Delegierter Rechtsakt | Produktkategorie-Spezifika | Batteriefelder, Textilfelder, Zeitpläne |
| Durchführungsrechtsakt | Technisches/prozedurales Detail | DPP-Register-Regeln, Zugriff auf eingeschränkte Daten |
| EN-Norm | Freiwillige technische Spezifikation | EN 18216–18223 (Kennungen, Datenträger, APIs…) |
| Nationale Umsetzung | Überwachung & Durchsetzung | Meldung an die Behörde, Verbrauchersprache |
Warum ist „die ESPR ist eine Verordnung, keine Richtlinie“ für einen DPP-Systemarchitekten wichtig?
2. Delegierte Rechtsakte: kategoriespezifische Anforderungen
Die Kommission erlässt delegierte Rechtsakte, die die ESPR je Produktkategorie konkretisieren. Ein delegierter Rechtsakt spezifiziert die Datenfelder, Lebenszyklusphasen, den Compliance-Zeitplan und die Verifizierungsregeln für diese Kategorie. Die ersten delegierten Rechtsakte unter der ESPR betreffen Eisen und Stahl (2026); Textilien, Reifen und Aluminium folgen (2027); Möbel (2028); Matratzen und IKT (2029). Batterien laufen unter ihrer eigenen Verordnung (2023/1542), mit den ersten betriebsbereiten Pässen im Februar 2027.
Um zu sehen, was ein delegierter Rechtsakt tatsächlich enthält, nehmen Sie einen hypothetischen Textil-Rechtsakt. Er würde aufzählen:
- die verpflichtenden Datenfelder (Faserzusammensetzung, Recyclinganteil, Produktionsland, Pflegehinweise);
- die Lebenszyklusphasen, die erfasst werden müssen (Faser → Garn → Stoff → Kleidungsstück → Einzelhandel → Lebensende);
- den Compliance-Zeitplan (vom Geltungsbeginn bis zur vollen Verpflichtung);
- die Verifizierungsregeln (wie Aussagen belegt und geprüft werden müssen).
Deshalb erzwingen delegierte Rechtsakte ein Kern-plus-Erweiterungen-Design: ein kategorieunabhängiger Kern (Kennungen, Datenträger, APIs) plus kategoriespezifische Erweiterungsmodule. „Batteriefelder" in den Kern zu kodieren ist der klassische Fehler — der nächste delegierte Rechtsakt würde eine Neuarchitektur erfordern.
Warum erzwingen delegierte Rechtsakte eine Kern-plus-Erweiterungen-Architektur statt eines großen Datenmodells?
3. Durchführungsrechtsakte: die operative Schicht
Durchführungsrechtsakte definieren, wie das System technisch funktioniert: den Registrierungsablauf des DPP-Registers, Datenformate, Protokolle und Tests. Ein wichtiger ist der DPP-Register-Durchführungsrechtsakt (2026/1778); der Rechtsakt zum Zugriff auf eingeschränkte Daten wird Ende 2026 erwartet. Hier findet ein Implementierer konkretes, zwingend zu befolgendes Verfahren — Einschreibung über qualifizierte elektronische Signaturen/Siegel, das Verhalten der Register-API und die Zugriffsrechteregeln.
Die Unterscheidung ist praktisch. Ein delegierter Rechtsakt sagt Ihnen, welche Felder ein Batteriepass enthalten muss; ein Durchführungsrechtsakt sagt Ihnen, wie Sie diesen Pass im Register registrieren und wer auf welche Felder zugreifen darf. Die beiden zu verwechseln führt dazu, dass man das richtige Datenmodell gegen den falschen Arbeitsablauf baut.
Welches Paar kontrastiert delegierte Rechtsakte und Durchführungsrechtsakte richtig?
4. EN-Normen: die freiwillige, aber de facto verbindliche Schicht
Die EN-182xx-Familie (veröffentlicht Mai 2026) ist formal freiwillig, aber die Konformität mit ihnen gewährt die Konformitätsvermutung mit den Artikeln 10 und 11 der ESPR. In der Praxis macht sie das zur de facto Spezifikation, der jede Implementierung folgt:
| Norm | Was sie spezifiziert |
|---|---|
| EN 18216 | Datenaustauschprotokolle — wie Passdaten zwischen Systemen fließen |
| EN 18219 | Eindeutige Kennungen — UPI, UOI, UFI und wie man sie konstruiert |
| EN 18220 | Datenträger — QR, Data Matrix, NFC, RFID und wie ein Datenträger die Kennung kodiert |
| EN 18221 | Speicherung, Archivierung und Persistenz — Aufbewahrung und Integrität über Jahrzehnte |
| EN 18222 | APIs für Lebenszyklusverwaltung und Durchsuchbarkeit |
| EN 18223 | Systeminteroperabilität über Implementierungen hinweg |
| prEN 18239 | Zugriffsrechte, Sicherheit und Vertraulichkeit (in Abstimmung) |
| prEN 18246 | Datenauthentifizierung, Zuverlässigkeit und Integrität (in Abstimmung) |
Die vollständige Familie wird in Modul 2 behandelt. Hier geht es um die Schichtung: Die Verordnung setzt Pflichten, Normen setzen Technik.
Die EN-182xx-Normen sind formal freiwillig. Warum werden sie dennoch als de facto Spezifikation behandelt?
5. Für regulatorische Änderungen designen
Die Hierarchie ist nicht statisch: Delegierte Rechtsakte treffen über die Zeit ein, Normen werden überarbeitet und nationale Leitlinien entwickeln sich. Eine belastbare DPP-Architektur hat daher:
- eine Regulierungs-Abstraktionsschicht — eine stabile interne Schnittstelle, die ESPR-Spezifika verbirgt, sodass eine Normrevision einen Adapter ändert, nicht das ganze System;
- Kategorieerweiterungen — austauschbare Module für jeden delegierten Rechtsakt;
- konfigurationsgetriebene Anforderungen — Feldlisten und Validierungsregeln als Daten, nicht als Code;
- einen Änderungsmanagement-Prozess — Folgenabschätzung, bevor ein regulatorisches Update ausgeliefert wird.
Eine konkrete Veranschaulichung: Wenn die Kennungsregeln der EN 18219 überarbeitet werden, aktualisiert ein gut geschichtetes System seinen Kennungs-Adapter hinter einer stabilen Schnittstelle. Ein schlecht geschichtetes System bearbeitet Kennungslogik, die über Registrierungs-, Validierungs- und API-Code verstreut ist — drei Stellen, an denen etwas bricht. Die Abstraktionsschicht macht aus „Compliance" eine Wartungsaufgabe statt einer wiederkehrenden Feuerwehrübung.
Ein neuer delegierter Rechtsakt fügt ein Feld „Haltbarkeitsbewertung“ zum Textil-DPP hinzu. Welche Designentscheidung erlaubt es, es zu unterstützen, ohne den Kern neu zu architekturieren?
Kernpunkte
- Die ESPR ist eine Verordnung — Kernanforderungen gelten einheitlich; nur die Durchsetzung variiert national.
- Delegierte Rechtsakte fügen kategoriespezifische Felder, Zeitpläne und Verifizierung hinzu.
- Durchführungsrechtsakte definieren operatives Detail (Registerablauf, Zugriffsregeln).
- Die EN-182xx-Normen liefern die de facto technische Spezifikation und die Konformitätsvermutung.
- Für Änderungen designen: Abstraktionsschicht, Kategorieerweiterungen, konfigurationsgetriebene Anforderungen.
Kernerkenntnis: Anforderungen leben auf fünf Ebenen. Wenn Sie wissen, aus welcher Ebene eine Anforderung stammt, wissen Sie, wie stabil sie ist und wie Sie dafür architekturieren.