A generatív mesterséges intelligencia vállalati elterjedése új kihívás elé állítja az információbiztonsági szervezeteket. A munkatársak számára ma már természetes lehet, hogy egy AI-szolgáltatást vesznek igénybe szövegíráshoz, elemzéshez, fordításhoz, programozáshoz vagy dokumentumok feldolgozásához.

A vállalat erre többféleképpen reagálhat. Az egyik legegyszerűbb megoldás egy olyan belső szabályzat létrehozása, amely meghatározza, hogy milyen AI-szolgáltatásokat szabad használni, milyen adatokat lehet azokba feltölteni, vagy akár teljesen megtiltja a nyilvános AI-szolgáltatások használatát.

Egy ilyen szabályzat önmagában azonban nem jelent megfelelő információbiztonsági kontrollt.

Ennek oka nem az, hogy a szabályzat szükségtelen lenne. Éppen ellenkezőleg: egyértelmű elvárások nélkül nehéz meghatározni, hogy a munkatársak milyen keretek között használhatják az AI-t. A probléma az, hogy a szabályzat megmondja, mit szabad vagy mit nem szabad megtenni, de önmagában nem akadályozza meg a szabály megszegését, és nem feltétlenül teszi láthatóvá annak megtörténtét.

Ez az AI esetében különösen fontos, mert a szolgáltatások használata gyakran nem igényel semmilyen vállalati infrastruktúra-módosítást.

A Shadow AI kialakulása

Az előző cikkben szó esett a Shadow IT AI vonatkozásairól. A klasszikus Shadow IT esetében a vállalat olyan technológia használatával szembesül, amelyet az IT-szervezet nem hagyott jóvá vagy nem tart nyilván.

A generatív AI ezt a problémát tovább nehezíti.

Egy munkatársnak nem kell alkalmazást telepítenie. Nem kell új szervert létrehoznia, és sok esetben nem kell vállalati rendszergazdai jogosultsággal rendelkeznie sem. Egy böngészőből elérhető egy AI-szolgáltatás, amelyhez akár néhány perc alatt hozzáférhet.

A kockázat ezért nem feltétlenül az, hogy a vállalatnál ismeretlen szoftver fut.

Lehet, hogy egyáltalán nem fut új szoftver a vállalati infrastruktúrán.

A munkatárs egyszerűen adatot küld egy külső szolgáltatásnak.

Ez történhet például akkor, amikor egy alkalmazott egy szerződést szeretne összefoglalni, egy hibás forráskódot akar kijavíttatni, egy ügyfélpanaszra szeretne választ készíteni, vagy egy belső dokumentum alapján szeretne prezentációt létrehozni.

A szándék önmagában nem rosszindulatú. A munkatárs munkát szeretne végezni hatékonyabban.

Információbiztonsági szempontból azonban a kérdés az, hogy milyen adat hagyta el a vállalati kontrollált környezetet, és milyen szolgáltatáshoz került.

Az OWASP 2025-ös LLM-kockázati listája külön kockázatként kezeli a Sensitive Information Disclosure problémáját, amely magában foglalhat személyes adatokat, pénzügyi információkat, bizalmas üzleti adatokat, hitelesítési adatokat és jogi dokumentumokat is. (OWASP Gen AI Security Project)

A tiltás és a technikai kontroll különbsége

Egy AI-használati szabályzat például kimondhatja:

„Bizalmas vállalati adat nyilvános AI-szolgáltatásba nem tölthető fel.”

Ez egy teljesen ésszerű követelmény.

A kérdés azonban az, hogy mi történik akkor, ha valaki mégis feltölt egy ilyen dokumentumot.

Három különböző helyzet képzelhető el.

Az első esetben a vállalat rendelkezik szabályzattal, de nincs technikai kontroll. A munkatárs feltölti az adatot, az esemény pedig valószínűleg csak akkor válik ismertté, ha valaki később észreveszi valahogyan(?).

A második esetben van technikai kontroll is. Például a vállalat képes felismerni bizonyos AI-szolgáltatások használatát, naplózza a forgalmat, vagy DLP-rendszeren keresztül vizsgálja az adatmozgást.

A harmadik esetben a kontroll nemcsak észlel, hanem szükség esetén meg is akadályozza az adatátadást.

A három modell között jelentős különbség van.

A szabályzat az első szinten is létezik, de önmagában egyik esetben sem garantálja, hogy a szabályt betartják.

A felhasználói “hiba” nem szüntethető meg szabályzattal

Az információbiztonságban régóta ismert probléma, hogy a biztonsági kontrollok nem építhetnek kizárólag arra, hogy minden felhasználó mindig helyesen fog viselkedni.

Az AI esetében ez különösen jól látható.

Egy munkatárs nem feltétlenül tudja eldönteni, hogy egy adott dokumentum milyen adatvédelmi vagy információbiztonsági kategóriába tartozik.

Lehet, hogy tudja, hogy az ügyfél neve érzékeny adat.

De mi a helyzet egy belső üzleti tervvel?

Egy hibajeggyel?

Egy konfigurációs fájllal?

Egy forráskóddal?

Egy olyan dokumentummal, amelyben nincs jelszó, de szerepel benne egy belső rendszer felépítése?

A szabályzat egyértelműbbé teheti ezeket a kérdéseket, de nem képes minden helyzetet előre meghatározni.

Ezért a szabályzatnak nem a technikai kontroll helyettesítőjeként, hanem annak részeként kell működnie.

Az AI használata ráadásul nem feltétlenül látható az IT számára

A hagyományos Shadow IT egyik problémája az, hogy az IT-szervezet nem tudja, milyen alkalmazások vannak használatban.

AI esetében ehhez hozzáadódik az úgynevezett SaaS-jellegű használat.

A felhasználó ugyanazon a vállalati laptopon dolgozik tovább, ugyanazzal az operációs rendszerrel, ugyanazzal a böngészővel.

A különbség mindössze annyi, hogy egy weboldalon megnyitott egy AI-szolgáltatást.

Ha a vállalat nem rendelkezik megfelelő láthatósággal, akkor nehéz megválaszolni az alapvető kérdéseket:

• Mely AI-szolgáltatásokat használják?
• Melyik szervezeti egység használja őket?
• Milyen célból?
• Milyen adatokat továbbítanak?
• Használnak-e személyes fiókokat?
• Milyen külső API-khoz kapcsolódnak?
• Történik-e automatizált adatátadás?

A NIST generatív AI-ra vonatkozó kockázatkezelési profilja ezért az AI használatával kapcsolatban a szervezeti governance, a dokumentáció, a nyomon követés és az emberi felülvizsgálat szükségességét is hangsúlyozza. (NIST)

A probléma második szintje: amikor az AI nemcsak feldolgoz, hanem fejleszt

A szabályozási probléma még összetettebbé válik, amikor az AI-t nem egyszerűen munkát támogató eszközként használják, hanem szoftverfejlesztésre.

Egy munkatárs AI segítségével létrehozhat egy olyan scriptet vagy kisebb alkalmazást, amely vállalati adatbázishoz, API-hoz vagy fájlrendszerhez kapcsolódik.

Ilyenkor már nem pusztán arról van szó, hogy a munkatárs egy külső AI-szolgáltatásba adatot küldött.

Létrejött egy új szoftverkomponens is.

Ennek pedig lehet:

• adatbázis-hozzáférése,
• API-kulcsa,
• felhasználói jogosultsága,
• külső kommunikációja,
• naplózása,
• függősége,
• sérülékenysége,
• és üzleti funkciója.

Ha erre csak egy általános AI-használati szabályzat vonatkozik, az nem feltétlenül elegendő.

A vállalati alkalmazásbiztonsági folyamatoknak azt is kezelniük kell, hogy ki hozhat létre alkalmazást, milyen környezetben, milyen adatokhoz férhet hozzá, hogyan kerülhet üzembe, és milyen biztonsági ellenőrzéseken kell átmennie.

Az AI által generált kód sem tekinthető megbízható kódnak

Az AI által előállított kód esetében ugyanazok a biztonsági alapelvek érvényesek, mint bármely más fejlesztésnél.

A generált kódot ellenőrizni kell.

Ez nem feltétlenül azért szükséges, mert az AI „rosszindulatú” vagy szándékosan hibás kódot készít. Sokkal egyszerűbb oka van: az AI nem ismeri automatikusan a vállalat teljes architektúráját, jogosultsági modelljét, adatvédelmi követelményeit és biztonsági szabályait.

Az OWASP külön kockázatként kezeli az LLM-ek kimenetének nem megfelelő kezelését. Ha egy AI által generált kimenet megfelelő validáció nélkül kerül tovább egy másik rendszerhez, az például injection-hoz, jogosultság-emeléshez vagy akár távoli kódfuttatáshoz is vezethet. (OWASP Gen AI Security Project)

Ez különösen fontos akkor, ha a fejlesztő az AI által generált kódot vagy SQL-lekérdezést ellenőrzés nélkül használja.

Az agentek újabb problémát jelentenek

A következő lépcső az AI-agentek megjelenése.

Egy hagyományos chatbot elsősorban választ ad.

Egy agent azonban már képes lehet más rendszereket elérni és műveleteket végrehajtani.

Ilyen lehet például egy adatbázis lekérdezése, fájl létrehozása, e-mail küldése vagy egy vállalati rendszerben végrehajtott módosítás.

Itt már nem elegendő azt vizsgálni, hogy „használhatja-e a munkatárs az AI-t”.

Azt is vizsgálni kell, hogy milyen jogosultságot kapott az AI által használt rendszer, és milyen műveleteket hajthat végre.

Az OWASP ezt Excessive Agency néven külön kockázati kategóriaként kezeli. A probléma egyik alapvető oka lehet a túl széles funkcionalitás, a túlzott jogosultság vagy a túl nagy autonómia. (OWASP Gen AI Security Project)

Ez már klasszikus információbiztonsági kérdés: a rendszer csak ahhoz férjen hozzá, amire ténylegesen szüksége van. Sokszor azonban az agentek a felhasználó saját felhasználói adataival és jogosultságaival futnak, aminél garantált, hogy a szükségesnél nagyobb jogosultsággal bír az agent, mint amire az adott folyamatban szükség vam.

Mit jelent akkor a megfelelő AI-governance?

A megoldás nem az, hogy nincs szükség szabályzatra.

Éppen ellenkezőleg.

Szükség van szabályzatra, de a szabályzatnak egy kontrollrendszer részeként kell működnie.

Egy érett megközelítés legalább négy réteget különít el.

1. Szabályozás

Meg kell határozni:

• milyen AI használható,
• milyen célra,
• milyen adatokkal,
• milyen fiókkal,
• milyen feltételekkel.

2. Láthatóság

A vállalatnak képesnek kell lennie az AI-használat feltérképezésére.

Ide tartozhat:

• hálózati forgalom elemzése,
• SaaS-felderítés,
• endpoint telemetry,
• identitáskezelés,
• API-használat,
• naplózás.

3. Megelőzés

Ahol indokolt, technikai kontrolloknak kell megakadályozniuk a nem engedélyezett adatátadást vagy hozzáférést.

Itt jöhet szóba például DLP, webes hozzáférés-szabályozás, identity-based access control vagy megfelelő API-kontroll.

4. Biztonságos fejlesztés

Az AI-val létrehozott alkalmazást nem azért kell külön kezelni, mert AI készítette.

Azért kell kezelni, mert vállalati alkalmazás lett belőle.

Ha vállalati adatot kezel, akkor ugyanúgy szükség lehet:

• forráskód-kezelésre,
• code review-ra,
• dependency-ellenőrzésre,
• secret managementre,
• jogosultságvizsgálatra,
• naplózásra,
• biztonsági tesztelésre.

A szabályzat tehát szükséges, de nem elégséges

Az AI-használati szabályzat fontos alap.

Segít meghatározni a vállalat elvárásait, kijelölni a felelősségeket, és egyértelművé tenni, hogy bizonyos adatok milyen környezetbe nem kerülhetnek.

De egy olyan szabályzat, amely mögött nincs technikai kontroll, nagyjából ugyanazt a problémát kezeli, mint amikor egy vállalat azt mondja:

„A munkatársaknak tilos jelszavakat megosztaniuk.”

Ez helyes szabály.

De ettől még nem lesz megfelelő a vállalat jelszóbiztonsága.

Ugyanígy:

„Bizalmas adatot tilos nyilvános AI-szolgáltatásba feltölteni.”

Ez is helyes szabály.

A valódi biztonsági kérdés azonban az, hogy a vállalat:

észreveszi-e, ha megtörténik, és képes-e megakadályozni, ha szükséges.

A generatív AI esetében ezért nem önmagában az AI-használat tiltása vagy engedélyezése jelenti a megfelelő biztonsági megközelítést.

A cél inkább egy olyan környezet kialakítása, amelyben az AI használata látható, szabályozott és technikailag kontrollált.

Ez különösen fontos azért, mert az AI használatának kockázata nem áll meg az adatbevitel oldalán.

Az AI ma már képes kódot generálni, rendszerekkel kommunikálni és bizonyos esetekben műveleteket végrehajtani.

A vállalatnak ezért nemcsak azt kell tudnia, hogy ki használ AI-t.

Azt is tudnia kell, hogy:

milyen adatot ad neki, milyen rendszert épít vele, milyen jogosultságot ad neki, és milyen rendszerekhez engedi hozzáférni.

A szabályzat ennek az alapja.

De önmagában nem kontroll.