Il nuovo ostacolo pratico: chi può registrare un pass?
Il registro DPP dell'UE è operativo dal 20 luglio 2026. Inizialmente, per molti team la questione tecnica era in primo piano: è possibile registrare un identificatore di prodotto e il supporto dati risolve correttamente? È necessario, ma non sufficiente. Con il regolamento di esecuzione (UE) 2026/1778 del 16 luglio 2026, l'identità a monte assume un proprio rilievo normativo: a registrare dovrebbero essere operatori economici verificati e l'accesso alle funzioni del registro non coincide con l'accesso pubblico alle informazioni sul prodotto.
Non è un motivo per rendere più complessi i codici QR. È un motivo per modellare con precisione responsabilità, prove e autorizzazioni prima del primo processo di registrazione in produzione. La guida seguente distingue questi livelli e mostra cosa i produttori possono preparare concretamente.
Tre identità da non confondere
In un progetto DPP compaiono almeno tre identità diverse.
In primo luogo c'è l'operatore economico: l'impresa o l'imprenditore individuale che immette un prodotto sul mercato o opera nel registro. L'articolo 4 del regolamento 2026/1778 collega la classificazione come «operatore economico verificato» a una prova d'identità. Per gli imprenditori individuali con sede nell'UE, l'atto normativo cita, ad esempio, una firma elettronica qualificata o uno strumento di identificazione elettronica conforme a eIDAS con un livello elevato di affidabilità. Anche le persone giuridiche devono essere verificate tramite prove definite.
In secondo luogo c'è l'utente umano. Acquisti, gestione dei dati master, conformità, fornitori esterni e un DPP-Service-Provider non agiscono automaticamente con la stessa autorità. Un account utente non sostituisce quindi il contesto aziendale verificato. Serve un'associazione tracciabile: chi agisce per quale operatore economico, con quale ruolo e fino a quando?
In terzo luogo c'è l'identità del prodotto. Un GTIN, un numero di serie o un altro identificatore descrive il prodotto o la granularità richiesta; non dimostra che la persona davanti allo schermo sia autorizzata a registrarlo. Il ESPR separa esplicitamente queste sfere: il supporto dati collega il prodotto al pass, mentre il registro conserva gli identificatori univoci e i dati di registrazione. La panoramica della Commissione sul DPP descrive il processo di conseguenza: le informazioni sul prodotto vengono create e registrate, quindi il registro genera un ID di registrazione univoco.
Chi riunisce queste tre identità in una tabella, un token API o una casella e-mail condivisa crea in seguito un rischio operativo e di audit. La domanda corretta non è «Chi conosce il link?», ma «Chi può avviare un'operazione nel registro per conto di questo operatore economico?».
L'accesso pubblico tramite QR non è un'autorizzazione del registro
Un codice QR sul prodotto resta un accesso al pass. Non è un meccanismo di login al registro e non dovrebbe diventarlo. Consumatori, riparatori, riciclatori e autorità hanno bisogno di informazioni diverse. L'attuale guida della Commissione sul DPP descrive espressamente l'accessibilità delle informazioni in base ai ruoli degli utenti.
In pratica, è quindi consigliabile una chiara separazione dei livelli:
- La scansione pubblica fornisce una vista stabile e accessibile gratuitamente del pass, con le informazioni prescritte per il relativo gruppo di prodotti.
- Un'interfaccia con accesso limitato in base ai ruoli gestisce prove, dati dei fornitori, cronologie delle modifiche e approvazioni interne.
- Il connettore del registro deve trasmettere solo i dati di registrazione necessari e associare la risposta del registro a uno specifico record di prodotto.
Questo evita due equivoci diffusi. Primo: un link QR «segreto» non sostituisce il controllo degli accessi; può essere inoltrato e non costituisce una prova affidabile dell'autorizzazione. Secondo: il registro non è il deposito di tutta la documentazione del prodotto. La Commissione spiega che le informazioni complete sul prodotto possono risiedere presso l'operatore economico o un DPP-Service-Provider; vengono registrati i metadati e gli identificatori necessari.
Indicazioni tecniche del regolamento
Il regolamento 2026/1778 non descrive il registro come un semplice database di ricerca. Cita, tra l'altro, un'API per la registrazione e la ricezione dei dati, una piattaforma per confermare l'esistenza e la completezza, uno schema per ID di registrazione univoci, un elenco di DPP-Service-Provider verificati, un sistema di log e schemi di identificazione e autorizzazione. Inoltre, i modelli di dati devono essere sottoposti a versionamento.
Queste disposizioni non definiscono un'architettura di prodotto completa. Forniscono però solide linee guida:
Profilo aziendale prima dell'importazione dei prodotti
Prima di un'importazione massiva, create un record aziendale controllato. Deve comprendere l'entità giuridica, il suo status di operatore economico, la prova d'identità scelta, la data della verifica e l'unità responsabile. Un sistema DPP dovrebbe conservare la prova stessa solo nella misura necessaria e consentita; spesso è sufficiente uno stato di verifica con riferimento e una logica di scadenza o rivalutazione.
La delega è un record autonomo
Quando interviene un Service-Provider o un'agenzia, la delega deve avere un ambito definito. Come minimo, è opportuno indicare operatore economico, azioni consentite, gruppi di prodotti o marchi, inizio, fine e revoca. Una chiave API generica senza limiti di mandato è troppo ampia per un'azione rilevante ai fini della registrazione.
La registrazione come processo dimostrabile
Per ogni registrazione, i team dovrebbero conservare almeno la versione locale del prodotto, l'identificatore trasmesso, la risposta comprensiva dell'ID di registrazione, il timestamp, il ruolo che ha agito e la classe di errore. In questo modo è possibile distinguere in seguito se un pass era incompleto sul piano dei contenuti, se un identificatore era in conflitto o se mancava l'autorizzazione. La registrazione dei log non deve trasformarsi nella raccolta di dati personali non necessari; deve creare una catena di azioni responsabile e verificabile.
Testare le autorizzazioni come regole di business
I casi di test non dovrebbero fermarsi a «l'API risponde 200». Verificate almeno quanto segue: un utente non autorizzato non può avviare una registrazione; un provider delegato può gestire solo il mandato concordato; una delega scaduta viene rifiutata; la vista pubblica del pass non divulga dati interni del registro o delle prove; e un'operazione inviata nuovamente viene trattata in modo tracciabile come ripetizione.
Un piano di avvio essenziale per le prossime settimane
Non iniziate con una migrazione completa. Scegliete una piccola quantità rappresentativa di prodotti e una catena reale di responsabilità.
- Per ogni prodotto pilota, assegnate produttore, soggetto che lo immette sul mercato, responsabili dei dati ed eventualmente Service-Provider.
- Documentate la procedura con cui viene verificato l'operatore economico e chi approva la verifica.
- Definite i ruoli per la bozza, l'approvazione dei contenuti, la registrazione e i soli diritti di lettura.
- Registrate un record di test con dati di prodotto sottoposti a versionamento e documentate registrazione, risposta e percorso di correzione.
- Testate l'accesso pubblico tramite QR separatamente dai ruoli interni e dal connettore del registro.
- Esercitate revoca e sostituzione: cosa succede in caso di cambio del fornitore di servizi, modifica della denominazione aziendale o identificatore errato?
Questa procedura è coerente anche con la raccomandazione già pubblicata di testare separatamente registro, resolver e fonte dati. La novità è l'attenzione al punto seguente: prima di una solida integrazione API deve essere chiaro quale organizzazione verificata e quale ruolo sono responsabili dell'azione.
Cosa non si dovrebbe ancora affermare
Il regolamento sul registro crea il quadro tecnico e organizzativo. Non rende immediatamente DPP obbligatorio per ogni gruppo di prodotti e non sostituisce gli atti delegati settoriali. La Commissione continua a definire l'introduzione per gruppi di prodotti; secondo gli ESPR atti delegati è generalmente previsto un periodo transitorio di almeno 18 mesi. Allo stesso modo, lo status aziendale verificato non autorizza dati di prodotto incompleti o errati.
Per i team, tuttavia, la conseguenza è concreta: identità, mandato, ruoli e registrazione dei log devono entrare nel backlog DPP prima di scalare le registrazioni. In questo modo il codice QR resta il semplice punto di accesso pubblico, mentre l'operazione nel registro diventa ciò che è sul piano normativo: un'azione responsabile e tracciabile di un operatore economico verificato.
