Kurš pieņem lēmumu, kad aģents deleģē?
Nodošana neiztukšo krēslu
Aģents deleģē uzdevumu. Cits aģents vāc materiālus, salīdzina ierakstus, izsauc rīku vai sagatavo ieteikumu. Trešais aģents pārbauda rezultātu. Darbs virzās tālāk, un šī virzība var būt noderīga. Tā var arī radīt ļoti senu vadības problēmu jaunā veidolā: visi kaut ko ir darījuši, bet neviens nevar pateikt, kuram bija tiesības pieņemt lēmumu.
Vilinošā atbilde ir aģents, kurš veica pēdējo zvanu. Tā parasti ir arī vismazāk noderīgā atbilde. Programmatūras komponents var izvēlēties maršrutu, pieprasīt vairāk darba un iesniegt instrukciju savienotai sistēmai. Neviena no šīm darbībām nenosaka, kurš pieņēma mērķi, kurš noteica robežas, kurš varēja atteikties no darbības vai kuram bija jāziņo, kad mainījās apstākļi. Tas tikai nosaka, ka ķēdē bija programma.
Šī atšķirība kļūst asa, kad darbplūsmai ir sekas. Ieteikta atbilde var kļūt par saziņu ar klientu. Klasifikācija var kļūt par iemeslu, kāpēc lieta tiek ievietota konkrētā rindā. Salīdzinājums var kļūt par pirkšanas ieteikumu. Sagatavots maksājuma norādījums var kļūt par maksājumu. Katrs solis var būt tehniski kompetents un tomēr organizatoriski nepilnīgs. Sistēma ir paveikusi deleģēšanas darbu, nepaveicot pilnvaru darbu.
Nav jāizdomā dramatiska neveiksme, lai saskatītu problēmu. Ņemsim apzināti hipotētisku darbplūsmu. Triage aģents saņem jautājumu, lūdz pētniecības aģentu pārbaudīt attiecīgo materiālu, nosūta rezultātu recenzentam un pēc tam sagatavo darbību lietu pārvaldības sistēmai. Pētniecības aģents nav pilnvarots rīkoties. Recenzents nav pilnvarots padarīt lietas iznākumu spēkā esošu. Triage aģentam ir rīka akreditācijas dati. Organizācija nav noteikusi, vai šie dati ļauj tam apstiprināt rezultātu. Darbplūsma informācijas panelī var izskatīties sakārtota. Tomēr tā ir nonākusi pie vissvarīgākā jautājuma bez atbildes.
Deleģēšana nav atbildības pazušana. Tā ir atbildība, ko kļūst grūtāk saskatīt. Laba darbības konstrukcija to atkal padara vieglāk saskatāmu. Tā nosaka, kāds ir sākotnējais lēmums, ko var deleģēt, kādi nosacījumi tiek pārnesti kopā ar uzdevumu, kurš var apstiprināt neatgriezenisku vai nozīmīgu darbību, kāds ieraksts paliek pēc nodošanas un kā cilvēks vai sistēma var iejaukties, kad maršruts vairs nav drošs. Tehnoloģijai netiek prasīts piemist morālai rīcībspējai. Tai tiek prasīts atstāt organizācijas rīcībspēju neskartu.
Tā ir praktiskā atbildības nozīme vairāku aģentu darbplūsmā. Tā nav dekoratīva rindiņa politikā, un tā nav retrospektīva tuvākā darbinieka meklēšana, kad kaut kas noiet greizi. Tā ir maršruta īpašība pirms darba sākuma. Īstā persona var pārbaudīt, kas tika ierosināts, saprast, kāpēc tas tika ierosināts, izmantot tai piešķirtās pilnvaras un atstāt ierakstu, ko vēlāk var apstrīdēt.
Eiropas jaunie mākslīgā intelekta noteikumi šeit ir noderīgi, jo tie mazāk interesējas par teatrālu cilvēku plūsmas galā nekā par apstākļiem, kādos uzraudzība patiešām var darboties. MI akta cilvēka uzraudzības noteikumi attiecas uz augsta riska sistēmām, nevis uz katru aģenta izmantošanu. Šis ierobežojums ir svarīgs. Bet operatīvie jautājumi aktā labi pārnēsājas: vai norīkota fiziska persona var saprast attiecīgās spējas un ierobežojumus, uzraudzīt anomālijas un negaidītu sniegumu, izvairīties no pārmērīgas paļaušanās, interpretēt izvadi, ignorēt vai atsaukt to un pārtraukt sistēmu drošā stāvoklī? Darbplūsma ar daudziem aģentiem nepadara šos jautājumus mazākus. Tā vairo vietas, kur atbilde var pazust.
Deleģēšana ir ķēde, nevis migla
Cilvēki deleģē pastāvīgi. Vadītājs lūdz kolēģim sagatavot piezīmi. Iepirkumu komanda lūdz ekspertam izvērtēt līguma nosacījumu. Klīnicists lūdz laboratorijai sniegt rezultātu. Persona, kas saņem uzdevumu, iegūst noteiktu lomu darbā; tā automātiski nepārņem visas pilnvaras, kas ir personai, kura lūgusi. Labas organizācijas šo ikdienišķo atšķirību nodrošina ar amatu aprakstiem, apstiprināšanas limitiem, procedūrām, pienākumu nošķiršanu un ierakstiem. Tās to dara tāpēc, ka spējas un atļaujas ir dažādas lietas.
Agentu sistēmas mēdz šo atšķirību izpludināt, jo agents var aprakstīt, plānot un izpildīt vienā sarunas virsmā. Modelis var spēt ģenerēt pārliecinošu plānu saziņai ar piegādātāju. Rīka ietvars var tehniski spēt nosūtīt ziņojumu. Orķestrācijas slānis var spēt izsaukt šo ietvaru bez pauzes. Šie fakti raksturo spējas. Tie neizlemj, vai ziņojums būtu jānosūta, vai ierosinātais saņēmējs ir darbības jomā, vai informācija ir piemērota izpaušanai, vai kam būtu jāuzņemas sekas, ja ierosinātā darbība ir nepareiza.
Ir lietderīgi nošķirt piecus jautājumus, kas bieži tiek apvienoti. Kurš deva uzdevumam tā mērķi? Kurš drīkst veikt sagatavošanas darbu? Kurš drīkst deleģēt apakšuzdevumu? Kurš drīkst izlemt, ka ierosinātā darbība ir pieņemama? Kurš drīkst padarīt šo darbību iedarbīgu ārējā pasaulē? Dažkārt viena cilvēka loma pamatoti ietver vairākas no šīm atbildēm. Dažkārt tās ir jānošķir. Mērķis nav radīt sarežģītu ceremoniju zemriska piezīmei. Mērķis ir izvairīties no tā, ka tehniska spēja klusībā tiek uzskatīta par institucionālu pilnvaru nodošanu.
Deleģēšanai tāpēc vajadzētu nest vairāk nekā tikai norādījumu. Tai vajadzētu nest mandātu. Mandāts nosaka mērķi, ierobežoto kontekstu, atļautās ievades, sagaidāmo iznākumu, darbības, kas paliek aizliegtas, budžetu vai laika ierobežojumu, ja tas ir būtiski, nosacījumus, kas prasa eskalāciju, un personu vai lomu, kas ir atbildīga par rezultātu. Saņēmējagents tad var veikt lietderīgu darbu redzamā ietvarā. Tas var lūgt citam agentam analīzi. Tas nevar paplašināt ietvaru tikai tāpēc, ka tam ienāk prātā ticams nākamais solis.
Šis nav arguments par to, lai katru mijiedarbību pārvērstu apstiprināšanas sapulcē. Tas ir arguments par to, lai izvēlētos brīdi, kurā organizācija vēlas, lai lēmums notiktu. Sistēma var sagatavot skaidrojumu bez cilvēka uzraudzības pār katru teikumu, ja mērķis, auditorija, avota robeža un publicēšanas noteikumi jau ir fiksēti. Sistēmai nevajadzētu iegūt spēju mainīt klienta tiesības tikai tāpēc, ka šim pašam komponentam ir piekļuve attiecīgajai datubāzei. Atšķirība ir sekas, nevis modeļa inteliģence.
That consequence is often distributed. A task can be harmless at one stage and consequential at the next. Reading a file may be routine. Combining it with another source may change the sensitivity of the material. Preparing a recommendation may be routine. Pressing a button that creates a legal, financial or service outcome may not be. A governance design that asks only whether an agent is autonomous misses this change of state. The useful question is narrower: autonomous to do what, for whom, against which conditions, and with whose authority?
There is a modest Dutch instinct worth keeping here. If a process needs a dozen signs, stamps and a laminated flowchart to establish who may press one button, it may not be a triumph of governance. But the opposite arrangement, in which a tool credential is treated as a constitutional settlement, is not a triumph either. The aim is a proportionate route that makes consequential authority clear without staging a small opera around every routine action.
European oversight is an operating requirement
The AI Act gives the clearest legal expression of this idea for high-risk AI systems. Article 14 requires them to be designed and developed so that natural persons can effectively oversee them while they are in use. The stated purpose is to prevent or minimise risks to health, safety and fundamental rights where those risks may remain despite other requirements. The measures must be commensurate with risk, autonomy and context of use. That is a deliberately operational standard. It does not say that a person somewhere in the organisation is generally interested in AI.
The provision goes further than a generic instruction to keep a human in the loop. Depending on what is appropriate and proportionate, the person assigned to oversight must be enabled to understand relevant capacities and limitations, monitor operation and detect anomalies, dysfunctions or unexpected performance, remain aware of automation bias, interpret output, decide not to use an output or to disregard, override or reverse it, and intervene or interrupt the system into a safe state. The law does not turn these into a universal checklist for every agent system. It does show why an end-of-process rubber stamp is a poor model of oversight.
Now add delegation. If an agent hands a task to another agent, the oversight role needs to be able to see more than the final sentence produced by the last model. It needs enough context to understand which agent proposed the subtask, which sources or tools were used, whether a policy limit was encountered, whether a result was changed by a reviewer, and whether a later agent extended the scope. Otherwise the human can see an output but not the route that produced it. That may be sufficient for a low-consequence draft. It is not a persuasive basis for accepting a consequential decision.
Article 26 makes the organisational point even plainer for deployers of high-risk systems. It says deployers are to assign human oversight to natural persons with the necessary competence, training, authority and support. Those words belong together. Competence without authority creates a well-informed bystander. Authority without competence creates a formal owner who cannot challenge the system. Both without support create a person expected to intervene in a process they cannot see, at a pace they cannot meet, using information they cannot interpret.
Daudzagenta darbā atbalsts ietver saskarnes un ieraksta formu. Operatoram nav vajadzīgs katrs modeļa ģenerētais tokens vai katrs iekšējais atkārtotais mēģinājums. Viņam ir vajadzīga piedāvātā darbība, nosauktais mērķis, būtiskie pierādījumi, piemērojamā politika un ierobežojums, kopš pēdējā pārskata punkta veiktās izmaiņas, paredzamā ietekme, iespējamais atcelšanas ceļš un iemesls, kāpēc lieta tika nodota augstāk. Tas mazāk ir jautājums par to, lai informācijas panelis izskatītos pārliecinošs, bet vairāk par to, lai samazinātu iespēju, ka cilvēks apstiprinās atbildi tāpēc, ka sistēma ir padarījusi alternatīvu atrast par nogurdinošu.
Eiropas Padomes Pamatkonvencija par mākslīgo intelektu, cilvēktiesībām, demokrātiju un tiesiskumu veido plašāku institucionālo saikni. Tās mērķis ir nodrošināt, ka darbības MI sistēmu dzīves ciklā atbilst cilvēktiesībām, demokrātijai un tiesiskumam. 8. un 9. pants prasa pārredzamību un uzraudzību, kas pielāgota konkrētam kontekstam un riskiem, kā arī atbildību par nelabvēlīgu ietekmi. Konvencija nenosaka aģentu orķestrācijas modeli. Tā tomēr ir noderīgs labojums uzskatam, ka programmatūras komponentu ķēde var izšķīdināt publiskās iestādes vai privātā dalībnieka atbildību, kas to izmanto.
Šim plašākajam skatījumam ir nozīme, jo deleģēts lēmums var ietekmēt vairāk nekā tikai tehnisko sniegumu. Tas var ietekmēt cilvēka spēju saprast lēmumu, to apstrīdēt, saņemt tiesisko aizsardzību vai vienkārši zināt, kura organizācija ir atbildīga. Darbplūsma var sastāvēt no vairāku piegādātāju komponentiem, vairāku pakalpojumu sniedzēju modeļiem, citas komandas pārvaldītiem rīkiem un pakalpojuma, kas tiek sniegts saskaņā ar publisku līgumu. Tas, ka ķēde tehniski ir sadalīta, nepadara ietekmi uz indivīdu mazāk reālu. Praksē tas padara skaidru lomu sadalījumu vēl svarīgāku.
Datu aizsardzība sniedz to pašu brīdinājumu no cita virziena. Eiropas Datu aizsardzības kolēģijas darbs pie MI modeļiem uzsver, ka datu aizsardzības analīze paliek kontekstuāla: organizācijām jānosaka sava loma, jāidentificē attiecīgā apstrāde un jāpiemēro attiecīgie pienākumi, nevis jāuztver etiķete MI modelis kā atbrīvojums no parastās atbildības. Ja daudzagenta darbplūsma skar personas datus, deleģēšana nedrīkst aizēnot to, kurš nosaka apstrādes mērķus un līdzekļus, kurš aģents vai rīks saņem kurus datus un vai nākamā nodošana ir nepieciešama uzdevuma veikšanai. Apakšuzdevums joprojām ir apstrādes posms. To saukt par deleģēšanu neliek tam pazust.
Nekas no tā nesniedz maģisku atbildi uz katru sarežģīto gadījumu. Tiesiskie pienākumi ir atkarīgi no lietojuma, dalībniekiem, datiem un nozares. Raksts nevar klasificēt konkrētu sistēmu. Bet tas var formulēt disciplinētu principu: ja darbplūsma sadala darbu, tai tas jādara tā, lai saglabātu spēju identificēt atbildību, laikus iejaukties, uzskaitīt ceļu un atbildēt cilvēkiem, kurus skar iznākums.
Cilvēkam ķēdē ir vajadzīga īsta ķēde
Cilvēka uzraudzību viegli reducē līdz ekrānam ar apstiprināšanas pogu. Šāds ekrāns var būt noderīgs. Tas var būt arī ceremoniāls objekts. Jautājums ir, vai cilvēkam, kurš to lieto, ir jēgpilna izvēle. Izvēle nav jēgpilna tikai tāpēc, ka saskarnē ir redzamas divas pogas. Tā ir atkarīga no tā, vai cilvēkam ir pietiekami daudz laika, informācijas, kompetences un institucionālas atļaujas, lai izlemtu citādi.
Laiks ir vismazāk pievilcīgā dizaina daļa un bieži vien visizšķirošākā. Ja sistēma nosūta simtiem priekšlikumu laikposmā, kurā viens vērtētājs pamatoti varētu izskatīt tikai daļu, organizācija ir izveidojusi rindu, nevis uzraudzību. Ja priekšlikums zaudē spēku, pirms vērtētājs ir paspējis iegūt kontekstu, sistēma ir padarījusi ātrumu par faktisko lēmumu pieņēmēju. Ja komanda tiek atalgota tikai par caurlaidību, tai ir dots kluss norādījums par to, kuru pogu nospiest. Programmatūra nevar novērst šādus apstākļus, pievienojot ticamības rādītāju citā zaļā tonī.
Informācijai jābūt samērīgai, nevis izsmeļošai. Vērtētājs, kuram dots tikai secinājums, to nevar apstrīdēt. Vērtētājs, kuram dots neapstrādāts visu aģenta mijiedarbību atšifrējums, parasti to arī nevar apstrīdēt. Izmantojamais vidusceļš ir lēmumu pakete. Tajā norādīts, kāda darbība tiek ierosināta, kāpēc tā atbilst noteiktajam mērķim, kuri būtiski pierādījumi to pamato, kāda nenoteiktība paliek, kura politika vai noteikums ir būtisks, kāda ir ierosinātā ietekme un kas notiktu, ja darbība netiktu apstiprināta. Paketei būtu jānodrošina saites uz dziļākiem pierādījumiem, taču tai nevajadzētu prasīt arheoloģisku ekspedīciju parastā gadījumā.
Kompetence nozīmē vairāk nekā vispārīgu kursu par mākslīgo intelektu. Konkrētajam uzdevumam vērtētājam ir jāsaprot izvades veids, zināmie ierobežojumi, kam varētu būt nozīme, veids, kā darbplūsmai būtu jādarbojas, un pazīmes, kas liecina par nepieciešamību nodot lietu tālāk. Cilvēks, kurš spēj atpazīt kļūdainu piegādātāja rēķinu, var būt labi piemērots ar rēķinu saistīta priekšlikuma izvērtēšanai. Šī pati persona var nebūt labi piemērota, lai novērtētu modeļa valodas pārklājumu vai datu aizsardzības ietekmi. Uzraudzības piešķiršana tāpēc ir arī personāla lēmums.
Institucionālā atļauja ir pārbaudījums, kurā daudzi dizaini klusi izgāžas. Vērtētājam ir jābūt iespējai atteikt, apturēt vai mainīt ierosināto ceļu, netiekot uzskatītam par sistēmas kļūmes avotu. Viņam ir nepieciešama piekļuve personai vai amatam, kas var izlemt, kas notiek tālāk. Viņam ir nepieciešams veids, kā reģistrēt, ka lieta ir nodota tālāk. Un sistēmai ir nepieciešams drošs stāvoklis, kurā darbs var gaidīt, netiekot nejauši apstiprināts atkārtota mēģinājuma, taimauta vai cita aģenta dēļ, kas uztver sākotnējo instrukciju kā nepabeigtu lietu.
Drošības inženierija jau sen ir uzskatījusi cilvēka sniegumu par daļu no sistēmas, nevis pēdējo lakas kārtu. Apvienotās Karalistes Veselības un drošības izpildinstitūcija raksturo cilvēka faktorus kā uzdevumu, indivīdu un organizāciju kopumā un brīdina tos neizskatīt atsevišķi. Tas ir saprātīgs ietvars aģentu uzraudzībai. Vērtētājs nav abstrakts cilvēka formas aizbāznis programmatūras plaisai. Viņš veic konkrētu uzdevumu ar konkrētu informāciju un rīkiem konkrētā organizācijā ar konkrētu spiedienu un ierobežojumiem. Kontroles kvalitāte ir atkarīga no visa tā.
Tāpēc labs dizains ar cilvēku uzraudzības lokā sākas pirms pogas parādīšanās. Tajā tiek noteikts, kuriem lēmumiem nepieciešama cilvēka kontrole, kurš turēs šo kontroli, kādus pierādījumus viņš saņems, cik daudz laika uzdevums atļauj, kas notiek, ja viņa nav, un vai kontrolei ir vara pār pašu darbību vai tikai pār darbības skaidrojumu. Ja organizācija nevar atbildēt uz šiem jautājumiem klusā otrdienā, tas nekļūs skaidrāks, kad iestāsies augstas sekas saturošs gadījums. Tai arī nevajadzētu būt vajadzībai pamanīt to tikai iedomātas krīzes dēļ.
One task, several kinds of authority
A compact authority model can make an agent workflow easier to operate. It does not need to be grand. Start with the difference between reading, proposing, delegating, committing and stopping. A role allowed to read can inspect the material necessary for a task. A role allowed to propose can prepare a possible action. A role allowed to delegate can assign bounded work to another actor. A role allowed to commit can make a consequential action effective. A role allowed to stop can pause or halt a route when its conditions no longer hold.
These are not simply ranks. A compliance reviewer may be able to stop a workflow but not to commit a customer outcome. A specialist agent may be able to propose a route but not to delegate new work outside its domain. A manager may be accountable for the purpose of a service yet not be the person authorised to release a particular payment. The useful property is not a hierarchy for its own sake. It is that the system can evaluate whether a particular actor has the relevant authority for a particular action in the current context.
Context does much of the work. The same proposed action can be ordinary in one circumstance and consequential in another. Sending an already approved template to a known internal address may be within a routine communication mandate. Sending a newly drafted message with personal data to a new recipient is different. A refund within a defined threshold may be delegated to a well-tested process. A change to an entitlement, a data deletion or an external commitment may need a named human decision. The policy should express that distinction before the model is asked to plan around it.
There is also an important difference between an approval and an acknowledgement. An acknowledgement records that someone saw a message. An approval records that an authorised person accepted a defined action, with the relevant context, at a defined point in the route. In a conversational system those can look similar. The record should not. If a later reviewer cannot tell what action was approved and what effect was expected, the organisation has logged a conversation rather than captured a decision.
Delegation itself needs limits. An agent that receives a task to compare three existing proposals may be allowed to ask a research agent to extract relevant terms. It should not treat that permission as an invitation to contact suppliers, acquire new data or reframe the procurement objective. The boundary can be expressed in policy, in tool scope, in a structured task contract or in all three. What matters is that it is enforceable enough to constrain the route rather than merely describe the desired behaviour after the fact.
Delegācijas dziļums ir vēl viens ierobežojums, ko vērts nosaukt. Cilvēks var dot vienam aģentam uzdevumu un joprojām saglabāt skaidru priekšstatu par tā pirmo nodošanu. Pēc vairākām ligzdotām nodošanām sākotnējais mērķis var būt tehniski klātesošs metadatos, taču praktiski neredzams. Organizācijas var noteikt maksimālo delegācijas dziļumu konkrētai darba klasei, pieprasīt pārskatīšanu noteiktā dziļumā vai aizliegt deleģētajam veidot tālākus deleģējumus bez jaunas atļaujas. Tie ir dizaina lēmumi, nevis universālas prasības. Tie ir visnoderīgākie tad, ja garāka ķēde apgrūtina saskatīt, kurš dalībnieks ieviesa jaunu pieņēmumu vai mainīja faktisko darbības jomu.
Rīku pilnvarām jābūt arī nošķirtām no modeļa pilnvarām. Modelis var izvēlēties rīku, pamatojoties uz plānu. Rīka integrācijai tomēr jāpārbauda, vai pieprasītā darbība, mērķis, datu kategorija, resursu ierobežojums un darbplūsmas stāvoklis atļauj šo izsaukumu. Tā nav neuzticēšanās modelim morālā nozīmē. Tas ir parasts robežu dizains. Labi izstrādāts plāns joprojām var būt nepiemērots konkrētajai situācijai, un slikti izstrādāts plāns nedrīkst kļūt reāls tikai tāpēc, ka tas sasniedza akreditācijas datus ar plašu piekļuvi.
Tas pats attiecas uz atkopšanos. Atkārtots mēģinājums ne vienmēr ir nekaitīgs. Pieprasījuma atkārtota mēģināšana publiska dokumenta lasīšanai atšķiras no pieprasījuma atkārtotas mēģināšanas, kas nosūta ziņojumu vai veic maksājumu. Kad deleģēts uzdevums neizdodas, darbplūsmai ir nepieciešama skaidra izvēle starp atkārtotu mēģinājumu, pārvirzīšanu, eskalāciju, pauzi un kontrolētu neveiksmi. Uztverot tos kā vienu vispārīgu kļūdu apstrādātāju, operatīvs lēmums tiek klusi pieņemts ar noklusējuma iestatījumiem. Aģenta izpildes vide var padarīt iespējas pieejamas. Organizācijai jāizlemj, kura iespēja attiecas uz kuru darbības klasi.
Neveiksme bieži ir trūkstošs lēmums
Kad cilvēki dzird par neveiksmi, viņi bieži iztēlojas aģentu, kas rada nepatiesu apgalvojumu, vai rīku, kuram beidzas laiks. Abiem var būt nozīme. Atklājošākas neveiksmes deleģētā darbā bieži ir klusākas. Uzdevums tika piešķirts bez skaidra īpašnieka. Priekšlikums šķērsoja robežu, kuru neviens nebija modelējis. Pārskatītājs varēja redzēt secinājumu, bet ne pierādījumus. Atkārtots mēģinājums turpinājās pēc pauzes. Cilvēks pamanīja problēmu, bet viņam nebija pilnvaru apturēt darbību. Lēmums tika pieņemts, bet ierakstā tika saglabāts tikai galīgais rezultāts, nevis nosacījums, kas to padarīja pieņemamu.
Šie nav apgalvojumi par konkrētu incidentu. Tās ir neveiksmju formas, kas izriet no pašas delegācijas struktūras. Tās var atrast arī cilvēku procesos. Programmatūrā tomēr tās var izplatīties automatizācijas ātrumā un tikt atkārtotas ļoti konsekventi. Šī konsekvence nav iemesls izmisumam. Tas ir iemesls uzskatīt darbplūsmas dizainu par daļu no kontroles, nevis pieņemt, ka viena modeļa komponenta precizitātes pārbaude atrisina jautājumu.
Apsveriet vēl vienu skaidri hipotētisku dizainu. Aģentam tiek lūgts sagatavot lietas kopsavilkumu. Tas deleģē dokumentu ieguvi vienam komponentam un valodas normalizāciju citam. Trešais komponents redz nepilnīgu lauku un izmanto savienotu zināšanu avotu, lai aizpildītu robu. Galīgais kopsavilkums lasās raiti. Ja darbplūsma nav ierakstījusi trūkstošo lauku, avotu, kas izmantots tā aizpildīšanai, ar to saistīto pārliecību vai nenoteiktību un faktu, ka sākotnējais uzdevums atļāva tikai kopsavilkuma veidošanu, pārskatītājs nevar noteikt, vai viņš apstiprina kopsavilkumu vai jaunizveidotu faktu apgalvojumu. Problēma nav tā, ka pēdējais teikums izklausās dīvaini. Problēma ir tā, ka uzdevuma nozīme mainījās maršrutā.
Pareiza atbilde nav aizliegt deleģēšanu. Tā ir ierakstīt izmaiņu punktus. Jauns avots, jauns rīks, jauna datu kategorija, jauna darbību klase, būtiskas izmaiņas pārliecībā, neizdevusies kontrole, garāka par atļauto deleģēšanas ķēde vai priekšlikums šķērsot ārēju robežu, katrs no tiem var kļūt par iemeslu darba izvirzīšanai pārskatīšanai. Precīzi trigeri atšķirsies atkarībā no konteksta. Princips ir stabils: izmaiņas, kas būtu svarīgas atbildīgajam īpašniekam, nedrīkst palikt neredzamas tāpēc, ka tās notikušas starp komponentiem.
Šeit noder domāšana par drošības pamatojumu. Drošības pamatojums nav solījums, ka nekas nevar noiet greizi. Tā ir strukturēta argumentācija par to, kāpēc sistēma ir pieņemama noteiktam mērķim noteiktos apstākļos, ar redzamiem pierādījumiem, pieņēmumiem, kontrolēm un atlikušajiem riskiem. Rūpīgi piemērojot to aģenta darbplūsmai, tas nozīmē, ka apgalvojums nav tāds, ka aģenti kopumā ir droši. Apgalvojums ir šaurāks: šo maršrutu drīkst izmantot šim mērķim ar šiem ierobežojumiem, jo pastāv šīs kontroles un uzraudzības kārtība, un tas ir jāpārskata, kad norādītie pieņēmumi vairs nav spēkā.
Tad darbplūsmu ir vieglāk apstrīdēt. Operators var jautāt, vai darbību klase ir piešķirta pareizi. Riska īpašnieks var jautāt, vai recenzentam joprojām ir pietiekami daudz laika. Inženieris var jautāt, vai atkārtots mēģinājums var radīt dublētu efektu. Datu aizsardzības speciālists var jautāt, vai apakšuzdevums joprojām ir nepieciešams un samērīgs. Persona, kuru skar iznākums, var, ja piemērojamais regulējums to prasa, saņemt iespēju apstrīdēt lēmumu. Šie jautājumi nav birokrātija, kas pievienota pēc interesantā tehniskā darba. Tie ir darbs, lai tehnisko sistēmu padarītu atbildīgu organizācijā.
Metrikai jāievēro tā pati disciplīna. Deleģēto uzdevumu skaita skaitīšana mums kaut ko stāsta par apjomu, nevis par atbildīgu darbību. Noderīgāki mērījumi var ietvert ātrumu, kādā darbplūsma tiek eskalēta, jo robeža ir mainījusies, laiku, ko lēmums gaida pie vārtiem, būtisku darbību īpatsvaru ar pilnīgu lēmumu paketi, veiksmīgu atsaukumu skaitu vai gadījumu skaitu, kad politikas pārbaude atteica rīka izsaukumu. Šādiem mērījumiem joprojām ir nepieciešama definīcija un konteksts. Tos nekad nedrīkst izdomāt brošūrai. Bet ierakstu veidošana tā, lai tos varētu izmērīt, ir pazīme, ka atbildība tiek uztverta kā darbības īpašība.
Ieraksts ir vieta, kur saglabājas atbildība
Daudzaģentu sistēma rada neveiklu vēstures veidu. Tajā ir ziņojumi, rīku izsaukumi, starpposma izvades, politikas pārbaudes, modeļu versijas, laika informācija, atkārtoti mēģinājumi, mainīti uzdevumi un, iespējams, cilvēku apstiprinājumi. Saglabāt katru baitu mūžīgi nav ne nepieciešams, ne bieži vien atbilstoši. Saglabāt tikai galīgo atbildi parasti ir pārāk maz. Ierakstam ir jāsaglabā lēmumi un pierādījumi, kas izskaidro, kā darbplūsma pārgāja no pieprasījuma uz iznākumu.
Būtiskai darbībai šim ierakstam parasti būtu jāļauj recenzentam rekonstruēt dažus pamatfaktus. Kāds bija mērķis? Kura politika vai pilnvarojums padarīja darbu pieļaujamu? Kurš vai kas saņēma katru uzdevumu? Kas tika ierosināts pie katriem būtiskiem vārtiem? Kāda informācija tika izmantota priekšlikuma pamatošanai? Ar kādiem ierobežojumiem, brīdinājumiem vai neveiksmēm saskārās? Kam bija pilnvaras apstiprināt, apturēt vai atsaukt darbību? Kāda darbība stājās spēkā un kas notika pēc tam? Šie nav eksotiski jautājumi. Tie ir jautājumi, ko organizācija uzdod, kad tā vēlas zināt, vai lēmums bija tās lēmums.
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.
Norādiet atļauto un aizliegto darbību klases. Aģentam var būt atļauts lasīt lietas failu, izvilkt nosauktos laukus, salīdzināt ar politiku un sagatavot projektu. Tam var būt aizliegts mainīt avota ierakstu, sazināties ar ārēju personu, izvēlēties jaunu avotu vai veikt darījumu. Tie nav tikai uzvednes norādījumi. Rīku un darbplūsmas slānim tie būtu jāīsteno, kur vien tas ir praktiski iespējams. Politika, ko nevar pārbaudīt darbības brīdī, joprojām noder kā vadlīnija, taču kā kontroles mehānisms tā ir vājāka.
Norādiet īpašnieku un eskalācijas ceļu. Īpašnieks nav obligāti persona, kas noklikšķinās uz apstiprinājuma par katru darbību. Tas ir lomas turētājs, kurš ir atbildīgs par rezultātu un par lēmumu par to, kas notiek, kad ceļš nonāk pie neatbildēta jautājuma. Eskalācijas ceļš norāda nākamo instanci, kad aģents konstatē robežas pārkāpumu, nepietiekamus pierādījumus, konfliktu starp avotiem, politikas neatbilstību vai nosacījumu, ko sistēmai nav atļauts atrisināt. Rinda bez nosaukta lēmumu īpašnieka ir tikai kavēšanās ar optimistisku etiķeti.
Pievienojiet pierādījumu noteikumu. Noteikums var noteikt, kuri avoti ir autoritatīvi, vai aģents drīkst meklēt ārpus tiem, kā tiek attēlota nenoteiktība, kas obligāti jācitē priekšlikumā un kad konfliktējošs avots prasa pārskatīšanu. Tas ir īpaši svarīgi sistēmām, kas ģenerē plūstošu prozu. Plūstamība var likt robežas pārkāpumam izskatīties kā noderīgam pabeigtam darbam. Pierādījumu noteikums padara pieejamu pareizo jautājumu: vai darbplūsma palika tā materiāla ietvaros, ko tai bija atļauts izmantot?
Nosakiet laika, resursu un deleģēšanas ierobežojumus, kur tiem ir nozīme. Uzdevums, kas var turpināties bezgalīgi, var radīt izmaksas, operatīvu sastrēgumu vai spiedienu apstiprināt novecojušu rezultātu. Uzdevums, kas var atkārtoti deleģēt, var radīt ķēdi, ko neviens īpašnieks nevar viegli pārbaudīt. Ierobežots dizains nosaka, cik ilgi uzdevums paliek spēkā, cik daudz resursu tas var patērēt, vai tas drīkst izveidot apakšuzdevumu, kāds maksimālais dziļums ir atļauts un kas notiek, kad tiek sasniegts ierobežojums. Atbilde var būt automātiska pauze, eskalācija vai kontrolēta kļūme. Svarīgi ir tas, ka lēmums tiek pieņemts pirms ierobežojuma pārkāpšanas.
Visbeidzot, definējiet pabeigšanas nosacījumu. Pabeigts ne vienmēr nozīmē, ka aģents radīja tekstu. Tas var nozīmēt, ka recenzents saņēma pilnu paketi, politikas vārti pieņēma konkrētu darbību, lejupstraumes sistēma apstiprināja atgriezenisku atjauninājumu vai atbildīgais īpašnieks izvēlējās neturpināt. Pabeigšanas nosacījumi uztur darbplūsmu godīgu. Tie neļauj aģentam izturēties pret lēmuma ierosināšanu tā, it kā organizācija to jau būtu pieņēmusi.
Šie modeļi noder neatkarīgi no tā, vai darbplūsma satur vienu ar modeli darbināmu aģentu vai lielāku specializētu komponentu komandu. Vairāk aģentu automātiski nenozīmē vairāk procesu. Tie prasa, lai robežas starp lomām būtu skaidri izteiktas, nevis tikai netieši norādītas. Šīs izteikšanas izmaksas parasti ir daudz zemākas nekā izmaksas, mēģinot rekonstruēt pilnvaras pēc tam, kad vairākas sistēmas ir apmainījušās ar daļējiem norādījumiem un viena no tām ir saskārusies ar ārpasauli.
Deleģēšanai būtu jāpadara organizācija spējīgāka, nevis mazāk atbildīga
Aģentu sistēmas bieži tiek aprakstītas tā, it kā to vērtība būtu organizācijas izņemšanā no darba. Interesantāka perspektīva ir pretēja. Rūpīgi izstrādāta sistēma var padarīt organizatoriskās saistības skaidrākas: uzdevumam ir īpašnieks, deleģēšanai ir robeža, nozīmīgai darbībai ir pilnvaras, pārskatīšanai ir pierādījumi, apturēšanai ir drošs stāvoklis un ierakstu var atkārtoti atskaņot. Tas nav šķērslis noderīgai automatizācijai. Tas ir tas, kas ļauj automatizācijai uzņemties jēgpilnu darbu, neprasot cilvēkiem uzticēties neredzamai ķēdei.
Mēs izveidojām Dweve Nexus tieši ap šo atšķirību. Tā vietējā produkta dokumentācija apraksta ilgstošus uzdevumus, pilnvaras, kas tiek izvērtētas pret darbības kontekstu pirms rīcības, skaidras sadarbības struktūras, tostarp deleģēšanu, un ierakstu, kas tiek veidots darba gaitā. Attiecīgais apgalvojums ir apzināti pieticīgs. Tās ir dizaina īpašības, kuru mērķis ir padarīt deleģēto ceļu pārbaudāmu. Tās nav pierādījums tam, ka konkrēta ieviešana ir likumīga, droša vai piemērota, un tās nenovērš nepieciešamību organizācijai pašai izlemt savu mērķi, pilnvaras un cilvēka uzraudzību.
Plašākā mācība nav atkarīga no viena produkta. Modelis var izlemt, kā sadalīt uzdevumu. Aģents var lūgt citam aģentam darbu. Rīks var veikt darbību. Organizācijai joprojām ir jāizlemj, kur dzīvo pilnvaras. Tai tas jādara pirms deleģēšanas sākuma, nevis pēc tam, kad galīgais rezultāts ir nopulēts līdz kaut kam, ko ir grūti apšaubīt.
Tā ir atbilde uz virsrakstu. Lēmuma īpašnieks nav aģents, kuram gadījās runāt pēdējam. Tā ir persona vai loma, kurai organizācija ir piešķīrusi pilnvaras pieņemt lēmuma sekas, ar pietiekamu informāciju un spēku tās atteikt. Deleģēšana ir noderīga, ja tā padara šo personu spējīgāku. Tā kļūst bīstama, ja tā padara viņu neiespējamu atrast.
Avoti
- Regula (ES) 2024/1689, Mākslīgā intelekta akts, EUR-Lex
- Eiropas Padomes Pamatkonvencija par mākslīgo intelektu un cilvēktiesībām, demokrātiju un tiesiskumu
- EDPB atzinums 28/2024 par datu aizsardzības aspektiem personas datu apstrādē saistībā ar AI modeļiem
- Cilvēka faktori: ievads, Apvienotās Karalistes Veselības un drošības izpildinstitūcija
- Dweve Nexus