20 lipca 2026 r. Komisja Europejska uruchomiła rejestr cyfrowych paszportów produktów wraz ze środowiskiem testowym. Tym samym abstrakcyjny wcześniej element ESPR stał się systemem, który firmy mogą rzeczywiście przetestować. Dla producentów szczególnie ważne jest teraz jedno rozróżnienie: rejestr to centralny indeks, natomiast sam paszport produktu pozostaje zdecentralizowany.
Co uruchomiono 20 lipca
Rejestr przechowuje jednoznaczne identyfikatory produktów, dane rejestracyjne i wybrane metadane. Kompletne informacje o produkcie nadal znajdują się u odpowiedzialnego podmiotu gospodarczego lub u wyznaczonego usługodawcy DPP. Dlatego Komisja wyraźnie opisuje rejestr jako usługę indeksowania, a nie centralny system zarządzania treścią.
Rejestracje przewidziano za pośrednictwem zabezpieczonego interfejsu użytkownika oraz API. Firmy mogą również generować elektroniczne potwierdzenie rejestracji. Jest to istotne w procesach B2B, ponieważ dostawcy i klienci mogą w ten sposób wykazać, że paszport został wpisany do systemu UE, bez powielania całego zbioru danych.
Uruchomienie nie dotyczy wyłącznie grup produktów ESPR. Komisja wymienia również baterie, wyroby budowlane, zabawki, detergenty i środki powierzchniowo czynne dla użytkowników końcowych, o ile odpowiednie przepisy unijne wymagają cyfrowego paszportu produktu. Pierwszym wiążącym terminem pozostaje 18 lutego 2027 r. dla określonych baterii.
Rejestr, resolver i źródło danych to trzy różne warstwy
Solidny system DPP powinien wyraźnie rozdzielać zadania:
- Rejestr UE potwierdza, że identyfikator i wymagane metadane zostały zarejestrowane.
- Resolver kieruje trwały identyfikator produktu do odpowiedniego zasobu.
- Właściwe źródło danych dostarcza aktualne treści ludziom i maszynom.
To rozdzielenie nie jest szczegółem. Umieszczenie wszystkich danych wyłącznie na własnej stronie produktu nie oznacza jeszcze integracji z rejestrem. Z drugiej strony samo zarejestrowanie identyfikatora nie zapewnia użytecznego paszportu produktu. Oba elementy trzeba połączyć za pomocą stabilnych identyfikatorów.
Do rozwiązywania identyfikatorów nadaje się otwarty, trwały odnośnik. Resolver tego standardu może udostępniać różne prezentacje na podstawie tego samego identyfikatora: zrozumiałą stronę internetową, odczytywalny maszynowo JSON-LD lub dodatkową dokumentację. Nośnik danych na produkcie lub opakowaniu pozostaje stabilny, nawet gdy systemy docelowe są rozwijane.
Co firmy powinny sprawdzić w środowisku testowym
Środowisko testowe nie służy wyłącznie do ręcznego sprawdzenia kilku kliknięć. Należy traktować je jako etap poprzedzający integrację produkcyjną.
Organizacja i role
Najpierw trzeba ustalić, która jednostka prawna dokonuje rejestracji, kto reprezentuje ją w systemie oraz które zespoły mogą tworzyć lub zmieniać rejestracje. Dotyczy to danych podstawowych, compliance, IT i ewentualnie zewnętrznych usługodawców. Osobiste konto testowe nie zastępuje modelu ról na potrzeby późniejszej eksploatacji.
Identyfikatory i poziom szczegółowości
Zespół produktowy powinien ustalić, czy późniejszy paszport będzie prowadzony na poziomie modelu, partii czy pojedynczego egzemplarza. Odpowiedź zależy od właściwych przepisów sektorowych. Test rejestru to właściwy moment, aby powiązać wewnętrzne identyfikatory produktów, GTIN, oznaczenia partii oraz wykorzystywany zewnętrznie trwały identyfikator.
API i powtarzalność
Proces produkcyjny wymaga czegoś więcej niż udanego żądania POST. Rejestracja, aktualizacja i obsługa błędów muszą być możliwe do powtórzenia i rejestrowane. Obejmuje to żądania idempotentne, techniczne potwierdzenia oraz jednoznaczne powiązanie między rekordem ERP, DPP oraz wpisem w rejestrze. Proces DPP oparty na API ogranicza ręczne rozbieżności, gdy produkty są tworzone w większych ilościach.
Rozdzielenie metadanych i danych merytorycznych
Dane rejestrowe nie powinny stać się drugim zbiorem danych o produktach. Należy określić, które pola są wymagane w rejestrze, a które pozostają w zdecentralizowanym paszporcie. Dla każdej informacji trzeba wskazać źródło nadrzędne, odpowiedzialną jednostkę oraz regułę aktualizacji.
Potwierdzenia i monitoring
Potwierdzenia rejestracji należy przechowywać wraz ze znacznikiem czasu, użytym identyfikatorem i odpowiedzią systemu. Potrzebne jest również uzgadnianie: czy paszport istnieje, czy resolver jest dostępny oraz czy metadane rejestrowe nadal odpowiadają statusowi produktu?
Dlaczego służby celne potrzebują własnego łańcucha kontroli
Rejestr pomaga organom celnym automatycznie sprawdzać przed dopuszczeniem do swobodnego obrotu, czy istnieją ważny zarejestrowany DPP oraz wymagany kod towarowy. Dla importerów oznacza to nową zależność: identyfikator produktu, wpis w rejestrze i zgłoszenie celne muszą być ze sobą zgodne.
Błąd nie ujawni się więc dopiero na stronie produktu. Może wpłynąć na proces graniczny. Firmy powinny już podczas testów symulować przepływy danych od utworzenia produktu po dokumentację importową oraz ustalić, kto może szybko skorygować błędną rejestrację.
Rozsądny 30-dniowy plan testów
- Wybrać rzeczywistą jednostkę prawną i niewielki, reprezentatywny asortyment produktów.
- Dla każdego produktu udokumentować planowany poziom szczegółowości DPP oraz identyfikatory nadrzędne.
- Przeprowadzić pełny proces za pośrednictwem interfejsu użytkownika oraz, jeśli ma to zastosowanie, API.
- Wspólnie zarchiwizować potwierdzenie rejestracji, odpowiedź resolvera i odczytywalne maszynowo dane produktu.
- Przetestować przypadki błędów: zduplikowany identyfikator, nieaktualne metadane, niedostępny host danych i wycofany produkt.
- Na podstawie wyników opracować model operacyjny z odpowiedzialnościami, monitoringiem i drogą eskalacji.
Operacyjne uruchomienie rejestru nie oznacza jeszcze, że wszystkie sektorowe wymagania dotyczące danych już w pełni obowiązują. Przenosi jednak dyskusję z prezentacji na weryfikowalne procesy. Firmy mogą teraz sprawdzić, czy ich identyfikatory, role i interfejsy API są ze sobą zgodne, zanim nadejdą pierwsze obowiązkowe terminy.
