Ki dönt, amikor egy ügynök delegál?

A delegáció képessé tehet egy AI-munkafolyamatot anélkül, hogy elszámoltathatóbbá tenné. A különbség az, hogy a felhatalmazás, a bizonyítékok és a leállítás...

Ki dönt, amikor egy ügynök delegál?

A handover does not empty the chair

An agent delegates a task. Another agent gathers material, compares records, calls a tool or prepares a recommendation. A third agent checks the result. The work moves, and that movement can be useful. It can also create a very old management problem in a new shape: everyone has done something, yet nobody can say who was entitled to make the decision.

The tempting answer is the agent that made the last call. It is also usually the least helpful answer. A software component may select a route, ask for more work and submit an instruction to a connected system. None of those things establishes who accepted the purpose, who set the boundary, who could have refused the action, or who had to be told when the conditions changed. It merely establishes that a program was in the chain.

That distinction becomes sharp when a workflow has consequences. A suggested reply can become a customer communication. A classification can become the reason a case is put in a particular queue. A comparison can become a purchasing recommendation. A drafted payment instruction can become a payment. Each step may be technically competent and still be organisationally incomplete. The system has done the work of delegation without doing the work of authority.

There is no need to invent a dramatic failure to see the problem. Take a deliberately hypothetical workflow. A triage agent receives a question, asks a research agent to inspect the relevant material, sends the result to a reviewer, and then prepares an action for a case-management system. The research agent is not authorised to act. The reviewer is not authorised to make the case outcome effective. The triage agent has a tool credential. The organisation has not specified whether that credential permits it to commit the result. The workflow may look orderly on a dashboard. It has nonetheless reached the most important question with no answer.

Delegation is not the disappearance of responsibility. It is responsibility made harder to see. A good operating design makes it easier again. It says what the initial decision is, what can be delegated, which conditions travel with the task, who can approve an irreversible or consequential action, what record remains after the handover, and how a person or system can intervene when the route is no longer safe. The technology is not being asked to possess moral agency. It is being asked to leave the organisation's agency intact.

That is the practical meaning of accountability in a multi-agent workflow. It is not a decorative line in a policy, and it is not a retrospective hunt for the nearest employee when something goes wrong. It is a property of the route before work begins. The right person can inspect what was proposed, understand why it was proposed, exercise the authority assigned to them, and leave behind a record that can be challenged afterwards.

Europe's emerging AI rules are helpful here because they are less interested in a theatrical human at the end of a flow than in the conditions under which oversight can actually work. The AI Act's human-oversight provisions apply to high-risk systems, not to every use of an agent. That limit matters. But the operational questions in the Act travel well: can an assigned natural person understand the relevant capabilities and limits, monitor for anomalies and unexpected performance, avoid over-reliance, interpret output, disregard or reverse it, and interrupt the system into a safe state? A workflow with many agents does not make those questions smaller. It multiplies the places where the answer can be lost.

A delegáció előreviheti a munkát. Nem törölheti el az utat, amelyen a felhatalmazás és a kifogás visszafelé halad.

A delegáció lánc, nem köd

Az emberek folyamatosan delegálnak. Egy vezető megkér egy kollégát, hogy készítsen egy feljegyzést. Egy beszerzési csapat megkér egy szakértőt, hogy vizsgáljon meg egy szerződési feltételt. Egy klinikus eredményt kér a laboratóriumtól. A feladatot átvevő személy meghatározott szerepet kap a munkában; nem örökli automatikusan mindazt a felhatalmazást, amellyel a kérő rendelkezik. A jól működő szervezetek ezt a hétköznapi megkülönböztetést munkaköri leírásokkal, jóváhagyási limitekkel, eljárásokkal, feladatkörök szétválasztásával és nyilvántartásokkal biztosítják. Azért teszik, mert a képesség és az engedély két különböző dolog.

Az ügynökrendszerek hajlamosak elmosni ezt a különbséget, mert egy ügynök egyetlen beszélgetési felületen képes leírni, megtervezni és végrehajtani. Egy modell képes lehet meggyőző tervet készíteni egy szállító megkeresésére. Egy eszközburkoló technikailag képes lehet elküldeni az üzenetet. Egy összehangolási réteg képes lehet megszakítás nélkül meghívni ezt a burkolót. Ezek a tények a képességet írják le. Nem döntik el, hogy az üzenetet el kell-e küldeni, hogy a javasolt címzett a hatókörön belül van-e, hogy az információ nyilvánosságra hozatala megfelelő-e, vagy hogy ki vállalja a következményt, ha a javasolt lépés hibás.

Érdemes szétválasztani öt, gyakran összemosott kérdést. Ki adta a feladatnak a célját? Ki végezhet előkészítő munkát? Ki delegálhat részfeladatot? Ki döntheti el, hogy egy javasolt lépés elfogadható-e? Ki teheti ezt a lépést hatásossá a külvilágban? Néha egyetlen emberi szerep jogosan birtokolja ezek közül többet is. Néha szét kell választani őket. A lényeg nem az, hogy alacsony kockázatú feljegyzéshez bonyolult ceremóniát hozzunk létre. A lényeg az, hogy ne kezeljük csendben a technikai képességet intézményi felhatalmazás átruházásaként.

A delegációnak ezért többet kell hordoznia, mint egy utasítást. Mandátumot kell hordoznia. A mandátum azonosítja a célt, a behatárolt kontextust, a megengedett bemeneteket, a várt kimenetet, a tiltva maradó lépéseket, a releváns költségvetést vagy időkorlátot, a eszkalációt igénylő feltételeket, valamint az eredményért felelős személyt vagy szerepet. A fogadó ügynök így látható kereteken belül végezhet hasznos munkát. Kérhet elemzést egy másik ügynöktől. Nem bővítheti a kereteket pusztán azért, mert egy kézenfekvő következő lépés eszébe jut.

Ez nem érv amellett, hogy minden interakciót jóváhagyási megbeszéléssé alakítsunk. Ez érv amellett, hogy a szervezet kiválassza azt a pontot, ahol döntés születik. Egy rendszer megfogalmazhat egy magyarázatot anélkül, hogy egy ember minden mondatot átnézne, ha a cél, a közönség, a forráshatár és a közzétételi szabályok már rögzítettek. Egy rendszer nem szerezheti meg a jogot, hogy módosítsa egy ügyfél jogosultságát pusztán azért, mert ugyanaz az összetevő hozzáfér a releváns adatbázishoz. A különbség a következmény, nem a modell intelligenciája.

Ez a következmény gyakran eloszlott. Egy feladat ártalmatlan lehet az egyik szakaszban, és jelentős következményekkel járhat a következőben. Egy fájl beolvasása rutinszerű lehet. Ha egy másik forrással kombináljuk, az megváltoztathatja az anyag érzékenységét. Egy ajánlás előkészítése rutinszerű lehet. Egy gomb megnyomása, amely jogi, pénzügyi vagy szolgáltatási következménnyel jár, már nem az. Egy irányítási tervezés, amely csak azt kérdezi, hogy egy ügynök autonóm-e, figyelmen kívül hagyja ezt az állapotváltozást. A hasznos kérdés szűkebb: autonóm mire, kinek, milyen feltételek mellett, és kinek a felhatalmazásával?

Van egy szerény holland ösztön, amelyet érdemes megtartani. Ha egy folyamathoz tucatnyi aláírás, bélyegző és egy laminált folyamatábra kell annak megállapításához, hogy ki nyomhat meg egy gombot, az nem feltétlenül az irányítás diadala. De az ellenkező elrendezés, amelyben egy eszköz hitelesítő adatát alkotmányos rendezésként kezelik, szintén nem diadal. A cél egy arányos út, amely egyértelművé teszi a jelentős következményekkel járó felhatalmazást anélkül, hogy minden rutinművelet köré kis operát rendeznénk.

Az európai felügyelet működési követelmény

Az AI-törvény adja ennek az elképzelésnek a legvilágosabb jogi kifejezését a nagy kockázatú AI-rendszerek esetében. A 14. cikk megköveteli, hogy azokat úgy tervezzék és fejlesszék, hogy természetes személyek hatékonyan felügyelhessék őket használat közben. A megfogalmazott cél az, hogy megelőzzék vagy minimalizálják az egészségre, biztonságra és alapvető jogokra gyakorolt kockázatokat, amennyiben ezek a kockázatok más követelmények ellenére is fennmaradhatnak. Az intézkedéseknek arányosnak kell lenniük a kockázattal, az autonómiával és a használat kontextusával. Ez szándékosan működési jellegű szabvány. Nem azt mondja, hogy egy személy a szervezetben általában érdeklődik az AI iránt.

A rendelkezés túlmutat azon az általános utasításon, hogy tartsunk egy embert a folyamatban. Attól függően, hogy mi megfelelő és arányos, a felügyelettel megbízott személynek képesnek kell lennie a releváns képességek és korlátok megértésére, a működés figyelemmel kísérésére, valamint az anomáliák, működési zavarok vagy váratlan teljesítmény észlelésére, tudatában kell maradnia az automatizációs torzításnak, értelmeznie kell a kimenetet, dönthet úgy, hogy nem használ fel egy kimenetet, vagy figyelmen kívül hagyja, felülbírálja vagy visszafordítja azt, és beavatkozhat vagy megszakíthatja a rendszert egy biztonságos állapotba. A törvény ezeket nem változtatja egyetemes ellenőrző listává minden ügynökrendszer számára. Mégis megmutatja, miért rossz modell a felügyeletre a folyamat végén elhelyezett formális jóváhagyás.

Most adjuk hozzá a delegálást. Ha egy ügynök átad egy feladatot egy másik ügynöknek, a felügyeleti szerepnek többet kell látnia, mint az utolsó modell által előállított végső mondatot. Elegendő kontextusra van szüksége annak megértéséhez, hogy melyik ügynök javasolta a részfeladatot, mely forrásokat vagy eszközöket használták, találkoztak-e szabályzati korláttal, módosította-e egy felülvizsgáló az eredményt, és hogy egy későbbi ügynök kiterjesztette-e a hatókört. Ellenkező esetben az ember látja a kimenetet, de nem az azt előállító utat. Ez elegendő lehet egy alacsony következményekkel járó tervezethez. Nem meggyőző alap egy jelentős következményekkel járó döntés elfogadásához.

A 26. cikk még világosabban fogalmazza meg a szervezeti szempontot a nagy kockázatú rendszerek telepítői számára. Kimondja, hogy a telepítőknek emberi felügyeletet kell kijelölniük olyan természetes személyeknek, akik rendelkeznek a szükséges kompetenciával, képzéssel, felhatalmazással és támogatással. Ezek a szavak együtt tartoznak. A kompetencia felhatalmazás nélkül jól tájékozott szemlélőt hoz létre. A felhatalmazás kompetencia nélkül olyan formális tulajdonost hoz létre, aki nem képes megkérdőjelezni a rendszert. Mindkettő támogatás nélkül olyan személyt hoz létre, akitől azt várják, hogy beavatkozzon egy olyan folyamatba, amelyet nem lát, olyan ütemben, amelyet nem tud tartani, olyan információ felhasználásával, amelyet nem tud értelmezni.

Multiágens munkánál a támogatás magában foglalja a felület és a rekord alakját. Egy kezelőnek nem kell minden token, amit egy modell létrehozott, sem minden belső újrapróbálkozás. Arra van szüksége, hogy lássa a javasolt műveletet, a megnevezett célt, az anyagi bizonyítékokat, az alkalmazandó szabályzatot és korlátot, az utolsó felülvizsgálati pont óta végrehajtott változtatásokat, a várható hatást, a lehetséges visszafordítási útvonalat, valamint azt az okot, amiért az esetet továbbították. Ez kevésbé arról szól, hogy az irányítópult megnyugtatóan nézzen ki, mint inkább arról, hogy csökkentse annak esélyét, hogy egy személy azért hagy jóvá egy választ, mert a rendszer az alternatívát fárasztóvá tette a megtalálásban.

Az Európa Tanácsnak a mesterséges intelligenciáról, az emberi jogokról, a demokráciáról és a jogállamiságról szóló keretegyezménye teremti meg a tágabb intézményi kapcsolatot. Célja annak biztosítása, hogy az AI-rendszerek életciklusában végzett tevékenységek összhangban legyenek az emberi jogokkal, a demokráciával és a jogállamisággal. A 8. és 9. cikk az adott kontextusokhoz és kockázatokhoz igazított átláthatóságot és felügyeletet, valamint a káros hatásokért való elszámoltathatóságot és felelősséget ír elő. Az egyezmény nem ír elő ágensösszehangolási mintát. Viszont hasznos ellensúlyt jelent azzal a gondolattal szemben, hogy a szoftverkomponensek láncolata feloldhatja az azt használó közhatalmi szerv vagy magánszereplő felelősségét.

Ez a tágabb nézőpont azért számít, mert egy átruházott döntés többet érinthet a technikai teljesítménynél. Érintheti azt, hogy egy személy képes-e megérteni egy döntést, megtámadni azt, jogorvoslatot kapni, vagy egyszerűen tudni, hogy melyik szervezet felelős. Egy munkafolyamat állhat több szállító komponenseiből, több szolgáltató modelljeiből, egy másik csapat által üzemeltetett eszközökből és egy közbeszerzési szerződés alapján nyújtott szolgáltatásból. Az, hogy a lánc technikailag megosztott, nem teszi kevésbé valóságossá az egyénre gyakorolt hatást. A gyakorlatban ez még fontosabbá teszi a szerepek egyértelmű elosztását.

Az adatvédelem ugyanezt a figyelmeztetést más irányból fogalmazza meg. Az Európai Adatvédelmi Testületnek az AI-modellekről szóló munkája hangsúlyozza, hogy az adatvédelmi elemzés kontextuális marad: a szervezeteknek meg kell határozniuk a szerepüket, azonosítaniuk kell az érintett adatkezelést, és alkalmazniuk kell a vonatkozó kötelezettségeket, ahelyett hogy az AI-modell címkéjét a szokásos elszámoltathatóság alóli mentességként kezelnék. Amikor egy multiágens munkafolyamat személyes adatokat érint, az átruházás nem homályosíthatja el azt, hogy ki határozza meg az adatkezelés céljait és eszközeit, melyik ágens vagy eszköz melyik adatot kapja, és hogy a következő átadás szükséges-e a feladathoz. Egy részfeladat akkor is adatkezelési lépés. Ha átruházásnak nevezzük, azzal nem tűnik el.

Egyik sem ad varázslatos választ minden nehéz esetre. A jogi kötelezettségek a felhasználástól, a szereplőktől, az adatoktól és az ágazattól függenek. Egy cikk nem sorolhat be egy adott rendszert. De megfogalmazhat egy fegyelmezett elvet: ha egy munkafolyamat elosztja a munkát, akkor úgy ossza el, hogy megőrizze a tekintély azonosításának, az időben történő beavatkozásnak, az útvonal elszámoltathatóságának és az eredmény által érintett embereknek való válaszadásnak a képességét.

Az embernek a folyamatban valódi folyamatra van szüksége

Az emberi felügyelet könnyen egy jóváhagyó gombbal ellátott képernyővé redukálódik. Ez a képernyő hasznos lehet. Lehet azonban pusztán ceremoniális tárgy is. A kérdés az, hogy az azt használó személynek van-e értelmes választása. Egy választás nem értelmes pusztán azért, mert a felület két gombot jelenít meg. Attól függ, hogy a személynek van-e elég ideje, információja, kompetenciája és intézményi engedélye ahhoz, hogy másként döntsön.

Az idő a tervezés legkevésbé fényes, mégis gyakran a legmeghatározóbb része. Ha a rendszer több száz javaslatot küld egy olyan időszakban, amely alatt egy értékelő észszerűen csak töredéküket tudná átvizsgálni, a szervezet sorban állást hozott létre, nem pedig felügyeletet. Ha a javaslat lejár, mielőtt az értékelő kontextushoz jutna, a rendszer a gyorsaságot tette meg tényleges döntéshozónak. Ha egy csapatot kizárólag az áteresztőképességért jutalmaznak, az hallgatólagos utasítás arra, hogy melyik gombot nyomják meg. A szoftver nem gyógyítja meg ezeket a berendezkedéseket azzal, hogy a megbízhatósági pontszámot a zöld más árnyalatában mutatja.

Az információnak arányosnak kell lennie, nem pedig kimerítőnek. Az az értékelő, aki csak egy következtetést kap, nem tudja azt megkérdőjelezni. Az az értékelő, aki az ügynök minden interakciójának nyers átiratát kapja, az sem tudja azt általában megkérdőjelezni. A használható középút a döntési csomag. Ez azonosítja, hogy milyen intézkedést javasolnak, miért illeszkedik a megadott célhoz, mely lényeges bizonyítékok támasztják alá, milyen bizonytalanság marad, melyik szabályzat vagy szabály releváns, mi a javasolt hatás, és mi történne, ha az intézkedést nem hagynák jóvá. A csomagnak hivatkoznia kell a mélyebb bizonyítékokra, de a hétköznapi esetben nem követelhet régészeti expedíciót.

A hozzáértés többet jelent egy általános mesterséges intelligenciáról szóló tanfolyamnál. Az adott feladathoz az értékelőnek értenie kell a kimenet típusához, az ismert korlátokhoz, amelyek számíthatnak, a munkafolyamat elvárt működéséhez, valamint azokhoz a jelekhez, amelyek eszkalációt igényelnek. Az, aki felismeri a hibás beszállítói számlát, jó helyzetben lehet egy számlával kapcsolatos javaslat értékelésére. Ugyanez a személy nem feltétlenül alkalmas a modell nyelvi lefedettségének vagy egy adatvédelmi vonatkozásnak a felmérésére. A felügyelet kijelölése ezért személyzeti döntés is.

Az intézményi felhatalmazás az a próbatétel, amelyen sok tervezés csendesen elbukik. Az értékelőnek képesnek kell lennie megtagadni, felfüggeszteni vagy megváltoztatni a javasolt útvonalat anélkül, hogy rendszerhiba forrásaként kezelnék. Szüksége van hozzáférésre egy személyhez vagy szerepkörhöz, aki eldöntheti, mi történjen ezután. Szüksége van módra annak rögzítésére, hogy az ügy eszkalálásra került. A rendszernek pedig szüksége van egy biztonságos állapotra, amelyben a munka várakozhat anélkül, hogy véletlenül végrehajtaná egy újrapróbálkozás, egy időtúllépés vagy egy másik ügynök, aki az eredeti utasítást befejezetlen ügyként kezeli.

A biztonságtechnika régóta az emberi teljesítményt a rendszer részeként kezeli, nem pedig végső lakkozott rétegként. Az Egyesült Királyság Egészségvédelmi és Biztonsági Végrehajtó Hatósága az emberi tényezőket a feladat, az egyén és a szervezet egységeként írja le, és figyelmeztet arra, hogy ne vizsgálják őket elszigetelten. Ez észszerű keret az ügynökfelügyelethez. Az értékelő nem egy absztrakt emberi dugó, amely egy szoftveres hiányosságot tölt ki. Konkrét feladatot végez, konkrét információkkal és eszközökkel, egy konkrét szervezeten belül, konkrét nyomásokkal és korlátokkal. Az ellenőrzés minősége mindeztől függ.

Emiatt a jól megtervezett ember-a-hurokban rendszer már a gomb megjelenése előtt elkezdődik. Meghatározza, mely döntések igényelnek emberi kaput, ki tartja a kaput, milyen bizonyítékot kapnak, mennyi időt enged a feladat, mi történik, ha az illető nincs jelen, és hogy a kapunak van-e hatalma maga felett az intézkedés felett, vagy csak az intézkedés magyarázata felett. Ha a szervezet egy csendes kedden nem tud válaszolni ezekre a kérdésekre, nem lesz világosabb, amikor egy nagy horderejű eset érkezik. És nem is kellene képzeletbeli válság ahhoz, hogy észrevegye.

A jogosultságoknak az intézkedés következményét kell leírniuk, nem csupán a hitelesítő adat technikai hatókörét.

Egy feladat, többféle felhatalmazás

Egy tömör felhatalmazási modell megkönnyítheti az ügynök-munkafolyamat működtetését. Nem kell nagyszabásúnak lennie. Kezdjük az olvasás, a javaslattétel, a delegálás, a jóváhagyás és a leállítás közötti különbséggel. Az a szerepkör, amely olvashat, megvizsgálhatja a feladathoz szükséges anyagokat. Az a szerepkör, amely javaslatot tehet, előkészíthet egy lehetséges intézkedést. Az a szerepkör, amely delegálhat, korlátozott munkát bízhat egy másik szereplőre. Az a szerepkör, amely jóváhagyhat, hatályossá tehet egy jelentős intézkedést. Az a szerepkör, amely leállíthat, szüneteltetheti vagy megállíthatja a folyamatot, ha a feltételei már nem teljesülnek.

Ezek nem egyszerűen szintek. Egy megfelelőségi felülvizsgáló leállíthat egy munkafolyamatot, de nem hagyhat jóvá egy ügyfélkimenetet. Egy szakértői ügynök javasolhat egy útvonalat, de nem delegálhat új munkát a saját területén kívül. Egy vezető felelős lehet egy szolgáltatás céljáért, mégsem ő az, aki felhatalmazást kapott egy adott kifizetés teljesítésére. A hasznos tulajdonság nem az önmagáért való hierarchia. Hanem az, hogy a rendszer képes értékelni, hogy egy adott szereplő rendelkezik-e a releváns felhatalmazással egy adott intézkedéshez az aktuális környezetben.

A környezet sokat számít. Ugyanaz a javasolt intézkedés lehet hétköznapi az egyik körülmények között, és jelentős egy másikban. Egy már jóváhagyott sablon elküldése egy ismert belső címre beleférhet a rutinszerű kommunikációs megbízásba. Egy újonnan megfogalmazott, személyes adatokat tartalmazó üzenet elküldése új címzettnek már más. Egy meghatározott küszöbértéken belüli visszatérítés delegálható egy jól bevált folyamatra. Egy jogosultság módosítása, egy adattörlés vagy egy külső kötelezettségvállalás név szerinti emberi döntést igényelhet. A szabályzatnak ezt a különbséget kell kifejeznie, mielőtt a modellt arra kérnénk, hogy ennek megfelelően tervezzen.

Fontos különbség van továbbá a visszaigazolás és a jóváhagyás között. A visszaigazolás rögzíti, hogy valaki látta az üzenetet. A jóváhagyás rögzíti, hogy egy felhatalmazott személy elfogadott egy meghatározott intézkedést, a releváns környezettel együtt, az útvonal egy meghatározott pontján. Egy beszélgetéses rendszerben ezek hasonlónak tűnhetnek. A nyilvántartásnak nem szabad annak lennie. Ha egy későbbi felülvizsgáló nem tudja megmondani, hogy milyen intézkedést hagytak jóvá, és milyen hatást vártak, a szervezet egy beszélgetést naplózott, nem pedig egy döntést rögzített.

Maga a delegálás is igényel korlátokat. Egy ügynök, amely azt a feladatot kapja, hogy hasonlítson össze három meglévő javaslatot, megkérhet egy kutatási ügynököt, hogy emelje ki a releváns feltételeket. Nem szabad ezt a jogosultságot felhívásnak tekintenie arra, hogy kapcsolatba lépjen beszállítókkal, új adatokat szerezzen be, vagy újrafogalmazza a beszerzési célt. A határ kifejezhető szabályzatban, eszközhatókörben, strukturált feladat-szerződésben vagy mindháromban. A lényeg az, hogy elég kikényszeríthető legyen ahhoz, hogy korlátozza az útvonalat, ne csupán utólag írja le a kívánt viselkedést.

Delegation depth is another limit worth naming. A human can give one agent a task and still retain a clear view of its first handover. After several nested handovers, the original purpose may be technically present in metadata yet practically invisible. Organisations can set a maximum delegation depth for a class of work, require review at a particular depth, or prohibit a delegate from creating further delegates without a fresh gate. These are design choices, not universal requirements. They are most useful where a longer chain makes it difficult to see which actor introduced a new assumption or changed the effective scope.

Tool authority must also be separate from model authority. A model might choose a tool based on a plan. The tool integration should still check whether the requested action, target, data category, resource limit and workflow state permit the call. This is not distrust of the model in a moral sense. It is ordinary boundary design. A well-formed plan can still be inappropriate for the current case, and a poorly formed plan should not become real merely because it reached a credential with broad access.

The same goes for recovery. A retry is not always harmless. Retrying a request to read a public document is different from retrying a request that sends a message or makes a charge. When a delegated task fails, a workflow needs an explicit choice among retry, reroute, escalate, pause and controlled failure. Treating them as one generic error handler is how an operational decision is quietly made by default settings. The agent runtime can make the options available. The organisation must decide which option applies to which action class.

Failure is often a missing decision

When people hear failure they often picture an agent producing a false statement or a tool timing out. Both can matter. The more revealing failures in delegated work are frequently quieter. The task was assigned without a clear owner. The proposal crossed a boundary no one had modelled. The reviewer could see the conclusion but not the evidence. A retry continued after a pause. A human noticed a problem but had no authority to stop the action. A decision was made, but the record preserved only the final output and not the condition that made it acceptable.

These are not claims about a named incident. They are failure modes derived from the structure of delegation itself. They can be found in human processes too. In software, however, they can travel at the pace of automation and be repeated very consistently. That consistency is not a reason to despair. It is a reason to treat workflow design as part of the control, rather than assuming that accuracy testing of one model component settles the question.

Consider another explicitly hypothetical design. An agent is asked to prepare a case summary. It delegates document extraction to one component and language normalisation to another. A third component sees an incomplete field and uses a connected knowledge source to fill the gap. The final summary reads smoothly. If the workflow has not recorded the missing field, the source used to fill it, the confidence or uncertainty that came with it, and the fact that the original task permitted only summarisation, a reviewer cannot tell whether they are approving a summary or a newly created factual assertion. The problem is not that the last sentence sounds odd. The problem is that the meaning of the task changed inside the route.

A megfelelő válasz nem az, hogy betiltjuk a delegálást, hanem hogy a változási pontokat rögzítjük. Egy új forrás, egy új eszköz, egy új adatkategória, egy új műveletosztály, az önbizalom érdemi változása, egy sikertelen kontroll, a megengedettnél hosszabb delegálási lánc, vagy egy külső határ átlépésére irányuló javaslat mind indok lehet arra, hogy a munkát felülvizsgálatra kiemeljük. A pontos kiváltó okok kontextusonként eltérőek. Az elv viszont állandó: az a változás, amely az elszámoltatható tulajdonos számára fontos lenne, ne maradjon láthatatlan csak azért, mert komponensek között történt.

Ez az a pont, ahol a biztonsági eset gondolkodásmódja hasznos. A biztonsági eset nem ígéret arra, hogy semmi nem romolhat el. Ez egy strukturált érvelés arról, hogy egy rendszer miért elfogadható egy meghatározott célra, meghatározott feltételek mellett, látható bizonyítékokkal, feltételezésekkel, kontrollokkal és fennmaradó kockázatokkal. Ügynök-munkafolyamatra gondosan alkalmazva ez azt jelenti, hogy az állítás nem az, hogy az ügynökök általában biztonságosak. Az állítás szűkebb: ez az útvonal erre a célra használható, ezekkel a korlátokkal, mert ezek a kontrollok és felügyeleti megállapodások léteznek, és újra kell gondolni, ha a megfogalmazott feltételezések már nem állnak fenn.

A munkafolyamat így könnyebben megkérdőjelezhető. Egy kezelő megkérdezheti, hogy a műveletosztályt megfelelően rendelték-e hozzá. Egy kockázati tulajdonos megkérdezheti, hogy a felülvizsgálónak van-e még elég ideje. Egy mérnök megkérdezheti, hogy egy újrapróbálkozás okozhat-e ismétlődő hatást. Egy adatvédelmi szakember megkérdezheti, hogy az alfeladat továbbra is szükséges és arányos-e. Egy személy, akit egy eredmény érint, ahol az alkalmazandó keretrendszer ezt megköveteli, utat kaphat a döntés megkérdőjelezésére. Ezek a kérdések nem az érdekes technikai munka után hozzáadott bürokrácia. Ezek azok a munkák, amelyek a technikai rendszert elszámoltathatóvá teszik egy szervezetben.

A mérőszámoknak ugyanezt a fegyelmet kell követniük. A delegált feladatok számának megszámlálása valamit elmond a mennyiségről, de nem az elszámoltatható működésről. Hasznosabb mérőszámok lehetnek: azoknak az eseteknek az aránya, amikor egy munkafolyamat határváltozás miatt eszkalálódik, az az idő, amit egy döntés egy kapunál várakozik, a teljes döntési csomaggal rendelkező, következményekkel járó műveletek aránya, a sikeres visszavonások száma, vagy azoknak az eseteknek a száma, amikor egy szabályzatellenőrzés megtagadott egy eszközhívást. Az ilyen mérésekhez még mindig definíció és kontextus kell. Soha ne találják ki őket egy brosúrához. De ha a nyilvántartásokat úgy tervezik, hogy mérhetők legyenek, az annak a jele, hogy az elszámoltathatóságot működési tulajdonságként kezelik.

A nyilvántartás az, ahol a felelősség fennmarad

Egy több ügynökből álló rendszer kínos fajta történetet hoz létre. Vannak benne üzenetek, eszközhívások, köztes kimenetek, szabályzatellenőrzések, modellverziók, időzítési információk, újrapróbálkozások, megváltozott hozzárendelések és esetleg emberi jóváhagyások. Minden bájtot örökre megőrizni nem szükséges, és gyakran nem is helyénvaló. Csak a végső választ megőrizni általában túl kevés. A nyilvántartásnak meg kell őriznie azokat a döntéseket és bizonyítékokat, amelyek megmagyarázzák, hogyan jutott el a munkafolyamat egy kéréstől egy eredményig.

Egy következményekkel járó művelet esetében ennek a nyilvántartásnak általában lehetővé kell tennie egy felülvizsgáló számára, hogy néhány alapvető tényt rekonstruáljon. Mi volt a cél? Melyik szabályzat vagy megbízás tette a munkát megengedhetővé? Ki vagy mi kapta az egyes hozzárendeléseket? Mit javasoltak az egyes, következményekkel járó kapuknál? Milyen információt használtak a javaslat alátámasztására? Milyen korlátokkal, figyelmeztetésekkel vagy hibákkal találkoztak? Kinek volt felhatalmazása a művelet jóváhagyására, leállítására vagy visszavonására? Melyik művelet lépett hatályba, és mi történt utána? Ezek nem egzotikus kérdések. Ezek azok a kérdések, amelyeket egy szervezet feltesz, amikor tudni akarja, hogy egy döntés az ő döntése volt-e.

The record should distinguish an operational fact from an explanation produced later. If a system says a reviewer approved an action, the event should record the identity or role of the reviewer, the action they were shown, the relevant context and the time at which the approval bound to that action. If the system says a model selected a delegate, the record should preserve the selection rule, candidates or criteria at the level appropriate for the use, and the resulting assignment. A later narrative can help a reader, but it should not replace the event that occurred.

Versioning matters here. An agent's output may be regenerated. A policy may be updated. A tool schema may change. A model endpoint may be swapped. If a decision depends on a particular version of a prompt, policy, model, knowledge source or integration, the record needs a stable reference to that version. Otherwise replay becomes a performance: it reproduces whatever the organisation happens to have now and calls the result an explanation of what happened then.

Reversibility deserves equal attention. The AI Act expressly refers, in the high-risk oversight context, to the ability to disregard, override or reverse an output and to interrupt a system so it comes to a halt in a safe state. In a multi-agent route, the safe state is not necessarily a stopped model process. It may mean no external communication is sent, a queued action is held, a downstream system is not updated, temporary credentials are no longer usable for the task, and the evidence needed to decide what happens next is retained. That is an operational inference from the oversight requirement, not a quotation of the law. It is also a useful design test.

Safe does not mean frozen forever. A halted workflow needs a controlled resumption path. Someone must decide whether to amend the task, discard the proposal, rerun a bounded part of the work, use a different tool, seek further evidence or abandon the route. A clean record makes that choice easier because it tells the next person what is known, what was attempted, why the work stopped and which effects have and have not occurred. Without that record, recovery becomes another unstructured delegation, usually undertaken under more pressure than the first one.

This is why retention and access need their own decisions. Not every actor should be able to read every trace. A record may contain personal data, commercially sensitive material or security-relevant details. But controlled access is not the same as no record. The Council of Europe Convention's emphasis on transparency, oversight, accountability and responsibility is a useful reminder that the boundary should be designed rather than assumed. An organisation can preserve an accountable route while limiting access to the detail that a particular reviewer genuinely needs.

What a delegation contract should make visible

A delegation contract can be a data structure, a workflow schema, a signed approval packet or a combination of these. Its form matters less than its content. It should tell the receiving actor what it is allowed to do, what it is not allowed to do and how the work will be judged. When these constraints are absent, agents tend to compensate with increasingly elaborate instructions. That may improve a particular run. It does not create an organisational boundary that a tool, reviewer or auditor can enforce.

Begin with the intended purpose. A purpose should be concrete enough to exclude nearby tasks. Compare the terms in the supplied proposals is different from find the best supplier. Summarise the received documents is different from establish the missing facts. Draft a reply for review is different from communicate a decision. The contrast can sound fussy until an agent uses a broad instruction to take a reasonable but unauthorised next step. Then it is the difference between useful initiative and an unbounded mandate.

Határozza meg a megengedett és a tiltott műveleti osztályokat. Egy ágens számára engedélyezhető, hogy elolvasson egy ügyiratot, kinyerjen megnevezett mezőket, összevessen egy szabályzattal, és elkészítsen egy tervezetet. Tilos lehet számára egy forrásrekord módosítása, külső féllel való kapcsolatfelvétel, új forrás kiválasztása vagy tranzakció végrehajtása. Ezek nem csupán prompt-utasítások. Az eszköz- és munkafolyamat-rétegnek érvényt kell szereznie nekik, ahol ez gyakorlatias. Egy olyan szabályzat, amelyet a művelet pillanatában nem lehet ellenőrizni, útmutatásként még hasznos, de kontrollként gyengébb.

Nevezze meg a felelőst és az eszkalációs útvonalat. A felelős nem feltétlenül az a személy, aki minden műveletnél rákattint az elfogadásra. Ő az a szerepkör, aki felelős az eredményért, és azért, hogy mi történjen, ha az útvonal megválaszolatlan kérdéshez ér. Az eszkalációs útvonal megjelöli a következő illetékes szervet, ha az ágens határsértést, elégtelen bizonyítékot, források közötti ütközést, szabályzati eltérést vagy olyan feltételt észlel, amelynek feloldására a rendszer nem jogosult. Egy várólista megnevezett döntési felelős nélkül csupán késlekedés optimista címkével.

Csatoljon bizonyíték-szabályt. A szabály rögzítheti, hogy mely források mérvadóak, hogy az ágens kereshet-e azokon túl, hogyan jelenik meg a bizonytalanság, mit kell idézni a javaslatban, és mikor igényel felülvizsgálatot egy ütköző forrás. Ez különösen fontos az olyan rendszereknél, amelyek gördülékeny prózát állítanak elő. A gördülékenység miatt egy határsértés hasznos teljesítésnek tűnhet. A bizonyíték-szabály elérhetővé teszi a helyes kérdést: a munkafolyamat azon az anyagon belül maradt-e, amelynek felhasználására felhatalmazást kapott?

Határozzon meg idő-, erőforrás- és delegálási korlátot, ahol ezek számítanak. Egy feladat, amely korlátlanul folytatódhat, költséget, működési torlódást vagy nyomást okozhat egy elavult eredmény rögzítésére. Egy feladat, amely ismételten delegálhat, olyan láncot hozhat létre, amelyet egyetlen felelős sem tud könnyen áttekinteni. A korlátozott kialakítás meghatározza, meddig érvényes a feladat, mennyi erőforrást fogyaszthat, létrehozhat-e alfeladatot, mekkora a megengedett maximális mélység, és mi történik, ha egy korlát elérésre kerül. A válasz lehet automatikus szüneteltetés, eszkaláció vagy szabályozott hiba. A lényeg az, hogy erről a korlát átlépése előtt döntsenek.

Végül határozza meg a teljesítési feltételt. A teljesítés nem mindig azt jelenti, hogy az ágens szöveget állított elő. Jelentheti azt, hogy egy felülvizsgáló teljes csomagot kapott, egy szabályzati kapu elfogadott egy konkrét műveletet, egy downstream rendszer megerősített egy visszafordítható frissítést, vagy egy elszámoltatható felelős úgy döntött, hogy nem folytatja. A teljesítési feltételek őszintén tartják a munkafolyamatot. Megakadályozzák, hogy az ágens úgy kezelje a döntés javaslatának aktusát, mintha a szervezet meghozta volna azt.

Ezek a minták hasznosak, akár egyetlen modellalapú ágenst, akár nagyobb, speciális összetevőkből álló csapatot tartalmaz a munkafolyamat. Több ágens nem feltétlenül igényel több folyamatot. Viszont megköveteli, hogy a szerepek közötti határok kifejezve legyenek, ne csak sejtetve. Ennek a kifejezésnek a költsége általában sokkal alacsonyabb, mint a felhatalmazás rekonstruálásának költsége, miután több rendszer részleges utasításokat cserélt, és az egyikük kapcsolatba lépett a külvilággal.

A delegálásnak képessé kell tennie a szervezetet, nem kevésbé elszámoltathatóvá

Az ágensrendszereket gyakran úgy írják le, mintha értékük abban állna, hogy kiveszik a szervezettséget a munkából. Az érdekesebb lehetőség ennek az ellenkezője. Egy gondosan megtervezett rendszer világosabbá teheti a szervezeti kötelezettségvállalásokat: egy feladatnak van felelőse, egy delegálásnak van határa, egy jelentős műveletnek van felhatalmazása, egy felülvizsgálatnak van bizonyítéka, egy megállásnak van biztonságos állapota, és egy rekord visszajátszható. Ez nem akadálya a hasznos automatizálásnak. Ez az, ami lehetővé teszi, hogy az automatizálás értelmes munkát vállaljon anélkül, hogy az embereknek egy láthatatlan láncban kellene megbízniuk.

Erre a megkülönböztetésre építettük a Dweve Nexus rendszert. A helyi termékdokumentáció tartós feladatokat ír le, a hatáskör értékelését a futási környezet alapján, még a művelet előtt, az egyértelmű együttműködési struktúrákat, beleértve a delegálást is, valamint a munkavégzés közben rögzített naplót. A kapcsolódó állítás szándékosan szerény. Ezek olyan tervezési tulajdonságok, amelyek célja, hogy a delegált útvonal ellenőrizhető legyen. Nem bizonyíték arra, hogy bármely konkrét telepítés jogszerű, biztonságos vagy megfelelő, és nem szüntetik meg annak szükségességét, hogy a szervezet maga döntsön céljáról, hatásköréről és emberi felügyeletéről.

A tágabb tanulság nem egyetlen terméktől függ. Egy modell eldöntheti, hogyan osztja fel a feladatot. Egy ágens munkát kérhet egy másik ágenstől. Egy eszköz végrehajthat egy műveletet. A szervezetnek továbbra is el kell döntenie, hol él a hatáskör. Ezt a delegálás megkezdése előtt kell megtennie, nem pedig azután, hogy egy végeredményt olyan csiszolttá tettek, amelyet már nehéz megkérdőjelezni.

Ez a válasz a címre. A döntés tulajdonosa nem az az ágens, amelyik történetesen utoljára szólalt meg. Hanem az a személy vagy szerepkör, akinek vagy amelynek a szervezet a döntés következményeinek elfogadására vonatkozó hatáskört kijelölte, elegendő információval és hatalommal ahhoz, hogy visszautasíthassa azt. A delegálás akkor hasznos, ha képessé teszi ezt a személyt. Veszélyessé akkor válik, ha lehetetlenné teszi, hogy megtalálják.

Ki dönt, amikor egy ügynök delegál?