kan ik nu al een testversie van mijn productpaspoort laten maken

Wat u concreet moet doen

Wat er van u wordt verwacht

De letterlijke vraag — kan ik nu al een testversie laten maken — heeft geen wettelijk antwoord, want er is nog geen verplichting om aan te toetsen. De gedelegeerde handeling voor ijzer en staal is er nog niet, en artikel 18 van de ESPR (Verordening (EU) 2024/1781) is precies het artikel dat regelt hoe de Europese Commissie productgroepen prioriteert en de inhoud van die handelingen voorbereidt. Zolang die handeling niet gepubliceerd is, ligt er geen verplichte dataset, geen verplicht format en geen verplichte QR-drager vast om tegen te testen. Wat er wél is: de artikelen die de algemene vorm van het digitaal productpaspoort beschrijven, en die vorm verandert niet meer wezenlijk, ook al is de inhoud per productgroep nog open.

Artikel 9: weten wat een paspoort moet kunnen

Artikel 9 van de ESPR beschrijft wat een digitaal productpaspoort in algemene zin is en moet kunnen: gegevens koppelen aan een specifiek product of productmodel, toegankelijk maken via een datadrager, en gedurende een bepaalde periode beschikbaar blijven. Voor een bedrijf van 10 tot 100 medewerkers betekent dit vooral dat een testversie zich kan richten op de structuur — welke gegevens hangen aan welk product, wie mag ze zien, hoe wordt de koppeling met een fysieke coil, plaat of profiel gelegd — zonder dat de exacte inhoud al vaststaat. Dat is precies het soort voorbereiding dat je kunt doen terwijl de regels nog niet definitief zijn.

Artikel 10: weten welke eisen aan de drager en de data worden gesteld

Artikel 10 van de ESPR gaat over de technische vereisten: interoperabiliteit, toegankelijkheid, en de manier waarop gegevens raadpleegbaar moeten zijn zonder dat degene die ze bekijkt afhankelijk is van één leverancier. Voor een testtraject is dit het artikel dat bepaalt of een pilot "toekomstbestendig" aanvoelt: een testversie die gebaseerd is op een gesloten, niet-overdraagbare drager loopt het risico dat hij bij publicatie van de definitieve handeling opnieuw gebouwd moet worden. Een testversie die uitgaat van open, overdraagbare data sluit beter aan bij wat artikel 10 beoogt, ook al ligt de exacte norm nog niet vast.

Artikel 38: weten wie in de keten welke gegevens aanlevert

Artikel 38 van de ESPR beschrijft de vereisten voor actoren in de toeleveringsketen: wie welke informatie moet doorgeven aan wie, en in welke vorm. Voor een staalhandel of metaalverwerker is dit relevant omdat een testversie van een paspoort zonder betrouwbare herkomstgegevens van de fabrikant of importeur weinig voorstelt. Een pilot kan dus prima getest worden op basis van de gegevens die vandaag al binnenkomen bij inkoop — certificaten, materiaalspecificaties, herkomstverklaringen — om te zien of die gegevensstroom al geschikt is om straks in een paspoort te landen.

Waar het misgaat in de praktijk

Een eerste situatie die vaak misgaat: een bedrijf laat een testpaspoort bouwen rond een sjabloon dat is afgekeken van een andere sector, bijvoorbeeld textiel of elektronica, zonder te kijken of dat aansluit bij wat voor staal relevant is. Het resultaat werkt technisch, maar moet bij publicatie van de sectorspecifieke handeling grotendeels opnieuw.

Een tweede situatie: de testversie wordt gebouwd op basis van gegevens die intern al lang niet meer klopten, zoals een oude leverancierslijst of een verouderde certificeringsstatus. De pilot ziet er dan goed uit, maar zegt weinig over of het bedrijf straks echt klaar is, omdat de onderliggende data niet is opgeschoond.

Een derde situatie: bedrijven testen alleen de QR-code en de weergave, maar niet het proces daarachter — wie in de organisatie de gegevens actueel houdt, wie verantwoordelijk is bij een fout, en wat er gebeurt als een klant om aanvullende informatie vraagt. Een testversie die alleen het "voorkant" van het paspoort simuleert, zegt weinig over de vraag hoe train ik mijn personeel om met het productpaspoort te werken, en die vraag komt onvermijdelijk terug zodra het paspoort verplicht wordt.

Een vierde situatie: een bedrijf met meerdere vestigingen laat op één locatie een testversie bouwen en neemt aan dat die zich later automatisch laat opschalen. Of dat zo werkt hangt af van hoe centraal de gegevensverwerking is ingericht; dat is een vraag die apart aandacht verdient, zie hoe regel ik het productpaspoort als ik meerdere vestigingen heb.

Een vijfde situatie: het testtraject wordt gezien als eindpunt in plaats van oefening. Er wordt een demo gebouwd, gepresenteerd aan het management, en vervolgens blijft die demo liggen tot de regels definitief zijn — waarna blijkt dat de dataset intussen alweer verouderd is.

Wat u kunt vastleggen

• Een overzicht van welke productgegevens vandaag al beschikbaar zijn per materiaalsoort of productlijn, en welke daarvan afkomstig zijn van de fabrikant of importeur zoals bedoeld in artikel 38 van de ESPR.
• Een beschrijving van de huidige gegevensstroom: waar komen certificaten en herkomstinformatie binnen, wie beheert ze, en in welk systeem staan ze.
• Een notitie over welke testversie is gekozen (welk platform, welke standaard) en waarom, zodat bij publicatie van de definitieve handeling snel te beoordelen is wat overeind kan blijven.
• Een lijst van aannames die in de testversie zijn gedaan over dataveldstructuur en toegankelijkheid, te toetsen aan artikel 9 en artikel 10 van de ESPR zodra de sectorspecifieke handeling verschijnt.
• Afspraken over wie in de organisatie de pilot beheert en wie verantwoordelijk is voor het actueel houden van de onderliggende gegevens.

Voor een overzicht van de stappen die hierbij passen, ook los van een concrete testversie, is er de vraag hoe pak ik het productpaspoort voor staal stap voor stap aan. En voor bedrijven die zich afvragen of zo'n testtraject al ergens op een gedeelde standaard kan aansluiten, is relevant of er al een gemeenschappelijke lijn is binnen de sector, zie is er al een branchestandaard voor het productpaspoort van staal.