BSA: van mit javítani az Uniós termékfelelősségi irányelven

termékfelelősségA BSA hat ajánlást terjesztett az uniós jogalkotók elé megfontolásra a kiegyensúlyozott és hatékony termékfelelősségi rendszer biztosítása érdekében.

A BSA üdvözli, hogy az EU Bizottsága a termékfelelősségi irányelv (Product Liability Directive – PLD)felülvizsgálatával a belső piac működésének, az áruk szabad mozgásának, a piaci szereplők közötti torzításmentes versenynek, valamint a fogyasztók egészségének és tulajdonának magas szintű védelmének biztosítása érdekében célul tűzte ki a termékfelelősségi irányelv felülvizsgálatát. Ennek érdekében fontos, hogy az új felelősségi szabályok tiszteletben tartsák a termékek és szolgáltatások különbségeit, valamint a vállalkozások közötti ellátási láncokat, amelyek egyértelmű és hatékony felelősségmegosztást biztosítanak. Összességében fontos, hogy minden új felelősségi rendszer a tényleges szükségleteken és a feltárt problémákon alapuljon.

A BSA ennek érdekében hat ajánlást terjesztett az uniós társjogalkotók elé megfontolásra a kiegyensúlyozott és hatékony termékfelelősségi rendszer biztosítása érdekében.

1. A hagyományos termékfelelősségi szabályokat nem szabad egyszerűen kiterjeszteni az önálló szoftverekre, amelyek inkább egy szolgáltatáshoz hasonlítanak

A PLD-tervezet az önálló szoftvereket terméknek kívánja minősíteni. A modern szoftverek azonban számos olyan tulajdonsággal rendelkezhetnek, amelyek általában egy szolgáltatáshoz kapcsolódnak, és ezért nem lennének alkalmasak a PLD-tervezet termékközpontú felelősségi rendszerére. Az önálló szoftverekre vonatkozó szigorú felelősség bevezetése kiterjesztené a felelősséget azokra a fejlesztőkre, akiktől ésszerűen nem várható el, hogy felelősséget vállaljanak az ellenőrzésükön kívül eső helyzetekért. Az önálló szoftverek szinte korlátlan számú forgatókönyvben és felhasználási módban integrálhatók és alkalmazhatók. A termékekre vonatkozó PLD-tervezet rendelkezései jelentős kihívások elé állíthatják a nem megfelelően használt önálló szoftvereket.

A PLD-tervezetnek ki kellene zárnia az önálló szoftvereket, különösen az úgynevezett „as-a-service” modellek által nyújtott szoftvereket a hatálya alól, mivel ezek alapvetően különböznek a fizikai termékektől. Az önálló szoftverekre vonatkozó szigorú felelősségi rendszer káros hatással lehet a szoftverfejlesztésre és az innovációra Európában. A szoftverfejlesztők elriadhatnak az innovációtól, ami kevesebb innovatív funkciót, kisebb teljesítményt és az egyszerűbb funkciók felé mutató tendenciákat eredményezhet.

Ha azonban az önálló szoftvereket a termékfelelősségi szabályok hatálya alá vonnák, a javaslatnak a következőket kellene tartalmaznia:

– a szigorú felelősségi rendszert a másokra jelentős kockázatot jelentő, rendellenesen veszélyes tevékenységekkel járó szélsőséges körülményekre kellene fenntartani, tehát olyan esetekre, amikor a szoftverek súlyos károkat okozhatnak; és

– el kell kerülni az átfedő és következetlen normákat, különösen a mesterséges intelligencia (AI) rendszerek között, ezért az AI-rendszereket ki kell zárni a PLD-tervezet hatálya alól. Az AI-rendszerek felelősségét ehelyett az AI-felelősségről szóló irányelvben kell szabályozni, amely kifejezetten előirányozza a mesterséges intelligenciával kapcsolatos felelősség felülvizsgálatát öt évvel a hatálybalépése után, és közvetlenül kapcsolódik az AI-törvényhez.

Ezenkívül az Európai Bizottság (EB) a kereskedelmi partnereivel folytatott tárgyalások során évek óta azon az állásponton van, hogy az önálló szoftvereket nem kell a Kereskedelmi Világszervezet (WTO) Általános Vám- és Kereskedelmi Egyezménye (GATT) értelmében vett „terméknek” tekinteni. Ennek megfelelően az EB gyakran azt az álláspontot képviselte, hogy a szoftverek – különösen az elektronikus úton történő – szolgáltatásnyújtást a szolgáltatások kereskedelméről szóló általános egyezmény értelmében szolgáltatásként kell kezelni. Ez lehetővé tette az EB számára, hogy fenntartsa azt az álláspontját, hogy a tagállamok helyi tartalmi követelményei és hasonló, az európai kultúra előmozdítását célzó intézkedések a WTO szabályai szerint megengedettek, mivel ebben az esetben a GATT „nemzeti elbánás” elve vitathatóan nem alkalmazható. Ha az EU az önálló szoftvereket a PLD értelmében „terméknek” minősítené, ez megnehezítené annak az álláspontnak a fenntartását, hogy a szoftvereket a WTO-szabályok értelmében nem kellene termékként kezelni.

A felülvizsgált PLD-nek továbbá összhangban kell állnia a termékbiztonsággal foglalkozó jelenlegi uniós jogszabályokkal, például a nemrégiben elfogadott általános termékbiztonsági rendelettel, amely az uniós piacon a termék hibásságának kezelésének alapját képezi, és amely nem tekinti terméknek az önálló szoftvert.

2. A kezdeti felelősséget annak a szervezetnek kell viselnie, amelyik a legjobban képes a kár enyhítésére

Annak biztosítása érdekében, hogy a felelősség azon feleket terhelje, akik ténylegesen ellenőrzik a szoftver funkcionalitását és irányítják annak felhasználási módját, a PLD-tervezetnek be kell vezetnie a „szoftverfejlesztő” és a „szoftverüzemeltető” fogalmát.

A termékekkel ellentétben egy kifejlesztett önálló szoftver általában számos működési lehetőséggel és különböző elérhető beállítással rendelkezik, amelyeket a szoftverfejlesztő hoz létre, és amelyek a szoftver telepítőjének döntése alapján sokféleképpen használhatók. Ez a szoftvertelepítő döntése, nem pedig a szoftverfejlesztőé. A vállalati szoftverfejlesztők innovatív, testre szabott vagy testreszabható megoldásokat hoznak létre üzleti ügyfeleik – a szoftvertelepítők – számára, akik aztán döntést hoznak a telepítendő szoftver funkcióiról.

Fontos, hogy az üzleti vállalkozások közötti (b2b) felek megőrizhessék legjobb gyakorlataikat, és a felelősséget arra a félre hárítsák, aki a szerződéses/licencmegállapodások révén a legjobban képes a károk enyhítésére. Ez a fogyasztók számára is hatékony kártérítést garantálna, lehetővé téve a fogyasztók számára, hogy a felelősséget attól a féltől követeljék, aki a felhasználásról dönt és a kockázatokat kezeli. Később a szoftverüzemeltetők a b2b-megállapodások alapján kártérítést kérhetnének a szoftverfejlesztőktől.

Mindent egybevetve, az összes érintett szolgáltató számára az egyértelműség fenntartása, a felelősségnek a döntéseket meghozó b2b félnél való megtartása és a fogyasztók számára a hatékony kártérítés biztosítása érdekében fontos, hogy a PLD alkalmazásában a szoftverüzemeltetők maradjanak eredetileg felelősek, ne pedig a szoftverfejlesztők.

3. Ha egy termék tartalmaz összetevőket, a kezdeti felelősséget a végtermék gyártójához kell kötni, aki eldöntötte, hogyan építi be az összetevőket

A szoftver gyakran lehet egy termék szerves része, az ellátási láncban több fél is részt vesz, és számos működési lehetőséggel és különböző beállításokkal rendelkezik. Ezek a beállítások viszont a termék gyártójának döntése alapján konfigurálhatók, és a termék forgalomba hozatalakor vehetők használatba (vagy nem). Egy termékbe több komponens/szoftverelem és eszköz is beépülhet, amelyeket különböző b2b szoftverfejlesztők készíthetnek. Gyakran egyetlen szoftverkomponens kifejlesztése komplex Bb2b ellátási láncot foglal magában.

A b2b kapcsolatokban a kockázatok és a felelősség megosztása gyakran a két vagy több üzleti egység közötti szerződéses megállapodás/licencelés egyik része, és ez tükrözi az ellátási lánc összetettségét. A jelenlegi PLD egyértelmű utat biztosít a fogyasztók számára, hogy jogorvoslatot kérjenek a fogyasztónak szánt végtermék gyártójától, a felelősséget pedig rendszerint szerződéses úton rendezik a termékellátási láncban feljebb lévő b2b felek között.

Ezeket a régóta fennálló szerződéses b2b kapcsolatokat nem szabad aláásni, és a fogyasztónak nem szabad arra kényszerülnie, hogy a termék különböző összetevőinek gyártóit keresve a szállítói láncban a feljebb lévő felektől kérjen jogorvoslatot. Ez indokolatlan terhet jelentene a fogyasztók számára, akiknek esetleg nincs tudomásuk arról, hogy miként azonosíthatják a megfelelő, az ellátási láncban felelős szervezetet. Fontos, hogy a PLD-tervezet 13. cikke lehetővé tegye a legjobb b2b gyakorlatok folytatását. Az üzleti vállalkozások a felelősség és a felelősségek elosztása során a szerződéses feltételekre támaszkodtak, és ez a rendszer hatékonynak és innovációbarátnak bizonyult, mivel lehetővé teszi a szükséges rugalmasságot az összetett ellátási láncok mentén.

Amint azt a PLD-tervezet indoklása kifejti, a jogszabályi változások célja a magas szintű fogyasztóvédelem biztosítása, függetlenül attól, hogy a hibás termék tárgyi vagy digitális, vagy a hiba az integrált alkatrészből származik, biztosítva a fogyasztók jogát az elszenvedett kár megtérítésére. Úgy véljük, hogy ennek biztosításához a legjobb módja az, hogy az eredeti felelősség továbbra is a végtermék gyártóját terheli, nem pedig az összetevők gyártóját.

4. A „hibásság” fogalmát tisztázni kell

A PLD-tervezet szerint a hibásság a biztonság hiányával függ össze, amelyet a nagyközönség joggal elvárhat. Nem világos azonban, hogy a hibásság jellemzői hogyan vonatkoznak majd a szoftverekre és az Al-rendszerekre. Egy termék hibássága akkor vélelmezhető, ha a termék nem felel meg az uniós jogban meghatározott kötelező biztonsági követelményeknek. Számos digitális technológia esetében azonban nincsenek ágazatspecifikus szabályok és előírások, néhány ágazatspecifikus szabályról azonban jelenleg folynak a tárgyalások (például a mesterséges intelligenciáról szóló törvény vagy a kibertér-ellenálló képességről szóló törvény). Mivel a termék hibássága a felelősség alapja, ezt a lehető legvilágosabban kell meghatározni, és a lehető legkevesebb teret kell hagyni a kétértelműségnek.

A PLD-tervezet nem teszi világossá, hogy pontosan mely jogi kötelezettségek be nem tartása esetén keletkezik a szoftverfejlesztők szigorú felelőssége a PLD-tervezet értelmében. Azt is egyértelművé kell tenni, hogy mely jogszabályok határoznak meg kötelező biztonsági követelményeket az újonnan megjelenő technológiákra vonatkozóan, és a terméktesztelésnek és a tanúsításnak mindenesetre kifejezetten ki kell esnie a PLD-tervezet hatálya alól. A PLD-tervezet a hibásság fogalmát is kiterjeszti a „terméknek a termékre gyakorolt olyan hatására, amely a bevezetés után tovább tanulható”. Tisztázni kell azonban, hogy ez a tényező hogyan befolyásolja a fejlesztő felelősségét, ha ez a tanulás a fejlesztő ellenőrzési körén kívül történik.

A PLD-tervezetben a biztonság szempontjából releváns kiberbiztonsági kötelezettségeknek nem megfelelő szoftverekkel kapcsolatos felelősségre vonatkozó vélelmek kétértelműek. A termék nem tekinthető hibásnak a kiberbiztonsági követelményekkel kapcsolatos problémák miatt. A kiberbiztonság folyamatos küzdelem a meglévő és a fejlődő fenyegetésekkel szemben, és a kiberbiztonsági szakemberek folyamatosan arra törekszenek, hogy megállítsák a rosszindulatú szereplőket. A termékek és frissítések gyors ütemű bevezetése elengedhetetlen ahhoz, hogy lépést tartsanak a szereplőkkel, akik folyamatosan új utakat keresnek a problémák megtalálására. A szigorú felelősség alkalmazása megfojtja a kiberbiztonsági szakembereket, és valószínűleg a termékek bevezetésének késedelmét eredményezi, mert attól tartanak, hogy valamilyen ismeretlen és potenciálisan ismeretlen sebezhetőség létezik.

A jelenlegi PLD értelmében a gyártók mentesülnek a felelősség alól, ha a termék forgalomba hozatalakor, üzembe helyezésekor vagy forgalmazásakor még nem állt fenn hiba. A PLD-tervezet azonban leszűkíti ezt a szabályt, és a gyártókat felelőssé teszi a hibásságért, még akkor is, ha az a termék forgalomba hozatalakor még nem létezett, ha a hiba a következőkre vezethető vissza: a) kapcsolódó szolgáltatás; b) szoftver, beleértve a szoftverfrissítéseket vagy -frissítéseket; vagy c) a biztonság fenntartásához szükséges szoftverfrissítések vagy -frissítések hiánya (feltéve, hogy ez a gyártó ellenőrzési körébe tartozik). Ezek a változások a gyakorlatban jelentős problémákat okoznának.

Először is, a „gyártói ellenőrzés” meghatározása nem egyértelmű és potenciálisan kivételesen tág. Az ellenőrzést az „engedélyezés” révén határozzák meg, ami túl tágan értelmezhető. Egy szoftverfejlesztő, aki egy harmadik féltől származó komponenssel való integrációhoz kapcsolatot vagy eszközt hoz létre, nem tekinthető úgy, hogy engedélyezi az adott komponens integrálását, és ezáltal felelősséggel tartozik az adott komponens által okozott károkért. Az „engedélyezés” kifejezést egy erősebb igével kellene helyettesíteni, például az „utasítani” vagy legalább a „kifejezetten engedélyezni” kifejezéssel. Másodszor, a „kapcsolódó szolgáltatásra” való hivatkozás problémás azon termékek szempontjából, amelyek „csatlakozókkal” rendelkeznek, amelyek lehetővé teszik a harmadik féltől származó alkalmazásokkal, szolgáltatásokkal és adatokkal való integrációt. Ezért a 10. cikk (2) bekezdésének a) pontját a kapcsolódó szolgáltatásokról meg kell szüntetni vagy pontosítani kell, hogy a csatlakozót kifejlesztő vagy elérhetővé tevő gyártó ne minősüljön úgy, hogy hallgatólagos „engedélyt” ad egy kapcsolódó szolgáltatásra. Harmadszor, a PLD-tervezetet pontosítani kell, hogy a fejlesztő által már nem támogatott szoftververziók ne tartozzanak a hatálya alá.

A PLD-tervezet enyhíti a bizonyítási terhet a műszakilag összetett termékek esetében, hogy megkönnyítse a hiba és a kár közötti okozati összefüggés bizonyítását. Nem egyértelmű azonban, hogy mi minősülhet „műszakilag összetett” terméknek. Az összetettség nem Al-specifikus és nem is problematikus, mivel a PLD a termék hibáira vonatkozik, függetlenül a hiba mögöttes kiváltó okaitól. További egyértelműséget kell teremteni a szükséges küszöbértéket illetően, hogy az igénylők mentesüljenek a hiba és a kár közötti okozati összefüggés bizonyítása alól a műszakilag összetett termékek esetében.

5. Nem szabad, hogy átfedések legyenek más uniós jogszabályokkal és más felelősségi rendszerekkel

Fontos, hogy a lehető legkisebbre csökkentsük a jogszabályok átfedéseit, és hogy a felelősség reformja a hibás termékekkel kapcsolatos fogyasztói jogorvoslat tényleges és egyértelműen azonosított akadályaira reagáljon. Ennek érdekében biztosítani kell, hogy a PLD-tervezet szabályai ne álljanak versenyben vagy ne legyenek átfedésben az egyéb jogi aktusok – például az általános adatvédelmi rendelet (GDPR) vagy az általános felelősségről szóló irányelvtervezet – szerinti felelősségi szabályokkal.

A PLD-tervezet bevezet néhány új kárkategóriát, amely a gyártókat felelősségre vonja a „nem kizárólag szakmai célokra használt adatok elvesztéséért vagy megrongálásáért”, ahelyett, hogy a más jogszabályokban, például az általános adatvédelmi rendeletben (azaz a személyes adatok megsértése és a kapcsolódó kötelezettségek már ott szabályozottak a személyes adatok esetében) rendelkezésre álló meglévő szabályozásra és jogorvoslatokra támaszkodna. Az „adatok elvesztése vagy megrongálása” fogalmának a PLD-tervezetbe való felvétele egymással versengő és egymást átfedő felelősségi rendszert hoz létre, és azt kockáztatja, hogy ugyanazért a kárért többszörös kártérítési igényt támasztanak, vagy legalábbis megnehezítené a felperesek és az alperesek számára annak eldöntését, hogy melyik rendszer alapján nyújtsanak be igényt. Ha a szándék az, hogy a nem személyes adatokra is kiterjedjen, akkor a személyes adatokat ki kell zárni a PLD-tervezet szerinti megtérítendő kár köréből. Az adatok elvesztésére vagy megrongálására vonatkozó, egymást átfedő felelősségi rendszer létrehozása csökkentené az egyértelműséget mind a fogyasztók, mind a vállalkozások számára. Ezért ellenezzük, hogy az adatok elvesztése vagy megrongálása bekerüljön a PLD-tervezet által elismert károk körébe. Különösen akkor, ha nem elég egyértelmű, hogy mi minősülhet az adatok elvesztéséhez vagy megrongálásához kapcsolódó „anyagi kárnak”, és milyen (pl. pénzügyi) küszöbértéknek kellene teljesülnie ahhoz, hogy kártérítést lehessen követelni.

Ugyanakkor a PLD-tervezet nem hozhat létre átfedő felelősségi rendszert a mesterséges intelligenciára vonatkozóan, amelyet az általános felelősségről szóló irányelvtervezetnek kell szabályoznia. Az AI-felelősségi irányelvtervezet közvetlenül kapcsolódik az AI-törvénytervezethez, és a legjobban szolgálná az AI által kiváltott sajátos aggályok kezelését, különösen, mivel az EU az AI-ra vonatkozó kockázatalapú megközelítés kialakításán dolgozik. Az al-felelősségi irányelvtervezet emellett a hatálybalépést követő öt év elteltével felülvizsgálati záradékot is tartalmaz, ami kellő rugalmasságot biztosít a társjogalkotók számára az időközben felmerült esetleges kihívások kezeléséhez, és egyúttal a PLD-tervezet, az al-felelősségi irányelvtervezet és az al-törvény tényleges működésének értékeléséhez.

A PLD-tervezet azonban azt javasolja, hogy már most rendelkezzenek a vétkesség nélküli felelősségről az al. Ezért bizonyos esetekben mind a PLD, mind az al-felelősségről szóló irányelv felelősségi rendszere érvénybe léphet, ami jelentős jogbizonytalanságot okozhat az al-fejlesztők és -felhasználók számára. Ennek elkerülése és az innováció túlterhelésének elkerülése érdekében az al-rendszereket ki kell zárni a PLD-tervezet hatálya alól, az al-felelősséget pedig az al-felelősségi irányelvtervezetben kell szabályozni.

6. A felelősség meghatározásakor kiegyensúlyozott megközelítést kell biztosítani

A bizonyítékok nyilvánosságra hozatala. Az ilyen nyilvánosságra hozatal elrendelésének küszöbe továbbra is nagyon alacsony. Ezt pontosítani kell az üzleti titkok jobb védelme és a tagállamok eltérő jogi értelmezésének elkerülése érdekében. Pontosítani lehetne, hogy a nemzeti bíróságoknak annak eldöntésekor, hogy az üzleti titkokról szóló irányelv értelmében bizalmas információként és/vagy üzleti titokként védendő információk nyilvánosságra hozatalára kötelezzék-e az alperest, figyelembe kell venniük, hogy az ilyen információk nyilvánosságra hozatala „releváns és szükséges”-e ahhoz, hogy a felperes a bírósági eljárás során bizonyítani tudja, hogy a termék hibás. A hozzáférési kérelemnek a termék hibás voltának, a felelős szereplő (gyártó, javító, …) vagy az okozati összefüggés megállapításához szükséges információkra kell korlátozódnia.

Elévülési idő. A tíz éves elévülési idő nem felel meg a szoftverfejlesztés vagy az al-alkalmazások valóságának. A termékek életciklusa igen eltérő lehet, és a hosszú ideig tartó támogatás igénye továbbra is nagy kihívást jelenthet a gyártók számára. A PLD-tervezet szerint a szoftverfejlesztőknek 10 évig kellene frissítéseket biztosítaniuk, ami nem tükrözi a szoftverprogramok időtartamát. A szoftvereket is magában foglaló termékekre vonatkozó felelősség elévülési idejét összhangba kell hozni a digitális tartalomról szóló irányelv és a kiberbiztonsági ellenálló képességről szóló törvényjavaslattal annak érdekében, hogy tükrözze a szoftverfejlesztés realitásait, és megőrizze a két jogszabály közötti összhangot.

Pszichológiai károk. A pszichológiai károk tekintetében további tisztázásra van szükség azzal kapcsolatban, hogy mi minősülhet anyagi kárnak, és milyen (pl. pénzügyi) küszöbértékeknek kell teljesülniük ahhoz, hogy kártérítést lehessen követelni a pszichológiai károkért. Az „orvosilag elismert” fogalmat úgy kell meghatározni, hogy az tartalmazza, hogy a felpereseknek mit kell bizonyítaniuk (azaz bármely orvos által felállított diagnózist és/vagy meghatározott állapot- vagy normakategóriákat) ahhoz, hogy ilyen kártérítést igényelhessenek.


 

Vélemény, hozzászólás?

Az e-mail címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük

Next Post

Musk tuti mazochista

csü ápr 13 , 2023
Elon Musk, a Twitter tulajdonosa szerint a Twittert irányítani és a tulajdonosának lenni „fájdalmas”. A világ épp második leggazdagabb embere októberben vált a Twitter többségi tulajdonosává 44 milliárd dollárért, és azonnal átszervezésébe fogott. Első lépésben elbocsátotta a vállalat alkalmazottainak több mint felét, majd menesztette a teljes igazgatótanácsot, míg végül feloszlatta […]
Elon Musk

És még ez is...