standard
L'UE ha già costruito un'architettura di riferimento per il passaporto
CIRPASS-2 ha pubblicato un'architettura di riferimento per i passaporti digitali. Non è legge, ma è il metro su cui si giudica l'interoperabilità.
Mentre le aziende aspettano gli atti delegati, un lavoro finanziato dall'UE ha costruito e testato come dovrebbe essere fatto un sistema di passaporto digitale di prodotto (DPP). CIRPASS-2 ha pubblicato un'architettura di riferimento, versione 1.1, a giugno 2026, e i progetti pilota girano proprio sulle categorie che affrontano per prime regole vincolanti: tessile, elettronica, edilizia e pneumatici.
Vale la pena conoscerla anche se niente di tutto ciò è legge.
Cosa è, e cosa non è, un'architettura di riferimento
È una descrizione dei blocchi costruttivi di cui ha bisogno un sistema di passaporto, dei ruoli che giocano i diversi attori e di una serie di raccomandazioni su come dovrebbero interagire. Li mette in relazione con i requisiti ESPR.
Non è vincolante. Nulla al suo interno obbliga qualcuno, e un sistema che se ne discosta non è non conforme.
Quello che è, in pratica, è la dichiarazione pubblica più dettagliata di come si presenta il "fatto bene" da parte di quella porzione di ecosistema che influenzerà gli standard. Quando prima o poi si giudicherà l'interoperabilità, sarà questo il vocabolario in cui verrà giudicata.
Perché conta sul piano commerciale più che su quello tecnico
Il rischio che i consigli di amministrazione non vedono, sui passaporti, non è fallire un controllo. È scegliere un sistema incapace di scambiare dati con i sistemi che scelgono i tuoi clienti e i tuoi fornitori.
Un passaporto che risponde solo dentro la piattaforma di un fornitore funziona benissimo finché il sistema acquisti di un cliente non vuole leggerlo in automatico, un marketplace non vuole esporlo, o un riciclatore non vuole interrogarlo dieci anni dopo. A quel punto un sistema chiuso smette di essere una decisione di prodotto e diventa qualcosa attorno a cui la tua filiera deve lavorare.
L'architettura di riferimento esiste proprio per evitare quell'esito, ed è il motivo per cui allinearcisi è una copertura più che un adempimento.
Cosa chiedere a un fornitore a riguardo
Tre domande che non ti obbligano a leggere un documento di 97 pagine.
Conoscete l'architettura di riferimento CIRPASS-2, e dove ve ne discostate? La risposta utile nomina uno scostamento e lo spiega. Un fornitore che dichiara pieno allineamento a un documento ancora allo stato di raccomandazione sta esagerando.
Quali categorie pilota avete guardato? I pilota sono pubblici e fanno emergere problemi reali di integrazione, in particolare sullo scambio di dati con i fornitori.
Come gestite gli aggiornamenti inviati da terze parti? Fornitori e riparatori che inviano dati dentro il passaporto di qualcun altro sono il punto in cui l'architettura si fa specifica, e quello in cui le implementazioni divergono di più.
La lacuna che vale la pena notare
Un'osservazione sull'ambito dell'architettura più che una critica: non c'è un blocco costruttivo per la verifica di autenticità rivolta al consumatore, e la contraffazione non è trattata come caso d'uso. La scansione è modellata come modo per raggiungere dati, non come modo per verificare che un prodotto sia autentico.
Quella lacuna è dove si colloca la nostra app per il consumatore, ed è il motivo per cui trattiamo autenticità e passaporto come un unico codice invece che come due sistemi. È un'osservazione su cosa copre il modello di riferimento, non la prova che nessun altro se ne occupi.
Fonti
- CIRPASS-2, *D4.1 Reference Architecture*, versione 1.1, 9 giugno 2026, inclusi i blocchi
- costruttivi del fornitore di servizi DPP e le raccomandazioni architetturali.