25.5.5. Az EU AI Act mint referencia

2025.10.06.
AI Biztonság Blog

Míg a korábbi keretrendszerek (NIST, MITRE) a „mit kellene” és a „hogyan lehet” kérdéseire fókuszáltak, az Európai Unió Mesterséges Intelligencia Törvénye (AI Act) a „mit kötelező” dimenzióját hozza be a képbe. Ez a jogszabály nem csupán egy ajánlásgyűjtemény, hanem egy kötelező érvényű keretrendszer, amely alapjaiban határozza meg az AI rendszerek fejlesztésének, üzembe helyezésének és felügyeletének feltételeit az EU piacán. Red teamerként a feladatod itt kiegészül: már nemcsak technikai sebezhetőségeket keresel, hanem a jogszabályi megfelelés hiányosságait is.

Kapcsolati űrlap

AI Biztonság kérdésed van? Itt elérsz minket:

A kockázatalapú megközelítés lényege

Az AI Act központi eleme a kockázatalapú besorolás. A rendszereket négy kategóriába sorolja aszerint, hogy mekkora veszélyt jelentenek az egészségre, biztonságra és az alapvető jogokra. A te munkád fókusza és mélysége közvetlenül függ attól, hogy a vizsgált rendszer melyik kategóriába esik.

Kockázati Szint Meghatározás Példák / Következmények
Elfogadhatatlan (Unacceptable) Az alapvető jogokat egyértelműen sértő, ezért betiltott AI alkalmazások. Társadalmi pontozórendszerek, valós idejű biometrikus azonosítás nyilvános helyeken (szűk kivételekkel), manipulatív technikák.
Magas (High) Jelentős kockázatot hordozó rendszerek, amelyekre szigorú követelmények vonatkoznak. Kritikus infrastruktúra vezérlése, orvosi eszközök, munkaerő-felvétel, hitelbírálat, bűnüldözés. Ez a Red Teaming elsődleges terepe.
Korlátozott (Limited) Olyan rendszerek, ahol a felhasználókat tájékoztatni kell arról, hogy AI-val interaktálnak. Chatbotok, deepfake generátorok. A fókusz az átláthatóság ellenőrzésén van.
Minimális (Minimal) A legtöbb AI alkalmazás, amelyekre nem vonatkoznak specifikus kötelezettségek. Spamszűrők, videójátékok AI ellenfelei, készletgazdálkodási rendszerek.

Az AI Act és a Red Teaming Gyakorlata

A jogszabály követelményei közvetlenül leképezhetők tesztelési forgatókönyvekre. Ahelyett, hogy elvont biztonsági elveket vizsgálnál, konkrét jogi előírásoknak való megfelelést kell validálnod. Nézzünk néhány tipikus problémát és a hozzájuk kapcsolódó tesztelési irányt.

1. Probléma: „Nem tudom, hol kezdjem. Melyik a legfontosabb tesztelési terület?”

Megoldás: Fókusz a magas kockázatú rendszerek (High-Risk AI Systems) követelményeire. Az AI Act III. melléklete listázza azokat a területeket, amelyek automatikusan magas kockázatúnak minősülnek. Ha a célrendszer ide tartozik, a törvény konkrét elvárásokat támaszt a robusztusság, adatminőség, naplózás és emberi felügyelet terén. A tesztterved gerincét ezeknek az elvárásoknak a validálása kell, hogy adja.

2. Probléma: „A modell torz eredményeket ad, de a fejlesztők szerint ‘az adatok ilyenek’.”

Megoldás: Adatminőség és torzítás tesztelése (Data Governance – Article 10). Az AI Act előírja, hogy a magas kockázatú rendszerek tanító-, validációs és tesztadatkészleteinek relevánsnak, reprezentatívnak, hibamentesnek és teljesnek kell lenniük. Red teamerként a feladatod, hogy ezt megkérdőjelezd.

Kérdés, amit fel kell tenned: „Hogyan tudjátok bizonyítani, hogy az adatkészlet nem tartalmazott olyan rejtett torzításokat, amelyek diszkriminatív eredményekhez vezetnek a védett csoportokkal szemben? Milyen módszerekkel mértétek és csökkentettétek ezt a kockázatot?”

A te támadásaid itt arra irányulhatnak, hogy szándékosan olyan bemeneti adatokat hozz létre (pl. demográfiai adatok finom megváltoztatásával), amelyek felfedik a modell rejtett torzításait.

3. Probléma: „A rendszer stabil a laboratóriumi teszteken, de a valós világ kaotikus.”

Megoldás: Robusztusság, pontosság és kiberbiztonság tesztelése (Article 15). Ez a cikkely a klasszikus Red Teaming legfontosabb jogi hivatkozási alapja. Előírja, hogy a rendszernek ellenállónak kell lennie a hibákkal és a rosszindulatú harmadik felek által végrehajtott manipulációs kísérletekkel szemben.

  • Adversarial támadások: Teszteld, hogy minimális, ember számára észrevehetetlen módosításokkal (pl. képpontok megváltoztatása) félrevezethető-e a modell.
  • Adatmérgezés (Data Poisoning): Vizsgáld meg, hogy a tanítóadatok közé csempészett rosszindulatú mintákkal lehet-e hátsó kaput (backdoor) létrehozni a modellben.
  • Robusztusság a váratlan bemenetekkel szemben: Mi történik, ha a rendszer olyan adatokkal találkozik, amelyek jelentősen eltérnek a tanítóadatok eloszlásától? Teszteld a rendszer viselkedését zajos, hiányos vagy formátumtól eltérő adatokkal.

4. Probléma: „Valami hiba történt, de a logokból semmi nem derül ki.”

Megoldás: Átláthatóság és naplózás tesztelése (Transparency & Logging – Articles 12-13). A törvény megköveteli az események automatikus naplózását (logging capabilities). A te feladatod nemcsak a naplózás meglétének ellenőrzése, hanem annak minőségi vizsgálata is. A logoknak elegendő információt kell tartalmazniuk ahhoz, hogy egy incidens vagy egy hibás döntés utólag visszakövethető legyen. Próbálj meg egy hibát előidézni, majd a fejlesztői csapattal közösen rekonstruálni az eseményeket kizárólag a logokra támaszkodva. Ha ez nem lehetséges, a rendszer nem felel meg az előírásnak.

5. Probléma: „A rendszer emberi felügyelet alatt áll, de a kezelő csak vakon rányom az ‘OK’ gombra.”

Megoldás: Az emberi felügyelet hatékonyságának tesztelése (Human Oversight – Article 14). Az AI Act előírja a hatékony emberi felügyeletet, beleértve a rendszer leállításának lehetőségét („stop button”). A Red Team feladata olyan szcenáriók szimulálása, amelyek tesztelik ezt a felügyeletet. Például: generálj nagy mennyiségű, gyorsan változó riasztást, hogy lásd, a kezelő képes-e lépést tartani (figyelmi túlterhelés). Vagy hozz létre olyan helyzetet, ahol a rendszer javaslata megtévesztő, de hihető, és vizsgáld, hogy a felügyelő személy észreveszi-e a hibát, vagy automatikusan jóváhagyja.

A Red Teamer szerepének átalakulása

Az AI Act bevezetésével a red teamer szerepe kibővül. Már nem elég pusztán technikai hibákat találni; képesnek kell lenned ezeket a hibákat jogi kontextusba helyezni. Egy sikeres adversarial támadás már nemcsak egy „P1 súlyosságú sebezhetőség”, hanem a 15. cikkely megsértésének konkrét bizonyítéka is. Ez a változás növeli a munkád súlyát és üzleti hatását, mivel a megállapításaid közvetlenül befolyásolhatják egy termék piacra dobásának jogszerűségét.