Jak zmienić dostawcę DPP bez utraty danych i kodów QR?

Czy przepisy DPP zakładają przenoszalność danych?

ESPR projektuje Digital Product Passport jako interoperacyjny system oparty na otwartych standardach. Motyw 36 wskazuje, że dane powinny być przenoszone przez otwartą, interoperacyjną sieć wymiany bez uzależnienia od jednego dostawcy.

Rozporządzenie ustanawia również wymogi ciągłości:

• art. 10 ust. 4 wymaga udostępnienia kopii zapasowej DPP przez dostawcę usług Digital Product Passport
• art. 11 wymaga interoperacyjności technicznej, semantycznej i organizacyjnej
• DPP ma pozostać dostępny przez okres określony we właściwym akcie delegowanym, także po niewypłacalności, likwidacji lub zakończeniu działalności odpowiedzialnego operatora
• utworzenie nowego DPP dla produktu mającego już paszport wymaga powiązania go z oryginalnym paszportem lub paszportami

Nie oznacza to, że każda platforma oferuje dziś identyczny przycisk eksportu albo że migracja następuje automatycznie. Zakres techniczny, umowa z dostawcą, kontrola domeny i właściwy akt produktowy nadal mają znaczenie.

EN 18221 i EN 18223 – co można powiedzieć na pewno?

Decyzja wykonawcza Komisji (UE) 2026/1736 opublikowała odniesienia do sześciu norm DPP. Dwie są szczególnie istotne dla ciągłości:

• EN 18221:2026 — przechowywanie, archiwizacja i trwałość danych
• EN 18223:2026 — interoperacyjność systemu

Decyzja publikuje numery i tytuły norm oraz wiąże je z odpowiednimi wymaganiami art. 10 i 11 ESPR. Nie opisuje jednak całej zawartości technicznej norm. Dlatego samo posiadanie ZIP-a lub endpointu eksportowego nie wystarcza do deklaracji zgodności z EN 18221 albo EN 18223.

Co powinien zawierać pełny DPP Exit Pack?

Minimalny pakiet migracyjny powinien pozwolić odczytać dane bez aplikacji dotychczasowego dostawcy.

Pakiet powinien zawierać manifest z wersją formatu, datą snapshotu, liczbą obiektów i checksumą każdego pliku. Format danych musi być udokumentowany i maszynowo czytelny. Checksumy pomagają wykryć zmianę pliku, ale same nie są certyfikatem prawnym ani podpisem kwalifikowanym.

Dlaczego eksport CSV nie wystarczy?

Płaski CSV może przenieść bieżące wartości pól, ale zwykle nie zachowuje całego kontekstu:

• rewizji produktu i dat zmian
• profilu wymagań użytego do oceny
• różnicy między draftem i opublikowanym snapshotem
• poziomu dostępu do pola
• powiązań dokumentów z wieloma produktami
• historii korekt i wycofania
• mapowania kodu QR do stabilnego adresu

CSV jest przydatną warstwą kompatybilności, ale powinien być częścią większego pakietu zawierającego JSON, schematy, binarne evidence i manifest integralności.

Co stanie się z istniejącym kodem QR?

Kod QR zazwyczaj zawiera URL. Jeżeli adres należy do domeny starego dostawcy, samo przeniesienie danych nie zmienia wydrukowanego kodu. Firma potrzebuje jednego z mechanizmów:

• utrzymania starego adresu i trwałego przekierowania
• własnej domeny lub subdomeny kontrolowanej przez firmę
• przenośnego resolvera identyfikatorów
• umownego okresu wygaszania po zakończeniu współpracy

Przed migracją trzeba zinwentaryzować każdy payload QR, docelowy adres oraz podmiot kontrolujący domenę. Nowy dostawca nie może zagwarantować ciągłości URL-a, którego nie kontroluje.

Czy trzeba aktualizować DPP Registry?

DPP Registry przechowuje identyfikatory, dane rejestracyjne i metadane wysokiego poziomu, a nie pełną treść DPP. W zależności od obowiązujących reguł migracja może wymagać aktualizacji endpointu, informacji o kopii zapasowej lub innych metadanych.

Exit Pack powinien zawierać identyfikatory i aktualny stan rejestracji, ale sam eksport nie wykonuje zmiany w Registry. Procedurę trzeba potwierdzić w aktualnej dokumentacji Registry oraz właściwych przepisach dla produktu.

Plan migracji dostawcy DPP

1. Zidentyfikuj produkty, poziom DPP i wszystkie publiczne adresy.
2. Zamów pełny eksport oraz słownik formatów i wersji.
3. Zweryfikuj manifest, liczby obiektów i checksumy evidence.
4. Odtwórz pakiet w środowisku testowym nowego dostawcy.
5. Porównaj publiczne snapshoty i prawa dostępu, nie tylko aktualne pola.
6. Przygotuj przekierowania lub przełączenie własnej domeny/resolvera.
7. Potwierdź wymagane zmiany w DPP Registry.
8. Wykonaj test kodów QR dla reprezentatywnych modeli, partii i sztuk.
9. Zachowaj archiwum migracji oraz ślad zatwierdzenia.
10. Dopiero po odbiorze zakończ umowę i wyłącz stare integracje.

Pytania do dostawcy przed podpisaniem umowy

• Czy pełny eksport obejmuje wszystkie wersje DPP, czy tylko stan bieżący?
• W jakim otwartym formacie otrzymam produkty, profile i historię?
• Czy evidence zachowuje oryginalne pliki, metadane i relacje?
• Kto kontroluje domenę oraz publiczny URL umieszczony w kodzie QR?
• Jak długo działają adresy po rozwiązaniu umowy?
• Czy istnieje procedura odtworzenia pakietu u innego dostawcy?
• Jak eksportowane i redagowane są zdarzenia audytowe?
• Jak wygląda aktualizacja Registry i kopii zapasowej?
• Czy można wykonywać okresowe backupy do storage kontrolowanego przez klienta?

DPP Continuity Export w DPP Compliance

Pełny Exit Pack, harmonogram backupów i eksport do storage klienta są zakresem roadmapy, a nie funkcjami dostępnymi obecnie. Dlatego nie używamy jeszcze hasła „No DPP vendor lock-in” jako deklaracji wdrożonej cechy produktu. Już dziś warto jednak stosować powyższą checklistę przy wyborze każdego dostawcy i projektowaniu własnych identyfikatorów oraz adresów DPP.