DPP-Date actualizate: ce prevede cu adevărat ESPR

Întrebarea pare banală, dar nu este: cât de des trebuie actualizat un pașaport digital al produsului? Cine caută un număr concret în ESPR-Regulamentul (UE) 2024/1781 va fi dezamăgit. Textul prevede doar că DPP trebuie să conțină „informații actuale și exacte” – fără frecvență, fără SLA și fără specificații tehnice. Ce înseamnă acest lucru în practică depinde în mare măsură de tipul produsului, de lanțul de aprovizionare și de actele delegate care urmează să fie adoptate pentru fiecare categorie de produse.

Acest articol explică ce categorii de date se pot modifica, ce modele de actualizare se dovedesc eficiente în implementările timpurii și unde se află capcanele de reglementare.

Ce se poate modifica în cadrul unui DPP

Un pașaport de produs nu este un PDF static. El constă în puncte de date cu cicluri de viață foarte diferite.

Date statice vs. dinamice

În linii mari, câmpurile DPP pot fi împărțite în trei clase:

Categorie de date	Frecvență tipică a modificării	Exemple
Date de bază	O singură dată (la lansarea produsului)	GTIN, compoziția materialului, producătorul
Date privind lotul/șarja	Pentru fiecare serie de producție	Valoarea PCF, originea materiilor prime, certificate
Date privind ciclul de viață	Declanșate de evenimente	Istoricul reparațiilor, retragerea produsului, calea de eliminare

Proiectul de date JRC pentru produsele din oțel evidențiază în mod deosebit această diferență: amprenta de carbon specifică produsului (PCF) este menționată explicit la nivel de lot și trebuie calculată folosind metode compatibile cu ISO 14067. Aceasta înseamnă că fiecare lot nou de producție poate avea o valoare PCF diferită – pașaportul trebuie să facă referire corect la această valoare, nu la media anului precedent.

Exemplul bateriei ca model

Pașaportul digital al bateriei, obligatoriu începând cu 18 februarie 2027, arată cât de dinamice pot fi datele DPP. Rapoartele din industrie privind implementarea pașaportului digital al bateriei identifică fragmentarea datelor și actualizările datelor dinamice drept cele două probleme centrale din practică. Bateriile acumulează date de-a lungul duratei lor de viață: starea de sănătate (SoH), ciclurile de încărcare, evenimentele de reparare. Cine lucrează aici cu un set de date static nu respectă regulamentul.

Modele de actualizare: cum funcționează astăzi implementările

Actualizări declanșate de evenimente prin webhook

Cel mai robust model în primele sisteme DPP este actualizarea declanșată de evenimente: un sistem backend trimite un webhook imediat ce se modifică un punct de date relevant – de exemplu, când este emis un nou certificat de testare sau este finalizată o reparație.

// Beispiel: Webhook-Handler für DPP-Update
app.post('/webhook/dpp-update', async (req, res) => {
  const { passportId, field, newValue, timestamp } = req.body;

  await dppRepository.patchField(passportId, {
    [field]: newValue,
    lastUpdated: timestamp,
  });

  await auditLog.append(passportId, { field, newValue, timestamp });
  res.status(204).send();
});

Important: ESPR impune implicit posibilitatea existenței unei piste de audit. Modificările trebuie să rămână trasabile – suprascrierea simplă, fără versionare, prezintă riscuri de reglementare.

Actualizări în lot pentru informațiile despre șarje

Atunci când valorile PCF sau certificatele pentru loturi întregi de producție sunt actualizate simultan, se recomandă o procedură de import în masă. În acest proces, o listă de numere de pașaport este transmisă împreună cu noua valoare a câmpului:

# Beispiel: Bulk-PATCH via CLI
curl -X PATCH https://api.example.com/v1/dpp/bulk \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "filter": { "batchId": "BATCH-2026-06-A" },
    "patch": {
      "carbonFootprint": 1.84,
      "carbonFootprintMethod": "ISO 14067:2018",
      "certifiedAt": "2026-06-15"
    }
  }'

Platforme precum qr3.app cu import în masă acceptă acest model, astfel încât fiecare lot să nu trebuiască actualizat manual.

GS1 Digital Link ca strat de rezoluție

Un aspect adesea subestimat: codul QR de pe produs nu trebuie să se schimbe – este imprimat fizic. Ceea ce trebuie să se schimbe este conținutul către care indică. Aici GS1 Digital Link oferă stratul esențial de abstractizare. Codul QR codifică un URI stabil (de exemplu, https://id.example.com/01/04012345678901/21/SN-00042), iar resolverul redirecționează către sursa de date actuală.

Driscoll's a demonstrat la GS1 Connect 2026 cum funcționează acest principiu la scară largă: peste un miliard de caserole pentru fructe de pădure au primit identități unice și migrează în prezent la coduri QR complet conforme cu GS1 Digital Link. Codul de pe ambalaj rămâne neschimbat; ceea ce se modifică este setul de date din spatele resolverului.

Noile tehnologii, precum parteneriatul dintre Polytag și DataLase, arată că în prezent codurile QR conforme cu GS1 pot fi aplicate și pe substraturi de ambalaj dificile, la viteza liniilor de producție – obstacolul fizic scade, iar logica resolverului din spate rămâne aceeași.

Capcane de reglementare

Directiva EmpCo exercită o presiune suplimentară

Cine crede că trebuie să monitorizeze doar ESPR subestimează imaginea de ansamblu. În iunie 2026, Comisia Europeană a inițiat proceduri de constatare a neîndeplinirii obligațiilor împotriva a 20 de state membre din cauza transpunerii necorespunzătoare a Directivei EmpCo (UE) 2024/825. Această directivă interzice practicile de greenwashing și solicită informații clare privind durabilitatea și reparabilitatea – informații care trebuie să fie integrate direct în DPP. Prin urmare, indicii de reparabilitate învechiți sau etichetele de sustenabilitate nevalabile din pașaport pot constitui nu doar o încălcare a ESPR, ci și o încălcare a EmpCo.

Fără un termen explicit de actualizare – dar cu obligații implicite

Lipsa unei indicații privind frecvența în ESPR nu reprezintă un cec în alb. Din formularea „informații actuale și exacte” pot fi deduse mai multe obligații implicite:

Actualitate legată de evenimente: De îndată ce are loc o retragere, o reparație sau o modificare a unui certificat, pașaportul trebuie actualizat – fără întârziere.
Actualitate legată de lot: Valorile PCF și dovezile privind materiile prime nu pot fi transferate de la un lot vechi la unul nou atunci când valorile diferă.
Conformitate cu supravegherea pieței: Autoritățile trebuie să poată accesa pașaportul pe întregul ciclu de viață al produsului. Un pașaport care nu mai este actualizat după vânzare este lipsit de valoare pentru informațiile privind repararea și eliminarea.

Ecommerce Europe recomandă în mod explicit, în documentul său de poziție, o introducere etapizată și o granularitate flexibilă a datelor – ceea ce înseamnă indirect că procesele de actualizare pot fi dezvoltate iterativ, atât timp cât sunt îndeplinite cerințele de bază.

Recomandări practice

Planificați jurnalul de audit de la început

Fiecare modificare a unui set de date DPP ar trebui înregistrată împreună cu marca temporală, autorul și motivul modificării. Astăzi, aceasta nu este o obligație explicită a ESPR, însă este așteptată în actele delegate și, în fapt, necesară pentru supravegherea pieței.

Arhitectura resolverului înaintea arhitecturii datelor

Cine stabilește mai întâi structura datelor și abia apoi se gândește cum să indice codul QR către acestea construiește în ordinea greșită. Ordinea corectă: definiți URI-ul resolverului (GS1 Digital Link), apoi schema datelor și, în final, procesele de actualizare. Pașaportul digital al produsului de pe qr3.app urmează acest principiu: codul QR este stabil, iar setul de date din spatele lui este versionat și poate fi modificat prin patch-uri.

Utilizați consecvent ID-urile loturilor

Cine gestionează valorile PCF sau certificatele la nivel de produs, în loc de nivel de lot, își creează probleme cel târziu la prima verificare de supraveghere a pieței. ID-ul lotului ar trebui să fie un câmp obligatoriu în fiecare set de date DPP – nu un câmp opțional de metadate.

Situația de reglementare este complexă, însă modelele tehnice pot fi gestionate. Esențial este ca posibilitatea de actualizare să nu fie tratată ca o funcționalitate adăugată ulterior, ci ca un principiu de arhitectură încă din prima zi.