Naujoji praktinė kliūtis: kas gali užregistruoti pasą?
ES DPP registras veikia nuo 2026 m. liepos 20 d. Daugeliui komandų iš pradžių svarbiausias buvo techninis klausimas: ar galima užregistruoti produkto identifikatorių ir ar duomenų laikmena tinkamai nukreipia? Tai būtina, bet nepakankama. 2026 m. liepos 16 d. Reglamentu (ES) 2026/1778 išankstinei tapatybei suteikiama atskira reguliacinė reikšmė: registruoti turėtų patikrinti ekonominės veiklos vykdytojai, o prieiga prie registro funkcijų nėra tas pats, kas vieša prieiga prie informacijos apie produktą.
Tai nėra priežastis QR kodus daryti sudėtingesnius. Tai priežastis prieš pirmąjį gamybinį registravimo procesą tinkamai sumodeliuoti atsakomybes, įrodymus ir teises. Toliau pateikiamas vadovas atskiria šiuos lygmenis ir parodo, kam gamintojai gali praktiškai pasiruošti jau dabar.
Trys tapatybės, kurių negalima painioti
DPP projekte egzistuoja bent trys skirtingos tapatybės.
Pirma, yra ekonominės veiklos vykdytojas: įmonė arba individualus verslininkas, tiekiantis produktą rinkai arba veikiantis registre. Reglamento 2026/1778 4 straipsnyje „patikrinto ekonominės veiklos vykdytojo“ statusas siejamas su tapatybės įrodymu. ES įsisteigusiems individualiems verslininkams teisės akte, pavyzdžiui, nurodomas kvalifikuotas elektroninis parašas arba su eIDAS suderinama elektroninė identifikavimo priemonė, užtikrinanti aukštą patikimumo lygį. Juridiniai asmenys taip pat turi būti patikrinti pagal nustatytus įrodymus.
Antra, yra fizinis naudotojas. Pirkimų, pagrindinių duomenų tvarkymo, atitikties darbuotojai, išorės paslaugų teikėjai ir DPP paslaugų teikėjas automatiškai neveikia turėdami tuos pačius įgaliojimus. Todėl naudotojo paskyra nepakeičia patikrinto įmonės konteksto. Reikia aiškaus priskyrimo: kas veikia kurio ekonominės veiklos vykdytojo vardu, kokį vaidmenį atlikdamas ir iki kada?
Trečia, yra produkto tapatybė. GTIN, serijos numeris arba kitas identifikatorius apibūdina produktą arba reikalaujamą detalumo lygį; jis neįrodo, kad prie ekrano esantis asmuo turi teisę registruoti. ESPR aiškiai atskiria šias sritis: duomenų laikmena susieja produktą su pasu, o registre saugomi unikalūs identifikatoriai ir registracijos duomenys. Komisijos apžvalgoje apie DPP procesas aprašomas taip pat: produkto informacija sukuriama ir užregistruojama, o tada registras sugeneruoja unikalų registracijos ID.
Kas šias tris tapatybes sujungia vienoje lentelėje, API rakte arba bendroje el. pašto dėžutėje, vėliau sukuria audito ir veiklos riziką. Tinkamas klausimas yra ne „Kas žino nuorodą?“, o „Kas gali šio ekonominės veiklos vykdytojo vardu inicijuoti registro veiksmą?“.
Vieša QR prieiga nėra teisė veikti registre
Ant produkto esantis QR kodas lieka prieigos prie paso priemone. Tai nėra prisijungimo prie registro mechanizmas ir tokiu neturėtų tapti. Vartotojams, remonto įmonėms, perdirbėjams ir institucijoms reikia skirtingos informacijos. Naujausiame Komisijos vadove apie DPP aiškiai nurodoma, kad informacija pasiekiama pagal naudotojų roles.
Todėl praktiškai rekomenduojama aiškiai atskirti sluoksnius:
- Viešai nuskaitant pateikiamas stabilus, nemokamai pasiekiamas paso vaizdas su konkrečiai produktų grupei privaloma informacija.
- Ribotos prieigos pagal roles sąsaja tvarko įrodymus, tiekėjų duomenis, pakeitimų istoriją ir vidinius patvirtinimus.
- Registro jungtis gali perduoti tik būtinus registracijos duomenis ir susieti registro atsakymą su konkrečiu produkto įrašu.
Taip išvengiama dviejų paplitusių klaidingų prielaidų. Pirma, „slapta“ QR nuoroda nepakeičia prieigos kontrolės: ja galima pasidalyti, be to, ji nėra patikimas teisės įrodymas. Antra, registras nėra visų produkto dokumentų saugykla. Komisija aiškina, kad visa produkto informacija gali būti saugoma pas ekonominės veiklos vykdytoją arba DPP paslaugų teikėją; registre registruojami būtini metaduomenys ir identifikatoriai.
Ką techniškai suponuoja reglamentas
Reglamente 2026/1778 registras neaprašomas kaip paprasta paieškos duomenų bazė. Jame, be kita ko, nurodoma registravimo ir duomenų gavimo API, platforma egzistavimui ir išsamumui patvirtinti, unikalių registracijos ID schema, patikrintų DPP paslaugų teikėjų katalogas, žurnalų sistema, taip pat identifikavimo ir autorizavimo schemos. Be to, duomenų modeliai turi būti versijuojami.
Iš šių reikalavimų neatsiranda paruošta produkto architektūra. Tačiau jie suteikia tvirtas gaires:
Įmonės profilis prieš importuojant produktus
Prieš masinį importą sukurkite kontroliuojamą įmonės įrašą. Jame turėtų būti juridinis vienetas, jo, kaip ekonominės veiklos vykdytojo, statusas, pasirinktas tapatybės įrodymas, patikros laikas ir atsakingas padalinys. Paties įrodymo DPP sistema turėtų saugoti tik tiek, kiek būtina ir leidžiama; dažnai pakanka patikros būsenos su nuoroda ir galiojimo pabaigos arba pakartotinio vertinimo logika.
Delegavimas yra atskiras įrašas
Kai veikia paslaugų teikėjas arba agentūra, delegavimui reikia nustatyti apimtį. Mažiausiai verta nurodyti ekonominės veiklos vykdytoją, leidžiamus veiksmus, produktų grupes arba prekių ženklus, pradžią, pabaigą ir atšaukimą. Bendras API raktas be įgaliojimo ribų yra pernelyg platus registracijai reikšmingam veiksmui.
Registracija kaip įrodomas procesas
Kiekvienai registracijai komandos turėtų saugoti bent vietinę produkto versiją, perduotą identifikatorių, atsakymą su registracijos ID, laiko žymą, veikusią rolę ir klaidos klasę. Taip vėliau galima atskirti, ar pasas buvo dalykiškai neišsamus, ar susidūrė identifikatoriai, ar trūko teisės veikti. Žurnalai neturėtų tapti nereikalingų asmens duomenų rinkimo priemone; jų paskirtis – sukurti atsakingą ir patikrinamą veiksmų grandinę.
Teises tikrinkite kaip verslo taisykles
Testavimo atvejai neturėtų baigtis ties „API atsako 200“. Patikrinkite bent tai: neįgaliotas naudotojas negali inicijuoti registracijos; deleguotas paslaugų teikėjas gali tvarkyti tik sutartą įgaliojimą; pasibaigus delegavimui veiksmas atmetamas; viešame paso vaizde neatskleidžiami vidiniai registro ar įrodymų duomenys; o pakartotinai pateiktas procesas atpažįstamas kaip pasikartojantis.
Paprastas artimiausių savaičių veiksmų planas
Nepradėkite nuo visiškos migracijos. Pasirinkite nedidelį, reprezentatyvų produktų rinkinį ir realią atsakomybės grandinę.
- Kiekvienam bandomajam produktui priskirkite gamintoją, tiekėją rinkai, už duomenis atsakingus asmenis ir, jei reikia, paslaugų teikėją.
- Dokumentuokite, kokiu būdu tikrinamas ekonominės veiklos vykdytojas ir kas patvirtina patikrą.
- Nustatykite projektavimo, dalykinio patvirtinimo, registravimo ir tik skaitymo teises turinčias roles.
- Užregistruokite bandomąjį įrašą su versijuotais produkto duomenimis ir užregistruokite registraciją, atsakymą bei taisymo kelią.
- Išbandykite viešą QR prieigą atskirai nuo vidinių rolių ir registro jungties.
- Išbandykite atšaukimą ir pasikeitimą: kas nutinka pakeitus paslaugų teikėją, įmonės pavadinimą arba nustačius klaidingą identifikatorių?
Ši eiga taip pat atitinka jau paskelbtą rekomendaciją registrą, sprendiklį ir duomenų šaltinį tikrinti atskirai. Naujas akcentas toks: prieš patikimą API integraciją turi būti aišku, kuri patikrinta organizacija ir kuri rolė yra atsakinga už veiksmą.
Ko dar nereikėtų teigti
Registro reglamentas sukuria techninę ir organizacinę sistemą. Jis nepadaro kiekvienos produktų grupės iš karto DPP privaloma ir nepakeičia konkretiems sektoriams skirtų deleguotųjų teisės aktų. Komisija ir toliau įgyvendinimą nustato pagal produktų grupes; pagal ESPR deleguotuosius teisės aktus iš esmės numatomas bent 18 mėnesių pereinamasis laikotarpis. Taip pat patikrintos įmonės statusas nesuteikia teisės teikti neišsamius ar neteisingus produkto duomenis.
Vis dėlto komandoms pasekmė konkreti: tapatybė, įgaliojimas, rolės ir žurnalai turi būti įtraukti į DPP planą dar prieš plečiant registracijas. Taip QR kodas išlieka paprastu viešu įėjimu, o veiksmas registre tampa tuo, kuo jis yra reguliavimo požiūriu: atsakingu, atsekamu patikrinto ekonominės veiklos vykdytojo veiksmu.
