Jaunais praktiskais šķērslis: kam ir tiesības reģistrēt pasi?
ES DPP-reģistrs darbojas kopš 2026. gada 20. jūlija. Daudzām komandām sākotnēji galvenais bija tehniskais jautājums: vai produkta identifikatoru var reģistrēt un vai datu nesējs pareizi novirza uz vajadzīgo informāciju? Tas ir nepieciešams, bet nepietiekami. Ar Īstenošanas regulu (ES) 2026/1778 (2026. gada 16. jūlijs) iepriekšējā identitāte iegūst patstāvīgu regulatīvu nozīmi: reģistrēt vajadzētu verificētiem ekonomikas dalībniekiem, un piekļuve reģistra funkcijām nav tas pats, kas publiska piekļuve produkta informācijai.
Tas nav iemesls padarīt QR kodus sarežģītākus. Tas ir iemesls pirms pirmā produktīvā reģistrācijas procesa rūpīgi modelēt atbildību, pierādījumus un pilnvaras. Šis ceļvedis nošķir šos līmeņus un parāda, ko ražotāji var praktiski sagatavot jau tagad.
Trīs identitātes, kuras nedrīkst sajaukt
DPP-projektā pastāv vismaz trīs dažādas identitātes.
Pirmkārt, ir ekonomikas dalībnieks: uzņēmums vai individuālais komersants, kas laiž produktu tirgū vai darbojas reģistrā. Regulas 2026/1778 4. pants statusu “verified economic operator” sasaista ar identitātes pierādījumu. ES reģistrētiem individuālajiem komersantiem tiesību akts, piemēram, min kvalificētu elektronisko parakstu vai eIDAS prasībām atbilstošu elektroniskās identifikācijas līdzekli ar augstu uzticamības līmeni. Arī juridiskās personas ir jāverificē, izmantojot noteiktus pierādījumus.
Otrkārt, ir cilvēks, kas lieto sistēmu. Iepirkumu, pamatdatu pārvaldības un atbilstības speciālisti, ārējie pakalpojumu sniedzēji un DPP-pakalpojumu sniedzējs automātiski nerīkojas ar vienādām pilnvarām. Tāpēc lietotāja konts neaizstāj verificētā uzņēmuma kontekstu. Ir vajadzīga izsekojama sasaite: kas, kura ekonomikas dalībnieka vārdā, ar kādu lomu un līdz kuram datumam rīkojas?
Treškārt, ir produkta identitāte. GTIN, sērijas numurs vai cits identifikators apraksta produktu vai prasīto detalizācijas pakāpi; tas nepierāda, ka persona pie ekrāna ir tiesīga veikt reģistrāciju. ESPR nepārprotami nošķir šīs jomas: datu nesējs sasaista produktu ar pasi, savukārt reģistrs glabā unikālos identifikatorus un reģistrācijas datus. Komisijas pārskatā par DPP process aprakstīts atbilstoši: produkta informāciju izveido un reģistrē, pēc tam reģistrs izveido unikālu reģistrācijas ID.
Ja šīs trīs identitātes apvieno vienā tabulā, API pilnvaru atslēgā vai kopīgā e-pasta pastkastē, vēlāk rodas audita un darbības riski. Pareizais jautājums nav “Kas zina saiti?”, bet gan “Kam ir tiesības šī ekonomikas dalībnieka vārdā ierosināt darbību reģistrā?”.
Publiska QR piekļuve nav reģistra pilnvara
QR kods uz produkta joprojām ir piekļuve pasei. Tas nav pieteikšanās mehānisms reģistrā, un tam par tādu arī nevajadzētu kļūt. Patērētājiem, remonta uzņēmumiem, pārstrādātājiem un iestādēm katram ir vajadzīga atšķirīga informācija. Pašreizējā Komisijas rokasgrāmatā par DPP nepārprotami norādīts, ka informācijai piekļūst atbilstoši lietotāja lomai.
Tāpēc praksē ieteicams skaidri nošķirt slāņus:
- Publiskā skenēšana nodrošina stabilu, bez maksas pieejamu pases skatu ar konkrētajai produktu grupai noteikto informāciju.
- Ar lomām ierobežota saskarne pārvalda pierādījumus, piegādātāju datus, izmaiņu vēsturi un iekšējos apstiprinājumus.
- Reģistra savienotājs drīkst nosūtīt tikai nepieciešamos reģistrācijas datus un piesaistīt reģistra atbildi konkrētam produkta datu ierakstam.
Tas novērš divus izplatītus maldīgus pieņēmumus. Pirmkārt, “slepena” QR saite neaizstāj piekļuves kontroli; to var pārsūtīt, un tā nav uzticams pilnvaru pierādījums. Otrkārt, reģistrs nav visu produkta dokumentu glabātuve. Komisija skaidro, ka pilnā produkta informācija var atrasties pie ekonomikas dalībnieka vai DPP-pakalpojumu sniedzēja; reģistrē nepieciešamos metadatus un identifikatorus.
Ko regula tehniski norāda
Regula 2026/1778 reģistru neapraksta kā vienkāršu uzmeklēšanas datubāzi. Tajā cita starpā minēts API reģistrācijai un datu saņemšanai, platforma esamības un pilnīguma apstiprināšanai, shēma unikāliem reģistrācijas ID, verificētu DPP-pakalpojumu sniedzēju direktorijs, žurnalēšanas sistēma, kā arī identifikācijas un autorizācijas shēmas. Turklāt datu modeļiem jābūt versētiem.
No šīm prasībām neizriet gatava produkta arhitektūra. Tomēr tās sniedz stabilas pamatnostādnes:
Uzņēmuma profils pirms produktu importa
Pirms masveida importa izveidojiet kontrolētu uzņēmuma datu ierakstu. Tajā iekļauj juridisko vienību, tās ekonomikas dalībnieka statusu, izvēlēto identitātes pierādījumu, pārbaudes laiku un atbildīgo struktūrvienību. Pašu pierādījumu DPP-sistēmai vajadzētu glabāt tikai tiktāl, ciktāl tas ir nepieciešams un pieļaujams; bieži pietiek ar pārbaudes statusu, atsauci un termiņa beigu vai atkārtotas izvērtēšanas loģiku.
Pilnvarojums ir atsevišķs datu ieraksts
Ja rīkojas pakalpojumu sniedzējs vai aģentūra, pilnvarojumam ir vajadzīgs tvērums. Tajā būtu jānorāda vismaz ekonomikas dalībnieks, atļautās darbības, produktu grupas vai zīmoli, sākums, beigas un atsaukšana. Vispārēja API atslēga bez pilnvarojuma robežām reģistrācijai nozīmīgai darbībai ir pārāk plaša.
Reģistrācija kā pierādāma darbība
Katrai reģistrācijai komandām būtu jāfiksē vismaz vietējā produkta versija, nosūtītais identifikators, atbilde, tostarp reģistrācijas ID, laika zīmogs, rīkojošā loma un kļūdas klase. Tādējādi vēlāk var atšķirt, vai pase bija saturiski nepilnīga, vai identifikatori pārklājās, vai arī trūka pilnvaru. Žurnalēšanai nevajadzētu kļūt par nevajadzīgu personas datu vākšanu; tai jāveido atbildīga un pārbaudāma darbību ķēde.
Pārbaudiet pilnvaras tāpat kā biznesa noteikumus
Testēšanas scenārijiem nevajadzētu beigties ar “API atbild 200”. Pārbaudiet vismaz: nepilnvarots lietotājs nevar ierosināt reģistrāciju; deleģēts pakalpojumu sniedzējs var apstrādāt tikai saskaņoto pilnvarojumu; beidzies pilnvarojums tiek noraidīts; publiskais pases skats neatklāj iekšējos reģistra vai pierādījumu datus; un atkārtoti iesniegta darbība tiek izsekojami apstrādāta kā atkārtojums.
Īss sākuma plāns nākamajām nedēļām
Nesāciet ar pilnīgu migrāciju. Izvēlieties nelielu, reprezentatīvu produktu kopumu un reālu atbildības ķēdi.
- Katram pilotprojektam piešķiriet ražotāju, laižot tirgū atbildīgo personu, par datiem atbildīgos un, ja nepieciešams, pakalpojumu sniedzēju.
- Dokumentējiet, ar kādu procedūru ekonomikas dalībnieks tiek verificēts un kas apstiprina pārbaudi.
- Definējiet lomas izstrādei, satura apstiprināšanai, reģistrācijai un tikai lasīšanas piekļuvei.
- Reģistrējiet testa datu ierakstu ar versētiem produkta datiem un reģistrējiet darbību, atbildi un labošanas ceļu.
- Testējiet publisko QR piekļuvi atsevišķi no iekšējām lomām un reģistra savienotāja.
- Izmēģiniet atsaukšanu un maiņu: kas notiek, mainoties pakalpojumu sniedzējam, uzņēmuma nosaukumam vai kļūdainam identifikatoram?
Šī pieeja atbilst arī jau publicētajam ieteikumam reģistru, novirzītāju un datu avotu testēt atsevišķi. Jaunais akcents ir šāds: pirms stabilas API integrācijas ir skaidri jāzina, kura verificētā organizācija un kura loma ir atbildīga par darbību.
Ko vēl nevajadzētu apgalvot
Reģistra regula izveido tehnisko un organizatorisko ietvaru. Tā nepadara katru produktu grupu uzreiz DPP-obligātu un neaizstāj nozaru deleģētos tiesību aktus. Komisija ieviešanu joprojām klasificē pa produktu grupām; saskaņā ar ESPR-deleģētajiem tiesību aktiem parasti paredzēts vismaz 18 mēnešu pārejas periods. Tāpat verificēts uzņēmuma statuss nav atļauja sniegt nepilnīgus vai nepatiesus produkta datus.
Tomēr komandām sekas ir konkrētas: identitāte, pilnvarojums, lomas un žurnalēšana jāiekļauj DPP-izstrādes darbu sarakstā, pirms reģistrācijas tiek mērogotas. Tādējādi QR kods paliek vienkāršs publiskais ieejas punkts, bet darbība reģistrā kļūst par to, kas tā ir regulatīvā nozīmē: verificēta ekonomikas dalībnieka atbildīgu, izsekojamu rīcību.
