DPP-Aktualność danych: co naprawdę nakazuje ESPR

Jak często trzeba aktualizować dane DPP? Co dokładnie nakazuje ESPR, gdzie pojawiają się problemy w praktyce i jakie wzorce techniczne się sprawdzają.

autor: QR3 Redaktion

DPP-Aktualność danych: co naprawdę nakazuje ESPR

To pytanie brzmi banalnie, ale takie nie jest: jak często trzeba aktualizować Cyfrowy Paszport Produktu? Kto w ESPR-rozporządzeniu (UE) 2024/1781 szuka konkretnej liczby, będzie rozczarowany. Tekst nakazuje jedynie, aby DPP zawierał „aktualne i dokładne informacje” – bez określenia częstotliwości, bez SLA i bez specyfikacji technicznej. To, co oznacza to w praktyce, w dużej mierze zależy od rodzaju produktu, łańcucha dostaw oraz aktów delegowanych, które dopiero zostaną wydane dla poszczególnych kategorii produktów.

W tym artykule wyjaśniamy, które kategorie danych w ogóle mogą się zmieniać, jakie wzorce aktualizacji sprawdzają się we wczesnych wdrożeniach oraz gdzie czyhają pułapki regulacyjne.


Co w ogóle może się zmieniać w DPP

Paszport produktu nie jest statycznym plikiem PDF. Składa się z punktów danych o bardzo różnych cyklach życia.

Dane statyczne a dynamiczne

Z grubsza DPP-pola można podzielić na trzy klasy:

Kategoria danych Typowa częstotliwość zmian Przykłady
Dane podstawowe Jednorazowo (przy wprowadzeniu produktu) GTIN, skład materiałowy, producent
Dane partii/serii Dla każdej serii produkcyjnej Wartość PCF, pochodzenie surowców, certyfikaty
Dane cyklu życia Sterowane zdarzeniami Historia napraw, wycofanie produktu, sposób utylizacji

Projekt danych JRC dla produktów stalowych szczególnie wyraźnie pokazuje tę różnicę: specyficzny dla produktu ślad węglowy (PCF) jest tam wyraźnie prowadzony na poziomie partii i musi być obliczany metodami zgodnymi z ISO 14067. Oznacza to, że każda nowa partia produkcyjna może mieć inną wartość PCF – paszport musi prawidłowo odwoływać się do tej wartości, a nie do średniej z poprzedniego roku.

Przykład baterii jako wzorzec

Cyfrowy Paszport Baterii, który będzie obowiązkowy od 18 lutego 2027 r., pokazuje, jak dynamiczne mogą być dane DPP. Raporty branżowe dotyczące wdrażania Cyfrowego Paszportu Baterii wskazują fragmentację danych i dynamiczne aktualizacje danych jako dwa najważniejsze problemy praktyczne. W całym cyklu życia baterie gromadzą dane: stan zdrowia (SoH), cykle ładowania, zdarzenia naprawcze. Kto pracuje tu ze statycznym zbiorem danych, nie spełnia wymogów rozporządzenia.


Wzorce aktualizacji: jak działają dziś wdrożenia

Aktualizacje sterowane zdarzeniami za pośrednictwem webhooka

Najbardziej niezawodnym wzorcem we wczesnych systemach DPP jest aktualizacja sterowana zdarzeniami: system backendowy wysyła webhook, gdy tylko zmieni się istotny punkt danych – na przykład gdy zostanie wydany nowy certyfikat kontroli lub zakończy się naprawa.

// Beispiel: Webhook-Handler für DPP-Update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Ważne: ESPR pośrednio wymaga możliwości prowadzenia ścieżki audytu. Zmiany muszą pozostać możliwe do prześledzenia – proste nadpisywanie bez wersjonowania wiąże się z ryzykiem regulacyjnym.

Aktualizacje wsadowe informacji o partiach

Gdy wartości PCF lub certyfikaty są aktualizowane jednocześnie dla całych partii produkcyjnych, warto zastosować procedurę importu zbiorczego. Przekazuje się wówczas listę numerów paszportów wraz z nową wartością pola:

# Beispiel: Bulk-PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Platformy takie jak qr3.app z importem zbiorczym obsługują ten wzorzec, dzięki czemu nie trzeba ręcznie aktualizować każdej partii.

Często niedoceniany aspekt: kod QR na produkcie nie może się zmieniać – jest fizycznie nadrukowany. Zmienić musi się treść, do której prowadzi. Właśnie tutaj GS1 Digital Link zapewnia kluczową warstwę abstrakcji. Kod QR koduje stabilny identyfikator URI (np. https://id.example.com/01/04012345678901/21/SN-00042), a resolver przekierowuje do aktualnego źródła danych.

Firma Driscoll's pokazała podczas GS1 Connect 2026, jak ta zasada działa na dużą skalę: ponad miliard opakowań typu Berry Clamshell otrzymało unikalne identyfikatory i jest obecnie migrowane na w pełni zgodne z GS1 Digital Link kody QR. Kod na opakowaniu pozostaje bez zmian; zmienia się zbiór danych za resolverem.

Nowe technologie, takie jak partnerstwo Polytag i DataLase, pokazują, że kody QR zgodne z GS1 można obecnie nanosić także na trudne podłoża opakowaniowe z prędkością linii produkcyjnej – bariera fizyczna maleje, a stojąca za nią logika resolvera pozostaje taka sama.


Pułapki regulacyjne

Dyrektywa EmpCo jako dodatkowa presja

Kto sądzi, że musi obserwować wyłącznie ESPR, nie docenia pełnego obrazu. W czerwcu 2026 r. Komisja Europejska wszczęła postępowania w sprawie uchybienia zobowiązaniom państwa członkowskiego wobec 20 państw z powodu niewłaściwego wdrożenia dyrektywy EmpCo (UE) 2024/825. Dyrektywa ta zakazuje greenwashingu i wymaga jasnych informacji o trwałości oraz możliwości naprawy – informacji, które mają bezpośrednio trafiać do DPP. Nieaktualne wskaźniki naprawialności lub nieważne etykiety zrównoważonego rozwoju w paszporcie mogą zatem stanowić nie tylko naruszenie ESPR, lecz także naruszenie EmpCo.

Brak wyraźnego terminu aktualizacji – ale obowiązki dorozumiane

Brak informacji o częstotliwości w ESPR nie jest przyzwoleniem na dowolność. Ze sformułowania „aktualne i dokładne informacje” można wywieść kilka obowiązków dorozumianych:

  • Aktualność związana ze zdarzeniami: Gdy tylko nastąpi wycofanie produktu, naprawa lub zmiana certyfikatu, paszport musi zostać zaktualizowany – bez zwłoki.
  • Aktualność związana z partią: Wartości PCF i dowody pochodzenia surowców nie mogą być przenoszone ze starej partii na nową, jeśli wartości się różnią.
  • Zgodność z nadzorem rynku: Organy muszą mieć możliwość uzyskania dostępu do paszportu przez cały cykl życia produktu. Paszport, który po sprzedaży nigdy nie jest aktualizowany, jest bezwartościowy w zakresie informacji o naprawach i utylizacji.

Ecommerce Europe zaleca w swoim stanowisku wyraźnie etapowe wdrażanie i elastyczną szczegółowość danych – co pośrednio oznacza, że procesy aktualizacji można budować iteracyjnie, o ile spełnione są podstawowe wymagania.


Praktyczne zalecenia

Od początku zaplanować dziennik audytu

Każda zmiana w rekordzie danych DPP powinna być rejestrowana wraz ze znacznikiem czasu, autorem i powodem zmiany. Dziś nie jest to wyraźny obowiązek ESPR, ale będzie oczekiwane w aktach delegowanych i jest faktycznie niezbędne do nadzoru rynku.

Architektura resolvera przed architekturą danych

Kto najpierw ustala strukturę danych, a dopiero potem zastanawia się, jak skierować na nią kod QR, buduje system w niewłaściwej kolejności. Prawidłowa kolejność to: zdefiniować URI resolvera (GS1 Digital Link), następnie schemat danych, a potem procesy aktualizacji. Cyfrowy Paszport Produktu na qr3.app działa zgodnie z tą zasadą: kod QR jest stabilny, a znajdujący się za nim rekord danych jest wersjonowany i można go aktualizować za pomocą poprawek.

Konsekwentnie stosować identyfikatory partii

Kto prowadzi wartości PCF lub certyfikaty na poziomie produktu zamiast na poziomie partii, najpóźniej podczas pierwszej kontroli rynku napotka problemy. Identyfikator partii powinien być obowiązkowym polem w każdym rekordzie danych DPP – a nie opcjonalnym polem metadanych.

Sytuacja regulacyjna jest złożona, ale wzorce techniczne można opanować. Kluczowe jest, aby nie traktować możliwości aktualizacji jako funkcji dodanej po fakcie, lecz jako zasadę architektoniczną od pierwszego dnia.

Źródła