27.5.1. EU AI Act megfelelőségi ellenőrző lista

2025.10.06.
AI Biztonság Blog

Az Európai Unió Mesterséges Intelligencia Törvénye (AI Act) nem csupán egy újabb szabályozás a sok közül; ez a világ első horizontális, átfogó jogi keretrendszere az MI számára. Red teamerként a feladatunk túlmutat a technikai sebezhetőségek feltárásán: a szabályozói elvárásoknak való megfelelést is tesztelnünk kell. Ez a lista gyakorlati mankót nyújt ahhoz, hogy a red teaming tevékenységed során célzottan vizsgáld az AI Act kulcsfontosságú követelményeit, különösen a magas kockázatú rendszerek esetében.

Kapcsolati űrlap

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

Az AI Act kockázati piramisa: A besorolás elsődlegessége

Mielőtt bármilyen ellenőrzésbe kezdenél, az első és legfontosabb lépés a vizsgált MI rendszer kockázati besorolásának megértése. Az AI Act egy négyfokozatú, kockázatalapú megközelítést alkalmaz, ami alapjaiban határozza meg a kötelezettségek mértékét. A te munkád fókusza is ezen a besoroláson múlik.

Elfogadhatatlan (Tilos) Magas Kockázat Korlátozott Kockázat (Átláthatóság) Minimális Kockázat

Ellenőrző lista magas kockázatú AI rendszerekhez

A red teaming tevékenység leginkább a magas kockázatú rendszerekre fókuszál, mivel itt a legszigorúbbak a követelmények és a legnagyobb a potenciális kár. Az alábbi táblázat a legfontosabb területeket foglalja össze, red teamer szempontból értelmezve.

Követelmény (AI Act Cikkek alapján) Red Teaming Ellenőrzési Pontok és Kérdések Státusz / Megjegyzés
Adatok és adatkormányzás
(Cikk 10)
  • Torzítás (Bias): Futtass teszteket védett jellemzőkkel (pl. nem, etnikum) rendelkező szintetikus vagy valós adatokkal! A modell aránytalanul rosszul teljesít valamelyik csoporton?
  • Adatszivárgás: Próbálj meg a modell kimeneteiből a tanító adathalmaz egyedi elemeire visszakövetkeztetni (tagsági következtetéses támadás)?
  • Relevancia: Az adathalmaz valóban lefedi a tervezett felhasználási környezetet? Keress olyan „edge case” eseteket, amikre a rendszer nincs felkészítve!
Technikai dokumentáció
(Cikk 11)
  • A dokumentáció naprakész és tükrözi a rendszer jelenlegi állapotát? Próbálj meg a dokumentáció alapján reprodukálni egy viselkedést!
  • A leírt korlátok és gyengeségek valósak? Teszteld a rendszer viselkedését a dokumentációban leírt korlátokon túl!
  • A dokumentáció tartalmazza az adatkezelési folyamatokat, a bias-tesztelés eredményeit és a validálási metrikákat?
Naplózás (Record-keeping)
(Cikk 12)
  • A rendszer automatikusan és manipulálhatatlanul naplózza a működési eseményeket (pl. döntések, emberi felülvizsgálatok)?
  • Kísérelj meg egy eseményt a naplók módosításával vagy törlésével eltüntetni!
  • A naplók elegendő információt tartalmaznak egy incidens utólagos kivizsgálásához? Szimulálj egy hibás döntést és próbáld meg a naplók alapján rekonstruálni az okokat!
Átláthatóság és tájékoztatás
(Cikk 13)
  • A felhasználói felület egyértelműen tájékoztatja a felhasználót a rendszer képességeiről, korlátairól és az emberi felügyelet lehetőségéről?
  • A rendszer által generált magyarázatok (explainability) félrevezetőek vagy manipulálhatóak? Próbálj meg olyan bemenetet adni, ami logikátlan kimenetet ad, de a magyarázat hihetőnek tűnik!
Emberi felügyelet
(Cikk 14)
  • Lehetséges-e a rendszer döntését egy embernek hatékonyan felülbírálni, leállítani vagy ignorálni? Teszteld a „stop” gomb működését valós idejű, kritikus szimulációkban!
  • A felügyeletet végző személy kap elég kontextust és időt a beavatkozáshoz? Generálj nagy mennyiségű riasztást, hogy teszteld a „riasztási fáradtságot”!
  • A rendszer automatizálási foka nem vezet a kezelő de-kvalifikálódásához vagy a túlzott bizalomhoz?
Pontosság, robusztusság és kiberbiztonság
(Cikk 15)
  • Robusztusság: Teszteld a rendszert zajos, hiányos vagy szándékosan megtévesztő bemenetekkel (adversarial attacks)!
  • Pontosság: A megadott pontossági szintek a valós működési környezetben is tarthatóak? Teszteld a rendszert a laboratóriumi körülményektől eltérő adatokon!
  • Kiberbiztonság: A hagyományos pentesting mellett fókuszálj a modellspecifikus támadásokra: modelllopás, adat-mérgezés (data poisoning), prompt injection, stb.

Korlátozott és elfogadhatatlan kockázatok kezelése

Bár a fókusz a magas kockázatú rendszereken van, ne feledkezz meg a többi kategóriáról sem:

  • Korlátozott kockázat: Itt a fő követelmény az átláthatóság. Ha egy rendszerrel interakcióba lépsz (pl. chatbot), vagy MI által generált tartalmat (pl. deepfake) látsz, erről a felhasználót egyértelműen tájékoztatni kell. Red teamerként tesztelheted, hogy ezek a tájékoztatások megkerülhetők-e, vagy elég egyértelműek-e egy átlagos felhasználó számára.
  • Elfogadhatatlan kockázat: Ezek a rendszerek egyszerűen tiltottak az EU-ban. Ilyenek például a kormányzati célú társadalmi pontozórendszerek vagy a tudatalatti manipulatív technikák. Itt a red teamer feladata annak ellenőrzése, hogy a fejlesztett rendszer funkciói nem csúsznak-e át véletlenül vagy szándékosan ebbe a kategóriába.

Összegzés: A megfelelőség mint folyamatos feladat

Ez az ellenőrző lista egy kiindulópont. Az AI Act egy komplex, élő jogszabály, amelynek értelmezése folyamatosan fejlődni fog. A red teaming szerepe itt kulcsfontosságú: nem elég a jogi szöveget kipipálni, proaktívan kell keresni azokat a kiskapukat és váratlan viselkedési formákat, amelyek megsérthetik a törvény szellemét, még ha a betűjét nem is. A te munkád segít abban, hogy egy szervezet ne csak megfeleljen, hanem valóban megbízható és biztonságos MI-t építsen.