Kto vlastní rozhodnutie, keď agent deleguje?

Delegácia môže zvýšiť schopnosti pracovného toku umelej inteligencie bez toho, aby zvýšila jeho zodpovednosť. Rozdiel spočíva v tom, či autorita, dôkazy a...

Kto vlastní rozhodnutie, keď agent deleguje?

Odovzdanie nevyprázdni stoličku

Agent deleguje úlohu. Ďalší agent zhromažďuje materiál, porovnáva záznamy, volá nástroj alebo pripravuje odporúčanie. Tretí agent kontroluje výsledok. Práca sa presúva a tento pohyb môže byť užitočný. Môže však tiež vytvoriť veľmi starý manažérsky problém v novej podobe: každý niečo urobil, no nikto nevie povedať, kto bol oprávnený rozhodnúť.

Lákavá odpoveď je agent, ktorý urobil posledné rozhodnutie. Je to však zvyčajne najmenej užitočná odpoveď. Softvérový komponent môže vybrať trasu, požiadať o ďalšiu prácu a odoslať inštrukciu do pripojeného systému. Žiadna z týchto vecí neurčuje, kto prijal účel, kto stanovil hranice, kto mohol odmietnuť akciu alebo kto musel byť informovaný, keď sa podmienky zmenili. Určuje to iba, že v reťazci bol program.

Tento rozdiel sa stáva ostrým, keď má pracovný postup dôsledky. Navrhnutá odpoveď sa môže stať komunikáciou so zákazníkom. Klasifikácia sa môže stať dôvodom, prečo je prípad zaradený do konkrétneho frontu. Porovnanie sa môže stať odporúčaním na nákup. Navrhnutý platobný príkaz sa môže stať platbou. Každý krok môže byť technicky kompetentný a napriek tomu organizačne neúplný. Systém vykonal prácu delegovania bez toho, aby vykonal prácu autority.

Netreba vymýšľať dramatické zlyhanie, aby sme problém videli. Zoberme si zámerne hypotetický pracovný postup. Triage agent prijme otázku, požiada výskumného agenta, aby preskúmal relevantný materiál, pošle výsledok recenzentovi a potom pripraví akciu pre systém riadenia prípadov. Výskumný agent nie je oprávnený konať. Recenzent nie je oprávnený uviesť výsledok prípadu do platnosti. Triage agent má poverenie k nástroju. Organizácia nešpecifikovala, či mu toto poverenie umožňuje potvrdiť výsledok. Pracovný postup môže na dashboarde vyzerať usporiadane. Napriek tomu sa dostal k najdôležitejšej otázke bez odpovede.

Delegovanie nie je zmiznutie zodpovednosti. Je to zodpovednosť, ktorá sa stala ťažšie viditeľnou. Dobrý operačný dizajn ju opäť uľahčí. Hovorí, aké je počiatočné rozhodnutie, čo možno delegovať, ktoré podmienky cestujú s úlohou, kto môže schváliť nezvratnú alebo závažnú akciu, aký záznam zostane po odovzdaní a ako môže človek alebo systém zasiahnuť, keď trasa už nie je bezpečná. Od technológie sa nežiada, aby mala morálne konanie. Žiada sa od nej, aby zachovala konanie organizácie nedotknuté.

To je praktický význam zodpovednosti vo viacagentovom pracovnom postupe. Nie je to dekoratívna veta v politike a nie je to retrospektívny hon na najbližšieho zamestnanca, keď sa niečo pokazí. Je to vlastnosť trasy pred začiatkom práce. Správna osoba môže preskúmať, čo bolo navrhnuté, pochopiť, prečo to bolo navrhnuté, vykonať autoritu, ktorá jej bola pridelená, a zanechať záznam, ktorý možno neskôr spochybniť.

Európske vznikajúce pravidlá AI sú tu užitočné, pretože sa menej zaujímajú o teatrálneho človeka na konci toku ako o podmienky, za ktorých môže dohľad skutočne fungovať. Ustanovenia o ľudskom dohľade v AI Act sa vzťahujú na vysokorizikové systémy, nie na každé použitie agenta. Tento limit je dôležitý. Operačné otázky v akte sa však dobre prenášajú: môže určená fyzická osoba pochopiť relevantné schopnosti a limity, monitorovať anomálie a neočakávaný výkon, vyhnúť sa nadmernému spoliehaniu, interpretovať výstup, ignorovať ho alebo ho zvrátiť a prerušiť systém do bezpečného stavu? Pracovný postup s mnohými agentmi tieto otázky nezmenšuje. Znsobuje miesta, kde sa odpoveď môže stratiť.

Delegovanie môže posunúť prácu dopredu. Nedokáže však vymazať cestu, po ktorej sa autorita a námietky vracajú späť.

Delegovanie je reťaz, nie hmla

Ľudia delegujú neustále. Manažér požiada kolegu, aby pripravil poznámku. Nákupný tím požiada odborníka, aby preskúmal zmluvnú podmienku. Klinik požiada laboratórium o výsledok. Osoba, ktorá úlohu dostane, získa v práci vymedzenú rolu; automaticky nezdedí každú právomoc, ktorú má ten, kto o ňu požiadal. Dobré organizácie tento všedný rozdiel zachytávajú v popisoch pracovných pozícií, limitoch schvaľovania, postupoch, oddelení právomocí a záznamoch. Robia to preto, lebo spôsobilosť a oprávnenie sú dve rozdielne veci.

Agentské systémy majú tendenciu tento rozdiel rozmazávať, pretože agent dokáže opísať, naplánovať a vykonať v rámci jedného konverzačného rozhrania. Model môže byť schopný vygenerovať presvedčivý plán na kontaktovanie dodávateľa. Technicky môže byť obal nástroja schopný správu odoslať. Orchestračná vrstva môže byť schopná zavolať tento obal bez prerušenia. Tieto skutočnosti opisujú spôsobilosť. Nerozhodujú o tom, či sa správa má odoslať, či navrhovaný príjemca patrí do rozsahu, či sú informácie vhodné na zverejnenie, ani o tom, kto by mal niesť následok, ak je navrhovaný krok nesprávny.

Pomáha oddeliť päť otázok, ktoré sa často spájajú do jednej. Kto dal úlohe jej účel? Kto môže vykonávať prípravné práce? Kto môže delegovať podúlohu? Kto môže rozhodnúť, že navrhovaný krok je prijateľný? Kto môže tento krok zrealizovať vo vonkajšom svete? Niekedy jedna ľudská rola oprávnene drží niekoľko z týchto odpovedí. Niekedy musia byť oddelené. Nejde o to vytvoriť zložitý ceremoniál pre poznámku s nízkym rizikom. Ide o to, aby sme technickú schopnosť ticho nepovažovali za prevod inštitucionálnej autority.

Delegovanie by preto malo niesť viac než len pokyn. Malo by niesť mandát. Mandát určuje cieľ, ohraničený kontext, povolené vstupy, očakávaný výstup, kroky, ktoré zostávajú zakázané, rozpočet alebo časový limit, ak prichádza do úvahy, podmienky vyžadujúce eskaláciu, a osobu alebo rolu zodpovednú za výsledok. Prijímajúci agent potom môže vykonávať užitočnú prácu v rámci viditeľného rámca. Môže požiadať iného agenta o analýzu. Nemôže rozšíriť rámec len preto, že ho napadne zdanlivo logický ďalší krok.

Toto nie je argument za premenu každej interakcie na schvaľovacie stretnutie. Je to argument za výber bodu, v ktorom organizácia chce, aby sa rozhodnutie uskutočnilo. Systém môže pripraviť vysvetlenie bez toho, aby sa človek pozeral na každú vetu, keď sú účel, publikum, hranica zdrojov a pravidlá zverejňovania už stanovené. Systém by nemal získať právomoc zmeniť nárok zákazníka len preto, že rovnaký komponent má prístup k príslušnej databáze. Rozdiel je v dôsledku, nie v inteligencii modelu.

Tento dôsledok sa často rozkladá na viacero krokov. Úloha môže byť v jednej fáze neškodná a v ďalšej závažná. Prečítanie súboru môže byť bežnou rutinou. Jeho skombinovanie s iným zdrojom môže zmeniť citlivosť materiálu. Príprava odporúčania môže byť bežnou rutinou. Stlačenie tlačidla, ktoré vytvorí právny, finančný alebo servisný výsledok, už rutinou byť nemusí. Návrh správy, ktorý sa pýta iba na to, či je agent autonómny, túto zmenu stavu prehliada. Užitočnejšia otázka je užšia: autonómny na čo, pre koho, za akých podmienok a s koho právomocou?

Je tu jedna mierna holandská črta, ktorú sa oplatí zachovať. Ak proces na to, aby sa zistilo, kto môže stlačiť jedno tlačidlo, potrebuje tucet podpisov, pečiatok a laminovaný vývojový diagram, nemusí ísť o triumf správy. Ale ani opačné usporiadanie, v ktorom sa poverenie nástroja považuje za ústavné riešenie, nie je triumfom. Cieľom je primeraná cesta, ktorá jasne vymedzí závažnú právomoc bez toho, aby sa okolo každej bežnej činnosti organizovala malá opera.

Európsky dohľad je prevádzkovou požiadavkou

Akt o umelej inteligencii dáva tejto myšlienke najjasnejšie právne vyjadrenie pre systémy umelej inteligencie s vysokým rizikom. Článok 14 vyžaduje, aby boli navrhnuté a vyvinuté tak, aby ich fyzické osoby mohli účinne dohliadať počas ich používania. Uvedeným účelom je predchádzať rizikám pre zdravie, bezpečnosť a základné práva alebo ich minimalizovať, ak tieto riziká môžu pretrvávať napriek iným požiadavkám. Opatrenia musia byť primerané riziku, autonómii a kontextu používania. Toto je zámerne prevádzkový štandard. Nehovorí, že nejaká osoba v organizácii sa o umelú inteligenciu všeobecne zaujíma.

Toto ustanovenie ide ďalej než všeobecný pokyn ponechať človeka v slučke. V závislosti od toho, čo je vhodné a primerané, musí byť osoba poverená dohľadom schopná pochopiť príslušné schopnosti a obmedzenia, monitorovať prevádzku a zisťovať anomálie, poruchy alebo neočakávaný výkon, zostať si vedomá zaujatosti automatizácie, interpretovať výstup, rozhodnúť sa výstup nepoužiť alebo ho ignorovať, prepísať či zvrátiť, a zasiahnuť alebo prerušiť systém do bezpečného stavu. Zákon z toho nerobí univerzálny kontrolný zoznam pre každý agentový systém. Ukazuje však, prečo je pečiatka na konci procesu chabým modelom dohľadu.

Teraz pridajte delegovanie. Ak agent odovzdá úlohu inému agentovi, rola dohľadu musí vidieť viac než len poslednú vetu vytvorenú posledným modelom. Potrebuje dostatok kontextu na to, aby pochopila, ktorý agent navrhol čiastkovú úlohu, ktoré zdroje alebo nástroje sa použili, či sa narazilo na limit politiky, či recenzent zmenil výsledok a či neskorší agent rozšíril rozsah. Inak človek vidí výstup, ale nie cestu, ktorá ho vytvorila. To môže stačiť na návrh s nízkymi dôsledkami. Nie je to presvedčivý základ na prijatie závažného rozhodnutia.

Článok 26 vyjadruje organizačný bod ešte jasnejšie pre prevádzkovateľov systémov s vysokým rizikom. Uvádza, že prevádzkovatelia majú prideliť ľudský dohľad fyzickým osobám s potrebnou kompetenciou, školením, právomocou a podporou. Tieto slová patria k sebe. Kompetencia bez právomoci vytvára dobre informovaného prizerajúceho sa. Právomoc bez kompetencie vytvára formálneho vlastníka, ktorý nemôže systém spochybniť. Oboje bez podpory vytvára človeka, od ktorého sa očakáva, že zasiahne do procesu, ktorý nevidí, tempom, ktoré nestíha, a s informáciami, ktorým nerozumie.

Pri práci s viacerými agentmi podpora zahŕňa podobu rozhrania a záznamu. Operátor nepotrebuje každý token, ktorý model vygeneroval, ani každý interný pokus o opakovanie. Potrebuje navrhovanú akciu, pomenovaný účel, materiálne dôkazy, platnú politiku a limit, zmeny vykonané od posledného kontrolného bodu, očakávaný účinok, možnú cestu späť a dôvod, prečo bol prípad eskalovaný. Nejde ani tak o to, aby dashboard vyzeral upokojujúco, ako o zníženie pravdepodobnosti, že človek schváli odpoveď len preto, že systém urobil alternatívu vyčerpávajúco ťažko nájditeľnou.

Rámcový dohovor Rady Európy o umelej inteligencii, ľudských právach, demokracii a právnom štáte vytvára širšiu inštitucionálnu súvislosť. Jeho účelom je zabezpečiť, aby činnosti v rámci životného cyklu systémov umelej inteligencie boli v súlade s ľudskými právami, demokraciou a právnym štátom. Články 8 a 9 vyžadujú transparentnosť a dohľad prispôsobené konkrétnym súvislostiam a rizikám, ako aj zodpovednosť a ručenie za nepriaznivé vplyvy. Dohovor nepredpisuje žiadny vzor orchestrácie agentov. Je však užitočnou korekciou predstavy, že reťazec softvérových komponentov môže rozpustiť zodpovednosť verejného orgánu alebo súkromného subjektu, ktorý ho používa.

Tento širší pohľad je dôležitý, pretože delegované rozhodnutie môže ovplyvniť viac než len technický výkon. Môže ovplyvniť schopnosť človeka porozumieť rozhodnutiu, napadnúť ho, získať nápravu alebo jednoducho vedieť, ktorá organizácia je zodpovedná. Pracovný postup môže pozostávať z komponentov od viacerých dodávateľov, modelov od viacerých poskytovateľov, nástrojov prevádzkovaných iným tímom a služby poskytovanej na základe verejnej zmluvy. Skutočnosť, že reťazec je technicky distribuovaný, nerobí vplyv na jednotlivca menej reálnym. V praxi to robí jasné rozdelenie úloh ešte dôležitejším.

Ochrana údajov dáva rovnaké varovanie z iného smeru. Práca Európskeho výboru pre ochranu údajov o modeloch umelej inteligencie zdôrazňuje, že analýza ochrany údajov zostáva kontextuálna: organizácie musia určiť svoju úlohu, identifikovať spracúvanie, ktoré vykonávajú, a uplatniť príslušné povinnosti, a nie považovať označenie model umelej inteligencie za výnimku z bežnej zodpovednosti. Keď pracovný postup s viacerými agentmi pracuje s osobnými údajmi, delegovanie by nemalo zakrývať, kto určuje účely a prostriedky spracúvania, ktorý agent alebo nástroj dostáva ktoré údaje a či je ďalšie odovzdanie potrebné na splnenie úlohy. Čiastková úloha je stále krokom spracúvania. Nazvať ju delegovaním ju nespôsobí, že zmizne.

Nič z toho neposkytuje zázračnú odpoveď na každý ťažký prípad. Právne povinnosti závisia od použitia, aktérov, údajov a sektora. Článok nemôže klasifikovať konkrétny systém. Môže však stanoviť disciplinovanú zásadu: ak pracovný postup rozdeľuje prácu, mal by ju rozdeľovať tak, aby sa zachovala schopnosť identifikovať právomoc, zasiahnuť včas, zodpovedať sa za postup a reagovať na ľudí dotknutých výsledkom.

Človek v slučke potrebuje skutočnú slučku

Ľudský dohľad sa ľahko zredukuje na obrazovku s tlačidlom schváliť. Táto obrazovka môže byť užitočná. Môže byť však aj ceremoniálnym objektom. Otázkou je, či osoba, ktorá ju používa, má zmysluplnú voľbu. Voľba nie je zmysluplná len preto, že rozhranie zobrazuje dve tlačidlá. Závisí od toho, či má osoba dostatok času, informácií, kompetencií a inštitucionálneho oprávnenia rozhodnúť sa inak.

Čas je najmenej pôvabná súčasť dizajnu a často tá najrozhodujúcejšia. Ak systém pošle stovky návrhov za obdobie, počas ktorého by jeden posudzovateľ mohol rozumne preskúmať len zlomok, organizácia si vytvorila rad, nie dohľad. Ak návrh vyprší skôr, než posudzovateľ získa kontext, systém urobil z rýchlosti skutočného rozhodovateľa. Ak je tím odmeňovaný len za priepustnosť, dostal tichý pokyn, ktoré tlačidlo stlačiť. Softvér tieto usporiadania nevylieči pridaním skóre dôveryhodnosti v inom odtieni zelenej.

Informácie musia byť primerané, nie vyčerpávajúce. Posudzovateľ, ktorý dostane len záver, ho nemôže spochybniť. Posudzovateľ, ktorý dostane surový prepis každej interakcie agenta, ho zvyčajne tiež nemôže spochybniť. Použiteľný stred je rozhodovací balík. Určuje, aká akcia sa navrhuje, prečo je v rámci stanoveného účelu, ktoré podstatné dôkazy ju podporujú, aká neistota zostáva, ktorá politika alebo pravidlo je relevantné, aký je navrhovaný účinok a čo by sa stalo, keby akcia nebola schválená. Balík by mal odkazovať na hlbšie dôkazy, ale nemal by si pre bežný prípad pýtať archeologickú expedíciu.

Kompetentnosť znamená viac než všeobecný kurz o AI. Pre danú úlohu musí posudzovateľ rozumieť typu výstupu, známym obmedzeniam, ktoré by mohli byť podstatné, spôsobu, akým má pracovný postup fungovať, a signálom, ktoré si vyžadujú eskaláciu. Človek, ktorý dokáže rozpoznať chybnú faktúru dodávateľa, môže byť vhodný na posudzovanie návrhu súvisiaceho s faktúrou. Tá istá osoba nemusí byť vhodná na posúdenie jazykovej pokrytosti modelu alebo dôsledku ochrany údajov. Prideľovanie dohľadu je preto aj personálnym rozhodnutím.

Inštitucionálne povolenie je test, ktorým mnohé návrhy potichu neprejdú. Posudzovateľ musí mať možnosť odmietnuť, pozastaviť alebo zmeniť navrhovaný postup bez toho, aby bol považovaný za zdroj systémovej poruchy. Potrebuje prístup k osobe alebo role, ktorá môže rozhodnúť, čo bude nasledovať. Potrebuje spôsob, ako zaznamenať, že záležitosť bola eskalovaná. A systém potrebuje bezpečný stav, v ktorom môže práca čakať bez toho, aby bola náhodne vykonaná opakovaním, časovým limitom alebo iným agentom, ktorý pôvodný pokyn považuje za nedokončenú záležitosť.

Bezpečnostné inžinierstvo už dlho považuje ľudský výkon za súčasť systému, nie za poslednú vrstvu laku. Britský Health and Safety Executive opisuje ľudské faktory ako úlohu, jednotlivca a organizáciu spolu a varuje pred ich posudzovaním izolovane. To je rozumný rámec pre dohľad nad agentmi. Posudzovateľ nie je abstraktná ľudská zátka tvarovaná na medzeru v softvéri. Vykonáva konkrétnu úlohu, s konkrétnymi informáciami a nástrojmi, v rámci konkrétnej organizácie s konkrétnymi tlakmi a limitmi. Kvalita kontroly závisí od všetkého tohto.

Z tohto dôvodu sa dobrý dizajn s človekom v slučke začína skôr, než sa objaví tlačidlo. Definuje, ktoré rozhodnutia potrebujú ľudskú bránu, kto bude bránu držať, aké dôkazy dostane, koľko času úloha umožňuje, čo sa stane, keď je neprítomný, a či má brána právomoc nad samotnou akciou alebo len nad vysvetlením akcie. Ak organizácia nevie odpovedať na tieto otázky v pokojný utorok, nebude to jasnejšie, keď príde prípad s vysokými následkami. A nemala by potrebovať imaginárnu krízu, aby si to všimla.

Oprávnenia by mali opisovať dôsledok konania, nielen technický dosah poverenia.

Jedna úloha, niekoľko druhov právomoci

Kompaktný model právomocí môže uľahčiť prevádzku pracovného postupu agenta. Nemusí byť veľkolepý. Začnite rozdielom medzi čítaním, navrhovaním, delegovaním, schvaľovaním a zastavením. Rola, ktorá môže čítať, môže nahliadať do materiálov potrebných na úlohu. Rola, ktorá môže navrhovať, môže pripraviť možný postup. Rola, ktorá môže delegovať, môže prideliť ohraničenú prácu inému aktérovi. Rola, ktorá môže schvaľovať, môže uviesť do platnosti závažný úkon. Rola, ktorá môže zastaviť, môže pozastaviť alebo prerušiť postup, keď jeho podmienky už neplatia.

Toto nie sú jednoducho hodnosti. Pracovník compliance môže mať možnosť zastaviť pracovný postup, ale nie schváliť výsledok pre zákazníka. Špecializovaný agent môže navrhnúť postup, ale nie delegovať novú prácu mimo svojej domény. Manažér môže byť zodpovedný za účel služby, a predsa nemusí byť osobou oprávnenou uvoľniť konkrétnu platbu. Užitočnou vlastnosťou nie je hierarchia sama osebe. Je ňou to, že systém dokáže vyhodnotiť, či má konkrétny aktér v aktuálnom kontexte príslušnú právomoc na konkrétny úkon.

Veľkú časť práce vykonáva kontext. Ten istý navrhovaný úkon môže byť v jednej situácii bežný a v inej závažný. Odoslanie už schválenej šablóny na známu internú adresu môže byť v rámci bežného komunikačného mandátu. Odoslanie novo formulovanej správy s osobnými údajmi novému príjemcovi je iné. Vrátenie platby v rámci stanoveného limitu možno delegovať na dobre otestovaný proces. Zmena nároku, výmaz údajov alebo externý záväzok môžu vyžadovať rozhodnutie konkrétnej osoby. Politika by mala tento rozdiel vyjadriť skôr, než sa model požiada, aby okolo neho plánoval.

Existuje tiež dôležitý rozdiel medzi schválením a potvrdením. Potvrdenie zaznamenáva, že niekto videl správu. Schválenie zaznamenáva, že oprávnená osoba prijala definovaný úkon s príslušným kontextom v určenom bode postupu. V konverzačnom systéme môžu vyzerať podobne. Záznam by nemal. Ak neskorší kontrolór nedokáže rozoznať, aký úkon bol schválený a aký účinok sa očakával, organizácia zaznamenala konverzáciu, nie zachytila rozhodnutie.

Aj samotné delegovanie potrebuje limity. Agent, ktorý dostane úlohu porovnať tri existujúce návrhy, môže mať povolené požiadať výskumného agenta o extrahovanie relevantných podmienok. Nemal by toto povolenie považovať za pozvanie kontaktovať dodávateľov, získavať nové údaje alebo preformulovať cieľ obstarávania. Hranicu možno vyjadriť v politike, v rozsahu nástrojov, v štruktúrovanej zmluve o úlohe alebo vo všetkých troch. Dôležité je, aby bola dostatočne vymáhateľná na to, aby obmedzovala postup, a nie len opisovala žiaduce správanie spätne.

Hĺbka delegovania je ďalší limit, ktorý stojí za zmienku. Človek môže dať jednému agentovi úlohu a stále si zachovať jasný prehľad o jeho prvom odovzdaní. Po niekoľkých vnorených odovzdaniach môže byť pôvodný účel technicky prítomný v metadátach, ale prakticky neviditeľný. Organizácie môžu nastaviť maximálnu hĺbku delegovania pre určitú triedu práce, vyžadovať kontrolu v konkrétnej hĺbke alebo zakázať delegátovi vytvárať ďalších delegátov bez nového schválenia. Toto sú dizajnové voľby, nie univerzálne požiadavky. Sú najužitočnejšie tam, kde dlhší reťazec sťažuje zistenie, ktorý aktér zaviedol nový predpoklad alebo zmenil efektívny rozsah.

Autorita nástrojov musí byť tiež oddelená od autority modelu. Model si môže vybrať nástroj na základe plánu. Integrácia nástroja by však mala stále kontrolovať, či požadovaná akcia, cieľ, kategória údajov, limit zdrojov a stav pracovného toku povoľujú vykonanie. Toto nie je nedôvera voči modelu v morálnom zmysle. Je to bežný návrh hraníc. Dobre zostavený plán môže byť stále nevhodný pre aktuálny prípad a zle zostavený plán by sa nemal stať skutočnosťou len preto, že sa dostal k povereniu so širokým prístupom.

To isté platí pre obnovu. Opakovaný pokus nie je vždy neškodný. Opakovaný pokus o prečítanie verejného dokumentu sa líši od opakovaného pokusu o odoslanie správy alebo vykonanie platby. Keď delegovaná úloha zlyhá, pracovný tok potrebuje explicitnú voľbu medzi opakovaním, presmerovaním, eskaláciou, pozastavením a riadeným zlyhaním. Zaobchádzanie s nimi ako s jedným generickým handlerom chýb je spôsob, akým sa prevádzkové rozhodnutie ticho prijíma predvolenými nastaveniami. Behové prostredie agenta môže sprístupniť možnosti. Organizácia musí rozhodnúť, ktorá možnosť sa vzťahuje na ktorú triedu akcií.

Zlyhanie je často chýbajúce rozhodnutie

Keď ľudia počujú slovo zlyhanie, často si predstavia agenta, ktorý vytvorí nepravdivé tvrdenie, alebo nástroj, ktorému vyprší čas. Oboje môže byť dôležité. Odhaľujúcejšie zlyhania v delegovanej práci sú však často tichšie. Úloha bola pridelená bez jasného vlastníka. Návrh prekročil hranicu, ktorú nikto nemodeloval. Recenzent videl záver, ale nie dôkazy. Opakovaný pokus pokračoval po pozastavení. Človek si všimol problém, ale nemal právomoc zastaviť akciu. Rozhodnutie padlo, ale záznam zachoval iba konečný výstup, nie podmienku, ktorá ho robila prijateľným.

Toto nie sú tvrdenia o konkrétnom incidente. Sú to spôsoby zlyhania odvodené zo štruktúry samotného delegovania. Možno ich nájsť aj v ľudských procesoch. V softvéri však môžu cestovať rýchlosťou automatizácie a byť veľmi konzistentne opakované. Táto konzistentnosť nie je dôvod na zúfalstvo. Je dôvodom považovať návrh pracovného toku za súčasť kontroly, a nie predpokladať, že testovanie presnosti jedného komponentu modelu vyrieši otázku.

Zvážte ďalší explicitne hypotetický návrh. Agent je požiadaný, aby pripravil zhrnutie prípadu. Deleguje extrakciu dokumentov jednému komponentu a normalizáciu jazyka druhému. Tretí komponent vidí neúplné pole a použije pripojený zdroj vedomostí na vyplnenie medzery. Konečné zhrnutie sa číta plynulo. Ak pracovný tok nezaznamenal chýbajúce pole, zdroj použitý na jeho vyplnenie, mieru istoty alebo neistoty, ktorá s ním prišla, a skutočnosť, že pôvodná úloha povoľovala iba sumarizáciu, recenzent nemôže povedať, či schvaľuje zhrnutie alebo novovytvorené faktické tvrdenie. Problém nie je v tom, že posledná veta znie čudne. Problém je v tom, že význam úlohy sa zmenil v rámci trasy.

Správnou reakciou nie je zakázať delegovanie. Je ňou zaznamenávať body zmeny. Nový zdroj, nový nástroj, nová kategória údajov, nová trieda akcií, podstatná zmena v miere istoty, zlyhaná kontrola, reťazec delegovania dlhší, než je povolené, alebo návrh na prekročenie externej hranice sa môžu stať dôvodom na predloženie práce na preskúmanie. Konkrétne spúšťače sa budú líšiť podľa kontextu. Princíp je stabilný: zmena, ktorá by bola dôležitá pre zodpovedného vlastníka, by nemala zostať neviditeľná len preto, že k nej došlo medzi komponentmi.

Toto je jedno miesto, kde je užitočné uvažovanie v duchu bezpečnostného prípadu. Bezpečnostný prípad nie je sľub, že sa nič nemôže pokaziť. Je to štruktúrovaný argument o tom, prečo je systém prijateľný na definovaný účel za definovaných podmienok, pričom sú viditeľné dôkazy, predpoklady, kontroly a zvyškové riziká. Ak sa to opatrne aplikuje na pracovný postup agenta, znamená to, že tvrdenie nie je, že agenti sú všeobecne bezpeční. Tvrdenie je užšie: táto trasa sa môže použiť na tento účel, s týmito obmedzeniami, pretože existujú tieto kontroly a opatrenia dohľadu, a musí sa prehodnotiť, keď uvedené predpoklady prestanú platiť.

Pracovný postup je potom ľahšie spochybniť. Operátor sa môže opýtať, či bola trieda akcií správne priradená. Vlastník rizika sa môže opýtať, či má recenzent stále dosť času. Inžinier sa môže opýtať, či by opakovanie pokusu mohlo vytvoriť duplicitný účinok. Špecialista na ochranu údajov sa môže opýtať, či je čiastková úloha naďalej nevyhnutná a primeraná. Osoba dotknutá výsledkom môže, ak to príslušný rámec vyžaduje, dostať možnosť spochybniť rozhodnutie. Tieto otázky nie sú byrokracia pridaná po zaujímavej technickej práci. Sú to práca, vďaka ktorej je technický systém zodpovedný v rámci organizácie.

Metriky by mali dodržiavať rovnakú disciplínu. Počítanie počtu delegovaných úloh nám hovorí niečo o objeme, nie o zodpovednej prevádzke. Užitočnejšie opatrenia môžu zahŕňať mieru, akou sa pracovný postup eskaluje, pretože sa zmenila hranica, čas, ktorý rozhodnutie čaká na bráne, podiel závažných akcií s kompletným rozhodovacím balíkom, počet úspešných zvrátení alebo počet prípadov, v ktorých politická kontrola odmietla volanie nástroja. Takéto merania stále potrebujú definíciu a kontext. Nikdy by sa nemali vymýšľať pre brožúru. Ale navrhovanie záznamov tak, aby sa dali merať, je znakom toho, že sa so zodpovednosťou zaobchádza ako s prevádzkovou vlastnosťou.

Záznam je miesto, kde zodpovednosť prežíva

Systém s viacerými agentmi vytvára nešikovný druh histórie. Má správy, volania nástrojov, medzivýstupy, kontroly politík, verzie modelov, informácie o načasovaní, opakovania, zmenené priradenia a možno aj ľudské schválenia. Uchovávať každý bajt navždy nie je nevyhnutné ani často vhodné. Uchovávať iba konečnú odpoveď je zvyčajne príliš málo. Záznam musí zachovať rozhodnutia a dôkazy, ktoré vysvetľujú, ako sa pracovný postup dostal od požiadavky k výsledku.

Pri závažnej akcii by mal záznam zvyčajne umožniť recenzentovi zrekonštruovať niekoľko základných faktov. Aký bol cieľ? Ktorá politika alebo mandát umožnila prácu? Kto alebo čo dostalo každé priradenie? Čo bolo navrhnuté na každej závažnej bráne? Ktoré informácie sa použili na podporu návrhu? S akými obmedzeniami, varovaniami alebo zlyhaniami sa stretlo? Kto mal právomoc schváliť, zastaviť alebo zvrátiť akciu? Aká akcia nadobudla účinnosť a čo sa stalo potom? Toto nie sú exotické otázky. Sú to otázky, ktoré si organizácia kladie, keď chce vedieť, či rozhodnutie bolo jej rozhodnutím.

Záznam by mal odlišovať prevádzkový fakt od vysvetlenia vytvoreného neskôr. Ak systém uvádza, že recenzent schválil akciu, udalosť by mala zaznamenať identitu alebo rolu recenzenta, akciu, ktorá mu bola zobrazená, relevantný kontext a čas, kedy sa schválenie viazalo na túto akciu. Ak systém uvádza, že model vybral delegáta, záznam by mal zachovať pravidlo výberu, kandidátov alebo kritériá na úrovni primeranej danému použitiu a výsledné priradenie. Neskorší opis môže čitateľovi pomôcť, ale nemal by nahrádzať udalosť, ktorá sa stala.

Verzie sú tu dôležité. Výstup agenta sa môže vygenerovať znova. Politika sa môže aktualizovať. Schéma nástroja sa môže zmeniť. Koncový bod modelu sa môže vymeniť. Ak rozhodnutie závisí od konkrétnej verzie výzvy, politiky, modelu, zdroja vedomostí alebo integrácie, záznam potrebuje stabilný odkaz na túto verziu. Inak sa prehratie stane predstavením: reprodukuje to, čo organizácia náhodou má teraz, a výsledok nazve vysvetlením toho, čo sa stalo vtedy.

Reverzibilita si zaslúži rovnakú pozornosť. Akt o umelej inteligencii sa v kontexte dohľadu nad vysokorizikovými systémami výslovne odvoláva na schopnosť ignorovať, prepísať alebo zvrátiť výstup a prerušiť systém tak, aby sa zastavil v bezpečnom stave. Vo viacagentovej trase bezpečný stav nemusí byť nevyhnutne zastavený proces modelu. Môže znamenať, že sa neodošle žiadna externá komunikácia, pozastavená akcia sa podrží, downstream systém sa neaktualizuje, dočasné poverenia sa už nedajú použiť na danú úlohu a zachovajú sa dôkazy potrebné na rozhodnutie o ďalšom postupe. Toto je prevádzkové vyvodenie z požiadavky na dohľad, nie citát zákona. Je to tiež užitočný dizajnový test.

Bezpečný neznamená navždy zmrazený. Zastavený pracovný postup potrebuje riadenú cestu obnovenia. Niekto sa musí rozhodnúť, či upraví úlohu, zahodí návrh, zopakuje ohraničenú časť práce, použije iný nástroj, vyhľadá ďalšie dôkazy alebo opustí trasu. Čistý záznam toto rozhodnutie uľahčuje, pretože ďalšej osobe hovorí, čo je známe, čo sa pokúšalo urobiť, prečo sa práca zastavila a ktoré účinky nastali a ktoré nie. Bez tohto záznamu sa obnova stane ďalšou neštruktúrovanou delegáciou, zvyčajne vykonanou pod väčším tlakom ako tá prvá.

Preto si uchovávanie a prístup vyžadujú vlastné rozhodnutia. Nie každý aktér by mal mať možnosť čítať každú stopu. Záznam môže obsahovať osobné údaje, obchodne citlivý materiál alebo podrobnosti týkajúce sa bezpečnosti. Ale riadený prístup nie je to isté ako žiadny záznam. Dôraz Dohovoru Rady Európy na transparentnosť, dohľad, zodpovednosť a zodpovednosť je užitočnou pripomienkou, že hranica by mala byť navrhnutá, nie predpokladaná. Organizácia môže zachovať zodpovednú trasu a zároveň obmedziť prístup k detailom, ktoré konkrétny recenzent skutočne potrebuje.

Čo by mala delegovaná zmluva sprístupniť

Delegovaná zmluva môže byť dátová štruktúra, schéma pracovného postupu, podpísaný balík schválení alebo ich kombinácia. Jej forma je menej dôležitá ako jej obsah. Mala by prijímajúcemu aktérovi povedať, čo môže robiť, čo nemôže robiť a ako sa bude práca posudzovať. Keď tieto obmedzenia chýbajú, agenti majú tendenciu kompenzovať to čoraz zložitejšími inštrukciami. To môže zlepšiť konkrétne spustenie. Nevytvára to organizačnú hranicu, ktorú by mohol presadzovať nástroj, recenzent alebo audítor.

Začnite so zamýšľaným účelom. Účel by mal byť dostatočne konkrétny na to, aby vylúčil podobné úlohy. Porovnať podmienky v predložených návrhoch je iné ako nájsť najlepšieho dodávateľa. Zhrnúť prijaté dokumenty je iné ako zistiť chýbajúce fakty. Navrhnúť odpoveď na posúdenie je iné ako komunikovať rozhodnutie. Tento kontrast môže znieť pedantne, kým agent nepoužije širokú inštrukciu na to, aby urobil rozumný, ale neoprávnený ďalší krok. Potom je to rozdiel medzi užitočnou iniciatívou a neobmedzeným mandátom.

Uveďte povolené a zakázané triedy činností. Agentovi môže byť dovolené prečítať spis, extrahovať pomenované polia, porovnať ich s politikou a pripraviť návrh. Môže mať zakázané meniť zdrojový záznam, kontaktovať externú stranu, vybrať nový zdroj alebo vykonať transakciu. Toto nie sú len pokyny v rámci výzvy. Vrstva nástrojov a pracovného postupu by ich mala presadzovať tam, kde je to praktické. Politika, ktorú nemožno skontrolovať v momente činnosti, je stále užitočná ako usmernenie, ale ako kontrola je slabšia.

Uveďte vlastníka a postup eskalácie. Vlastník nie je nevyhnutne osoba, ktorá klikne na schválenie pri každej činnosti. Je to rola zodpovedná za výsledok a za rozhodnutie o tom, čo sa stane, keď postup narazí na nezodpovedanú otázku. Postup eskalácie určuje vyššiu autoritu, keď agent zistí porušenie hraníc, nedostatočné dôkazy, konflikt medzi zdrojmi, nesúlad s politikou alebo stav, ktorý systém nie je oprávnený vyriešiť. Front bez určeného vlastníka rozhodnutí je len oneskorenie s optimistickým označením.

Pripojte pravidlo pre dôkazy. Pravidlo môže určiť, ktoré zdroje sú smerodajné, či agent môže hľadať aj mimo nich, ako sa vyjadruje neistota, čo musí byť citované v návrhu a kedy si konfliktný zdroj vyžaduje preskúmanie. Toto je obzvlášť dôležité pre systémy, ktoré generujú plynulý text. Plynulosť môže spôsobiť, že porušenie hraníc vyzerá ako užitočné dokončenie. Pravidlo pre dôkazy sprístupňuje správnu otázku: zostal pracovný postup v rámci materiálu, ktorý bol oprávnený použiť?

Stanovte hranice času, zdrojov a delegovania tam, kde sú dôležité. Úloha, ktorá môže pokračovať neobmedzene, môže vytvoriť náklady, prevádzkové preťaženie alebo tlak na potvrdenie zastaraného výsledku. Úloha, ktorá môže opakovane delegovať, môže vytvoriť reťazec, ktorý žiadny vlastník nedokáže ľahko preskúmať. Ohraničený návrh určuje, ako dlho úloha zostáva platná, koľko zdrojov môže spotrebovať, či môže vytvoriť podúlohu, aká maximálna hĺbka je povolená a čo sa stane po dosiahnutí limitu. Odpoveďou môže byť automatické pozastavenie, eskalácia alebo riadené zlyhanie. Dôležité je, že sa o tom rozhodne skôr, ako sa limit prekročí.

Nakoniec definujte podmienku dokončenia. Dokončené nemusí vždy znamenať, že agent vytvoril text. Môže to znamenať, že recenzent dostal kompletný balík, brána politiky prijala konkrétnu činnosť, nadväzujúci systém potvrdil reverzibilnú aktualizáciu alebo zodpovedný vlastník sa rozhodol nepokračovať. Podmienky dokončenia udržiavajú pracovný postup čestný. Zabraňujú tomu, aby agent považoval akt navrhnutia rozhodnutia za rozhodnutie organizácie.

Tieto vzory sú užitočné bez ohľadu na to, či pracovný postup obsahuje jediného agenta založeného na modeli alebo väčší tím špecializovaných komponentov. Viac agentov automaticky nevyžaduje viac procesov. Vyžadujú však, aby boli hranice medzi rolami vyjadrené, nie len naznačené. Náklady na toto vyjadrenie sú zvyčajne oveľa nižšie ako náklady na snahu zrekonštruovať autoritu po tom, čo si niekoľko systémov vymenilo čiastočné pokyny a jeden z nich sa dotkol vonkajšieho sveta.

Delegovanie by malo organizáciu posilniť, nie znížiť jej zodpovednosť

Systémy agentov sa často opisujú, akoby ich hodnota spočívala v odstraňovaní organizácie z práce. Zaujímavejšia perspektíva je opačná. Starostlivo navrhnutý systém môže objasniť organizačné záväzky: úloha má vlastníka, delegovanie má hranice, dôležitá činnosť má autoritu, preskúmanie má dôkazy, zastavenie má bezpečný stav a záznam možno prehrať. To nie je prekážkou užitočnej automatizácie. Práve to umožňuje automatizácii prevziať zmysluplnú prácu bez toho, aby ľudia museli dôverovať neviditeľnému reťazcu.

Dweve Nexus sme postavili práve na tomto rozlíšení. Jeho lokálna produktová dokumentácia opisuje trvalé úlohy, autoritu posudzovanú voči kontextu prostredia pred vykonaním akcie, explicitné štruktúry spolupráce vrátane delegovania a záznam vytváraný priebežne počas práce. Príslušné tvrdenie je zámerne skromné. Ide o dizajnové vlastnosti, ktoré majú delegovanú cestu spraviť preskúmateľnou. Nie sú dôkazom, že akékoľvek konkrétne nasadenie je zákonné, bezpečné alebo vhodné, a neodstraňujú potrebu, aby si organizácia určila vlastný účel, autoritu a ľudský dohľad.

Širšie ponaučenie nezávisí od jedného produktu. Model sa môže rozhodnúť, ako si rozdelí úlohu. Agent môže požiadať iného agenta o prácu. Nástroj môže vykonať akciu. Organizácia stále musí rozhodnúť, kde sa nachádza autorita. Musí tak urobiť pred začiatkom delegovania, nie až potom, čo sa konečný výstup vyleští do podoby, ktorú je ťažké spochybniť.

Toto je odpoveď na názov. Vlastníkom rozhodnutia nie je agent, ktorý náhodou prehovoril ako posledný. Je ním osoba alebo rola, ktorej organizácia pridelila autoritu prijať dôsledky rozhodnutia, s dostatkom informácií a moci ho odmietnuť. Delegovanie je užitočné, keď robí túto osobu schopnejšou. Stáva sa nebezpečným, keď ju robí nenájditeľnou.

Kto vlastní rozhodnutie, keď agent deleguje?