Kdo rozhoduje, když agent deleguje?

Delegace může učinit AI pracovní postup schopnějším, aniž by zvýšila jeho odpovědnost. Rozdíl spočívá v tom, zda pravomoc, důkazy a právo zastavit zůstávají...

Kdo rozhoduje, když agent deleguje?

Předání úkolu neznamená předání odpovědnosti

Agent deleguje úkol. Další agent shromažďuje materiály, porovnává záznamy, volá nástroj nebo připravuje doporučení. Třetí agent kontroluje výsledek. Práce se přesouvá a tento přesun může být užitečný. Může ale také vytvořit velmi starý manažerský problém v nové podobě: každý něco udělal, ale nikdo nedokáže říct, kdo měl právo rozhodnout.

Lákavá odpověď je agent, který provedl poslední krok. Obvykle je to také ta nejméně užitečná odpověď. Softwarová komponenta může vybrat trasu, vyžádat si další práci a odeslat instrukci do připojeného systému. Žádná z těchto věcí neurčuje, kdo přijal účel, kdo nastavil hranice, kdo mohl akci odmítnout nebo kdo musel být informován, když se podmínky změnily. Pouze to dokazuje, že v řetězci byl nějaký program.

Tento rozdíl se stává zásadním, když má pracovní postup důsledky. Navržená odpověď se může stát komunikací se zákazníkem. Klasifikace se může stát důvodem, proč je případ zařazen do konkrétní fronty. Srovnání se může stát doporučením k nákupu. Návrh platebního příkazu se může stát platbou. Každý krok může být technicky správný, a přesto organizačně neúplný. Systém vykonal práci delegování, aniž by vykonal práci autority.

K tomu, abychom problém viděli, není třeba vymýšlet dramatické selhání. Vezměme si záměrně hypotetický pracovní postup. Třídicí agent obdrží dotaz, požádá výzkumného agenta, aby prozkoumal příslušný materiál, odešle výsledek recenzentovi a poté připraví akci pro systém správy případů. Výzkumný agent není oprávněn jednat. Recenzent není oprávněn učinit výsledek případu účinným. Třídicí agent má přihlašovací údaje k nástroji. Organizace neurčila, zda mu tyto údaje umožňují výsledek potvrdit. Pracovní postup může na přehledové obrazovce vypadat spořádaně. Přesto se dostal k nejdůležitější otázce bez odpovědi.

Delegování není zmizení odpovědnosti. Je to odpovědnost, kterou je obtížnější vidět. Dobrý provozní návrh ji zviditelní. Říká, jaké je počáteční rozhodnutí, co lze delegovat, jaké podmínky se přesouvají spolu s úkolem, kdo může schválit nevratnou nebo závažnou akci, jaký záznam po předání zůstává a jak může člověk nebo systém zasáhnout, když trasa přestane být bezpečná. Od technologie se nežádá, aby měla morální odpovědnost. Žádá se od ní, aby zachovala odpovědnost organizace.

To je praktický význam odpovědnosti ve víceagentovém pracovním postupu. Není to ozdobná věta v politice a není to ani zpětné hledání nejbližšího zaměstnance, když se něco pokazí. Je to vlastnost trasy ještě před zahájením práce. Správná osoba může zkontrolovat, co bylo navrženo, pochopit, proč to bylo navrženo, vykonat autoritu, která jí byla přidělena, a zanechat záznam, který lze později zpochybnit.

Vznikající evropská pravidla pro umělou inteligenci jsou zde užitečná, protože se méně zajímají o divadelního člověka na konci toku než o podmínky, za kterých může dohled skutečně fungovat. Ustanovení o lidském dohledu v aktu o umělé inteligenci se vztahují na systémy s vysokým rizikem, nikoli na každé použití agenta. Tento limit je důležitý. Provozní otázky z aktu se ale dobře přenášejí: může určená fyzická osoba porozumět příslušným schopnostem a omezením, sledovat anomálie a neočekávaný výkon, vyhnout se přílišné důvěře, interpretovat výstup, ignorovat jej nebo jej zvrátit a přerušit systém do bezpečného stavu? Pracovní postup s mnoha agenty tyto otázky nezmenšuje. Znsobuje místa, kde může být odpověď ztracena.

Delegace může posunout práci dopředu. Nemůže však vymazat cestu, po které se autorita a námitky vracejí zpět.

Delegace je řetěz, ne mlha

Lidé delegují neustále. Manažer požádá kolegu, aby připravil zápis. Nákupní tým požádá odborníka, aby prověřil smluvní ustanovení. Klinik požádá laboratoř o výsledek. Člověk, který úkol přebírá, získává v práci vymezenou roli; automaticky tím nezíská všechny pravomoci, které má ten, kdo úkol zadal. Dobré organizace tento všední rozdíl zohledňují pomocí pracovních náplní, limitů schvalování, postupů, oddělení funkcí a záznamů. Dělají to proto, že schopnost a oprávnění jsou dvě různé věci.

Agentské systémy mají tendenci tento rozdíl stírat, protože agent dokáže popisovat, plánovat i vykonávat v jediném konverzačním rozhraní. Model možná umí vytvořit přesvědčivý plán, jak kontaktovat dodavatele. Obal nástroje může být technicky schopen zprávu odeslat. Orchestrační vrstva může být schopna tento obal zavolat bez pauzy. Tyto skutečnosti popisují schopnost. Nerozhodují o tom, zda má být zpráva odeslána, zda navrhovaný příjemce spadá do rozsahu, zda je vhodné danou informaci zveřejnit, ani kdo má nést následky, pokud je navrhovaný úkon chybný.

Pomáhá oddělit pět otázek, které se často spojují dohromady. Kdo dal úkolu jeho účel? Kdo může provádět přípravné práce? Kdo může delegovat dílčí úkol? Kdo může rozhodnout, že je navrhovaný úkon přijatelný? Kdo může tento úkon zviditelnit ve vnějším světě? Někdy jedna lidská role oprávněně drží několik z těchto odpovědí. Někdy musí být odděleny. Nejde o to vytvářet slavnostní ceremonii pro zápis s nízkým rizikem. Jde o to, abychom tiše nezaměňovali technickou schopnost za přenos institucionální autority.

Delegace by proto měla nést víc než jen pokyn. Měla by nést mandát. Mandát určuje cíl, ohraničený kontext, povolené vstupy, očekávaný výstup, úkony, které zůstávají zakázané, případný rozpočet nebo časový limit, podmínky vyžadující eskalaci a osobu nebo roli odpovědnou za výsledek. Přijímající agent pak může dělat užitečnou práci uvnitř viditelného rámce. Může požádat jiného agenta o analýzu. Nemůže rámec rozšířit jen proto, že ho napadne věrohodný další krok.

Toto není argument pro proměnu každé interakce ve schvalovací poradu. Je to argument pro volbu okamžiku, ve kterém si organizace přeje, aby došlo k rozhodnutí. Systém může navrhnout vysvětlení, aniž by se člověk díval na každou větu, pokud jsou účel, publikum, hranice zdrojů a pravidla zveřejňování již pevně stanoveny. Systém by neměl získat moc změnit nárok zákazníka jen proto, že stejná součást má přístup k příslušné databázi. Rozdíl je v důsledku, ne v inteligenci modelu.

Ten důsledek se často rozptyluje. Úkol může být v jedné fázi neškodný a v další závažný. Přečtení souboru může být rutinní. Jeho kombinace s jiným zdrojem může změnit citlivost materiálu. Příprava doporučení může být rutinní. Stisknutí tlačítka, které vytvoří právní, finanční nebo servisní důsledek, už rutinní být nemusí. Návrh správy, který se ptá pouze na to, zda je agent autonomní, tuto změnu stavu přehlíží. Užitečnější otázka je užší: autonomní k čemu, pro koho, za jakých podmínek a s čí autoritou?

Je tu jeden skromný nizozemský instinkt, který stojí za to zachovat. Pokud proces potřebuje tucet podpisů, razítek a laminovaný vývojový diagram, aby určil, kdo smí stisknout jedno tlačítko, nemusí to být triumf správy. Ale ani opačné uspořádání, kdy se pověření nástroje považuje za ústavní dohodu, není triumfem. Cílem je přiměřená cesta, která jasně vymezí závažnou autoritu, aniž by se kolem každé rutinní akce pořádala malá opera.

Evropský dohled je provozní požadavek

Akt o umělé inteligenci dává této myšlence nejjasnější právní vyjádření pro systémy umělé inteligence s vysokým rizikem. Článek 14 vyžaduje, aby byly navrženy a vyvinuty tak, aby je fyzické osoby mohly účinně dohlížet během jejich používání. Uvedeným účelem je předcházet rizikům pro zdraví, bezpečnost a základní práva nebo je minimalizovat tam, kde tato rizika mohou přetrvávat i přes splnění dalších požadavků. Opatření musí být přiměřená riziku, autonomii a kontextu použití. To je záměrně provozní norma. Neříká, že někdo v organizaci má obecný zájem o umělou inteligenci.

Toto ustanovení jde dál než obecný pokyn ponechat člověka ve smyčce. Podle toho, co je vhodné a přiměřené, musí být osoba pověřená dohledem schopna porozumět příslušným schopnostem a omezením, sledovat provoz a odhalovat anomálie, poruchy nebo neočekávaný výkon, zůstat si vědoma automatizačního zkreslení, interpretovat výstup, rozhodnout se výstup nepoužít nebo jej ignorovat, přepsat či zvrátit, a zasáhnout nebo přerušit systém do bezpečného stavu. Zákon z toho nedělá univerzální kontrolní seznam pro každý agentní systém. Ukazuje však, proč je razítko na konci procesu špatným modelem dohledu.

Nyní přidejte delegování. Pokud agent předá úkol jinému agentovi, musí role dohledu vidět víc než jen poslední větu vytvořenou posledním modelem. Potřebuje dostatek kontextu, aby pochopila, který agent navrhl dílčí úkol, jaké zdroje nebo nástroje byly použity, zda byl narušen limit politiky, zda byl výsledek změněn recenzentem a zda pozdější agent rozšířil rozsah. Jinak člověk vidí výstup, ale ne cestu, která jej vytvořila. To může stačit pro návrh s nízkými důsledky. Není to přesvědčivý základ pro přijetí závažného rozhodnutí.

Článek 26 činí organizační bod ještě jasnějším pro nasazující subjekty systémů s vysokým rizikem. Uvádí, že nasazující subjekty mají přidělit lidský dohled fyzickým osobám s potřebnou způsobilostí, školením, autoritou a podporou. Tato slova patří k sobě. Způsobilost bez autority vytváří dobře informovaného přihlížejícího. Autorita bez způsobilosti vytváří formálního vlastníka, který nemůže systém zpochybnit. Obojí bez podpory vytváří člověka, který má zasahovat do procesu, který nevidí, tempem, které nestíhá, a s informacemi, kterým nerozumí.

U multiagentní práce zahrnuje podpora podobu rozhraní a záznamu. Operátor nepotřebuje každý token, který model vygeneroval, ani každý interní pokus o opakování. Potřebuje navrhovanou akci, pojmenovaný účel, věcné důkazy, platnou politiku a limit, změny provedené od posledního kontrolního bodu, očekávaný účinek, možnou cestu zpět a důvod, proč byl případ eskalován. Nejde ani tak o to, aby dashboard působil uklidňujícím dojmem, jako spíš o snížení pravděpodobnosti, že člověk schválí odpověď jen proto, že systém udělal hledání alternativy vyčerpávající.

Širší institucionální souvislost zajišťuje Rámcová úmluva Rady Evropy o umělé inteligenci, lidských právech, demokracii a právním státu. Jejím účelem je zajistit, aby činnosti v životním cyklu systémů umělé inteligence byly v souladu s lidskými právy, demokracií a právním státem. Články 8 a 9 požadují transparentnost a dohled přizpůsobené konkrétním souvislostem a rizikům a odpovědnost za nepříznivé dopady. Úmluva nepředepisuje žádný vzor orchestrace agentů. Představuje však užitečnou korekci představy, že řetězec softwarových komponent může rozpustit odpovědnost veřejného orgánu nebo soukromého subjektu, který jej používá.

Tento širší pohled je důležitý, protože delegované rozhodnutí může ovlivnit víc než jen technický výkon. Může ovlivnit schopnost člověka rozhodnutí pochopit, napadnout je, získat nápravu nebo prostě vědět, která organizace je odpovědná. Pracovní postup může být složen z komponent od několika dodavatelů, modelů od několika poskytovatelů, nástrojů provozovaných jiným týmem a služby poskytované na základě veřejné zakázky. Skutečnost, že je řetězec technicky distribuovaný, neznamená, že dopad na jednotlivce je méně reálný. V praxi to činí jasné rozdělení rolí důležitějším.

Ochrana údajů přichází se stejným varováním z jiného směru. Práce Evropského sboru pro ochranu osobních údajů k modelům umělé inteligence zdůrazňuje, že analýza ochrany údajů zůstává kontextuální: organizace musí určit svou roli, identifikovat dotčené zpracování a uplatnit příslušné povinnosti, místo aby označení model umělé inteligence považovaly za výjimku z běžné odpovědnosti. Když se multiagentní pracovní postup dotýká osobních údajů, delegování by nemělo zastírat, kdo určuje účely a prostředky zpracování, který agent nebo nástroj dostává která data a zda je další předání pro daný úkol nezbytné. Dílčí úkol je stále krokem zpracování. Nazvat jej delegováním neznamená, že zmizí.

Žádné z toho nepřináší kouzelné řešení pro každý obtížný případ. Právní povinnosti závisí na použití, aktérech, datech a odvětví. Článek nemůže klasifikovat konkrétní systém. Může však formulovat disciplinovanou zásadu: pokud pracovní postup rozděluje práci, měl by ji rozdělovat způsobem, který zachovává schopnost identifikovat odpovědnost, včas zasáhnout, vyúčtovat cestu a reagovat na lidi dotčené výsledkem.

Člověk v procesu potřebuje skutečný proces

Lidský dohled se snadno zredukuje na obrazovku s tlačítkem schválení. Taková obrazovka může být užitečná. Může být také jen ceremoniálním předmětem. Otázkou je, zda má osoba, která ji používá, skutečnou volbu. Volba není smysluplná jen proto, že rozhraní zobrazuje dvě tlačítka. Závisí na tom, zda má osoba dostatek času, informací, kompetencí a institucionálního oprávnění rozhodnout se jinak.

Čas je nejméně okázalou součástí návrhu a často tou nejrozhodnější. Pokud systém odešle stovky návrhů za období, ve kterém by jeden posuzovatel mohl rozumně prozkoumat jen zlomek, organizace vytvořila frontu, nikoli dohled. Pokud návrh vyprší dřív, než si posuzovatel stihne opatřit kontext, systém učinil rychlost skutečným rozhodovatelem. Pokud je tým odměňován pouze za propustnost, dostal tichý pokyn, které tlačítko stisknout. Software tyto poměry nevyléčí tím, že přidá skóre spolehlivosti v jiném odstínu zelené.

Informace musí být přiměřené, nikoli vyčerpávající. Posuzovatel, který dostane pouze závěr, ho nemůže zpochybnit. Posuzovatel, který dostane surový přepis každé interakce agenta, ho obvykle také zpochybnit nemůže. Užitečný střed představuje rozhodovací balíček. Uvádí, jaká akce se navrhuje, proč je v souladu se stanoveným účelem, jaké podstatné důkazy ji podporují, jaká nejistota zůstává, který předpis nebo pravidlo je relevantní, jaký je navrhovaný účinek a co by se stalo, kdyby akce nebyla schválena. Balíček by měl odkazovat na podrobnější důkazy, ale neměl by v běžném případě vyžadovat archeologickou výpravu.

Způsobilost znamená víc než obecný kurz o AI. Pro daný úkol musí posuzovatel rozumět typu výstupu, známým omezením, která by mohla být podstatná, způsobu, jakým má pracovní postup fungovat, a příznakům, které vyžadují eskalaci. Člověk, který pozná vadnou fakturu od dodavatele, může být vhodný k posouzení návrhu souvisejícího s fakturami. Tentýž člověk nemusí být vhodný k posouzení jazykového pokrytí modelu nebo důsledků pro ochranu údajů. Přidělování dohledu je proto také personálním rozhodnutím.

Institucionální oprávnění je zkouškou, kterou mnoho návrhů tiše selhává. Posuzovatel musí mít možnost navrhovanou cestu odmítnout, pozastavit nebo změnit, aniž by byl považován za zdroj systémové závady. Potřebuje přístup k osobě nebo roli, která může rozhodnout, co bude dál. Potřebuje způsob, jak zaznamenat, že záležitost byla eskalována. A systém potřebuje bezpečný stav, ve kterém může práce čekat, aniž by byla omylem potvrzena opakováním, časovým limitem nebo jiným agentem, který původní instrukci považuje za nedokončenou záležitost.

Bezpečnostní inženýrství dlouho považovalo lidský výkon za součást systému, nikoli za poslední vrstvu laku. Britský úřad pro bezpečnost a ochranu zdraví při práci popisuje lidské faktory jako úkol, jednotlivce a organizaci dohromady a varuje před jejich posuzováním izolovaně. To je rozumný rámec pro dohled nad agenty. Posuzovatel není abstraktní lidská zátka do mezery v softwaru. Vykonává konkrétní úkol, s konkrétními informacemi a nástroji, uvnitř konkrétní organizace s konkrétními tlaky a omezeními. Kvalita kontroly závisí na tom všem.

Z tohoto důvodu dobrý návrh s člověkem ve smyčce začíná dřív, než se objeví tlačítko. Definuje, která rozhodnutí potřebují lidskou bránu, kdo bude bránu držet, jaké důkazy obdrží, kolik času úkol umožňuje, co se stane, když nebude přítomen, a zda má brána pravomoc nad samotnou akcí, nebo pouze nad vysvětlením akce. Pokud organizace nedokáže odpovědět na tyto otázky v klidné úterý, nebude to jasnější, až přijde případ s vysokými důsledky. Ani by neměla potřebovat smyšlenou krizi, aby si toho všimla.

Oprávnění by měla popisovat důsledek akce, ne pouze technický dosah pověření.

Jeden úkol, několik druhů oprávnění

Kompaktní model oprávnění může zjednodušit provoz agentního pracovního postupu. Nemusí být velkolepý. Začněte rozdílem mezi čtením, navrhováním, delegováním, schvalováním a zastavením. Role s oprávněním číst může prohlížet materiál nezbytný pro úkol. Role s oprávněním navrhovat může připravit možnou akci. Role s oprávněním delegovat může přidělit ohraničenou práci jinému aktérovi. Role s oprávněním schvalovat může uvést v účinnost důslednou akci. Role s oprávněním zastavit může pozastavit nebo přerušit postup, když jeho podmínky přestanou platit.

Nejde jen o úrovně. Komisař pro shodu může být schopen zastavit pracovní postup, ale nemůže schválit výsledek pro zákazníka. Specializovaný agent může být schopen navrhnout postup, ale nemůže delegovat novou práci mimo svou doménu. Manažer může být odpovědný za účel služby, a přesto nemusí být osobou oprávněnou uvolnit konkrétní platbu. Užitečnou vlastností není hierarchie sama o sobě. Je to to, že systém dokáže vyhodnotit, zda má konkrétní aktér v aktuálním kontextu příslušné oprávnění pro konkrétní akci.

Velkou část práce odvede kontext. Stejná navrhovaná akce může být v jedné situaci běžná a v jiné důsledná. Odeslání již schválené šablony na známou interní adresu může spadat do běžného komunikačního mandátu. Odeslání nově formulované zprávy s osobními údaji novému příjemci je něco jiného. Vrácení peněz v rámci stanoveného limitu může být delegováno na dobře otestovaný proces. Změna nároku, výmaz dat nebo externí závazek mohou vyžadovat rozhodnutí konkrétní osoby. Politika by měla tento rozdíl vyjádřit dříve, než je model požádán, aby kolem něj plánoval.

Důležitý je také rozdíl mezi potvrzením a schválením. Potvrzení zaznamenává, že někdo viděl zprávu. Schválení zaznamenává, že oprávněná osoba přijala definovanou akci s příslušným kontextem v definovaném bodě postupu. V konverzačním systému mohou vypadat podobně. Záznam by neměl. Pokud pozdější recenzent nedokáže rozlišit, jaká akce byla schválena a jaký účinek se očekával, organizace zaznamenala konverzaci, nikoli zachytila rozhodnutí.

I samotné delegování potřebuje limity. Agent, který dostane úkol porovnat tři stávající návrhy, může mít povoleno požádat výzkumného agenta o extrakci relevantních podmínek. Neměl by toto oprávnění považovat za pozvání ke kontaktování dodavatelů, získávání nových dat nebo přeformulování cíle zadávání zakázek. Hranici lze vyjádřit v politice, v rozsahu nástrojů, ve strukturované smlouvě o úkolu nebo ve všech třech. Důležité je, aby byla dostatečně vymahatelná k omezení postupu, ne pouze k popisu žádoucího chování zpětně.

Hloubka delegování je další limit, který stojí za zmínku. Člověk může dát jednomu agentovi úkol a stále si zachovat jasný přehled o jeho prvním předání. Po několika vnořených předáních může být původní účel technicky přítomen v metadatech, ale prakticky neviditelný. Organizace mohou nastavit maximální hloubku delegování pro určitou třídu práce, vyžadovat revizi v určité hloubce nebo zakázat delegátovi vytvářet další delegáty bez nového schválení. To jsou konstrukční volby, nikoli univerzální požadavky. Jsou nejužitečnější tam, kde delší řetězec ztěžuje rozpoznání, který aktér zavedl nový předpoklad nebo změnil efektivní rozsah.

Oprávnění k nástrojům musí být také odděleno od oprávnění modelu. Model může vybrat nástroj na základě plánu. Integrace nástroje by přesto měla ověřit, zda požadovaná akce, cíl, kategorie dat, limit prostředků a stav pracovního postupu volání umožňují. To není nedůvěra k modelu v morálním smyslu. Je to běžný návrh hranic. Dobře utvořený plán může být pro daný případ stále nevhodný a špatně utvořený plán by se neměl stát skutečným jen proto, že dosáhl pověření se širokým přístupem.

Totéž platí pro obnovu. Opakování pokusu není vždy neškodné. Opakování požadavku na přečtení veřejného dokumentu se liší od opakování požadavku, který odešle zprávu nebo provede platbu. Když delegovaný úkol selže, pracovní postup potřebuje explicitní volbu mezi opakováním, přesměrováním, eskalací, pozastavením a řízeným selháním. Zacházet s nimi jako s jedním generickým obslužným programem chyb je způsob, jak je provozní rozhodnutí tiše učiněno výchozím nastavením. Běhové prostředí agenta může možnosti zpřístupnit. Organizace musí rozhodnout, která možnost se vztahuje na kterou třídu akcí.

Selhání je často chybějící rozhodnutí

Když lidé slyší slovo selhání, často si představí agenta, který vytvoří nepravdivé tvrzení, nebo nástroj, kterému vyprší časový limit. Obojí může být důležité. Odhalující selhání v delegované práci jsou však často tišší. Úkol byl přidělen bez jasného vlastníka. Návrh překročil hranici, kterou nikdo nemodeloval. Recenzent viděl závěr, ale ne důkazy. Opakování pokračovalo po pozastavení. Člověk si problému všiml, ale neměl pravomoc akci zastavit. Rozhodnutí bylo učiněno, ale záznam uchoval pouze konečný výstup, nikoli podmínku, která jej učinila přijatelným.

Toto nejsou tvrzení o konkrétním incidentu. Jsou to režimy selhání odvozené ze struktury delegování samotného. Lze je nalézt i v lidských procesech. V softwaru se však mohou šířit tempem automatizace a být velmi konzistentně opakovány. Tato konzistence není důvodem k zoufalství. Je důvodem k tomu, abychom návrh pracovního postupu považovali za součást řízení, spíše než předpokládali, že testování přesnosti jedné součásti modelu věc vyřeší.

Zvažte další explicitně hypotetický návrh. Agent je požádán, aby připravil shrnutí případu. Deleguje extrakci dokumentů jedné součásti a normalizaci jazyka jiné. Třetí součást vidí neúplné pole a použije propojený zdroj znalostí k vyplnění mezery. Konečné shrnutí se čte plynule. Pokud pracovní postup nezaznamenal chybějící pole, zdroj použitý k jeho vyplnění, míru jistoty nebo nejistoty, která s ním přišla, a skutečnost, že původní úkol umožňoval pouze shrnutí, recenzent nemůže říci, zda schvaluje shrnutí, nebo nově vytvořené faktické tvrzení. Problém není v tom, že poslední věta zní divně. Problém je v tom, že se význam úkolu změnil uvnitř trasy.

Správnou reakcí není delegování zakázat, ale zaznamenávat body změny do záznamu. Nový zdroj, nový nástroj, nová kategorie dat, nová třída akcí, podstatná změna v míře jistoty, selhaná kontrola, řetězec delegování delší, než je povoleno, nebo návrh na překročení vnější hranice se může stát důvodem k předložení práce k přezkumu. Přesné spouštěče se budou lišit podle kontextu. Princip je stabilní: změna, která by byla důležitá pro odpovědného vlastníka, by neměla zůstat neviditelná jen proto, že k ní došlo mezi komponentami.

Zde se hodí myšlení v duchu bezpečnostního případu. Bezpečnostní případ není slib, že se nic nemůže pokazit. Je to strukturovaný argument o tom, proč je systém přijatelný pro definovaný účel za definovaných podmínek, s viditelnými důkazy, předpoklady, kontrolami a zbytkovými riziky. Při pečlivé aplikaci na pracovní postup agenta to znamená, že tvrzení není, že jsou agenti obecně bezpeční. Tvrzení je užší: tato trasa může být použita pro tento účel, s těmito omezeními, protože existují tyto kontroly a opatření dohledu, a musí být přehodnocena, když uvedené předpoklady přestanou platit.

Pracovní postup je pak snazší zpochybnit. Operátor se může zeptat, zda byla třída akcí správně přiřazena. Vlastník rizika se může zeptat, zda má recenzent stále dostatek času. Inženýr se může zeptat, zda by opakování mohlo vytvořit duplicitní účinek. Specialista na ochranu údajů se může zeptat, zda je dílčí úkol stále nezbytný a přiměřený. Osoba dotčená výsledkem může, pokud to příslušný rámec vyžaduje, dostat možnost rozhodnutí zpochybnit. Tyto otázky nejsou byrokracie přidaná po zajímavé technické práci. Jsou to práce na tom, aby byl technický systém odpovědný v rámci organizace.

Metriky by měly dodržovat stejnou disciplínu. Počítání počtu delegovaných úkolů nám říká něco o objemu, ne o odpovědném provozu. Užitečnější měřítka mohou zahrnovat míru, s jakou pracovní postup eskaluje, protože se změnila hranice, čas, který rozhodnutí čeká na bráně, podíl zásadních akcí s úplným rozhodovacím balíčkem, počet úspěšných zvratů nebo počet případů, kdy kontrola zásad odmítla volání nástroje. Taková měření stále potřebují definici a kontext. Nikdy by neměla být vymyšlena pro propagační materiál. Ale navržení záznamů tak, aby mohly být měřeny, je známkou toho, že se s odpovědností zachází jako s provozní vlastností.

Záznam je místo, kde odpovědnost přežívá

Multiagentní systém vytváří neohrabaný druh historie. Obsahuje zprávy, volání nástrojů, mezivýstupy, kontroly zásad, verze modelů, informace o načasování, opakování, změněná přiřazení a možná i lidská schválení. Uchovávat každý bajt navždy není nutné ani často vhodné. Uchovávat pouze konečnou odpověď je obvykle příliš málo. Záznam musí zachovat rozhodnutí a důkazy, které vysvětlují, jak pracovní postup přešel od požadavku k výsledku.

U zásadní akce by měl záznam obvykle umožnit recenzentovi rekonstruovat několik základních skutečností. Jaký byl cíl? Která zásada nebo mandát učinila práci přípustnou? Kdo nebo co obdrželo každé přiřazení? Co bylo navrženo u každé zásadní brány? Které informace byly použity na podporu návrhu? S jakými omezeními, varováními nebo selháními se setkal? Kdo měl pravomoc akci schválit, zastavit nebo zvrátit? Jaká akce nabyla účinnosti a co se stalo poté? To nejsou exotické otázky. To jsou otázky, které si organizace klade, když chce vědět, zda bylo rozhodnutí jejím rozhodnutím.

Záznam by měl odlišit provozní skutečnost od vysvětlení vytvořeného dodatečně. Pokud systém uvádí, že recenzent schválil určitý úkon, měl by záznam zachytit totožnost nebo roli recenzenta, úkon, který mu byl předložen, příslušný kontext a čas, kdy se schválení k danému úkonu vázalo. Pokud systém uvádí, že model vybral delegáta, měl by záznam uchovat pravidlo výběru, kandidáty nebo kritéria na úrovni odpovídající danému použití a výsledné přiřazení. Pozdější popis může čtenáři pomoci, ale neměl by nahrazovat událost, která nastala.

Verzování je zde důležité. Výstup agenta může být přegenerován. Zásady mohou být aktualizovány. Schéma nástroje se může změnit. Koncový bod modelu může být vyměněn. Pokud rozhodnutí závisí na konkrétní verzi promptu, zásad, modelu, zdroje znalostí nebo integrace, potřebuje záznam stabilní odkaz na tuto verzi. Jinak se přehrání stane představením: reprodukuje to, co organizace zrovna má, a výsledek označí za vysvětlení toho, co se stalo tehdy.

Vratnosti si zaslouží stejnou pozornost. Nařízení o umělé inteligenci se v souvislosti s dohledem nad vysoce rizikovými systémy výslovně zmiňuje o možnosti ignorovat, přepsat nebo zvrátit výstup a o možnosti přerušit systém tak, aby se zastavil v bezpečném stavu. Ve víceagentní trase není bezpečný stav nutně zastavený proces modelu. Může znamenat, že není odeslána žádná externí komunikace, že je pozastaven naplánovaný úkon, že není aktualizován navazující systém, že dočasné přihlašovací údaje již nejsou pro daný úkol použitelné a že jsou zachovány důkazy potřebné pro rozhodnutí o dalším postupu. To je provozní odvození z požadavku na dohled, nikoli citace zákona. Je to také užitečný návrhový test.

Bezpečný neznamená navždy zmrazený. Zastavený pracovní postup potřebuje řízenou cestu obnovení. Někdo musí rozhodnout, zda upravit úkol, zahodit návrh, znovu spustit ohraničenou část práce, použít jiný nástroj, získat další důkazy nebo opustit trasu. Čistý záznam toto rozhodnutí usnadňuje, protože další osobě sdělí, co je známo, o co bylo usilováno, proč byla práce zastavena a které účinky nastaly a které nenastaly. Bez takového záznamu se obnova stává další nestrukturovanou delegací, obvykle prováděnou pod větším tlakem než ta první.

Proto si uchovávání a přístup zaslouží vlastní rozhodnutí. Ne každý aktér by měl mít možnost číst každou stopu. Záznam může obsahovat osobní údaje, obchodně citlivé materiály nebo bezpečnostně relevantní podrobnosti. Řízený přístup však není totéž co žádný záznam. Důraz Úmluvy Rady Evropy na transparentnost, dohled, odpovědnost a zodpovědnost je užitečnou připomínkou, že hranice by měla být navržena, nikoli předpokládána. Organizace může zachovat odpovědnou trasu a zároveň omezit přístup k podrobnostem, které konkrétní recenzent skutečně potřebuje.

Co by měla smlouva o delegování zviditelnit

Smlouva o delegování může být datová struktura, schéma pracovního postupu, podepsaný balíček schválení nebo jejich kombinace. Na její formě záleží méně než na jejím obsahu. Měla by přijímajícímu aktérovi sdělit, co smí dělat, co nesmí dělat a jak bude práce posuzována. Když tyto omezující podmínky chybí, mají agenti tendenci kompenzovat to stále propracovanějšími instrukcemi. To může zlepšit konkrétní běh. Nevytváří to však organizační hranici, kterou by mohl vynucovat nástroj, recenzent nebo auditor.

Začněte zamýšleným účelem. Účel by měl být dostatečně konkrétní, aby vyloučil podobné úkoly. Porovnat podmínky v předložených návrzích se liší od najít nejlepšího dodavatele. Shrnout obdržené dokumenty se liší od zjistit chybějící skutečnosti. Navrhnout odpověď k posouzení se liší od sdělit rozhodnutí. Tento kontrast může působit pedantsky, dokud agent nepoužije širokou instrukci k tomu, aby podnikl rozumný, ale neoprávněný další krok. Pak je to rozdíl mezi užitečnou iniciativou a neomezeným mandátem.

Uveďte povolené a zakázané třídy činností. Agentovi může být povoleno přečíst spis, extrahovat pojmenovaná pole, porovnat je s politikou a připravit návrh. Může mu být zakázáno měnit zdrojový záznam, kontaktovat externí stranu, vybrat nový zdroj nebo provést transakci. Nejedná se pouze o pokyny v promptu. Vrstva nástrojů a pracovního postupu by je měla prosazovat tam, kde je to praktické. Politika, kterou nelze v okamžiku činnosti zkontrolovat, je stále užitečná jako vodítko, ale jako kontrola je slabší.

Jmenujte vlastníka a eskalační cestu. Vlastník nemusí být nutně osoba, která u každé činnosti klikne na schválení. Je to role odpovědná za výsledek a za rozhodnutí o tom, co se stane, když cesta narazí na nezodpovězenou otázku. Eskalační cesta určuje další autoritu, když agent zjistí porušení hranic, nedostatečné důkazy, konflikt mezi zdroji, nesoulad s politikou nebo stav, který systém není oprávněn řešit. Fronta bez jmenovaného vlastníka rozhodnutí je jen zpoždění s optimistickým označením.

Připojte pravidlo pro důkazy. Pravidlo může určit, které zdroje jsou směrodatné, zda agent smí vyhledávat i mimo ně, jak je reprezentována nejistota, co musí být citováno v návrhu a kdy konfliktní zdroj vyžaduje přezkum. To je důležité zejména u systémů, které generují plynulý text. Plynulost může způsobit, že porušení hranic vypadá jako užitečné dokončení. Pravidlo pro důkazy zpřístupňuje správnou otázku: zůstal pracovní postup v rámci materiálu, který byl oprávněn použít?

Stanovte časový, zdrojový a delegovací limit tam, kde na nich záleží. Úkol, který může pokračovat neomezeně dlouho, může vytvářet náklady, provozní zahlcení nebo tlak na potvrzení zastaralého výsledku. Úkol, který může opakovaně delegovat, může vytvořit řetězec, který žádný vlastník snadno nezkontroluje. Ohraničený návrh říká, jak dlouho úkol zůstává platný, kolik zdrojů může spotřebovat, zda může vytvořit podúkol, jaká maximální hloubka je povolena a co se stane při dosažení limitu. Odpovědí může být automatické pozastavení, eskalace nebo řízené selhání. Důležité je, že je rozhodnuto dříve, než je limit překročen.

Nakonec definujte podmínku dokončení. Dokončeno nemusí vždy znamenat, že agent vytvořil text. Může to znamenat, že recenzent obdržel kompletní balíček, že politická brána přijala konkrétní činnost, že navazující systém potvrdil vratnou aktualizaci nebo že odpovědný vlastník se rozhodl nepokračovat. Podmínky dokončení udržují pracovní postup poctivý. Brání agentovi, aby zacházel s aktem navržení rozhodnutí, jako by ho organizace učinila.

Tyto vzory jsou užitečné, ať už pracovní postup obsahuje jediného agenta podporovaného modelem, nebo větší tým specializovaných komponent. Více agentů automaticky nevyžaduje více procesů. Vyžadují, aby hranice mezi rolemi byly vyjádřeny, nikoli pouze naznačeny. Náklady na toto vyjádření jsou obvykle mnohem nižší než náklady na pokus o rekonstrukci autority poté, co si několik systémů vyměnilo dílčí pokyny a jeden z nich se dotkl vnějšího světa.

Delegace by měla organizaci učinit schopnější, ne méně odpovědnou

Systémy agentů jsou často popisovány, jako by jejich hodnota spočívala v odstranění organizace z práce. Zajímavější vyhlídka je opačná. Pečlivě navržený systém může učinit organizační závazky jasnějšími: úkol má vlastníka, delegace má hranici, důsledná činnost má autoritu, přezkum má důkazy, zastavení má bezpečný stav a záznam lze přehrát. To není překážkou užitečné automatizace. To je to, co umožňuje automatizaci převzít smysluplnou práci, aniž by lidé museli důvěřovat neviditelnému řetězci.

Dweve Nexus jsme postavili právě kolem tohoto rozlišení. Jeho místní produktová dokumentace popisuje dlouhodobé úkoly, autoritu posuzovanou vůči běhovému kontextu před provedením akce, explicitní struktury spolupráce včetně delegování a záznam vytvářený v průběhu práce. Příslušné tvrzení je záměrně skromné. Jde o návrhové vlastnosti, jejichž cílem je učinit delegovanou cestu kontrolovatelnou. Nejsou důkazem, že konkrétní nasazení je zákonné, bezpečné nebo vhodné, a nezbavují organizaci povinnosti rozhodnout o vlastním účelu, autoritě a lidském dohledu.

Širší ponaučení nezávisí na jediném produktu. Model může rozhodnout, jak rozdělit úkol. Agent může požádat jiného agenta o práci. Nástroj může provést akci. Organizace stále musí rozhodnout, kde autorita sídlí. Musí tak učinit před zahájením delegování, ne až poté, co je konečný výstup vyleštěn do podoby, kterou je obtížné zpochybnit.

To je odpověď na otázku v názvu. Vlastníkem rozhodnutí není agent, který náhodou promluvil jako poslední. Je jím osoba nebo role, které organizace přidělila autoritu přijmout důsledky rozhodnutí, s dostatkem informací a moci je odmítnout. Delegování je užitečné, když danou osobu činí schopnější. Stává se nebezpečným, když ji činí nemožnou najít.

Zdroje