Egy szervezet könnyen érezheti úgy, hogy a kockázat jelentős részét kiszervezte, amikor nem maga fejleszt AI-modellt, hanem kész felhőszolgáltatást, generatív AI-eszközt vagy szoftverbe épített AI-funkciót használ. A valóság ennél kényelmetlenebb: az üzleti döntés, az adathasználat, az ügyfélhatás és a megfelelőségi felelősség továbbra is a szervezet működésében jelenik meg.
A külső AI-szolgáltatás nem egyszerű beszerzési tétel. AI irányítási rendszerben úgy kell kezelni, mint olyan irányítási kapcsolatot, amely adatkezelési, modellműködési, információbiztonsági, szerződéses, auditálhatósági és változáskezelési kérdéseket egyszerre vet fel. A beszállító technológiát adhat, de a szervezetnek kell eldöntenie, milyen célra, milyen adatokkal, milyen kontrollok mellett és milyen bizonyítékok alapján használja azt.
Miért marad a felelősség a szervezetnél?
A harmadik féltől származó AI használata gyakran azért vonzó, mert gyorsabb, olcsóbb és egyszerűbb, mint egy saját rendszer fejlesztése. A külső szolgáltató biztosíthat modellt, infrastruktúrát, API-t, felhasználói felületet, biztonsági funkciókat vagy beépített automatizálást. Ettől azonban a kiszervezés nem szünteti meg a felelősséget, mert az AI-rendszer hatása továbbra is a szervezet folyamataiban, ügyfélkapcsolataiban és döntéseiben jelenik meg.
Az ISO/IEC 42001 logikája szerint az AI irányítási rendszer a szervezet AI-val kapcsolatos politikáit, céljait és folyamatait rendezi egységes irányítási rendszerbe, függetlenül attól, hogy a szervezet fejlesztőként, szolgáltatóként vagy felhasználóként vesz részt az AI-életciklusban (International Organization for Standardization, 2023a). Ez a beszállítói kapcsolatoknál különösen fontos. Egy szervezet nem mondhatja azt, hogy az AI-kockázat kizárólag a külső szolgáltató ügye, ha ő választja ki az eszközt, ő tölti fel az adatokat, ő állítja be a használati feltételeket, és ő építi be a kimenetet a döntési folyamatba.
A külső AI-szolgáltatás kockázata több irányból érkezhet. Lehet adatkezelési kockázat, ha nem világos, milyen adat kerül a szolgáltatóhoz, hogyan használják fel, meddig őrzik meg, és bekerül-e modellfejlesztési vagy tanítási folyamatba. Lehet modellkockázat, ha nem átlátható, hogyan működik a modell, milyen korlátai vannak, milyen hibákat produkálhat, vagy hogyan változik idővel. Emellett a beszállítói kapcsolat AI-kockázati láncot hoz létre, mert a szervezet saját kontrolljai részben egy külső fél működésétől függenek.
A beszállítói kockázat hagyományosan is ismert terület az információbiztonságban. Az ISO/IEC 27036 a beszállítói kapcsolatok információbiztonsági kezelését olyan keretként tárgyalja, amelyben az ügyfélnek és a szolgáltatónak egyaránt szerepe van az információs rendszerek és adatok védelmében (International Organization for Standardization, 2021). AI-környezetben ez a logika bővül: nemcsak a hozzáférést, titkosítást vagy incidenskezelést kell vizsgálni, hanem az adatfelhasználás célját, a modellfrissítést, az AI-kimenetek kezelését és a szolgáltató bizonyítékait is.
A felelősség megmaradása nem azt jelenti, hogy a szervezetnek minden technikai részletet saját maga kell ellenőriznie. Azt jelenti, hogy tudnia kell, milyen bizonyítékokra támaszkodik. Ha a szolgáltató állítja, hogy nem használja fel az ügyféladatokat modellképzésre, akkor ezt szerződéses feltétellel, dokumentációval, beállítással vagy auditbizonyítékkal kell alátámasztani. Ebben az értelemben a bizalom nem helyettesíti a bizonyítékot, különösen olyan AI-szolgáltatásnál, amely üzleti vagy személyes adatokat kezel.
A NIST AI Risk Management Framework az AI-kockázatokat nemcsak technikai hibaként, hanem az egyénekre, szervezetekre és társadalomra gyakorolt hatások összefüggésében kezeli (National Institute of Standards and Technology, 2023). Harmadik felek esetében ez azt jelenti, hogy a szervezetnek nem elég a szolgáltatás elérhetőségét vagy árát vizsgálnia. A használati kontextust is értékelnie kell: milyen döntést támogat az eszköz, kikre hat, milyen adatokat kezel, és milyen következménye lehet egy hibás, elfogult vagy jogosulatlan kimenetnek.
A külső AI-szolgáltatások különösen megtévesztők lehetnek, ha egy meglévő szoftverben „csak” új funkcióként jelennek meg. Egy ügyfélszolgálati platformba épített automatikus válaszgenerálás, egy HR-rendszerbe épített jelöltértékelés vagy egy irodai alkalmazásba épített dokumentumelemzés látszólag nem külön AI-projekt. A kockázat azonban ettől még valós. Ilyenkor a beépített AI-funkció is irányítandó AI-használat, még akkor is, ha a szervezet nem külön beszerzésként találkozik vele.
A felelős kezelés első gyakorlati lépése az AI-szolgáltatások nyilvántartása. A szervezetnek tudnia kell, milyen külső AI-eszközöket használ, mely üzleti folyamatokban, milyen adatokkal, milyen felhasználói körrel és milyen döntési következményekkel. Nyilvántartás nélkül nincs valós kockázatkezelés. Ha az AI-használatok csak csapatok, részlegek vagy egyéni munkatársak szintjén jelennek meg, akkor a láthatatlan AI-használat gazdátlan kockázatot termel, mert sem a kontrollok, sem a szerződéses feltételek nem illeszkednek hozzá.
A felelősségi rendnek ezért ki kell térnie arra, ki engedélyezhet külső AI-szolgáltatást, ki értékeli a beszállítót, ki vizsgálja az adatkezelést, ki hagyja jóvá a szerződéses feltételeket, ki ellenőrzi az információbiztonsági bizonyítékokat, és ki felügyeli a szolgáltatás működését. A beszállítói AI-kockázat nem kezelhető egyetlen osztály feladataként. A külső AI irányítása több szerepkör közös döntése, amelyben üzleti, jogi, adatvédelmi, információbiztonsági, IT- és compliance-szempontok egyaránt megjelennek.
A beszállítói átvilágítás AI-specifikus szempontjai
A hagyományos beszállítói átvilágítás általában pénzügyi stabilitást, szolgáltatási szintet, információbiztonságot, adatvédelmet, üzletmenet-folytonosságot és szerződéses feltételeket vizsgál. AI-szolgáltatásnál ez nem elég. Az átvilágításnak a modellműködésre, az adathasználatra, a kimenetek korlátaira, a változásbejelentésre, az emberi felügyelet támogatására és az auditálhatóságra is ki kell terjednie.
A beszállítói átvilágítás célja nem az, hogy a szervezet teljesen feltárja a szolgáltató üzleti titkait vagy modellarchitektúráját. A cél annak eldöntése, hogy a szolgáltatás a tervezett használati célra, adott kockázati szinten, elfogadható kontrollok mellett használható-e. Ezért az átvilágításnak a használati célból kell kiindulnia, nem egy általános, minden szolgáltatóra azonosan alkalmazott kérdőívből.
Az ISO/IEC 23894 az AI-kockázatkezelést olyan megközelítésként írja le, amelyet az AI-val kapcsolatos tevékenységekbe és szervezeti funkciókba kell beépíteni (International Organization for Standardization, 2023b). Beszállítók esetében ez azt jelenti, hogy az AI-kockázatértékelés nem különülhet el a beszerzéstől, szerződéskötéstől és üzemeltetéstől. Ha az átvilágítás csak a beszerzési folyamat végén történik meg, akkor már gyakran késő: az üzleti igény, a szolgáltatóválasztás és a költségkeret addigra rögzült.
Az AI-specifikus átvilágítás első területe az adatkezelés. Meg kell érteni, milyen adatok kerülnek a szolgáltatóhoz, milyen célból, milyen jogalapon, milyen feldolgozási helyen, milyen megőrzési idővel és milyen hozzáférési szabályok mellett. Generatív AI-szolgáltatásnál különösen fontos kérdés, hogy a szolgáltató felhasználja-e a bemeneteket, dokumentumokat, promptokat vagy kimeneteket saját modelljeinek fejlesztésére. Itt az adathasználat célja kulcskontroll, mert ugyanaz az adat elfogadható lehet feldolgozásra, de nem feltétlenül elfogadható modellképzésre.
A második terület a modellműködés és a szolgáltatás korlátainak értése. A szervezetnek tudnia kell, milyen típusú AI-funkciót használ: osztályozást, rangsorolást, generálást, ajánlást, előrejelzést, kivonatolást vagy automatikus döntéstámogatást. Nem minden esetben szükséges mély technikai részlet, de a használati korlátoknak világosnak kell lenniük. A modell korlátja üzleti kockázattá válik, ha a felhasználók biztos tényként kezelik a bizonytalan vagy nem ellenőrzött kimenetet.
A harmadik terület a teljesítmény, pontosság és megbízhatóság. Külső szolgáltatónál a szervezet sokszor nem tudja közvetlenül újratesztelni a modellt teljes mélységben, de kérhet dokumentált teljesítményinformációkat, tesztelési módszereket, validálási összefoglalót, ismert korlátokat és felhasználási figyelmeztetéseket. A NIST AI RMF hangsúlyos eleme a kockázatok mérhetősége és kezelhetősége, ami külső AI-szolgáltatásnál csak akkor működik, ha a szolgáltató legalább érdemi információt ad a rendszer jellemzőiről (National Institute of Standards and Technology, 2023). Ebben a helyzetben a homályos szolgáltatói ígéret nem elég, mert a szervezetnek saját döntést kell hoznia az elfogadható kockázatról.
A negyedik terület az információbiztonság. Ide tartozik a hozzáférés-kezelés, titkosítás, sérülékenységkezelés, naplózás, incidensbejelentés, alvállalkozók kezelése, felhőbiztonság és a szolgáltató biztonsági tanúsítványainak értékelése. A NIST SP 800-161 Rev. 1 a kiberbiztonsági ellátási lánc kockázatkezelését olyan szervezeti szintű gyakorlatként kezeli, amelyben a kockázatokat azonosítani, értékelni és mérsékelni kell a teljes beszállítói láncban (Boyens et al., 2022). AI-szolgáltatásoknál az információbiztonság és az AI-kockázat összekapcsolódik, mert az adat, a modell, a hozzáférés és a kimenet ugyanabban a szolgáltatási láncban mozog.
Az ötödik terület az auditálhatóság. A szolgáltatónak nem feltétlenül kell minden belső részletet feltárnia, de a szervezetnek rendelkeznie kell olyan bizonyítékokkal, amelyekkel később igazolható a döntés megalapozottsága. Ilyen lehet tanúsítás, független auditjelentés, biztonsági riport, adatkezelési dokumentáció, modellleírás, változáskezelési tájékoztató vagy szerződéses vállalás. Ha ezek hiányoznak, akkor a beszállítói kockázat nem értékelhető megfelelően, csak feltételezések alapján kezelhető.
Az átvilágítás mélységét a kockázat határozza meg. Egy alacsony kockázatú, belső produktivitási célú AI-eszköznél elegendő lehet egyszerűbb beszállítói kérdőív és alapvető adatkezelési korlátozás. Egy ügyféladatokat kezelő, döntéstámogató vagy érzékeny üzleti folyamatba épített AI-szolgáltatásnál részletesebb bizonyítékokra, erősebb szerződéses garanciákra és szigorúbb monitoringra van szükség. A beszállítói kontrollnak arányosnak kell lennie, de az arányosság nem jelentheti a kritikus kérdések elhagyását.
Az átvilágítás során legalább a következő AI-specifikus kérdéscsoportokat célszerű vizsgálni:
milyen AI-funkciót biztosít a szolgáltató;
milyen adatok kerülnek a szolgáltatásba;
használják-e az adatokat modellképzésre vagy szolgáltatásfejlesztésre;
milyen alvállalkozók vagy felhőszolgáltatók vesznek részt;
milyen biztonsági és adatvédelmi kontrollok működnek;
milyen dokumentáció áll rendelkezésre a modellről;
hogyan történik a modell vagy szolgáltatás frissítése;
kap-e a szervezet előzetes változásbejelentést;
milyen audit- vagy bizonyítékszolgáltatás érhető el;
hogyan kezelik az incidenseket, hibákat és panaszokat.
A beszállítói átvilágítás végső kimenete nem maga a kérdőív, hanem a döntés. Használható-e a szolgáltatás? Milyen korlátozással? Milyen adatokkal nem használható? Szükséges-e további szerződéses feltétel? Kell-e pilot, kockázatcsökkentő intézkedés vagy vezetői jóváhagyás? Ilyenkor az átvilágítás döntési kapu, nem adminisztratív melléklet a beszerzés végén.
Szerződéses és technikai kontrollok kapcsolata
A külső AI-szolgáltatás kezelésében a szerződés és a technikai kontroll nem helyettesíti, hanem kiegészíti egymást. A szerződés rögzíti az elvárásokat, kötelezettségeket, jogokat és felelősségi határokat. A technikai kontroll biztosítja, hogy ezek az elvárások a mindennapi működésben is érvényesüljenek. Egyik sem elegendő önmagában. A szerződés papíron véd, a technikai kontroll a működésben.
Adatkezelésnél például a szerződés kimondhatja, hogy a szolgáltató nem használhatja fel az ügyféladatokat saját modelljeinek tanítására. Ez fontos, de nem mindig elég. Szükség lehet olyan adminisztrátori beállításra, amely kikapcsolja a tanítási célú felhasználást, korlátozza az adatmegőrzést, meghatározza a hozzáférési jogosultságokat és naplózza a használatot. Így a szerződéses tilalom technikai beállítással válik ellenőrizhetővé, különösen generatív AI-eszközök esetében.
A szerződésnek ki kell térnie az adatkezelés céljára, az adatfeldolgozás helyére, az alvállalkozókra, az adatmegőrzésre, a törlésre, az incidensbejelentésre, a biztonsági követelményekre és a szolgáltatás megszűnésekor követendő eljárásra. AI-szolgáltatásnál emellett szükséges lehet a modellfrissítések, teljesítményváltozások, lényeges funkciómódosítások és auditbizonyítékok kezelésének rögzítése. Ilyenkor az AI-szerződés nem csak adatvédelmi megállapodás, hanem működési és kockázatkezelési eszköz is.
Az EU AI Act a magas kockázatú AI-rendszerek esetében különös jelentőséget tulajdonít többek között a kockázatkezelésnek, adatirányításnak, műszaki dokumentációnak, naplózásnak, átláthatóságnak, emberi felügyeletnek, valamint a pontosság, robusztusság és kiberbiztonság követelményeinek (European Parliament & Council of the European Union, 2024). Nem minden külső AI-szolgáltatás tartozik magas kockázatú kategóriába, de a szervezeti tanulság világos: a szolgáltatói szerződésnek és kontrollrendszernek alkalmasnak kell lennie a kockázati szinthez illeszkedő bizonyításra.
A technikai kontrollok közé tartozhat a felhasználói jogosultságok korlátozása, az érzékeny adatok bevitelének tiltása, adatmaszkolás, naplózás, exportkorlátozás, jóváhagyási munkafolyamat, biztonságos API-kulcs-kezelés, integrációs kontroll, tartalomszűrés, emberi felülvizsgálat vagy monitoring. Ezek nem minden esetben érhetők el ugyanabban a szolgáltatásban. Ezért a szolgáltatás konfigurálhatósága beszerzési szempont, nem utólagos technikai részlet.
A szerződésben a szolgáltatói változásbejelentés különösen fontos. AI-szolgáltatásoknál a modell vagy annak működési környezete változhat anélkül, hogy a szervezet ezt közvetlenül észrevenné. Egy API mögött módosulhat a modellverzió, az alapértelmezett beállítás, a tartalomszűrés, a naplózás vagy az adatkezelési feltétel. Ha a szervezet erről nem kap időben információt, akkor a kontrollált használat látszólagossá válhat, mert a szolgáltatás már nem pontosan ugyanaz, amelyet korábban értékeltek.
A szerződésnek ezért ki kell mondania, milyen változásokról kell a szolgáltatónak értesítést adnia. Nem minden apró fejlesztés igényel előzetes jóváhagyást, de lényeges változás lehet például az adatfeldolgozási hely módosítása, új alvállalkozó bevonása, modellfrissítés, funkcióváltozás, biztonsági kontroll csökkenése, auditbizonyíték megváltozása vagy szolgáltatási feltételek módosulása. Ebben a rendszerben a változásbejelentés kockázati riasztás, nem marketingtájékoztató.
A technikai és szerződéses kontrollokat a felhasználási célhoz kell igazítani. Egy generatív AI-szolgáltatás belső szövegtervezéshez más kontrollt igényel, mint ugyanaz a szolgáltatás ügyféladatok elemzésére vagy jogi dokumentumok előkészítésére. A szolgáltatás neve önmagában nem határozza meg a kockázatot. Ugyanaz az AI-eszköz más kockázatú lehet, ha más adatokkal, más döntési helyzetben és más felhasználói körrel használják.
A szerződéses kontrolloknak tartalmazniuk kell a bizonyítékszolgáltatás módját is. A szolgáltató milyen rendszerességgel ad biztonsági vagy megfelelőségi dokumentumot? Elérhető-e független auditjelentés? Értesít-e incidensről? Biztosít-e naplókat vagy ügyféloldali adminisztrációs riportokat? Támogatja-e a törlési vagy hozzáférési kérelmek kezelését? Itt a bizonyítékhoz való hozzáférés szerződéses jog, amelyet később audit vagy incidenshelyzetben lehet érvényesíteni.
A szervezetnek azt is meg kell határoznia, milyen esetben nem használható a szolgáltatás. Lehetnek tiltott adatkategóriák, tiltott döntési célok, jóváhagyáshoz kötött felhasználások vagy csak tesztkörnyezetben engedélyezett funkciók. A belső szabályok és a szerződéses feltételek akkor működnek jól együtt, ha a munkatársak nem jogi absztrakciókat kapnak, hanem konkrét használati határokat. Ilyenkor a belső szabály fordítja le a szerződést, hogy a napi működésben is alkalmazható legyen.
A beszállítói AI-kontroll egyik legfontosabb döntése az, hogy mi történik a szolgáltatás megszűnésekor. Hogyan exportálhatók vagy törölhetők az adatok? Mi történik a naplókkal? Megmaradnak-e a szervezet által adott bemenetek vagy finomhangolási adatok? Tovább használhatja-e a szolgáltató az ezekből származó tanulságokat? Van-e átállási terv más szolgáltatóra vagy belső megoldásra? A kilépési feltételek hiánya függőséget teremt, amely később üzleti és megfelelőségi kockázattá válhat.
Változásbejelentés, auditálhatóság és bizonyítékok
A külső AI-szolgáltatás kockázata nem állandó. Változhat a modell, a szolgáltatási architektúra, az adatkezelési gyakorlat, az alvállalkozói lánc, a biztonsági környezet, a jogi feltétel vagy a szervezet saját használati módja. Ezért a beszállítói értékelés nem egyszeri esemény, hanem folyamatos felügyeleti feladat.
A változásbejelentés azért kritikus, mert a szervezet csak akkor tudja újraértékelni a kockázatot, ha értesül a lényeges változásokról. Egy modellfrissítés javíthatja a teljesítményt, de új viselkedést, új hibákat vagy eltérő kimeneti mintázatot is létrehozhat. Egy új alvállalkozó bevonása javíthatja a skálázhatóságot, de módosíthatja az adatáramlást vagy az adatfeldolgozás földrajzi helyét. Ilyenkor a szolgáltatói változás szervezeti változásként hat, még akkor is, ha technikailag a szolgáltató oldalán történik.
Az AI-szolgáltatások auditálhatósága több szintű kérdés. Az egyik szint a szolgáltató saját bizonyítéka: tanúsítvány, független audit, megfelelőségi jelentés, biztonsági dokumentáció, adatvédelmi tájékoztató vagy technikai fehér könyv. A másik szint a szervezet saját bizonyítéka: beszerzési döntés, kockázatértékelés, jóváhagyás, konfiguráció, használati szabály, naplózás és monitoring. A kettő együtt ad képet. Az auditálhatóság közös bizonyítéklánc, amelyben a szolgáltató és a szervezet dokumentumai egymásra épülnek.
A NIST SP 800-161 Rev. 1 hangsúlyozza, hogy a kiberbiztonsági ellátási lánc kockázatkezelése szervezeti szinten, több rétegben és a beszállítói kapcsolatok teljes életciklusán át értelmezendő (Boyens et al., 2022). AI-szolgáltatásoknál ez a megközelítés különösen hasznos, mert a beszállítói kapcsolat nem ér véget a szerződés aláírásával. A szervezetnek nyomon kell követnie, hogy a szolgáltatás továbbra is megfelel-e az eredeti kockázati és működési feltételeknek.
Az ENISA ellátási lánci támadásokról szóló elemzése rámutatott, hogy a beszállítói láncok egyre fontosabb támadási és kockázati felületet jelentenek a digitális rendszerekben (European Union Agency for Cybersecurity, 2021). AI-környezetben ez a jelentőség tovább nő, mert a szolgáltatói kapcsolat nemcsak szoftverkomponenseket, hanem adatáramlást, modellműködést és automatizált kimeneteket is magában foglalhat. Ennek következtében az AI-beszállító digitális kockázati kapu, amelyen keresztül biztonsági, adatvédelmi és működési kockázatok léphetnek be.
A bizonyítékok értékelésénél nem elég azt nézni, hogy a szolgáltató adott-e dokumentumot. Azt is vizsgálni kell, hogy a dokumentum mire vonatkozik, mennyire friss, független-e, lefedi-e a használt szolgáltatást, kiterjed-e alvállalkozókra, és kapcsolódik-e az AI-specifikus kockázatokhoz. Egy általános biztonsági tanúsítvány hasznos lehet, de nem feltétlenül válaszolja meg, hogy a generatív AI-bemeneteket felhasználják-e modellfejlesztésre. Ezért a bizonyíték relevanciája fontosabb a mennyiségénél, különösen összetett szolgáltatói ökoszisztémában.
A szolgáltatói bizonyítékokat érdemes kockázati szint szerint kategorizálni. Alacsony kockázatnál elegendő lehet nyilvános biztonsági dokumentáció, adatkezelési feltétel és belső jóváhagyás. Közepes kockázatnál szükséges lehet részletesebb kérdőív, szerződéses adatfeldolgozási megállapodás, konfigurációs bizonyíték és incidensbejelentési vállalás. Magasabb kockázatnál indokolt lehet független auditjelentés, részletes technikai dokumentáció, alvállalkozói lista, változásbejelentési mechanizmus és rendszeres felülvizsgálat. Így a bizonyítékkérésnek kockázatalapúnak kell lennie, nem pusztán beszerzési rutinon alapulnia.
A szervezet saját oldalán is szükség van bizonyítékokra. Rögzíteni kell, ki döntött a szolgáltatás használatáról, milyen célra engedélyezték, milyen adatkategóriákkal használható, milyen korlátozások érvényesek, milyen technikai beállítások történtek, és milyen monitoringot végeznek. Ha a szolgáltatás később problémát okoz, ezek nélkül nehéz igazolni, hogy a szervezet ésszerű és felelős döntést hozott. Ilyenkor a belső dokumentáció védi a döntés minőségét, nem csupán auditmappát tölt meg.
A változáskezelés része a szolgáltató rendszeres újraértékelése is. Nem minden szolgáltatót kell azonos gyakorisággal felülvizsgálni, de magasabb kockázatú AI-szolgáltatásoknál indokolt lehet éves vagy eseményalapú értékelés. Eseményalapú újraértékelés szükséges lehet jelentős szolgáltatásváltozás, incidens, új adatkategória, új üzleti cél, szabályozási változás vagy jelentős felhasználói panasz esetén. Ez alapján a felülvizsgálatot nem naptárhoz kell kötni kizárólag, hanem kockázati eseményekhez is.
Az auditálhatóság egyik gyakorlati kérdése a naplózás. Külső AI-szolgáltatásnál tisztázni kell, milyen naplók keletkeznek, ki fér hozzájuk, meddig őrzik őket, exportálhatók-e, és alkalmasak-e incidensvizsgálatra vagy megfelelőségi ellenőrzésre. Generatív AI-eszközöknél különösen fontos lehet, hogy látható legyen, ki, mikor, milyen célra használta a szolgáltatást, milyen adatot vitt be, és milyen kimenetet használt fel döntéshez vagy kommunikációhoz. Ebben a helyzetben a naplózás a felelős használat nyoma, nem csupán technikai adatgyűjtés.
A szolgáltatóval kapcsolatos döntéseket a szervezetnek össze kell kapcsolnia a belső AI-nyilvántartással. Egy külső AI-szolgáltatás akkor kezelhető átláthatóan, ha szerepel az AI-használati esetek között, megvan a tulajdonosa, ismert a kockázati besorolása, dokumentáltak a beszállítói bizonyítékai, és láthatók a felülvizsgálati kötelezettségei. Ha ez nincs meg, akkor a beszállítói kontroll elszakad a napi működéstől, és a megfelelőség könnyen formális gyakorlattá válik.
Beszállítói kérdéslista generatív AI-szolgáltatáshoz
Egy generatív AI-szolgáltatás beszerzésénél a kérdéslista célja az, hogy a szervezet ne csak funkciót és árat hasonlítson össze, hanem a használat feltételeit, kockázatait és bizonyítékait is értékelje. A kérdéseknek adatkezelési, biztonsági, modell-, szerződéses és auditálhatósági területeket egyaránt le kell fedniük. Egy jól felépített kérdéslista esetében a beszerzés kockázati döntéssé válik, nem pusztán technológiai választássá.
Az első kérdéscsoport az adatkezelésre vonatkozik. A szervezetnek pontosan értenie kell, milyen adatok kerülnek a szolgáltatóhoz, milyen célból, milyen ideig és milyen jogi feltételekkel. Generatív AI-nál a promptok, feltöltött dokumentumok, kimenetek, naplók és felhasználói metaadatok is relevánsak lehetnek. Ebben a körben a prompt is adatkezelési esemény lehet, különösen akkor, ha ügyféladatot, üzleti titkot vagy személyes adatot tartalmaz.
Adatkezelési kérdések:
Milyen adatokat kezel a szolgáltatás a használat során?
Felhasználja-e a szolgáltató a bemeneteket vagy kimeneteket modellképzésre?
Kikapcsolható-e szerződésesen és technikailag a tanítási célú felhasználás?
Hol történik az adatfeldolgozás és adattárolás?
Milyen adatmegőrzési idők érvényesek?
Hogyan történik az adatok törlése a szolgáltatás megszűnésekor?
Milyen alvállalkozók férhetnek hozzá az adatokhoz?
Van-e lehetőség ügyféloldali adatmaszkolásra vagy érzékeny adatok kizárására?
A második kérdéscsoport az információbiztonságra és hozzáférés-kezelésre irányul. Egy generatív AI-szolgáltatás gyakran sok felhasználóval, böngészőn keresztül, felhőalapon vagy API-n át működik. Ez megnöveli a hozzáférés-kezelés, naplózás és konfiguráció szerepét. Ilyenkor a felhasználói jogosultság AI-kontroll is, mert meghatározza, ki milyen adatokkal és milyen célra használhatja az eszközt.
Biztonsági kérdések:
Támogatott-e az egyszeri bejelentkezés és többtényezős hitelesítés?
Beállíthatók-e szerepköralapú jogosultságok?
Naplózható-e a felhasználói aktivitás?
Exportálhatók-e a naplók ellenőrzési vagy incidensvizsgálati célból?
Milyen titkosítást alkalmaznak adatátvitel és adattárolás során?
Hogyan kezelik a sérülékenységeket?
Milyen incidensbejelentési határidőt vállal a szolgáltató?
Milyen biztonsági tanúsítványok vagy auditjelentések érhetők el?
A harmadik kérdéscsoport a modellműködésre és kimenetekre vonatkozik. A generatív AI sajátossága, hogy meggyőzően megfogalmazott, de hibás vagy nem ellenőrzött kimenetet is adhat. Ezért nem elég azt tudni, hogy a szolgáltatás „jól működik”. A szervezetnek értenie kell, milyen korlátok mellett használható, milyen típusú feladatokra ajánlott, és milyen esetekben szükséges emberi ellenőrzés. Ezen a ponton az AI-kimenet nem automatikus igazság, hanem ellenőrizendő munkatermék.
Modell- és kimeneti kérdések:
Milyen modell vagy modellcsalád áll a szolgáltatás mögött?
Kap-e a szervezet értesítést modellverzió-változásról?
Milyen ismert korlátai vannak a szolgáltatásnak?
Milyen tesztelési vagy validálási dokumentáció érhető el?
Hogyan kezeli a szolgáltató a pontatlan, káros vagy nem megfelelő kimeneteket?
Van-e tartalomszűrés vagy biztonsági korlát?
Támogatott-e az emberi felülvizsgálat munkafolyamata?
Megkülönböztethető-e a modell által generált tartalom az ember által jóváhagyott tartalomtól?
A negyedik kérdéscsoport a szerződéses elvárásokra vonatkozik. A szerződésnek nemcsak az árat és szolgáltatási szintet kell rögzítenie, hanem az AI-specifikus kötelezettségeket is. Ide tartozik a felhasználási cél, adathasználat, változásbejelentés, auditbizonyíték, alvállalkozók kezelése, incidens, törlés, kilépés és felelősségi határ. Ebben a keretben a szerződés az AI-irányítás jogi gerince, amelyhez a technikai beállításoknak és belső szabályoknak illeszkedniük kell.
Szerződéses kérdések:
Rögzíti-e a szerződés a megengedett és tiltott adathasználatokat?
Vállal-e a szolgáltató adatfeldolgozói vagy más releváns jogi kötelezettségeket?
Előírható-e előzetes értesítés lényeges szolgáltatásváltozásról?
Rögzíti-e a szerződés az alvállalkozók kezelését?
Milyen audit- vagy bizonyítékszolgáltatási jogok vannak?
Mi történik szolgáltatásmegszűnéskor az adatokkal és naplókkal?
Van-e támogatott adatexport vagy átállási lehetőség?
Milyen felelősségi korlátokat tartalmaz a szerződés?
Az ötödik kérdéscsoport a szervezeti bevezetésre és működtetésre irányul. Még a legjobb szolgáltatói kontroll is gyenge lesz, ha a szervezet nem határozza meg a belső használati szabályokat. Ki használhatja az eszközt? Milyen adatokkal? Milyen kimenetet kell ellenőrizni? Ki hagyhat jóvá ügyfélnek szánt tartalmat? Hogyan kell hibát vagy incidenst jelenteni? Ezen a ponton a beszállítói kontroll belső működési szabállyá válik, különben a felhasználók saját értelmezésük szerint alkalmazzák az eszközt.
Belső működtetési kérdések:
Ki az üzleti tulajdonosa a szolgáltatásnak?
Ki felel a szolgáltató rendszeres felülvizsgálatáért?
Milyen adatkategóriákkal engedélyezett a használat?
Milyen célokra tilos a szolgáltatás használata?
Milyen kimenetek igényelnek emberi jóváhagyást?
Hogyan kell dokumentálni a lényeges felhasználási eseteket?
Milyen képzés szükséges a felhasználóknak?
Hogyan történik a panaszok, hibák és incidensek kezelése?
A kérdéslista használata akkor eredményes, ha a válaszokból döntés születik. A válasz lehet elfogadás, feltételes elfogadás, további bizonyítékkérés, korlátozott pilot, szerződésmódosítás vagy elutasítás. A beszállító nem attól megfelelő, hogy minden kérdésre tökéletes választ ad, hanem attól, hogy a szolgáltatás kockázata érthető, kontrollálható és a használati célhoz képest elfogadható. Így a beszállítói döntés az elfogadható kockázatról szól, nem arról, hogy létezik-e kockázatmentes AI-szolgáltatás.
A harmadik felek, beszállítók és külső AI-szolgáltatások kezelése az AI irányítási rendszer egyik leggyakorlatiasabb területe. A szervezetnek nem kell minden modellt saját maga fejlesztenie, de minden külső AI-használatnál tudnia kell, milyen adatot ad át, milyen modelltől függ, milyen bizonyítékokra támaszkodik, milyen szerződéses jogai vannak, és hogyan kezeli a változásokat. A felelős AI-irányítás lényege itt az, hogy a külső technológia ne váljon belső vakfolttá.
Felhasznált szakirodalom
Boyens, J., Paulsen, C., Moorthy, R., & Bartol, N. (2022). Cybersecurity supply chain risk management practices for systems and organizations (NIST Special Publication 800-161 Revision 1). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-161r1
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
European Union Agency for Cybersecurity. (2021). ENISA threat landscape for supply chain attacks. ENISA. https://www.enisa.europa.eu/publications/threat-landscape-for-supply-chain-attacks
International Organization for Standardization. (2021). ISO/IEC 27036-1:2021: Cybersecurity — Supplier relationships — Part 1: Overview and concepts. ISO. https://www.iso.org/standard/82905.html
International Organization for Standardization. (2023a). ISO/IEC 42001:2023: Information technology — Artificial intelligence — Management system. ISO. https://www.iso.org/standard/42001
International Organization for Standardization. (2023b). ISO/IEC 23894:2023: Information technology — Artificial intelligence — Guidance on risk management. ISO. https://www.iso.org/standard/77304.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