De nieuwe praktische bottleneck: wie mag een paspoort registreren?
Het EU-DPP-register is sinds 20 juli 2026 operationeel. Voor veel teams stond aanvankelijk de technische vraag centraal: kan een productidentifier worden geregistreerd en verwijst de gegevensdrager correct door? Dat is noodzakelijk, maar onvolledig. Met de Uitvoeringsverordening (EU) 2026/1778 van 16 juli 2026 krijgt de voorafgaande identiteit een eigen regelgevingsbetekenis: registreren moeten geverifieerde economische actoren, en toegang tot registerfuncties is niet hetzelfde als openbare toegang tot productinformatie.
Dit is geen reden om QR-codes ingewikkelder te maken. Het is wel een reden om verantwoordelijkheden, bewijsstukken en bevoegdheden vóór het eerste productieve registratieproces zorgvuldig te modelleren. De volgende handleiding scheidt deze niveaus en laat zien wat fabrikanten nu praktisch kunnen voorbereiden.
Drie identiteiten die niet met elkaar mogen worden vermengd
In een DPP-project komen minstens drie verschillende identiteiten voor.
Ten eerste is er de economische actor: de onderneming of eenmanszaak die een product in de handel brengt of in het register handelt. Artikel 4 van Verordening 2026/1778 koppelt de kwalificatie als ‘verified economic operator’ aan een identiteitsbewijs. Voor in de EU gevestigde eenmanszaken noemt de rechtshandeling bijvoorbeeld een gekwalificeerde elektronische handtekening of een eIDAS-conform elektronisch identificatiemiddel met een hoog betrouwbaarheidsniveau. Rechtspersonen moeten eveneens aan de hand van vastgestelde bewijsstukken worden geverifieerd.
Ten tweede is er de menselijke gebruiker. Inkoop, stamgegevensbeheer, compliance, externe dienstverleners en een DPP-serviceprovider handelen niet automatisch met dezelfde bevoegdheid. Een gebruikersaccount is daarom geen vervanging voor de geverifieerde bedrijfscontext. Er is een traceerbare toewijzing nodig: wie handelt namens welke economische actor, met welke rol en tot wanneer?
Ten derde is er de productidentiteit. Een GTIN, serienummer of andere identifier beschrijft het product of de vereiste granulariteit; deze toont niet aan dat de persoon achter het scherm bevoegd is om te registreren. Het ESPR scheidt deze sferen uitdrukkelijk: de gegevensdrager verbindt het product met het paspoort, terwijl het register de unieke identificatoren en registratiegegevens bijhoudt. Het overzicht van de Commissie over het DPP beschrijft het proces overeenkomstig: productinformatie wordt aangemaakt en geregistreerd, waarna het register een unieke registratie-ID genereert.
Wie deze drie identiteiten samenvoegt in één tabel, API-token of gedeelde e-mailinbox, creëert later een audit- en operationeel risico. De juiste vraag luidt niet ‘Wie kent de link?’, maar ‘Wie mag namens deze economische actor een registerhandeling starten?’.
Openbare QR-toegang is geen registerbevoegdheid
Een QR-code op het product blijft een toegang tot het paspoort. Het is geen inlogmechanisme voor het register en mag dat ook niet worden. Consumenten, reparatiebedrijven, recyclers en overheidsinstanties hebben elk andere informatie nodig. De actuele leidraad van de Commissie voor het DPP beschrijft uitdrukkelijk dat informatie toegankelijk is op basis van gebruikersrollen.
Praktisch is daarom een duidelijke scheiding in lagen aan te bevelen:
- De openbare scan levert een stabiele, kosteloos bereikbare paspoortweergave met de voor de betreffende productgroep voorgeschreven informatie.
- Een interface met rolbeperkingen beheert bewijsstukken, leveranciersgegevens, wijzigingsgeschiedenissen en interne goedkeuringen.
- De registerconnector mag alleen de vereiste registratiegegevens doorgeven en een antwoord van het register aan een concrete productregistratie koppelen.
Dit voorkomt twee veelvoorkomende misvattingen. Ten eerste: een ‘geheime’ QR-link vervangt geen toegangscontrole; deze kan worden doorgestuurd en is geen betrouwbaar bewijs van bevoegdheid. Ten tweede: het register is niet de opslagplaats voor alle productdocumentatie. De Commissie licht toe dat de volledige productinformatie bij de economische actor of een DPP-serviceprovider kan staan; geregistreerd worden de vereiste metadata en identificatoren.
Wat de verordening technisch suggereert
Verordening 2026/1778 beschrijft het register niet als een eenvoudige opzoekdatabase. Ze noemt onder meer een API voor registratie en gegevensontvangst, een platform voor het bevestigen van bestaan en volledigheid, een schema voor unieke registratie-ID’s, een register van geverifieerde DPP-serviceproviders, een logsysteem en identificatie- en autorisatieschema’s. Datamodellen moeten bovendien worden geversioneerd.
Uit deze voorschriften volgt geen kant-en-klare productarchitectuur. Ze bieden wel robuuste uitgangspunten:
Bedrijfsprofiel vóór productimport
Maak vóór een bulkimport een gecontroleerde bedrijfsregistratie aan. Daaronder vallen de juridische eenheid, de status als economische actor, het gekozen identiteitsbewijs, het tijdstip van de controle en de verantwoordelijke afdeling. Het bewijsstuk zelf mag een DPP-systeem alleen opslaan voor zover dat noodzakelijk en toegestaan is; vaak volstaat een controlestatus met referentie en een logica voor vervaldatum of herbeoordeling.
Delegatie is een afzonderlijk gegevensrecord
Wanneer een serviceprovider of agentschap optreedt, moet de delegatie een reikwijdte hebben. Minimaal zijn de economische actor, toegestane acties, productgroepen of merken, begin, einde en intrekking zinvol. Een algemene API-sleutel zonder mandaatgrens is voor een registratiegerelateerde handeling te ruim.
Registratie als aantoonbaar proces
Per registratie moeten teams minimaal de lokale productversie, de verzonden identifier, het antwoord inclusief registratie-ID, tijdstempel, handelende rol en foutklasse vastleggen. Zo kan later worden onderscheiden of een paspoort inhoudelijk onvolledig was, een identifier botste of de bevoegdheid ontbrak. De logging mag niet ontaarden in het verzamelen van onnodige persoonsgegevens; zij moet een verantwoordelijke, controleerbare keten van handelingen creëren.
Bevoegdheden testen zoals bedrijfsregels
Testgevallen mogen niet eindigen bij ‘API antwoordt 200’. Controleer minimaal: een onbevoegde gebruiker kan geen registratie starten; een gedelegeerde provider kan alleen het overeengekomen mandaat uitvoeren; een verlopen delegatie wordt afgewezen; de openbare paspoortweergave onthult geen interne register- of bewijsgegevens; en een opnieuw ingediende handeling wordt traceerbaar als herhaling behandeld.
Een beknopt startplan voor de komende weken
Begin niet met een volledige migratie. Kies een kleine, representatieve producthoeveelheid en een echte verantwoordelijkheidsketen.
- Wijs voor elk pilotproduct de fabrikant, de marktdeelnemer die het product in de handel brengt, de gegevensverantwoordelijke en eventueel de serviceprovider toe.
- Documenteer volgens welke procedure de economische actor wordt geverifieerd en wie de controle goedkeurt.
- Definieer rollen voor ontwerp, inhoudelijke goedkeuring, registratie en uitsluitend leesrechten.
- Registreer een testrecord met geversioneerde productgegevens en leg registratie, antwoord en correctiepad vast.
- Test de openbare QR-toegang afzonderlijk van interne rollen en de registerconnector.
- Oefen intrekking en wijziging: wat gebeurt er bij een wisseling van dienstverlener, een gewijzigde bedrijfsnaam of een foutieve identifier?
Deze werkwijze sluit ook aan bij de al gepubliceerde aanbeveling om register, resolver en gegevensbron afzonderlijk te testen. Nieuw is de nadruk: vóór een robuuste API-integratie moet duidelijk zijn welke geverifieerde organisatie en welke rol verantwoordelijk is voor de handeling.
Wat nog niet beweerd moet worden
De registerverordening schept het technische en organisatorische kader. Ze maakt niet elke productgroep onmiddellijk DPP-plichtig en vervangt geen sectorspecifieke gedelegeerde handelingen. De Commissie deelt de invoering nog steeds per productgroep in; volgens ESPR-gedelegeerde handelingen is in beginsel een overgangsperiode van ten minste 18 maanden voorzien. Evenmin is een geverifieerde bedrijfsstatus een vrijbrief voor onvolledige of onjuiste productgegevens.
Voor teams is de consequentie desondanks concreet: identiteit, mandaat, rollen en logging horen in de DPP-backlog voordat registraties opschalen. Zo blijft de QR-code de eenvoudige openbare ingang — en wordt de registerhandeling wat deze regelgevend gezien is: een verantwoordelijke, traceerbare actie van een geverifieerde economische actor.
