Digitalt produktpass: utvikling av DPP og batteripass etter ESPR

De fleste virksomheter møter det digitale produktpasset på samme måte: en kunde sender over et spørreskjema, eller en kjede vil vite hvilken identifikator som skal stå på etiketten neste år. Da går det opp for folk at en forordning som internt lå under «bærekraft», i realiteten er et programvareprosjekt med en dato på seg.

Den programvaren bygger vi. Datamodell, identifikatorer, API-et bak QR-koden, integrasjonen mot PLM- eller ERP-systemet der produktdataene allerede ligger, og registreringen EU-registeret forventer. Ikke den juridiske vurderingen av virkeområdet (den tar juristene eller compliance-avdelingen din), men alt som kommer etter den.

Hva et digitalt produktpass faktisk krever

Økodesignforordningen (ESPR, forordning (EU) 2024/1781) erstattet det gamle økodesigndirektivet og utvidet virkeområdet fra energirelaterte produkter til nesten alt som selges i EU. Kjernemekanismen er det digitale produktpasset: et strukturert, maskinlesbart datasett knyttet til et produkt, et parti eller et enkeltstykke, tilgjengelig via en databærer på produktet selv.

Uten forordningsspråket er dette fire tekniske oppgaver:

• En unik identifikator for produkt, modell, parti eller enkeltstykke, tildelt etter en anerkjent ordning og stabil gjennom hele produktets levetid.
• En databærer (i praksis en QR-kode, av og til NFC eller RFID), som løser opp til den identifikatoren. GS1 Digital Link er syntaksen de fleste forsyningskjeder samler seg om, fordi én QR-kode da kan betjene forbrukeren, butikkens skanner og gjenvinneren med hvert sitt svar.
• Et datasett som fastsettes av den delegerte rettsakten for din produktgruppe: materialsammensetning, stoffer som gir grunn til bekymring, levetid og reparerbarhet, andel resirkulert materiale, klimafotavtrykk, tilgang på reservedeler og informasjon om avhending. Ulike felter er synlige for ulike målgrupper, og tilgangsstyring er en del av spesifikasjonen, ikke noe som kommer i tillegg senere.
• En registrering i EUs sentrale register, pluss plikten til å holde passet tilgjengelig i en definert periode: også etter at du har sluttet å selge produktet. Det er mer et drifts- og kontinuitetsspørsmål enn et programmeringsspørsmål.

Rammeverket fikk full anvendelse 19. juli 2026, og EUs sentrale DPP-register ble satt i drift samtidig. Det slo på maskineriet. Det som binder den enkelte virksomheten, er den delegerte rettsakten for dens egen produktgruppe.

Datoene som betyr noe

Den første harde plikten gjelder verken tekstiler eller møbler: den gjelder batterier, og den følger av batteriforordningen, ikke av ESPR selv.

• 18. februar 2027: batteripasset blir obligatorisk etter forordning (EU) 2023/1542 for elbilbatterier, industribatterier over 2 kWh og LMT-batterier (lette transportmidler). Hvert slikt batteri som bringes i omsetning på EU-markedet fra den datoen, må ha et pass tilgjengelig via QR-kode, med klimafotavtrykk, materialsammensetning, andel resirkulert materiale, helsetilstand og informasjon om aktsomhetsvurderinger.
• Fra 2026: den første ESPR-arbeidsplanen (COM(2025) 187) setter jern og stål først blant de prioriterte gruppene, fulgt av tekstiler, dekk og aluminium, deretter møbler og madrasser. Hver produktgruppe får sin egen delegerte rettsakt, og hver rettsakt setter sin egen overgangsperiode: typisk atten måneder til to år fra vedtak til anvendelse.

Lager du batterier eller bygger dem inn i kjøretøy, maskiner eller el-sykler, måles klokka i måneder. Lager du tekstiler, stål, dekk eller møbler, måles den i rettsakter, og det fornuftige nå er å bygge datagrunnlaget i stedet for å vente på den endelige feltlisten.

Hva vi bygger

Produktdatamodell og gap-analyse

Vi starter i dataene du allerede har, ikke i et tomt skjema. De fleste produsenter sitter på sytti prosent av det et pass trenger, spredt over PLM, ERP, leverandørerklæringer, prøverapporter og regneark ingen har åpnet siden forrige revisjon. Vi holder det som finnes opp mot kravene for din produktgruppe, og resultatet er en liste over de feltene du i dag ikke kan produsere, med kilden hvert enkelt felt måtte komme fra, som regel en leverandør som aldri har blitt spurt.

Det dokumentet er ofte mer verdt enn programvaren som følger etter, fordi det gjør en diffus compliance-bekymring om til en innkjøpsoppgave med navn på.

Identifikator og databærer

Vi implementerer identifikatorordningen (GS1 GTIN med serie- eller partikvalifikatorer, eller en alternativ ordning der bransjen din bruker en slik), og genererer de oppløsbare lenkene bak den. Der én QR-kode må betjene flere målgrupper, bygger vi resolveren slik at forbrukerens mobil, butikkens system og gjenvinnerens skanner hver får det svaret som er ment for dem, med de beskyttede feltene bak autentisert tilgang.

Selve passtjenesten

Et produktpass er et API og en offentlig visning, ikke en PDF. Vi bygger begge deler: en tjeneste som holder passdataene, versjonerer dem, leverer dem ut under identifikatoren og viser dem lesbart på de språkene markedene dine krever. Den må være tilgjengelig og korrekt i mange år, og derfor bygger vi den som en liten, kjedelig, godt overvåket tjeneste, ikke som en funksjon inne i noe større som kan bli faset ut.

Integrasjon mot systemene du allerede har

Passdata må mates inn, ikke tastes. Vi bygger integrasjonene mot SAP, Dynamics, Odoo, Infor og egenutviklede ERP-systemer, mot PLM-systemer som Siemens Teamcenter eller PTC Windchill, og mot leverandørportalene og kvalitetssystemene som holder resten. Der leverandører sender data på e-post og i regneark (og det er normalen i starten) bygger vi mottaks- og valideringslaget som gjør det om til strukturerte poster uten at noen taster om igjen.

Registrering og dokumentasjon

Vi tar den tekniske siden av å registrere pass i EU-registeret, holder registreringen i takt med produktendringer og produserer sporet som viser hva som ble publisert når. Der kundene dine kjører sine egne forespørsler om forsyningskjededata, bygger vi eksportveiene slik at det å svare på dem ikke blir et prosjekt hver gang.

Hva dette ikke er

Vi selger ikke en DPP-plattform med lisens per produkt. Det finnes etter hvert en del av dem, og for en virksomhet med et oversiktlig sortiment og ryddige data er en av dem ofte det riktige svaret: da sier vi det.

Det vi gjør, er tilfellene slike plattformer håndterer dårlig: produkter med kompliserte stykklister, data spredt over systemer som aldri var ment å snakke sammen, identifikatorordninger som må leve side om side med en eksisterende merking, eller produsenter som av hensyn til datasuverenitet vil ha passtjenesten i sin egen infrastruktur.

Vi gir heller ikke juridiske råd om virkeområde, klassifisering eller samsvar. Vi jobber sammen med dem som gjør det.

Bransjer vi jobber med

Batteri- og e-mobilitetsprodusenter med februar 2027 foran seg: produsenter av kjøretøy, el-sykler, scootere og industrielle energilagre, og celleleverandørene bak dem.

Tekstil- og klesmerker som forbereder seg på den delegerte rettsakten for tekstiler, der det vanskelige nesten alltid ligger i forsyningskjededataene og ikke i passet.

Stål, aluminium og byggevarer, der miljødeklarasjoner og materialpass allerede finnes i en eller annen form, og arbeidet består i å stemme dem av mot ESPR-datamodellen.

Elektronikk og hvitevarer, som ligger i skjæringspunktet mellom ESPR, Cyber Resilience Act og eksisterende energimerking, og som stort sett vil kjøre ett dataprogram i stedet for tre.

Møbler, dekk og forbruksvarer, der rettsaktene ligger lenger fram, og der det fornuftige nå er identifikatorordningen og datastrømmen.

Slik pleier et oppdrag å gå

Første steg er kort og til fastpris: et forprosjekt for produktpass, vanligvis to til tre uker. Vi går gjennom produktstruktur, datakilder og gjeldende krav, og leverer gap-analyse, forslag til datamodell, anbefaling om identifikator og databærer, og en kostnadsberegnet plan.

Deretter kjører de fleste en pilot på én produktlinje: én SKU-familie, hele veien fra datainnhenting til en skannbar QR-kode og en registeroppføring. En pilot prøver modellen mot virkeligheten, og det er da du finner ut at en leverandør ikke kan oppgi andelen resirkulert materiale, og at noen må ta en beslutning om det.

Så kommer utrullingen, produktgruppe for produktgruppe, med bredere integrasjoner og gradvis mindre manuell registrering. Til slutt er det enten dokumentert overlevering til teamet ditt, eller videre drift hos oss under en supportavtale: pass må være tilgjengelige lenge etter at prosjektet er over, og noen må eie det.

Standarder og rammeverk vi arbeider etter

• ESPR, forordning (EU) 2024/1781, og de delegerte rettsaktene som vedtas under den
• Batteriforordningen (EU) 2023/1542, artikkel 77 og vedlegg XIII
• GS1 Digital Link, GTIN og GS1 EPCIS der sporbarhet kreves
• CIRPASS-referansearkitekturen og de kommende standardene fra CEN/CENELEC JTC 24
• ISO/IEC 15459 for identifikatorer, ISO 14040/14044 der klimadata går inn i passet
• W3C Verifiable Credentials, der dataenes ekthet mellom partnere i forsyningskjeden må kunne bevises

Teknologi

Tjenester i Node.js, Python, Go og Java; PostgreSQL og event-sourcing der passhistorikken må kunne rekonstrueres; REST- og GraphQL-API-er; AWS, Azure og europeisk suveren drift, inkludert on-premise der det kreves. Vi bygger for at tjenesten skal kjøre i din skykonto, ikke i vår, med mindre du heller vil at vi drifter den.

Ofte stilte spørsmål

Når blir det digitale produktpasset obligatorisk?

Det finnes ingen enkelt dato. ESPR fikk full anvendelse 19. juli 2026 og EU-registeret er i drift, men plikten for et konkret produkt starter først når den delegerte rettsakten for produktgruppen får anvendelse. Det første obligatoriske passet er batteripasset, 18. februar 2027, etter batteriforordningen. Jern og stål, tekstiler, dekk og aluminium følger gjennom ESPR-arbeidsplanen, hver med sin egen overgangsperiode.

Gjelder det digitale produktpasset oss når vi ikke er et EU-selskap?

Bringer du produkter i omsetning på EU-markedet, ja. Plikten treffer markedsdeltakeren som setter produktet i omløp i EU, og det kan være importøren din eller en autorisert representant, men dataene må komme fra deg, og i praksis er det produsenten som bygger passet.

Kan vi ikke bare sette en QR-kode på etiketten som peker til produktsiden vår?

Nei. Passet må bære et definert datasett i maskinlesbar form, bruke en identifikator fra en anerkjent ordning, være registrert i EU-registeret, forbli tilgjengelig i en fastsatt periode og vise ulike felter til ulike målgrupper. En markedsføringsside bak en QR-kode oppfyller ingenting av dette.

Vi publiserer allerede miljødeklarasjoner. Er ikke det nok?

Det er et godt utgangspunkt, og det betyr som regel at de vanskeligste dataene allerede er samlet inn. Arbeidet som gjenstår, er å avbilde dem på passdatamodellen, gi produktene stabile identifikatorer og bygge tjenesten som leverer dataene på forespørsel i stedet for som en PDF til nedlasting.

Hvor lang tid tar en implementering?

En pilot på én produktlinje tar vanligvis seks til ti uker etter et fullført forprosjekt. Full utrulling over et sortiment avhenger langt mer av datatilgjengelighet enn av utvikling, og innhenting av leverandørdata er nesten alltid den kritiske linjen.

Hvor ligger passdataene?

Der du trenger at de ligger. Vi bygger tjenesten for å kjøre i din egen AWS- eller Azure-konto, i europeisk suveren infrastruktur eller on-premise. EU-registeret holder registreringsoppføringer, ikke produktdataene dine.

Kom i gang

Send oss produktsortimentet ditt og gruppen du tror du hører inn under, så sier vi om en passplikt sannsynligvis treffer deg, når, og hvordan dataene dine måtte se ut. Er det ærlige svaret at en hyllevareplattform tjener deg bedre, sier vi det også.

Kontakt oss for å avtale et forprosjekt for digitalt produktpass.

Relaterte tjenester

• EU-markedsinngang utvikling: resten av compliance-stakken for salg inn i Europa
• Vedlikehold av eldre systemkode: når produktdataene sitter fast i et system ingen vil ta i
• Bemanningsforsterkning og outsourcing: ingeniører som går inn i teamet ditt så lenge programmet varer