Egy új use case nem feltétlenül része az eredeti jóváhagyásnak

Egy vállalat biztonsági és adatvédelmi szempontból megvizsgál egy AI-alapú megoldást. Meghatározzák, hogy mire használható, milyen adatokat dolgozhat fel, kik férhetnek hozzá, és milyen technikai, illetve szervezeti kontrollok szükségesek a működéséhez. A vizsgálat lezárul, a rendszer megkapja a szükséges jóváhagyásokat, és megkezdődik a használata.

Néhány hónappal később az üzleti terület (vagy egy társszervezet) felismeri, hogy ugyanez a rendszer egy további feladatra is alkalmas lehet. A szükséges módosítás viszonylag egyszerű: új adatforrást kapcsolnak hozzá, megváltoztatják a feldolgozási logikát, vagy egy új munkafolyamatba építik be.

Az új megoldás technikailag működik. Az eredeti rendszer már engedélyezett, a felhasználók hozzáférnek, a szükséges infrastruktúra rendelkezésre áll. Ezért az új felhasználási esetet nem kezelik új rendszerként, és nem indítanak új biztonsági felülvizsgálatot sem.

Csakhogy az új megoldás már nem feltétlenül az a rendszer, amelyet a vállalat korábban jóváhagyott.

Az eredeti alkalmazás például belső, általános dokumentumok összefoglalására kapott engedélyt. Az új változat már ügyféladatokat elemez, szerződéseket értékel vagy munkavállalói információkat dolgoz fel. Maga az AI-szolgáltatás nem változott, de a felhasználás célja, az adatköre és a kockázati profilja igen.

A probléma nem feltétlenül egy új, ismeretlen AI-eszköz megjelenése. Hanem az, hogy egy ismert és jóváhagyott rendszer képességeit a jóváhagyás keretein túl kezdik használni.

A jóváhagyás nem általános felhatalmazás

A vállalati rendszerek biztonsági jóváhagyása nem pusztán egy terméknévhez vagy technológiához kapcsolódik. A döntés meghatározott felhasználási környezetre vonatkozik.

A vizsgálat során a vállalat többek között azt mérlegelheti, hogy:

• milyen üzleti célból használják a rendszert;
• milyen adatokat dolgoz fel;
• honnan származnak ezek az adatok;
• mely felhasználók és szolgáltatások férnek hozzájuk;
• milyen külső rendszerekkel kommunikál;
• milyen adatmegőrzési, naplózási és hozzáférés-kezelési feltételek érvényesülnek;
• milyen következményekkel járhat egy hiba vagy jogosulatlan adatközlés.

Ezek a körülmények együtt határozzák meg a rendszer kockázatát.

Ha egy jóváhagyott alkalmazáshoz új adatforrást kapcsolnak, az eredeti kockázatértékelés már nem feltétlenül írja le megfelelően az új működést. Ugyanez igaz akkor is, ha a rendszer korábbi funkcióját egy másik üzleti folyamatban kezdik alkalmazni, vagy új felhasználói csoport számára teszik elérhetővé.

A rendszer neve és technológiai alapja változatlan maradhat. A biztonsági szempontból releváns körülmények azonban megváltozhatnak.

Ezért az eredeti jóváhagyást nem lehet automatikusan kiterjeszteni minden olyan felhasználási esetre, amely ugyanarra a technológiára épül.

A változás gyakran nem rendszerbevezetésként jelenik meg

A hagyományos vállalati működésben egy új alkalmazás beszerzése vagy bevezetése rendszerint jól felismerhető esemény. Projekt indul, követelmények készülnek, a biztonsági terület véleményezi a megoldást, majd megtörténik a bevezetés.

Egy már működő AI-rendszer új célra történő felhasználása egészen másképp nézhet ki.

Lehet, hogy egy fejlesztő egyszerűen hozzáad egy új adatforrást. Egy üzleti elemző új feladatot állít be. Egy automatizációs szakember egy meglévő AI-funkciót egy másik folyamatba illeszt. Egy belső alkalmazás új táblázatokhoz vagy adatbázisokhoz kap hozzáférést.

Ezek a módosítások technikailag kisebb jelentőségűnek tűnhetnek, miközben biztonsági szempontból lényeges változást jelentenek.

A vállalat így úgy vezethet be új adatfeldolgozási folyamatot, hogy közben nem érzékeli: valójában új felhasználási eset jött létre.

Ez a jelenség különösen veszélyes akkor, ha az eredeti rendszer már megbízhatónak számít a szervezetben. A korábbi jóváhagyás biztonságérzetet teremt, és a későbbi módosításokat is automatikusan elfogadhatónak tekinthetik.

Mitől válhat kockázatossá az új use case?

Tegyük fel, hogy egy vállalat egy AI-alapú dokumentumfeldolgozó rendszert kizárólag belső, nem bizalmas anyagok összefoglalására engedélyezett.

Később a pénzügyi terület ugyanazt a megoldást kezdi használni számlák és szerződések feldolgozására. A HR-osztály munkavállalói dokumentumokat szeretne elemezni vele, az ügyfélszolgálat pedig ügyféllevelezéseket kapcsol hozzá.

Ezek a felhasználási esetek nem pusztán új feladatokat jelentenek. Más adatvédelmi, üzleti titokkal kapcsolatos és hozzáférés-kezelési követelményeket is felvethetnek.

Az új adatforrás például olyan információkat tartalmazhat, amelyekhez az eredeti alkalmazás felhasználói nem férhetnének hozzá közvetlenül. Az AI-rendszer integrációja révén azonban ezek az információk összefoglalva vagy más formában elérhetővé válhatnak számukra.

Az is előfordulhat, hogy az új adatokat olyan szolgáltatás dolgozza fel, amelynek adatmegőrzési vagy feldolgozási feltételeit erre az adatkörre nem értékelték.

Egy másik esetben az AI kimenete már nem egyszerű tájékoztatásra szolgál, hanem döntést támogat egy üzleti folyamatban. Ezzel a tévedések lehetséges következményei is megváltozhatnak.

A lényeg, hogy az új use case kockázata nem feltétlenül az AI-modellből ered. Sokszor az új adatforrás, az új hozzáférés, az eltérő üzleti cél vagy a megváltozott felhasználási környezet hozza létre.

A rendszer engedélyezett, de a felhasználás már nem az

Ez a helyzet az ellenőrzés szempontjából is különleges.

Ha a vállalat csak azt vizsgálja, hogy az alkalmazott AI-szolgáltatás szerepel-e az engedélyezett rendszerek listáján, akkor az új felhasználási eset láthatatlan maradhat. A technológia megfelel a nyilvántartásnak, a hozzáférés működik, a rendszer pedig a korábbi jóváhagyás alapján megbízhatónak tűnik.

A tényleges működés azonban már eltérhet attól, amit a vállalat felülvizsgált.

Ezért két külön kérdést kell kezelni:

1. Engedélyezett-e maga a rendszer?
2. Engedélyezett-e a rendszer konkrét használata az adott célra, adatkörrel és integrációkkal?

A két kérdés nem helyettesíti egymást. Az elsőre adott igen nem jelenti automatikusan azt, hogy a másodikra is igen a válasz.

Ez a különbség nem kizárólag az AI-ra igaz. A vállalati rendszerek és adatintegrációk világában régóta ismert probléma, de az AI-eszközök gyors konfigurálhatósága, egyszerű integrálhatósága és sokoldalúsága különösen könnyen előidézheti.

Mit kellene kontrollálni?

A megoldás nem az, hogy minden apró konfigurációs változtatásból új, teljes körű rendszerbevezetési projektet kell létrehozni. Ez aránytalanul lassúvá tenné az üzleti működést, és arra ösztönözhetné a felhasználókat, hogy a hivatalos folyamatokon kívül keressenek megoldást.

Ehelyett olyan változáskezelésre van szükség, amely felismeri, ha egy módosítás érdemben megváltoztatja a rendszer kockázatát.

Ennek része lehet:

• A jóváhagyás hatókörének pontos rögzítése. Nem elegendő az alkalmazás nevét és tulajdonosát nyilvántartani. A jóváhagyásnak tartalmaznia kell az engedélyezett célokat, adatköröket, integrációkat és lényeges használati feltételeket is.
• A lényeges változások kötelező felülvizsgálata. Új adatkör, új adatforrás, új felhasználói csoport, új integráció vagy megváltozott döntési szerep esetén meg kell vizsgálni, hogy szükséges-e új jóváhagyás.
• A technikai változások láthatóvá tétele. Az adatkapcsolatok, jogosultságok, API-integrációk és konfigurációk változásainak naplózása segíthet felismerni, ha a rendszer túllépi az eredetileg meghatározott kereteket.
• A kockázathoz igazított ellenőrzés. Egy alacsony kockázatú változtatás egyszerűsített eljárással is jóváhagyható. Érzékeny adatok bevonása vagy új, kritikus üzleti funkció esetén viszont részletesebb vizsgálat indokolt.
• Egyértelmű felelősség. A rendszer üzleti tulajdonosának tudnia kell, milyen célra és milyen adatokkal használható a megoldás. Az új felhasználási eset kezdeményezőjének pedig jeleznie kell, ha a tervezett változtatás túlmutat az eredeti engedélyezésen.

A cél nem a változások megakadályozása, hanem az, hogy a lényeges változások ne maradjanak ellenőrizetlenek.

A valódi probléma az engedélyezés és a tényleges működés közötti rés

Egy vállalat rendelkezhet jól működő AI-szabályzattal, engedélyezett szolgáltatások listájával és részletes biztonsági felülvizsgálati eljárással, miközben a jóváhagyott rendszerek felhasználása fokozatosan túlnő az eredeti kereteken.

Ilyenkor nem feltétlenül a szabályozás hiányzik. Lehet, hogy a szervezet nem kezeli megfelelően a már jóváhagyott rendszerek életciklusa során bekövetkező változásokat.

A biztonsági felülvizsgálat ugyanis nem feltétlenül örök érvényű igazolás. Egy adott állapotra, meghatározott feltételek mellett születik. Ha ezek a feltételek lényegesen megváltoznak, a korábbi döntés érvényességét is újra kell értékelni.

Ez különösen fontos az AI esetében, ahol egy meglévő megoldás újrafelhasználása gyakran gyorsabb és egyszerűbb, mint egy teljesen új rendszer bevezetése. A technikai újrafelhasználás azonban nem jelent automatikus biztonsági jóváhagyást.

Összegzés

Az egyik legkönnyebben figyelmen kívül hagyható AI-biztonsági kockázat nem egy ismeretlen szolgáltatás megjelenése, hanem egy már engedélyezett rendszer észrevétlen továbbfejlesztése vagy új célra történő felhasználása.

A rendszer eredeti jóváhagyása meghatározott célra, adatkörre és működési feltételekre vonatkozott. Ha ezeket a kereteket valaki engedély nélkül kiterjeszti, a vállalat olyan adatfeldolgozást végezhet, amelyet valójában soha nem vizsgáltak meg.

Nem elég a rendszert jóváhagyni. Azt is kontrollálni kell, hogy a jóváhagyott rendszerből milyen új megoldásokat, adatkapcsolatokat és felhasználási eseteket hoznak létre.