Az AI ISO/IEC szabványcsalád a gyakorlatban

A kézikönyv egy kis AI tanácsadó és fejlesztő szervezet szemszögéből rendezi el az ISO/IEC JTC 1/SC 42 és a kapcsolódó bizottságok AI szabványait. Példáink egyéni vállalkozóra vagy néhány fős csapatra szabottak, amely Claude API-ra, Supabase-re és Next.js-re épít, és EU ügyfeleknek dolgozik. Minden szabványnál ugyanaz az öt kérdés szerepel. Mit ad, mikor kell, mit csinál vele a fejlesztő egy LLM vagy ügynök projektben, milyen bizonyíték keletkezik, és melyik dokumentumba kerül.

Az ISO megfelelés és audit kézikönyv a 42001 és a 42005 alapjait már tartalmazza (fő követelmények, az A melléklet területei egy táblában, az AI rendszer kártya mezői). Erre épül itt a kontrollok egyenkénti kibontása, a családi szabványok, a tanúsítói oldal (42006), az európai harmonizált szabványok és egy egyszemélyes szervezet tanúsítási útja. A technikai védelmet (prompt injekció, MCP, eval, RAG elválasztás) az AI ügynökök és vibecoding kézikönyv írja le, arra hivatkozunk, nem ismételjük.

A szabványok szövege jogvédett, ezért a kontrollok és követelmények lényege saját megfogalmazásban áll, a szám és a cím a hivatkozást szolgálja, a kötelező tartalmat a megvásárolt szabványból kell ellenőrizni. Ez a kézikönyv nem jogi tanács és nem tanúsítási garancia. Tanúsítványt akkreditált tanúsító ad ki saját auditja alapján, az AI Act szerinti minősítés jogászi feladat.

0. Dokumentumtípusok. Mi tanúsítható és mi nem

Az ISO világban a dokumentum típusa dönti el, hogy auditálni lehet-e ellene.

Egy útmutató szabvány nem tanúsítható, a súlya mégis valós. Ha a szervezet az AI politikájában vagy az eljárásaiban kijelenti, hogy a 23894 szerint kezeli a kockázatot, az auditor ezt a vállalást ellenőrizni fogja. Hivatkozni tehát csak arra érdemes, amit a működés valóban követ.

Az 5259 sorozatban vegyes a kép. Saját leírása szerint az 5259-3 követelményeket és útmutatót is ad az adatminőség irányításához, de önálló tanúsítási séma 2026 októberében nem ismert. A gyakorlatban a 42001 A.7 kontrolljainak bizonyítékaként használjuk.

1. Státusztábla, 2026. október 20.

Az adatok az iso.org katalógusából, nemzeti szabványügyi testületek adatbázisaiból (SCC, EVS, DIN), a CEN-CENELEC és a JTC 21 közleményeiből, valamint másodlagos összefoglalókból származnak. A katalógus naponta változik, ezért audit és ajánlat előtt az iso.org adatlapot újra meg kell nézni. Az ellenőrizendő jelzés olyan adatot jelöl, amely a szerkesztéskor csak másodlagos forrásból vagy egymásnak ellentmondó forrásokból volt megállapítható.

1.1 Megjelent dokumentumok

1.2 Fejlesztés alatt

A táblában szereplő szakaszok és dátumok mind a 2026 októberi állapotot tükrözik, és mind ellenőrizendők, mert az ISO és a CEN adatlapjai gyakran eltérő szakaszt mutatnak.

Nincs ilyen szabvány. ISO/IEC 42002 és 42004 nem létezik. A 17847 nem önálló kiadvány, a tartalma a 42119-3 alatt fut. Ha egy ügyfél vagy egy szállító ilyen számra hivatkozik, a forrást ellenőrizni kell.

2. ISO/IEC 22989:2022. Fogalmak és szerepek

Mit ad. Közös szókincset az AI rendszerre, a modellre, a tanításra, a megbízhatóságra és az érdekelt felekre. A 42001 normatívan hivatkozik rá, vagyis a 42001 fogalmait a 22989 szerint kell érteni. Az ISO Publicly Available Standards oldalán 2024 óta ingyenesen elérhető volt, a jelenlegi állapot ellenőrizendő.

Mikor kell. Minden AIMS hatókör megfogalmazásakor, és amikor egy szerződésben vagy ajánlatban el kell dönteni, ki a szolgáltató és ki a felhasználó.

2.1 Szerepek (AI stakeholder roles)

A 22989 szerepkategóriái saját összefoglalásban.

Az Anthropic ebben a képben platform szolgáltató és a modell előállítója, a tanácsadó pedig a 42001 A.10 értelmében az ő ügyfele. Ez a láncolat kerül az AIMS hatókörébe és a beszállítói nyilvántartásba.

Az AI Act szerepei nem azonosak. Az AI Act provider és deployer fogalma jogi kategória, a 22989 szerepei leíró kategóriák. Egy tanácsadó, aki saját nevén hoz forgalomba egy rendszert, AI Act szerinti provider. Ha az ügyfél nevén és felelősségére fejleszt, gyakran az ügyfél a provider, a tanácsadó pedig alvállalkozó fejlesztő. A megosztást a szerződésben kell rögzíteni, és a minősítés jogászi kérdés.

2.2 Életciklus és megbízhatóság

A 22989 életciklus modellje a tervezéstől a kivezetésig tart (kezdeményezés, tervezés és fejlesztés, verifikáció és validáció, telepítés, üzemeltetés és monitorozás, folyamatos validáció, újraértékelés, kivezetés). Az LLM projektben a folyamatos validáció a legfontosabb fázis, mert a modellt a szolgáltató cserélheti, a RAG korpusz pedig naponta változik.

A megbízhatósági jellemzők (robusztusság, megbízhatóság, rendelkezésre állás, ellenállóképesség, biztonság, adatvédelem, elszámoltathatóság, átláthatóság, magyarázhatóság, irányíthatóság, előrejelezhetőség, méltányosság) a későbbi szabványok fejezetcímei lesznek. Ezek közül a 25059, a 24028 és a 24029 emel ki néhányat mérhető formában.

Fejlesztői gyakorlat. Az AI rendszer kártya szerep mezője a 22989 kategóriáit használja, az AI Act szerinti szerepet külön sorban, indoklással rögzíti. A rendszerleírásban szétválik a modell (például Claude), az AI rendszer (az ügynök a promptokkal, eszközökkel, RAG-gel) és az AI szolgáltatás (amit az ügyfél kap).

Bizonyíték. Hatókör dokumentum a szerepekkel, AI rendszer leltár szerepenként.

Amd 1. A generatív AI fogalmait hozó módosítás 2026 őszén FDAmd szakaszban van (ellenőrizendő). Megjelenése után a kártyák fogalomhasználatát érdemes hozzáigazítani (foundation model, prompt, finomhangolás, ágens jellegű rendszer).

3. ISO/IEC 42001:2023 mélyen

3.1 A 4-10. klauzula AI sajátos tartalma

Az ISO megfelelés és audit kézikönyv a fő követelményeket összefoglalta. Klauzulánként az alábbiak mutatják, mi tér el a 27001 logikájától, és mit kérdez belőle egy auditor egy kis AI fejlesztőnél.

4. A szervezet környezete.

• 4.1 a belső és külső tényezők között az AI rendszerek rendeltetését és a szervezet szerepét (22989) is meghatározza. Külső tényező lehet az AI Act, a GDPR, az ügyfelek ágazati szabályai, a modellszolgáltatók piaca, a méltányosság iránti társadalmi elvárás.
• 4.2 az érdekelt felek között megjelennek az AI subjectek, vagyis akikre a kimenet hat, akkor is, ha nem felhasználók.
• 4.3 a hatókör AI rendszerekre és szerepekre is szól. Egy kis szervezetnél a hatókör jellemzően ilyen. Ügyfelek számára fejlesztett és üzemeltetett LLM alapú ügynökök, RAG alkalmazások és MCP szerverek tervezése, fejlesztése, átadása és üzemeltetési támogatása, AI producer és AI provider szerepben.
• 4.4 az AIMS kiépítése és fenntartása, a folyamatok és kölcsönhatásaik.

5. Vezetés.

• 5.1 a felső vezetés elkötelezettsége. Egyszemélyes szervezetben a vezető maga a fejlesztő, ezért az auditor azt nézi, hogy a döntések (kockázat elfogadása, release, modellcsere) dokumentáltan, időben elkülönítve születnek-e.
• 5.2 AI politika, amely keretet ad az AI célokhoz, elkötelezettséget vállal a követelmények teljesítésére és a folyamatos fejlesztésre. Dokumentuma az AI politika.
• 5.3 szerepek, felelősségek, hatáskörök. Egy embernél is ki kell mondani, ki dönt release-ről, ki bírálja felül a kimenetet az ügyfélnél, ki a kapcsolattartó incidensnél.

6. Tervezés.

• 6.1.1 a kockázatok és lehetőségek kezelésénél a szervezet megkülönbözteti az elfogadható és a nem elfogadható kockázatot. Ez az AI kockázati kritérium, amelyet a 23894 részletez.
• 6.1.2 AI kockázatértékelés, az AI célokhoz viszonyítva. Lehet a szervezet szintjén és AI rendszerenként.
• 6.1.3 AI kockázatkezelés, az A melléklet kontrolljainak összevetésével, Statement of Applicability készítésével, a kihagyások indoklásával. A szervezet saját kontrollt is felvehet, és más forrást (például OWASP) is használhat.
• 6.1.4 AI rendszer hatásvizsgálat. Egyénekre, csoportokra és a társadalomra gyakorolt következmények, a rendeltetés és az előre látható helytelen használat alapján. Az eredményét a kockázatértékelésben figyelembe kell venni. Részletei a 42005 lépéseinél állnak.
• 6.2 AI célok mérhetően, felelőssel, határidővel. Dokumentuma az AI célok listája.
• 6.3 változások tervezése.

7. Támogatás. 7.1 erőforrások, 7.2 kompetencia, 7.3 tudatosság, 7.4 kommunikáció, 7.5 dokumentált információ. AI sajátosság, hogy a kompetenciának ki kell terjednie az AI technológiára és a hatásokra, és a tudatosság része az AI politika és a saját hozzájárulás ismerete. Az AI Act 4. cikk szerinti AI jártasság bizonyítéka is ide kerülhet.

8. Működés.

• 8.1 működés tervezése és irányítása, beleértve a kiszervezett folyamatokat. A modellszolgáltató és a felhő kiszervezett folyamat, ellenőrzése kell.
• 8.2 AI kockázatértékelés tervezett időközönként és jelentős változáskor.
• 8.3 AI kockázatkezelési terv végrehajtása.
• 8.4 AI hatásvizsgálat tervezett időközönként és jelentős változáskor.

9. Teljesítményértékelés.

• 9.1 monitorozás, mérés, elemzés. AI mérőszámok kellenek (eval pontszám, felülbírálási arány, eszközhívás hibaarány, incidensszám, költség, válaszidő).
• 9.2 belső audit. Egyszemélyes szervezetben a saját munka auditálása függetlenségi problémát okoz, ezért külső belső auditor vagy kölcsönös audit egy másik tanácsadóval a szokásos megoldás.
• 9.3 vezetőségi átvizsgálás, legalább évente.

10. Fejlesztés. 10.1 folyamatos fejlesztés, 10.2 nem megfelelőség és helyesbítő intézkedés. Az AI incidens (káros kimenet, jogosulatlan eszközhívás, adatszivárgás) ide fut be, és a kockázatértékelés frissítését is kiváltja.

Kötelező dokumentált információk, saját listázásban. Hatókör, AI politika, AI kockázatértékelési folyamat és eredmény, AI kockázatkezelési folyamat és eredmény, Statement of Applicability, hatásvizsgálati folyamat és eredmény, AI célok, kompetencia bizonyíték, a működési tervezéshez szükséges dokumentáció, monitorozás és mérés eredménye, belső audit program és eredmény, vezetőségi átvizsgálás eredménye, nem megfelelőségek és helyesbítések. A teljes, hiteles lista a szabványban található, a fenti saját összeállítás.

3.2 Az A melléklet 38 kontrollja egyenként

Minden kontroll lényege saját szavakkal áll. Az LLM projekt oszlop egy Claude API-ra épülő, Supabase hátterű, eszközhívó ügynökre vonatkozik. Két szintet különít el a bizonyíték oszlop. A projekt szintű dokumentumok az adott rendszer repójában élnek (például egy külön compliance mappában), a szervezeti szintűek a szervezet saját irányítási rendszerében, egyetlen példányban.

A.2 AI politikák

A.3 Belső szervezet

A.4 Erőforrások

A.5 Hatások értékelése

A.6 AI rendszer életciklus

A.7 Adatok az AI rendszerekhez

A.8 Információ az érdekelt feleknek

A.9 AI rendszerek használata

A.10 Harmadik fél és ügyfél kapcsolatok

A 38 kontroll mind kötelezően értékelendő a Statement of Applicabilityben. Kihagyni csak indoklással lehet, és egy LLM fejlesztőnél szinte mindegyik alkalmazandó. A leggyakoribb jogos kizárás az A.7 egy része, ha a szervezet saját tanítást nem végez. Ez csak akkor igaz, ha RAG-et, eval készletet és few shot példát sem kezel, ami ritka.

3.3 A B melléklet. Megvalósítási útmutató

A B melléklet kontrollonként leírja, milyen tartalom és megvalósítás várható. Normatívan nem kötelező, de az auditor a B melléklet szerint kérdez. Néhány kontrollnál a lényege saját szavakkal a következő.

• AI politika. A politika a szervezet üzleti stratégiájából, kockázati étvágyából és jogi környezetéből indul, és témaspecifikus szabályzatokra (AI erőforrások, hatásvizsgálat, fejlesztés) hivatkozhat.
• Aggályok jelentése. A jelentő védelme, névtelen jelzés lehetősége, a jelzés kivizsgálása és visszajelzés.
• Erőforrások. Az adat, eszköz, számítás és emberi kompetencia leírása rendszerenként, mert az AI rendszer megértéséhez és a kockázatértékeléshez ez az alap.
• Hatásvizsgálat. Mikor kell, ki végzi, milyen szempontok szerint, hogyan kerül az eredmény a tervezésbe, és ki hagyja jóvá. A tartalmi szempontok (méltányosság, átláthatóság, biztonság, adatvédelem, társadalmi hatás) felsorolása.
• Verifikáció és validáció. Értékelési módszerek és metrikák kiválasztása, a tesztadat függetlensége a fejlesztési adattól, az elfogadási kritérium előre rögzítése.
• Eseménynaplók. Naplózás a rendszer teljesítményének és a hibák nyomon követésének támogatására, a naplók megőrzése és védelme.
• Adatminőség. A minőségi követelmények meghatározása a rendeltetéshez, az adat reprezentativitása, a bias forrásai az adatban.
• Harmadik fél. Szerződéses rögzítés, beszállítói értékelés, a beszállító által adott modell vagy adat dokumentációjának bekérése.

Fejlesztői gyakorlat. A B melléklet egyben a belső audit kérdéslistája. A kártyák kitöltésekor kontrollonként végigmegyünk azon, amit a B melléklet a megvalósításhoz sorol. Ahol nincs válasz, a mező kitöltetlen jelöléssel marad, kitalált tartalom helyett. Ha a kártya első vázlatát AI asszisztens készíti elő, ugyanez a szabály rá is vonatkozik.

3.4 A C melléklet. Szervezeti célok és kockázatforrások

A C melléklet informatív listákat ad, amelyekből a szervezet az AI céljait és a kockázatértékelés forrásait választja.

Lehetséges szervezeti célok. Elszámoltathatóság, AI szakértelem, a tanító és tesztadat elérhetősége és minősége, környezeti hatás, méltányosság, karbantarthatóság, adatvédelem, robusztusság, biztonság (safety), információbiztonság (security), átláthatóság és magyarázhatóság.

Kockázatforrások. A környezet összetettsége, az átláthatóság és magyarázhatóság hiánya, az automatizáltság szintje, a gépi tanulás sajátos kockázatai (adatminőség, adatmérgezés, drift), hardver problémák, életciklus problémák (rossz tervezés, hiányzó karbantartás, kivezetés), a technológia érettsége.

LLM projektben. Az AI célok listája innen választ, mérőszámmal. Kockázatforrásként a kockázatregiszter kategória oszlopába kerülnek. Ügynöknél az automatizáltság szintje és az átláthatóság hiánya a két legerősebb forrás. A technológia érettsége akkor kerül elő, ha az ügyfél frissen megjelent modellt vagy béta API-t akar.

3.5 A D melléklet. Szektorok és integráció

A D melléklet kimondja, hogy az AIMS bármely szektorban alkalmazható (egészségügy, védelem, közlekedés, pénzügy, foglalkoztatás, energia), és hogy más irányítási rendszerekkel (27001, 27701, 9001) integrálható. Szektorspecifikus szabályokat nem ír elő, csak jelzi, hogy ilyenek léteznek és figyelembe veendők.

LLM projektben. Egy pénzügyi ügyfélnél a DORA és a pénzügyi felügyeleti elvárás, egy egészségügyi ügyfélnél az orvostechnikai eszköz szabályozás, egy HR projektnél az AI Act III. melléklete kerül a 4.1 külső tényezői közé. A jogi követelmények nyilvántartása (önálló dokumentum vagy a 27001 ISMS meglévő regisztere) szektoronként bővül.

3.6 A Statement of Applicability AI-ra

A 42001 SoA a 27001 SoA mintájára készül, de külön dokumentum, vagy integrált rendszerben külön szakasz. Minden A melléklet kontrollnál rögzíti, alkalmazandó-e, miért, megvalósult-e, és hol a bizonyíték. A szervezet saját kontrolljai (például lethal trifecta értékelés vagy az AI ügynökök és vibecoding kézikönyv MCP szerver bekötési checklistje) ugyanebbe a táblába kerülnek, forrásjelöléssel.

Ha a szervezetnek már van 27001 SoA-ja, az AI szakasz hozzáadásakor a fenti 38 sor kerül bele, a meglévő oszlopszerkezettel.

4. ISO/IEC 42005:2025. AI rendszer hatásvizsgálat lépésenként

Az ISO megfelelés és audit kézikönyv a mikor és a mit kérdését összefoglalta. Itt végrehajtási lépésekre bontva, saját folyamatként áll, a 42005 szempontjai alapján.

Mit ad. Útmutatót arra, hogyan értékelje egy szervezet egy AI rendszer és előre látható alkalmazásai hatását egyénekre, csoportokra és a társadalomra, mikor és az életciklus mely pontján, és hogyan illessze ezt a kockázatkezelésbe és az AIMS-be. Nem tanúsítható. A 42001 6.1.4, 8.4 és A.5 tartalmát tölti ki.

Mikor kell. Minden új AI rendszernél tervezéskor, élesítés előtt, és jelentős változáskor. Magas kockázatú AI Act rendszernél az alapjogi hatásvizsgálat (27. cikk, a deployer bizonyos köreinél kötelező) és a GDPR DPIA mellett.

4.1 A lépések

1. Kiváltó esemény rögzítése. Új rendszer, új modell, új eszköz írási joggal, új adatforrás, új felhasználói kör, új cél, incidens, szabályozási változás. A kiváltók listája a hatásvizsgálati dokumentum elején áll, hogy egy változásnál gépiesen eldönthető legyen, kell-e új vizsgálat.
2. Hatókör és rendszerleírás. Mi a rendszer, mi a rendeltetése, milyen környezetben fut, milyen modell és eszközök vannak benne. Hivatkozás az AI rendszer kártyára, nem másolat.
3. Rendeltetés és előre látható helytelen használat. Mire való, és mire fogják valószínűleg mégis használni. Egy dokumentum összefoglaló asszisztensnél az előre látható helytelen használat a jogi vélemény helyettesítése.
4. Érintettek azonosítása. Közvetlen felhasználók, a kimenet alanyai, a nem felhasználó harmadik felek, a sérülékeny csoportok (kiskorúak, idősek, nem anyanyelvi felhasználók, fogyatékossággal élők).
5. Adatok és technológia jellemzése. Milyen adatból dolgozik, mennyire reprezentatív a felhasználói körre, milyen ismert korlátai vannak a modellnek (nyelv, tudás dátuma, hallucináció).
6. Lehetséges előnyök. A hatásvizsgálat nem csak ártalomlista. Rögzíti, kinek és mennyit ér a rendszer, mert az arányosság mérlegelése ehhez képest történik.
7. Lehetséges ártalmak dimenziónként. Tévedés és megbízhatóság, méltányosság és diszkrimináció, magánszféra, biztonság (fizikai és információs), átláthatóság és magyarázhatóság, emberi autonómia és manipuláció, munkára és megélhetésre gyakorolt hatás, környezeti hatás, társadalmi szintű hatás (félretájékoztatás, bizalomvesztés).
8. Súlyosság és valószínűség értékelése. A szervezet AI kockázati kritériumai szerint, ugyanazon a skálán, mint a kockázatregiszter, hogy a két dokumentum összevethető legyen.
9. Intézkedések. Technikai (eszközjogosultság, kimenet validálás, emberi jóváhagyás), szervezeti (képzés, használati szabály), tájékoztatási (AI jelzés, korlátok közlése).
10. Maradék hatás és elfogadás. Ki fogadja el a maradék hatást, milyen indokkal, és meddig érvényes az elfogadás.
11. Monitorozás. Milyen jel mutatja, hogy a hatás a vártnál rosszabb (panaszok száma, felülbírálási arány, eval eredmény csoportonként).
12. Dokumentálás és kommunikáció. Verziózott dokumentum, jóváhagyás, és döntés arról, mit kap meg belőle az ügyfél vagy a nyilvánosság.
13. Visszacsatolás. Az eredmény frissíti a kockázatregisztert és a tervezést.

4.2 Kapcsolódás a DPIA-hoz és az alapjogi hatásvizsgálathoz

Egy kis projektben a három vizsgálat egy helyen él. Az AI hatásvizsgálat tartalmazza a 42005 szerinti teljes vizsgálatot. Ehhez képest az adatkezelési és DPIA dokumentum a GDPR 35. cikk szerinti, személyes adatokra vonatkozó részt viszi, és a közös szakaszokra kereszthivatkozik. Ha az alapjogi hatásvizsgálat kötelező, az a deployer (gyakran az ügyfél) dokumentuma, a tanácsadó a saját vizsgálatával támogatja.

LLM példa. Egy ügyfélszolgálati ügynök, amely visszatérítést kezdeményezhet. Érintett a visszatérítést kérő ügyfél, az ügyintéző és a cég pénzügye. Az ártalmak között a jogos kérés elutasítása, a manipulálható visszatérítés (prompt injekció), a magyarul rosszul fogalmazó ügyfelek hátrányos kezelése szerepel. Intézkedésként egy összeghatár feletti emberi jóváhagyás, kimenet validálás, és nyelvi változatokat tartalmazó eval készlet szolgál.

Bizonyíték. Kitöltött, jóváhagyott, dátumozott AI hatásvizsgálat, a kockázatregiszterben a belőle származó tételek hivatkozással, a változásnaplóban a kiváltó esemény.

5. ISO/IEC 42006:2025. A tanúsítók követelményei és ami ebből az auditra következik

Mit ad. A 42001 szerint tanúsító szervezetek kiegészítő követelményeit, az ISO/IEC 17021-1 fölött. Mielőtt 2025 júliusában megjelent az első kiadás, a tanúsítók a 17021-1 és a 27006-1 analógiájával dolgoztak. Az európai akkreditáló testületek együttműködése (EA) és több nemzeti akkreditáló (például SCC, ANAB) a 42006-ot kötelezővé tette vagy átállási rendet hirdetett. Ez másodlagos forrásból származik, a magyar NAH álláspontja ellenőrizendő.

Mikor kell. Tanúsító kiválasztásakor, árajánlat összevetésekor, és az audit előkészítésekor.

5.1 Mit szabályoz

• Kompetencia. Az auditcsoportnak együttesen kell értenie az AI technológiához és életciklushoz, az irányítási rendszerekhez, az AI governance-hez, a hatókörbe eső technikai tevékenységhez, a vonatkozó jogszabályokhoz és a szektorhoz. A tanúsítási döntést hozó személyeknek is megfelelő kompetencia kell.
• Auditidő. A számítás kiindulópontja az AIMS hatókörében az AI életciklusban részt vevő személyek száma, módosító tényezőkkel. Másodlagos források szerint a tényezők a hatókörbe eső szabályozási keretek, az AI rendszerek száma, a magas kockázatú vagy érzékeny felhasználás, a harmadik fél kapcsolatok, és az A mellékleten túli saját kontrollok. A kiszámított érték minimum, az eltérést dokumentálni kell (ellenőrizendő).
• Szerepek szerinti eltérés. Az auditidő a szervezet szerepétől is függ (előállító, fejlesztő vagy szolgáltató, felhasználó, több szerep). Egy fejlesztő és szolgáltató tanácsadó több szerepben van, ez növeli az időt.
• Tanúsítási dokumentumok. A tanúsítvány a hatókört és a szerepet is megnevezi.
• Hozzáférés a dokumentációhoz. A tanúsító a szervezet dokumentációjához megfelelő hozzáférést vár, a bizalmasság tiszteletben tartásával.

5.2 Auditnapok egy kis szervezetnél

Egy másodlagos forrás a 42006 A melléklet táblázatát az 1-10 fős sávra auditori napban így adja vissza. AI előállító 5, fejlesztő vagy szolgáltató 3,5, felhasználó 3,5, több szerep 6,5 nap. A következő sávban (11-15 fő) 6, 4, 4 és 8 nap. Nem ellenőrzött, hogy ezek az első tanúsítás (stage 1 és stage 2 együtt) értékei, vagy a teljes ciklusé. Ugyanezen forrás szerint az ügyféllel töltött idő nem csökkenhet a számított idő 70 százaléka alá a tervezés és a jelentésírás miatt, az újratanúsítás pedig általában az első tanúsítás idejének legalább kétharmada. A bekezdés minden számadata ellenőrizendő.

Egy egyszemélyes tanácsadónál, aki fejleszt és szolgáltat, ezek alapján nagyjából 4-7 auditori nap várható az első tanúsításra, ami távoli audittal is lehetséges (becslés). Integrált 27001 és 42001 auditnál a közös elemek (hatókör, politika, belső audit, vezetőségi átvizsgálás) miatt a két rendszer együttes ideje csökkenthető. A kombinált csökkentés mértékét a tanúsító saját szabálya és az IAF MD 11 határozza meg, a konkrét értéket a tanúsítótól érdemes megkérdezni.

5.3 Mit jelent ez a felkészülésre

• Az auditor érteni fog az LLM-hez. A politika önmagában kevés. Mélyebb kérdések várhatók a rendszerleltárról, a szerepekről, az érzékeny felhasználásokról, a kiszervezett szolgáltatásokról és a SoA indoklásáról.
• A működés nyoma kell. Kockázat és hatásvizsgálat, eval futások, monitorozási rekordok, beszállítói felülvizsgálat, incidensnapló, vezetőségi átvizsgálás. Az ISO megfelelés és audit kézikönyv alapállítása, hogy az auditor a működés nyomát keresi, itt hatványozottan érvényes.
• Mintavétel AI rendszerekből. Az auditor egy vagy több AI rendszert végig fog követni a kártyától az eval eredményen át a naplóig. Minden rendszernek ugyanazt a bizonyítékláncot kell mutatnia.
• Tanúsító kiválasztása. Ellenőrizni kell, hogy a tanúsító akkreditált-e a 42001-re (nem csak a 27001-re), melyik akkreditáló testület alatt, és a 42006 szerint működik-e. Az IAF CertSearch adatbázisa és az akkreditáló nyilvántartása mutatja.
• A 42006 nem változtat a 42001 követelményein. A szervezetnek ugyanazt kell teljesítenie, csak alaposabb ellenőrzésre számíthat.

6. ISO/IEC 23894:2023. AI kockázatkezelés

Mit ad. Útmutatót az AI sajátos kockázatainak kezeléséhez az ISO 31000:2018 szerkezetében. Megtartja a 31000 elveit, keretrendszerét és folyamatát (kontextus, kockázatazonosítás, elemzés, értékelés, kezelés, monitorozás, kommunikáció, rögzítés), és mindegyikhez AI kiegészítést ad. Mellékletei saját összefoglalásban a következők. Az A melléklet AI vonatkozású célokat, a B melléklet AI kockázatforrásokat sorol, a C melléklet pedig a kockázatkezelést az AI életciklus szakaszaihoz rendeli. Nem tanúsítható.

Viszony a 42001-hez. A 42001 a mit (legyen AI kockázatértékelés és kezelés, kritériumokkal), a 23894 a hogyan. Ugyanezt a szerepet tölti be a 27005 az információbiztonsági kockázatra a 27001 mellett. Integrált rendszerben egyetlen kockázati módszertan kezeli mindkettőt, és a kockázatregiszter kategóriája mutatja, melyik irányítási rendszerhez tartozik egy tétel.

Mikor kell. Az AIMS kockázati módszertanának megírásakor (6.1.1 kritériumok), és minden AI rendszer első kockázatértékelésekor.

6.1 Mit tesz hozzá az AI a 31000-hez

• Kontextus. Az érintettek köre tágabb (AI subjectek), a kockázat a szervezeten kívül, egyénnél és társadalomnál is jelentkezhet, és a hatásvizsgálat eredménye bemenet.
• Azonosítás. Az AI sajátos forrásai, vagyis az adat (minőség, bias, mérgezés), a modell (átláthatatlanság, hallucináció, drift), az automatizáltság, a környezet változása, a beszállítói függés.
• Elemzés. A bizonytalanság nagyobb, mert a viselkedés nem determinisztikus. Valószínűséget eval eredményből és üzemi mérésből érdemes becsülni, nem érzésből.
• Kezelés. A kezelés lehet technikai korlát (eszközjog szűkítése), emberi felügyelet, tájékoztatás, vagy a felhasználás korlátozása. Az elkerülés (a funkció nem épül meg) AI-nál gyakrabban indokolt, mint hagyományos szoftvernél.
• Monitorozás. Folyamatos, mert a kockázat a modell és az adat változásával mozog.

6.2 LLM projektben

A kockázatregiszter minden AI tételénél négy plusz mező szerepel. Az AI kockázatforrás kategória (a 42001 C melléklete vagy a 23894 B melléklete szerint), az érintett csoport (a hatásvizsgálatból), a mérési alap (eval azonosító, üzemi metrika), és az életciklus szakasz. Tipikus tételek egy ügynöknél, saját példák.

Bizonyíték. Kockázatkezelési módszertan (önálló dokumentum vagy a 27001 meglévő módszertanának AI kiegészítése), kitöltött kockázatregiszter, kezelési terv, a maradék kockázat elfogadása dátummal.

7. Architektúra és életciklus. 23053, 5338, 8183

7.1 ISO/IEC 23053:2022. ML alapú AI rendszerek keretrendszere

Mit ad. Funkcionális leírást arról, miből áll egy gépi tanulásra épülő AI rendszer. Az adat (gyűjtés, előkészítés, tanító, validációs és tesztkészlet), a modellfejlesztés (tanítás, hangolás, értékelés), a betanított modell, a hozzá tartozó eszközök, és a rendszer, amely a modellt bemenet és kimenet közé illeszti. Fogalmi szabvány, nem tanúsítható.

LLM projektben. Egy hosztolt modell API-jára (például a Claude API-ra) épülő rendszerben a tanítás a szolgáltatónál történik. A 23053 elemei ennek ellenére leképezhetők. Tanító adat helyén a few shot példák, a rendszerprompt és a RAG korpusz áll, a hangolás helyén a promptmérnöki iteráció és a paraméterek, az értékelés helyén az eval készlet. A leképezésből következik, hogy az A.7 adat kontrolljai egy promptolt rendszerre is vonatkoznak.

Amd 1. A generatív AI kiegészítés FDAmd szakaszban van (ellenőrizendő). Megjelenése után várhatóan közvetlenül leírja a foundation model, a finomhangolás és a lekérdezéskori kiegészítés (retrieval augmentation) elemeit.

Bizonyíték. Az AI rendszer kártya architektúra szakasza a 23053 komponensei szerint tagolva.

7.2 ISO/IEC 5338:2023. AI rendszer életciklus folyamatok

Mit ad. Az ISO/IEC/IEEE 12207 (szoftver) és 15288 (rendszer) életciklus folyamatait AI rendszerekre igazítja. Három csoportba sorolja a folyamatokat. Egy részük változatlanul átvehető, más részük AI sajátos módosítást kap (például a követelményelemzés, a verifikáció, az üzemeltetés), és vannak új, AI sajátos folyamatok (tudásgyűjtés, AI adatmérnökség, folyamatos validáció). Nem tanúsítható.

Mikor kell. Amikor a szervezet a 42001 A.6.1.3 szerinti fejlesztési folyamatát leírja, és ehhez elismert referenciát keres.

LLM projektben. A folyamatos validáció folyamat a legfontosabb. Időzített eval futás élesben (például hetente mintavétellel a naplóból, redakció után), modellverzió változás figyelése, és küszöbsértés esetén incidens. Az AI adatmérnökség folyamat a RAG betöltő pipeline (8. pont). A követelményelemzés AI kiegészítése, hogy a követelmény statisztikai küszöbként is megfogalmazható (a válaszok legalább adott aránya legyen helyes az eval készleten).

Bizonyíték. A fejlesztési folyamatleírás a 5338 folyamataira hivatkozva, a CI ütemezett eval futásának naplója, a tesztbizonyíték az eredményekkel.

7.3 ISO/IEC 8183:2023. Adat életciklus keretrendszer

Mit ad. Az AI rendszerben használt adat életciklusát szakaszokra bontja, az ötlettől és az üzleti követelménytől a tervezésen, beszerzésen, előkészítésen, modellépítésen, telepítésen és üzemeltetésen át a kivezetésig. A szakaszok itt használt neve nem a szabványszövegből való, a tagolás a szabványból ellenőrizendő. Ehhez a vázhoz köthetők az adatminőségi (5259) és az adatvédelmi (27701, 27091) követelmények. Nem tanúsítható.

LLM projektben. A RAG korpusz életciklusa. Ki kéri az adatot, honnan jön, mi a jogalap, hogyan darabolódik, mikor frissül, mikor és hogyan törlődik az embedding is, ha a forrásdokumentum törlődik. A kivezetés szakasz a leggyakoribb hiány. Ha az ügyfél egy dokumentumot visszavon, a vektor táblából és a gyorsítótárból is törölni kell, és a törlést naplózni.

Bizonyíték. Adatleltár az adatkezelési és DPIA dokumentumban életciklus oszloppal, törlési eljárás és naplórekord.

8. ISO/IEC 5259 sorozat. Adatminőség analitikához és gépi tanuláshoz

8.1 A részek

Az 5259-2 a 25012 hagyományos jellemzőit (például pontosság, teljesség, konzisztencia, hitelesség, aktualitás, hozzáférhetőség) ML sajátos jellemzőkkel egészíti ki. Ilyen a reprezentativitás, a kiegyensúlyozottság, a változatosság, a relevancia, az azonosíthatóság, az auditálhatóság és a hasonlóság. A lista másodlagos forrásból származik és ellenőrizendő, a hiteles jellemzőkészletet és a definíciókat a szabvány adja.

Mikor kell. Minden olyan rendszernél, ahol a kimenet minősége az adaton múlik. LLM projektben ez a RAG korpusz, az eval készlet, a few shot példák és a strukturált bemeneti adat. AI Act magas kockázatú rendszernél a 10. cikk adatgovernance követelményeinek ez a legközelebbi ISO támasza, a prEN 18284 megjelenéséig.

8.2 Gyakorlat. Adatminőség egy RAG korpuszra

Egy ügyfél belső szabályzataiból és GYIK anyagaiból épített RAG korpusz minőségi ellenőrzése, a 5259-2 jellemzőit saját mérőszámokra fordítva.

Supabase és pgvector esetén a darabtábla metaadat oszlopai (forrás azonosító, forrás verzió, betöltés ideje, tartalom hash, bérlő, jogosultsági címke) egyszerre szolgálják a származást (A.7.5), a kivezetést (8183) és a bérlőelválasztást (az AI ügynökök és vibecoding kézikönyv RAG szakasza). Az ellenőrzés CI feladatként fut minden betöltés után, és a riport dátummal a tesztbizonyíték adatminőségi szakaszába kerül.

Eval készlet minősége. Ugyanez a logika az eval készletre is vonatkozik. Egy rosszul összerakott eval készlet hamis biztonságot ad. Ellenőrizni kell, hogy a kérdések lefedik-e a valós felhasználói eloszlást, vannak-e nehéz és rosszindulatú esetek, a várt válaszokat szakértő hagyta-e jóvá, és hogy a készlet nem szivárgott-e be few shot példaként a promptba.

Bizonyíték. Adatminőségi követelmények a kártyán, mérési szkript a repóban, riport futásonként, eltérésnél helyesbítés az incidens vagy változásnaplóban.

9. A megbízhatóság családja. Bias, megbízhatóság, robusztusság, etika, átláthatóság, irányíthatóság

9.1 ISO/IEC TR 24028:2020. Megbízhatóság áttekintése

Mit ad. Áttekintést arról, mi teszi megbízhatóvá egy AI rendszert, milyen sérülékenységek és fenyegetések rontják (például adatmérgezés, ellenséges bemenet, modell lopás, hardver hiba, emberi tényező), és milyen enyhítő megközelítések léteznek (átláthatóság, irányíthatóság, adatkezelés, tesztelés). Műszaki jelentés, informatív.

LLM projektben. Fogalmi térkép a kockázatazonosításhoz. A konkrét LLM fenyegetéseket az OWASP LLM és Agentic Top 10 és a MITRE ATLAS jobban lefedi (ezekről az AI ügynökök és vibecoding kézikönyv szól). Arra viszont jó a 24028, hogy az ügyfél vezetőjének a megbízhatóság szerkezetét ISO nyelven elmagyarázzuk.

9.2 ISO/IEC TR 24027:2021 és TS 12791:2024. Bias

Mit ad a 24027. Leírja a nem kívánt bias forrásait (emberi kognitív bias, adat bias, tervezési döntésekből eredő bias), a méltányossági mérőszámok családjait, és kezelési stratégiákat az életciklus minden szakaszában. Műszaki jelentés.

Mit ad a 12791. Kezelési technikákat a nem kívánt bias csökkentésére osztályozási és regressziós ML feladatokban, az életciklus mentén. Műszaki specifikáció. Generatív feladatokra közvetlenül nem szól, de a gondolkodásmódja átvihető.

LLM projektben. Ahol az LLM osztályoz vagy pontoz (jelentkező rangsorolás, panasz súlyossági besorolás, kockázati címke), ott a 12791 közvetlenül alkalmazható. Csoportonkénti eval szükséges (nem, kor, nyelv, régió, ha jogszerűen és arányosan kezelhető), és csoportonként meg kell mérni a pozitív besorolási arányt és a hibaarányt, majd küszöböt kell rögzíteni a megengedett különbségre. Szabad szöveges generálásnál ellenpár tesztek készülnek, vagyis ugyanaz a kérdés csak egy védett tulajdonságban eltérve, a válaszok összevetésével. Magyar projektben gyakori, kevéssé észrevett bias a nyelvi változat (tájszó, nem standard helyesírás, idegen anyanyelvű fogalmazás).

Bizonyíték. Bias eval eredmény csoportonként a tesztbizonyítékban, küszöb a kártyán, eltérés a kockázatregiszterben. Személyes adat felhasználása bias méréshez külön adatvédelmi mérlegelést igényel, ennek helye az adatkezelési és DPIA dokumentum.

9.3 ISO/IEC 24029 sorozat. Neurális hálók robusztussága

Mit ad. A TR 24029-1:2021 áttekinti a robusztusság értékelésének módszereit (statisztikai, formális, empirikus). Formális módszereket a 24029-2:2023 ír le robusztussági tulajdonságok bizonyítására. Statisztikai módszereket a készülő 24029-3 ad (szakasza ellenőrizendő).

LLM projektben. Formális verifikáció egy hosztolt nagy nyelvi modellre nem kivitelezhető, a 24029-1 empirikus és statisztikai szemlélete viszont jól alkalmazható. A robusztusság eval az alábbi perturbációkból áll, mindegyikre ugyanazzal a pontozóval.

A statisztikai szemlélet szerint nem egy futás eredménye számít, hanem az arány és a szórás több futáson. Az eval riport ezért mintaszámot és konfidenciaintervallumot vagy legalább ismételt futás szórását mutat.

Bizonyíték. Robusztusság eval készlet a repóban, futási eredmény a tesztbizonyítékban, küszöb a kártyán. Az AI Act 15. cikk szerinti robusztussági követelményhez (magas kockázatnál) ez a fő bizonyíték, amíg a prEN 18229-2 nem jelenik meg.

9.4 ISO/IEC TR 24368:2022. Etikai és társadalmi szempontok

Mit ad. Áttekintést az AI etikai és társadalmi kérdéseiről, elvekről (például elszámoltathatóság, méltányosság, átláthatóság, magánszféra, emberi kontroll, környezeti felelősség), és arról, hogyan jelennek meg más szabványokban. Informatív. A gyakorlati folytatása a készülő TS 22443 (szakasza ellenőrizendő).

LLM projektben. A hatásvizsgálat (42005) társadalmi szakaszához és az AI politikához ad szempontlistát. Önálló bizonyítékot nem termel, a hatásvizsgálatban hivatkozzuk.

9.5 ISO/IEC 12792:2025. Átláthatósági taxonómia

Mit ad. Az átláthatósághoz szükséges információelemek taxonómiáját, az elemek jelentésével és azzal, melyik érdekelt félnek miért fontosak. Bármely szervezetre és AI alkalmazásra vonatkozik. A teljes szöveg fizetős, a belső szerkezetét a szerkesztéskor nem láttuk, ezért ellenőrizendő.

LLM projektben. Az AI rendszer kártya és a felhasználói tájékoztató mezőinek ellenőrzőlistája. Átláthatóság közönségenként mást jelent. A felhasználónak az kell, hogy AI-val beszél, mire jó és mire nem a rendszer, kihez forduljon. Az ügyfél üzemeltetőjének a modell, a korlátok, a naplózás és a felügyelet módja kell. Auditornak és hatóságnak a teljes műszaki dokumentáció. A 12792 alapján a kártya mezőit közönség szerint érdemes címkézni, és ebből két kivonat készül, egy felhasználói és egy üzemeltetői.

Bizonyíték. Kártya közönségcímkékkel, felhasználói tájékoztató, üzemeltetői dokumentáció. Az AI Act 13. cikk (magas kockázat) és 50. cikk (átláthatósági kötelezettség) tárgyában ez a fő ISO támasz.

9.6 ISO/IEC TS 8200:2024 és a készülő 42105. Irányíthatóság és emberi felügyelet

Mit ad a TS 8200. Elveket, jellemzőket és megközelítéseket az automatizált AI rendszerek irányíthatóságához. Lefedi az állapot megfigyelhetőségét és az állapotátmeneteket, a vezérlés átadásának folyamatát és költségét, a bizonytalanságra adott reakciót az átadás közben, és a verifikáció és validáció megközelítéseit.

Mit ad a 42105. Emberi felügyelet AI rendszerek felett, FDIS szavazáson 2026 augusztusától (ellenőrizendő). Várhatóan az AI Act 14. cikkének fő nemzetközi támasza lesz, a prEN 18229-3 mellett.

LLM projektben. Egy ügynök irányíthatósága négy kérdésre bontható.

1. Megfigyelhetőség. Látja-e az ember, mit csinál az ügynök (melyik lépésnél tart, milyen eszközt hív, milyen adattal). Napló és élő állapotjelzés.
2. Beavatkozás. Meg tudja-e állítani, vissza tudja-e vonni, át tudja-e venni. Leállító kapcsoló, megszakítható hurok, visszavonható műveletek.
3. Átadás. Mikor adja át az ügynök a döntést embernek (bizonytalanság, összeghatár, visszafordíthatatlan művelet), és milyen kontextussal. Az átadás költsége (mennyi idő, amíg az ember képbe kerül) tervezési szempont.
4. Ellenőrzés. Tesztelve van-e, hogy a leállítás és az átadás valóban működik. Eval eset arra, hogy az ügynök kér-e jóváhagyást, amikor kell.

Az AI ügynökök és vibecoding kézikönyv emberi jóváhagyási mintája ennek a megvalósítása. A TS 8200 ehhez képest abban ad többet, hogy az átadás költségét és a bizonytalanság kezelését külön tervezési elemként kezeli.

Bizonyíték. Felügyeleti szakasz a kártyán (ki, mikor, hogyan), jóváhagyást igénylő műveletek listája, eval eredmény a jóváhagyás kérésére, napló a felülbírálásokról, felülbírálási arány mint AI cél mérőszáma.

10. Minőség és tesztelés. 25059, 29119-11, 42119, 24970

10.1 ISO/IEC 25059:2023. AI rendszerek minőségi modellje

Mit ad. A 25010 termékminőségi és használati minőségi modelljét kiegészíti AI sajátos aljellemzőkkel. A rendelkezésre álló források szerint funkcionális alkalmasság alatt a funkcionális adaptivitás (a rendszer képes adatból vagy korábbi eredményből tanulni és ezt használni) és a módosított funkcionális helyesség (az AI rendszer nem minden körülmény között helyes) szerepel. Használhatóság vagy interakciós képesség alatt a felhasználói irányíthatóság és az átláthatóság, megbízhatóság alatt a robusztusság, biztonság (safety) alatt a beavatkozhatóság (intervenability) jelenik meg. Az aljellemzők számáról és helyéről a források eltérnek, ráadásul a 25010:2023 átnevezett néhány fő jellemzőt, és a 25059 felülvizsgálata DIS szakaszban van. A felsorolás tehát ellenőrizendő, a hiteles listát a szabványból kell venni.

Mikor kell. Minőségi követelmények megfogalmazásakor (A.6.2.2), és amikor az ügyfél mérhető elfogadási kritériumot kér.

10.2 Gyakorlat. Minőségi jellemzők mérése egy LLM ügynökön

Bizonyíték. Minőségi követelmények jellemzőnként a követelmény nyomonkövetési táblában, mérési eredmények a tesztbizonyítékban. Ugyanez a tábla a 42001 A.6.2.4 és az AI Act 15. cikk pontossági és robusztussági bizonyítéka is.

10.3 ISO/IEC TR 29119-11:2020 és TS 42119-2:2025. AI tesztelés

Mit ad a TR 29119-11. Bevezetést az AI alapú rendszerek tesztelésébe. A fő gondolata, hogy a nem determinisztikus viselkedés miatt a tesztorákulum probléma (mi a várt eredmény, és mikor sikeres a teszt) az AI tesztelés központi nehézsége. Technikákat sorol (metamorf tesztelés, A/B tesztelés, back to back tesztelés, ellenséges tesztelés, adat alapú tesztelés). Műszaki jelentés. Egy új TS 29119-11 előkészítés alatt van (ellenőrizendő).

Mit ad a TS 42119-2. Követelményeket és útmutatót a 29119 sorozat alkalmazására AI rendszerek tesztelésénél, kockázat alapon. Ahol a 29119 már definiál tesztgyakorlatot, ott leírja, hogyan alkalmazandó AI-ra. A 42119 sorozat a jövőbeli fő AI tesztelési család. Ezen belül a 42119-3 a V&V elemzés, a 42119-7 és -8 előkészítés alatt van (ellenőrizendő).

LLM projektben. A tesztorákulum problémára négy gyakorlati válasz létezik.

• Determinisztikus ellenőrzés, ahol lehet. Strukturált kimenet séma validálása, eszközhívás argumentumainak ellenőrzése, hivatkozott forrás létezése. Ezek hagyományos unit tesztek.
• Metamorf reláció. Ha a bemenetet egy ismert módon megváltoztatjuk, a kimenetnek egy ismert módon kell változnia vagy nem változnia (átfogalmazás, sorrendcsere, irreleváns kontextus). A 9.3 pont robusztusság evalja erre épül.
• Rubrika alapú pontozás. Emberi vagy LLM pontozó előre rögzített szempontokkal, az LLM pontozó kalibrálásával (az AI ügynökök és vibecoding kézikönyv eval szakasza szerint).
• Back to back. Új modellverzió vagy prompt összevetése az előzővel ugyanazon a készleten, a különbségek kézi átnézésével. A modellcsere változáskezelési kapuja ez.

A 29119-3 tesztdokumentációs minimuma (az ISO megfelelés és audit kézikönyv tesztelési szakaszában) AI-nál kiegészül a tesztkészlet verziójával, a modellazonosítóval, a paraméterekkel (hőmérséklet, maximális token), a futások számával és a szórással.

Bizonyíték. A tesztbizonyíték AI szakasza ezekkel a mezőkkel, CI napló, eval riport fájl.

10.4 ISO/IEC 24970. AI rendszer naplózás

Mit ad. A készülő szabvány az AI rendszerek eseménynaplózását rendezi, FDIS szavazás 2026 augusztusától (ellenőrizendő). Az AI Act 12. cikkéhez (automatikus naplózás magas kockázatnál) és a 42001 A.6.2.8 kontrollhoz kapcsolódik, a prEN 18229-1 mellett.

LLM projektben, amíg nem jelenik meg. A naplóséma mezőit saját javaslat adja. Kérés azonosító, időbélyeg, bérlő, álnevesített felhasználó, modellazonosító és paraméterek, rendszerprompt verzió hash, RAG darabazonosítók, eszközhívások argumentumokkal (redaktálva), eszköz eredmény státusza, végső kimenet hash vagy redaktált szöveg, emberi jóváhagyás vagy felülbírálás, költség, hiba. A megőrzés a GDPR adattakarékossággal és az AI Act megőrzési elvárásával együtt mérlegelendő, és a döntés a kártyára kerül.

Egy TypeScript típus a naplórekordra, Postgres vagy Supabase tárolásra szánva.

type AiCallLog = {
  requestId: string;
  timestamp: string;            // ISO 8601, UTC
  tenantId: string;
  userPseudonym: string;        // álnevesített azonosító, nem email
  model: { id: string; temperature: number; maxTokens: number };
  systemPromptHash: string;     // a rendszerprompt verziójának hash-e
  ragChunkIds: string[];
  toolCalls: Array<{
    name: string;
    argsRedacted: Record<string, unknown>;
    status: "ok" | "error" | "denied";
  }>;
  outputHash: string;           // vagy redaktált szöveg, a kártya döntése szerint
  humanReview?: { reviewer: string; decision: "approved" | "overridden" | "rejected" };
  costUsd: number;
  error?: string;
};

11. ISO/IEC 38507:2022. AI governance a vezető testület számára

Mit ad. Útmutatót a szervezet irányító testületének (igazgatóság, tulajdonos, ügyvezető) arról, milyen irányítási következményekkel jár az AI használata. Az ISO/IEC 38500 informatikai governance elveire épít (felelősség, stratégia, beszerzés, teljesítmény, megfelelés, emberi viselkedés), és ezeket AI-ra alkalmazza. Kiemeli, hogy a felelősség nem ruházható át a rendszerre, hogy a vezetésnek értenie kell az AI által hozott vagy támogatott döntések természetét, és hogy az AI használat kockázati étvágyát a vezetésnek kell rögzítenie. Nem tanúsítható.

Mikor kell. Ügyfélnél, amikor a vezetőség AI stratégiát vagy AI politikát fogad el, és tanácsadói munkában, amikor a döntéshozói felelősséget kell elmagyarázni. Saját AIMS-ben a 42001 5. klauzulájának (vezetés) tartalmi háttere. A vezetői oldal szervezeti kérdéseivel az Irányítási rendszerek és governance kézikönyv foglalkozik bővebben.

LLM projektben. Az ügyfélnek átadott ügynök átadási dokumentuma tartalmaz egy vezetői oldalt. Ezen szerepel, milyen döntéseket hoz vagy készít elő a rendszer, mi a kockázati étvágy, ki az elszámoltatható személy az ügyfélnél, és mikor kell a vezetésnek újra döntenie (modellcsere, hatókör bővítés, incidens). Saját szervezetben a vezetőségi átvizsgálás jegyzőkönyve a 38507 szempontjait követi.

Bizonyíték. Vezetői összefoglaló az átadáskor, ügyféloldali jóváhagyás, saját vezetőségi átvizsgálás.

12. Biztonság és adatvédelem. 27090, 27091, TS 22440

12.1 ISO/IEC 27090. AI biztonság

Mit ad. Útmutatót az AI rendszereket érő biztonsági fenyegetések megértéséhez, észleléséhez és kezeléséhez a teljes életciklusban, a 27001 és 27002 kiegészítéseként. Az ISO adatlap 2026 októberében az első kiadás utolsó gyártási lépéseit mutatja, vagyis a megjelenés küszöbön áll vagy éppen megtörtént (ellenőrizendő). A végleges tartalom a szerkesztéskor nem volt elérhető.

Mikor kell. Integrált 27001 és 42001 rendszerben az AI kockázatok információbiztonsági oldalához. Megjelenése után a SoA-ban és a kockázatkezelési módszertanban hivatkozható forrás lesz az AI sajátos fenyegetésekre.

LLM projektben. Addig is az AI ügynökök és vibecoding kézikönyv anyaga (OWASP LLM, Agentic és MCP Top 10, MITRE ATLAS) adja a tartalmat, a klasszikus alkalmazásbiztonsági alapokat pedig a Kiberbiztonság kézikönyv. A 27090 várhatóan azonos fenyegetéscsaládokat tárgyal (adatmérgezés, modellkivonás, ellenséges bemenet, prompt injekció, ellátási lánc), ISO nyelven. Megjelenése után a fenyegetésmodell kategóriáit össze kell vetni vele, és ahol eltér, kereszthivatkozást kell felvenni.

12.2 ISO/IEC 27091. AI adatvédelem

Mit ad. Útmutatót az AI rendszerek és ML modellek adatvédelmi kockázatainak azonosításához és kezeléséhez az életciklus mentén. FDIS vagy azt megelőző jóváhagyási szakaszban van (ellenőrizendő).

LLM projektben. A 27701 (az ISO megfelelés és audit kézikönyvben) és a GDPR DPIA AI sajátos kiegészítése lesz. Egy LLM projektben a következő tipikus témák már most kezelendők. Személyes adat a promptban és a naplóban, személyes adat a RAG korpuszban, a modellszolgáltató adatkezelése (tanításra használja-e, meddig őrzi, hol dolgozza fel), memorizált adat kinyerhetősége, érintetti jogok (törlés a korpuszból és az embeddingből), automatizált döntés a GDPR 22. cikk szerint. Az általános adatvédelmi gyakorlatot az Adatbiztonság és adatvédelem kézikönyv tárgyalja.

Bizonyíték. Az adatkezelési és DPIA dokumentum AI szakasza, a beszállítói nyilvántartás a modellszolgáltató adatkezelési feltételeivel, törlési eljárás.

12.3 ISO/IEC TS 22440. Funkcionális biztonság és AI

Mit ad. Követelményeket és példákat AI használatára biztonsági (safety) funkciókban, illetve nem AI biztonsági funkciókra AI rendszerek védelmében, az IEC 61508 típusú funkcionális biztonsági szabványokkal együtt alkalmazva. CD szakaszban, megjelenés 2027 körül várható (ellenőrizendő).

Relevancia. Egy tanácsadó, aki irodai ügynököket, RAG alkalmazásokat és automatizációkat épít, jellemzően nem fejleszt safety funkciót. Akkor válik relevánssá, ha ipari, gépipari, járműipari vagy orvostechnikai ügyfélnél az AI fizikai folyamatot befolyásol. Ilyenkor a projekt meghaladja a kis tanácsadói kört, és szakosodott funkcionális biztonsági partner kell.

13. Készülő dokumentumok, amelyek a következő egy-két évben számítanak

14. CEN-CENELEC JTC 21 és a harmonizált szabványok az AI Acthoz

14.1 Hogyan működik a megfelelési vélelem

Az AI Act 40. cikke szerint ha egy magas kockázatú AI rendszer megfelel egy harmonizált szabványnak, amelynek hivatkozása megjelent az EU Hivatalos Lapjában, vélelmezni kell, hogy megfelel a szabvány által lefedett követelményeknek. Harmonizált szabványt az európai szabványügyi szervezetek készítenek a Bizottság szabványosítási kérése alapján (M/613, a módosított kérés). A lefedett követelményeket a szabvány ZA melléklete sorolja fel, ami ott nem szerepel, arra nincs vélelem. Önkéntes a szabvány alkalmazása, más úton is bizonyítható a megfelelés, de akkor a teljes bizonyítási teher a szolgáltatóé.

A Digital Omnibus (EU 2026/1744) a magas kockázatú kötelezettségek alkalmazását 2027. december 2-ra (III. melléklet) és 2028. augusztus 2-ra (I. melléklet) tolta (részletesen az AI ügynökök és vibecoding kézikönyv szabályozási szakaszában). Ezek a határidők a szabványok elkészültétől függetlenül rögzültek.

14.2 EN 18286:2026. Az első harmonizált AI szabvány

Státusz. A nyilvános véleményezés 2025. október 30-án indult, a CEN-CENELEC 2026. július 12-én hagyta jóvá. Hivatkozását a Bizottság (EU) 2026/2274 végrehajtási határozata tette közzé, amely a Hivatalos Lapban 2026. október 14-én jelent meg, és a közzététel napján hatályba lépett. Több független forrás (EUR-Lex kivonat, Nemko, JTC 21) egybehangzóan közli, az EUR-Lex teljes szövege a szerkesztéskor nem volt megnyitható, ezért ellenőrizendő.

Mit ad. Minőségirányítási rendszer követelményeit AI Act szabályozási célokra, a magas kockázatú AI rendszerek szolgáltatói számára. A ZA melléklet a 17. cikk (1) a)-m) pontjaihoz és a 11. cikk (1) bekezdés első mondatához (műszaki dokumentáció) rendeli a klauzulákat, a 17. cikk (2), (3) és (4) bekezdése nem lefedett. Szerkezete a 4-10. klauzulás rendet követi, de a minőség fogalma itt a szabályozási megfelelés, beleértve az egészség, a biztonság és az alapvető jogok védelmét. Klauzula megfeleltetést a B melléklet a 9001-gyel, a C melléklet az EN ISO/IEC 42001:2026-tal ad. Van szabályozási megfelelési stratégia klauzulája, amelynek nincs párja a 9001-ben és a 42001-ben. A forgalomba hozatal utáni monitorozást és az incidenseket is kezeli.

Kinek kell. Magas kockázatú AI rendszer szolgáltatójának (AI Act provider). Egy tanácsadónak akkor, ha saját nevén hoz forgalomba ilyen rendszert, vagy ha az ügyfél (mint provider) minőségirányítási rendszerét kell támogatnia. Átláthatósági kötelezettség alá eső chatbothoz vagy minimális kockázatú belső eszközhöz nem kell.

14.3 Miért nem ad vélelmet a 42001

• Nincs a Hivatalos Lapban. Az ISO/IEC 42001 nemzetközi szabvány, a CEN 2026-ban EN ISO/IEC 42001:2026 néven változatlanul átvette, de ZA mellékletet nem kapott, és a hivatkozása nem jelent meg harmonizált szabványként.
• Más a tárgya. A 42001 a szervezet AI irányítási rendszerét szabályozza, a szervezet által meghatározott célok és kockázati kritériumok szerint. Az AI Act a termékre (a rendszerre) és annak hatására fogalmaz meg kötelező követelményeket, az egészség, a biztonság és az alapvető jogok védelmében.
• A kockázatfogalom eltér. A 42001 kockázata a szervezet céljaira vonatkozó bizonytalanság hatása, kiegészítve a hatásvizsgálattal. Az AI Act 9. cikk kockázata az egyénekre és a társadalomra jelentett kockázat, a szervezet érdekétől függetlenül. A prEN 18228 ezt termékbiztonsági szemlélettel kezeli.
• A műszaki követelmények hiányoznak. A 42001 nem ír elő konkrét naplózási, pontossági, robusztussági, kiberbiztonsági vagy emberi felügyeleti szintet. Kontrollcélt ad, a szintet a szervezet választja.
• Hiányzó elemek. A szabályozási megfelelési stratégia, a forgalomba hozatal utáni monitorozás AI Act szerinti tartalma és a súlyos incidens jelentés hatósági oldala nem része a 42001-nek.

Gyakorlati következtetés. A 42001 tanúsítvány hasznos keret és erős bizonyíték a beszállítói minősítésben, és jó alap az EN 18286 szerinti rendszerhez, de egy magas kockázatú rendszer AI Act megfelelőségét önmagában nem bizonyítja. Javasolt út a meglévő 42001 AIMS kiterjesztése az EN 18286 többletelemeivel, párhuzamos rendszer építése helyett.

14.4 A többi JTC 21 projekt

A dátumok célok, nem kötelezettségek. Hivatalos Lap hivatkozás a Bizottság értékelése után következik, ezért a teljes készlet vélelmet adó állapota 2027 közepénél korábban nem várható. Az aktuális állapotot a CEN-CENELEC adatbázisában vagy a jtc21.eu oldalon kell nézni.

Fejlesztői következmény. Egy 2027 decemberében élesedő magas kockázatú rendszer fejlesztése most zajlik, amikor a szabványok nagy része még tervezet. A tervezetek a nemzeti szabványügyi testületeken keresztül elérhetők (az MSZT véleményezési rendje szerint), és érdemes hozzájuk igazítani a dokumentációt, tudva, hogy a végleges szöveg eltérhet.

15. Leképezés. AI Act cikkek, ISO szabványok, NIST AI RMF

A NIST AI RMF négy funkciója (Govern, Map, Measure, Manage) az AI ügynökök és vibecoding kézikönyv szabályozási szakaszában szerepel. Az alábbi tábla tájékozódásra szolgál, jogi megfeleltetésnek nem minősül.

A NIST oszlop a funkciót és ahol egyértelmű, a kategória számát adja. Hivatalos átjárót (crosswalk) is közzétett a NIST az AI RMF és a 42001 között, ennek aktuális változata ellenőrizendő. Amerikai ügyfélnél vagy amerikai anyavállalatú ügyfélnél ez a leképezés a közös nyelv.

16. Bizonyíték és dokumentum térkép

A dokumentumok két szinten élnek. Projekt szinten AI rendszerenként, a rendszer repójában (például egy külön compliance mappában), szervezeti szinten egyszer, a szervezet saját irányítási rendszerében. Ha egy projektben valamelyik még hiányzik, a megfelelő szakasz szempontjai alapján vázat érdemes készíteni, és a hiányt jelölni.

17. Egy egyszemélyes AI tanácsadó realisztikus útja a 42001 tanúsításig

A becslések tapasztalati nagyságrendek, a tényleges idő és költség a tanúsító ajánlatától, a hatókörtől és a kiinduló állapottól függ. Tanúsítást senki nem garantálhat előre.

17.1 Megéri-e, és melyik változat

Önálló 42001. Akkor érdemes, ha az ügyfelek kifejezetten AI irányítási bizonyítékot kérnek (nagyvállalati beszállítói minősítés, szabályozott szektor), és a 27001 nincs napirenden. Kisebb a dokumentáció, de az információbiztonsági kérdésekre (titokkezelés, hozzáférés, mentés) az auditor így is rákérdez, mert az A.4, A.6 és A.10 kontrollok érintik.

Integrált 27001 és 42001. A közös harmonizált szerkezet miatt a hatókör, a politikai keret, a kockázati módszertan, a dokumentumkezelés, a belső audit, a vezetőségi átvizsgálás és a nem megfelelőség kezelés egy rendszerben fut. Egy AI fejlesztőnél, aki ügyféladatot kezel, az ügyfelek többsége a 27001-et kéri először, ezért az integrált út általában jobb ár és érték arányú. Meglévő 27001 esetén a 42001 kiterjesztésként épül rá.

Előbb nem tanúsított megfelelés. Ha egyik ügyfél sem kér tanúsítványt, a 42001 szerint működő, de nem tanúsított rendszer is értékes, és az ajánlatokban bizonyítékcsomagként mutatható. Ilyenkor nem szabad azt állítani, hogy a szervezet 42001 megfelelő. Annyi mondható, hogy a 42001 szerint épített irányítási rendszert működtet.

17.2 Hatókör megfogalmazása

A hatókör a 4.3 szerint rögzíti a tevékenységeket, a helyszínt, az AI rendszereket és a szerepeket. Minta, saját megfogalmazásban, egy kitalált egyéni vállalkozóra.

Az AI irányítási rendszer hatóköre a Minta Tanácsadó egyéni vállalkozó ügyfelek számára végzett tevékenysége. Ide tartozik a nagy nyelvi modellekre épülő AI ügynökök, RAG alkalmazások, MCP szerverek és automatizációk tervezése, fejlesztése, tesztelése, átadása és üzemeltetési támogatása, valamint a saját belső AI eszközhasználat. A szervezet AI producer (AI developer) és AI provider (AI product or service provider) szerepben jár el az ISO/IEC 22989 szerint, a saját belső eszközhasználatnál AI customer (AI user) szerepben. Az alapmodelleket harmadik fél szolgáltatók biztosítják, ezek az A.10 szerint beszállítóként kezeltek. A hatókör nem terjed ki alapmodellek tanítására és magas kockázatú AI rendszerek (AI Act III. melléklet) saját nevén történő forgalomba hozatalára.

A kizárásnak valósnak kell lennie. Ha a szervezet mégis épít HR szűrőt, a hatókört és a kockázatértékelést módosítani kell. Az auditor a hatókört az ajánlatokkal és a szerződésekkel veti össze.

17.3 Fázisok

Reális teljes átfutás a döntéstől a tanúsítványig 6-12 hónap, ha a fejlesztési gyakorlat (PR review, CI, eval) már létezik. Az auditori napok nagyságrendjét az 5.2 pont adja.

17.4 Egyszemélyes szervezet sajátos kérdései

• Függetlenség. A belső audit nem auditálhatja a saját munkát. Külső belső auditor megbízása vagy kölcsönös audit egy másik tanúsított tanácsadóval a szokásos megoldás.
• Feladatkör elkülönítés. Ahol egy ember fejleszt és jóváhagy, a kompenzáló kontroll az időbeli elkülönítés és a nyom. A jóváhagyás külön PR review lépés, ellenőrzőlistával, másnapi átnézéssel, vagy az ügyfél bevonásával.
• Helyettesítés. Betegség vagy kiesés esetén ki állítja le az ügyfélnél futó ügynököt. Az ügyféloldali leállító kapcsoló és a dokumentált átadás a válasz.
• Arányosság. A dokumentáció legyen kicsi és igaz. Az auditor egy egyszemélyes szervezettől nem vár nagyvállalati eljárásrendet, de minden állításra bizonyítékot vár.

17.5 Minimum dokumentáció

Szervezeti szint.

1. Hatókör (a 17.2 pont szerint)
2. AI politika szerepekkel, felelősségekkel, használati szabállyal
3. Jogi és egyéb követelmények nyilvántartása
4. AI kockázatkezelési módszertan és kritériumok (a 23894 szerint)
5. AI kockázatregiszter és kezelési terv
6. Hatásvizsgálati folyamat és rendszerenkénti hatásvizsgálatok
7. Statement of Applicability a 38 kontrollra (a SoA AI szakasza)
8. AI célok mérőszámmal
9. AI rendszerleltár
10. Kompetencia és képzési bizonyítékok
11. Beszállítói nyilvántartás és értékelés
12. Dokumentumkezelési szabály (verzió, jóváhagyás, megőrzés)
13. Belső audit program, terv és jelentés
14. Vezetőségi átvizsgálás jegyzőkönyve
15. Nem megfelelőség és helyesbítő intézkedés napló, incidensnapló

Projekt szint, AI rendszerenként.

1. AI rendszer kártya
2. AI hatásvizsgálat vagy hivatkozás a szervezeti példányra
3. Adatkezelési és DPIA dokumentum, ha személyes adat van
4. Tesztbizonyíték eval, robusztusság, bias és adatminőségi eredménnyel
5. A kockázatregiszter projekt tételei
6. Release checklist AI kapuval
7. Változásnapló modell, prompt, eszköz és adatforrás változásokkal

Integrált 27001 rendszernél ehhez jönnek az ISO megfelelés és audit kézikönyvben felsorolt ISMS dokumentumok, de a közös elemek (hatókör, módszertan, audit, átvizsgálás) egy példányban léteznek.

18. A gyakorlatban

Az alábbi szabályok minden AI funkció (LLM hívás, ügynök, RAG, MCP szerver, automatizáció AI lépéssel) fejlesztésénél érvényesek, az AI ügynökök és vibecoding kézikönyv záró szabályai mellett. Akkor is, ha a kódot vagy a dokumentációt részben AI asszisztens írja, a felelősség és a jóváhagyás a csapaté marad.

1. Kártya az első commit előtt. Új AI funkciónál a csapat létrehozza vagy frissíti az AI rendszer kártyát. Kitölti a 22989 szerinti szerepet, az AI Act szerinti szerepet és kategóriát indoklással (javaslatként, nem jogi minősítésként), a modellazonosítót, az eszközlistát és a jóváhagyást igénylő műveleteket.
2. Hatásvizsgálat kiváltók szerint. Ha a változás a 4.1 lista valamelyik kiváltóját érinti (új modell, írási jogú eszköz, új adatforrás, új felhasználói kör, új cél), a változtatás mellé a hatásvizsgálat frissítése is bekerül, a változott szakasz vázlatával. A jóváhagyás emberi döntés.
3. Kockázat tétel AI mezőkkel. Minden új AI kockázat a kockázatregiszterbe kerül forráskategóriával, érintett csoporttal, mérési alappal és életciklus szakasszal (6.2 pont).
4. Eval nélkül nincs AI release. Funkcionális helyesség, robusztusság (a 9.3 pont perturbációi közül legalább átfogalmazás, ellenséges bemenet, hiányzó adat), és ahol osztályozás vagy pontozás van, csoportonkénti bias eval. Az eredmény a tesztbizonyítékba kerül modellazonosítóval, paraméterekkel, futásszámmal, szórással és dátummal.
5. Minőségi küszöb előre. A 25059 jellemzői közül a funkcióra relevánsakat a küszöbbel együtt még a fejlesztés előtt felírjuk a követelmény nyomonkövetési táblába, nem az eredmény ismeretében.
6. RAG korpusz adatminőség. Minden betöltő pipeline származási metaadatot ír (forrás, verzió, idő, hash, bérlő, jogosultság), és a 8.2 tábla mérőszámaiból legalább a teljességet, aktualitást, egyediséget, hozzáférési helyességet és PII ellenőrzést futtatja CI-ban. A törlés az embeddinget és a gyorsítótárat is eléri.
7. Naplózás tervezetten. Az AI hívás naplója a 10.4 pont mezőit tartalmazza redakcióval, a megőrzési idő döntése a kártyára kerül. Teljes prompt vagy kimenet naplózása személyes adattal csak indokolt és dokumentált esetben történik.
8. Irányíthatóság beépítve. Minden ügynöknek van leállítási módja, lépés és költségkorlátja, és visszafordíthatatlan műveletnél emberi jóváhagyása (a TS 8200 négy kérdése). Az eval tartalmaz esetet arra, hogy az ügynök jóváhagyást kér, amikor kell.
9. Átláthatóság közönségenként. Felhasználói felületen AI jelzés (AI Act 50. cikk), forráshivatkozás RAG válasznál, korlátok közlése. Az üzemeltetői dokumentáció a kártyából készülő kivonat.
10. Modellcsere változáskezelés. Modellazonosító vagy rendszerprompt változásnál back to back eval fut az előző verzióval, az eredmény a kártyára kerül, a jóváhagyás a PR-ben történik, a változásnaplóba bejegyzés kerül, érdemi viselkedésváltozásnál pedig a hatásvizsgálat is frissül.
11. Beszállító minden új AI szolgáltatásnál. Új modell, embedding szolgáltató vagy MCP szerver a beszállítói nyilvántartásba kerül adatkezelési feltétellel, régióval, megőrzéssel, kivezetési ütemtervvel (A.10.3).
12. Státusz ellenőrzése hivatkozás előtt. Ajánlatban, dokumentumban vagy ügyfélnek szóló szövegben egy szabványra csak az iso.org vagy a CEN-CENELEC aktuális adatlapjának ellenőrzése után hivatkozunk, vagy jelezzük, hogy az ellenőrzés elmaradt. Nem létező számra (42002, 42004, a 17847 önálló kiadványként) nem hivatkozunk.
13. Megfelelési állítások fegyelme. Rendszerről vagy szervezetről nem írjuk, hogy ISO megfelelő, AI Act megfelelő vagy tanúsított, ha ezt tanúsítvány vagy jogi vélemény nem támasztja alá. Tanúsítatlan esetben a megfogalmazás az, hogy a 42001 szerint épített gyakorlatot követ. Harmonizált szabványnál vélelmet csak a ZA mellékletben lefedett követelményekre és csak OJ hivatkozás után említünk.
14. Bizonyítékot nem találunk ki. Eval eredmény, jóváhagyás, audit dátum, felülvizsgálat csak akkor kerül a dokumentumba, ha megtörtént, egyébként a mező kitöltetlenként jelölve marad. AI asszisztenssel készülő dokumentációnál ez a legkönnyebben megsérülő szabály, mert a modell hihető, de kitalált adatot is szívesen ír.
15. Magas kockázat gyanúja. HR, oktatás, hitelbírálat, alapvető szolgáltatás, biometria, kritikus infrastruktúra esetén a csapat jelzi a III. melléklet szerinti magas kockázat lehetőségét, a jogászi minősítés szükségességét és az EN 18286, valamint a JTC 21 tervezetek szerinti dokumentációs igényt. A fejlesztés a megrendelő döntéséig nem halad tovább.
16. Szabványszöveget nem másolunk. Kontrollt, követelményt saját szavakkal foglalunk össze, és megnevezzük a hiteles szöveg forrását (a megvásárolt szabványt).

19. Ellenőrizetlen vagy bizonytalan adatok

• A 42001 módosításának hiánya egy másodlagos forráson (GAICC, ISO open data alapján, 2026. október 5-i állapot) nyugszik.
• A 42006 auditidő táblázata (5, 3,5, 3,5 és 6,5 nap az 1-10 fős sávban), a 70 százalékos és a kétharmados szabály másodlagos forrásból származik, a szabvány A mellékletét a szerkesztéskor nem láttuk.
• A magyar akkreditáló (NAH) 42006 átállási rendje és a 42001-re akkreditált magyar tanúsítók listája nincs ellenőrizve.
• A 27090 megjelenésének napja, valamint a 27091, a 24029-3, a 22989 Amd 1, a 23053 Amd 1, a 24970, a 42105, a TS 25568, a TS 22443 és a 42119-3 szakasza ellentmondó vagy másodlagos forrásból való.
• Az EN 18286 OJ hivatkozása (2026/2274 határozat, 2026. október 14.) több egybehangzó forrásból származik, de az EUR-Lex teljes szövege nem volt megnyitható.
• A JTC 21 többi projektjének várható dátumai egy 2026. szeptember végi tanúsítói összefoglalóból valók.
• A 8183 életciklus szakaszainak neve, az 5259-2 ML sajátos jellemzőinek listája és a 25059 aljellemzőinek száma és helye másodlagos forrásból és szakmai tapasztalatból származik.
• A 12792 belső szerkezete nem ismert a szerkesztők előtt.
• A 22989 ingyenes elérhetősége (ISO Publicly Available Standards) és a NIST AI RMF és 42001 crosswalk aktuális változata nincs ellenőrizve.
• Az időigények és auditnapok a tanúsítási útnál becslések.

Források

• ISO katalógus adatlapok (iso.org/standard) a 42001, 42005, 42006, 42007, 42003, 12792, TS 8200, TS 42119-2, 24029-2, 24029-3, 25059, 27090, 27091 és TS 22440 számokra.
• Nemzeti adatbázisok, SCC (scc-ccn.ca), EVS (evs.ee), DIN, ISS a 5259 sorozat, a 42005, a 42006 és a 27091 adataira.
• SCC átállási közlemény a 42006:2025-ről.
• GAICC összefoglaló az ISO/IEC 42000 sorozat 2026-os állapotáról (másodlagos).
• Bright Defense és Sensiba cikkek a 42006 auditidejéről (másodlagos).
• EUR-Lex kivonat a (EU) 2026/2274 végrehajtási határozatról, Nemko, Intertek, Modulos dokumentáció és CEN-CENELEC hírlevél az EN 18286-ról.
• JTC 21 (jtc21.eu), iTeh adatlapok a prEN 18228 és prEN 18282 projektekre.
• Az AI Actra, a Digital Omnibusra és a NIST AI RMF-re vonatkozó források az AI ügynökök és vibecoding és az ISO megfelelés és audit kézikönyv forrásjegyzékében.

Állapot 2026 októberében. A szöveg szakmai összefoglaló, nem jogi tanácsadás, a szabványok és jogszabályok aktuális szövegét a kiadótól érdemes ellenőrizni.