Az AI ügynököt ma már tényleg „egy délután” összerakni — a gond az, hogy utána gyakran senki sem tudja pontosan, mit csinált, miért csinálta, és hogyan lehet visszacsinálni.

Mi történt

A ZDNet a Rubrik ZeroLabs frissen publikált felmérésére hivatkozva azt írja: az IT-menedzsereknek csak 23%-a mondja azt, hogy „teljes” kontrollja van a szervezetében futó AI ügynökök felett. A kép nem csak a kontrollérzetről szól: a válaszadók 81%-a szerint az ügynökök több kézi auditálást és monitorozást igényelnek, mint amennyi időt eredetileg meg kellett volna spórolniuk.

A jelentés egyik gyakorlati oka a „shadow AI” jelenség: az ügynökök felpörgetése egyszerű, ezért a felhasználók és csapatok sokszor kikerülik a vállalati védelmi rétegeket (a cikk példája szerint akár VPN kikapcsolásával), hogy gyorsan beüzemeljenek egy asszisztenst. Ennek eredménye: nem jóváhagyott belső megoldások és szállítói (vendor) ügynökök nagy mennyiségben.

A Microsoft egyik termékmenedzsere, Kriti Faujdar szerint az egész kísértetiesen emlékeztet a korai felhőbevezetés korszakára: csapatok különböző keretrendszerekkel és beszállítókkal, egymástól függetlenül építkeznek, ami széttöredezett működéshez, következetlen irányításhoz (governance) és rejtett biztonsági résekhez vezet.

A felmérés további számai is azt sugallják, hogy a tempó és a védelem nincs egyensúlyban: a menedzserek 86%-a arra számít, hogy az ügynökök terjedése megelőzi a biztonsági korlátokat a következő egy évben, és 52% szerint ez már fél éven belül bekövetkezhet. A cikk szerint ráadásul a válaszadók szinte mindegyike jelzi, hogy hiányoznak az úgynevezett „undo” képességek — vagyis az a lehetőség, hogy egy nem várt ügynöki lépést vissza lehessen görgetni.

Miért fontos

Az „AI ügynök” itt nem egy sima chatbot. Gondolj rá úgy, mint egy digitális gyakornokra, aki API-hozzáféréssel (vagyis gép-gép kapcsolatokon keresztüli jogosultsággal) eszközöket használ, adatokat ér el, és lépések láncolatát hajtja végre önállóan. Ezért kockázatosabb lehet, mint a hagyományos szoftver: nem csak válaszol, hanem csinál is dolgokat a rendszereidben.

A biztonság és megfelelőség szempontjából a legnagyobb rés nem feltétlenül az, hogy „hibázik-e” az ügynök, hanem hogy látható-e, mi történt. Ha nincs nyomkövetés és audit, akkor nem tudsz megbízhatóan válaszolni olyan alapvető kérdésekre, mint hogy mely adatokat érintette, milyen jogosultságokkal dolgozott, és hogyan lehet egy rossz lépést reprodukálni vagy visszafordítani. Ez a fajta bizonytalanság könnyen megeszi az ígért produktivitást — ahogy a felmérésben szereplő extra kézi ellenőrzés is jelzi.

A cikk egy másik, kevésbé látványos, de fontos problémát is kiemel: a modellek „driftje”. Ez azt jelenti, hogy ugyanaz az ügynök (mert a mögötte lévő alapmodell idővel változik) Q1-ben máshogy viselkedhet, mint Q3-ban, anélkül, hogy te bármit átállítottál volna. Olyan ez, mintha egy korábban átadott folyamatleírás szövege és értelme észrevétlenül módosulna a kezedben — a governance-nek pedig úgy kell működnie, hogy „mozog a talaj”.

Mire figyelj

  1. Ügynökinventár és jogosultságok: tudod-e egy listában megmondani, hány ügynök fut, ki hozta létre, és pontosan milyen rendszerekhez férnek hozzá? A cikkben idézett szakértők szerint nagyvállalatban gyorsan kialakulhat több száz, átfedő jogosultságú ügynök „közös identitásmodell” nélkül.
  2. Megfigyelhetőség (observability) és telemetria: van-e technikai nyoma az ügynöki lépések láncolatának? A ZeroLabs által felsorolt utólagos kérdések (trace, ok-okozat, érintett adatok/eszközök, siker és költség, reprodukálható hibák) jó minimum-listának tűnnek ahhoz, hogy ne csak fussanak az ügynökök, hanem számon is kérhetők legyenek.
  3. „Undo” és visszagörgetés: ha az ügynök hibásan módosít valamit (adat, jogosultság, workflow), van-e szervezeti és technikai mechanizmus a károk csökkentésére? Enélkül az autonómia ára gyakran a kockázat.
  4. Sebesség vs. governance döntések: Faujdar szerint a nyertesek azok lesznek, akik az ügynökmenedzsmentet „első osztályú diszciplínaként” kezelik, nem utólagos toldásként. Érdemes figyelni, hogy a szervezetben ki a felelős ezért: csak IT, vagy biztonság és architektúra is be van vonva.
  5. Szállítói lock-in kockázat a stackben: Nik Kale arra figyelmeztet, hogy érdemes különválasztani az orchestration réteget (ami az ügynök lépéseit szervezi), a modellt és a governance-t. Ha mindhárom egyetlen vendor platformján ül, akkor „egy szerződésben” adod át az ügynök „agyát”, jogosultságait és az elszámoltathatóság láncát.