DPP-register: kontrollitud ettevõtjate ja juurdepääsurollide korrektne seadistamine

DPP-registri määrus seab usaldusväärse registreerimise eelduseks identiteedi ja õigused. Praktiline juhend rollide, volituste ja auditijälgede kohta.

autor QR3 Redaktion

DPP-register: kontrollitud ettevõtjate ja juurdepääsurollide korrektne seadistamine

Uus praktiline kitsaskoht: kes tohib passi registreerida?

ELi DPP-register on alates 20. juulist 2026 töös. Paljude meeskondade jaoks oli esialgu esiplaanil tehniline küsimus: kas tooteidentifikaatori saab registreerida ja kas andmekandja lahendab õigesti? See on vajalik, kuid ebapiisav. 16. juuli 2026. aasta rakendusmäärus (EL) 2026/1778 annab eelnevale identiteedile eraldi regulatiivse tähenduse: registreerima peaksid kontrollitud ettevõtjad ning juurdepääs registri funktsioonidele ei ole sama mis avalik juurdepääs tooteteabele.

See ei ole põhjus QR-koode keerukamaks muuta. See on põhjus modelleerida vastutused, tõendid ja õigused enne esimest tootmisregistratsiooni protsessi korralikult. Järgmine juhend eristab need tasandid ja näitab, mida tootjad saavad nüüd praktiliselt ette valmistada.

Kolm identiteeti, mida ei tohi segi ajada

DPP-projektis esineb vähemalt kolm eri identiteeti.

Esiteks on ettevõtja: ettevõte või füüsilisest isikust ettevõtja, kes toote turule laseb või registris tegutseb. Määruse 2026/1778 artikkel 4 seob „kontrollitud ettevõtja“ staatuse identiteeditõendiga. ELis asuvate füüsilisest isikust ettevõtjate puhul nimetab õigusakt näiteks kvalifitseeritud elektroonilist allkirja või eIDASiga kooskõlas olevat kõrge usaldustasemega elektroonilist identimisvahendit. Ka juriidilised isikud tuleb kontrollida kindlaksmääratud tõendite alusel.

Teiseks on inimkasutaja. Ost, põhiandmete haldus, vastavuskontroll, välised teenuseosutajad ja DPP-teenuseosutaja ei tegutse automaatselt samade volitustega. Kasutajakonto ei asenda seetõttu kontrollitud ettevõtluskonteksti. Vajalik on jälgitav seos: kes tegutseb millise ettevõtja nimel, millises rollis ja kuni mis ajani?

Kolmandaks on tooteidentiteet. GTIN, seerianumber või muu identifikaator kirjeldab toodet või nõutud detailsustaset; see ei tõenda, et ekraani ees olev isik tohib registreerida. ESPR eristab need valdkonnad sõnaselgelt: andmekandja seob toote passiga, register aga hoiab kordumatuid identifikaatoreid ja registreerimisandmeid. Komisjoni ülevaade DPP kohta kirjeldab protsessi vastavalt: tooteteave luuakse ja registreeritakse, seejärel genereerib register kordumatu registreerimis-ID.

Kes need kolm identiteeti ühte tabelisse, API-võtmesse või ühisesse e-postkasti kokku koondab, tekitab hiljem auditi- ja käitlusriski. Õige küsimus ei ole „Kes linki teab?“, vaid „Kes tohib selle ettevõtja nimel registritoimingu käivitada?“.

Avalik QR-juurdepääs ei ole registriõigus

Tootel olev QR-kood jääb pääsuks passi juurde. See ei ole registri sisselogimismehhanism ega peaks selleks muutuma. Tarbijad, remondiettevõtted, ringlussevõtjad ja ametiasutused vajavad igaüks erinevat teavet. Kehtiv Komisjoni juhend DPP kohta kirjeldab sõnaselgelt, et teave on kasutajarollide alusel kättesaadav.

Praktikas on seetõttu soovitatav kihid selgelt lahutada:

  • Avalik skannimine avab stabiilse ja tasuta kättesaadava passivaate koos konkreetse tooterühma jaoks nõutud teabega.
  • Rollipõhiselt piiratud liides haldab tõendeid, tarnijaandmeid, muudatuste ajalugu ja sisemisi kinnitusi.
  • Registriühendus tohib edastada ainult vajalikud registreerimisandmed ja seostada registri vastuse konkreetse tooteandmekirjega.

See hoiab ära kaks levinud eksiarvamust. Esiteks ei asenda „salajane“ QR-link juurdepääsukontrolli; seda saab edasi jagada ja see ei ole usaldusväärne õigustõend. Teiseks ei ole register kõigi tootedokumentide hoiukoht. Komisjon selgitab, et täielik tooteteave võib paikneda ettevõtja või DPP-teenuseosutaja juures; registreeritakse vajalikud metaandmed ja identifikaatorid.

Mida määrus tehniliselt eeldab

Määrus 2026/1778 ei käsitle registrit pelgalt otsinguandmebaasina. Selles nimetatakse muu hulgas registreerimise ja andmete vastuvõtu API-t, olemasolu ja täielikkuse kinnitamise platvormi, kordumatute registreerimis-ID-de skeemi, kontrollitud DPP-teenuseosutajate kataloogi, logisüsteemi ning identifitseerimis- ja autoriseerimisskeeme. Ka andmemudelid peavad olema versioonitud.

Nendest nõuetest ei tulene valmis toote­arhitektuuri. Küll aga annavad need kindlad suunised:

Ettevõtte profiil enne toodete importi

Looge enne massimporti kontrollitud ettevõtte andmekirje. See hõlmab juriidilist üksust, selle staatust ettevõtjana, valitud identiteeditõendit, kontrollimise aega ja vastutavat üksust. Tõendit ennast peaks DPP-süsteem säilitama ainult vajalikus ja lubatud ulatuses; sageli piisab kontrolliolekust koos viite ning aegumise või kordushindamise loogikaga.

Delegeerimine on eraldi andmekirje

Kui teenuseosutaja või agentuur tegutseb ettevõtja nimel, peab delegeerimisel olema määratletud ulatus. Vähemalt tasub märkida ettevõtja, lubatud toimingud, tooterühmad või kaubamärgid, algus, lõpp ja tühistamine. Üldine API-võti ilma volituse piirita on registreerimisega seotud toimingu jaoks liiga üldine.

Registreerimine tõendatava toiminguna

Iga registreerimise kohta peaksid meeskonnad säilitama vähemalt kohaliku tooteversiooni, edastatud identifikaatori, vastuse koos registreerimis-ID-ga, ajatempli, tegutsenud rolli ja veaklassi. Nii saab hiljem eristada, kas pass oli sisuliselt puudulik, identifikaator kattus või puudus õigus. Logimine ei tohi muutuda tarbetute isikuandmete kogumiseks; selle eesmärk on luua vastutustundlik ja kontrollitav toimingute ahel.

Õigusi tuleb testida nagu ärireegleid

Testjuhtumid ei tohiks piirduda olukorraga „API vastab 200“. Kontrollige vähemalt järgmist: volitamata kasutaja ei saa registreerimist käivitada; delegeeritud teenuseosutaja saab hallata ainult kokkulepitud volitust; aegunud delegeerimine lükatakse tagasi; avalik passivaade ei paljasta sisemisi registri- ega tõendiandmeid ning uuesti esitatud toimingut käsitletakse jälgitavalt kordusena.

Lühike tegevuskava lähinädalateks

Ärge alustage täielikust migratsioonist. Valige väike ja esinduslik toodete hulk ning tegelik vastutusahel.

  1. Määrake iga piloottoote puhul tootja, turulelaskja, andmevastutaja ja vajaduse korral teenuseosutaja.
  2. Dokumenteerige, millise menetlusega ettevõtjat kontrollitakse ja kes kontrolli heaks kiidab.
  3. Määratlege rollid kavandamiseks, sisuliseks kinnitamiseks, registreerimiseks ja ainult lugemiseks.
  4. Registreerige versioonitud tooteandmetega testandmekirje ning logige registreerimine, vastus ja parandusteekond.
  5. Testige avalikku QR-juurdepääsu eraldi sisemistest rollidest ja registriühendusest.
  6. Harjutage tühistamist ja üleminekut: mis juhtub teenuseosutaja vahetumisel, ettevõtte nime muutumisel või vigase identifikaatori korral?

See tegevuskava sobib ka juba avaldatud soovitusega testida registrit, lahendajat ja andmeallikat eraldi. Uus on rõhuasetus: enne töökindlat API-integratsiooni peab olema selge, milline kontrollitud organisatsioon ja milline roll toimingu eest vastutab.

Mida ei tohiks veel väita

Registrimäärus loob tehnilise ja korraldusliku raamistiku. See ei muuda iga tooterühma kohe DPP-kohustuslikuks ega asenda valdkonnapõhiseid delegeeritud õigusakte. Komisjon käsitleb rakendamist endiselt tooterühmade kaupa; pärast ESPR-delegeeritud õigusakte on üldjuhul ette nähtud vähemalt 18-kuuline üleminekuaeg. Samuti ei anna kontrollitud ettevõtte staatus õigust puudulikele või valedele tooteandmetele.

Meeskondade jaoks on järeldus siiski konkreetne: identiteet, volitus, rollid ja logimine peavad jõudma DPP-mahajäämusse enne registreerimise laiendamist. Nii jääb QR-kood lihtsaks avalikuks sissepääsuks ning registritoimingust saab see, mis ta regulatiivselt on: kontrollitud ettevõtja vastutustundlik ja jälgitav tegevus.

Allikad