Egy belső audit akkor válik igazán próbára tett szakmai helyzetté, amikor nem elég megkérdezni, hogy „van-e szabályzat”. AI-rendszereknél azt is látni kell, hogy a szabályok hogyan jelennek meg a tényleges használatban, a döntési gyakorlatban, a naplókban, a tesztekben, az incidensekben és a felelősségi nyomvonalban.
Az ISO/IEC 42001 alapú AI irányítási rendszerben a bizonyítékgyűjtés nem puszta dokumentumellenőrzés. Az auditor feladata annak megállapítása, hogy a szervezet képes-e bizonyítani az AI-kockázatok azonosítását, kezelését, kontrollálását és fejlesztését. Az ISO/IEC 42001 az AI irányítási rendszer létrehozására, működtetésére, fenntartására és folyamatos fejlesztésére ad követelményrendszert, ezért az auditbizonyítékoknak is ezt a működő rendszerlogikát kell láthatóvá tenniük (International Organization for Standardization, 2023a).
Az AI-audit fő bizonyítéktípusai
Az AI-rendszerek auditálásakor a bizonyítékok több rétegből állnak. Vannak formális dokumentumok, például szabályzatok, kockázatértékelések, hatáselemzések és modellleírások. Vannak működési rekordok, például tesztjegyzőkönyvek, jóváhagyások, naplók, incidensjegyek és változásnaplók. Emellett vannak interjúk, megfigyelések és működési minták is, amelyek azt mutatják meg, hogy a dokumentált folyamat ténylegesen hogyan működik.
Egy AIMS belső auditja nem támaszkodhat kizárólag egyetlen bizonyítéktípusra. A szabályzat megmutatja, mit kellene tenni, de nem bizonyítja, hogy a gyakorlatban meg is történik. A napló megmutathat egy eseményt, de önmagában nem magyarázza meg a döntési kontextust. Egy interjú segíthet megérteni a folyamatot, de önmagában ritkán elegendő. Ilyenkor a bizonyíték ereje az összevethetőségből származik, mert több forrás együtt ad megbízható képet.
Az auditbizonyítékok egyik első csoportját a dokumentált irányítási elemek adják. Ide tartozik az AI-politika, az AI-használati esetek nyilvántartása, a kockázatértékelési módszertan, a hatáselemzési sablon, a beszállítói értékelés, az adatkezelési szabály, a modellváltozás-kezelési eljárás és az incidenskezelési rend. Ezek azt mutatják meg, hogy a szervezet milyen keretet hozott létre az AI irányítására.
A második bizonyítéktípus a konkrét használati esethez kapcsolódó dokumentáció. Egy AI-alapú panaszkezelő rendszer auditjánál például nem elég az általános AI-szabályzatot elkérni. Szükséges lehet a rendszer célleírása, az adatforrás-dokumentáció, a modell- vagy szolgáltatásleírás, a validálási eredmény, az élesítési jóváhagyás, a felhasználói útmutató és a monitoringriport. Itt az általános szabály csak háttér, a konkrét rendszer bizonyítéka mutatja meg a tényleges megfelelést.
A harmadik bizonyítéktípus a rendszeradat és a napló. AI-környezetben a naplózás különösen fontos, mert a döntési és működési események gyakran nem rekonstruálhatók pusztán utólagos elmondásból. Napló lehet például a hozzáférési log, a modellverzió, a kimeneti esemény, a felhasználói beavatkozás, a riasztás, a hibajegy vagy a szolgáltatói változásértesítés. Az EU AI Act magas kockázatú AI-rendszerek esetében külön is hangsúlyozza a naplózás, műszaki dokumentáció és átláthatóság jelentőségét, ami auditálási szempontból is fontos hivatkozási keretet ad (European Parliament & Council of the European Union, 2024).
A negyedik bizonyítéktípus az interjú. Az auditor interjút készíthet az AI-rendszer üzleti tulajdonosával, fejlesztőjével, felhasználójával, adatvédelmi felelősével, információbiztonsági szakértőjével, beszállítói kapcsolattartójával vagy incidenskezelési felelősével. Az interjú célja nem az, hogy a beszélgetőpartner „bizonyítsa” a megfelelést, hanem hogy az auditor megértse a folyamatot, az eltéréseket és a tényleges döntési helyzeteket. Ebben a szerepben az interjú útvonalat nyit a bizonyítékhoz, de nem helyettesíti a visszakövethető rekordot.
Az ötödik bizonyítéktípus a működési minta. Ez lehet egy lezárt panaszkezelési ügy, egy modellváltozás, egy beszállítói értékelés, egy incidens, egy hozzáférésigénylés vagy egy felhasználói jóváhagyási folyamat mintája. A mintavétel megmutatja, hogy a folyamat nemcsak elvileg létezik, hanem konkrét esetekben is következetesen működik-e. Az ISO 19011 menedzsmentrendszer-auditokra vonatkozó útmutatása is bizonyítékalapú megközelítést alkalmaz, amelyben az audit megállapításai ellenőrizhető információkra épülnek (International Organization for Standardization, 2018).
A bizonyítékok csoportosítása akkor hasznos, ha segít az auditornak teljes képet alkotni. Egy AI-kontroll működését például többféle bizonyíték támaszthatja alá:
szabályzat vagy eljárásrend: mi az elvárt működés;
jóváhagyási rekord: ki döntött és mikor;
napló vagy rendszeradat: mi történt ténylegesen;
interjú: hogyan értelmezik a szereplők a folyamatot;
működési minta: következetesen alkalmazzák-e a kontrollt;
incidens- vagy panaszadat: mi történik eltérés esetén.
Ez a felosztás különösen fontos AI-rendszereknél, mert a kockázat gyakran nem egyetlen dokumentumban jelenik meg. Az adatforrás, a modellműködés, az emberi felügyelet, a beszállítói függőség és a felhasználói döntés együtt alkotja a kontrollkörnyezetet. Emiatt az AI-audit több bizonyíték nyelvén beszél, és az auditor feladata ezek összekapcsolása.
A bizonyítékok minősége ugyanakkor nem azonos a mennyiségükkel. Sok dokumentum is lehet gyenge bizonyíték, ha elavult, nem kapcsolódik a vizsgált rendszerhez, vagy nem mutat tényleges működést. Kevés, de pontos és visszakövethető bizonyíték többet érhet, mint egy nagy dokumentumcsomag. Az auditor ezért nem dokumentumtömeget keres, hanem releváns, aktuális és elegendő bizonyítékot.
A dokumentált és tényleges működés összevetése
Az AIMS belső auditjának egyik legfontosabb feladata annak vizsgálata, hogy a dokumentált működés és a tényleges működés megegyezik-e. Egy szabályzat előírhatja, hogy minden új AI-használati eset előtt kockázatértékelést kell készíteni, de az auditor számára az a kérdés, hogy ez megtörtént-e a konkrét rendszereknél is. Ebben az összevetésben a papíron meglévő kontroll még nem működő kontroll, csak ellenőrzési kiindulópont.
A dokumentált működés azt mutatja meg, hogyan kellene működnie a rendszernek. Ide tartoznak az eljárások, felelősségi mátrixok, képzési anyagok, kontrollleírások, tesztelési követelmények és jóváhagyási szabályok. Ezek nélkül az audit nehezen tudná meghatározni a vizsgálat mércéjét. A tényleges működés azonban azt mutatja meg, hogy a szervezet a valós döntési helyzetekben követi-e ezeket a szabályokat.
A két szint közötti eltérés többféle lehet. Előfordulhat, hogy a dokumentum túl általános, ezért a gyakorlatban nem ad elég útmutatást. Előfordulhat, hogy a szabály jó, de a felhasználók nem ismerik. Az is gyakori, hogy a folyamat működik, de nincs róla megfelelő bizonyíték. AI-környezetben mindhárom eset auditkockázatot jelent, mert a bizonyítatlan működés auditálási szempontból gyenge működés, még akkor is, ha a munkatársak jóhiszeműen járnak el.
Egy AI-alapú panaszkezelő rendszer példája jól mutatja ezt. A dokumentáció szerint a rendszer csak javaslatot tehet panaszok kategorizálására, végső döntést ember hoz. Az auditor azonban mintát kérhet lezárt ügyekből, hogy látható-e az emberi felülvizsgálat nyoma. Ha a rendszerjavaslat automatikusan kerül elfogadásra, vagy a felhasználók nem rögzítik az eltéréseket, akkor a dokumentált emberi felügyelet nem bizonyítható tényleges kontrollként.
A dokumentált és tényleges működés összevetése az adatkezelésnél is alapvető. Egy szervezet rögzítheti, hogy az AI-rendszer csak meghatározott panaszadatokat használ, de az audit során ellenőrizni kell, hogy a tényleges adatfolyam is ezt tükrözi-e. Szükséges lehet adatmező-lista, hozzáférési lista, adatmegőrzési szabály, törlési rekord és rendszerkapcsolati térkép. A „Datasheets for Datasets” megközelítés éppen az adatállományok motivációjának, összetételének, gyűjtési folyamatának és javasolt használatának dokumentálását emeli ki, ami AI-auditban is értékes adatbizonyítéki szemléletet ad (Gebru et al., 2021).
A tényleges működés vizsgálata nem jelenti azt, hogy az auditor minden műveletet újra végrehajt. Ehelyett mintát vesz, rekonstruál, összevet és következtet. Megnézi, hogy egy konkrét ügy hogyan indult, milyen adatokat használt, milyen AI-kimenet született, ki ellenőrizte, volt-e eltérés, és hogyan zárult a folyamat. Ilyenkor a működési minta a folyamat valóságtesztje, mert megmutatja, hogy a szabályok hogyan élnek a napi munkában.
Az interjúk különösen hasznosak az eltérések értelmezésére. Ha a dokumentáció szerint minden panaszkezelő munkatárs képzést kapott az AI-eszköz korlátairól, az auditor megkérdezheti, hogyan ismerik fel a téves javaslatot, mikor kell felülírni a kimenetet, és hova kell fordulni rendellenesség esetén. Ha a válaszok bizonytalanok vagy eltérőek, akkor a képzési rekord önmagában nem elegendő. Ebben az esetben a tudatosság nem azonos a képzési jelenléttel, és az auditnak ezt a különbséget is látnia kell.
A dokumentált és tényleges működés összevetése a beszállítói AI-szolgáltatásoknál különösen nehéz lehet. A szervezet sokszor nem lát bele teljesen a modell működésébe, mégis felelős a szolgáltatás használatának irányításáért. Ilyenkor a bizonyíték lehet szolgáltatói dokumentáció, adatfeldolgozási megállapodás, biztonsági tanúsítvány, modellváltozás-értesítés, szolgáltatási napló, auditriport vagy szerződéses garancia. Az auditor feladata annak megállapítása, hogy a külső bizonyíték elégséges-e a belső kockázat kezeléséhez.
A dokumentált és tényleges működés közötti eltérés nem mindig nemmegfelelőség. Lehet fejlesztési lehetőség is, ha a gyakorlat érettebb, mint a dokumentáció, de nincs megfelelően rögzítve. Például a csapat ténylegesen ellenőrzi az AI-kimeneteket, de a folyamatban nincs leírva, milyen esetben kell felülvizsgálatot dokumentálni. Ilyenkor a jó gyakorlatot is dokumentálhatóvá kell tenni, különben később személyfüggő és nehezen fenntartható marad.
Az audit célja tehát nem az, hogy minden eltérést formális hibának minősítsen. A cél annak megértése, hogy az AIMS mennyire bizonyítható, mennyire következetes és mennyire fejleszthető. A dokumentált működés adja a keretet, a tényleges működés adja a valóságot, az audit pedig a kettő közötti kapcsolatot értékeli.
Interjú, mintavétel és naplóvizsgálat szerepe
Az AI-rendszerek belső auditja három különösen fontos bizonyítékgyűjtési technikára támaszkodik: interjúra, mintavételre és naplóvizsgálatra. Ezek nem egymás helyettesítői, hanem egymást erősítő módszerek. Az interjú megmutatja az értelmezést és a felelősségi gyakorlatot, a mintavétel konkrét eseteken teszteli a folyamatot, a naplóvizsgálat pedig időrendi és rendszertechnikai nyomot ad. Együtt a három módszer a működés három nézetét adja, ezért AI-auditban különösen hasznos a kombinációjuk.
Az interjú akkor jó, ha célzott, szerepköralapú és bizonyítékhoz kötött. Más kérdéseket kell feltenni az üzleti tulajdonosnak, a napi felhasználónak, a fejlesztőnek, az adatvédelmi szakértőnek és az információbiztonsági felelősnek. Az üzleti tulajdonosnál a cél, kockázat és jóváhagyás a fő téma. A felhasználónál a kimenetek értelmezése, felülírása és visszajelzése. A fejlesztőnél vagy szolgáltatói kapcsolattartónál a modellváltozás, tesztelés és technikai kontroll.
Az interjúk során kerülni kell az olyan kérdéseket, amelyekre csak formális igen-nem válasz adható. A „tudja-e, hogy kell használni a rendszert?” kérdés helyett jobb azt kérni: mutassa be, mit tesz, ha az AI javaslata ellentmond a saját szakmai megítélésének. A „van-e incidensfolyamat?” kérdés helyett hasznosabb egy konkrét korábbi rendellenességet végigkövetni. Ilyenkor az interjú nem nyilatkozatot gyűjt, hanem működési megértést épít.
A mintavétel az audit egyik legerősebb eszköze. AI-rendszereknél mintát lehet venni használati esetekből, döntési eseményekből, panaszkezelési ügyekből, hozzáférés-engedélyezésekből, modellváltozásokból, hibajegyekből, incidensekből vagy beszállítói értékelésekből. A minta kiválasztásának kockázatalapúnak kell lennie. Nem mindegy, hogy az auditor véletlenszerűen választ három alacsony jelentőségű ügyet, vagy célzottan vizsgál magasabb kockázatú, határértékhez közeli, panasszal érintett vagy változás utáni eseteket.
A mintavétel mélységét a kockázathoz és az auditcélhoz kell igazítani. Egy alacsony kockázatú, belső tudáskereső eszköznél elegendő lehet néhány hozzáférési és felhasználói minta. Egy ügyfélre ható panaszkezelő rendszerben viszont indokolt lehet több lezárt ügy, eltérő panasztípusok, felülírt AI-javaslatok és hibás kimenetek vizsgálata. Ebben az értelemben a minta nem kényelmi választás, hanem a kockázati fókusz gyakorlati megvalósítása.
A naplóvizsgálat az AI-auditban azért különösen fontos, mert sok esemény csak rendszeradatból rekonstruálható. A napló megmutathatja, ki használta a rendszert, mikor történt kimenetgenerálás, milyen verzió futott, volt-e felülírás, keletkezett-e riasztás, történt-e jogosulatlan hozzáférés, vagy mikor frissült a modell. A naplók nélkül az auditor sokszor csak interjúkra és utólagos dokumentumokra támaszkodna, ami gyengíti a bizonyíték megbízhatóságát.
A napló azonban önmagában sem mindig elég. Ha egy AI-alapú panaszkezelő rendszer naplója csak azt mutatja, hogy egy ügyet feldolgoztak, de nem mutatja az AI-javaslatot, az emberi felülvizsgálatot vagy a felülírás okát, akkor a napló bizonyítéki értéke korlátozott. Az auditor ilyenkor megállapíthatja, hogy a naplózás nem támogatja megfelelően az auditálhatóságot. Ilyenkor a napló értéke a visszakövethetőségben mérhető, nem pusztán abban, hogy technikailag létezik.
A NIST AI Risk Management Framework a kockázatok feltérképezését, mérését, kezelését és irányítását egymáshoz kapcsolódó funkciókként írja le (National Institute of Standards and Technology, 2023). Az auditbizonyítékok gyűjtésénél ez a szemlélet azt jelenti, hogy az auditor nemcsak azt nézi, történt-e mérés, hanem azt is, hogyan lett a mérési eredményből döntés, intézkedés vagy kontrollmódosítás. Ilyenkor a mérés csak akkor auditértékű, ha van következménye a működésben.
Az interjú, mintavétel és naplóvizsgálat összekapcsolása egy konkrét ellenőrzési útvonalat ad. Az auditor például kiválaszt egy panaszkezelési ügyet, megnézi a kapcsolódó AI-kimenetet, ellenőrzi a felhasználói döntést, összeveti a naplóval, majd interjúban megkérdezi, hogyan értelmezték a javaslatot. Ha mindhárom forrás összhangban van, a bizonyíték erős. Ha eltérés van, az auditor célzottan vizsgálhatja, hogy szabályhiányról, képzési problémáról, rendszerkorlátról vagy dokumentációs hiányról van-e szó.
A bizonyítékgyűjtés során az auditor nem tévesztheti össze a hibát az auditnyom hiányával. Lehet, hogy a munkatárs helyesen járt el, de nem rögzítette a döntés okát. Ez működési szempontból még nem feltétlenül káresemény, audit szempontból azonban bizonyítékhiány. AI-rendszereknél ez különösen fontos, mert későbbi panasz, jogvita vagy incidens esetén a döntés rekonstruálhatósága alapvető lehet.
A naplóvizsgálatnál az adatvédelmi és hozzáférési szempontokat is kezelni kell. Az auditor ne kérjen indokolatlanul teljes hozzáférést személyes vagy érzékeny adatokhoz, ha mintavétel, anonimizált riport vagy célzott kivonat is elegendő. A bizonyítékgyűjtésnek arányosnak kell lennie. Ebben a helyzetben az audit sem lehet kontrollálatlan adatgyűjtés, mert maga az auditfolyamat is része a felelős működésnek.
A bizonyíték relevanciája, aktualitása és elegendősége
Egy auditbizonyíték akkor használható jól, ha releváns, aktuális, megbízható és elegendő. A relevancia azt jelenti, hogy a bizonyíték valóban a vizsgált követelményhez kapcsolódik. Az aktualitás azt jelenti, hogy a bizonyíték a vizsgált időszakra vagy jelenlegi működésre vonatkozik. A megbízhatóság azt jelenti, hogy a bizonyíték ellenőrizhető forrásból származik. Az elegendőség pedig azt jelenti, hogy a bizonyíték mennyisége és minősége alapján megalapozott auditmegállapítás tehető. Röviden: a jó bizonyíték döntésképes bizonyíték, nem pusztán információ.
A relevancia hiánya gyakori probléma. Egy általános AI-etikai irányelv például fontos lehet, de nem bizonyítja, hogy egy panaszkezelő rendszerben működik az emberi felülvizsgálat. Egy szolgáltatói biztonsági tanúsítvány hasznos lehet, de nem feltétlenül bizonyítja az adatfelhasználás célhoz kötöttségét vagy a modellkimenetek ellenőrzését. Az auditor feladata annak megállapítása, hogy a bizonyíték pontosan mely auditkérdésre ad választ.
Az aktualitás AI-rendszereknél különösen érzékeny kérdés. Egy fél évvel korábbi modellleírás vagy tesztjelentés lehet, hogy már nem tükrözi a jelenlegi állapotot, ha azóta adatforrás, modellverzió, felhasználási cél vagy beszállítói szolgáltatás változott. Emiatt az auditornak ellenőriznie kell a dokumentum verzióját, dátumát, jóváhagyását és kapcsolatát az éles rendszerrel. Ilyenkor az elavult bizonyíték hamis biztonságérzetet adhat, mert látszólag van dokumentáció, de nem a jelenlegi működésről.
A megbízhatóság szintén több tényezőtől függ. Egy rendszerből exportált napló általában erősebb bizonyíték, mint egy kézzel összeállított utólagos táblázat. Egy jóváhagyott, verziókezelt eljárás erősebb, mint egy e-mailben küldött informális leírás. Egy szolgáltatói auditriport értékes lehet, de az auditor vizsgálhatja, milyen körre, időszakra és kontrollokra terjed ki. Ebben az értelemben a bizonyíték forrása is auditkérdés, nem csak a tartalma.
Az elegendőség nem azt jelenti, hogy minden lehetséges bizonyítékot be kell gyűjteni. Az auditnak arányosnak kell maradnia. Egy kisebb kockázatú AI-eszköznél néhány jól kiválasztott bizonyíték elegendő lehet. Magasabb kockázatú vagy ügyfelet érintő rendszerben viszont többféle bizonyíték kombinációjára lehet szükség. Az auditor szakmai ítélete abban áll, hogy meg tudja határozni: mennyi bizonyíték elég a megbízható következtetéshez.
Az AI-rendszerek átláthatósági dokumentációjára jó példa a model card megközelítés. Mitchell és munkatársai a modellekről olyan dokumentációs formát javasoltak, amely tartalmazza többek között a tervezett felhasználást, a teljesítményjellemzőket, az értékelési környezetet és a korlátokat (Mitchell et al., 2019). Auditkörnyezetben ez nem helyettesíti a szervezeti kontrollokat, de segíthet abban, hogy a modell működéséről és korlátairól ellenőrizhető bizonyíték álljon rendelkezésre.
A relevancia és elegendőség értékelésekor az auditor a bizonyítékok közötti összhangot is vizsgálja. Ha a modellleírás szerint a rendszer csak javaslatot ad, de a napló és a felhasználói interjúk alapján a javaslatot rendszeresen automatikusan elfogadják, akkor a dokumentáció és a működés ellentmond egymásnak. Ha a kockázatértékelés magas kockázatot jelez, de nincs hozzá kapcsolódó monitoring vagy felülvizsgálati rekord, akkor a kockázatkezelési lánc megszakadt. Ilyenkor az ellentmondó bizonyíték önmagában megállapítást alapozhat meg, mert a kontrollrendszer következetlenségét jelzi.
Az auditbizonyíték értékelésénél az auditoroknak óvatosan kell bánniuk a „láttuk, hogy működik” típusú benyomásokkal. Egy bemutató vagy demó hasznos lehet, de nem feltétlenül bizonyítja a mindennapi működést. A demó gyakran kontrollált környezetben történik, előre kiválasztott példával. Az auditor ezért kérhet éles működési mintát, naplót vagy lezárt ügyet is. Ilyenkor a demonstráció nem azonos az üzemszerű bizonyítékkal, legfeljebb kiegészíti azt.
A szolgáltatói bizonyítékoknál az elegendőség különösen fontos. Egy külső AI-szolgáltató adhat általános biztonsági dokumentációt, de a szervezetnek azt kell megítélnie, hogy ez elég-e a saját felhasználási kockázatához. A FactSheets megközelítés az AI-szolgáltatásokkal kapcsolatos cél, teljesítmény, biztonság, védelem és eredet információinak dokumentálását javasolja, ami jól illeszkedik a beszállítói bizonyítékok auditálási igényéhez (Arnold et al., 2019).
A bizonyíték elegendőségét befolyásolja az is, hogy milyen következménye lehet az AI-rendszer hibájának. Egy belső dokumentumkereső eszköznél egy téves találat kellemetlen lehet, de korlátozott hatású. Egy panaszkezelő rendszerben azonban a hibás kategorizálás, késedelmes kezelés vagy nem megfelelő ügyfélválasz közvetlen ügyfélhatást és megfelelőségi problémát okozhat. Ezért a bizonyítékigény a hatás súlyával nő, és az auditor nem alkalmazhat minden rendszerre azonos mélységű vizsgálatot.
Az auditor akkor jár el megalapozottan, ha a bizonyítékokat nem elszigetelten, hanem auditkritériumhoz kötve értékeli. A kérdés mindig az: mit kellett volna teljesíteni, mit mutat a bizonyíték, elegendő-e a következtetéshez, és milyen kockázati jelentősége van az eltérésnek. Ez a gondolkodásmód védi az auditot attól, hogy puszta dokumentumgyűjtéssé váljon.
Hiányos bizonyítékból fakadó megállapítások kezelése
A hiányos bizonyíték nem mindig jelenti azt, hogy a kontroll nem működik, de azt igen, hogy az auditor nem tudja megfelelően igazolni a működést. Ez különösen fontos AIMS-környezetben, mert az AI-rendszerek felelős irányítása nemcsak helyes döntéseket, hanem visszakövethető döntéseket is igényel. Ha nincs bizonyíték, az auditmegállapításnak világosan különbséget kell tennie a kontrollhiány, a dokumentációhiány és a bizonyítékhiány között. Ilyenkor a hiány típusa határozza meg a javítást, ezért nem mindegy, hogyan fogalmaz az auditor.
Kontrollhiányról akkor beszélhetünk, ha a szervezet nem alakított ki szükséges ellenőrzési pontot. Például nincs előírás arra, hogy egy AI-alapú panaszkezelő rendszer kimeneteit embernek kell felülvizsgálnia. Dokumentációhiányról akkor van szó, ha a kontroll létezik, de nincs megfelelően leírva vagy jóváhagyva. Bizonyítékhiány pedig akkor áll fenn, ha a kontroll állítólag működik, de a konkrét esetekben nem található visszakövethető nyom. Ez a hármas különbség segít elkerülni a túl általános megállapításokat.
Egy gyenge auditmegállapítás így hangozhat: „az AI-rendszer dokumentációja hiányos”. Ez túl általános, és nem segít a javításban. Egy erősebb megállapítás például így fogalmazható meg: „a panaszkezelő AI-rendszer 2025. márciusi és áprilisi mintáiban nem volt visszakövethető az emberi felülvizsgálat eredménye, miközben a belső eljárás minden ügyfélválasz előtt kötelező ellenőrzést ír elő”. Ebben a formában a megállapítás bizonyítékra és kritériumra épül, ezért intézkedésre alkalmas.
A hiányos bizonyíték értékelésénél az auditor nem feltételezhet automatikusan rossz működést. Lehet, hogy a kontrollt ténylegesen elvégezték, de nem rögzítették. Ugyanakkor az sem elfogadható, hogy a szervezet pusztán szóbeli megerősítéssel pótolja a hiányzó auditnyomot. Az audit feladata nem az, hogy jóhiszeműséget feltételezzen, hanem hogy bizonyíthatóságot értékeljen. AI-rendszereknél a visszakövethetőség a felelősség része, különösen ügyfélhatással járó folyamatokban.
Raji és munkatársai az internal algorithmic auditing kapcsán arra mutattak rá, hogy az AI-rendszerek auditálása életcikluson átívelő dokumentációt és szervezeti elszámoltathatóságot igényel (Raji et al., 2020). Ez a megközelítés különösen hasznos a hiányos bizonyítékok értékelésekor. Ha a fejlesztés, bevezetés, működtetés és változáskezelés bizonyítékai nem kapcsolódnak össze, akkor az auditor nem tudja rekonstruálni, hogyan jutott a szervezet egy adott AI-működési állapotig.
A hiányos bizonyítékból fakadó megállapítások súlyosságát kockázatalapon kell meghatározni. Ha egy alacsony kockázatú belső AI-segédeszköznél hiányzik egy képzési jelenléti ív, az lehet kisebb eltérés. Ha egy ügyfélpanaszok kezelését támogató rendszerben nem bizonyítható az emberi felülvizsgálat, az már jelentősebb eltérés lehet. Ha egy magas hatású döntéstámogató AI-rendszert tesztelési bizonyíték nélkül élesítettek, az kritikus nemmegfelelőséghez is vezethet.
A javító intézkedésnek a bizonyítékhiány okát kell kezelnie. Ha a felhasználók nem tudják, mit kell rögzíteniük, képzési és eljárási pontosítás kell. Ha a rendszer nem teszi lehetővé a felülvizsgálat nyomának rögzítését, technikai módosítás szükséges. Ha a vezetők nem kérik számon a dokumentációt, irányítási kontrollt kell erősíteni. Ilyenkor a javítás nem lehet puszta utólagos iratgyártás, mert az nem oldja meg a működési bizonyíthatóság problémáját.
A hiányos bizonyíték kezeléséhez érdemes az auditoroknak külön bizonyítéki értékelési táblát használni. Ebben minden vizsgált kontrollhoz rögzíthető a kritérium, a kért bizonyíték, a kapott bizonyíték, a bizonyíték típusa, az aktualitás, az eltérés és a következtetés. Ez különösen hasznos összetett AI-rendszereknél, ahol sok dokumentum, napló, interjú és szolgáltatói adat kapcsolódik össze. Az ilyen rendszerezés segíti, hogy az auditmegállapítások következetesek és védhetők legyenek.
Egy AI-alapú panaszkezelő rendszerhez például az auditbizonyíték-lista így épülhet fel:
Vizsgált terület
Bizonyíték típusa
Példa bizonyíték
Auditcél
Használati cél
dokumentum
jóváhagyott használati eset leírása
a rendszer rendeltetésének ellenőrzése
Kockázatértékelés
dokumentum
AI-kockázatértékelési rekord
fő kockázatok és kontrollok azonosítása
Adatforrás
dokumentum és rendszeradat
adatmező-lista, hozzáférési riport
adatjogszerűség és adatminimalizálás vizsgálata
Emberi felügyelet
működési minta
lezárt panaszok felülvizsgálati nyoma
döntési kontroll működésének ellenőrzése
AI-kimenetek kezelése
napló
javaslat, felülírás, felhasználói döntés
kimenetek visszakövethetőségének vizsgálata
Felhasználói tudatosság
interjú és dokumentum
képzési rekord, interjújegyzet
gyakorlati ismeretek ellenőrzése
Incidenskezelés
dokumentum és működési minta
hibajegy, panasz, javító intézkedés
rendellenességek kezelésének vizsgálata
Beszállítói kontroll
dokumentum
szolgáltatói dokumentáció, szerződéses melléklet
külső AI-kockázatok értékelése
Ez a táblázat nem önmagában bizonyíték, hanem auditmódszertani eszköz. Segít abban, hogy az auditor ne csak dokumentumokat kérjen be, hanem minden kontrollhoz megfelelő bizonyítéktípust rendeljen. A cél az, hogy egy AI-kontrollt több oldalról kell látni, mert a dokumentum, a rendszeradat és a felhasználói gyakorlat együtt mutatja a működést.
A hiányos bizonyíték kezelésénél fontos az arányosság. Nem minden bizonyítékhiány igényel azonnali nagy projektet. Néha elegendő a sablon pontosítása, a naplómező bővítése, egy jóváhagyási lépés kötelezővé tétele vagy a felhasználói útmutató frissítése. Más esetben viszont a hiány mélyebb irányítási problémát jelez, például nincs kijelölt rendszerfelelős, nincs modellváltozás-kezelés, vagy nincs rendszeres monitoring. Az auditnak ezt a különbséget világosan kell kimondania.
A hiányos bizonyítékok lezárása utánkövetést igényel. Ha a szervezet azt vállalja, hogy a panaszkezelő AI-rendszerben bevezeti a felülvizsgálati nyom kötelező rögzítését, az auditor később mintát kérhet az új működésből. Nem elegendő azt látni, hogy elkészült egy új eljárás. Meg kell vizsgálni, hogy a változás ténylegesen megjelent-e a napi munkában. Így a javító intézkedés értéke a működésben dől el, nem a lezárási dátumban.
Az AIMS belső auditjában a bizonyítékgyűjtés végső célja nem az, hogy minél több dokumentumot archiváljon a szervezet. A cél az, hogy az AI-rendszerek felelős működése rekonstruálható, értékelhető és fejleszthető legyen. A jó auditbizonyíték megmutatja, ki döntött, mi alapján döntött, milyen kontroll működött, milyen eltérés történt, és hogyan reagált a szervezet.
A belső auditor akkor ad valódi értéket, ha nem elégszik meg a formális megfeleléssel, de nem is csúszik át technikai túlvizsgálatba. Az AI-rendszerek auditálása szervezeti, működési és bizonyítéki fegyelmet igényel. A felelős AI-irányítás egyik legfontosabb jele, hogy a szervezet nemcsak állítja, hanem ellenőrizhetően bizonyítja is a kontrollált működést.
Felhasznált szakirodalom
Arnold, M., Bellamy, R. K. E., Hind, M., Houde, S., Mehta, S., Mojsilović, A., Nair, R., Natesan Ramamurthy, K., Reimer, D., Olteanu, A., Piorkowski, D., Tsay, J., & Varshney, K. R. (2019). FactSheets: Increasing trust in AI services through supplier’s declarations of conformity. IBM Journal of Research and Development, 63(4/5), 6:1–6:13. https://doi.org/10.1147/JRD.2019.2942288
European Parliament & Council of the European Union. (2024). Regulation (EU) 2024/1689 of the European Parliament and of the Council of 13 June 2024 laying down harmonised rules on artificial intelligence. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
Gebru, T., Morgenstern, J., Vecchione, B., Vaughan, J. W., Wallach, H., Daumé III, H., & Crawford, K. (2021). Datasheets for datasets. Communications of the ACM, 64(12), 86–92. https://doi.org/10.1145/3458723
International Organization for Standardization. (2018). ISO 19011:2018: Guidelines for auditing management systems. ISO. https://www.iso.org/standard/70017.html
International Organization for Standardization. (2023a). ISO/IEC 42001:2023: Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/42001
Mitchell, M., Wu, S., Zaldivar, A., Barnes, P., Vasserman, L., Hutchinson, B., Spitzer, E., Raji, I. D., & Gebru, T. (2019). Model cards for model reporting. Proceedings of the Conference on Fairness, Accountability, and Transparency, 220–229. https://doi.org/10.1145/3287560.3287596
National Institute of Standards and Technology. (2023). Artificial intelligence risk management framework (AI RMF 1.0). U.S. Department of Commerce. https://doi.org/10.6028/NIST.AI.100-1
Raji, I. D., Smart, A., White, R. N., Mitchell, M., Gebru, T., Hutchinson, B., Smith-Loud, J., Theron, D., & Barnes, P. (2020). Closing the AI accountability gap: Defining an end-to-end framework for internal algorithmic auditing. Proceedings of the 2020 Conference on Fairness, Accountability, and Transparency, 33–44. https://doi.org/10.1145/3351095.3372873