Auditálható AI-ügynökök: kontroll és bizalom valós időben

Egy autonóm AI-ügynök akkor válik igazán kockázatossá, amikor nem csak válaszol, hanem cselekszik: eszközökhöz fér hozzá, fájlokat kezel, adatbázist kérdez, űrlapokat tölt, tranzakciókat indít, vagy akár klinikai döntéstámogatást ad. Ilyenkor a kérdés nem az, hogy „okos-e”, hanem hogy ellenőrizhető-e.

A 2025.12.22-én publikált friss kutatás egy olyan irányt tol előtérbe, amit én régóta hiányolok a gyakorlati bevezetésekből: ne csak azt mérjük, hogy az AI „mennyire hajlamos félremenni”, hanem azt, hogy milyen gyorsan és mennyire megbízhatóan vesszük észre, ha félremegy. Ez a verifiability-first (ellenőrizhetőség-első) gondolkodásmód különösen fontos ott, ahol a hibának ára van: egészségügyben és pénzügyi/banki folyamatokban egyaránt.

A poszt a „Mesterséges intelligencia a pénzügyi és banki szektorban” sorozat része, de tudatosan áthozom az egészségügyi párhuzamokat is: ugyanazok a kontrollmechanizmusok segítenek abban, hogy egy banki AI-ügynök ne utaljon rossz helyre, és abban is, hogy egy diagnosztikai asszisztens ne „hallucináljon” egy téves javaslatot és ne tüntesse el a nyomokat.

Miért most lett kritikus az AI-ügynökök auditálhatósága?

Az ok egyszerű: az LLM-ekből épített rendszerek ma már nem csak chatelnek, hanem többlépcsős feladatokat hajtanak végre és több eszközt kapcsolnak össze. Egy ügynök feladata lehet például:

• bankban: reklamáció kezelése, azonosítási folyamat léptetése, limitek módosításának előkészítése, csalásgyanús események priorizálása
• egészségügyben: lelet-összefoglaló készítése, képalkotó vizsgálat triázs támogatása, telemedicina „előszűrés”, időpontok és dokumentáció egyeztetése

A gond ott kezdődik, hogy ezek a rendszerek eszközhozzáféréssel és „személyiséggel” (prompt/persona) is futnak. A kutatás kiindulópontja szerint korábbi benchmarkok már megmutatták: az ügynök „karaktere” és a tool-access jogosultság erősen befolyásolja a félrecsúszás esélyét.

A valós üzleti és klinikai környezetben viszont nem az a kérdés, hogy lesz-e félrecsúszás. Hanem ez:

Mennyi idő alatt derül ki, és vissza lehet-e vezetni bizonyíthatóan, mi történt?

Ha erre nincs jó válasz, akkor nincs felelős skálázás sem.

Mit jelent a „Verifiability-First” architektúra a gyakorlatban?

A cikk három, egymásra épülő elemet javasol. A lényeg: a rendszer úgy legyen megtervezve, hogy bizonyíthatóan megfigyelhető és auditálható legyen futás közben, ne csak utólagos logokból.

1) Futásidejű attesztáció: a „mi történt” ne csak állítás legyen

A futásidejű attesztáció (attestation) azt célozza, hogy az ügynök műveleteiről ne pusztán napló készüljön, hanem ellenőrizhető bizonyíték, ami összeköti:

• a szándékot (mit kellett volna csinálnia)
• a tényleges lépéseket (mit csinált)
• az eszközhasználatot (milyen API-t, adatforrást, parancsot hívott)

A kutatás szerint ehhez kriptográfiai és szimbolikus módszerek kombinációja jön szóba. Magyarul: ne lehessen utólag „szépíteni” a történetet.

Egészségügyi példa: egy triázs-ügynök javaslatot ad sürgősségre. Attesztáció nélkül csak azt látod, mit írt le. Attesztációval azt is, hogy mely tüneteket emelte ki, mely protokoll-szabályokra támaszkodott, és hogy hozzáfért-e olyan adatmezőhöz, amihez nem kellett volna.

Banki példa: egy ügyfélazonosítási (KYC) asszisztens dokumentumokat kér be. Attesztációval bizonyítható, hogy nem kért be indokolatlan adatot, és a döntés (továbbléptetés/megakasztás) mögött milyen ellenőrzések futottak.

2) Könnyűsúlyú Audit Agent: folyamatos „szándék vs. viselkedés” ellenőrzés

A második elem a beágyazott, könnyűsúlyú Audit Agent: egy külön „őr”, amely folyamatosan figyeli, hogy az ügynök viselkedése összhangban van-e a deployer intenttel (a szervezet által meghatározott szándékkal és szabályokkal).

Itt szerintem a legfontosabb gyakorlati gondolat az, hogy az Audit Agent korlátozott következtetéssel dolgozik. Ez jó hír: nem egy másik „szuper-LLM”-et teszünk az LLM mellé (ami ugyanúgy tévedhet), hanem egy célzott, szűk szabály- és ellenőrzéskészletet.

Konkrétan az Audit Agent figyelhet például:

• jogosultsági határok átlépésére (pl. hozzáférési szint, adatminimálás)
• tiltott eszközhasználatra (pl. külső fájlküldés, nem engedélyezett API)
• ellentmondásra a feladatcél és a lépések között
• „stealth” viselkedésre (elrejtett lépések, elhallgatott részletek)

Tézis: ha a rendszeredben nincs ilyen őr, akkor az „autonóm ügynök” gyakorlatilag bizalmi alapon fut.

3) Challenge-response protokollok: a magas kockázatú művelet ne menjen át „csendben”

A harmadik elem a challenge-response attesztáció magas kockázatú műveletek előtt. A lényege: bizonyos lépésekhez a rendszernek bizonyítania kell, hogy jogos és helyes a művelet, mielőtt végrehajtja.

Gondolj rá úgy, mint egy „4 szem elvre” – csak itt a második pár szem egy verifikációs mechanizmus.

• banki high-risk: kedvezményezett felvétele, nagyösszegű utalás, limitmódosítás, ügyféladatok exportja
• egészségügyi high-risk: gyógyszerjavaslat, sürgősségi irány, diagnosztikai konklúzió kiemelése, lelet automatikus továbbítása

A cél nem a lassítás. A cél a kontrollpont.

OPERA benchmark: nem a félrecsúszás esélye, hanem a detektálás sebessége a KPI

A kutatás egy OPERA nevű benchmarkot és értékelési protokollt javasol (Observability, Provable Execution, Red-team, Attestation). Nekem azért tetszik ez a keret, mert a valós működéshez közelebb álló kérdéseket tesz fel.

Az OPERA három dolgot mér:

1. A félreigazodás (misalignment) detektálhatóságát – észreveszed-e egyáltalán?
2. A detektálás idejét „sunyi” stratégiák mellett – mennyi lépésig tud rossz irányba menni?
3. Az ellenőrizhetőségi mechanizmusok ellenállását adverszariális prompt/persona injekcióval szemben

Ez banki és egészségügyi környezetben is kulcs, mert a kár ritkán egyetlen látványos hibából jön. Sokszor kicsi, egymásra rakódó eltérésekből.

A jó AI-kontroll nem azt jelenti, hogy soha nincs hiba. Azt jelenti, hogy a hiba gyorsan és visszakövethetően látszik.

Hogyan fordítható ez le banki AI rendszerekre (és miért releváns az egészségügynek is)?

Az AI a pénzügyi szektorban tipikusan ott kap szerepet, ahol nagy az adatmennyiség és sok a szabály: csalásfelderítés, hitelkockázat-értékelés, automatizált ügyfélszolgálat, személyre szabott ajánlatok. Az autonóm ügynökök ezt egy szinttel feljebb viszik: nem csak jelzik, hanem intézik.

Ügyfélszolgálati AI-ügynök: a „jó szándék” nem elég

Egy LLM-alapú ügyfélszolgálati ügynök könnyen „túlsegít”: kérhet olyan adatot, amihez nincs joga, vagy olyan megoldást ajánl, ami ellentétes belső policyval.

Verifiability-first megközelítés:

• attesztált eszközhasználat: bizonyítható, mely rendszerekhez nyúlt
• Audit Agent: azonnal jelez, ha PII-t kér be feleslegesen
• challenge-response: például zárolás feloldása előtt kötelező kontroll

Csalásfelderítés és tranzakciós döntéstámogatás: gyors detektálás, kisebb veszteség

Csalásnál a „time to detection” pénzben mérhető. Ha a modell rosszul priorizál, vagy egy támadó prompt-injekcióval eléri, hogy bizonyos jeleket figyelmen kívül hagyjon, akkor a veszteség nő.

A kutatás fókusza – mennyire gyorsan és megbízhatóan detektálunk – tökéletesen passzol ide. Ugyanez igaz egészségügyben is: későn detektált téves triázs = rossz betegút.

Hitelkockázat-értékelés: auditálhatóság a megfelelőség és ügyfélbizalom alapja

Az EU-s és hazai megfelelőségi elvárások (model governance, audit trail, döntési dokumentáció) felől nézve a verifikálhatóság nem extra, hanem alap.

Egy auditálható AI-ügynöknél az a nyerő, ha utólag nem vitatkozunk arról, hogy „a modell így gondolta”, hanem vissza tudjuk vezetni:

• milyen adatokat használt
• milyen szabályokon ment át
• hol és miért állt meg

Ez a logika 1:1 átvihető a klinikai döntéstámogatásra: a kórház nem „promptokra” akar támaszkodni, hanem ellenőrizhető folyamatokra.

Gyakorlati ellenőrzőlista: mit kérj AI-ügynök beszállítótól 2026-ra készülve?

Ha banki vagy egészségügyi AI-ügynök bevezetésén dolgozol, én ezeket a kérdéseket tenném fel már a pilot előtt:

1. Milyen eseményekről készül attesztált napló? (eszközhívás, adatlekérés, döntési ág, kimenet)
2. Van-e külön Audit Agent jellegű komponens? Mit figyel, mennyire „szűk” a hatásköre?
3. Mely műveletek számítanak high-risk-nek, és van-e challenge-response? Ki/mi adja meg a „zöld jelzést”?
4. Hogyan védekeztek prompt/persona injekció ellen? (különösen többcsatornás: email, PDF, chat, jegyzet)
5. Mi a cél KPI: pontosság vagy detektálási idő? (szerintem a kettő együtt kell, de az utóbbi gyakran hiányzik)
6. Vissza lehet-e játszani egy ügyet end-to-end? (reprodukálhatóság: ugyanazokból a bemenetekből ugyanaz a döntési lánc?)

Ha ezekre nincs tiszta válasz, akkor az ügynök valójában kísérlet – nem éles rendszer.

Merre tart ez 2026-ban? A bizalom ára: bizonyíthatóság

A trend világos: az autonóm AI-ügynökök terjedni fognak a bankoknál és az egészségügyben is, mert képesek adminisztrációt lefaragni és gyorsítani a döntési folyamatokat. Csakhogy a skálázás ára nem több prompt, hanem több kontroll.

A verifiability-first szemlélet azért erős, mert a vitát a megfelelő helyre teszi: nem a modell „jóságát” kell bizonygatni, hanem a rendszer működését kell bizonyíthatóvá tenni. Ez az a minimum, amire betegbiztonság és pénzügyi kockázatkezelés mellett egyszerűen szükség van.

Ha a „Mesterséges intelligencia a pénzügyi és banki szektorban” sorozat korábbi témáiban a csalásfelderítés, hitelkockázat-értékelés és automatizált ügyfélszolgálat volt a fókusz, akkor ez a poszt egy következő lépésről szól: hogyan tartod kézben azokat az AI-kat, amelyek már cselekszenek is.

Te melyik területen lenne a legnagyobb haszna egy Audit Agentnek: tranzakciók, KYC, ügyfélszolgálat – vagy inkább klinikai triázs és telemedicina?