DPP-Mantenere aggiornati i dati: cosa prescrive davvero ESPR

La domanda sembra banale, ma non lo è: con quale frequenza deve essere aggiornato un passaporto digitale di prodotto? Chi cerca un numero concreto nel ESPR-regolamento (UE) 2024/1781 rimarrà deluso. Il testo prescrive soltanto che il DPP debba contenere «informazioni aggiornate e accurate», senza frequenza, SLA o specifiche tecniche. Ciò che questo significa nella pratica dipende fortemente dal tipo di prodotto, dalla catena di fornitura e dagli atti delegati che devono ancora essere emanati per ciascuna categoria di prodotto.

Questo articolo spiega quali categorie di dati possano cambiare, quali schemi di aggiornamento si dimostrino efficaci nelle prime implementazioni e dove si trovino le insidie normative.

Cosa può cambiare in un DPP

Un passaporto di prodotto non è un PDF statico. È composto da punti dati con cicli di vita molto diversi.

Dati statici e dinamici

In linea generale, i campi DPP possono essere suddivisi in tre classi:

Categoria di dati	Frequenza tipica di modifica	Esempi
Dati anagrafici	Una tantum (al lancio del prodotto)	GTIN, composizione dei materiali, produttore
Dati di lotto	Per ciclo di produzione	Valore PCF, origine delle materie prime, certificati
Dati del ciclo di vita	Basati sugli eventi	Storico delle riparazioni, richiamo, percorso di smaltimento

Il progetto di dati JRC per i prodotti in acciaio rende questa differenza particolarmente evidente: l'impronta di carbonio specifica del prodotto (PCF) è indicata esplicitamente a livello di lotto e deve essere calcolata con metodi compatibili con la norma ISO 14067. Ciò significa che ogni nuovo lotto di produzione può avere un valore PCF diverso: il passaporto deve fare riferimento correttamente a questo valore, non alla media dell'anno precedente.

L'esempio delle batterie come modello

Il passaporto digitale delle batterie, obbligatorio dal 18 febbraio 2027, mostra quanto possano essere dinamici i dati DPP. I report di settore sull'implementazione del passaporto digitale delle batterie individuano nella frammentazione dei dati e negli aggiornamenti dinamici dei dati i due problemi centrali nella pratica. Nel corso della loro vita, le batterie accumulano dati: stato di salute (SoH), cicli di ricarica, eventi di riparazione. Chi lavora qui con un set di dati statico non rispetta il regolamento.

Schemi di aggiornamento: come funzionano oggi le implementazioni

Aggiornamenti basati sugli eventi tramite webhook

Lo schema più solido nei primi sistemi DPP è l'aggiornamento basato sugli eventi: un sistema backend invia un webhook non appena cambia un punto dati rilevante, ad esempio quando viene emesso un nuovo certificato di collaudo o viene completata una riparazione.

// 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();
});

Importante: il ESPR richiede implicitamente la capacità di mantenere una traccia di audit. Le modifiche devono rimanere tracciabili: una semplice sovrascrittura senza versionamento comporta rischi normativi.

Aggiornamenti batch per le informazioni sui lotti

Quando i valori PCF o i certificati vengono aggiornati contemporaneamente per interi lotti di produzione, si presta una procedura di importazione in blocco. In questo caso viene trasmesso un elenco di numeri di passaporto insieme al nuovo valore del campo:

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

Piattaforme come qr3.app con importazione in blocco supportano questo schema, evitando di dover aggiornare manualmente ogni lotto.

GS1 Digital Link come livello di risoluzione

Un aspetto spesso sottovalutato: il codice QR sul prodotto non può cambiare, perché è stampato fisicamente. A dover cambiare è il contenuto a cui rimanda. È proprio qui che GS1 Digital Link fornisce il decisivo livello di astrazione. Il codice QR codifica un URI stabile (ad es. https://id.example.com/01/04012345678901/21/SN-00042), mentre il resolver reindirizza alla fonte di dati di volta in volta aggiornata.

Driscoll's ha dimostrato al GS1 Connect 2026 come funziona questo principio su larga scala: oltre un miliardo di confezioni a conchiglia per frutti di bosco sono state dotate di identità univoche e stanno migrando verso codici QR pienamente conformi a GS1 Digital Link. Il codice sulla confezione rimane invariato; a cambiare è il set di dati dietro al resolver.

Le nuove tecnologie, come la partnership tra Polytag e DataLase, dimostrano che oggi i codici QR conformi a GS1 possono essere applicati anche su substrati di imballaggio difficili alla velocità delle linee di produzione: l'ostacolo fisico diminuisce, mentre la logica del resolver sottostante rimane la stessa.

Insidie normative

La direttiva EmpCo come ulteriore pressione

Chi ritiene di dover monitorare soltanto la ESPR sottovaluta il quadro complessivo. Nel giugno 2026 la Commissione europea ha avviato procedure d'infrazione contro 20 Stati membri per la carente attuazione della direttiva EmpCo (UE) 2024/825. Questa direttiva vieta il greenwashing e richiede informazioni chiare sulla durabilità e sulla riparabilità: informazioni che dovrebbero confluire direttamente nel DPP. Indici di riparabilità obsoleti o etichette di sostenibilità non valide nel passaporto possono quindi costituire non solo una violazione della ESPR, ma anche una violazione della direttiva EmpCo.

Nessun termine esplicito per gli aggiornamenti, ma obblighi impliciti

L'assenza di un'indicazione sulla frequenza nella ESPR non è una licenza a non fare nulla. Dalla formulazione «informazioni aggiornate e accurate» si possono ricavare diversi obblighi impliciti:

Attualità legata agli eventi: non appena si verifica un richiamo, una riparazione o una modifica del certificato, il passaporto deve essere aggiornato, senza attese.
Attualità legata al lotto: i valori PCF e le prove sull'origine delle materie prime non possono essere trasferiti da un vecchio lotto a uno nuovo quando i valori differiscono.
Conformità alla vigilanza del mercato: le autorità devono poter consultare il passaporto per l'intero ciclo di vita del prodotto. Un passaporto che non viene più aggiornato dopo la vendita è privo di valore per le informazioni sulla riparazione e sullo smaltimento.

Ecommerce Europe raccomanda espressamente, nel suo documento programmatico, un'introduzione per fasi e una granularità flessibile dei dati: ciò significa indirettamente che i processi di aggiornamento possono essere strutturati in modo iterativo, purché siano soddisfatti i requisiti fondamentali.

Raccomandazioni pratiche

Pianificare il registro di audit fin dall'inizio

Ogni modifica a un set di dati DPP dovrebbe essere registrata con indicazione di data e ora, autore e motivo della modifica. Oggi non è un obbligo esplicito della ESPR, ma è previsto dagli atti delegati ed è di fatto necessario per la vigilanza del mercato.

Architettura del resolver prima dell'architettura dei dati

Chi definisce prima la struttura dei dati e solo dopo si chiede come il codice QR debba rimandarvi sta procedendo nel modo sbagliato. L'ordine corretto è: definire l'URI del resolver (GS1 Digital Link), poi lo schema dei dati e infine i processi di aggiornamento. Il passaporto digitale di prodotto su qr3.app segue questo principio: il codice QR è stabile, mentre il set di dati sottostante è versionato e aggiornabile tramite patch.

Utilizzare sistematicamente gli ID di lotto

Chi gestisce i valori PCF o i certificati a livello di prodotto anziché a livello di lotto si troverà ad affrontare problemi al più tardi durante la prima verifica di vigilanza del mercato. L'ID del lotto dovrebbe essere un campo obbligatorio in ogni set di dati DPP, non un campo di metadati facoltativo.

Il quadro normativo è complesso, ma gli schemi tecnici sono gestibili. È decisivo non trattare la capacità di aggiornamento come una funzionalità aggiunta in un secondo momento, bensì come un principio architetturale da definire fin dal primo giorno.