Konteksts: kāpēc vajadzīgs centrāls reģistrs digitālo produktu pasēm?
Digitālā produktu pase (DPP) ir Eiropas Ekodizaina regulas ilgtspējīgiem produktiem (ESPR) stūrakmens; tā ir spēkā kopš 2024. gada jūlija. Tā nosaka ražotājiem pienākumu nodrošināt mašīnlasāmus datu ierakstus arvien plašākam produktu kategoriju lokam — no baterijām un tekstilizstrādājumiem līdz elektronikai. Bet kur tad īsti atrodas atsauces uz šiem ierakstiem? Tieši to risina jaunā īstenošanas regula.
- gada 29. aprīlī Eiropas Komisija publicēja īstenošanas regulas projektu par DPP reģistru, kas pašlaik ir atvērts publiskai apspriešanai. Dokumentā aprakstīts, kā centralizēts reģistrs glabās unikālos produktu identifikatorus un sasaistīs tos ar produktu datiem, kas tiek mitināti decentralizēti. Tā nav pašu produktu datu datubāze — tā ir atsauču katalogs.
Šī arhitektūras izvēle ir apzināta: ES nevēlas izveidot monolītisku datu silosu, bet gan savstarpēji savietojamu ražotāju sistēmu tīklu, ko var atklāt caur koplietojamu centrālo mezglu.
Ko projekts patiesībā prasa
Struktūra: centrāls reģistrs, decentralizēti dati
Projekta pamatprincips ir skaidrs: reģistrs glabā tikai unikālos identifikatorus (UID) un saistītos resolvera galapunktus — proti, URL adreses, no kurām var iegūt faktiskos DPP datus. Paši produktu dati paliek pie ražotāja vai norādītā datu operatora.
Šis modelis konceptuāli ir cieši saskaņots ar GS1 Digital Link — atvērto standartu, kas sasaista GTIN ar strukturētiem tīmekļa URI. Skeneris vai tirgus uzraudzības iestāde var izmantot centrālā reģistra ierakstu, lai atrastu atbildīgo resolveru un no turienes iegūtu pilnos pases datus.
Reģistrācijas pienākumi uzņēmējiem
Projekts nosaka, ka ražotājiem un importētājiem ir pienākums reģistrēt savus produktus reģistrā pirms to laišanas tirgū. Konkrēti, viņiem ir:
- jāiesniedz unikālais produkta identifikators (UID),
- jānorāda resolvera galapunkts (URL), kurā var piekļūt DPP,
- jāsniedz metadati par produkta kategoriju un atbildīgo uzņēmēju.
Reģistrācija veicama, izmantojot standartizētu API, kura tehnisko specifikāciju vēl izstrādā ECLASS un citas standartizācijas iestādes. Projektā ir atsauce uz pašlaik notiekošo CEN/CENELEC JTC 24 darbu, kura uzdevums ir saskaņot datu modeļus.
Piekļuves tiesības un datu aizsardzība
Viens no apspriešanas centrālajiem strīdus jautājumiem, visticamāk, būs par to, kurš drīkst piekļūt kuriem reģistra datiem. Projekts izšķir trīs dalībnieku klases:
| Dalībnieks | Lasīšanas piekļuve | Rakstīšanas piekļuve | Piezīmes |
|---|---|---|---|
| Sabiedrība / patērētāji | Resolvera URL, produkta kategorija | Nē | Nav komerciāli sensitīvu tirdzniecības datu |
| Tirgus uzraudzības iestādes | Pilns ieraksts, ieskaitot metadatus | Nē | Vienots visā ES |
| Uzņēmēji (ražotāji, importētāji) | Savi ieraksti | Jā | Autentifikācija caur EU Login |
Komerciāli sensitīva informācija — piemēram, attiecības ar piegādātājiem vai iepirkuma cenas — reģistrā skaidri netiek glabāta. Tam projekts norāda uz iespēju definēt piekļuves līmeņus (Access Rights) pašā DPP, kā jau paredzēts ESPR deleģētajā regulā par baterijām.
Tehniskās sekas ražotājiem un IT pakalpojumu sniedzējiem
API integrācija un masveida reģistrācija
Uzņēmumiem ar plašu produktu klāstu masveida reģistrācijas jautājums ir kritisks. Projektā ieskicēts REST API, caur kuru UID var iesniegt partijās. Vienkāršots piemērs tam, kā šāds reģistrācijas izsaukums varētu būt strukturēts:
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"
}
}
Pašam UID jāatbilst atzītai identifikācijas sistēmai — projektā skaidri nosaukti GS1 GTIN, kā arī ISO/IEC 15459 atbilstoši kodi. Patentētas sistēmas ir atļautas, taču tām jābūt globāli unikālām un pastāvīgi atrisināmām.
Uzņēmumiem, kas jau strādā ar tādiem rīkiem kā qr3.app Bulk Import, pamatprincips būtiski nemainās: strukturētu CSV vai JSON ar UID un resolvera URL var attēlot uz reģistra API. Patiesais izaicinājums slēpjas pārvaldībā — kurš organizācijā ir atbildīgs par ierakstu uzturēšanu, kad mainās resolvera URL vai produkti tiek izņemti no tirgus?
Dzīves cikla pārvaldība: atsaukšanas un arhivēšana
Projekts pievēršas arī produkta dzīves ciklam pēc laišanas tirgū. Ražotājiem ir pienākums atjaunināt reģistra ierakstus, kad:
- mainās resolvera galapunkts,
- produkts tiek atsaukts (ieraksts tad jāatzīmē kā "recalled", bet ne jādzēš),
- uzņēmums tiek likvidēts vai nodots.
Arhivēšanas pienākums ir noteikts vismaz 10 gadus pēc tam, kad produkts pēdējo reizi laists tirgū — prasība, kas rada īpašu izaicinājumu MVU bez sava IT infrastruktūras.
Laika grafiks un nākamie soļi
Sagaidāms, ka publiskā apspriešana par projektu ilgs līdz 2026. gada jūnija beigām. Komentārus var iesniegt caur ES portālu "Izsakiet viedokli". Komisija ir signalizējusi par nodomu pieņemt galīgo īstenošanas regulu pirms 2026. gada beigām, lai to saskaņotu ar pirmajām produktu specifiskajām ESPR deleģētajām regulām — visupirms par tekstilizstrādājumiem (plānots 2027. gadā).
Bateriju regulai, kas ir saistoša kopš 2024. gada februāra, piemēro īpašu kārtību: bateriju pases sistēma sākotnēji darbojas caur atsevišķu mehānismu, taču vidējā termiņā to paredzēts integrēt centrālajā reģistrā.
Ko uzņēmumiem darīt jau tagad
Lai gan regula vēl nav galīga, ir sagatavošanās soļi, ko varat veikt jau šodien:
- Definējiet savu UID stratēģiju: izlemiet, vai paļauties uz GS1 GTIN vai alternatīvu sistēmu. GS1 Digital Link priekšrocība ir tā, ka identifikators vienlaikus darbojas kā atrisināms tīmekļa URI.
- Izveidojiet savu resolvera infrastruktūru: resolvera galapunktam jābūt pastāvīgi pieejamam un versionētam. Izmantojiet stabilas bāzes URL adreses — nevis dinamiskas īsās URL adreses.
- Definējiet datu uzturēšanas procesus: kurš jūsu organizācijā ir atbildīgs par reģistra atjauninājumiem, kad produkti mainās vai tiek atsaukti?
- Sekojiet līdzi apspriešanai: galīgā regula var atšķirties no projekta — īpaši attiecībā uz API specifikācijām un piekļuves tiesībām.
Novērtējums: ko reģistrs dara — un ko nedara
Centrālais DPP reģistrs nav kvalitātes sertifikāts vai atbilstības novērtējums. Tas ir direktoriju pakalpojums — salīdzināms ar DNS produktu identifikatoriem. Atbildība par DPP datu pareizību paliek uzņēmējiem, un to pārbauda tirgus uzraudzības iestādes.
Nozares kritiķi — tostarp BusinessEurope — jau ir norādījuši, ka centrālā reģistra un decentralizētas datu glabāšanas duālā struktūra palielina atbilstības izmaksas, būtiski neuzlabojot datu aizsardzību. Atbalstītāji, tostarp tādas vides organizācijas kā European Environmental Bureau, savukārt apgalvo, ka tikai centrāls iebraukšanas punkts var nodrošināt izpildāmību no iestāžu puses.
Apspriešanas posms parādīs, vai Komisija paliks pie hibrīdās arhitektūras vai veiks korekcijas. Uzņēmumiem, kas tehnisko sagatavošanos sāk jau tagad, galvenā atziņa ir šāda: pamatprincipi — unikāli identifikatori, stabili resolveri, strukturēti metadati — paliks spēkā neatkarīgi no galīgā regulējuma teksta.
