Két rendelet, egy kódbázis: hol találkozik az AI Act és a GDPR a szoftverfejlesztésben?

Aki AI-alapú terméket fejleszt, annak a megfelelés eddig jellemzően a GDPR-t jelentette, az AI Act pedig sokáig távoli, inkább jogi témának tűnt. 2027. december 2-től azonban a legtöbb önálló nagy kockázatú AI-rendszerre alkalmazni kell az AI Act követelményeit, és a két rendelet ekkor már a fejlesztési backlogban találkozik.

A jó hír, hogy sok ponton átfedik egymást, így az egyik szerint elvégzett munka a másik szerinti megfelelést is segíti, ami időt és pénzt takarít meg. Vannak azonban olyan pontok is, ahol az egyik rendelet betartása megnehezíti a másikét. Az Európai Bizottság és az Európai Adatvédelmi Testület közös iránymutatáson dolgozik a két rendelet viszonyáról, de amíg ez meg nem jelenik, a fejlesztőknek bizonytalan terepen kell döntéseket hozniuk.

Az alábbiakban az International Association of Privacy Professionals (IAPP) idén októberi áttekintésére támaszkodva azokat a területeket vesszük sorra, amelyek egy szoftverfejlesztő cég mindennapjait a leginkább érintik.

Adatfeldolgozó és szolgáltató egyszerre?

Az első gyakorlati kérdés az, hogy ki milyen szerepben vesz részt az AI-fejlesztésben, és ezt már a megrendelővel kötött szerződésben érdemes rögzíteni, mert ettől függ, kit terhelnek a két rendelet kötelezettségei.

Mindkét rendelet saját fogalomrendszert használ: a GDPR adatkezelőt és adatfeldolgozót ismer, az AI Act szolgáltatót és alkalmazót, és a kettő között nincs automatikus megfelelés. Az AI Act szerint szolgáltató az, aki a rendszert saját neve vagy védjegye alatt hozza forgalomba vagy helyezi üzembe, így egyedi fejlesztésnél ez sokszor a megrendelő lesz, a fejlesztő pedig csak akkor válik szolgáltatóvá, ha a terméket az előbbiek szerint forlgalomba hozza vagy üzembe helyezii.

Ennek azért van jelentősége, mert a kötelezettségek a szerepet követik. Egy fejlesztő cég, amely a GDPR szerint adatfeldolgozóként kevesebb felelősséget visel (az adatkezelőhöz képest), az AI Act szerint szolgáltatóként a legtöbb kötelezettséget viselheti, a műszaki dokumentációtól egészen a megfelelőségértékelésig. Ezért a szerepet mindkét rendelet szerint külön kell megállapítani, mielőtt a fejlesztés elindul.

Naplózás és törlési jog

A második pont architekturális, és később nagyon drága lehet javítani. Az AI Act 12. cikke a nagy kockázatú rendszereknél automatikus naplózást követel meg, hogy a működés visszakövethető legyen. Ezek a naplók könnyen személyes adatokat is tartalmaznak, ami miatt számolni kell az érintetti jogok érvényesítésének, például a hozzáférési vagy a törlési kérelmek teljesítésének kötelezettségével. Fejlesztői szemmel ez azt jelenti, hogy a naplózást eleve a GDPR szerinti beépített adatvédelem elvével összhangban kell megtervezni.

A gyakorlatban ez jelentheti azt, hogy a naplóba nevek és e-mail-címek helyett technikai azonosítók kerülnek, amelyek személyhez kötését egy külön, szigorúbban védett tábla tárolja. Ez lehetőséget ad arra is, hogy a bejegyzések az azonosító alapján visszakereshetők legyenek, így a cég egy hozzáférési kérelemre is válaszolni tud. A harmadik, hogy a naplók a kötelező, legalább hat hónapos megőrzési idő lejárta után automatikusan törlődnek.

Ezek a megoldások csökkentik a kockázatot, de a fő kérdést nem döntik el. A GDPR ugyan lehetővé teszi a törlés megtagadását, ha az adat megőrzését jogi kötelezettség írja elő, arra azonban még nincs hatósági iránymutatás, hogy ez az AI Act szerinti naplózásra pontosan hogyan alkalmazandó.

Torzításvizsgálat különleges adatokkal

A harmadik terület a tanítóadatok minősége, ahol a torzítás vizsgálata ütközik a különleges adatok kezelésének tilalmával. Egy modell diszkriminatív működését gyakran csak úgy lehet kimutatni, ha a fejlesztő látja, hogy az eredmények hogyan alakulnak például nemzetiség vagy egészségi állapot szerint, márpedig az ilyen adatok kezelését a GDPR 9. cikke alapesetben tiltja.

A júliusban kihirdetett Digital Omnibus on AI ezzel próbálta feloldani ezt az ellentmondást: az AI Act 4a. cikke alapján a szolgáltatók szigorú feltételekkel kezelhetnek különleges adatokat a torzítás felderítésére és javítására. A feltételek a fejlesztési folyamatra is kihatnak, mert ez csak akkor megengedett, ha szintetikus vagy anonimizált adatokkal ugyanez nem érhető el, és az adatokat a korrekció után törölni kell. Érdemes tehát a tesztelési folyamatot szintetikus adatokra építeni, és dokumentálni, ha ez valahol nem elegendő.

Szakmai körökben ugyanakkor sokan úgy látják, hogy az egyensúly még nincs jól beállítva, és a hatósági gyakorlat sem alakult ki. A szintetikus adatokra épülő tesztelés és a döntések gondos dokumentálása ezért ma inkább a kockázatot csökkenti, teljes jogbiztonságot nem ad.

Ahol a két rendelet egymást segíti

Ezeken a pontokon egyetlen jól átgondolt tervezési döntés két rendelet követelményeit is szolgálja.

Ha a fejlesztő eleve beépíti az AI Act 14. cikke szerinti emberi felügyeletet, azzal az alkalmazónak is segít abban, hogy annak ügyfelei ne kerüljenek kizárólag automatizált döntés hatálya alá, amit a GDPR 22. cikke korlátoz. Ugyanígy az AI Act szerinti műszaki dokumentáció, amelyet a kis- és középvállalkozások egyszerűsített formában is elkészíthetnek majd, jó alapot ad a megrendelő adatvédelmi hatásvizsgálatához. Ez a megfelelés így versenyelőnnyé válhat egy közbeszerzésen vagy egy nagyvállalati beszállítói auditon.

A 2027-es határidő és a nyitott jogi kérdések könnyen azt a benyomást keltik, hogy még ráér a téma, pedig a bizonytalanság nem ok a várakozásra, mert a mostani fejlesztési döntések határozzák meg, mennyibe kerül majd a megfelelés.

A GDPR már ma is teljes egészében vonatkozik minden AI-rendszerre, amely személyes adatot kezel, függetlenül attól, hogy az AI Act szerint magas kockázatú kategóriába tartozik-e vagy sem. Az AI Act rendelkezéseinek kötelező alkalmazása fokozatosan lép életbe. A ma tervezett termékek 2027-ben már piacon lesznek, és egy utólagos átalakítás, a fejlesztési költségek mellett, új megfelelőségértékelést is jelenthet.

Aki most tervez új AI-alapú terméket, vagy egy meglévő rendszer lényeges módosítását, annak érdemes már a tervezési fázisban egy asztalhoz ültetni a fejlesztőket és az adatvédelmi szakembert, mert a jog még alakul, a kód viszont már most készül.

Források:

• EU Digital Laws: Mapping the Interplays with the GDPR, Artificial Intelligence Act (IAPP, 2026. október)
• A view from Brussels: A sneak peek into upcoming guidelines on GDPR, AI Act interplay (IAPP, 2026 június)
• AI system development: CNIL’s recommendations to comply with the GDPR (CNIL, 2026. január)