Il 20 luglio 2026 la Commissione europea ha attivato il registro per i passaporti digitali di prodotto e il relativo ambiente di test. Una componente ESPR astratta è così diventata un sistema che le aziende possono effettivamente provare. Per i produttori è ora soprattutto importante distinguere un aspetto: il registro è l’indice centrale, mentre il passaporto di prodotto resta decentralizzato.
Cosa è diventato operativo il 20 luglio
Il registro acquisisce identificativi univoci dei prodotti, dati di registrazione e metadati selezionati. Le informazioni complete sui prodotti restano presso l’operatore economico responsabile o presso un fornitore di servizi DPP incaricato. Per questo la Commissione descrive esplicitamente il registro come un servizio di indicizzazione e non come un sistema centrale di gestione dei contenuti.
Le registrazioni sono previste tramite un’interfaccia utente protetta e tramite un’API. Le aziende possono inoltre generare una ricevuta elettronica di registrazione. Questo è rilevante per i processi B2B, perché fornitori e clienti possono così dimostrare che un passaporto è stato registrato nel sistema UE senza duplicare l’intero patrimonio di dati.
L’avvio non riguarda soltanto i gruppi di prodotti ESPR. La Commissione cita anche batterie, prodotti da costruzione, giocattoli, detergenti e tensioattivi destinati agli utilizzatori finali, nella misura in cui il rispettivo diritto dell’Unione richieda un passaporto digitale di prodotto. La prima scadenza vincolante resta il 18 febbraio 2027 per determinate batterie.
Registro, resolver e fonte dei dati sono tre livelli diversi
Un sistema DPP solido dovrebbe separare chiaramente i compiti:
- Il registro UE conferma che un identificativo e i metadati prescritti sono registrati.
- Un resolver indirizza l’identificativo persistente del prodotto verso la risorsa appropriata.
- La fonte effettiva dei dati fornisce contenuti aggiornati per persone e macchine.
Questa separazione non è un dettaglio. Chi archivia tutti i dati esclusivamente su una propria pagina di prodotto non dispone ancora di un’integrazione con il registro. Chi, al contrario, registra soltanto un identificativo non mette ancora a disposizione un passaporto di prodotto utilizzabile. Entrambi gli elementi devono essere collegati tramite identificativi stabili.
Per la risoluzione è adatto un link aperto e permanente. Un resolver GS1-Digital-Link può rendere accessibili diverse rappresentazioni a partire dallo stesso identificativo: una pagina web di facile comprensione, JSON-LD leggibile dalle macchine o documentazione integrativa. Il supporto dati sul prodotto o sull’imballaggio resta così stabile, anche se i sistemi di destinazione continuano a evolversi.
Cosa dovrebbero verificare le aziende nell’ambiente di test
L’ambiente di test non è pensato soltanto per una prova manuale. Dovrebbe essere trattato come una fase preliminare dell’integrazione in produzione.
Organizzazione e ruoli
Per prima cosa occorre chiarire quale entità giuridica effettua la registrazione, chi la rappresenta nel sistema e quali team possono creare o modificare le registrazioni. Ciò riguarda i dati anagrafici, la compliance, l’IT ed eventualmente i fornitori di servizi esterni. Un accesso personale di test non sostituisce un modello dei ruoli per la successiva operatività.
Identificativi e granularità
Il team di prodotto dovrebbe verificare se il passaporto futuro sarà gestito a livello di modello, lotto o singolo articolo. La risposta dipende dal diritto settoriale applicabile. Il test del registro è il momento giusto per mettere in relazione gli ID interni dei prodotti, i GTINs, gli identificativi dei lotti e l’identificativo persistente utilizzato esternamente.
API e ripetibilità
Un processo operativo richiede più di un POST eseguito con successo. Registrazione, aggiornamento e gestione degli errori devono poter essere ripetuti e registrati. Sono inclusi richieste idempotenti, ricevute tecniche e una chiara corrispondenza tra il record ERP, DPP e la voce del registro. Un processo DPP basato su API riduce le discrepanze manuali quando i prodotti vengono creati in grandi quantità.
Separazione tra metadati e dati specialistici
I dati del registro non dovrebbero diventare un secondo patrimonio di dati sui prodotti. Definite quali campi sono richiesti nel registro e quali restano nel passaporto decentralizzato. Per ogni informazione servono una fonte primaria, un soggetto responsabile e una regola di aggiornamento.
Prova e monitoraggio
Le ricevute di registrazione dovrebbero essere archiviate insieme al timestamp, all’identificativo utilizzato e alla risposta del sistema. Serve inoltre un controllo incrociato: il passaporto esiste, il resolver è raggiungibile e i metadati del registro corrispondono ancora allo stato del prodotto?
Perché la dogana ha bisogno di una propria catena di verifica
Il registro aiuta le autorità doganali a verificare automaticamente, prima dell’immissione in libera pratica, se sono presenti un DPP registrato valido e il codice delle merci richiesto. Per gli importatori nasce così una nuova dipendenza: l’identificativo del prodotto, la voce del registro e la dichiarazione doganale devono essere coerenti.
Un errore, quindi, non diventa visibile soltanto su una pagina di prodotto. Può riguardare il processo di frontiera. Le aziende dovrebbero simulare già nei test i flussi di dati dalla creazione del prodotto fino alla documentazione d’importazione e stabilire chi può correggere rapidamente una registrazione errata.
Un piano di test valido in 30 giorni
- Selezionare un’entità giuridica reale e un assortimento di prodotti ridotto ma rappresentativo.
- Documentare per ogni prodotto la granularità DPP prevista e gli identificativi principali.
- Eseguire un ciclo completo tramite l’interfaccia utente e, se pertinente, l’API.
- Archiviare insieme la ricevuta di registrazione, la risposta del resolver e i dati di prodotto leggibili dalle macchine.
- Testare i casi di errore: identificativo duplicato, metadati obsoleti, host dei dati non raggiungibile e prodotto ritirato.
- Sulla base dei risultati, definire un modello operativo con responsabilità, monitoraggio e percorso di escalation.
L’avvio operativo del registro non significa ancora che tutti i requisiti settoriali relativi ai dati siano già pienamente applicabili. Sposta però il dibattito dalle presentazioni ai processi verificabili. Le aziende possono ora capire se i loro identificativi, ruoli e API sono compatibili, prima che arrivino le prime scadenze obbligatorie.
