Ab 31. Juli zählt der Reparaturpfad
Am 31. Juli 2026 müssen die Mitgliedstaaten die Richtlinie (EU) 2024/1799 anwenden. Sie soll Reparaturen von Waren fördern und ergänzt die bestehenden Gewährleistungsregeln. Das ist kein Digital-Product-Passport-Gesetz. Für Hersteller, Importeure, Händler und Reparaturbetriebe ist der Termin trotzdem ein guter Stichtag: Eine Reparatur lässt sich nur zuverlässig anbieten, wenn die richtigen Produkt-, Ersatzteil- und Prozessdaten auffindbar sind. Die Richtlinie wurde am 13. Juni 2024 angenommen, trat am 30. Juli 2024 in Kraft und ist ab dem 31. Juli 2026 anzuwenden. Das bestätigt die EU-Kommission ebenso wie Artikel 22 der Richtlinie.
Der praktische Fehler wäre nun, den Produktpass als bloßes Compliance-PDF zu behandeln. Ein belastbarer Datenzugang muss den Weg von der Identifikation eines konkreten Produkts bis zu einer umsetzbaren Reparaturentscheidung unterstützen. Das lässt sich bereits heute vorbereiten, ohne eine noch nicht erlassene produktgruppenspezifische DPP-Pflicht vorwegzunehmen.
Was die Reparaturrichtlinie tatsächlich verlangt
Die Richtlinie betrifft Waren mit Reparierbarkeitsanforderungen des Unionsrechts, die in Anhang II aufgeführt sind. Für diese Produkte müssen Hersteller auf Verlangen reparieren, soweit die Reparatur technisch möglich ist. Die Kommission nennt als Beispiele unter anderem Kühlschränke und Smartphones. Die Regelung greift auch außerhalb der gesetzlichen Gewährleistung; bei der Gewährleistung soll die Reparatur attraktiver werden. Sie schafft außerdem ein europäisches Formular für Reparaturinformationen und eine europäische Online-Plattform für Reparaturen. Die Details stehen in der amtlichen Richtlinie (EU) 2024/1799.
Wichtig für die Planung: Die Richtlinie macht nicht automatisch aus jedem Produktpass einen Reparaturpass. Sie bestimmt weder ein einheitliches Datenmodell für alle Ersatzteile noch einen bestimmten QR-Code. Welche Informationen in einem DPP künftig verpflichtend sein werden, ergibt sich erst aus den jeweiligen delegierten Rechtsakten zur Ökodesign-Verordnung. Wer diesen Unterschied sauber trennt, vermeidet zwei Risiken: überzogene Rechtsbehauptungen im Vertrieb und eine Datenarchitektur, die am späteren Produktgruppenakt vorbeigeht.
Warum der DPP dennoch der richtige Datenanker ist
Die Ökodesign-Verordnung (EU) 2024/1781 definiert den Digitalen Produktpass als elektronisch zugänglichen produktspezifischen Datensatz. Sie legt fest, dass ein DPP über einen Datenträger mit einer persistenten eindeutigen Produktkennung verbunden sein soll. Die späteren delegierten Rechtsakte können festlegen, auf welcher Ebene – Modell, Charge oder Einzelstück – Daten geführt werden, wer sie aktualisieren darf und wie lange der Pass verfügbar bleibt. Das steht in Artikel 9 der Verordnung.
Für Reparaturprozesse ist besonders Artikel 11 relevant: Er nennt unter den möglichen berechtigten Akteuren ausdrücklich professionelle Reparaturbetriebe und unabhängige Betreiber. Zugleich ist der Zugriff nicht pauschal öffentlich, sondern an produktgruppenspezifische Rechte gebunden. Daraus folgt eine technische Leitlinie, keine neue Rechtsbehauptung: Daten für Kundinnen und Kunden, Reparaturbetriebe, Ersatzteilteams und Behörden sollten getrennt modelliert werden. Ein QR-Code darf auf eine belastbare Kennung verweisen; er sollte nicht selbst der Speicherort sensibler Betriebs-, Vertrags- oder Kundendaten sein.
Der Reparaturpfad in sechs Datenstationen
Ein gutes Zielbild beginnt nicht mit einem Dashboard, sondern mit einem prüfbaren Ablauf.
1. Produkt sicher identifizieren
Beim Scan oder bei einer manuellen Eingabe muss klar werden, ob die Anfrage ein Modell, eine Charge oder ein einzelnes Gerät betrifft. Die persistente Kennung braucht eine stabile Auflösung: keine Kampagnen-URL, keine saisonale Produktseite und keine Adresse, die beim Relaunch verschwindet. Bei dynamischen QR-Codes gehört deshalb ein dokumentierter Weiterleitungs- und Rückfallpfad in die Architektur. Eine technische Einführung in produktbezogene DPP-Endpunkte bietet der bereits veröffentlichte qr3-Leitfaden zur DPP-API.
2. Reparierbarkeit vom Diagnoseergebnis trennen
Ein Datenblatt kann sagen, dass ein Produkt grundsätzlich reparierbar ist. Es beantwortet noch nicht, ob der konkrete Fehler, der Sicherheitszustand und das verfügbare Ersatzteil eine Reparatur zulassen. Halten Sie daher getrennte Felder für Produktregel, Fehlerdiagnose, Sicherheitswarnung und Reparaturentscheidung vor. Die Entscheidung braucht Herkunft, Zeitstempel und verantwortliche Rolle. So wird aus einer allgemeinen Aussage kein unprüfbares Versprechen gegenüber Kundinnen und Kunden.
3. Ersatzteile mit Version und Gültigkeit führen
Reparaturteams benötigen nicht nur eine Teilenummer. Nötig sind Kompatibilität, Hardware- oder Software-Revision, Verfügbarkeit, zulässige Alternativen, Sicherheits- und Montagehinweise sowie der Zeitpunkt der letzten Prüfung. Eine Änderung des Lieferstatus darf nicht das ursprüngliche Teil überschreiben. Modellieren Sie stattdessen Versionen und Gültigkeitszeiträume. Das erleichtert Rückrufe, Servicekampagnen und die spätere Nachvollziehbarkeit.
4. Rollen statt pauschale Freigaben definieren
Öffentlich sichtbare Informationen können etwa Modellbezeichnung, Pflegehinweise und die Anlaufstelle für Reparatur sein. Professionelle Reparaturbetriebe benötigen je nach Produkt zusätzliche technische Unterlagen. Interne Teams benötigen weitergehende Lieferanten- und Qualitätsdaten. Legen Sie diese Trennung früh fest und protokollieren Sie Zugriffe auf nicht öffentliche Inhalte. Die ESPR fordert für DPPs einen hohen Sicherheits- und Datenschutzstandard; Kundendaten dürfen ohne ausdrückliche Einwilligung nicht im Pass gespeichert werden.
5. Den Status der Anfrage nachvollziehbar machen
Die neue Richtlinie stärkt den Zugang zu Reparaturinformationen. Operativ entsteht Vertrauen aber erst, wenn Anfragen nicht in Postfächern verschwinden. Ein minimaler Statusfluss reicht: Anfrage eingegangen, Identität oder Gerät geprüft, Kostenschätzung erstellt, Ersatzteil verfügbar, Reparatur vereinbart, abgeschlossen oder begründet abgelehnt. Jede Ablehnung sollte den konkreten Grund und den nächsten möglichen Schritt festhalten. Das ist auch die Grundlage für belastbare Servicekennzahlen.
6. Daten nach der Reparatur zurückspielen
Nach einem Teiletausch ändern sich mindestens Servicehistorie und unter Umständen Konfiguration, Gewährleistungsdaten oder Sicherheitsstatus. Definieren Sie, wer diesen Eintrag anlegen darf, welche Nachweise zu speichern sind und welche Informationen anschließend für welche Rolle sichtbar werden. Die ESPR verlangt, dass DPP-Daten genau, vollständig und aktuell sind. Eine Reparaturhistorie ohne Governance würde diesen Anspruch gerade nicht erfüllen.
Was bis Ende der Woche geprüft werden sollte
Der 31. Juli ist kein Anlass für eine hastige Komplettmigration. Er ist ein sinnvoller Checkpoint für drei konkrete Fragen. Erstens: Können Sie für die betroffenen Produktgruppen eine Reparaturanfrage einem eindeutigen Produkt zuordnen? Zweitens: Sind Ersatzteil- und Kompatibilitätsdaten versioniert und für berechtigte Reparaturbetriebe auffindbar? Drittens: Können Sie nachweisen, wer einen Datensatz geändert hat und warum?
Wenn eine Antwort fehlt, beginnen Sie mit einem kleinen Pilotprodukt und einem echten Reparaturfall. Messen Sie die Zeit vom Scan bis zur belastbaren Entscheidung, nicht die Zahl der befüllten Felder. So verbinden Sie die ab 31. Juli geltende Reparaturpraxis mit einer DPP-Architektur, die offen genug für künftige delegierte Rechtsakte bleibt.
Quellen
- Europäische Kommission: Directive on repair of goods – Stand und Anwendungsdatum der Reparaturrichtlinie.
- EUR-Lex: Richtlinie (EU) 2024/1799 – amtlicher Text, insbesondere Artikel 4, 21 und 22 sowie Anhang II.
- EUR-Lex: Verordnung (EU) 2024/1781 – Digitaler Produktpass, insbesondere Artikel 9 bis 11 und Anhang III.
