ISO/IEC JTC 5: DPP-Architektur auf Interoperabilität vorbereiten

Warum jetzt ein Architekturthema auf die Agenda kommt

Der Digitale Produktpass wird in Europa schrittweise über sektorale Rechtsakte eingeführt. Für Unternehmen entsteht daraus leicht der Eindruck, dass jede Produktgruppe ihr eigenes Datenmodell, ihren eigenen Datenträger und ihre eigene Integrationslogik braucht. Genau an dieser Schnittstelle beginnt die Arbeit von ISO/IEC JTC 5: Das gemeinsame technische Komitee wurde 2026 eingerichtet und soll die Grundlagen für sektor- und systemübergreifende DPP-Interoperabilität erarbeiten. Sein erstes angekündigtes Treffen findet vom 7. bis 9. September 2026 in Berlin statt. ISO/IEC JTC 5 beschreibt seinen Auftrag ausdrücklich als Rahmen für DPP-System und DPP-Ökosystem; sektorspezifische Normen bleiben bei den zuständigen Fachgremien.

Das ist keine neue gesetzliche Pflicht und auch keine veröffentlichte ISO-Norm. Es ist aber ein belastbarer Anlass, die eigene Architektur von kurzfristigen Datenfeldern zu trennen. Der erste Arbeitspunkt, ISO/AWI 25534-1, befindet sich noch im Projektstadium 10.99; das Projekt wurde am 12. Februar 2026 genehmigt. Laut ISO geht es um Begriffe, Grundprinzipien, Datenkategorien sowie Governance- und Vertrauensmechanismen. Der öffentliche Projekteintag nennt ausdrücklich „under development“. Wer daraus heute eine Zertifizierungspflicht oder ein fertiges Austauschformat ableitet, greift vor.

Was der internationale Rahmen von den EU-Vorgaben trennt

Die EU setzt bereits konkrete Leitplanken. Die Kommission erläutert, dass der DPP produktbezogene Informationen in einem dezentralen Modell zugänglich macht: Die vollständigen Daten bleiben beim Wirtschaftsakteur oder beim DPP-Service-Provider; das Register führt eindeutige Kennungen und vorgeschriebene Registrierungsdaten. Ein Datenträger wie ein QR-Code verbindet das physische Produkt mit seinem Pass. Die DPP-Seite der Kommission nennt zudem unterschiedliche Zugriffe für Rollen und sektorale Zeitpläne.

Daneben stehen die europäischen harmonisierten Standards. Die Durchführungsentscheidung (EU) 2026/1736 vom 14. Juli 2026 verweist auf sechs DPP-Standards, unter anderem zu Kennungen, Interoperabilität, Datenträgern, APIs, Datenaustausch und Datenspeicherung. Ihre Rolle ist konkret: Für die von ihnen abgedeckten Anforderungen kann die Einhaltung die Konformitätsvermutung nach Artikel 10 und 11 ESPR stützen.

JTC 5 ersetzt diese Ebenen nicht. Es arbeitet darüber: Ein sektorneutraler Rahmen soll erklären helfen, wie sich Begriffe, Datenkategorien, Vertrauen und Governance zwischen Systemen zueinander verhalten. Die praktische Konsequenz ist wichtig. Ein Hersteller sollte nicht auf eine künftige ISO-Ausgabe warten, um seine Batterie-, Textil- oder Stahlinformationen bereitzustellen. Er sollte aber vermeiden, heutige Branchenfelder als unveränderlichen Kern eines unternehmensweiten DPP-Modells festzuschreiben.

Drei Architekturentscheidungen, die heute sinnvoll sind

1. Stabile Identität von fachlichen Profilen trennen

Ein Pass braucht eine langlebige technische Identität: Produkt, Variante, Charge oder Einzelstück; verantwortlicher Wirtschaftsakteur; Auflösung über den Datenträger. Die Rechtsgrundlage bestimmt anschließend, welche Fachinformationen dafür erforderlich sind. Diese Fachinformationen gehören in versionierte Profile. Ein Batteriemodul für CO₂- oder State-of-Health-Daten ist deshalb kein allgemeines Basisschema. Ebenso wenig dürfen Material-, Reparatur- oder Recyclingdaten nur als unstrukturierter Freitext in einem allgemeinen Pass landen.

Praktisch bedeutet das: Eine stabile Kern-ID, eine dokumentierte Profilkennung und eine Profilversion gehören zusammen. Jede ausgelieferte Passansicht sollte erkennen lassen, welches Profil und welche Version den Inhalt bestimmt haben. So können Teams einen Rechtsakt, eine Branchenregel oder später eine Norm nachziehen, ohne historische Daten oder URLs umzuschreiben.

2. Datenherkunft und Zugriff getrennt modellieren

Interoperabilität ist nicht nur ein JSON-Format. Sie hängt davon ab, ob ein Empfänger Herkunft, Gültigkeit und Rolle einer Information beurteilen kann. Speichern Sie daher je Datenelement oder Datenpaket mindestens Quelle, Geltungsbereich, Erfassungszeitpunkt, verantwortliche Partei und fachliche Version. Ein interner Qualitätswert ist etwas anderes als eine rechtsverbindliche Konformitätsaussage; eine Lieferantenauskunft ist etwas anderes als ein Messwert.

Der zweite Teil ist der Zugriff. Die Kommission beschreibt unterschiedliche Informationszugriffe für Verbraucher, Reparaturbetriebe, Recycler und Behörden. Das verlangt eine bewusste Trennung von öffentlicher Passansicht, berechtigtem Fachzugriff und internem Arbeitsbereich. Eine URL darf dabei nicht zur Berechtigung werden. Rollen, Mandate, Datenkategorien und protokollierbare Entscheidungen müssen serverseitig geprüft werden.

3. Austauschgrenzen als Verträge testen

Ein DPP-System hat mehrere Übergänge: ERP oder PLM liefern Stammdaten, Lieferanten liefern Nachweise, ein Service-Provider hostet Daten, ein Register nimmt Metadaten entgegen, und externe Nutzer lesen eine öffentliche oder geschützte Ansicht. Für jeden Übergang braucht es einen maschinenlesbaren Vertrag: zulässige Felder, Kennungen, Semantik, Fehlerfälle, Versionierung und Rückwärtskompatibilität.

Das lässt sich schon jetzt testen. Sinnvolle Testfälle sind unbekannte Profilversionen, abgelaufene Nachweise, fehlende Datenherkunft, unzulässige Rollen, doppelte Registrierung und ein Datenträger, der auf einen nicht mehr verfügbaren Pass zeigt. Der Test beweist noch keine Konformität mit einer künftigen ISO-Norm. Er schafft aber die Nachweisbarkeit, die bei der späteren Umstellung fehlt, wenn Datenmodell und Rechte bereits untrennbar vermischt sind.

Ein 90-Tage-Arbeitsplan ohne Spekulation

In den nächsten 30 Tagen lohnt sich ein Bestandsbild: Welche Produktkennungen existieren, welche Datenprofile werden tatsächlich verwendet und welche Daten liegen nur in Dokumenten vor? Danach folgt ein Architekturentscheid: Kernmodell, Profilregister, Herkunftsmodell und Zugriffsmatrix. In einem dritten Schritt sollte ein reales Produkt durch alle Übergänge laufen — vom Quellsystem über den Pass bis zur Rolle des Reparaturbetriebs oder der Behörde.

Dabei bleiben die Grenzen klar. ISO/AWI 25534-1 ist kein fertiger Standard; es gibt keine veröffentlichten Klauseln, die Teams implementieren könnten. Auch die Kommissions-Zeitachse ist indikativ und ersetzt keine Prüfung des für die jeweilige Produktgruppe geltenden Rechtsakts. Der Nutzen der Beobachtung liegt deshalb nicht im vorgezogenen Häkchen auf einer Compliance-Liste, sondern in einer Architektur, die neue Profile, Rollen und Austauschregeln sauber aufnehmen kann.