Hvorfor et arkitekturemne nu kommer på dagsordenen
Det digitale produktpas indføres gradvist i Europa gennem sektorspecifikke retsakter. Det kan let give virksomheder indtryk af, at hver produktgruppe har brug for sin egen datamodel, sin egen databærer og sin egen integrationslogik. Det er netop ved denne grænseflade, at arbejdet i ISO/IEC JTC 5 begynder: Den fælles tekniske komité blev oprettet i 2026 og skal udarbejde grundlaget for sektor- og systemuafhængig DPP-interoperabilitet. Det første annoncerede møde finder sted fra den 7. til den 9. september 2026 i Berlin. ISO/IEC JTC 5 beskriver udtrykkeligt sit mandat som en ramme for DPP-systemer og DPP-økosystemer; sektorspecifikke standarder forbliver hos de ansvarlige fagudvalg.
Det er hverken et nyt lovkrav eller en offentliggjort ISO-standard. Det er dog en solid anledning til at adskille sin egen arkitektur fra kortsigtede datafelter. Det første arbejdspunkt, ISO/AWI 25534-1, befinder sig stadig på projektstadiet 10.99; projektet blev godkendt den 12. februar 2026. Ifølge ISO handler det om begreber, grundprincipper, datakategorier samt governance- og tillidsmekanismer. Det offentlige projektopslag angiver udtrykkeligt „under development“. Den, der allerede nu udleder et certificeringskrav eller et færdigt udvekslingsformat heraf, går for langt.
Hvad den internationale ramme adskiller fra EU-kravene
EU fastlægger allerede konkrete retningslinjer. Kommissionen forklarer, at DPP gør produktrelaterede oplysninger tilgængelige i en decentral model: De fuldstændige data forbliver hos den erhvervsdrivende eller hos DPP-serviceudbyderen; registret fører entydige identifikatorer og foreskrevne registreringsdata. En databærer som en QR-kode forbinder det fysiske produkt med dets pas. Kommissionens DPP-side nævner desuden forskellige adgange for roller og sektorvise tidsplaner.
Dertil kommer de europæiske harmoniserede standarder. Gennemførelsesafgørelse (EU) 2026/1736 af 14. juli 2026 henviser til seks DPP-standarder, blandt andet om identifikatorer, interoperabilitet, databærere, API'er, dataudveksling og datalagring. Deres rolle er konkret: For de krav, de dækker, kan overholdelse understøtte formodningen om overensstemmelse efter artikel 10 og 11 i ESPR.
JTC 5 erstatter ikke disse niveauer. Det arbejder oven over dem: En sektorneutral ramme skal bidrage til at forklare, hvordan begreber, datakategorier, tillid og governance hænger sammen mellem systemer. Den praktiske konsekvens er vigtig. En producent bør ikke vente på en fremtidig ISO-udgave med at stille sine batteri-, tekstil- eller ståldata til rådighed. Producenten bør dog undgå at fastlåse nutidens branchefelter som en uforanderlig kerne i en virksomheds-dækkende DPP-model.
Tre arkitekturbeslutninger, der giver mening allerede i dag
1. Adskil stabil identitet fra faglige profiler
Et pas har brug for en langtidsholdbar teknisk identitet: produkt, variant, parti eller enkeltstykke; ansvarlig erhvervsdrivende; opslag via databæreren. Retsgrundlaget bestemmer derefter, hvilke faglige oplysninger der er nødvendige. Disse faglige oplysninger hører hjemme i versionerede profiler. Et batterimodul til CO₂- eller State-of-Health-data er derfor ikke et generelt basisskema. Materiale-, reparations- eller genanvendelsesdata må heller ikke ende som ustruktureret fritekst i et generelt pas.
I praksis betyder det, at et stabilt kerne-ID, en dokumenteret profilidentifikator og en profilversion hører sammen. Hver leveret pasvisning bør gøre det muligt at se, hvilken profil og hvilken version der bestemte indholdet. På den måde kan teams følge en retsakt, en branchebestemmelse eller senere en standard uden at omskrive historiske data eller URL'er.
2. Modellér dataoprindelse og adgang separat
Interoperabilitet er ikke kun et JSON-format. Den afhænger af, om en modtager kan vurdere en oplysnings oprindelse, gyldighed og rolle. Gem derfor som minimum kilde, gyldighedsområde, registreringstidspunkt, ansvarlig part og faglig version for hvert dataelement eller hver datapakke. En intern kvalitetsværdi er noget andet end en juridisk bindende overensstemmelseserklæring; en leverandøroplysning er noget andet end en måleværdi.
Den anden del er adgangen. Kommissionen beskriver forskellige informationsadgange for forbrugere, reparationsvirksomheder, genanvendelsesvirksomheder og myndigheder. Det kræver en bevidst adskillelse mellem offentlig pasvisning, autoriseret faglig adgang og internt arbejdsområde. En URL må ikke blive til en tilladelse. Roller, mandater, datakategorier og beslutninger, der kan logges, skal kontrolleres på serversiden.
3. Test udvekslingsgrænser som kontrakter
Et DPP-system har flere overgange: ERP eller PLM leverer stamdata, leverandører leverer dokumentation, en serviceudbyder hoster data, et register modtager metadata, og eksterne brugere læser en offentlig eller beskyttet visning. For hver overgang er der brug for en maskinlæsbar kontrakt: tilladte felter, identifikatorer, semantik, fejlsituationer, versionering og bagudkompatibilitet.
Det kan allerede testes nu. Relevante testtilfælde er ukendte profilversioner, udløbet dokumentation, manglende dataoprindelse, uautoriserede roller, dobbeltregistrering og en databærer, der peger på et pas, som ikke længere er tilgængeligt. Testen beviser endnu ikke overensstemmelse med en fremtidig ISO-standard. Den skaber dog den dokumenterbarhed, der mangler ved en senere omlægning, hvis datamodel og rettigheder allerede er blandet uløseligt sammen.
En 90-dages arbejdsplan uden spekulation
I de næste 30 dage kan det betale sig at skabe et overblik: Hvilke produktidentifikatorer findes, hvilke dataprofiles bruges faktisk, og hvilke data findes kun i dokumenter? Derefter følger en arkitekturbeslutning: kernemodel, profilregister, oprindelsesmodel og adgangsmatrix. I et tredje trin bør et reelt produkt føres gennem alle overgange — fra kildesystemet via passet til reparationsvirksomhedens eller myndighedens rolle.
Grænserne skal samtidig være tydelige. ISO/AWI 25534-1 er ikke en færdig standard; der findes ingen offentliggjorte klausuler, som teams kan implementere. Kommissionens tidslinje er også vejledende og erstatter ikke en gennemgang af den retsakt, der gælder for den pågældende produktgruppe. Værdien af at følge udviklingen ligger derfor ikke i et afkrydset punkt på en compliance-liste, men i en arkitektur, der kan optage nye profiler, roller og udvekslingsregler på en ordentlig måde.
