ISO/IEC JTC 5: preparare l’architettura di DPP all’interoperabilità

Perché ora l’architettura entra nell’agenda

Il passaporto digitale di prodotto viene introdotto gradualmente in Europa attraverso atti legislativi settoriali. Per le aziende nasce facilmente l’impressione che ogni gruppo di prodotti abbia bisogno di un proprio modello di dati, di un proprio supporto dati e di una propria logica d’integrazione. È proprio a questa intersezione che inizia il lavoro di ISO/IEC JTC 5: il comitato tecnico congiunto è stato istituito nel 2026 e dovrà elaborare le basi per l’interoperabilità tra settori e sistemi di DPP. Il primo incontro annunciato si terrà dal 7 al 9 settembre 2026 a Berlino. ISO/IEC JTC 5 descrive espressamente il proprio mandato come quadro per il sistema di DPP e l’ecosistema di DPP; le norme specifiche di settore restano di competenza degli organismi tecnici responsabili.

Non si tratta di un nuovo obbligo di legge né di una norma ISO pubblicata. È tuttavia un motivo concreto per separare la propria architettura dai campi dati a breve termine. Il primo punto di lavoro, ISO/AWI 25534-1, è ancora nella fase di progetto 10.99; il progetto è stato approvato il 12 febbraio 2026. Secondo ISO, riguarda termini, principi fondamentali, categorie di dati e meccanismi di governance e fiducia. La scheda pubblica del progetto indica espressamente “under development”. Chi ne deduce oggi un obbligo di certificazione o un formato di scambio definitivo anticipa i tempi.

Cosa separa il quadro internazionale dai requisiti dell’UE

L’UE ha già definito indicazioni concrete. La Commissione spiega che il DPP rende accessibili le informazioni relative al prodotto in un modello decentralizzato: i dati completi restano presso l’operatore economico o il fornitore di servizi DPP; il registro contiene identificativi univoci e i dati di registrazione prescritti. Un supporto dati come un codice QR collega il prodotto fisico al relativo passaporto. La pagina della Commissione sul DPP indica inoltre diversi livelli di accesso per ruoli e calendari settoriali.

A ciò si aggiungono le norme armonizzate europee. La decisione di esecuzione (UE) 2026/1736 del 14 luglio 2026 rimanda a sei norme DPP, tra cui quelle relative a identificativi, interoperabilità, supporti dati, API, scambio e archiviazione dei dati. Il loro ruolo è concreto: per i requisiti da esse coperti, la conformità può sostenere la presunzione di conformità ai sensi degli articoli 10 e 11 del ESPR.

JTC 5 non sostituisce questi livelli. Opera al di sopra di essi: un quadro neutrale rispetto ai settori dovrebbe contribuire a spiegare come termini, categorie di dati, fiducia e governance si rapportino tra loro nei diversi sistemi. La conseguenza pratica è importante. Un produttore non dovrebbe aspettare una futura pubblicazione ISO per rendere disponibili le informazioni relative a batterie, prodotti tessili o acciaio. Dovrebbe però evitare di fissare gli attuali campi di settore come nucleo immutabile di un modello DPP aziendale.

Tre decisioni architetturali sensate già oggi

1. Separare l’identità stabile dai profili tecnici

Un passaporto ha bisogno di un’identità tecnica duratura: prodotto, variante, lotto o singolo pezzo; operatore economico responsabile; risoluzione tramite il supporto dati. La base giuridica stabilisce poi quali informazioni tecniche siano necessarie. Queste informazioni devono confluire in profili versionati. Un modulo batteria per dati su CO₂ o sullo stato di salute non è quindi uno schema di base generale. Allo stesso modo, i dati su materiali, riparazione o riciclaggio non devono finire in un passaporto generale soltanto come testo libero non strutturato.

In pratica, un ID di base stabile, un identificativo di profilo documentato e una versione del profilo devono essere associati. Ogni vista del passaporto distribuita dovrebbe rendere riconoscibili il profilo e la versione che ne hanno determinato il contenuto. In questo modo i team possono recepire un atto legislativo, una regola di settore o, in seguito, una norma senza riscrivere i dati storici o gli URL.

2. Modellare separatamente provenienza dei dati e accesso

L’interoperabilità non è solo un formato JSON. Dipende dalla possibilità per il destinatario di valutare l’origine, la validità e il ruolo di un’informazione. Perciò, per ogni elemento o pacchetto di dati, memorizzate almeno la fonte, l’ambito di validità, il momento della rilevazione, la parte responsabile e la versione tecnica. Un valore interno di qualità è diverso da una dichiarazione di conformità giuridicamente vincolante; una dichiarazione del fornitore è diversa da un valore misurato.

La seconda componente è l’accesso. La Commissione descrive diversi accessi alle informazioni per consumatori, imprese di riparazione, riciclatori e autorità. Ciò richiede una separazione consapevole tra vista pubblica del passaporto, accesso tecnico autorizzato e area di lavoro interna. Un URL non deve diventare un’autorizzazione. Ruoli, mandati, categorie di dati e decisioni verificabili devono essere controllati lato server.

3. Testare i confini di scambio come contratti

Un sistema DPP ha diversi passaggi: ERP o PLM forniscono i dati anagrafici, i fornitori forniscono le attestazioni, un fornitore di servizi ospita i dati, un registro riceve i metadati e gli utenti esterni leggono una vista pubblica o protetta. Per ogni passaggio serve un contratto leggibile dalla macchina: campi consentiti, identificativi, semantica, casi di errore, versionamento e compatibilità all’indietro.

Questo può essere testato già ora. Casi di test utili sono versioni di profilo sconosciute, attestazioni scadute, provenienza dei dati mancante, ruoli non autorizzati, registrazioni duplicate e un supporto dati che rimanda a un passaporto non più disponibile. Il test non dimostra ancora la conformità a una futura norma ISO. Crea però la verificabilità che verrà a mancare in seguito, quando modello dei dati e diritti saranno già inscindibilmente mescolati.

Un piano di lavoro di 90 giorni senza speculazioni

Nei prossimi 30 giorni conviene realizzare una fotografia dello stato attuale: quali identificativi di prodotto esistono, quali profili di dati vengono effettivamente utilizzati e quali dati sono presenti soltanto nei documenti? Segue una decisione architetturale: modello di base, registro dei profili, modello di provenienza e matrice degli accessi. In un terzo passaggio, un prodotto reale dovrebbe attraversare tutti i passaggi — dal sistema sorgente, passando per il passaporto, fino al ruolo dell’impresa di riparazione o dell’autorità.

I limiti restano chiari. ISO/AWI 25534-1 non è una norma definitiva; non esistono clausole pubblicate che i team possano implementare. Anche la tempistica della Commissione è indicativa e non sostituisce la verifica dell’atto legislativo applicabile al rispettivo gruppo di prodotti. Il valore del monitoraggio non sta quindi nel mettere anticipatamente una spunta su una lista di conformità, ma in un’architettura capace di accogliere in modo ordinato nuovi profili, ruoli e regole di scambio.