Az AI következő (jelenlegi) hulláma már nem csak válaszol, hanem cselekszik. Az AI agentek (önállóan, több lépésben feladatot végrehajtó mesterséges intelligencia rendszerek) jegyet nyitnak az ügyfélszolgálati rendszerben, e-mailt küldenek, adatot módosítanak, visszatérítést vagy megrendelést indítanak. Az AI agent tesztelés ezért egészen más kérdést tesz fel, mint egy chatbot ellenőrzése: nem azt, hogy jó-e a válasz, hanem azt, hogy helyes-e a tett.

A különbség üzletileg is éles. Egy chatbot rossz válasza kellemetlen, de az ügyfél még mérlegelheti. Egy agent rossz döntése viszont már megtörtént esemény: elküldött levél, jóváírt összeg, felülírt ügyféladat. A vezetők jó része mégis ugyanazzal a mércével méri az agentet, mint egy csevegőfelületet: kipróbál néhány kérdést, és ha a válaszok meggyőzőek, a rendszer mehet élesbe. Egy cselekvő rendszernél ez a mérce nem elég.

Ez a cikk nem az LLM alapú rendszerek általános tesztelési sajátosságairól szól (hallucináció, valószínűségi működés), ezekről az AI rendszerek tesztelése: miért teljesen más, mint egy hagyományos szoftveré? cikkünkben írtunk. Itt azt vizsgáljuk, mi változik akkor, amikor az AI már önállóan dönt és végrehajt.

Mitől más egy agent, mint egy chatbot?

Egy chatbot egy kérdésre egy választ ad. Egy agent egy célt kap, és maga dönti el, milyen lépésekben éri el. Ehhez eszközöket használ: belső rendszerek programozói felületeit (API), adatbázisokat, levelezést, böngészőt. Megtervezi a lépéseket, a részeredményekből újabb döntést hoz, és ha valami nem sikerül, másik úton próbálkozik.

Ebből következik a tesztelés legfontosabb változása: a tesztelendő egység már nem egy kérdés-válasz pár, hanem egy teljes munkafolyamat. Képzeljünk el egy ügyfélszolgálati agentet, amely egy reklamáció alapján ellenőrzi a rendelést, megnézi a szállítási státuszt, és ha jogosnak ítéli a panaszt, visszatérítést indít. Egy ilyen folyamatban öt-hat döntési pont is van, és bármelyiken elcsúszhat úgy, hogy a végén udvarias, meggyőző visszaigazolás születik.

Új hibatípusok, amelyekre a hagyományos teszt nem készít fel

Az agentek hibái ritkán látványosak. Jellemzően ezekkel kell számolni:

• Rossz eszköz vagy rossz paraméter. Az agent gondolatmenete helyes, de rossz rendelésre vagy rossz összeggel indítja a visszatérítést. A logika jó, a végrehajtás mégis kárt okoz.
• Túlzott cselekvési jogkör. Az OWASP (a nemzetközi alkalmazásbiztonsági közösség) nagy nyelvi modellekre vonatkozó kockázati listája külön tételként kezeli ezt (Excessive Agency): amikor egy AI komponens a szükségesnél több funkcióhoz, jogosultsághoz vagy önállósághoz jut. Ilyenkor egy félreértett vagy manipulált utasítás valódi károkozássá válhat.
• Láncolt hibák. Egy korai tévedés a következő lépések bemenete lesz, és lépésről lépésre felnagyítódik. A végeredményből sokszor már nem is látszik, hol csúszott el a folyamat.
• Elakadás és költségelszállás. Az agent újra és újra próbálkozik egy sikertelen lépéssel, közben pedig hívásokat és használati díjat termel.
• Manipulálhatóság. Az agent által feldolgozott tartalomba (e-mail, weboldal, dokumentum) rejtett utasítás eltérítheti a működését. Ez az utasításmanipuláció (prompt injection) önálló biztonsági téma. Itt annyi a lényeg, hogy egy agentnél a manipuláció nem rossz válaszhoz, hanem rossz tetthez vezet.

Az amerikai szabványügyi intézet (NIST) a mesterséges intelligencia elleni támadásokat rendszerező 2025-ös kiadványában már külön foglalkozik az AI agentek biztonságával. Ez jól jelzi, hogy nem elméleti kockázatról van szó.

Mit tesztelünk: eredményt, útvonalat és mellékhatást

Egy agent ellenőrzése három kérdésre bontható:

• Végeredmény: elérte-e a célt, és helyes-e, amit létrehozott.
• Döntési útvonal: milyen lépéseken és eszközökön keresztül jutott el oda, és elfogadható-e ez az útvonal. Egy helyes végeredmény is lehet szerencse műve, ha közben az agent olyan adatot kért le, amihez nem kellett volna hozzányúlnia.
• Mellékhatások: mit változtatott meg a környező rendszerekben, amit nem kellett volna.

A gyakorlatban ehhez három dolog kell.

Az első az izolált tesztkörnyezet. Az agent eszközeit szimuláljuk (API mock, sandbox, azaz elzárt próbakörnyezet), hogy a teszt ne mozgasson valós pénzt, ne küldjön éles e-mailt és ne módosítson éles adatot. A szimulált eszközök ráadásul rögzítik, mit próbált tenni az agent, így a mellékhatás nemcsak elkerülhetővé, hanem mérhetővé is válik.

A második a forgatókönyv-készlet: reprezentatív feladatok, határesetek és szándékosan félrevezető bemenetek. Mivel az agent viselkedése nem determinisztikus, ugyanazt a forgatókönyvet többször kell lefuttatni. Egyetlen sikeres futás nem bizonyíték. A kérdés az, hogy száz futásból hányszor jár el helyesen.

A harmadik az automatizált kiértékelés. Több ezer döntési útvonalat nem lehet kézzel átnézni. Elterjedt megoldás, hogy egy másik nyelvi modell előre rögzített szempontok szerint pontozza az útvonalakat (LLM-as-a-judge), az ember pedig a kétes eseteket és egy véletlenszerű mintát ellenőrzi. Ennek is van korlátja: az értékelő modellt emberi mintavétellel rendszeresen kalibrálni kell, különben a saját tévedéseit hitelesíti.

Kontroll: amit tesztelni kell, és amit tervezni kell

Egy agent biztonsága nemcsak a modell minőségén múlik, hanem a köré épített kereteken is. Ezek egy része tervezési döntés, de mindegyik megléte tesztelendő követelmény:

• Legkisebb szükséges jogosultság. Az agent csak azokhoz az eszközökhöz és adatokhoz férjen hozzá, amelyek a feladatához kellenek. Az OWASP ajánlása szerint a jogosultságot a kiszolgáló rendszereknek kell ellenőrizniük, és nem a nyelvi modellre kell bízni, hogy mit szabad.
• Emberi jóváhagyás. A visszafordíthatatlan vagy magas kockázatú lépések (kifizetés, adattörlés, külső levél) előtt ember erősítse meg a műveletet.
• Vészfék. Automatikus leállás, ha az agent túllép egy lépésszámot, költségkeretet vagy hibaarányt, illetve ha szokatlan műveletbe kezd (circuit breaker). Nem elég, hogy létezik: tesztelni kell, hogy a megfelelő pillanatban valóban kiold-e.
• Naplózás és visszakövethetőség. Utólag is meg kell tudni mondani, mit, miért és milyen adatok alapján tett az agent. Egy vitás ügyfélpanasznál vagy egy auditnál ez lesz az egyetlen bizonyíték.
• Visszaállíthatóság. Ahol lehet, a végrehajtott műveletek legyenek visszavonhatók.

Érdemes a jogkört fokozatosan bővíteni. Az első szakaszban az agent csak javaslatot tesz, és ember hajtja végre a műveletet. Ilyenkor éles adatokon, kockázat nélkül mérhető, milyen arányban javasolta volna a helyes lépést. Ha az eredmények meggyőzőek, következhet a szűkített, alacsony értékhatárhoz kötött önálló működés, és csak ezután a teljes jogkör.

Összegzés

Az AI agent nem okosabb chatbot, hanem új kockázati kategória: cselekvő rendszer, amelynek a döntéseit, az útvonalát és a mellékhatásait is ellenőrizni kell. Az AI agent tesztelés ezért izolált környezetet, ismételt futtatást, emberrel kalibrált automatizált kiértékelést, valamint tesztelt kontrollmechanizmusokat igényel.

A vezetői kérdés ennek megfelelően nem az, hogy jól válaszol-e az agent. Hanem az, hogy mielőtt éles jogosultságot kap, tudjuk-e bizonyítani: mit tehet, mit nem tehet, és mi történik, ha téved?

Források

OWASP: Top 10 for LLM Applications 2025, LLM06 Excessive Agency (2025), a túlzott cselekvési jogkör mint kockázat és a jogosultságkezelési ajánlások. Elérhető: genai.owasp.org

NIST: AI 100-2 E2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations (2025), az AI agentek biztonsága mint önálló támadási terület. Elérhető: nist.gov