Egy AI-rendszer kockázata sokszor nem magában a modellben kezdődik, hanem abban az adatfolyamban, amelyből a rendszer tanul, amelyre működés közben támaszkodik, és amelyet később naplóként, visszajelzésként vagy bizonyítékként megőriz. Ha nem világos, honnan származik az adat, mire használható, ki férhet hozzá, meddig őrizhető meg, és milyen minőségi korlátai vannak, akkor az AI-irányítás már az alapoknál bizonytalanná válik.
Az AI-adatkezelés ezért nem pusztán adatvédelmi vagy informatikai részfeladat. A felelős AI irányítási rendszerben az adatkezelés a teljes életcikluson végigkíséri a rendszert: az adatgyűjtéstől a tisztításon, címkézésen, tanításon, validáláson és éles használaton át egészen a naplózásig, megőrzésig és törlésig. A cél az, hogy az AI-rendszer ne használjon ellenőrizetlen, jogszerűtlen, pontatlan, túlzott vagy nem megfelelően védett adatot.
Az AI-adatkezelés életciklus-logikája
Az AI-rendszerek adatkezelése azért igényel külön irányítási figyelmet, mert az adat nem egyszeri bemenet. Egy szervezet gyakran úgy gondol az adatra, mint valamire, amit a fejlesztés elején összegyűjtenek, megtisztítanak, majd átadnak a modellnek. A gyakorlatban azonban az adat az AI-rendszer működési környezete, nem csupán induló nyersanyaga. Az adat megjelenik a tanításban, a validálásban, az éles következtetésben, a felhasználói visszajelzésekben, a naplózásban és a későbbi újratanításban is.
Az ISO/IEC 42001 szemlélete szerint az AI irányítási rendszernek nemcsak szabályokat kell létrehoznia, hanem működtetnie, fenntartania és folyamatosan javítania is kell az AI-hoz kapcsolódó irányítási folyamatokat (International Organization for Standardization, 2023). Ez az adatkezelésre is igaz: nem elegendő egy egyszeri adatvédelmi ellenőrzés, ha az AI-rendszer később új adatforrásokat, új felhasználói köröket vagy új döntési célokat kap. Ilyenkor a jóváhagyott adatkezelés idővel elavulhat, ha a szervezet nem épít be rendszeres felülvizsgálatot.
Az AI-adatkezelési életciklus legalább nyolc egymáshoz kapcsolódó lépésből áll:
adatforrások azonosítása;
adatgyűjtési vagy adatátvételi feltételek tisztázása;
adattisztítás és előkészítés;
címkézés vagy kategorizálás;
tanítás, validálás és tesztelés;
éles működéshez szükséges adathasználat;
naplózás, monitoring és visszacsatolás;
megőrzés, archiválás vagy törlés.
Ez a felsorolás nem technikai fejlesztési recept, hanem irányítási térkép. Minden lépésnél meg kell határozni, milyen adat kerül a rendszerbe, milyen célra, milyen jogosultsággal, milyen minőségi elvárással, milyen hozzáférési rendben és milyen megőrzési szabállyal. Egy érett AIMS-ben minden adatmozgásnak irányítási jelentősége van, mert az adatokon keresztül a rendszer kockázatai is változhatnak.
A NIST AI Risk Management Framework a kockázatkezelést az AI-rendszer teljes kontextusához köti: az érintettekhez, a célhoz, az adatokhoz, a méréshez és a működés közbeni kezeléshez (National Institute of Standards and Technology, 2023). Az adatkezelés ebből a nézőpontból nem elszigetelt kontrollterület, hanem a rendszer megbízhatóságának, átláthatóságának és elszámoltathatóságának alapja. Ha egy szervezet nem tudja megmondani, milyen adatból dolgozik a modell, akkor a modell kimenete sem értelmezhető felelősen, még akkor sem, ha technikailag gyors vagy pontosnak tűnik.
Az adatkezelési életciklus egyik fő kihívása, hogy az adatok jelentése a felhasználási helyzettől függ. Ugyanaz az adat alacsony kockázatú lehet statisztikai elemzésben, de magasabb kockázatúvá válhat, ha személyre szabott döntéstámogatásban, munkavállalói értékelésben vagy ügyfélkommunikációban használják. Ezért az adat célja legalább olyan fontos, mint az eredete, mert a cél határozza meg, milyen jogszerűségi, minőségi és hozzáférési kontrollokra van szükség.
Az AI-adatkezelés irányítása akkor működik jól, ha nem csupán adatvédelmi minimumokat rögzít. Az adatoknak alkalmasnak kell lenniük a tervezett AI-használatra, dokumentálni kell a korlátaikat, és ellenőrizni kell, hogy nem vezetnek-e félreértelmezhető, torz vagy nem kellően megalapozott kimenetekhez. A „datasheets for datasets” megközelítés is abból indul ki, hogy az adatkészletek motivációját, összetételét, gyűjtési módját, ajánlott használatát és korlátait dokumentálni kell (Gebru et al., 2021). Ebben a logikában az adatkészletnek saját igazolási csomagja van, nem csak technikai fájlneve vagy tárhelye.
Az adatkezelési életciklus azért is fontos, mert az AI-rendszer később új adatokat termelhet. Ilyenek lehetnek a felhasználói interakciók, hibajelzések, döntési naplók, modellkimenetek, emberi felülvizsgálatok eredményei vagy visszacsatolási adatok. Ezeket ugyanúgy kontrollálni kell, mint az induló tanítóadatokat. A működés közbeni adatoknál a napló egyszerre bizonyíték és kockázatforrás, mert segíti az auditot, de érzékeny információkat is tartalmazhat.
A gyakorlatban ezért az AI-adatkezelést nem lehet kizárólag a fejlesztői csapatra bízni. Szükség van üzleti tulajdonosra, adatgazdára, információbiztonsági szerepkörre, adatvédelmi vagy jogi értékelésre, valamint üzemeltetési felelősre. Ezek a szerepek együtt biztosítják, hogy az adathasználat ne csak technikailag legyen lehetséges, hanem irányítási szempontból is igazolható. Egy működő AIMS-ben az adatfelelősség szerepkörökhöz kötött, nem informális szakértői jóindulaton múlik.
Adatforrás, cél és jogszerűség dokumentálása
Az AI-adatkezelés első kontrollpontja az adatforrások azonosítása. A szervezetnek dokumentálnia kell, hogy az AI-rendszer milyen belső vagy külső adatokra épül, ki az adatgazda, milyen feltételekkel használható az adat, és milyen korlátozások kapcsolódnak hozzá. Ez azért lényeges, mert az ismeretlen adatforrás ismeretlen kockázatot jelent, különösen akkor, ha az adat személyes, üzletileg érzékeny vagy döntéstámogató célra használt.
Az adatforrás dokumentálása nem pusztán technikai leltár. Tartalmaznia kell az adat eredetét, frissítési gyakoriságát, minőségi jellemzőit, jogi státuszát, hozzáférési feltételeit és ismert korlátait. Külső adatforrás esetén külön vizsgálni kell a szerződéses, licencelési és beszállítói feltételeket. Belső adatforrásnál azt kell tisztázni, hogy az eredeti adatgyűjtési cél összeegyeztethető-e az AI-rendszer tervezett használatával. Ilyenkor az adat újrafelhasználása új döntést igényel, nem automatikus jogosultságot.
A GDPR alapelvei különösen fontosak ott, ahol személyes adatok érintettek. A célhoz kötöttség, az adattakarékosság, a pontosság, a korlátozott tárolhatóság, az integritás és bizalmas jelleg, valamint az elszámoltathatóság olyan irányítási elvek, amelyek AI-rendszereknél is közvetlenül értelmezhetők (European Parliament & Council of the European Union, 2016). Az AI-adatkezelésben a jogszerűség nem utólagos ellenőrző lista, hanem már az adatfolyam tervezésénél meghatározó követelmény.
Az adathasználati célt különösen pontosan kell megfogalmazni. Nem elegendő azt írni, hogy „AI-fejlesztés” vagy „modelloptimalizálás”, mert ezek túl tág kategóriák. A szervezetnek rögzítenie kell, hogy az adatot előrejelzésre, osztályozásra, ügyfélkommunikáció támogatására, munkafolyamat-segítésre, minőségellenőrzésre, tesztelésre vagy naplóelemzésre használja-e. Ha a cél homályos, akkor az adattakarékosság sem ellenőrizhető, mert nem világos, mi számít szükséges adatnak.
Az EU AI Act a magas kockázatú AI-rendszerek esetében külön figyelmet fordít a tanító-, validációs és tesztadatokra, valamint az adatirányítási és adatminőségi gyakorlatokra (European Parliament & Council of the European Union, 2024). Bár nem minden AI-rendszer magas kockázatú, a mögöttes irányítási elv szélesebb körben is hasznos: a szervezetnek tudnia kell, milyen adatokkal tanít, milyen adatokkal ellenőriz, és milyen adatokkal működtet egy rendszert. A napi működésben a tanítóadat és az üzemeltetési adat külön kontrollt igényel, mert más kockázatokat hordoznak.
Az adathasználati cél mellett rögzíteni kell a jogosultsági alapot is. Ez nem kizárólag jogi kérdés, hanem irányítási döntés is: ki hagyja jóvá az adott adathasználatot, milyen feltételekkel, milyen dokumentáció alapján, és mikor kell újraértékelni. Ha az AI-rendszer célja megváltozik, például belső elemzésből ügyfélre ható döntéstámogatássá válik, akkor az eredeti adatkezelési értékelés nem feltétlenül marad elegendő. Ilyen esetben a célváltozás adatkezelési változás is, nem csak üzleti fejlesztés.
Az adatforrás- és célleírásnak gyakorlati formát kell öltenie. A szervezet használhat adatnyilvántartást, AI-rendszerleltárt, adatlapot, adatvédelmi hatásvizsgálati hivatkozást, beszállítói dokumentációt vagy belső kontrollűrlapot. A lényeg nem a forma, hanem az, hogy az adatfolyam visszakereshető legyen. Egy auditálható rendszerben az adatútvonalnak követhetőnek kell lennie, az első gyűjtési ponttól az éles működésig.
Az adatkezelési dokumentációnak nemcsak a megengedett, hanem a tiltott felhasználásokat is tartalmaznia kell. Például rögzíthető, hogy bizonyos adatok nem használhatók modellújratanításra, nem küldhetők külső szolgáltatóhoz, nem használhatók automatizált döntéshez, vagy csak anonimizált, aggregált formában elemezhetők. Ez azért fontos, mert a korlátozás is irányítási bizonyíték, és később segít eldönteni, történt-e szabálytalan használat.
Egy AI-adatforrás dokumentációja legalább a következő kérdésekre adjon választ:
Honnan származik az adat?
Ki az adatgazda vagy felelős?
Milyen célra gyűjtötték eredetileg?
Milyen AI-célra kívánják használni?
Tartalmaz-e személyes vagy érzékeny adatot?
Milyen minőségi korlátai ismertek?
Ki férhet hozzá, és milyen szerepkörben?
Meddig őrizhető meg?
Használható-e tanításra, validálásra vagy csak működésre?
Milyen feltételekkel kell törölni vagy archiválni?
Az ilyen kérdéssor nem lassítja szükségtelenül az AI-bevezetést. Éppen ellenkezőleg: csökkenti annak esélyét, hogy a projekt később jogszerűségi, minőségi vagy auditálhatósági hiányosság miatt álljon meg. A gyakorlati tanulság egyszerű: a jól dokumentált adat gyorsítja a felelős döntést, mert nem kell minden kockázatot újra és újra utólag rekonstruálni.
Adatminőség, címkézés és validálás kontrolljai
Az AI-rendszer teljesítménye és megbízhatósága erősen függ az adatok minőségétől. Pontatlan, hiányos, elavult, torz vagy rosszul címkézett adatokból a modell is bizonytalanabb kimeneteket adhat. Ez nem jelenti azt, hogy minden adatnak tökéletesnek kell lennie, de azt igen, hogy az adatminőségi korlátokat ismerni és kezelni kell, mielőtt a rendszer éles döntéstámogatásba kerül.
Az adatminőség az AI-környezetben több szempontból vizsgálható. Fontos a pontosság, teljesség, időszerűség, konzisztencia, reprezentativitás, relevancia és nyomon követhetőség. A minőségi elvárások mindig a felhasználási céltól függnek: más szintű adatminőség szükséges egy belső trendfigyelő eszközhöz, és más egy olyan rendszerhez, amely ügyfélre vagy munkavállalóra ható döntést támogat. Ilyenkor az adatminőség nem abszolút tulajdonság, hanem a használati célhoz viszonyított megfelelőség.
Az ISO/IEC 5259 sorozat az adatok minőségét kifejezetten az analitika és a gépi tanulás kontextusában tárgyalja, ami jól mutatja, hogy az AI-adatminőség külön figyelmet igényel a hagyományos adatkezelési megközelítések mellett (International Organization for Standardization, 2024). A szervezeti gyakorlatban ez azt jelenti, hogy a minőségellenőrzésnek már az adatgyűjtésnél és előkészítésnél el kell kezdődnie, nem csak a modelltesztelésnél. Egy AIMS-ben az adatminőség korai kontrollpont, nem utólagos magyarázat a gyenge modellkimenetre.
A címkézés külön kockázati pont lehet. Ha az AI-rendszer tanítóadatai emberi címkézésre, kategorizálásra vagy értékelésre épülnek, dokumentálni kell a címkézési szabályokat, a címkézők szerepét, a minőségellenőrzés módját és az eltérések kezelését. Rosszul vagy következetlenül címkézett adatból a modell a szervezeti hibákat is megtanulhatja. Ezért a címkézés irányítási döntés is, nem csupán előkészítő technikai művelet.
A címkézési kontrolloknak legalább három kérdést kell kezelniük. Először: világosak-e a kategóriák és címkézési szabályok? Másodszor: ellenőrizte-e valaki a címkézés minőségét és következetességét? Harmadszor: van-e eljárás a vitás, bizonytalan vagy többértelmű esetek kezelésére? Ha ezek hiányoznak, akkor a modell a bizonytalanságot rejtett szabályként tanulhatja meg, amit később nehéz visszafejteni.
Az adattisztítás szintén dokumentálandó folyamat. Rögzíteni kell, milyen rekordokat távolítottak el, milyen hiányzó értékeket pótoltak, milyen átalakításokat végeztek, és ezek hogyan befolyásolhatják a kimeneteket. Az adattisztítás nem semleges művelet: döntések sorozata arról, mi számít hibának, kivételnek vagy releváns információnak. Ebből következik, hogy az adattisztítás megváltoztathatja a modell valóságképét, ezért nem maradhat dokumentálatlan.
A Dataset Nutrition Label megközelítés arra hívja fel a figyelmet, hogy az adatkészletek minőségéről, összetételéről és korlátairól közérthető, strukturált információra van szükség a felelős felhasználáshoz (Holland et al., 2018). Ez az AIMS szempontjából különösen hasznos, mert az adatminőségi információt nemcsak fejlesztőknek, hanem üzleti, compliance, audit és vezetői szerepköröknek is érthetővé kell tenni. Egy szervezetben az adatminőségi bizonyítékot több szerepkör olvassa, ezért nem lehet kizárólag technikai jegyzet.
A tanító-, validációs és tesztadatok elkülönítése szintén alapvető kontroll. Ha ugyanaz az adat szolgál tanításra és teljesítményellenőrzésre, a teszteredmény túlzottan kedvező képet adhat a rendszer valós működéséről. A szervezetnek ezért dokumentálnia kell, hogyan választotta szét az adatokat, milyen mintavételi logikát alkalmazott, és milyen korlátai vannak a tesztkörnyezetnek. Ebben a helyzetben a validálás célja a valós használhatóság bizonyítása, nem pusztán egy kedvező pontszám előállítása.
Az éles működésben az adatminőség újra változhat. A bemeneti adatok eltérhetnek a tanításkor használt adatoktól, új ügyféltípusok jelenhetnek meg, megváltozhatnak a folyamatok, vagy a felhasználók másképp kezdhetik használni a rendszert. Ilyenkor a modell teljesítménye romolhat, még akkor is, ha az eredeti teszteredmények megfelelőek voltak. A működési tanulság az, hogy az adatminőséget működés közben is figyelni kell, nem csak a fejlesztés lezárásakor.
A minőségellenőrzési kontrolltervben érdemes külön rögzíteni:
milyen adatminőségi mutatókat figyelnek;
milyen hibák számítanak kritikusnak;
milyen gyakran történik adatminőségi felülvizsgálat;
ki vizsgálja az eltéréseket;
mikor kell újratesztelni vagy felfüggeszteni a használatot;
hogyan dokumentálják a minőségi kivételeket;
milyen visszacsatolás kerül a fejlesztési vagy üzemeltetési folyamatba.
Az adatminőségi kontrolloknak arányosnak kell lenniük. Egy kísérleti, belső ötletgeneráló eszköz más kontrollszintet igényel, mint egy ügyfélkockázati előrejelző modell. Ugyanakkor még az alacsonyabb kockázatú használatoknál is kell minimális adatminőségi tudatosság: legalább az adatforrás, cél, korlát és felelős legyen ismert. Így az arányosság nem kontrollhiányt jelent, hanem a kockázathoz igazított ellenőrzési mélységet.
Hozzáférés, naplózás, megőrzés és törlés
Az AI-adatkezelés egyik legfontosabb működési kérdése, hogy ki férhet hozzá az adatokhoz, milyen céllal, milyen jogosultsági szinten és milyen időtartamra. A hozzáférés nemcsak az adatbázisokra vonatkozik, hanem tanítóadatokra, tesztkészletekre, címkézési felületekre, naplókra, modellkimenetekre, promptokra, riportokra és exportált állományokra is. A mindennapi működésben az AI-adat több helyen jelenik meg, mint amennyit az első adatleltár általában mutat.
A hozzáféréskezelés alapelve a szükséges és arányos hozzáférés. A munkatársak csak azokhoz az adatokhoz férjenek hozzá, amelyekre az adott szerepkörükben valóban szükségük van. A fejlesztőnek nem feltétlenül kell azonosítható ügyféladat, a tesztelőnek nem feltétlenül kell teljes adatállomány, az üzleti felhasználónak pedig nem feltétlenül kell nyers napló. Ilyenkor a jogosultság nem kényelmi kérdés, hanem adatvédelmi, információbiztonsági és auditálhatósági kontroll.
A jogosultsági rendet szerepkörökhöz kell kötni. Külön érdemes kezelni az adatgazdát, a fejlesztőt, a modellüzemeltetőt, a belső auditort, az üzleti felhasználót, az incidenskezelőt és a külső beszállítót. Minden szerepkörnél meg kell határozni, milyen adatot láthat, módosíthat, exportálhat vagy törölhet. A gyakorlatban a szerepköralapú hozzáférés csökkenti az informális adatmozgást, mert előre tisztázza, ki mit tehet az AI-adatokkal.
A naplózás kettős természetű. Egyrészt elengedhetetlen az auditálhatósághoz, az incidensek kivizsgálásához, a teljesítményfigyeléshez és a használati szabályok ellenőrzéséhez. Másrészt a naplók maguk is tartalmazhatnak személyes, bizalmas vagy üzletileg érzékeny információt. Ezért a napló nem melléktermék, hanem önálló adatkezelési objektum, amelyhez hozzáférési, megőrzési és törlési szabályokat kell rendelni.
A naplózási tervnek ki kell térnie arra, milyen eseményeket rögzít a szervezet. Ilyen lehet a felhasználói hozzáférés, adatbetöltés, modellfuttatás, kimenetgenerálás, emberi felülvizsgálat, módosítás, export, hiba, incidens vagy kivételes hozzáférés. A naplózás célját is meg kell határozni: biztonsági ellenőrzés, teljesítményfigyelés, audit, incidenskezelés vagy jogi bizonyítás. Ha a cél hiányzik, akkor a túlzott naplózás is kockázattá válhat, mert indokolatlan mennyiségű adatot őrizhet meg.
Az adatmegőrzésnél különösen fontos a célhoz kötöttség és az időbeli korlátozás. Más megőrzési idő lehet indokolt a tanítóadatokra, a tesztadatokra, a működési naplókra, a hibajegyekre, a modellkimenetekre és az auditbizonyítékokra. A GDPR tárolási korlátozási elve alapján a személyes adatok nem őrizhetők meg tovább, mint ameddig a célhoz szükségesek (European Parliament & Council of the European Union, 2016). Az AI-irányításban a megőrzési idő kontrollértékű döntés, mert a túl rövid megőrzés auditkockázatot, a túl hosszú megőrzés adatvédelmi kockázatot okozhat.
A törlés nem egyszerű fájltörlési feladat. AI-környezetben tisztázni kell, hogy az adat hol található: nyers adatállományban, előkészített adatkészletben, tanítóhalmazban, teszthalmazban, naplóban, biztonsági mentésben, riportban vagy beszállítói rendszerben. Ha az adat több helyre áramlik, akkor a törlésnek is több pontot kell érintenie. Emiatt az adatútvonal ismerete a törlés feltétele, különösen akkor, ha személyes vagy érzékeny adatról van szó.
Külön figyelmet igényel, ha az AI-rendszer külső szolgáltatóhoz kapcsolódik. Ilyenkor dokumentálni kell, milyen adat kerül ki a szervezetből, hol történik feldolgozás, történik-e naplózás vagy modellfejlesztési célú felhasználás, milyen visszatartási szabályok vannak, és hogyan ellenőrizhető a törlés. A beszállítói kapcsolatban az adatkezelési kontroll szerződéses kérdéssé válik, mert a szervezet felelőssége nem szűnik meg az adatok továbbításával.
A hozzáférés, naplózás, megőrzés és törlés gyakorlati kontrolljai például a következők lehetnek:
szerepköralapú jogosultsági mátrix;
hozzáférési jóváhagyási folyamat;
rendszeres jogosultság-felülvizsgálat;
érzékeny adatok maszkolása vagy pszeudonimizálása;
naplózási célok és naplózott események listája;
naplók hozzáférési korlátozása;
adatkategóriánkénti megőrzési idők;
törlési és archiválási folyamat;
beszállítói adatkezelési feltételek;
incidens esetén követendő adatkezelési lépések.
A működési kontrolloknak nemcsak létezniük kell, hanem bizonyíthatónak is kell lenniük. Egy auditor vagy vezetői felülvizsgálat számára nem elegendő az a kijelentés, hogy a hozzáféréseket „kezelik”. Szükség van jogosultsági listákra, felülvizsgálati jegyzőkönyvekre, naplóbeállításokra, törlési bizonyítékokra és kivételkezelési dokumentációra. Ilyenkor a kontroll akkor él, ha bizonyítható, nem akkor, ha a szabályzatban elvileg szerepel.
Adatkezelési kontrollterv a napi működésben
Az AI-adatkezelési kontrollterv célja, hogy az adatfolyam minden lényeges pontján világossá tegye a felelősséget, a kontrollt és a bizonyítékot. Nem az a feladata, hogy minden technikai részletet túladminisztráljon, hanem az, hogy a fejlesztéstől az üzemeltetésig ellenőrizhetővé tegye az adathasználatot. Egy jó kontrolltervben az adatfolyam döntési pontokra bomlik, nem átláthatatlan technikai láncolatra.
A kontrollterv kiindulópontja az adatfolyam feltérképezése. Meg kell mutatnia, honnan jön az adat, milyen átalakításokon megy keresztül, hol használja a modell, milyen kimenetet hoz létre, milyen napló keletkezik, és mi történik az adatokkal a használat után. Ez nem feltétlenül bonyolult ábra; lehet táblázat vagy folyamatvázlat is. A lényeg az, hogy az adatmozgás láthatóvá váljon, mert csak látható adatfolyamra lehet kontrollt építeni.
Egy AI-modell tanítási és üzemeltetési adatfolyamához készített rövid kontrollterv például a következő területeket tartalmazhatja:
Adatkezelési szakasz
Fő kockázat
Kontroll
Bizonyíték
Adatforrás kiválasztása
Ismeretlen eredet vagy jogszerűtlen használat
Adatforrás- és céljóváhagyás
Adatforrás-adatlap, jóváhagyás
Adatátvétel
Nem megfelelő hozzáférés vagy túlzott adat
Jogosultsági és adattakarékossági ellenőrzés
Hozzáférési lista, adatmező-leírás
Adattisztítás
Dokumentálatlan torzítás vagy adatvesztés
Tisztítási szabályok rögzítése
Adattisztítási jegyzőkönyv
Címkézés
Következetlen kategorizálás
Címkézési útmutató és mintavételes ellenőrzés
Címkézési szabályzat, ellenőrzési eredmény
Tanítás és validálás
Nem megfelelő tesztadat vagy túlillesztés
Tanító-, validációs és tesztadat elkülönítése
Tesztterv, adatfelosztási dokumentáció
Éles működés
Eltérő bemeneti adatok vagy hibás kimenet
Monitoring és emberi felülvizsgálat
Monitoringriport, felülvizsgálati napló
Naplózás
Túlzott vagy érzékeny naplóadat
Naplózási cél és megőrzési idő meghatározása
Naplózási terv, konfiguráció
Törlés és archiválás
Indokolatlan megőrzés vagy hiányos törlés
Megőrzési és törlési szabály
Törlési jegyzőkönyv, archiválási lista
Ez a táblázat a gyakorlatban szerepkörökkel és határidőkkel egészíthető ki. Minden kontrollhoz szükséges felelős: adatgazda, üzleti tulajdonos, technikai felelős, információbiztonsági felelős, adatvédelmi szerepkör vagy belső auditor. Ha nincs felelős, akkor a kontroll végrehajtása bizonytalan marad. Egy AIMS-ben a kontroll felelőse ugyanolyan fontos, mint maga a kontroll, mert a szabály csak kijelölt végrehajtóval válik működéssé.
A kontrolltervnek külön kezelnie kell a fejlesztési és üzemeltetési adatokat. A fejlesztésben fontos a tanító- és tesztadatok minősége, célhoz kötöttsége és dokumentáltsága. Az üzemeltetésben előtérbe kerül a bemeneti adatok változása, a naplózás, a hozzáférés, a visszacsatolás és az incidenskezelés. Ezért a fejlesztési adatkontroll nem váltja ki az üzemeltetési kontrollt, mert a kockázatok más időpontban és más formában jelentkeznek.
A gépi tanulási rendszerek rejtett technikai adósságáról szóló kutatás arra figyelmeztet, hogy az ML-rendszerekben a függőségek, visszacsatolási hurkok, adatváltozások és rendszerkapcsolatok hosszú távú karbantartási terheket hozhatnak létre (Sculley et al., 2015). Ez az adatkezelésben különösen fontos: ha nincs adatverziózás, változásnapló és monitoring, akkor a szervezet később nem tudja pontosan megállapítani, miért változott a modell viselkedése. A működési tanulság az, hogy az adatváltozás modellváltozássá válhat, még akkor is, ha a modellkód nem módosult.
A kontrolltervnek ezért tartalmaznia kell a változáskezelési szabályokat is. Új adatforrás, új adatkategória, új címkézési módszer, megváltozott megőrzési szabály, új beszállítói feldolgozás vagy eltérő üzemeltetési környezet esetén újra kell értékelni a kockázatokat. Nem minden változás igényel teljes újrajóváhagyást, de minden lényeges adatváltozásnak nyoma kell legyen. Ilyenkor a változásnapló az adatkezelési emlékezet, amely nélkül a későbbi audit és hibakeresés nehézkessé válik.
Az incidens- és eltéréskezelést szintén be kell építeni az adatkezelési gyakorlatba. Adatkezelési eltérés lehet például jogosulatlan hozzáférés, hibás adatbetöltés, pontatlan címkézés, nem engedélyezett adatforrás használata, túl hosszú megőrzés, hiányzó törlés vagy olyan naplóadat keletkezése, amelyet a szervezet nem tervezett kezelni. A gyakorlatban az adatkezelési incidens nem mindig látványos, de hosszú távon jelentős megfelelőségi és bizalmi kockázatot okozhat.
A bizonyítékkezelés az AIMS egyik központi eleme. Minden adatkezelési kontrollhoz kapcsolódnia kell valamilyen dokumentumnak, naplónak, jóváhagyásnak, riportnak vagy ellenőrzési eredménynek. Ezekből áll össze az a bizonyítéklánc, amely megmutatja, hogy a szervezet felelősen irányította az AI-adatfolyamot. Az auditálhatóság szempontjából a bizonyíték nem utólagos adminisztráció, hanem a felelős működés nyoma.
A rövid adatkezelési kontrolltervnek a következő minimális szerkezetben érdemes elkészülnie:
Az AI-rendszer célja és adatkezelési szerepe.
Az adatforrások és adatkategóriák felsorolása.
Az adathasználati célok és korlátok rögzítése.
A jogszerűségi és jogosultsági feltételek meghatározása.
Az adatminőségi elvárások és ellenőrzések leírása.
A hozzáférési és naplózási szabályok megadása.
A megőrzési, archiválási és törlési szabályok meghatározása.
A változás- és incidenskezelési pontok kijelölése.
A felelősök és jóváhagyók megnevezése.
A bizonyítékok és felülvizsgálati gyakoriság rögzítése.
Ez a szerkezet segít abban, hogy az AI-adatkezelés ne szakadjon szét különálló jogi, technikai és üzleti részfeladatokra. A kontrollterv a közös működési nyelvet teremti meg: megmutatja, mit kell védeni, miért, kinek, mikor és milyen bizonyítékkal. Ebben az értelemben az adatkezelési kontrollterv az AI-rendszer irányítási térképe, amely a fejlesztési döntéseket összeköti az üzemeltetési felelősséggel.
A napi működésben a legfontosabb tanulság az, hogy az AI-adatkezelés nem egyetlen szakértői terület feladata. Az üzleti cél, az adatminőség, a jogszerűség, a hozzáférés, a naplózás, a megőrzés és a törlés együtt határozza meg, hogy a rendszer felelősen működtethető-e. Az AI irányítási rendszer akkor válik éretté, amikor az adatfolyam minden lényeges pontján megválaszolható három kérdés: milyen adatot használunk, milyen feltételekkel használjuk, és mivel tudjuk igazolni, hogy a kontroll működött.
Felhasznált szakirodalom
European Parliament & Council of the European Union. (2016). Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data. Official Journal of the European Union. https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
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
Holland, S., Hosny, A., Newman, S., Joseph, J., & Chmielinski, K. (2018). The Dataset Nutrition Label: A framework to drive higher data quality standards. arXiv. https://arxiv.org/abs/1805.03677
International Organization for Standardization. (2023). ISO/IEC 42001:2023: Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/42001
International Organization for Standardization. (2024). ISO/IEC 5259-1:2024: Artificial intelligence — Data quality for analytics and machine learning (ML) — Part 1: Overview, terminology, and examples. ISO. https://www.iso.org/standard/81088.html
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
Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 28. https://papers.neurips.cc/paper/5656-hidden-technical-debt-in-machine-learning-systems.pdf