DPP-Mantenere aggiornati i dati: cosa prescrive davvero il ESPR

Dall’adozione della ESPR-Verordnung (EU) 2024/1781, il Digital Product Passport (DPP) è diritto vincolante dell’UE. Ciò che molte aziende sottovalutano è che il DPP non è un documento statico generato una sola volta al momento dell’immissione sul mercato. Deve essere mantenuto aggiornato per tutto il ciclo di vita del prodotto — e i requisiti al riguardo diventano sempre più precisi.

Questo articolo spiega quali dati devono essere aggiornati e quando, come l’architettura della Registry influenza il modello di aggiornamento e quali schemi tecnici si dimostrano efficaci nella pratica.

Cosa stabilisce il regolamento sul ciclo di aggiornamento

Campi dati statici e dinamici

La ESPR non indica una frequenza di aggiornamento esplicita, ma stabilisce che il DPP debba contenere «informazioni aggiornate e accurate». La precisazione avviene a livello settoriale — e qui la bozza JRC per i prodotti semifiniti in ferro e acciaio offre finora il quadro più chiaro.

La bozza distingue sistematicamente tra due livelli di granularità dei dati:

Livello	Identificatore	Dati esemplificativi	Evento di aggiornamento
Livello di lotto (Lot)	Numero di lotto	Percentuale di materiale riciclato, composizione della lega, PCF secondo ISO 14067	In caso di modifica della produzione, nuovo lotto
Livello di prodotto (Item)	Numero di serie	Dimensioni, certificazioni, dichiarazioni di conformità	In caso di ricertificazione, richiamo, riparazione

Questa distinzione è decisiva per l’architettura del database: i dati di lotto vengono in genere scritti una volta per ciclo produttivo e poi rimangono stabili — a meno che un ricalcolo dell’impronta di CO₂ non produca un valore corretto. I dati a livello di prodotto, invece, possono cambiare per tutta la durata d’uso, ad esempio quando un dispositivo viene riparato o una certificazione viene rinnovata.

Il regolamento sulle batterie (UE) 2023/1542 conosce già implicitamente questa distinzione: i dati sulla capacità, che cambiano a causa del degrado, devono essere mantenuti aggiornati — un requisito difficilmente soddisfabile senza un’architettura chiara.

La Registry come registro, non come archivio dati

Un malinteso frequente riguarda il ruolo della DPP-Registry centrale. La bozza del regolamento di esecuzione sulla DPP-Registry chiarisce: la Registry memorizza esclusivamente l’identificatore univoco, l’endpoint del resolver e il codice merceologico — non i dati effettivi del passaporto.

Questo comporta per la gestione degli aggiornamenti che il contenuto del passaporto e la Registry sono sistemi separati. Chi aggiorna i dati del prodotto, di norma, non deve intervenire sulla Registry — salvo che cambi l’endpoint del resolver, ad esempio in caso di sostituzione del sistema. Il consorzio CIRPASS-2 ha richiamato esplicitamente questo modello architetturale nella sua posizione sulla bozza relativa alla Registry e raccomanda di includere la norma EN 18219 come riferimento vincolante nel regolamento di esecuzione — tra l’altro per garantire l’interoperabilità con il GS1 Digital Link.

Scenari di aggiornamento nella pratica

Scenario 1: nuova impronta di CO₂ dovuta al cambio di fornitore

L’impronta di CO₂ specifica del prodotto (PCF) viene gestita a livello di lotto secondo la bozza JRC sull’acciaio e deve essere calcolata con metodi compatibili con la ISO 14067. Se un produttore di acciaio cambia vettore energetico o fornitore di rottami, cambia il PCF del nuovo lotto — ma non quello dei lotti già consegnati.

Tecnicamente, ciò significa che il record DPP-del vecchio lotto rimane invariato. Per il nuovo lotto viene creato un nuovo record, che può utilizzare lo stesso endpoint del resolver, ma presenta un nuovo numero di lotto come identificatore.

# Beispiel: Neuen Chargen-Datensatz via API anlegen
curl -X POST https://api.example.com/dpp/lots \
  -H "Content-Type: application/json" \
  -d '{
    "lotId": "LOT-2026-0612-A",
    "productId": "GTIN-04012345678901",
    "pcf_kgCO2e_per_kg": 1.84,
    "pcf_method": "ISO-14067:2018",
    "recycled_content_pct": 42,
    "alloy_composition": {"C": 0.18, "Mn": 1.40, "Si": 0.25}
  }'

Scenario 2: certificazione in scadenza a livello di prodotto

Le dichiarazioni di conformità e le certificazioni hanno date di scadenza. Non appena viene rilasciata una nuova certificazione, il DPP deve essere aggiornato a livello di prodotto. Poiché l’endpoint del resolver rimane invariato, non è necessario alcun aggiornamento della Registry — cambia soltanto il record dietro l’endpoint.

// TypeScript-Beispiel: Zertifizierung aktualisieren
interface Certification {
  type: string;
  issuedBy: string;
  validUntil: string; // ISO 8601
  documentUrl: string;
}

async function updateCertification(
  itemId: string,
  cert: Certification
): Promise<void> {
  await dppClient.patch(`/items/${itemId}/certifications`, {
    body: cert,
  });
}

Scenario 3: migrazione del resolver in caso di cambio di sistema

Se un’azienda cambia il proprio fornitore del servizio DPP, cambia l’endpoint del resolver. In questo caso è necessario aggiornare la Registry — per ogni identificatore interessato. È il tipo di aggiornamento più oneroso, perché richiede una scrittura nella Registry.

Raccomandazione: utilizzate un resolver stabile e proprietario (ad es. dpp.ihrunternehmen.de) come livello intermedio, che inoltri internamente al rispettivo fornitore. In questo modo l’endpoint registrato nella Registry rimane stabile nel tempo.

Requisiti tecnici del sistema di aggiornamento

Versioning e audit trail

La ESPR non richiede esplicitamente il versioning, ma la combinazione di responsabilità sul prodotto e controlli doganali rende di fatto indispensabile un audit trail. Se nel 2030 un funzionario doganale verifica il DPP di una trave d’acciaio prodotta nel 2027, deve essere possibile ricostruire quali dati fossero validi al momento dell’importazione.

Schema minimo per una tabella DPP con versioning:

CREATE TABLE dpp_versions (
  id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  identifier   TEXT NOT NULL,          -- GTIN + Lot/Serial
  valid_from   TIMESTAMPTZ NOT NULL,
  valid_until  TIMESTAMPTZ,            -- NULL = aktuell gültig
  data         JSONB NOT NULL,
  changed_by   TEXT NOT NULL,
  change_reason TEXT
);

CREATE INDEX ON dpp_versions (identifier, valid_from DESC);

GS1 Digital Link come ancoraggio stabile dell’identificatore

Il GS1 Digital Link separa con chiarezza identificatore e resolver: il codice QR sul prodotto codifica un URL come https://id.gs1.org/01/04012345678901/10/LOT-2026-0612-A, che tramite il resolver GS1 o un resolver proprietario conduce al record DPP aggiornato. Gli aggiornamenti del record non richiedono una nuova etichettatura — il supporto fisico rimane invariato.

TEKLYNX ha aggiornato il proprio software CODESOFT e ora supporta gli schemi di codifica GS1 «++», con i quali è possibile scrivere direttamente gli URL web nella memoria dei tag RAIN-RFID — un requisito derivante dalla combinazione della EN 18220 e dello standard GS1 Digital Link.

Governance: chi può aggiornare cosa?

Oltre alla questione tecnica, si pone quella della governance: quali attori della catena di fornitura possono scrivere quali campi del DPP? Il consorzio CIRPASS-2 ha individuato punti critici relativi alla sovranità dei dati nelle catene di fornitura transfrontaliere.

Un modello pratico distingue tre ruoli:

Produttore (Creator): Scrive tutti i campi al momento della creazione; può aggiornare tutti i campi.
Attore autorizzato (Editor): Può aggiornare campi definiti, ad es. la cronologia delle riparazioni e le nuove certificazioni — documentandoli con il proprio identificatore.
Lettore (Reader): Può leggere tutti i campi pubblici, senza diritti di scrittura.

Ecommerce Europe ha chiesto nel proprio documento di posizione sull’implementazione del DPP che anche per i prodotti usati siano possibili «DPPs» parziali — vale a dire record che aggiornano soltanto una parte dei campi originari. Tecnicamente ciò è già possibile oggi, ma manca ancora come categoria formale nei regolamenti di esecuzione.

Conclusioni

Mantenere aggiornati i dati del DPP non è un’attività una tantum, ma un processo operativo. Le principali conclusioni derivanti dall’attuale quadro normativo sono:

Separate lotto e prodotto — la strategia degli identificatori determina quali dati devono essere aggiornati e quando.
La Registry non è un archivio dati — gli aggiornamenti al contenuto del passaporto non richiedono in genere una scrittura nella Registry.
Il versioning è di fatto obbligatorio — anche se il regolamento non lo prescrive esplicitamente.
GS1 Digital Link disaccoppia il supporto fisico dal record — riducendo notevolmente l’onere degli aggiornamenti dei dati.
I ruoli di governance devono essere definiti in anticipo — chi può scrivere cosa e come viene registrato?

Le norme diventano più precise e i primi progetti pilota sono in corso — chi imposta correttamente l’architettura oggi evita costose correzioni quando entreranno in vigore i regolamenti di esecuzione specifici per settore.