EN 18286 felkészülés 5 lépésben: az AI governance-től az auditálható megfelelésig

Sorozatunk első cikkében bemutattuk az EN 18286:2026-ot, a másodikban pedig tisztáztuk, miért nem helyettesíti az ISO/IEC 42001 az AI Act 17. cikkét. Most jön a kérdés, ami minden ilyen beszélgetés végén elhangzik: „jó, de akkor hétfőn reggel mit csináljak?” Ez a cikk erre válaszol – öt lépésben, konkrét kimenetekkel. A legfontosabb üzenettel kezdjük: nagy valószínűséggel nem kell nulláról építkeznetek.

Miért nem kell a nulláról kezdeni?

A leggyakoribb hiba, amit felkészülési projekteknél látunk, hogy a szervezet önálló, párhuzamos „AI Act projektet” indít – új dokumentumsablonokkal, új kockázati módszertannal, új audit-ciklussal, a meglévő irányítási rendszerek mellett. Ez drága, lassú, és a végén két rendszer versenyez ugyanazokért az erőforrásokért.

Az EN 18286 felépítése épp az ellenkezőjét sugallja. A szabvány a klasszikus 4–10 fejezetes ISO-vázra épül, és tájékoztató mellékleteiben kifejezetten megfeleltetést közöl az ISO 9001-hez (C melléklet) és az ISO/IEC 42001-hez (D melléklet). Ez nem véletlen: a szabványalkotók abból indultak ki, hogy a legtöbb érintett szervezetnél már működik valamilyen menedzsmentrendszer.

Az igazi munka tehát nem a rendszer felépítése, hanem a meglévő rendszer kiterjesztése és a hiányzó, AI-specifikus rétegek beillesztése. Így néz ki ez öt lépésben.

1. lépés – AI-rendszerek és szerepkörök feltérképezése

Cél: tudni, mid van, és milyen minőségben vagy jelen a piacon.

Sok szervezet a leltározás során több AI-rendszert talál, mint amennyit elsőre számon tartott. Ennek tipikus okai a SaaS-eszközök beépített AI-funkciói, a saját fejlesztésű scoring-logikák és az „árnyék-AI” – vagyis az üzleti területek által önállóan bevezetett eszközök. A pontos eltérés szervezetenként változik, ezért ezt leltárral kell feltárni.

Két dimenziót kell rögzíteni minden rendszerre:

• Mi ez a rendszer? Rendeltetési cél, felhasználói kör, milyen döntést támogat vagy hoz, milyen adatokon.
• Mi a mi szerepünk benne? Ez a kritikus kérdés. Az AI Act megkülönbözteti többek között a szolgáltatót (provider) és az alkalmazót (deployer). A 25. cikk alapján forgalmazó, importőr, alkalmazó vagy más harmadik fél bizonyos esetekben szolgáltatóvá válhat: például ha egy már forgalomba hozott vagy használatba vett magas kockázatú AI-rendszeren a saját nevét vagy védjegyét tünteti fel, jelentős módosítást hajt végre rajta, vagy a rendeltetési célt úgy változtatja meg, hogy egy korábban nem magas kockázatú rendszer magas kockázatúvá válik.

Ezért a testreszabást és a white-label megoldásokat érdemes külön jogi-technikai vizsgálatnak alávetni. Egy toborzási eszköz finomhangolása vagy egy saját márkanév alatt kínált hitelbírálati funkció nem automatikusan teszi a szervezetet szolgáltatóvá; a 25. cikk feltételeit az adott módosítás, márkanévhasználat és rendeltetési cél alapján kell értékelni.

Kimenet: AI-leltár, rendszerenként rögzített rendeltetési céllal, szerepkörrel és jogilag releváns besorolással – például tiltott gyakorlat, magas kockázat, 50. cikk szerinti átláthatósági kötelezettséggel érintett vagy egyéb rendszer. A felmérés időigénye a szervezet méretétől és az AI-használat átláthatóságától függ; a 2–4 hét legfeljebb projektbecslésként kezelhető.

2. lépés – Az alkalmazandó AI Act követelmények meghatározása

Cél: hogy a projekt hatóköre ténykérdés legyen, ne vitatéma.

A leltár után rendszerenként kell eldönteni, mely követelmények élnek. Ez nem elméleti gyakorlat: közvetlenül meghatározza, hogy mekkora munka áll előttetek.

Az EN 18286 ZA melléklete jelzi, hogy a szabvány mely AI Act-követelmények lefedését célozza, többek között a 17. cikk (1) bekezdését és a 11. cikk (1) első mondatát. Jelenleg azonban nincs OJEU-hivatkozás. Egy későbbi hivatkozás joghatását az AI Act 40. cikke és a Bizottság által meghatározott pontos terjedelem alapján kell megítélni; ezért nem célszerű előre automatikus, teljes 17. cikk szerinti megfelelőségi vélelmet ígérni.

Kimenet: rendszerenkénti követelménytérkép („applicability matrix”), amely minden érintett rendszerhez hozzárendeli az alkalmazandó cikkeket és a felelős szervezeti egységet.

3. lépés – A meglévő folyamatok újrahasznosítása

Cél: megtalálni azt, ami már megvan – csak nem AI-nyelven van dokumentálva. Tapasztalataink szerint egy működő ISO-rendszerrel rendelkező szervezetnél ez jellemzően a követelmények 40–60 százaléka; ez saját projekttapasztalatunkon alapuló becslés, nem publikált statisztika.

Ez a lépés jelentősen befolyásolja a projekt idő- és erőforrásigényét. Minél több meglévő folyamat, kontroll és bizonyíték használható fel valóban, annál kisebb az újonnan kialakítandó megfelelési réteg.

A kulcsszó a kiterjesztés: ugyanaz a dokumentumkezelési eljárás, ugyanaz az auditprogram, ugyanaz a vezetőségi átvizsgálási ciklus – kiegészítve az AI-rendszerekre vonatkozó bemenetekkel. Ne indítsatok külön projektet arra, amit egy meglévő eljárás hatókörének bővítésével meg lehet oldani.

Kimenet: újrahasznosítási térkép, amely az EN 18286 fejezeteihez hozzárendeli a meglévő eljárásokat, és megjelöli, melyik igényel csak hatókörbővítést, és melyiket kell érdemben átírni.

4. lépés – A valódi hiányosságok azonosítása

Cél: hogy pontosan tudjátok, hol keletkezik új munka – és mennyi.

A gap-elemzést a 17. cikk (1) bekezdésének elemei, az EN 18286 követelményei és az adott rendszerre alkalmazandó további AI Act-kötelezettségek mentén érdemes futtatni. Tapasztalatunk szerint különösen az alábbi területeket célszerű külön ellenőrizni:

• Rendszerspecifikus megfelelőségi bizonyítékok. A szervezeti szintű QMS-politikák mellett meg kell határozni, hogy az egyes magas kockázatú AI-rendszerekre milyen dokumentáció és bizonyíték támasztja alá az alkalmazandó követelmények teljesítését.
• Változáskezelés folyamatosan tanuló rendszerekre. Az előre meghatározott, a megfelelőségértékeléskor figyelembe vett változásokat és a későbbi módosításokat olyan módon kell kezelni, hogy megállapítható legyen, szükséges-e új megfelelőségértékelés vagy dokumentációfrissítés.
• Incidensbejelentési határidők. A 73. cikk konkrét jogszabályi határidőket állapít meg, ezért a szervezetnek működő és tesztelt eszkalációs folyamatra van szüksége, nem pusztán általános incidenspolicy-ra.
• AI-specifikus beszállítói kontrollok. A modell-, adat- és komponensbeszállítókkal kapcsolatos információs és kontrolligényeket az adott ellátási lánc, szerződéses szerepek és kockázatok alapján kell meghatározni.
• Alapjogi szempontok – ahol alkalmazandó. A 27. cikk szerinti FRIA nem minden szolgáltató vagy alkalmazó általános kötelezettsége; meghatározott magas kockázatú rendszerek egyes alkalmazóira vonatkozik. Ahol releváns, célszerű a GDPR szerinti DPIA-val összehangolni.

Az EN 18286 emellett olyan témákat is kezel, amelyek a klasszikus QMS-ekben kevésbé megszokottak, például az érdekelt vagy érintett személyekkel kapcsolatos alapjogi szempontokat és a környezeti fenntarthatóságot. Ezeket nem szabad úgy bemutatni, mintha minden szervezet számára önálló, azonos tartalmú AI Act-kötelezettségek lennének; az alkalmazandóságot a szabvány és a konkrét jogszabályi szerep alapján kell megítélni.

Kimenet: priorizált hiánylista, mindegyik tételnél felelőssel, becsült ráfordítással és határidővel. A 2027. december 2-i dátumból csak a III. melléklet szerinti magas kockázatú rendszerek esetében kell visszaszámolni; az I. melléklet szerinti rendszerek fő határideje 2028. augusztus 2.

5. lépés – Dokumentáció, monitoring és bizonyítékok

Cél: hogy a megfelelés ne állítás legyen, hanem bemutatható.

Ebben a szakaszban válik a megfelelés ellenőrizhetővé. A hatósági vagy vevői átvilágításnál nem elegendő egy policy vagy általános állítás: az alkalmazandó követelményekhez naprakész, visszakereshető és konzisztens bizonyítékokat kell tudni kapcsolni.

A tipikus bizonyítékbázis – az adott rendszerre és szerepkörre való alkalmazhatóság szerint – például a következőkből állhat:

• Műszaki dokumentáció rendszerenként (11. cikk + IV. melléklet), verziókövetve
• Teszt- és validációs jegyzőkönyvek, a futtatás időpontjával és a felelőssel
• Adat-életút és adatkezelési bizonyítékok: ahol a 10. cikk alkalmazandó, dokumentálni kell többek között az adatok eredetét, előkészítését, releváns minőségi jellemzőit és kezelését; a pontos tartalom a rendszer és az adatfelhasználás jellegétől függ.
• Automatikus naplózás (12. cikk) – és a naplók megőrzési rendje
• Piacra kerülés utáni felügyeleti terv (72. cikk) és a hozzá tartozó mérési adatok
• Incidens-nyilvántartás és a bejelentések dokumentált nyomvonala (73. cikk)
• Változásnapló minden lényeges modell- vagy adatváltozásról
• Képzési nyilvántartás (4. cikk, AI-írástudás)
• Beszállítói megállapodások és AI-specifikus információátadási vagy kontrollklauzulák, ahol az ellátási lánc és a szerződéses szerepek ezt indokolják
• Vezetőségi átvizsgálási jegyzőkönyvek, amelyekben az AI-megfelelőség napirendi pont

A monitoring nem projektzárás utáni feladat. A szolgáltatói post-market monitoring az AI Act 72. cikke szerinti kötelezettség, a vezetőségi átvizsgálás pedig a QMS működtetésének része. Ezeket úgy érdemes bevezetni, hogy a tényleges működésről és felülvizsgálatról már a határidő előtt keletkezzenek bizonyítékok.

Kimenet: működő bizonyítékbázis, definiált tulajdonosokkal és felülvizsgálati ciklusokkal – nem egy mappa dokumentumokkal, hanem egy fenntartott rendszer.

Realisztikus ütemterv

Egy közepes méretű szervezetnél, több magas kockázatú rendszerrel a felkészülés könnyen több hónapos, összetett program lehet. A 12–18 hónap legfeljebb tapasztalati projektbecslésként használható; a tényleges időigényt a rendszerek száma, érettsége, a meglévő QMS és a hiányosságok súlya határozza meg.

A 2027. december 2-i határidő a III. melléklet szerinti magas kockázatú rendszerekre vonatkozik. Ezeknél a start valóban most van; az I. melléklet szerinti magas kockázatú rendszereknél a fő alkalmazási dátum 2028. augusztus 2. A működő ISO-rendszer előnyt jelenthet, de csak az újrahasznosítható kontrollok tényleges felmérése után.

Kezdjük az 1. lépéssel – együtt

A Harveys csapata ezt az öt lépést kulcsrakész módszertanként viszi végig. Ahol a legtöbb értéket tudjuk hozni:

• AI-leltár és szerepkör-tisztázás – a teljes rendszerállomány feltérképezése, a 25. cikk szerinti provider/deployer határvonal meghúzásával. Ez az a lépés, ahol a legtöbb szervezet kellemetlen meglepetéseket talál – jobb most, mint egy auditon.
• Újrahasznosítási és gap-elemzés – megmutatjuk, a meglévő ISO 9001 / ISO 42001 / ISO 27001 / GDPR apparátusotokból mi vihető át változtatás nélkül, mi igényel hatókörbővítést, és hol keletkezik valódi új munka. Priorizált hiánylistával és ütemtervvel.
• Bizonyítékbázis kialakítása.

Ha még nem olvastad, érdemes a sorozat előző részeivel kezdeni: EN 18286:2026 – maga a szabvány, illetve ISO/IEC 42001 és EN 18286 – a két szabvány kapcsolata.

Kezdjük el a felkészülést – közösen

A Harveys csapata AI Act megfelelőségi felkészítésre, tanácsadásra és folyamatos szakmai támogatásra specializálódott.

Kérjen rövid AI Act megfelelőségi felmérést. Megvizsgáljuk, hogyan érinti szervezetét az EU AI Act, mely rendszereknél szükséges részletesebb vizsgálat, és hol érdemes gap-elemzéssel kezdeni.

AI Act megfelelőségi felmérés →

Ez a cikk tájékoztató jellegű, és nem minősül jogi tanácsadásnak. A konkrét megfelelőségi kötelezettségek meghatározásához a rendszer és a szervezet egyedi vizsgálata, adott esetben jogi képviselő bevonása szükséges.