Dlaczego „jednorazowa rejestracja" to za mało
Wiele firm traktuje cyfrowy paszport produktu (DPP) jako jednorazowy obowiązek zgodności: zebrać dane, utworzyć wpis w rejestrze, gotowe. Rozporządzenie ESPR (UE) 2024/1781 opowiada jednak inną historię. Wymaga ono, aby wpisy w rejestrze pozostawały dostępne i aktualne przez co najmniej 10 lat od ostatniego wprowadzenia produktu do obrotu. Jeśli wycofasz dziś jakiś model, musisz utrzymywać jego wpis co najmniej do 2036 roku — wraz z prawidłowymi punktami końcowymi resolvera i poprawnymi unikalnymi identyfikatorami.
W tym artykule wyjaśniamy, co tak naprawdę oznacza aktualizacja wpisu w rejestrze, których pól ona dotyczy oraz jak zabezpieczyć ten proces od strony technicznej.
Co rejestr przechowuje — a czego nie
29 kwietnia 2026 roku Komisja Europejska opublikowała projekt rozporządzenia wykonawczego dotyczącego centralnego rejestru DPP. Dokument jasno pokazuje, jak minimalistyczny ma być centralny rejestr: przechowuje on tylko trzy elementy danych na każdy wpis:
| Pole | Opis | Obowiązek aktualizacji |
|---|---|---|
| Unikalny identyfikator (UID) | Unikalny identyfikator produktu/modelu | Niezmienny po przypisaniu |
| Punkt końcowy resolvera | URL, pod którym można pobrać pełny DPP | Możliwy do aktualizacji; wymagany przy migracji |
| Kod towarowy | Kod kategorii produktu (np. kod HS lub CN) | Możliwy do skorygowania w przypadku błędnego wpisu |
Właściwe dane produktu — skład materiałowy, wskaźnik możliwości naprawy, ślad węglowy — nie są przechowywane w centralnym rejestrze. Udostępnia je producent lub upoważniony powiernik danych w punkcie końcowym resolvera. Rejestr jest po prostu książką adresową. To rozdzielenie ma znaczenie architektoniczne: aktualizacja centralnego wpisu jest konieczna tylko wtedy, gdy zmienia się UID, resolver lub kod towarowy. Utrzymanie danych na poziomie treści odbywa się wyłącznie po stronie dostawcy danych.
Wymagania dotyczące danych specyficznych dla produktu — co dokładnie musi pojawić się w DPP — pozostają domeną regulacji branżowych, takich jak rozporządzenia delegowane na podstawie ESPR lub, w przypadku baterii, rozporządzenia w sprawie baterii (UE) 2023/1542.
Kiedy aktualizacja rejestru jest obowiązkowa
Zmienił się punkt końcowy resolvera
To najczęstszy scenariusz w praktyce. Firmy zmieniają dostawców chmury, migrują na nowe platformy DPP lub konsolidują domeny. Gdy tylko poprzedni punkt końcowy resolvera staje się nieosiągalny, żaden skaner — czy to organu celnego, organu nadzoru rynku, czy konsumenta końcowego — nie może pobrać DPP. Rozporządzenie nie określa wprost terminu reakcji, ale 10-letni obowiązek dostępności w praktyce oznacza zerową tolerancję dla trwale zerwanych odnośników.
Zalecenie: Stosuj stabilny resolver na subdomenie należącej do firmy (np. dpp.yourcompany.com) jako warstwę pośrednią. Dzięki temu przy zmianie platformy wystarczy zmienić konfigurację wewnętrznie — bez ingerencji we wpis w rejestrze. Jest to zgodne z zasadą GS1 Digital Link, w której QR code wskazuje na stabilny resolver, który z kolei przekierowuje do zmieniających się systemów zaplecza.
Wprowadzono nieprawidłowy kod towarowy
Kody towarowe (kody CN lub HS) określają, które rozporządzenia delegowane mają zastosowanie do produktu. Nieprawidłowy kod może spowodować zaklasyfikowanie produktu do niewłaściwej kategorii lub jego błędną klasyfikację podczas zautomatyzowanych kontroli granicznych — które UE planuje wprowadzić od 2028 roku na mocy proponowanego aktu o gospodarce o obiegu zamkniętym. Korekty są dozwolone na mocy projektu rozporządzenia wykonawczego, ale wymagają udokumentowanego uzasadnienia.
Przejęcie spółki lub przeniesienie licencji
Gdy zmienia się ekonomiczne właścicielstwo produktu, należy ocenić, czy odpowiedzialność za resolver również jest przenoszona. Konto w rejestrze jest powiązane z pierwotnym podmiotem rejestrującym; przeniesienie wymaga sformalizowanego procesu przeprowadzanego przez właściwy organ krajowy.
Proces techniczny: aktualizacja wpisu
Rozporządzenie wykonawcze przewiduje interfejs do rejestru oparty na API. Dokładny punkt końcowy zostanie opublikowany dopiero po wejściu rozporządzenia w życie, ale oczekiwany przebieg pracy można wywnioskować z projektu:
# Authentication via OAuth 2.0 Client Credentials
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X POST https://registry.dpp.ec.europa.eu/oauth/token \
-d "grant_type=client_credentials" \
-d "client_id=YOUR_CLIENT_ID" \
-d "client_secret=YOUR_SECRET" \
-d "scope=registry:write"
# PATCH request to update the resolver endpoint
# Note: The registry API URL below is illustrative; the final endpoint will be published upon entry into force.
curl -X PATCH https://registry.dpp.ec.europa.eu/v1/entries/{uid} \
-H "Authorization: Bearer {ACCESS_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/{uid}",
"updateReason": "platform_migration"
}'
Pole updateReason jest w projekcie wskazane jako obowiązkowe dla wszystkich zmian innych niż wpis początkowy. Dopuszczalne wartości obejmują platform_migration, domain_change, commodity_code_correction oraz ownership_transfer. Historia audytu wszystkich aktualizacji jest przechowywana przez rejestr przez pełny 10-letni okres.
Aktualizacje zbiorcze dla dużych portfeli produktów
Firmy posiadające tysiące SKU nie są w stanie ręcznie obsługiwać pojedynczych żądań. Projekt rozporządzenia przewiduje punkt końcowy do operacji wsadowych:
{
"batchUpdate": [
{
"uid": "urn:epc:id:sgtin:0614141.107346.2017",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2017",
"updateReason": "platform_migration"
},
{
"uid": "urn:epc:id:sgtin:0614141.107346.2018",
"resolverEndpoint": "https://dpp.yourcompany.com/resolve/0614141.107346.2018",
"updateReason": "platform_migration"
}
]
}
Budowanie i utrzymywanie tych procesów zbiorczych wymaga ustrukturyzowanego zarządzania danymi, jakiego wymaga proces importu zbiorczego dla wpisów DPP.
Standaryzacja międzynarodowa jako kotwica stabilności
Proces aktualizacji jest tak solidny, jak standardy, na których został zbudowany. W tym miejscu wkracza powołanie ISO/IEC JTC 5: nowy Wspólny Komitet Techniczny, którego sekretariat sprawuje Niemiecki Instytut Normalizacyjny (DIN), ma za zadanie opracowanie międzynarodowych standardów na rzecz globalnej interoperacyjności systemów DPP.
W praktyce dla procesów aktualizacji oznacza to: gdy ISO/IEC JTC 5 przyjmie standardy dla formatów danych, schematów API i struktur identyfikatorów, mają one zasilić przyszłe rewizje rozporządzeń wykonawczych do ESPR. Firmy, które już opierają się na identyfikatorach zgodnych z GS1 (GTIN, SGTIN) oraz resolverach GS1 Digital Link, są w dobrej pozycji: standardy te są uznawane za implementację referencyjną dla JTC 5.
Notyfikacja WTO dotycząca rozporządzenia o rejestrze UE (G/TBT/N/EU/1211) z 21 maja 2026 roku również sygnalizuje, że system jest klasyfikowany jako techniczny przepis handlowy — z konsekwencjami dla producentów z krajów trzecich eksportujących produkty do UE. Oni również muszą utrzymywać i aktualizować wpisy w rejestrze.
Utrzymanie danych jako proces ciągły: implikacje organizacyjne
10-letni obowiązek nie jest wyłącznie zadaniem informatycznym. Wymaga on działań organizacyjnych:
- Udokumentuj odpowiedzialność: Kto w Twojej organizacji odpowiada za wpisy w rejestrze? Ta rola musi być obsadzona nawet przy rotacji personelu i restrukturyzacji firmy.
- Skonfiguruj monitorowanie resolvera: Zautomatyzowane kontrole dostępności (sprawdzanie statusu HTTP) dla wszystkich aktywnych punktów końcowych resolvera to nie miły dodatek — to operacyjne minimum.
- Prowadź dziennik zmian: Historia audytu w rejestrze jest dostępna dla organów. Uzupełnij ją o wewnętrzny dziennik zmian zawierający uzasadnienia i zatwierdzenia.
- Przeglądaj umowy z dostawcami platform: Jeśli korzystasz z zewnętrznego dostawcy usług DPP, umowa musi wyraźnie obejmować wymóg 10-letniej dostępności — w tym postanowienia na wypadek niewypłacalności lub zamknięcia działalności dostawcy.
27 maja 2026 roku Komisja Europejska przeprowadziła webinarium poświęcone wdrożeniu DPP dla baterii, które wprost odniosło się do wyzwań związanych z utrzymaniem danych, przed jakimi stoją MŚP. Przekaz był jasny: długoterminowa dostępność danych nie jest szczegółem technicznym — jest podstawowym obowiązkiem.
Podsumowanie
Wpis w rejestrze DPP nie jest dokumentem statycznym. Rozporządzenie wykonawcze z kwietnia 2026 roku ustanawia ramy prawne, które wymagają od producentów aktywnego i udokumentowanego utrzymywania swoich danych przez całą dekadę. Dobra wiadomość: centralny rejestr jest celowo utrzymywany w minimalistycznej formie. Jeśli zaprojektujesz punkty końcowe resolvera pod kątem stabilności, użyjesz identyfikatorów zgodnych z GS1 i wbudujesz procesy zmian w swoją organizację, techniczny nakład pracy związany z aktualizacjami pozostanie możliwy do opanowania — a Ty będziesz dobrze przygotowany na nadchodzące standardy ISO/IEC JTC 5.
