Amikor egy AI csak válaszol, a legrosszabb, ami történhet, hogy rossz választ ad. Kellemetlen, néha költséges, de a hibát egy ember még elkaphatja, mielőtt bármi történik belőle. Egészen más a helyzet, amikor az AI nemcsak mond valamit, hanem tesz is. Elküld egy emailt, módosít egy rekordot az ügyfélrendszerben, elindít egy folyamatot, hozzányúl egy fájlhoz. Ilyenkor a rossz döntésből azonnal valódi következmény lesz, és nincs az az ember, aki minden egyes lépést előre átnézne. A hiba nem a képernyőn marad, hanem kilép a világba, és onnantól nem visszavonni kell, hanem kezelni a kárt, amit okozott.
Ezt a váltást nevezik AI ügynöknek. A különbség nem apró. Egy ügynök nem egy chat, amivel beszélgetünk, hanem egy szereplő, aki hozzáfér eszközökhöz, és önállóan használja őket egy cél érdekében. Épp ettől hasznos, mert leveszi a végrehajtás terhét. És épp ettől kockázatos, mert a keze elér olyan dolgokhoz, amiknek súlya van. Ahogy egyre több cég vág bele az ügynökök bevezetésébe, ez a kérdés a napi működés részévé válik.
A kapuőr a művelet előtt
A kutatás alapötlete egyszerű és józan. Ha az ügynök cselekedni készül, a művelet ne fusson le azonnal, hanem előbb menjen át egy ellenőrző ponton, ami megnézi, szabad-e. Ez a pont egy kapuőr, ami minden eszközhasználat előtt összeveti a tervezett műveletet a cég biztonsági szabályaival, és csak akkor engedi tovább, ha az megfelel. Ha a szabály tiltja, a művelet elbukik, mielőtt kárt okozna.
Ez a gondolat nem új az informatikában, a rendszereink tele vannak jogosultságokkal és ellenőrzésekkel. Az AI ügynöknél viszont van egy csavar, amit könnyű alábecsülni. A kapuőr döntése gyakran maga is egy bizonytalan ítéleten múlik. Vegyünk egy szabályt, ami tiltja, hogy az ügynök személyes adatot küldjön ki a cégen kívülre. Ehhez a kapuőrnek el kell döntenie, hogy egy adott szövegben van-e személyes adat, és ez a felismerés soha nem száz százalékos. Néha téved, néha átenged olyat, amit nem kellett volna.
Itt van a probléma lényege. Az ügynök viselkedését olyan ellenőrzésekkel akarjuk biztosítani, amelyek maguk sem tökéletesek. Ha úgy teszünk, mintha a kapuőr csalhatatlan lenne, hamis biztonságérzetbe ringatjuk magunkat. A kutatás éppen ezt a hamis biztonságot utasítja el.
Amikor az ellenőrzés maga is téved
A kutatás újdonsága, hogy nem tesz úgy, mintha az ellenőrzések hibátlanok volnának, hanem beépíti a hibázás esélyét a számításba. Ahelyett hogy azt mondaná, ez a művelet biztosan rendben van, azt mondja meg, mekkora legfeljebb az esélye annak, hogy egy szabály mégis sérül. Vagyis nem ígér tökéletességet, hanem megbízható felső korlátot ad a kockázatra.
Ennek a felső korlátnak két fontos tulajdonsága van. Az egyik, hogy megbízható abban az értelemben, hogy a valódi kockázatot soha nem becsüli alá. Inkább óvatos, mint hazug. Ha azt mondja, a szabálysértés esélye legfeljebb ennyi, akkor arra tényleg lehet építeni, mert a valóságban nem lehet rosszabb. A másik, hogy gyorsan kiszámolható, elég gyorsan ahhoz, hogy futás közben, minden művelet előtt le tudjon menni, ne csak utólag, elemzésként.
A módszer arra is figyel, hogy az egyes ellenőrzések hibái összefügghetnek. A rossz eset nem az, amikor egy ellenőrzés téved, hanem amikor több egyszerre, ugyanabba az irányba. A kutatás a legrosszabb együttállásra számol, vagyis nem a szerencsés esetet feltételezi, hanem a legkedvezőtlenebbet, és arra ad korlátot. Ez az óvatosság az, amitől a garancia komolyan vehető.
Miben más egy ügynök egy megszokott programnál
Sokan azt gondolják, hogy erre a problémára a bevett jogosultságkezelés úgyis megoldás, hiszen a rendszereinkben eddig is szabályoztuk, ki mit érhet el. A különbség viszont éppen az, amitől az ügynök más. Egy hagyományos program előre megírt lépéseket hajt végre, mindig ugyanúgy, ezért ki lehet tesztelni és fel lehet készülni rá. Az ügynök viszont menet közben találja ki, mit tesz, a helyzethez igazodva, és minden futásnál kicsit másképp.
Ettől lesz hasznos, mert rugalmasan reagál, de ettől lesz nehezebb is felügyelni. Nem lehet előre végigjátszani minden lehetséges lépését, mert a lépéseit ott és akkor hozza létre. Pont ezért nem elég egyszer beállítani a jogosultságokat és megnyugodni. Kell egy folyamatos kapu, ami minden konkrét művelet előtt, a maga valóságában nézi meg, szabad-e, nem pedig egy általános szabály, amit egyszer lefektettünk és utána bízunk benne.
Egy példa a gyakorlatból
Egy hazai pénzügyi szolgáltatónál dolgoztunk egy ügynök bevezetésén, aminek az volt a dolga, hogy ügyféllevelekre készítsen és küldjön válaszokat. A csábítás nagy volt, mert a levelezés nagy részét tényleg le tudta volna venni a csapatról. A kockázat viszont nyilvánvaló, mert egy ügyfélnek kiment levél nem vonható vissza, és ha rossz adat vagy más ügyfél adata kerül bele, az azonnal baj.
A megoldás nem az volt, hogy vakon rábíztuk, és nem is az, hogy elvetettük az egészet. Egy kaput tettünk a küldés elé. Az ügynök megírhatta a választ, de a levél nem ment el addig, amíg át nem ment az ellenőrzéseken. Az egyik nézte, tartalmaz-e olyan személyes adatot, aminek nem szabad kimennie, a másik azt, hogy a címzett tényleg az az ügyfél-e, akiről a levél szól. Ahol az ellenőrzés bizonytalan volt, ott a levél nem ment automatikusan, hanem emberhez került jóváhagyásra.
A lényeg, hogy tudtuk, mekkora a maradék kockázat. Nem azt mondtuk, hogy ez teljesen biztonságos, mert az nem lett volna igaz. Azt mondtuk, hogy a hibás kiküldés esélye egy megadott korlát alatt van, és ezt a korlátot a cég vezetése tudta mérlegelni. Ez egészen más beszélgetés, mint a szokásos, ahol vagy vakon bíznak a rendszerben, vagy alaptalanul félnek tőle.
A bizalom lépésről lépésre
Van ennek a gondolatnak egy tágabb kerete is, amit a nagy AI laborok is hangoztatnak. Érdemes az AI ügynökre úgy tekinteni, mint egy új munkatársra, aki még nem bizonyított. Egy új kollégának sem adjuk oda az első napon minden rendszer kulcsát. Előbb kap egy szűk jogkört, figyeljük, hogyan dolgozik, és ahogy bizalmat épít, úgy kap egyre több hozzáférést. Az ügynöknél ugyanez a helyes út.
A gyakorlatban ez azt jelenti, hogy egy ügynök ne kezdje azzal, hogy mindenhez hozzáfér és bármit megtehet. Kezdje szűken, kevés jogosultsággal, sok kapuval, és a hatókörét csak akkor tágítsuk, ha a viselkedése ezt megérdemli. Ez a fokozatos bizalom sokkal biztonságosabb, mint az az elterjedt gyakorlat, hogy izgalmában a cég egyből mindent rábíz az új ügynökre, aztán reménykedik, hogy nem lesz baj.
Ennek a fokozatosságnak van egy kellemes mellékhatása is. Amíg az ügynök szűk körben dolgozik, a csapatnak van ideje megtanulni, mire számíthat tőle, hol szokott tévedni, és mikor kell résen lenni. Mire a hatóköre kitágul, addigra már ismerik a szokásait, és sokkal jobban meg tudják ítélni, mit bízhatnak rá nyugodtan. A bizalom így nem vakon nő, hanem tapasztalatból, és ez az, ami valódi biztonságot ad, nem a papíron lefektetett szabály.
Ami ezt az egészet összeköti, az egy szemléleti váltás. A cselekvő AI-nál a kérdés már nem az, hogy jó választ ad-e, hanem az, hogy szabad-e neki megtennie, amit tenni készül, és mekkora az esélye, hogy hibázik. Aki a válaszoló AI logikájával közelít egy cselekvő ügynökhöz, az a legfontosabb kockázatot nézi el. A kapu, a mérhető maradék kockázat és a fokozatos bizalom nem lassítja a bevezetést, hanem az teszi egyáltalán felelősen vállalhatóvá.
Melyik művelet elé kell kapu
Nem minden művelet elé kell kaput tenni, mert az lassítaná a rendszert, és fölöslegesen bonyolítaná. A kapu ott indokolt, ahol a tévedésnek valódi ára van. Három ismérv szinte mindig jelzi ezt. Az első a visszafordíthatatlanság, vagyis ha a művelet nem vonható vissza, mint egy elküldött levél vagy egy törölt adat. A második a kifelé irányulás, amikor a művelet elhagyja a céget, és ügyfélhez, hatósághoz vagy partnerhez jut. A harmadik az érzékeny adat érintettsége, amikor a művelet személyes vagy bizalmas információval dolgozik.
Ahol ezek közül egy is teljesül, ott a kapu megéri a ráfordítást. Ahol egyik sem, ott az ügynök nyugodtan dolgozhat szabadon, mert a hibája olcsó és javítható. Ez a megkülönböztetés önmagában rendet tesz a bevezetésben, mert kijelöli, hova kell a figyelem és a kontroll, és hol lehet elengedni. A legtöbb rosszul sikerült ügynök bevezetésnél pont ez a szűrés hiányzik, és vagy mindent szabadon engednek, vagy mindent lelassítanak. Egy jó szűrés viszont pár óra munka, és utána a rendszer ott kap kontrollt, ahol tényleg számít, máshol pedig gyors marad.
Amit egy vezető ebből átvehet
A kutatás matematikája mélyen technikai, de az üzenete egyszerű, és most kezd igazán aktuálissá válni, ahogy egyre több cég lép a beszélő AI-tól a cselekvő felé. Mielőtt egy ügynök bármit megtehet, ami visszafordíthatatlan vagy ügyfelet érint, legyen a művelet előtt egy kapu, ami ellenőriz. Az ellenőrzésről pedig ne feltételezzük, hogy tökéletes, hanem tudjuk meg, mekkora a hibázás esélye, és döntsünk annak tudatában.
Ez a szemlélet illeszkedik ahhoz, amit az AI felügyeletéről általában is gondolok. Nem attól lesz biztonságos egy rendszer, hogy hibátlannak hisszük, hanem attól, hogy ismerjük a gyenge pontjait, kapukat teszünk a veszélyes helyekre, és a bizalmat kiérdemelni hagyjuk, nem előlegezzük. A cselekvő AI hatalmas lehetőség, de csak azoknak, akik előbb rakják le a kapukat, és utána engedik el a kezét. Aki fordítva csinálja, előbb enged, aztán kap észbe, az a saját rendszerén tanulja meg, mekkora a különbség a beszélő és a cselekvő AI között, és ez a lecke általában drága.
kdconsulting.hu · [email protected]