Wymogi dla dostawców usług DPP: zasady UE dotyczące platform

Aktualizacja redakcyjna, 20 lipca 2026 r.: Rejestr produkcyjny, środowisko testowe i pierwszy publiczny przewodnik są już dostępne, lecz przewodnik obejmuje wyłącznie podmiotów gospodarczych. Nie zawiera ścieżki rejestracji dostawcy usług, procedury certyfikacji, publicznej listy dostawców ani pełnej specyfikacji metod API. Rozporządzenie (UE) 2026/1778 wymaga listy zweryfikowanych dostawców usług DPP, ale chodzi o weryfikację tożsamości i dostępu do funkcji Rejestru, nie o certyfikację, akredytację ani przejęcie odpowiedzialności wynikającej z prawa produktowego.

Dlaczego warstwa usługowa ma znaczenie

Wiele firm wciąż myśli o Cyfrowym Paszporcie Produktu na poziomie widocznym: dane produktowe, kody QR, strony dla konsumentów, oświadczenia zgodności.

Tymczasem dla UE to tylko część obrazu. Istnieje również warstwa infrastrukturalna: systemy i dostawcy usług, którzy przechowują, zarządzają, udostępniają, zabezpieczają i utrzymują rekordy DPP w czasie.

Dlatego Komisja Europejska przygotowuje akt delegowany skierowany specjalnie do dostawców usług DPP.

Dla platform programistycznych ma to bezpośrednie znaczenie. Sugeruje, że dostawcy DPP mogą stać się czymś więcej niż zwykłymi dostawcami SaaS. Mogą stać się regulowaną lub częściowo regulowaną częścią ekosystemu DPP, od której oczekuje się przenoszalności, zarządzania, ciągłości i niezawodnego dostępu do danych produktowych.

Co Komisja chce uregulować

Inicjatywa Komisji dotycząca dostawców usług DPP wskazuje, że chce uzyskać informacje zwrotne na temat sposobu przechowywania danych i zarządzania nimi przez dostawców usług oraz potrzeby systemu certyfikacji.

To kluczowe sformułowanie, ponieważ pokazuje, że problem nie sprowadza się do użyteczności interfejsu czy generowania kodów QR. Prawdziwe pytania mają charakter architektoniczny:

• kto kontroluje dane
• jak są przechowywane
• kto ma do nich dostęp
• jak zapewnia się ich dostępność w czasie
• czy dostawcy usług potrzebują formalnej kwalifikacji lub certyfikacji

Ostateczny akt nie został jeszcze przyjęty, ale kwestie dotyczące zarządzania są już jasno określone.

Zakres prawny jest węższy niż debata polityczna

Art. 11 ust. 2 ESPR wyraźnie upoważnia Komisję do określenia w akcie delegowanym trzech kwestii:

1. wymogów, które podmioty muszą spełnić, aby zostać dostawcami usług DPP;
2. w stosownych przypadkach systemu certyfikacji służącego weryfikacji spełnienia tych wymogów wejścia; oraz
3. wymogów, które dostawcy muszą spełniać podczas świadczenia usług DPP.

Tylko ten zakres można bezpiecznie przedstawiać jako przesądzony. Motyw 40 zawiera niewiążącą, lecz istotną wskazówkę: przewiduje jaśniejsze role i obowiązki agencji wydających oraz dostawców usług przy tworzeniu, uwierzytelnianiu, przetwarzaniu i przechowywaniu danych DPP, a być może także przy wycofywaniu ważnych elementów DPP, takich jak identyfikatory i nośniki danych. Sam motyw nie nakłada jednak tych szczegółowych obowiązków ani nie gwarantuje, że każdy z nich znajdzie się w ostatecznym akcie.

Dokładne kryteria kwalifikacji, obowiązki usługowe i ewentualny mechanizm certyfikacji nie zostały opublikowane. Przenoszalność, ciągłość, cyberbezpieczeństwo, interoperacyjność i rozdzielenie ról są dobrze udokumentowanymi zagadnieniami wdrożeniowymi, ale materiały konsultacyjne przedstawiają warianty przyszłych rozwiązań, a nie ostateczną normę.

ESPR ustanawia już część podstawowych zasad: DPP może być przechowywany przez podmiot gospodarczy lub dostawcę usług; projekt musi zapewniać wysoki poziom bezpieczeństwa i prywatności; dostawca nie może sprzedawać, ponownie wykorzystywać ani przetwarzać danych DPP poza zakresem niezbędnym do świadczenia usługi, chyba że podmiot gospodarczy wyraźnie na to zezwolił; a art. 10 ust. 4 wymaga kopii zapasowej za pośrednictwem dostawcy usług DPP. Motyw 38 opisuje dostawcę kopii zapasowej jako niezależną stronę trzecią. Akt delegowany ma uszczegółowić zarządzanie dostawcami, a nie tworzyć te obowiązki od zera.

Najnowszy portal Komisji dotyczący DPP umieszcza akt o dostawcach w 2027 r., ale obecnie wymienia go dwukrotnie, raz w II, a raz w III kwartale. Dopóki Komisja nie usunie tej niespójności albo nie opublikuje projektu, rok jest użytecznym sygnałem planistycznym, lecz kwartał nie.

Co wnosi obecnie rozporządzenie dotyczące Rejestru

Przyjęte rozporządzenie dotyczące Rejestru nie rozstrzyga przyszłego reżimu dostawców, ale usuwa jedną ważną niejasność.

• Rejestr będzie zawierał listę zweryfikowanych dostawców usług DPP. Nie należy nazywać jej unijną listą certyfikowanych podmiotów: weryfikacja dotyczy dostępu do funkcji Rejestru, a nie stwierdzenia spełnienia wszystkich przyszłych wymogów operacyjnych.
• Kwalifikujący się dostawca działający w łańcuchu wartości musi zostać zweryfikowany, aby tworzyć lub zmieniać rejestracje. W odpowiednich przypadkach Rejestr sprawdza również odwołanie do dostawcy kopii zapasowej.
• Rozporządzenie tworzy maszynowo czytelne repozytorium semantyczne z udokumentowanymi interfejsami API i wspólnymi formatami. Wspiera to interoperacyjność, pozostawiając ostateczne zasady zarządzania właściwe dla dostawców odrębnemu aktowi delegowanemu.
• Podmiot gospodarczy nadal odpowiada za poprawność danych DPP i danych rejestracyjnych. Zweryfikowana platforma może wykonywać prace techniczne bez przejmowania tej odpowiedzialności prawnej.

To rozróżnienie ma znaczenie w zakupach: należy pytać, czy dostawca obsługuje weryfikację, wersjonowanie, interoperacyjność semantyczną i eksport danych, ale nie należy akceptować deklaracji „dostawcy DPP certyfikowanego przez UE”, dopóki przyszły prawny system certyfikacji rzeczywiście jej nie uzasadni.

Co jest już widoczne z dotychczasowego procesu

1. Rola dostawcy usług jest oddzielana od roli właściciela produktu

Producenci, importerzy i inne podmioty gospodarcze pozostają odpowiedzialni za zgodność produktu. Dostawca usług pełni inną rolę: zapewnia infrastrukturę umożliwiającą praktyczne funkcjonowanie DPP.

To rozróżnienie jest ważne, ponieważ sugeruje jasne granice między:

• odpowiedzialnością za zgodność
• własnością danych
• obsługą techniczną
• długoterminową ciągłością rejestrów

Uwaga dla paszportu baterii: rozporządzenie o bateriach używa innej konstrukcji niż przyszła rola usługodawcy ESPR DPP. Komisja potwierdziła w maju 2026 r., że chodzi tam o upoważnionych operatorów działających w imieniu odpowiedzialnego podmiotu gospodarczego, więc nie należy automatycznie przenosić tej etykiety na każdy model platformowy. W praktyce odpowiedzialny podmiot gospodarczy nadal odpowiada za paszport baterii. Upoważniony operator może wspierać obsługę techniczną lub organizacyjną w jego imieniu, ale nie przejmuje odpowiedzialności ani nie jest tym samym pojęciem co przyszły usługodawca ESPR DPP.

2. Zarządzanie staje się wymaganiem pierwszej klasy

Inicjatywa nie pyta, czy platformy powinny dbać o zarządzanie. Zakłada, że zarządzanie ma znaczenie, i pyta, jaki model powinien obowiązywać.

3. Przenoszalność wyłania się jako kluczowe oczekiwanie projektowe

Zapis konsultacji silnie sugeruje, że systemy DPP nie powinny być projektowane wokół trwałego uzależnienia od jednego dostawcy. To wskazuje, że otwarte struktury, możliwość eksportu i logika zmiany dostawcy powinny być podstawą projektową platform.

4. Kopie zapasowe i ciągłość nie są kwestiami drugorzędnymi

Długoterminowa dostępność danych DPP jest centralnym tematem debaty. Platformy skupione wyłącznie na bieżącej prezentacji produktów mogą nie sprostać wymogom regulacyjnym, jeśli zasady ciągłości kopii zapasowych zostaną bardziej sformalizowane.

Cztery obszary projektowe, na które platformy powinny się przygotować

Nawet przed finalizacją aktu delegowanego jest widoczny użyteczny model przygotowawczy.

1. Jasna własność danych i granice zarządzania

Najłatwiej uzasadnić architekturę, w której podmiot gospodarczy zachowuje kontrolę nad danymi produktowymi, a dostawca zapewnia obsługującą je warstwę usługową.

Poważna platforma powinna już teraz wyjaśnić:

• kto jest właścicielem danych
• kto może je edytować
• jak śledzone są zmiany
• jak eksportowane są rejestry
• co się dzieje po zakończeniu relacji usługowej

Jeśli platforma nie potrafi tego jasno wyjaśnić, jest już słaba z perspektywy zarządzania.

2. Interoperacyjność i ochrona przed uzależnieniem

To najsilniejszy punkt konsensusu w zapisie konsultacji.

Dla platform interoperacyjność nie powinna być traktowana jako miły dodatek, lecz kształtować podstawowy model:

• identyfikatory powinny pozostać przenoszalne
• rejestry powinny być eksportowalne w użytecznym, ustrukturyzowanym formacie
• systemy powinny unikać zależności własnościowych utrudniających migrację
• zmiana dostawcy nie powinna zmuszać firm do odbudowy fundamentów danych produktowych od zera

Przenośna architektura jest rozwiązaniem przygotowawczym o niższym ryzyku, lecz dokładne obowiązki przy zmianie dostawcy określi dopiero akt delegowany.

3. Logika kopii zapasowych i planowanie ciągłości

Debata o dostawcach usług DPP wielokrotnie wraca do kopii zapasowych, ciągłości i pytania o to, co się dzieje po zniknięciu pierwotnego dostawcy.

Platformy powinny już teraz myśleć w kategoriach:

• aktywne udostępnianie danych a usługa obejmująca wyłącznie kopię zapasową
• migawki danych a logika kopii ciągłości
• warunki udostępnienia danych
• identyfikowalne przechowywanie ostatniego prawidłowego rekordu produktu

Nie każdy ostateczny szczegół jest znany, ale wymóg poważnego podejścia do ciągłości już istnieje.

4. Kontrola dostępu i obsługa danych zastrzeżonych

DPP to nie tylko publiczna strona internetowa dla konsumentów. Wiele rejestrów DPP będzie zawierać warstwy danych z różnymi prawami dostępu.

Platformy powinny zatem być gotowe do obsługi:

• informacji skierowanych do opinii publicznej
• zastrzeżonych danych B2B
• warstw dostępu dla organów nadzoru
• możliwości prześledzenia dostępu i zmian

To jeden z najwyraźniejszych sygnałów, że platformy DPP są bliżej regulowanej infrastruktury niż zwykłych narzędzi do zarządzania treścią.

Certyfikacja: co wiadomo, a czego nie

Certyfikacja to jedno z najważniejszych otwartych pytań w debacie o dostawcach usług.

Co jest już wiadome

• Komisja wprost zapytała, czy potrzebny jest system certyfikacji
• część interesariuszy zdecydowanie popiera niezależną certyfikację ex ante
• inni opowiadają się za lżejszymi lub bardziej elastycznymi modelami
• dojrzałość w zakresie bezpieczeństwa i zarządzania już jest widoczna jako istotne oczekiwanie

Czego jeszcze nie wiadomo

• czy certyfikacja będzie obowiązkowa dla wszystkich dostawców usług
• jaki organ lub proces będzie oceniać dostawców
• czy ostateczny model będzie rozróżniać poszczególne role dostawców
• jak obciążający może być proces dla mniejszych firm programistycznych

Praktyczny wniosek dla platform jest prosty: buduj tak, jakbyś mógł w przyszłości musieć wykazać uporządkowane zarządzanie, możliwość prześledzenia zmian, niezawodność i dojrzałość w zakresie bezpieczeństwa.

Dlaczego zdecentralizowana architektura stale powraca w dyskusji

Jednym z najsilniejszych sygnałów projektowych w odpowiedziach konsultacyjnych jest poparcie dla zdecentralizowanego zarządzania.

Nie oznacza to, że każdy system DPP trzeba utrzymywać samodzielnie lub w pełni rozproszyć technicznie. Interesariusze chcą jednak uniknąć modelu, w którym jeden dostawca staje się nieuniknionym i nieprzejrzystym dysponentem danych produktowych firmy.

Dla platform sugeruje to podejście bardziej odporne:

• klient jest właścicielem danych produktowych
• dostawca obsługuje warstwę usługową
• eksporty i przenoszalność są normą, nie wyjątkiem
• ciągłość kopii zapasowych nie oznacza dominacji dostawcy nad całym ekosystemem danych

To dobrze wpisuje się w szerszą preferencję UE dla otwartych standardów i interoperacyjnej infrastruktury cyfrowej.

Co platformy powinny budować w 2026 roku: jeszcze przed przyjęciem ostatecznego aktu

Najbardziej przydatne kroki przygotowawcze to te, które pozostają wartościowe przy wielu możliwych ostatecznych rozwiązaniach prawnych.

1. Ustrukturyzowane eksporty

Jeśli klient odejdzie, zmieni dostawcę lub będzie musiał spełnić nowe wymogi zarządzania, rekord musi być przenoszalny w praktyce, nie tylko w teorii.

2. Identyfikowalna historia audytu

Platformy powinny zakładać, że zdolność wykazania kto zmienił co, kiedy i na jakiej podstawie będzie zyskiwać na znaczeniu.

3. Logika dostępu oparta na rolach

Nawet jeśli ostateczny akt delegowany doprecyzuje model, zróżnicowany dostęp już teraz stanowi rozsądny wymóg przyjmowany na etapie projektowania.

4. Jasna polityka ciągłości

Platformy powinny zdefiniować, co dzieje się z rejestrami, gdy konto klienta zostaje zamknięte, relacja z dostawcą się kończy lub uruchamiane są obowiązki ciągłości.

5. Otwarte wybory architektoniczne

Systemy zaprojektowane wokół otwartych identyfikatorów, ustrukturyzowanych rejestrów i logiki migracji są lepiej pozycjonowane niż systemy zaprojektowane wokół zależności i nieprzejrzystości.

O co powinny pytać firmy kupujące dostęp do platformy DPP

Ten artykuł jest skierowany nie tylko do twórców oprogramowania. Dotyczy również producentów, importerów i właścicieli marek oceniających dostawców.

Przydatne pytania obejmują:

• Jak traktujecie własność danych?
• Czy rejestry mogą być eksportowane w formacie ustrukturyzowanym?
• Jakie macie podejście do kopii zapasowych i ciągłości?
• Jak rozdzielacie dane publiczne od zastrzeżonych?
• Jak projektujecie system pod kątem interoperacyjności?
• Co się stanie, jeśli będziemy chcieli zmienić dostawcę w przyszłości?

To nie są już niszowe pytania zakupowe. Dotyczą sedna wiarygodności architektury DPP oferowanej przez dostawcę.

Podsumowanie strategiczne

Ostateczny akt delegowany dotyczący dostawców usług DPP nie został jeszcze przyjęty. Kierunek prac jest jednak wystarczająco wyraźny, by na jego podstawie podejmować praktyczne decyzje.

Najbardziej odporna platforma DPP nie będzie prawdopodobnie oparta na nieprzejrzystości, barierze wyjścia i słabej logice ciągłości. Silniejszy model jest zbudowany wokół:

• przejrzystego zarządzania
• eksportowalnych, ustrukturyzowanych rejestrów
• interoperacyjności
• dostępu opartego na rolach
• dyscypliny kopii zapasowych i ciągłości

Firmy nie muszą czekać na każdy szczegół techniczny, by już teraz korzystać z tych kryteriów.

Czytaj dalej

• Kto może świadczyć usługi DPP? Wymogi UE dla dostawców
• Czym jest Cyfrowy Paszport Produktu (DPP)?
• Wymagania danych DPP: jakie dane naprawdę potrzebujesz
• Status wdrożenia ESPR i DPP w 2026 roku

Źródła oficjalne

• Inicjatywa Komisji Europejskiej: Cyfrowy paszport produktu: zasady dla dostawców usług
• Odpowiedź Komisji dla PE E-000888/2026(ASW): operatorzy baterii a usługodawcy ESPR DPP
• Rozporządzenie ESPR (UE) 2024/1781
• Rozporządzenie wykonawcze Komisji (UE) 2026/1778 (Rejestr DPP)
• Komisja Europejska: Rejestr DPP
• Komisja Europejska: portal Cyfrowego Paszportu Produktu i orientacyjny harmonogram
• Portal „Have Your Say” Komisji Europejskiej

---

Jeśli platformy DPP zmierzają ku silniejszym wymogom zarządzania, przenoszalności i ciągłości, warto współpracować z dostawcą, który od początku śledzi te kwestie. OriginPass traktuje dane produktowe jako ustrukturyzowaną i przenoszalną infrastrukturę, a nie tylko jako strony paszportów cyfrowych.