Европейската комисия консултира проект на регламент за централен DPP регистър

Контекст: Защо централен регистър за цифрови продуктови паспорти?

Цифровият продуктов паспорт (DPP) е крайъгълният камък на европейския Регламент за екопроектиране на устойчиви продукти (ESPR), който е в сила от юли 2024 г. Той изисква от производителите да предоставят машинно четими записи с данни за нарастващ брой продуктови категории — от батерии и текстил до електроника. Но къде всъщност се намират препратките към тези записи? Точно това урежда новият регламент за изпълнение.

На 29 април 2026 г. Европейската комисия публикува проект на регламент за изпълнение относно DPP регистъра, който сега е открит за обществена консултация. Документът описва как централизиран регистър ще съхранява уникални продуктови идентификатори и ще ги свързва с продуктови данни, хоствани по децентрализиран начин. Това не е база данни за самите продуктови данни — това е директория с препратки.

Този архитектурен избор е целенасочен: ЕС не иска да създаде монолитен информационен силоз, а по-скоро оперативно съвместима мрежа от системи на производителите, които могат да бъдат открити чрез споделен централен възел.

Какво всъщност изисква проектът

Структура: централен регистър, децентрализирани данни

Основният принцип на проекта е ясен: регистърът съхранява само уникални идентификатори (UID) и свързаните с тях резолверни крайни точки — тоест URL адресите, от които могат да бъдат извлечени реалните DPP данни. Самите продуктови данни остават у производителя или у определен оператор на данни.

Този модел е концептуално тясно свързан с GS1 Digital Link, отворения стандарт, който свързва GTIN кодовете със структурирани уеб URI адреси. Скенер или орган за надзор на пазара може да използва записа в централния регистър, за да локализира отговорния резолвер и да извлече оттам пълните данни на паспорта.

Задължения за регистрация на икономическите оператори

Проектът установява, че производителите и вносителите са длъжни да регистрират продуктите си в регистъра, преди да ги пуснат на пазара. По-конкретно, те трябва да:

подадат уникалния продуктов идентификатор (UID),
предоставят резолверната крайна точка (URL), на която може да се достъпи DPP,
доставят метаданни за продуктовата категория и за отговорния икономически оператор.

Регистрацията трябва да се извършва чрез стандартизиран API, чиято техническа спецификация все още се разработва от ECLASS и други органи за стандартизация. Проектът се позовава на текущата работа на CEN/CENELEC JTC 24, който е натоварен да хармонизира моделите на данни.

Права за достъп и защита на данните

Един от централните спорни въпроси в консултацията вероятно ще бъде кой може да достъпва кои регистрационни данни. Проектът разграничава три класа участници:

Участник	Достъп за четене	Достъп за запис	Бележки
Общественост / Потребители	Резолверен URL, продуктова категория	Не	Без търговски чувствителни данни
Органи за надзор на пазара	Пълен запис, включително метаданни	Не	Единен за целия ЕС
Икономически оператори (производители, вносители)	Собствени записи	Да	Удостоверяване чрез EU Login

Търговски чувствителната информация — като отношения с доставчици или покупни цени — изрично не трябва да се съхранява в регистъра. За това проектът посочва възможността за дефиниране на нива на достъп (Access Rights) в рамките на самия DPP, както вече е предвидено в делегирания регламент ESPR за батериите.

Технически последствия за производителите и доставчиците на ИТ услуги

Интеграция на API и масова регистрация

За компаниите с големи продуктови портфолиа въпросът за масовата регистрация е от решаващо значение. Проектът очертава REST API, чрез който UID кодовете могат да се подават на партиди. Опростен пример как би могло да бъде структурирано такова обаждане за регистрация:

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"
  }
}

Самият UID трябва да съответства на призната система за идентификация — проектът изрично посочва GS1 GTIN, както и кодове, съвместими с ISO/IEC 15459. Собствените (proprietary) системи са разрешени, но трябва да бъдат глобално уникални и постоянно разрешими (resolvable).

За компаниите, които вече работят с инструменти като qr3.app Bulk Import, основният принцип не се променя съществено: структурирана доставка на UID кодове и резолверни URL адреси във формат CSV или JSON може да бъде съпоставена с Registry API. Истинското предизвикателство се крие в управлението (governance) — кой в организацията отговаря за поддръжката на записите, когато резолверните URL адреси се променят или продуктите се изтеглят от пазара?

Управление на жизнения цикъл: изземвания и архивиране

Проектът също така разглежда жизнения цикъл на продукта след пускането му на пазара. Производителите са длъжни да актуализират записите в регистъра, когато:

резолверната крайна точка се промени,
продуктът бъде изтеглен (записът тогава трябва да бъде маркиран като „изтеглен", но не изтрит),
компанията бъде прекратена или прехвърлена.

Задължението за архивиране е определено на най-малко 10 години след последния път, когато продуктът е бил пуснат на пазара — изискване, което поставя особено предизвикателство пред МСП без собствена ИТ инфраструктура.

График и следващи стъпки

Очаква се обществената консултация по проекта да продължи до края на юни 2026 г. Коментари могат да се подават чрез портала EU Have Your Say. Комисията заяви намерението си да приеме окончателния регламент за изпълнение преди края на 2026 г., за да го съгласува с първите специфични за продуктите делегирани регламенти по ESPR — най-вече за текстила (планиран за 2027 г.).

За Регламента за батериите, който е задължителен от февруари 2024 г., се прилага специален режим: системата на паспорта за батерии първоначално функционира чрез отделен механизъм, но в средносрочен план се предвижда да бъде интегрирана в централния регистър.

Какво трябва да направят компаниите сега

Макар че регламентът все още не е окончателен, има подготвителни стъпки, които можете да предприемете още днес:

Определете своята UID стратегия: Решете дали да разчитате на GS1 GTIN, или на алтернативна система. GS1 Digital Link има предимството, че идентификаторът същевременно функционира като разрешим уеб URI.
Изградете своята резолверна инфраструктура: Резолверната крайна точка трябва да бъде постоянно достъпна и версионирана. Използвайте стабилни базови URL адреси — не динамични къси URL адреси.
Определете процеси за поддръжка на данните: Кой във вашата организация отговаря за актуализациите на регистъра, когато продуктите се променят или биват изтегляни?
Следете консултацията: Окончателният регламент може да се различава от проекта — особено по отношение на спецификациите на API и правата за достъп.

Оценка: какво прави регистърът — и какво не прави

Централният DPP регистър не е сертификат за качество или оценка на съответствието. Той е директорийна услуга — съпоставима с DNS за продуктови идентификатори. Точността на DPP данните остава отговорност на икономическите оператори и се проверява от органите за надзор на пазара.

Критиците от индустрията — включително BusinessEurope — вече отбелязаха, че двойствената структура на централен регистър и децентрализирано съхранение на данни увеличава разходите за съответствие, без съществено да подобрява защитата на данните. Поддръжниците, включително екологични организации като European Environmental Bureau, от своя страна твърдят, че само централна входна точка може да гарантира приложимостта от страна на органите.

Фазата на консултация ще покаже дали Комисията ще се придържа към хибридната архитектура, или ще направи корекции. За компаниите, които започват техническата си подготовка сега, основният извод е следният: фундаменталните принципи — уникални идентификатори, стабилни резолвери, структурирани метаданни — ще останат валидни независимо от окончателния регулаторен текст.