Новото практическо тесно място: Кой има право да регистрира паспорт?
Регистърът на ЕС за DPP функционира от 20 юли 2026 г. В началото за много екипи на преден план стоеше техническият въпрос: може ли да се регистрира продуктов идентификатор и препраща ли правилно носителят на данни? Това е необходимо, но недостатъчно. С Регламент за изпълнение (ЕС) 2026/1778 от 16 юли 2026 г. предварително удостоверената идентичност придобива собствено регулаторно значение: регистрациите следва да се извършват от проверени икономически оператори, а достъпът до функциите на регистъра не е същото като публичния достъп до информацията за продукта.
Това не е причина QR кодовете да се усложняват. Това е причина отговорностите, доказателствата и правомощията да бъдат ясно моделирани още преди първия продуктивен процес по регистрация. Следващото ръководство разделя тези нива и показва какво могат да подготвят производителите още сега.
Три идентичности, които не бива да се смесват
В един проект за DPP участват най-малко три различни идентичности.
Първо, това е икономическият оператор: дружеството или едноличният търговец, който пуска продукт на пазара или извършва действия в регистъра. Член 4 от Регламент 2026/1778 обвързва определянето като „verified economic operator“ с доказване на идентичност. За установени в ЕС еднолични търговци правният акт посочва например квалифициран електронен подпис или съвместимо с eIDAS електронно средство за идентификация с високо ниво на доверие. Юридическите лица също трябва да бъдат проверени чрез определени доказателства.
Второ, това е човешкият потребител. Служителите по снабдяване, поддръжка на основни данни, съответствие, външните доставчици на услуги и един DPP-доставчик на услуги не действат автоматично с едни и същи правомощия. Затова потребителският акаунт не е заместител на проверения корпоративен контекст. Необходимо е проследимо съпоставяне: кой действа от името на кой икономически оператор, в каква роля и до кога?
Трето, това е продуктовата идентичност. Един GTIN, сериен номер или друг идентификатор описва продукта, съответно изискваната степен на детайлност; той не доказва, че лицето пред екрана има право да извърши регистрацията. ESPR изрично разделя тези сфери: носителят на данни свързва продукта с паспорта, докато регистърът съхранява уникалните идентификатори и регистрационните данни. Прегледът на Комисията относно DPP описва процеса по същия начин: информацията за продукта се създава и регистрира, след което регистърът генерира уникален регистрационен идентификатор.
Който обедини тези три идентичности в една таблица, API токен или обща електронна пощенска кутия, по-късно създава одитен и оперативен риск. Правилният въпрос не е „Кой знае връзката?“, а „Кой има право да задейства регистрово действие от името на този икономически оператор?“.
Публичният QR достъп не е правомощие за регистъра
QR кодът върху продукта остава вход към паспорта. Той не е механизъм за вход в регистъра и не бива да се превръща в такъв. Потребителите, ремонтните предприятия, рециклиращите предприятия и органите на властта се нуждаят от различна информация. В актуалното ръководство на Комисията относно DPP изрично се посочва, че информацията е достъпна според ролите на потребителите.
На практика затова се препоръчва ясно разделяне на слоевете:
- Публичното сканиране предоставя стабилен, безплатно достъпен изглед на паспорта с информацията, изисквана за съответната продуктова група.
- Интерфейс с ограничен достъп според ролите управлява доказателствата, данните за доставчиците, хронологията на промените и вътрешните одобрения.
- Конекторът към регистъра трябва да предава само необходимите регистрационни данни и да свързва отговора от регистъра с конкретен продуктов запис.
Това предотвратява две широко разпространени погрешни допускания. Първо: „тайна“ QR връзка не заменя контрола на достъпа; тя може да бъде препратена и не е надеждно доказателство за правомощие. Второ: регистърът не е мястото за съхранение на всички документи за продукта. Комисията пояснява, че пълната информация за продукта може да се намира при икономическия оператор или при DPP-доставчик на услуги; регистрират се необходимите метаданни и идентификатори.
Какво подсказва регламентът от техническа гледна точка
Регламент 2026/1778 не описва регистъра като обикновена база данни за справки. В него се посочват, наред с другото, API за регистрация и получаване на данни, платформа за потвърждаване на съществуването и пълнотата, схема за уникални регистрационни идентификатори, указател на проверени DPP-доставчици на услуги, система за регистриране, както и схеми за идентификация и оторизация. Освен това моделите на данни трябва да бъдат версионирани.
От тези изисквания не следва готова продуктова архитектура. Те обаче дават устойчиви ориентири:
Корпоративен профил преди импортиране на продукти
Преди масов импорт създайте контролиран корпоративен запис. Той трябва да включва юридическото лице, статуса му като икономически оператор, избраното доказателство за идентичност, момента на проверката и отговорното звено. Самото доказателство следва да се съхранява от система DPP само доколкото това е необходимо и допустимо; често е достатъчен статус на проверката с препратка и логика за изтичане или повторна оценка.
Делегирането е отделен запис
Когато доставчик на услуги или агенция извършва действия, делегирането трябва да има обхват. Най-малкото е разумно да се посочат икономическият оператор, разрешените действия, продуктовите групи или марките, началото, краят и отмяната. Общ API ключ без граница на мандата е твърде общ за действие с регистрово значение.
Регистрацията като доказуем процес
За всяка регистрация екипите трябва най-малкото да съхраняват локалната версия на продукта, предадения идентификатор, отговора, включително регистрационния идентификатор, времевия печат, действащата роля и класа на грешката. Така по-късно може да се разграничи дали паспортът е бил съдържателно непълен, дали идентификатор е в конфликт или дали е липсвало правомощие. Регистрирането не трябва да се превръща в събиране на ненужни лични данни; то трябва да създава отговорна и проверима верига от действия.
Тествайте правомощията като бизнес правила
Тестовите случаи не трябва да приключват с „API отговаря с 200“. Проверете най-малкото следното: неупълномощен потребител не може да задейства регистрация; делегиран доставчик може да обработва само договорения мандат; изтекло делегиране се отхвърля; публичният изглед на паспорта не разкрива вътрешни данни от регистъра или данни от доказателствата; и повторно подаден процес се третира проследимо като повторение.
Стегнат план за старт през следващите седмици
Не започвайте с пълна миграция. Изберете малък, представителен набор от продукти и реална верига на отговорност.
- За всеки пилотен продукт определете производителя, лицето, което го пуска на пазара, отговорните за данните и, ако е приложимо, доставчика на услуги.
- Документирайте по каква процедура се проверява икономическият оператор и кой одобрява проверката.
- Определете роли за изготвяне, съдържателно одобрение, регистрация и права само за четене.
- Регистрирайте тестов запис с версионирани продуктови данни и документирайте регистрацията, отговора и пътя за корекция.
- Тествайте публичния QR достъп отделно от вътрешните роли и конектора към регистъра.
- Упражнете отмяна и промяна: какво се случва при смяна на доставчик на услуги, промяна на наименованието на дружеството или грешен идентификатор?
Този процес съответства и на вече публикуваната препоръка регистърът, резолверът и източникът на данни да се тестват отделно. Новото е акцентът: преди надеждна интеграция с API трябва да е ясно коя проверена организация и коя роля носят отговорност за действието.
Какво все още не бива да се твърди
Регламентът за регистъра създава техническата и организационната рамка. Той не прави всяка продуктова група незабавно DPP-задължена и не заменя специфичните за сектора делегирани правни актове. Комисията продължава да въвежда изискванията по продуктови групи; съгласно ESPR-делегираните правни актове по принцип е предвиден преходен период от най-малко 18 месеца. Също така провереният корпоративен статус не е разрешение за непълни или неверни продуктови данни.
За екипите последицата все пак е конкретна: идентичността, мандатът, ролите и регистрирането трябва да бъдат включени в DPP-беклога, преди регистрациите да се мащабират. Така QR кодът остава лесният публичен вход, а действието в регистъра се превръща в това, което е от регулаторна гледна точка: отговорно, проследимо действие на проверен икономически оператор.
