Uusi käytännön pullonkaula: kuka saa rekisteröidä passin?
EU:n DPP-rekisteri on ollut toiminnassa 20. heinäkuuta 2026 lähtien. Monissa tiimeissä etusijalla oli aluksi tekninen kysymys: voidaanko tuotetunniste rekisteröidä ja ohjautuuko tietoväline oikein? Se on tarpeen, mutta ei riitä. Täytäntöönpanoasetuksella (EU) 2026/1778, joka annettiin 16. heinäkuuta 2026, edeltävä henkilöllisyys saa oman sääntelymerkityksensä: rekisteröijien tulee olla varmennettuja taloudellisia toimijoita, eikä rekisteritoimintojen käyttö ole sama asia kuin julkinen pääsy tuotetietoihin.
Tämä ei ole syy tehdä QR-koodeista monimutkaisempia. Se on syy mallintaa vastuut, todisteet ja valtuudet huolellisesti ennen ensimmäistä tuotantorekisteröintiä. Seuraava opas erottaa nämä tasot toisistaan ja näyttää, mitä valmistajat voivat nyt käytännössä valmistella.
Kolme identiteettiä, joita ei saa sekoittaa
DPP-hankkeessa esiintyy vähintään kolme erilaista identiteettiä.
Ensinnäkin on taloudellinen toimija: yritys tai yksityinen elinkeinonharjoittaja, joka saattaa tuotteen markkinoille tai toimii rekisterissä. Asetuksen 2026/1778 4 artikla liittää luokittelun ”varmennetuksi taloudelliseksi toimijaksi” henkilöllisyyden todentamiseen. EU:ssa toimiville yksityisille elinkeinonharjoittajille säädöksessä mainitaan esimerkiksi hyväksytty sähköinen allekirjoitus tai eIDAS-yhteensopiva sähköinen tunnistusväline, jonka luottamustaso on korkea. Myös oikeushenkilöt on varmennettava määriteltyjen todisteiden avulla.
Toiseksi on henkilökohtainen käyttäjä. Hankinta, perustietojen ylläpito, vaatimustenmukaisuus, ulkoiset palveluntarjoajat ja DPP-palveluntarjoaja eivät automaattisesti toimi samoin valtuuksin. Käyttäjätili ei siksi korvaa varmennettua yritysyhteyttä. Tarvitaan jäljitettävä yhteys: kuka toimii minkä taloudellisen toimijan puolesta, missä roolissa ja mihin asti?
Kolmanneksi on tuotteen identiteetti. GTIN, sarjanumero tai muu tunniste kuvaa tuotetta tai vaadittua tarkkuustasoa; se ei todista, että näytön ääressä oleva henkilö on oikeutettu rekisteröintiin. ESPR erottaa nämä alueet nimenomaisesti: tietoväline yhdistää tuotteen passiin, kun taas rekisteri säilyttää yksiselitteiset tunnisteet ja rekisteröintitiedot. Komission DPP-yleiskatsaus kuvaa menettelyn vastaavasti: tuotetiedot luodaan ja rekisteröidään, minkä jälkeen rekisteri muodostaa yksilöllisen rekisteröintitunnuksen.
Jos nämä kolme identiteettiä yhdistetään samaan taulukkoon, API-avaimeen tai yhteiseen sähköpostilaatikkoon, myöhemmin syntyy auditointi- ja toimintariski. Oikea kysymys ei ole ”Kuka tuntee linkin?”, vaan ”Kuka saa käynnistää rekisteritoimen tämän taloudellisen toimijan nimissä?”.
Julkinen QR-käyttö ei ole rekisteröintivaltuus
Tuotteessa oleva QR-koodi on edelleen pääsy passiin. Se ei ole rekisterin kirjautumismekanismi, eikä siitä pidä sellaista tehdä. Kuluttajat, korjaamot, kierrättäjät ja viranomaiset tarvitsevat kukin erilaisia tietoja. Nykyisessä komission DPP-oppaassa todetaan nimenomaisesti, että tiedot ovat saatavilla käyttäjäroolien mukaan.
Käytännössä suositeltavaa on siksi erottaa kerrokset selvästi:
- Julkinen skannaus avaa vakaan ja maksutta käytettävissä olevan passinäkymän, jossa ovat kyseiselle tuoteryhmälle määrätyt tiedot.
- Roolirajoitettu käyttöliittymä hallinnoi todisteita, toimittajatietoja, muutoshistoriaa ja sisäisiä hyväksyntöjä.
- Rekisteriliitin saa välittää vain tarvittavat rekisteröintitiedot ja yhdistää rekisterin vastauksen tiettyyn tuotetietueeseen.
Tämä estää kaksi yleistä väärinkäsitystä. Ensinnäkin ”salainen” QR-linkki ei korvaa käyttöoikeuksien hallintaa: sen voi välittää eteenpäin, eikä se ole luotettava valtuustodiste. Toiseksi rekisteri ei ole kaikkien tuotetietojen säilytyspaikka. Komissio selittää, että täydelliset tuotetiedot voivat olla taloudellisen toimijan tai DPP-palveluntarjoajan hallussa; rekisteriin tallennetaan tarvittavat metatiedot ja tunnisteet.
Mitä asetus antaa ymmärtää teknisesti
Asetuksessa 2026/1778 rekisteriä ei kuvata pelkkänä hakutietokantana. Siinä mainitaan muun muassa rekisteröinnin ja tietojen vastaanoton API, olemassaolon ja täydellisyyden vahvistamiseen tarkoitettu alusta, yksilöllisten rekisteröintitunnusten rakenne, varmennettujen DPP-palveluntarjoajien hakemisto, lokijärjestelmä sekä tunnistus- ja valtuutusjärjestelmät. Myös tietomallit on versioitava.
Näistä vaatimuksista ei seuraa valmista tuotearkkitehtuuria. Ne tarjoavat kuitenkin vankat suuntaviivat:
Yritysprofiili ennen tuotteiden tuontia
Luokaa hallittu yritystietue ennen massatuontia. Siihen kuuluvat oikeushenkilö, sen asema taloudellisena toimijana, valittu henkilöllisyyden todentamismenetelmä, tarkastusajankohta ja vastuullinen taho. Todisteen itsensä tulisi olla DPP-järjestelmässä vain siltä osin kuin se on tarpeen ja sallittua; usein tarkastustila viitteineen ja vanhenemis- tai uudelleenarviointilogiikka riittää.
Valtuutus on oma tietueensa
Jos palveluntarjoaja tai toimisto toimii puolesta, valtuutukselle on määriteltävä laajuus. Vähintään kannattaa määrittää taloudellinen toimija, sallitut toimet, tuoteryhmät tai brändit, alku, loppu ja peruutus. Yleinen API-avain ilman toimeksiannon rajausta on rekisteröinnin kannalta liian karkea.
Rekisteröinti todennettavana tapahtumana
Kustakin rekisteröinnistä tiimien tulisi säilyttää vähintään paikallinen tuotteen versio, välitetty tunniste, vastaus rekisteröintitunnuksineen, aikaleima, toimiva rooli ja virheluokka. Näin voidaan myöhemmin erottaa, oliko passi sisällöllisesti puutteellinen, törmäsikö tunniste toiseen vai puuttuiko valtuus. Lokitusta ei pidä käyttää tarpeettomien henkilötietojen keräämiseen; sen tulee muodostaa vastuullinen ja tarkastettavissa oleva tapahtumaketju.
Testatkaa valtuudet kuten liiketoimintasäännöt
Testitapausten ei pidä päättyä siihen, että ”API vastaa 200”. Tarkistakaa vähintään seuraavat: valtuuttamaton käyttäjä ei voi käynnistää rekisteröintiä; valtuutettu palveluntarjoaja voi käsitellä vain sovitun toimeksiannon; vanhentunut valtuutus hylätään; julkinen passinäkymä ei paljasta sisäisiä rekisteri- tai todisteita; ja uudelleen lähetetty tapahtuma käsitellään jäljitettävästi toistona.
Kevyt aloitussuunnitelma tuleville viikoille
Älkää aloittako täysimittaisesta migraatiosta. Valitkaa pieni, edustava tuotemäärä ja todellinen vastuuketju.
- Määrittäkää jokaiselle pilottituotteelle valmistaja, markkinoille saattaja, tietovastaavat ja tarvittaessa palveluntarjoaja.
- Dokumentoikaa, millä menetelmällä taloudellinen toimija varmennetaan ja kuka hyväksyy tarkastuksen.
- Määrittäkää roolit luonnostelulle, sisällölliselle hyväksynnälle, rekisteröinnille ja pelkälle lukuoikeudelle.
- Rekisteröikää testitietue, jossa on versioidut tuotetiedot, ja lokittakaa rekisteröinti, vastaus ja korjauspolku.
- Testatkaa julkinen QR-käyttö erillään sisäisistä rooleista ja rekisteriliittimestä.
- Harjoitelkaa peruutusta ja vaihtoa: mitä tapahtuu palveluntarjoajan vaihtuessa, yritysnimen muuttuessa tai tunnisteen ollessa virheellinen?
Tämä menettely sopii yhteen myös jo julkaistun suosituksen kanssa, jossa rekisteri, resolveri ja tietolähde kehotetaan testaamaan erikseen. Uutta on painotus: ennen vankkaa API-integraatiota on oltava selvää, mikä varmennettu organisaatio ja mikä rooli vastaa toimesta.
Mitä ei vielä pidä väittää
Rekisteriasetus luo tekniset ja organisatoriset puitteet. Se ei tee jokaisesta tuoteryhmästä heti DPP-velvoitteista eikä korvaa alakohtaisia delegoituja säädöksiä. Komissio määrittelee käyttöönoton edelleen tuoteryhmittäin; ESPR-delegoitujen säädösten jälkeen siirtymäajaksi on lähtökohtaisesti varattu vähintään 18 kuukautta. Vastaavasti varmennettu yritysasema ei anna lupaa puutteellisiin tai virheellisiin tuotetietoihin.
Tiimeille seuraus on silti konkreettinen: identiteetti, toimeksianto, roolit ja lokitus kuuluvat DPP-tiekartalle ennen rekisteröintien skaalaamista. Näin QR-koodi säilyy yksinkertaisena julkisena sisäänkäyntinä ja rekisteritoimesta tulee sitä, mitä se sääntelyn kannalta on: varmennetun taloudellisen toimijan vastuullinen ja jäljitettävä toimi.
