ISO/IEC JTC 5: przygotowanie architektury na interoperacyjność DPP

ISO/IEC JTC 5 pracuje nad międzynarodowymi ramami DPP. Co otwarty projekt roboczy oznacza dziś praktycznie dla modeli danych, ról i interfejsów.

autor: QR3 Redaktion

ISO/IEC JTC 5: przygotowanie architektury na interoperacyjność DPP

Dlaczego temat architektury trafia teraz do agendy

Ten paszport jest w Europie stopniowo wprowadzany za pomocą aktów prawnych dotyczących poszczególnych sektorów. Firmy mogą łatwo odnieść wrażenie, że każda grupa produktów potrzebuje własnego modelu danych, własnego nośnika danych i własnej logiki integracji. Właśnie na tym styku rozpoczyna się praca ISO/IEC JTC 5: wspólny komitet techniczny powołany w 2026 roku ma opracować podstawy międzysektorowej i między systemami interoperacyjności DPP. Jego pierwsze zapowiedziane spotkanie odbędzie się w dniach 7–9 września 2026 roku w Berlinie. ISO/IEC JTC 5 wyraźnie opisuje swój mandat jako ramy dla systemu DPP i ekosystemu DPP; normy sektorowe pozostają w gestii właściwych komitetów branżowych.

Nie jest to nowy obowiązek prawny ani opublikowana norma ISO. Jest to jednak solidny powód, aby oddzielić własną architekturę od krótkoterminowych pól danych. Pierwszy punkt prac, ISO/AWI 25534-1, znajduje się jeszcze na etapie projektu 10.99; projekt zatwierdzono 12 lutego 2026 roku. Według ISO chodzi o terminy, podstawowe zasady, kategorie danych oraz mechanizmy zarządzania i zaufania. Publiczny wpis projektu wyraźnie wskazuje „under development”. Wyciąganie z tego już dziś obowiązku certyfikacji lub gotowego formatu wymiany byłoby przedwczesne.

Co odróżnia międzynarodowe ramy od wymogów UE

UE już wyznacza konkretne ramy. Komisja wyjaśnia, że DPP udostępnia informacje związane z produktem w modelu zdecentralizowanym: pełne dane pozostają u podmiotu gospodarczego lub u dostawcy usług DPP; rejestr zawiera jednoznaczne identyfikatory i wymagane dane rejestracyjne. Nośnik danych, taki jak kod QR, łączy fizyczny produkt z jego paszportem. Strona Komisji dotycząca DPP wskazuje także różne poziomy dostępu dla poszczególnych ról i harmonogramy sektorowe.

Obok tego funkcjonują europejskie normy zharmonizowane. Decyzja wykonawcza (UE) 2026/1736 z 14 lipca 2026 r. odsyła do sześciu norm DPP, między innymi dotyczących identyfikatorów, interoperacyjności, nośników danych, interfejsów API, wymiany danych i przechowywania danych. Ich rola jest konkretna: w odniesieniu do objętych nimi wymagań zgodność może wspierać domniemanie zgodności na podstawie art. 10 i 11 ESPR.

JTC 5 nie zastępuje tych poziomów. Pracuje ponad nimi: neutralne sektorowo ramy mają pomóc wyjaśnić, jak terminy, kategorie danych, zaufanie i zarządzanie odnoszą się do siebie między systemami. Praktyczna konsekwencja jest istotna. Producent nie powinien czekać na przyszłe wydanie ISO, aby udostępnić informacje dotyczące baterii, tekstyliów czy stali. Powinien jednak unikać utrwalania dzisiejszych pól branżowych jako niezmiennego rdzenia ogólnofirmowego modelu DPP.

Trzy decyzje architektoniczne, które warto podjąć już dziś

1. Oddzielić trwałą tożsamość od profili biznesowych

Paszport potrzebuje trwałej tożsamości technicznej: produktu, wariantu, partii lub pojedynczej sztuki; odpowiedzialnego podmiotu gospodarczego; rozpoznawania za pośrednictwem nośnika danych. Podstawa prawna określa następnie, jakie informacje fachowe są do tego potrzebne. Informacje te powinny znajdować się w wersjonowanych profilach. Moduł baterii przeznaczony do danych o emisji CO₂ lub stanie technicznym nie jest zatem ogólnym schematem bazowym. Również dane dotyczące materiałów, napraw czy recyklingu nie powinny trafiać do ogólnego paszportu wyłącznie jako nieustrukturyzowany tekst.

W praktyce oznacza to, że razem powinny występować stabilny identyfikator główny, udokumentowany identyfikator profilu i wersja profilu. Każdy udostępniony widok paszportu powinien pozwalać ustalić, który profil i która wersja określiły jego zawartość. Dzięki temu zespoły mogą uwzględnić akt prawny, regułę branżową lub późniejszą normę bez przepisywania danych historycznych czy adresów URL.

2. Oddzielnie modelować pochodzenie danych i dostęp

Interoperacyjność to nie tylko format JSON. Zależy ona od tego, czy odbiorca może ocenić pochodzenie, ważność i rolę danej informacji. Dlatego dla każdego elementu danych lub pakietu danych należy przechowywać co najmniej źródło, zakres obowiązywania, moment pozyskania, odpowiedzialną stronę i wersję merytoryczną. Wewnętrzna ocena jakości różni się od prawnie wiążącego oświadczenia o zgodności; informacja od dostawcy różni się od wyniku pomiaru.

Druga kwestia to dostęp. Komisja opisuje różne zakresy dostępu do informacji dla konsumentów, zakładów naprawczych, podmiotów zajmujących się recyklingiem i organów publicznych. Wymaga to świadomego rozdzielenia publicznego widoku paszportu, uprawnionego dostępu specjalistycznego i wewnętrznego obszaru roboczego. Adres URL nie może przy tym stawać się uprawnieniem. Role, upoważnienia, kategorie danych i decyzje możliwe do zarejestrowania muszą być sprawdzane po stronie serwera.

3. Testować granice wymiany jako kontrakty

System DPP ma wiele punktów przejścia: ERP lub PLM dostarczają dane podstawowe, dostawcy przekazują dowody, dostawca usług hostuje dane, rejestr przyjmuje metadane, a użytkownicy zewnętrzni odczytują widok publiczny lub chroniony. Dla każdego przejścia potrzebny jest odczytywalny maszynowo kontrakt: dozwolone pola, identyfikatory, semantyka, przypadki błędów, wersjonowanie i kompatybilność wsteczna.

Można to testować już teraz. Przydatne przypadki testowe obejmują nieznane wersje profili, wygasłe dowody, brak pochodzenia danych, niedozwolone role, podwójną rejestrację oraz nośnik danych wskazujący na paszport, który nie jest już dostępny. Test nie dowodzi jeszcze zgodności z przyszłą normą ISO. Tworzy jednak możliwość wykazania zgodności, której zabraknie później, jeśli model danych i uprawnienia zostaną już ze sobą nierozerwalnie połączone.

Plan prac na 90 dni bez spekulacji

W ciągu najbliższych 30 dni warto sporządzić obraz stanu obecnego: jakie identyfikatory produktów istnieją, jakie profile danych są faktycznie używane i które dane znajdują się wyłącznie w dokumentach? Następnie należy podjąć decyzję architektoniczną dotyczącą modelu głównego, rejestru profili, modelu pochodzenia i macierzy dostępu. W trzecim kroku rzeczywisty produkt powinien przejść przez wszystkie punkty przejścia — od systemu źródłowego, przez paszport, po rolę zakładu naprawczego lub organu publicznego.

Granice pozostają przy tym jasne. ISO/AWI 25534-1 nie jest gotową normą; nie ma opublikowanych klauzul, które zespoły mogłyby wdrożyć. Również oś czasu Komisji ma charakter orientacyjny i nie zastępuje analizy aktu prawnego obowiązującego dla danej grupy produktów. Korzyść z obserwowania tych prac nie polega więc na przedwczesnym odhaczaniu pozycji na liście zgodności, lecz na stworzeniu architektury, która potrafi prawidłowo przyjmować nowe profile, role i zasady wymiany.

Źródła