Amikor AI-ügynökre bízol egy feladatot, a legtöbben azt kérdezik: „meg tudja-e csinálni?” Ez ma már ritkán a szűk keresztmetszet — a legtöbb modern AI-modell meg tudja csinálni. A valódi, minden lépésnél megismétlődő kérdés ez: szabad-e neki magától döntenie, hogy megcsinálja-e — vagy előtte meg kell állnia, és vissza kell kérdeznie?
Ez a cikk azt írja le, hogyan dől el nálam ez a kérdés, mert ez a döntés az, ami a legtöbb AI-bevezetésnél vagy egyáltalán nincs kimondva, vagy rosszul van meghúzva — vagy mindenben megkérdezik az embert (és akkor minek az automatizáció), vagy semmiben (és akkor egy hiba visszavonhatatlanná válhat, mielőtt észreveszed).
A fő elv: a döntéshozó soha nem hajt végre
A saját rendszeremben van egy réteg, aminek egyetlen, szigorúan betartott szabálya, hogy soha nem végez munkát saját kézzel. Nem olvas fájlt közvetlenül, nem ír, nem futtat parancsot, nem küld ki emailt. Minden konkrét munkát egy szűkebb jogosultságú, specializált végrehajtóra bíz, egy pontosan körülhatárolt feladattal.
Ez elsőre bürokratikus formalitásnak tűnhet — miért ne csinálhatná meg a döntéshozó is közvetlenül, ha úgyis ő szervezi az egészet? A válasz: mert ez a szétválasztás egy biztonsági határ, nem szervezési kényelem. Ha a döntéshozó soha nem hajt végre semmit közvetlenül, akkor minden egyes tényleges műveletnek van egy külön, azonosítható felelőse, egy külön naplózási pontja, és — ez a lényeg — egy külön hely, ahol meg lehet állítani, mielőtt megtörténik. Ha a döntéshozó maga is végrehajtana, ez a megállási pont eltűnne, mert a „döntés” és a „végrehajtás” ugyanabban a pillanatban történne.
A kapu: amikor a döntés nem elég, ellenőrzés is kell
Van egy második réteg, ami a legkockázatosabb lépéseknél lép működésbe: egy előzetes, független ellenőrzés, ami PASS vagy BLOCK verdiktet ad, mielőtt a tervezett lépés egyáltalán elindulhatna. Ha BLOCK a verdikt, a kérést újra kell fogalmazni — és ha ez háromszor egymás után sem sikerül, a döntés visszakerül emberi kézbe. Nem lehet a folyamatot a végtelenségig újrapróbálgatni, remélve, hogy az ellenőrzés majd egyszer átenged valamit, ami nem stimmel.
A kulcskérdés az, hogy mikor kötelező ez a kapu, és mikor nem. Ha minden egyes lépésnél lefuttatnád, agyonlassítanád a rendszert, és a gyakorlatban senki nem venné komolyan — ez pontosan megtörtént egy korábbi verzióban, ahol egy idő után a kapu-ellenőrzés puszta formalitássá vált, mert túl sokszor futott le triviális esetekre is. A megoldás a szelektivitás: csak azoknál a lépéseknél kötelező a kapu, amik visszavonhatatlanok, külső felet (ügyfelet, publikus felületet) érintenek, vagy pénzügyi/jogi vonzatuk van. Minden más esetben a döntéshozó saját belátása szerint dönthet, hogy egyáltalán szükség van-e rá — és ha nem futtatja le, ez maga is naplózott döntés, nem hallgatólagos kihagyás.
Három kérdés, amivel eldöntheted, mi menjen kapun át
Ha most próbálod meghúzni ezt a határt a saját rendszeredben, három kérdést érdemes feltenni minden egyes autonóm műveletre:
- Vissza tudod-e vonni egy kattintással, ha rosszul sült el? Ha egy email már kiment, egy weboldal élesítve van, vagy egy fájl felülíródott biztonsági mentés nélkül — az nem vonható vissza egyszerűen. Ha igen a válasz, kapu kell.
- Lát-e egy külső fél hamarabb egy hibát, mint te magad? Egy ügyfélnek kiküldött üzenet, egy publikusan látható tartalom — ezeknél a hiba nem nálad landol először, hanem ott, ahol a legrosszabb: egy ügyfélnél vagy a nyilvánosság előtt.
- Van-e pénzügyi vagy jogi vonzata? Egy árajánlat, egy szerződéses elem, egy fizetési utalás — ezeknél a hiba ára nem csak kellemetlenség, hanem konkrét kár.
Ha bármelyik kérdésre igen a válasz, az adott lépés a „mindig kapun át” kategóriába kerül nálam. Minden más — belső fájlszervezés, piszkozat-készítés, elemzés — szabadon futhat, mert a hiba ára alacsony, és gyorsan javítható.
A szám, ami mutatja az arányt
Jelenleg körülbelül 130 explicit szabály fut a rendszeremben, és ebből mindössze 29 esik a „kritikus, mindig kapun át” kategóriába. A többi — a nagy többség — utólagos, összesített ellenőrzésbe kerül: hetente egyszer valaki (vagy valami) átfut rajta, és ha rendszeresen ugyanaz a probléma bukkan fel, az jelzi, hogy talán mégis fel kellene léptetni kritikussá.
Ez az arány nem véletlen. Ha minden szabály kritikus lenne, a kapu-fegyelem összeomlana a mennyiség súlya alatt. Ha semmi nem lenne kritikus, elveszne a védelem pont ott, ahol a legjobban kellene. A 29/130 arány azt tükrözi, hogy a kockázat nem egyenletesen oszlik el a döntések között — a legtöbb apró döntés olcsón hibázható, kevés döntés az, ahol a hiba tényleg drága.
Mikor engedd, hogy magától menjen
Van egy gyakori félreértés, hogy a szigorú kapu-fegyelem azt jelenti, hogy szinte semmit nem bízol az AI-ra. Ennek pont az ellenkezője igaz: minél pontosabban meghúzod a határt, annál nagyobb autonómiát mersz adni azon a másik oldalon. Ha tudod, hogy a kritikus 20-30%-ra biztos kapu vigyáz, a maradék 70-80%-ot nyugodtan futni hagyhatod felügyelet nélkül — pont azért, mert nem kell minden egyes apró lépésnél azon gondolkodnod, hogy „mi van, ha ez most az a ritka eset, ami elszáll”. A bizalom nem egyenletesen oszlik el a feladatok között, és nem is kell, hogy annak tűnjön — a cél az, hogy ott legyen szigorú, ahol drága a hiba, és ott legyen laza, ahol nem az.
Amit magaddal vihetsz
A delegálás nem bináris kérdés — nem az van, hogy „bízom az AI-ban” vagy „nem bízom”. A gyakorlatban ez egy folyamatos, lépésenkénti mérlegelés: mennyire drága a hiba, ha ez a konkrét lépés rosszul sül el, és van-e olyan pont, ahol meg tudom állítani, mielőtt megtörténne. Ha ezt a kérdést minden autonóm lépésnél feltetted magadnak — akár egy egyszerű háromkérdéses listával, mint fentebb —, már messze előrébb jársz, mint a legtöbb AI-bevezetés, ahol ez a döntés soha nincs explicit kimondva, csak valahogy alakul.
Ha érdekel, hogyan néz ki ez a kapu-logika technikai vázként — a verdikt-típusok, az újrapróbálkozási limit, a szelektivitás pontos szabályai —, ezt is megtalálod a Blueprint-ek között.