Europos Komisija pateikė konsultacijoms reglamento projektą dėl centrinio DPP registro

Kontekstas: kodėl reikia centrinio skaitmeninių produktų pasų registro?

Skaitmeninis produkto pasas (DPP) yra Europos Tvarių produktų ekologinio projektavimo reglamento (ESPR), galiojančio nuo 2024 m. liepos mėn., kertinis akmuo. Jis įpareigoja gamintojus pateikti mašininiu būdu nuskaitomus duomenų įrašus vis didesniam produktų kategorijų skaičiui — nuo baterijų ir tekstilės iki elektronikos. Bet kur iš tikrųjų saugomos nuorodos į šiuos įrašus? Būtent tai ir sprendžia naujasis įgyvendinimo reglamentas.

2026 m. balandžio 29 d. Europos Komisija paskelbė įgyvendinimo reglamento dėl DPP registro projektą, kuris dabar pateiktas viešoms konsultacijoms. Dokumente aprašoma, kaip centralizuotame registre bus saugomi unikalūs produkto identifikatoriai ir kaip jie bus susiejami su decentralizuotai talpinamais produkto duomenimis. Tai nėra pačių produkto duomenų duomenų bazė — tai nuorodų katalogas.

Šis architektūrinis sprendimas yra apgalvotas: ES nenori kurti monolitinės duomenų saugyklos, o veikiau sąveikų gamintojų sistemų tinklą, kurį būtų galima atrasti per bendrą centrinį mazgą.

Ką iš tikrųjų reikalauja projektas

Struktūra: centrinis registras, decentralizuoti duomenys

Pagrindinis projekto principas yra aiškus: registre saugomi tik unikalūs identifikatoriai (UID) ir su jais susieti resolverio (angl. resolver) galiniai taškai — tai yra URL adresai, kuriais galima gauti tikruosius DPP duomenis. Patys produkto duomenys lieka pas gamintoją arba paskirtą duomenų operatorių.

Šis modelis konceptualiai glaudžiai susijęs su GS1 Digital Link — atviru standartu, susiejančiu GTIN su struktūruotais žiniatinklio URI. Skaitytuvas arba rinkos priežiūros institucija gali pasinaudoti centrinio registro įrašu, kad surastų atsakingą resolverį ir iš jo gautų visus paso duomenis.

Registravimo prievolės ūkio subjektams

Projekte nustatyta, kad gamintojai ir importuotojai privalo užregistruoti savo produktus registre prieš pateikdami juos rinkai. Konkrečiai jie turi:

pateikti unikalų produkto identifikatorių (UID),
nurodyti resolverio galinį tašką (URL), kuriuo pasiekiamas DPP,
pateikti metaduomenis apie produkto kategoriją ir atsakingą ūkio subjektą.

Registracija turi būti vykdoma per standartizuotą API, kurios techninę specifikaciją vis dar rengia ECLASS ir kitos standartizacijos institucijos. Projekte remiamasi vykstančiu CEN/CENELEC JTC 24 darbu, kuriam pavesta suderinti duomenų modelius.

Prieigos teisės ir duomenų apsauga

Vienas iš pagrindinių ginčytinų klausimų konsultacijose tikriausiai bus tas, kas gali turėti prieigą prie kurių registro duomenų. Projekte skiriamos trys subjektų klasės:

Subjektas	Skaitymo prieiga	Rašymo prieiga	Pastabos
Visuomenė / vartotojai	Resolverio URL, produkto kategorija	Ne	Jokių komerciškai jautrių prekybos duomenų
Rinkos priežiūros institucijos	Visas įrašas, įskaitant metaduomenis	Ne	Vienodai visoje ES
Ūkio subjektai (gamintojai, importuotojai)	Savo įrašai	Taip	Autentifikavimas per EU Login

Komerciškai jautri informacija — pavyzdžiui, ryšiai su tiekėjais ar pirkimo kainos — registre neturi būti saugoma. Šiuo tikslu projekte nurodoma galimybė apibrėžti prieigos lygius (Access Rights) pačiame DPP, kaip jau numatyta ESPR deleguotajame reglamente dėl baterijų.

Techninės pasekmės gamintojams ir IT paslaugų teikėjams

API integracija ir masinis registravimas

Įmonėms, turinčioms didelius produktų portfelius, masinio registravimo klausimas yra itin svarbus. Projekte aprašoma REST API, per kurią UID galima pateikti partijomis. Supaprastintas pavyzdys, kaip galėtų atrodyti toks registravimo iškvietimas:

POST /registry/v1/products
Content-Type: application/json
Authorization: Bearer <EU-Login-Token>

{
  "uid": "https://id.gs1.org/01/04012345678901/21/ABC123",
  "resolverEndpoint": "https://dpp.example.com/resolver",
  "productCategory": "ESPR:TextileUpperGarment",
  "economicOperator": {
    "eori": "DE123456789",
    "name": "Muster GmbH"
  }
}

Pats UID turi atitikti pripažintą identifikavimo sistemą — projekte aiškiai įvardijami GS1 GTIN, taip pat ISO/IEC 15459 atitinkantys kodai. Nuosavos sistemos leidžiamos, tačiau jos turi būti globaliai unikalios ir nuolat pasiekiamos per resolverį.

Įmonėms, jau dirbančioms su tokiais įrankiais kaip qr3.app Bulk Import, pagrindinis principas reikšmingai nesikeičia: struktūruotą CSV arba JSON UID ir resolverio URL paketą galima susieti su registro API. Tikrasis iššūkis slypi valdysenoje — kas organizacijoje atsako už įrašų tvarkymą, kai keičiasi resolverio URL arba produktai pašalinami iš rinkos?

Gyvavimo ciklo valdymas: atšaukimai ir archyvavimas

Projekte taip pat sprendžiamas produkto gyvavimo ciklo klausimas po pateikimo rinkai. Gamintojai privalo atnaujinti registro įrašus, kai:

pasikeičia resolverio galinis taškas,
produktas atšaukiamas (tada įrašas turi būti pažymėtas kaip „atšauktas", bet ne ištrintas),
įmonė likviduojama arba perduodama.

Archyvavimo prievolė nustatyta bent 10 metų po to, kai produktas paskutinį kartą buvo pateiktas rinkai — reikalavimas, keliantis ypatingą iššūkį MVĮ, neturinčioms savo IT infrastruktūros.

Tvarkaraštis ir tolesni žingsniai

Numatoma, kad viešos konsultacijos dėl projekto truks iki 2026 m. birželio pabaigos. Pastabas galima teikti per ES portalą „Išsakykite savo nuomonę" (Have Your Say). Komisija nurodė ketinanti priimti galutinį įgyvendinimo reglamentą iki 2026 m. pabaigos, kad jis derėtų su pirmaisiais konkretiems produktams skirtais ESPR deleguotaisiais reglamentais — visų pirma dėl tekstilės (planuojama 2027 m.).

Baterijų reglamentui, privalomam nuo 2024 m. vasario mėn., taikoma speciali tvarka: baterijų paso sistema iš pradžių veikia per atskirą mechanizmą, tačiau vidutiniu laikotarpiu ją ketinama integruoti į centrinį registrą.

Ką įmonės turėtų daryti jau dabar

Nors reglamentas dar nėra galutinis, jau šiandien galite imtis parengiamųjų žingsnių:

Apibrėžkite savo UID strategiją: nuspręskite, ar remtis GS1 GTIN, ar alternatyvia sistema. GS1 Digital Link pranašumas yra tas, kad identifikatorius kartu veikia ir kaip per resolverį pasiekiamas žiniatinklio URI.
Sukurkite savo resolverio infrastruktūrą: resolverio galinis taškas turi būti nuolat pasiekiamas ir versijuojamas. Naudokite stabilius baziniai URL — ne dinaminius trumpuosius URL.
Apibrėžkite duomenų priežiūros procesus: kas jūsų organizacijoje atsako už registro atnaujinimus, kai produktai keičiasi arba atšaukiami?
Stebėkite konsultacijas: galutinis reglamentas gali skirtis nuo projekto — ypač API specifikacijų ir prieigos teisių požiūriu.

Vertinimas: ką registras daro — ir ko nedaro

Centrinis DPP registras nėra kokybės sertifikatas ar atitikties įvertinimas. Tai katalogo paslauga — panaši į DNS, skirtą produktų identifikatoriams. Už DPP duomenų tikslumą ir toliau atsako ūkio subjektai, o juos tikrina rinkos priežiūros institucijos.

Pramonės kritikai — įskaitant BusinessEurope — jau pastebėjo, kad dvejopa centrinio registro ir decentralizuoto duomenų saugojimo struktūra didina atitikties sąnaudas reikšmingai negerindama duomenų apsaugos. Šalininkai, įskaitant aplinkosaugos organizacijas, tokias kaip European Environmental Bureau, savo ruožtu teigia, kad tik centrinis prieigos taškas gali užtikrinti, jog institucijos galės užtikrinti reikalavimų vykdymą.

Konsultacijų etapas atskleis, ar Komisija laikysis hibridinės architektūros, ar atliks pakeitimų. Įmonėms, jau dabar pradedančioms techninį pasirengimą, svarbiausia išvada yra tokia: pamatiniai principai — unikalūs identifikatoriai, stabilūs resolveriai, struktūruoti metaduomenys — liks galioti nepriklausomai nuo galutinio reglamento teksto.