AI Act megfelelési dokumentáció: mit kér a hatóság, és hogyan állítsd össze

Melyik öt dokumentumot kell elő tudni venni egy magas kockázatú AI rendszernél?

Öt: az Annex IV szerinti műszaki dokumentáció (Art. 11), a kockázatkezelési rendszer nyilvántartása (Art. 9), az adatkormányzási leírás (Art. 10), a naplózási terv (Art. 12), és a használati útmutató az emberi felügyelet leírásával együtt (Art. 13 és Art. 14). Mind az öt a szolgáltatót terheli, és a rendelet 2027-12-02-i alkalmazási dátumára kell kész állapotban lennie.

Ez a felsorolás félrevezető lehet, ha öt külön dossziét képzelsz el. Az Annex IV 5. pontja magába hivatkozza a kockázatkezelési rendszer leírását, a 2. pont az adatkormányzást és az emberi felügyelet értékelését, a 9. pont pedig a piacra kerülés utáni megfigyelési tervet. A gyakorlatban egyetlen verziózott dokumentumfa működik, nem öt párhuzamos Word-fájl, amelyek fél év után ellentmondanak egymásnak.

Mikorra kell mindez kész? A 2026-os határidő elcsúszott

A magas kockázatú rendszerekre vonatkozó dokumentációs kötelezettségek nem 2026. augusztus 2-án léptek életbe. Az (EU) 2026/1744 rendelet (Digital Omnibus on AI) 2026-07-27-én hatályba lépett, és a III. fejezet 1–3. szakaszát, vagyis az Art. 8–27-et 2027-12-02-re halasztotta. A termékbe ágyazott rendszerek 2028-08-02-re csúsztak.

Tizenhat hónap haladék jól hangzik, de a dokumentáció nagy része visszamenőleg nem gyártható le. Az Annex IV 2. pontja dátumozott és aláírt tesztjegyzőkönyveket kér, a tervezési döntések indoklását, és azt, hogy milyen kompromisszumokat kötöttetek. Ha ezt 2027 őszén kezditek el, marad az utólagos rekonstrukció, amit egy auditon nehéz megvédeni.

A magyar oldalon van egy rendezetlen pont. A 2025. évi LXXV. törvény és a 344/2025. (X. 31.) Korm. rendelet még a 2026-08-02-es alkalmazási logikára épül. Nem találtunk publikus forrást arról, hogy ezeket a Digital Omnibus után hozzáigazították volna az új dátumokhoz. Ez a gyakorlatban nem ad felmentést, de érdemes figyelni a jogszabályváltozást.

Mit tartalmaz a műszaki dokumentáció az Art. 11 és az Annex IV szerint?

Az Annex IV kilenc pontból áll: általános rendszerleírás, a fejlesztési folyamat részletei, a működés és a kontroll bemutatása, a teljesítménymutatók indoklása, a kockázatkezelési rendszer leírása, az életciklus alatti változások, az alkalmazott szabványok listája, az EU megfelelőségi nyilatkozat másolata, és a piacra kerülés utáni megfigyelési terv. Az Art. 11(1) szerint mindezt piacra lépés előtt kell elkészíteni és naprakészen tartani.

1. Általános rendszerleírás

Rendeltetés, a szolgáltató neve, a verzió és annak viszonya a korábbi verziókhoz. Ide tartozik az is, hogy a rendszer milyen külső hardverrel, szoftverrel vagy más AI rendszerrel lép kapcsolatba, a szoftver- és firmware-verziók, a forgalomba hozatal formái (beágyazott szoftver, letöltés, API), a futtató hardver, és a felhasználói felület alapleírása.

Valós projektben ez a leggyorsabban elavuló fejezet. Ha kéthetente adtok ki verziót, a verziótörténet nem maradhat kézzel karbantartott táblázat, hanem a kiadási folyamatból kell generálni. A fejezetet a terméktulajdonos írja, a verzióadatokat a fejlesztés szolgáltatja.

2. A fejlesztési folyamat és a rendszerelemek részletes leírása

Ez a leghosszabb és a legritkábban elkészülő rész. Nyolc alpontja lefedi a fejlesztési módszereket és az előtanított modellek vagy harmadik féltől származó eszközök használatát, a tervezési specifikációt az algoritmus általános logikájával, a fő tervezési döntések indoklását, azt, hogy mire optimalizál a rendszer, az architektúrát és a tanításhoz használt számítási erőforrást, az adathalmazok datasheetjeit, az Art. 14 szerinti emberi felügyeleti intézkedések értékelését, az előre meghatározott változásokat, a validációs és tesztelési eljárásokat a diszkriminatív hatás vizsgálatával együtt, végül a kiberbiztonsági intézkedéseket.

A tesztjegyzőkönyveket a rendelet dátumozva és a felelős személy által aláírva kéri. Ez az a mondat, ami miatt a fejezetet nem lehet a projekt végén megírni. Ha a modell egy zárt API mögötti előtanított modellre épül, itt kell leírni, mit használtok, milyen verzióban, és hogyan módosítottátok. Aki emiatt inkább saját infrastruktúrán futtatna modellt, annak a lokális AI futtatásról szóló cikkünk adja meg a technikai kereteket.

Ezt a fejezetet a fejlesztési vezető és az ML-mérnök írja, a tesztjegyzőkönyveket a tesztelésért felelős kolléga jegyzi, a harmadik féltől származó komponensek licencfeltételeit pedig a jogi oldal nézi át.

3. A működés, a monitorozás és a kontroll

A rendszer képességei és teljesítménybeli korlátai, a pontosság mértéke azokra a személyekre és csoportokra bontva, akikre a rendszert szánták, az előrelátható nem szándékolt kimenetek, valamint az egészségre, a biztonságra, az alapvető jogokra és a diszkriminációra vonatkozó kockázatforrások. Ide kerül az Art. 14 szerinti emberi felügyelet technikai leképezése és a bemeneti adatra vonatkozó előírás.

A csoportbontott pontosság az a követelmény, ami miatt nem elég egy globális metrika. Kell egy szegmentált kiértékelő halmaz, és kell hozzá olyan attribútum, ami alapján szegmentálni tudsz. Ez adatvédelmi kérdéseket nyit, amire az Art. 10(5) ad kivételes jogalapot. Írja az ML-mérnök, jóváhagyja a terméktulajdonos.

4. A teljesítménymutatók megfelelőségének indoklása

Rövid fejezet, amit majdnem mindenki kihagy. Nem elég közölni, hogy a modell F1-értéke 0,91. Meg kell indokolni, miért az F1 a helyes mutató ehhez a rendeltetéshez, és miért nem a recall, a precízió vagy a kalibráció. Egy hitelbírálati modellnél ez a különbség rendszerint az, hogy kinek árt jobban a téves pozitív és kinek a téves negatív. Írja az ML-mérnök, lektorálja egy független belső szem.

5. A kockázatkezelési rendszer leírása

Az 5. pont az Art. 9 szerinti kockázatkezelési rendszert kéri részletes leírásban. Ez a következő szakasz témája, mert önálló nyilvántartásként érdemes vezetni, és csak hivatkozni rá innen.

6. Az életciklus alatti változások

Változásnapló arról, mit módosított a szolgáltató a rendszeren a teljes életciklus alatt. Ennek a fejezetnek van egy jogi éle: az Art. 25 szerint a lényeges módosítás átbillentheti a szerepeket, és aki eddig alkalmazó volt, szolgáltatóvá válhat. A változásnaplót a fejlesztés vezeti, de azt, hogy egy adott változás lényegesnek minősül-e, a jogi oldal mondja ki.

7. Az alkalmazott harmonizált szabványok listája

Fel kell sorolni azokat a harmonizált szabványokat, amelyeket alkalmaztok, és amelyek hivatkozását közzétették az Európai Unió Hivatalos Lapjában. Ha nincs alkalmazott harmonizált szabvány, akkor részletesen le kell írni, milyen más megoldással teljesítitek a III. fejezet 2. szakaszának követelményeit. A hiányzó szabvány tehát nem mentesít, hanem több írásmunkát jelent. Azt, hogy melyik szabvány jelent már meg harmonizáltként, a Hivatalos Lap aktuális jegyzékéből érdemes ellenőrizni, mert ez a lista gyorsan változik.

8. Az EU megfelelőségi nyilatkozat másolata

Az Art. 47 szerinti nyilatkozat írásbeli, gépi olvasható, és a szolgáltató saját felelősségére készül. Az Annex III rendszerek többségénél az Art. 43 alapján belső kontroll az értékelési út, tehát a nyilatkozatot a szolgáltató maga állítja ki, bejelentett szervezet bevonása nélkül. Aláírja a cégvezető vagy az arra felhatalmazott vezető, mert ez felelősségvállalás, nem adminisztráció.

9. A piacra kerülés utáni megfigyelési terv

Az Art. 72 szerinti terv, amelynek része, hogyan gyűjtitek és elemzitek a rendszer éles működéséből származó adatokat, és hogyan csatoljátok vissza a kockázatkezelésbe. Az Art. 72(3) alapján a Bizottságnak végrehajtási aktussal sablont kell kiadnia ehhez a tervhez, a rendelet szövegében szereplő határidő 2026-02-02 volt. Hogy a végleges sablon megjelent-e, azt a cikk lezárásakor nem tudtuk publikus forrásból megerősíteni, ezért a tervet érdemes úgy strukturálni, hogy később átemelhető legyen.

Mit tartalmaz a kockázatkezelési nyilvántartás az Art. 9 szerint?

Az Art. 9(2) szerint a kockázatkezelés folyamatos, iteratív folyamat a rendszer teljes életciklusán át, rendszeres felülvizsgálattal. Négy lépésből áll: az ismert és észszerűen előrelátható kockázatok azonosítása, ezek becslése rendeltetésszerű használat és észszerűen előrelátható visszaélés mellett, az éles működésből érkező adatok alapján felmerülő további kockázatok értékelése, végül a célzott mérséklő intézkedések elfogadása.

A nyilvántartás egy sora akkor használható, ha egy külső olvasó is meg tudja belőle mondani, mi történt. Ehhez kell a kockázat azonosítója és leírása, az érintett védett érdek (egészség, biztonság vagy alapvető jog), a bekövetkezés becsült valószínűsége és hatása, a mérséklő intézkedés, a maradékkockázat és annak elfogadása, a mérséklést igazoló teszt hivatkozása, a felelős neve, és a következő felülvizsgálat dátuma.

Az Art. 9(5) azt kéri, hogy a maradékkockázat kockázatonként és összességében is elfogadhatónak minősüljön, elsősorban tervezéssel és fejlesztéssel csökkentve, másodsorban kontrollintézkedésekkel, végül az Art. 13 szerinti tájékoztatással és képzéssel. Az Art. 9(9) külön kiemeli a 18 év alattiakra és más sérülékeny csoportokra gyakorolt hatás mérlegelését.

Az incidenskezelés a másik oldalról köti a nyilvántartást. Az Art. 73 szerint a súlyos incidenst az ok-okozati összefüggés megállapítása után haladéktalanul, de legkésőbb 15 napon belül be kell jelenteni; széles körű jogsértés vagy az Art. 3(49)(b) szerinti incidens esetén 2 napon belül. Ha az incidensből nem keletkezik új sor a kockázatnyilvántartásban, akkor a nyilvántartás nem él.

Hogyan írd meg az adatkormányzási leírást az Art. 10 alapján?

Az Art. 10(2) nyolc pontban sorolja fel, mit kell dokumentálni a tanító-, validációs és teszthalmazokról: a tervezési döntéseket, az adatgyűjtés folyamatát és az adatok eredetét, személyes adatnál az eredeti gyűjtési célt, az előkészítő műveleteket (annotálás, címkézés, tisztítás, frissítés, dúsítás, aggregálás), a feltételezéseket, az adathalmazok elérhetőségének és mennyiségének értékelését, a torzításvizsgálatot, a torzítás elleni intézkedéseket, végül az adathiányok azonosítását.

Az Art. 10(3) szerint az adathalmazoknak relevánsnak, kellően reprezentatívnak, és a lehetséges mértékben hibamentesnek és teljesnek kell lenniük a rendeltetéshez képest. Az Art. 10(4) a földrajzi, kontextuális, viselkedési és funkcionális sajátosságok figyelembevételét kéri. Ha a rendszer nem tanításos módszert használ, az Art. 10(6) szerint ezek a bekezdések csak a teszthalmazra vonatkoznak.

A leggyakoribb hiány nem a torzításvizsgálat, hanem az adateredet igazolása. Egy magyar KKV-nál a tanítóadat jellemzően a saját ERP-jéből vagy CRM-jéből jön, ahol az eredeti gyűjtési cél számlázás vagy ügyfélkezelés volt. Ezt az Art. 10(2)(b) miatt le kell írni, és a GDPR célhoz kötöttségével is össze kell egyeztetni.

Amit az omnibus módosított a torzításészlelésen

Az Art. 10(5) eredetileg a magas kockázatú rendszerek szolgáltatóinak adott kivételes jogalapot arra, hogy különleges kategóriájú személyes adatot kezeljenek torzításészlelés és -korrekció céljából, hat szigorú feltétel mellett: nincs más hatékony megoldás, technikai korlátok gátolják az újrafelhasználást, szigorú hozzáférés-kontroll és titoktartás, harmadik félnek nem továbbítható, a korrekció után törlés, és dokumentált indoklás. A Digital Omnibus ezt a jogalapot kiterjesztette minden MI-rendszerre, nem csak a magas kockázatúakra, és visszaállította a szigorú szükségesség mércéjét (Freshfields, 2026-07-10).

Ez jó hír annak, aki eddig azért nem mérte a torzítást, mert nem volt jogalapja a védett attribútumok kezelésére. Rossz hír annak, aki most azt gondolja, hogy szabad utat kapott: a hat feltétel megmaradt, és a dokumentált indoklás az egyik közülük.

Mit kell logolni, és meddig kell megőrizni a naplókat?

Az Art. 12(1) szerint a magas kockázatú rendszernek technikailag lehetővé kell tennie az események automatikus naplózását az élettartama alatt. Az Art. 12(2) három célt jelöl ki: a kockázatot okozó helyzetek és a lényeges módosítások azonosítása, az Art. 72 szerinti piacra kerülés utáni megfigyelés támogatása, és az Art. 26(5) szerinti működésfigyelés. A megőrzés alsó határa hat hónap.

Távoli biometrikus azonosításnál az Art. 12(3) konkrét minimumot ír elő: minden használat kezdő és záró időpontja, a referencia-adatbázis, amellyel a bemenetet összevetették, az a bemeneti adat, amelyre a keresés találatot adott, és az Art. 14(5) szerinti eredményellenőrzésben részt vevő természetes személyek azonosítása.

Itt van egy tévedés, amit sok fejlesztőcsapatnál látunk. Egy LLM-megfigyelő eszközben rögzített trace nem az Art. 12 szerinti napló. A trace fejlesztői célra készül, jellemzően mintavételezve, pár hetes megőrzéssel, és a promptot is tartalmazza. Az Art. 12 napló ezzel szemben az auditálhatóságot szolgálja, hat hónapon túl is, és személyes adatot csak a szükséges mértékben tartalmazhat. A két rendszer összeköthető, de nem helyettesíti egymást. A technikai oldalról a LangFuse és LangSmith összehasonlításunk mutatja, mit tud egy megfigyelő réteg, a Power Automate és a Python alapú stack összevetése pedig azt, hogy egy low-code platformból mennyivel nehezebb kinyerni az Art. 11, 12 és 13 által kért bizonyítékokat.

A naplózási terv maga rövid dokumentum. Sorolja fel az eseménytípusokat, a rögzített mezőket, a személyes adatok kezelésének jogalapját és minimalizálását, a megőrzési időt, a hozzáférési jogosultságokat, és azt, hogyan lehet a naplót a hatóság kérésére az Art. 21(2) alapján átadni.

Mit kell tartalmaznia a használati útmutatónak és az emberi felügyelet leírásának?

Az Art. 13(3) hat pontban határozza meg a használati útmutató tartalmát: a szolgáltató azonosító és elérhetőségi adatai, a rendszer képességei és teljesítménybeli korlátai, az előre meghatározott változások, az Art. 14 szerinti emberi felügyeleti intézkedések, a szükséges számítási és hardvererőforrás a várható élettartammal és karbantartással együtt, végül a naplók gyűjtését és értelmezését lehetővé tévő mechanizmusok leírása.

A képességek és korlátok pont a legsúlyosabb. Ide tartozik a rendeltetés, a tesztelt pontossági, robusztussági és kiberbiztonsági szint a metrikákkal együtt, minden ismert körülmény, ami ezt befolyásolhatja, az észszerűen előrelátható visszaélés melletti kockázatok, a kimenet magyarázatát segítő technikai lehetőségek, a teljesítmény konkrét személyekre vagy csoportokra vetítve, és a bemeneti adatra vonatkozó előírások.

Emberi felügyelet: az Art. 14 tervezési követelmény

Az Art. 14(1) szerint a rendszert úgy kell megtervezni, hogy a természetes személyek ténylegesen felügyelni tudják, a megfelelő ember-gép interfészeket is beleértve. Az Art. 14(4) öt képességet sorol fel, amit a felügyeletet ellátó személynek biztosítani kell: értse a rendszer képességeit és korlátait, és tudja észlelni az anomáliákat; ismerje fel az automatizálási torzítást; helyesen értelmezze a kimenetet; dönthessen úgy, hogy nem használja a rendszert, vagy felülírja a kimenetet; és tudja megállítani a működést.

Ezt a fejezetet nem lehet egy mondattal letudni. Ha a leírásban az áll, hogy a felhasználó felülbírálhatja a döntést, de a felületen nincs olyan gomb, ami ezt naplózottan megteszi, akkor a dokumentum és a rendszer ellentmond egymásnak. Az auditon a rendszer nyer.

Biometrikus azonosításnál az Art. 14(5) négy szem elvét ír elő: az azonosítás alapján csak akkor lehet eljárni, ha azt legalább két megfelelő felkészültségű és felhatalmazású természetes személy külön ellenőrizte és megerősítette.

Az alkalmazói oldal ehhez kapcsolódik. Az Art. 26 szerint a felügyeletet hozzáértő, képzett és felhatalmazott személyekre kell bízni, a bemeneti adatnak relevánsnak kell lennie, munkahelyi bevezetés előtt tájékoztatni kell a munkavállalói képviselőket és az érintett munkavállalókat, és a szolgáltatótól kapott információt fel kell használni a GDPR 35. cikk szerinti adatvédelmi hatásvizsgálathoz.

Ki írja melyik dokumentumot, és mikor kell frissíteni?

A dokumentáció akkor marad naprakész, ha minden munkatermékhez tartozik egy nevesített felelős és egy frissítést kiváltó esemény. A rendelet nem ír elő szervezeti felállást, csak eredményt: az Art. 11(1) szerint a műszaki dokumentációt naprakészen kell tartani, az Art. 9(2) szerint a kockázatkezelést rendszeresen felül kell vizsgálni.

A frissítés legnagyobb kockázata nem a lustaság, hanem az, hogy senki nem veszi észre, hogy frissíteni kellene. Ezért érdemes a kiadási folyamatba beépíteni egy ellenőrzőpontot: ha a változás érinti a modellt, a tanítóadatot, a rendeltetést vagy a felhasználói felületet, a kiadás addig nem megy ki, amíg az érintett fejezet nem frissült.

Mit kér egy hatósági ellenőrzés, és mennyi idő alatt kell előadni?

Az Art. 21(1) szerint a szolgáltató indokolt hatósági megkeresésre köteles átadni minden olyan információt és dokumentumot, amely a III. fejezet 2. szakaszának való megfelelést igazolja, a hatóság által könnyen érthető nyelven. Az Art. 21(2) alapján hozzáférést kell adni az Art. 12(1) szerinti naplókhoz is. A kapott információt az Art. 78 szerinti titoktartás védi.

Napokban mért határidőt az Art. 21 nem tartalmaz. A teljesítési határidőt a nemzeti eljárási jog és maga a hatósági felhívás szabja meg. Magyarországon a piacfelügyeleti hatóság a Mesterséges Intelligencia Hivatal, a bejelentő hatóság a Nemzeti Akkreditáló Hatóság, a pénzügyi szektorban pedig az MNB jár el ágazati piacfelügyeletként. A 344/2025. Korm. rendelet kizárja a sommás eljárást, és 30 napos megfizetési határidőt ír elő a kiszabott bírságra.

Az iratmegőrzés az Art. 18 szerint tíz év a forgalomba hozataltól vagy az üzembe helyezéstől: a műszaki dokumentáció, a minőségirányítási rendszer dokumentumai, a bejelentett szervezet által jóváhagyott változások és határozatok, valamint az EU megfelelőségi nyilatkozat. A bírságolási oldal az Art. 99 második tétele: 15 millió euró vagy a világméretű éves árbevétel 3%-a, amelyik magasabb; KKV-nál és startupnál az Art. 99(6) alapján a kettő közül az alacsonyabb.

Ha a dokumentáció ügyvédi titok vagy szigorított titoktartás alá eső adatokat is érint, azt a kezdetektől külön kell kezelni. Erre a helyzetre a jogi irodáknak szóló megoldásainknál írtuk le a mintát. Ha csak azt akarod látni, mi az a minimum csomag, amivel egy Annex III rendszer elindulhat, arra a magas kockázatú AI megfelelési checklistünk való, a besorolás és az auditra való felkészítés pedig az EU AI Act megfelelési szolgáltatásunk része.

Mi a dolgod, ha a rendszered nem magas kockázatú?

Ha a rendszer az Annex III valamelyik pontja alá esik, de az Art. 6(3) derogációra hivatkozva nem sorolod magas kockázatúnak, akkor az Art. 6(4) alapján az értékelést a piacra lépés vagy az üzembe helyezés előtt dokumentálnod kell, és a rendszert az Art. 49(2) szerint regisztrálni kell. A hatóság kérésére ezt a dokumentációt be kell mutatni. Profilalkotás esetén a derogáció nem alkalmazható.

A derogáció négy esete: a rendszer szűk eljárási feladatot lát el, korábban befejezett emberi tevékenység eredményét javítja, döntési minták eltérését észleli anélkül, hogy megfelelő emberi felülvizsgálat nélkül helyettesítené az emberi értékelést, vagy előkészítő feladatot végez. Mindegyikhez társul az a feltétel, hogy a rendszer ne jelentsen jelentős kockázatot az egészségre, a biztonságra vagy az alapvető jogokra.

A derogációs memó rövid dokumentum, de érdemes szigorúan felépíteni: a rendszer rendeltetése, melyik Annex III pont jöhetne szóba, melyik derogációs eset áll fenn és miért, miért nem valósul meg profilalkotás, milyen kockázatelemzés támasztja alá a jelentős kockázat hiányát, ki írta alá és mikor, valamint mikor kell újraértékelni. Ez a mi ajánlott szerkezetünk, nem jogszabályi forma.

Az Art. 6(5) szerint a Bizottságnak iránymutatást kell kiadnia a magas kockázatú és nem magas kockázatú rendszerek gyakorlati elhatárolásáról. A Digital Omnibus ezt a határidőt 2027-08-02-re tolta. Addig a besorolás saját felelősségre és saját érvelésre épül, ami a mi olvasatunkban óvatosságra int: kétes esetben a magas kockázatú kezelés drágább, de védhető, a téves derogáció pedig az Art. 99 alá visz.

Az omnibus a nem magas kockázatúnak minősített Annex III rendszerek regisztrációját megtartotta, de könnyebb adminisztrációval. A kötelezettség tehát nem tűnt el, csak kevesebb mezőt kell kitölteni.

Mit vigyél magaddal ebből?

Ez a cikk tájékoztatásra készült a felsorolt források alapján, és nem helyettesíti a konkrét rendszerre adott jogi véleményt. A besorolás és a dokumentáció tartalma rendszerenként eltér, a magyar végrehajtási szabályok pedig még mozgásban vannak.