A technológiai és a jogi architektúra egysége: Egy informatikai projekt sikerét már nemcsak a technológiai megvalósítás minősége és a határidők betartása határozza meg. Ugyanilyen jelentősége van annak a szerződéses keretrendszernek, amely pontosan rögzíti a fejlesztés tárgyát, a felek feladatait, az adatok felhasználását, a teljesítmény mérését, valamint a hibákért és kockázatokért viselt felelősséget.
Ez különösen igaz a mesterséges intelligenciát alkalmazó megoldásokra. Egy MI-rendszer működése nem választható el az azt kiszolgáló adatoktól, modellektől, külső szolgáltatásoktól, automatizált folyamatoktól és emberi döntésektől. A szerződésnek ezért a projekt tényleges technológiai felépítését és teljes életciklusát is tükröznie kell.
Az AI Act 2026. augusztus 2-től főszabály szerint alkalmazandó, egyes kötelezettségei azonban már korábban hatályba léptek, míg a nagy kockázatú MI-rendszerekre vonatkozó részletes követelmények alkalmazása későbbi időpontokra tolódott. Nem minden MI-rendszerre vonatkoznak tehát azonos kötelezettségek: a szerződés előkészítésekor először a rendszer rendeltetését, kockázati besorolását és a felek tényleges szerepét kell meghatározni. Az aktuális alkalmazási ütemezés az Európai Bizottság AI Act-oldalán követhető.
Ebben a cikkben azt mutatom be, mely szerződéses kérdéseket érdemes fejlesztői és megrendelői oldalon különösen körültekintően rendezni.
1. A szerződéses elnevezéseknél fontosabbak a tényleges szerepek
A „fejlesztő”, „szolgáltató” és „megrendelő” megjelölések önmagukban nem határozzák meg, hogy az AI Act alapján kit milyen kötelezettség terhel. A minősítés a felek tényleges tevékenységétől, a rendszer piacra bocsátásának módjától és tervezett felhasználásától függ. Előfordulhat például, hogy a technikai fejlesztést végző vállalkozás kizárólag alvállalkozóként működik közre, míg az AI Act szerinti szolgáltatói kötelezettségeket az a fél viseli, amely a rendszert a saját neve vagy védjegye alatt hozza forgalomba. Nagy kockázatú MI-rendszer esetén bizonyos jelentős módosítások vagy a rendszer rendeltetésének megváltoztatása következtében a megrendelő is szolgáltatói szerepbe kerülhet.
A szerződésben ezért célszerű egyértelműen meghatározni: ki végzi el az MI-rendszer jogi és kockázati besorolását; kit terhelnek a dokumentációs és megfelelőségértékelési feladatok; ki biztosítja a rendszer nyomon követését és naplózhatóságát; ki kezeli és jelenti az incidenseket; ki felel a rendszer későbbi módosításaiért és frissítéseiért; milyen információkat és közreműködést kötelesek egymásnak biztosítani a felek.
2. Amit a fejlesztői oldalon érdemes rendezni
A fejlesztés tárgya és a változások kezelése
A fejlesztési szerződések egyik leggyakoribb problémája, hogy a projekt indulásakor még nem határozható meg teljes részletességgel a végleges műszaki tartalom. Ez különösen igaz agilis fejlesztésnél, ahol a követelmények a sprintek és a felhasználói visszajelzések alapján folyamatosan változhatnak. A rugalmasság azonban nem jelentheti azt, hogy a teljesítés tartalma utólag már nem állapítható meg.
A szerződésnek vagy annak mellékleteinek rendezniük kell: a specifikáció és a backlog jogi szerepét; a fejlesztési szakaszokat és mérföldköveket; az átadás-átvételi és tesztelési követelményeket; a hibák osztályozását és javításának határidejét; a változtatási igények jóváhagyásának rendjét; a módosítások díjra és teljesítési határidőre gyakorolt hatását.
A fejlesztő számára különösen fontos annak rögzítése, hogy mely eredmény, funkció vagy teljesítményszint tartozik az eredeti vállalás körébe, és mi minősül külön díjazás ellenében elvégzendő többletfeladatnak.
Megfelelőség a tervezéstől kezdve
MI-rendszer fejlesztésekor a jogi megfelelőség nem kezelhető kizárólag a projekt lezárásakor átadandó dokumentációként. Már a tervezés során figyelembe kell venni többek között az alkalmazott adatok minőségét, a rendszer átláthatóságát, naplózhatóságát, emberi felügyeletét, pontosságát, robusztusságát és kiberbiztonságát.
Ha a fejlesztő az AI Act szerinti szolgáltatói szerepet is betölti, a szerződésben rendezni kell a rendszer besorolásával, kockázatkezelésével, tesztelésével, dokumentálásával és későbbi nyomon követésével kapcsolatos kötelezettségeket.
A nagy kockázatú MI-rendszerek Annex IV szerinti technikai dokumentációja elsősorban a megfelelőség igazolását szolgálja. Ettől külön kell kezelni a megrendelő vagy alkalmazó részére átadandó használati és műszaki információkat. Ezeknek ki kell térniük többek között a rendszer rendeltetésére, teljesítményére, korlátaira, ismert kockázataira, az emberi felügyelet módjára és a szükséges karbantartásra. Az alkalmazók tájékoztatására vonatkozó követelményeket az AI Act 13. cikke részletezi.
Adatok, külső modellek és nyílt forráskódú komponensek
A fejlesztő gyakran nem kizárólag saját fejlesztésű elemekből építi fel a rendszert. Nyílt forráskódú könyvtárak, külső API-k, felhőszolgáltatások, előtanított modellek és harmadik féltől származó adatkészletek egyaránt beépülhetnek a megoldásba.
A szerződésnek ezért tisztáznia kell: mely adatokat és tartalmakat biztosítja a megrendelő; ki felel azok jogszerű felhasználhatóságáért és minőségéért; milyen külső modellek, API-k vagy szoftverkomponensek kerülnek alkalmazásra;
milyen licenc- és felhasználási feltételek kapcsolódnak ezekhez; milyen feltételekkel cserélhető le vagy szüntethető meg egy külső szolgáltatás; milyen kötelezettségek erednek a copyleft vagy más nyílt forráskódú licencekből; ki viseli a harmadik fél szolgáltatási feltételeinek megváltozásából eredő kockázatot.
Különösen fontos a komponensek és licencek megfelelő nyilvántartása, valamint annak biztosítása, hogy a megrendelő a rendszer átvétele után is jogszerűen használhassa a teljes megoldást.
Kiberbiztonság, frissítések és sérülékenységek
A biztonsági követelményeket nem elegendő általános kötelezettségként rögzíteni. Meg kell határozni a biztonsági frissítések, a sérülékenység-kezelés, az incidensjelzés, a hozzáférés-kezelés és a naplózás konkrét szabályait is.
A Cyber Resilience Act jelentősége különösen a digitális elemeket tartalmazó termékek fejlesztésénél nő. A rendelet jelentési kötelezettségei 2026. szeptember 11-től, főbb követelményei pedig 2027. december 11-től alkalmazandók. Mivel a 2026-ban megkötött fejlesztési és támogatási szerződések gyakran több évre szólnak, a későbbi követelményekre már a jelenlegi szerződéses struktúrában is célszerű felkészülni. Európai Bizottság – Cyber Resilience Act
A fejlesztő felelősségének határai
MI-rendszereknél a hibás eredmény nem feltétlenül vezethető vissza egyetlen fejlesztési hibára. A kimenetet befolyásolhatja a tanítóadat, a felhasználói bemenet, a külső modell működése, a rendszer konfigurációja, a megrendelő által végzett módosítás vagy az emberi ellenőrzés hiánya is.
A fejlesztői szerződésnek ezért célszerű elkülönítenie: a fejlesztési hibát; a külső szolgáltatás hibáját vagy elérhetetlenségét;
a nem megfelelő vagy rendeltetésellenes felhasználást; a megrendelő által biztosított hibás adatokat; a rendszer ismert és dokumentált korlátait; a fejlesztő által nem ellenőrizhető modellváltozásokat.
A felelősség korlátozásának és a kártérítési plafonoknak a projekt valós kockázataihoz, a díjazáshoz és az alkalmazandó kötelező jogszabályi korlátokhoz kell igazodniuk.
3. Amit a megrendelőnek és az alkalmazónak szem előtt kell tartania
A felhasználási cél és az átvétel egyértelmű meghatározása
A megrendelő számára nem elegendő annak rögzítése, hogy a fejlesztő milyen rendszert ad át. Azt is meg kell határozni, hogy a rendszer milyen üzleti folyamatban, milyen adatokkal, milyen felhasználói körben és milyen döntések támogatására használható. Az átvételi követelményeknek mérhetőnek és ellenőrizhetőnek kell lenniük. Az olyan általános kifejezések, mint a „megfelelő pontosság”, a „megbízható működés” vagy a „jogszabályoknak megfelelő rendszer”, konkrét kritériumok nélkül később nehezen érvényesíthetők.
Az SLA-k új generációja
MI-alapú rendszereknél a puszta rendelkezésre állás és válaszidő rögzítése már nem feltétlenül elegendő. Az SLA-nak és a műszaki specifikációnak a rendszer rendeltetéséhez igazodó teljesítménymutatókat is tartalmaznia kell. Ilyen lehet különösen: a pontosság és a hibaarány; a válaszidő és rendelkezésre állás; az elfogadhatatlan vagy bizonytalan kimenetek aránya;
a teszteléshez használt adatkészlet és módszertan; a teljesítményromlás vagy modelldrift észlelésének módja; az emberi ellenőrzést igénylő esetek köre; az incidensek kezelésének és a hibák javításának határideje.
A generatív rendszerek téves vagy félrevezető kimeneteinek – az úgynevezett hallucinációknak – a kezelése nem kizárólag SLA-kérdés. A kapcsolódó kockázatokat a specifikációban, az átvételi feltételekben, a felhasználói tájékoztatásban, az emberi felügyelet szabályaiban és a felelősségi rendelkezésekben együttesen kell kezelni.
Adatvédelem és hatásvizsgálatok
Ha a rendszer személyes adatokat kezel, tisztázni kell a felek adatvédelmi szerepét, az adatkezelés célját és jogalapját, az adatfeldolgozók és további adatfeldolgozók igénybevételét, valamint az esetleges harmadik országbeli adattovábbításokat.
A projekt jellegétől függően szükség lehet GDPR szerinti adatvédelmi hatásvizsgálatra. Az AI Act szerinti alapjogi hatásvizsgálat ettől eltérő követelmény, és nem valamennyi MI-rendszer alkalmazójára vonatkozik: csak meghatározott alkalmazók és nagy kockázatú felhasználások esetében kötelező. A szerződésnek ugyanakkor biztosítania kell, hogy a megrendelő megkapja a szükséges vizsgálatok elvégzéséhez és a megfelelőség igazolásához szükséges információkat és közreműködést. Az alapjogi hatásvizsgálat szabályait az AI Act 27. cikke tartalmazza.
Szellemi alkotások és felhasználási jogok
Az a feltételezés, hogy „amit a megrendelő kifizet, az automatikusan az övé lesz”, informatikai és MI-fejlesztéseknél rendszerint nem ad megfelelő választ a felmerülő kérdésekre. Külön kell kezelni: a felek már meglévő szoftvereit, modelljeit és egyéb szellemi alkotásait; a projekt során létrejövő egyedi forráskódot; a konfigurációkat, promptokat és dokumentációt; a tanító-, teszt- és finomhangolási adatokat; a finomhangolt modellhez és modellparaméterekhez való hozzáférést; a generált kimenetek felhasználását; a külső komponensekhez és modellekhez kapcsolódó jogokat.
A szerződésnek nemcsak azt kell rögzítenie, hogy kit milyen felhasználási jog illet meg, hanem annak terjedelmét, időbeli és területi hatályát, átruházhatóságát, továbbengedélyezhetőségét és megszűnés utáni fennmaradását is.
MI-hez kapcsolódó fejlesztés esetén a szabadalmazhatóság is felmerülhet, de nem minden algoritmus vagy MI-megoldás részesülhet szabadalmi oltalomban. Ehhez többek között megfelelő műszaki jelleg, újdonság és feltalálói tevékenység szükséges.
Vendor lock-in és kilépési stratégia
A szolgáltatóváltás feltételeit már a szerződés megkötésekor célszerű rendezni. Ellenkező esetben a megrendelő olyan technológiai vagy szerződéses függésbe kerülhet, amely a későbbi migrációt aránytalanul költségessé vagy gyakorlatilag lehetetlenné teszi. A kilépési rendelkezéseknek ki kell térniük különösen: az adatok exportálható formátumára; az átadandó dokumentációra; a migrációs közreműködésre; az átmeneti szolgáltatás időtartamára; az adatok visszaadására és törlésére;
a szükséges hozzáférések megszüntetésére; indokolt esetben a forráskódletéti konstrukcióra; a finomhangolt modellekhez vagy modellparaméterekhez való további hozzáférésre, ha ez technikailag és szerződésileg biztosítható.
A megrendelő érdeke nem feltétlenül az, hogy valamennyi technológiai elem a tulajdonába kerüljön, hanem az, hogy a szolgáltatás megszűnésekor is biztosított legyen az üzletmenet folytonossága, az adatok hozzáférhetősége és a más rendszerre történő átállás.
4. Felelősség és kockázatmegosztás
MI-rendszerek esetén különösen fontos meghatározni, hogy ki felel: a modell vagy a fejlesztett rendszer hibájáért; a pontatlan vagy megtévesztő kimenetekért; a hibás integrációért; a nem megfelelő bemeneti adatokért; a jogellenes vagy rendeltetésellenes használatért; a szükséges emberi ellenőrzés elmulasztásáért; a biztonsági incidensekért; harmadik személyek szerzői vagy más jogainak megsértéséért; a megfelelőségi és dokumentációs kötelezettségek elmulasztásáért.
A felelősségi szabályoknak összhangban kell állniuk a felek tényleges ráhatásával. Nem célszerű olyan kötelezettséget telepíteni valamelyik félre, amelynek teljesítéséhez nincs megfelelő hozzáférése, információja vagy technikai ellenőrzési lehetősége.
A kártérítési korlátok, felelősségkizárások, szavatossági rendelkezések és helytállási kötelezettségek mellett indokolt lehet a megfelelő felelősségbiztosítás, valamint a hibák és incidensek kivizsgálásához szükséges naplók és bizonyítékok megőrzésének szabályozása is.
5. A technológiai-jogi audit szerepe
Egy IT- vagy MI-projekt jogi megfelelősége nem kizárólag a szerződés szövegéből állapítható meg. A tényleges működés, az adatáramlások, a rendszerbe épített komponensek és az alkalmazott szervezeti folyamatok eltérhetnek attól, amit a dokumentáció vagy a szerződés rögzít. A technológiai-jogi audit során együttesen vizsgálható: a rendszer architektúrája és tényleges rendeltetése; az adatforrások és adatáramlások; a külső modellek, API-k és szoftverkomponensek; a kapcsolódó szerződések és licencfeltételek; a felhasználói jogosultságok és emberi felügyeleti pontok; a naplózás, incidenskezelés és dokumentáció; a szerződéses vállalások és a tényleges működés összhangja.
A vizsgálat indokolt esetben forráskód-, információbiztonsági vagy licencelési ellenőrzéssel is kiegészíthető. Az audit célja nem egy általános megfelelőségi garancia kiadása, hanem a jogi és technológiai kockázatok, hiányosságok és eltérések feltárása, valamint a szükséges intézkedések meghatározása.
Összegzés
Egy korszerű IT- vagy MI-szerződés nemcsak a fejlesztendő rendszer leírása és a díjazás rögzítése. Meghatározza a projekt teljes életciklusát: a tervezéstől és fejlesztéstől kezdve az átadáson, működtetésen és módosításokon át egészen a szolgáltatás megszüntetéséig vagy a szolgáltatóváltásig.
A megfelelő szerződéses struktúra: egyértelművé teszi a felek szerepét és feladatait; mérhetővé teszi a teljesítést; rendezi az adatok és szellemi alkotások felhasználását; meghatározza a biztonsági és megfelelőségi követelményeket; felosztja a felelősséget és a projekt kockázatait; biztosítja a későbbi módosítás és kilépés feltételeit.
A technológiai és a jogi architektúra összehangolása ezért nem pusztán megfelelőségi feladat: a sikeres és hosszú távon működőképes informatikai projekt egyik alapfeltétele.
Jelen cikk általános tájékoztatást tartalmaz, és nem minősül egyedi ügyben adott jogi tanácsadásnak.
