Den nye praktiske flaskehals: Hvem må registrere et pas?
EU's DPP-register har været operationelt siden 20. juli 2026. For mange teams stod det tekniske spørgsmål først: Kan en produktidentifikator registreres, og viderestiller databæreren korrekt? Det er nødvendigt, men ikke tilstrækkeligt. Med gennemførelsesforordning (EU) 2026/1778 af 16. juli 2026 får den forudgående identitet sin egen regulatoriske betydning: Verificerede erhvervsaktører skal foretage registreringer, og adgang til registerfunktioner er ikke det samme som offentlig adgang til produktoplysninger.
Det er ikke en anledning til at gøre QR-koder mere komplicerede. Det er en anledning til at modellere ansvar, dokumentation og bemyndigelser korrekt før den første produktive registreringsproces. Den følgende vejledning adskiller disse niveauer og viser, hvad producenter praktisk kan forberede nu.
Tre identiteter, der ikke må blandes sammen
I et DPP-projekt optræder mindst tre forskellige identiteter.
For det første er der erhvervsaktøren: virksomheden eller den enkeltstående erhvervsdrivende, der bringer et produkt i omsætning eller handler i registret. Artikel 4 i forordning 2026/1778 knytter klassificeringen som „verificeret erhvervsaktør“ til et identitetsbevis. For enkeltstående erhvervsdrivende, der er etableret i EU, nævner retsakten eksempelvis en kvalificeret elektronisk signatur eller et eIDAS-kompatibelt elektronisk identifikationsmiddel med højt sikkerhedsniveau. Juridiske personer skal ligeledes verificeres gennem definerede beviser.
For det andet er der den menneskelige bruger. Indkøb, vedligeholdelse af stamdata, compliance, eksterne tjenesteudbydere og en DPP-serviceudbyder handler ikke automatisk med samme bemyndigelse. En brugerkonto er derfor ikke en erstatning for den verificerede virksomhedskontekst. Der er brug for en efterprøvbar tilknytning: Hvem handler på vegne af hvilken erhvervsaktør, med hvilken rolle og indtil hvornår?
For det tredje er der produktidentiteten. En GTIN, et serienummer eller en anden identifikator beskriver produktet eller den krævede granularitet; den dokumenterer ikke, at personen ved skærmen har bemyndigelse til at registrere. ESPR adskiller udtrykkeligt disse sfærer: Databæreren forbinder produktet med passet, mens registret indeholder de entydige identifikatorer og registreringsdata. Kommissionens oversigt over DPP beskriver forløbet tilsvarende: Produktinformationer oprettes og registreres, hvorefter registret genererer et entydigt registrerings-id.
Den, der samler disse tre identiteter i en tabel, et API-token eller en fælles e-mailindbakke, skaber senere en revisions- og driftsrisiko. Det rigtige spørgsmål er ikke „Hvem kender linket?“, men „Hvem må udløse en registerhandling på vegne af denne erhvervsaktør?“.
Offentlig QR-adgang er ikke registerbemyndigelse
En QR-kode på produktet er fortsat en adgang til passet. Den er ikke en loginmekanisme til registret og bør heller ikke blive det. Forbrugere, reparationsvirksomheder, genvindingsvirksomheder og myndigheder har hver især brug for andre oplysninger. Den aktuelle kommissionsvejledning om DPP beskriver udtrykkeligt, at oplysninger er tilgængelige efter brugerroller.
I praksis anbefales derfor en klar lagdeling:
- Det offentlige scan giver en stabil, gratis tilgængelig pasvisning med de oplysninger, der er foreskrevet for den pågældende produktgruppe.
- En rollebegrænset grænseflade administrerer dokumentation, leverandørdata, ændringshistorik og interne godkendelser.
- Registerforbindelsen må kun overføre de nødvendige registreringsdata og knytte et svar fra registret til et konkret produktdatasæt.
Det forhindrer to udbredte fejlopfattelser. For det første: Et „hemmeligt“ QR-link erstatter ikke adgangskontrol; det kan videresendes og er ikke et pålideligt bevis på bemyndigelse. For det andet: Registret er ikke lagersted for al produktdokumentation. Kommissionen forklarer, at de fuldstændige produktoplysninger kan ligge hos erhvervsaktøren eller en DPP-serviceudbyder; de nødvendige metadata og identifikatorer registreres.
Hvad forordningen teknisk lægger op til
Forordning 2026/1778 beskriver ikke registret som en simpel lookup-database. Den nævner blandt andet en API til registrering og modtagelse af data, en platform til bekræftelse af eksistens og fuldstændighed, et skema for entydige registrerings-id'er, et register over verificerede DPP-serviceudbydere, et logsystem samt identifikations- og autorisationsordninger. Datamodeller skal desuden være versionsstyrede.
Disse krav udgør ikke en færdig produktarkitektur. Men de giver robuste retningslinjer:
Virksomhedsprofil før produktimport
Opret et kontrolleret virksomhedsregister, før en masseimport påbegyndes. Det omfatter den juridiske enhed, dens status som erhvervsaktør, det valgte identitetsbevis, tidspunktet for kontrollen og den ansvarlige funktion. Selve beviset bør et DPP-system kun opbevare, i det omfang det er nødvendigt og tilladt; ofte er en kontrolstatus med reference samt logik for udløb eller fornyet vurdering tilstrækkelig.
Delegering er et selvstændigt datasæt
Når en serviceudbyder eller et bureau handler, skal delegeringen have et omfang. Som minimum bør erhvervsaktør, tilladte handlinger, produktgrupper eller mærker, start, slut og tilbagekaldelse angives. En generel API-nøgle uden mandatbegrænsning er for grovkornet til en registreringsrelevant handling.
Registrering som en dokumenterbar proces
For hver registrering bør teams som minimum registrere den lokale produktversion, den indsendte identifikator, svaret inklusive registrerings-id, tidsstempel, den handlende rolle og fejlkategorien. Dermed kan man senere skelne mellem, om et pas var fagligt ufuldstændigt, en identifikator kolliderede, eller bemyndigelsen manglede. Logningen bør ikke blive til indsamling af unødvendige personoplysninger; den skal skabe en ansvarlig og efterprøvbar handlingskæde.
Test bemyndigelser som faglige regler
Testtilfælde bør ikke slutte ved „API svarer 200“. Kontrollér som minimum: En ubemyndiget bruger kan ikke udløse en registrering; en delegeret udbyder kan kun behandle det aftalte mandat; en udløbet delegering afvises; den offentlige pasvisning afslører ingen interne register- eller dokumentationsdata; og en genindsendt proces behandles efterprøvbart som en gentagelse.
En enkel startplan for de kommende uger
Begynd ikke med en fuld migrering. Vælg en lille, repræsentativ produktmængde og en reel ansvarskæde.
- Tildel producent, importør, dataansvarlige og eventuelt serviceudbyder for hvert pilotprodukt.
- Dokumentér, med hvilken metode erhvervsaktøren verificeres, og hvem der godkender kontrollen.
- Definér roller for udkast, faglig godkendelse, registrering og skrivebeskyttet adgang.
- Registrér et testdatasæt med versionsstyrede produktdata, og log registrering, svar og korrektionsforløb.
- Test den offentlige QR-adgang adskilt fra interne roller og registerforbindelsen.
- Øv tilbagekaldelse og skift: Hvad sker der ved skift af tjenesteudbyder, en ændret virksomhedsbetegnelse eller en fejlbehæftet identifikator?
Dette forløb passer også med den allerede offentliggjorte anbefaling om at teste register, resolver og datakilde separat. Det nye fokus er: Før en robust API-integration skal det stå klart, hvilken verificeret organisation og hvilken rolle der er ansvarlig for handlingen.
Hvad der endnu ikke bør hævdes
Registerforordningen skaber den tekniske og organisatoriske ramme. Den gør ikke enhver produktgruppe øjeblikkeligt DPP-pligtig og erstatter ikke sektorspecifikke delegerede retsakter. Kommissionen fastlægger fortsat indførelsen produktgruppe for produktgruppe; efter ESPR-delegerede retsakter er der som udgangspunkt fastsat en overgangsperiode på mindst 18 måneder. En verificeret virksomhedsstatus er heller ikke et fripas til ufuldstændige eller forkerte produktdata.
Konsekvensen for teams er alligevel konkret: Identitet, mandat, roller og logning hører hjemme i DPP-backloggen, før registreringer skaleres. På den måde forbliver QR-koden den enkle offentlige indgang — og registerhandlingen bliver det, den regulatorisk er: en ansvarlig, efterprøvbar handling fra en verificeret erhvervsaktør.
