mi történik a termékútleveleimmel, ha a hosztingpartner abbahagyja a tevékenységét

A gyártó felelőssége, nem a hosting szolgáltatóé

Az adatlap-adatok rendelkezésre bocsátásának kötelezettsége azon gyártóra vagy importőrre hárul, aki a terméket a piacra helyezi, nem pedig azon vállalatra, amely a hosztálást végzi. Egy hosting szolgáltató, mint a matrapas.eu, ezt a kötelezettséget megbízás alapján teljesíti, de a végső felelősség nem csapódik át. Ha egy hosting szolgáltató felhagyja a tevékenységet, ez nem jelenti azt, hogy az adatlap rendelkezésre bocsátásának kötelezettsége eltűnik — ez továbbra is azon a félen marad, amely a terméket a piacra helyezte. Ami azonban megváltozik, az az, hogy ki végzi azt a technikát akkor.

Kire vonatkozik ez, és mely helyzetre nem

Ez a téma az adatok continuálásáról szól: az adatok, amelyek a QR-kód mögött állnak, továbbra is lekérdezhetőek maradnak, még akkor is, ha valami megváltozik az adatokat hosztáló szolgáltatónál. Ez más kérdés, mint az, hogy mi történik, ha a gyártó vagy importáló vállalat maga felhagyja a tevékenységet — ezt a helyzetet az amit az adatlap kezd, ha a termék mögötti vállalat leálltartalmazza. Ez az oldal nem foglalkozik azzal sem, hogy az adatlapnak összességében meddig kell rendelkezésre állnia; ezt az az adatlap megőrzési időszakaesetében tárgyaljuk. Ez az oldal arra az esetre korlátozódik, hogy mi történik gyakorlatilag, ha az adatlap műszaki szolgáltatója — a hosting szolgáltató — hiányzik, miközben a termék mögötti vállalat továbbra is létezik.

Mi van már rögzítve, és mi még nem

Az, hogy mikor lép életbe pontosan a matracok digitális adatlapjára vonatkozó kötelezettség, még nincs megállapítva: az ESPR-rendelet maga már hatályos, de az azt a matracokra vonatkozóan konkrétizáló delegált jogi aktus a 2025-2030 munkaterv keretében várható, és egy dátum itt az aktus megjelenésekor kerül feltüntetésre. Az azonban már rögzített, az ESPR-rendelet alapelvéből: a 10. cikk követelményeket állapít meg a digitális adatlap hozzáférhetőségére és tartósságára vonatkozóan, a 13. cikk pedig azt szabályozza, hogy az adatlapokat egy központi európai nyilvántartásba veszik fel. Ez a nyilvántartás függetlenül létezik attól a féltől, amely az alapul szolgáló adatokat hosztálja — ez egy hivatkozási rendszer, nem az összes tartalom raktára. A nyilvántartás pontosan mit tartalmaz és mit kell benne tartalmaznia, az itt van leírva: az európai adatlap-nyilvántartás.

Hogyan kezelik ezt a gyakorlatban

A gyártó vagy importőr számára, aki egy hosting szolgáltatóval dolgozik, az első lépés annak ismerete, hogy mit írtak le szerződésben arra az esetre, ha a hosting szolgáltató leáll: rögzítve van-e az adatok átadása, és kinek adják át akkor ezeket az adatokat. Ezt követően fontos tudni, hogy milyen formátumban kerül sor az adatok átadására — egy olyan adatsor, amely csak egy szolgáltató rendszerén belül értelmezhető, kevésbé értékes, mint egy olyan adatsor, amely másik félhez átvihető. Ez összhangban van azzal a kérdéssel, hogy egy adatlap egy külső rendszerhez kapcsolódik-e: aki terméki adatait már egy ERP- vagy készletkezelési rendszerben kezeli, ahogy az az adatlap saját rendszerhez való csatolásaesetében van leírva, annak saját adatforrása van, amely nem tűnik el, ha a hosting szolgáltató leáll — a csatolás azt biztosítja, hogy az alapul szolgáló információ máshol is megmarad, még akkor is, ha a megjelenítés másik félen keresztül megy végbe.

Ezt követően releváns, hogy mi történik a QR-kóddal és az azt jellemző linkkel. Ha egy hosting szolgáltató felhagyja, és az adatok másik helyre költöznek, a létező QR-kódnak a termékre továbbra is érvényes információra kell mutatnia — nem halott linkre. Gyakorlatilag ez azt jelenti, hogy az alapul szolgáló URL gyakran megmarad (például egy átirányítás útján az új rendszerhez), hogy ne kelljen minden termékre új kódot felvinni. Aki arra kíváncsi, hogy ez a fizikai kód és a digitális adatok közötti csatolás pontosan hogyan működik, annak részletes információ itt található: hogyan kerül a QR-kód a matracraEgy hostingszolgáltató közötti átmenet során tehát elsősorban arra kell ügyelni, hogy a termék azonosítási kódja és a hozzá tartozó adatkapcsolat sértetlen maradjon, még akkor is, ha a mögöttes infrastruktúra megváltozik.

Végül célszerű előzetesen megkérdezni, hogy egy hostingszolgáltató hogyan jár el a saját üzleti tevékenységének befejeztével: van-e olyan eljárás, amely életbe lép, értesítik-e előzetesen a gyártót, és van-e olyan időszak, amikor az adatok még letölthetők, mielőtt a rendszert leállítanák. Az ilyen jellegű megállapodások a gyakorlatban azt határozza meg, hogy mekkora kockázat jár az egyik específikus szállító kiesésével.

E tekintetben a következőn alapul: az ESPR 10. és 13. cikke

Az ESPR (2024/1781 EU rendelet) 10. cikke az olyan követelményeket írja elő a digitális termékpasszusszal kapcsolatban, mint az adatok hozzáférhetősége azalatt az időszak alatt, amíg azoknak rendelkezésre kell állniuk — ez a követelmény magára a passzuszra vonatkozik, és nem egy specifikus technikai szolgáltatóra. Az ugyanez rendelet 13. cikke a digitális termékpasszuszok nyilvántartását szabályozza, amelybe a passzuszok úgy kerülnek felvételre, hogy azok megtalálhatók és ellenőrizhetők legyenek, függetlenül attól, hogy mely fél végzi az alapul szolgáló hosting szolgáltatást. E cikkek együttesen azt a felelősséget helyezik rá, aki a passzuszt létre hozta, hogy az adatok továbbra is rendelkezésre álljanak, és nem az adott szerv felelőssége, amely a technikai végrehajtást végzi.

Aki jelenleg hostingszolgáltatót választ vagy fontolgat, ezt ellenőrzőlistáként használhatja: kérdezze meg az adatok exportálási lehetőségeiről, arról, hogy mi történik a QR-linkkel egy lehetséges átmenet esetén, valamint a hostingszolgáltató üzleti tevékenységének befejeztéhez kapcsolódó eljárásról — és rögzítse ezeket az megállapodásokat, mielőtt az első passzuszok elhagynák az üzletet.