Vem äger beslutet när en agent delegerar?

Vem äger beslutet när en agent delegerar?

En överlämning tömmer inte stolen

En agent delegerar en uppgift. En annan agent samlar in material, jämför uppgifter, anropar ett verktyg eller förbereder en rekommendation. En tredje agent kontrollerar resultatet. Arbetet rör sig, och den rörelsen kan vara användbar. Den kan också skapa ett mycket gammalt ledningsproblem i en ny skepnad: alla har gjort något, men ingen kan säga vem som var behörig att fatta beslutet.

Den lockande lösningen är den agent som gjorde det sista anropet. Det är också oftast den minst användbara lösningen. En programvarukomponent kan välja en väg, begära mer arbete och skicka en instruktion till ett anslutet system. Inget av detta fastställer vem som accepterade syftet, vem som satte gränserna, vem som kunde ha vägrat åtgärden, eller vem som måste informeras när förutsättningarna ändrades. Det fastställer bara att ett program fanns i kedjan.

Den skillnaden blir skarp när ett arbetsflöde får konsekvenser. Ett föreslaget svar kan bli en kundkommunikation. En klassificering kan bli anledningen till att ett ärende hamnar i en viss kö. En jämförelse kan bli en inköpsrekommendation. En utkastad betalningsinstruktion kan bli en betalning. Varje steg kan vara tekniskt kompetent och ändå organisatoriskt ofullständigt. Systemet har utfört delegeringens arbete utan att utföra auktoritetens arbete.

Det finns ingen anledning att uppfinna ett dramatiskt misslyckande för att se problemet. Ta ett medvetet hypotetiskt arbetsflöde. En triageagent tar emot en fråga, ber en forskningsagent undersöka det relevanta materialet, skickar resultatet till en granskare och förbereder sedan en åtgärd för ett ärendehanteringssystem. Forskningsagenten är inte behörig att agera. Granskaren är inte behörig att göra ärendets utfall gällande. Triageagenten har en verktygsbehörighet. Organisationen har inte specificerat om den behörigheten tillåter att resultatet verkställs. Arbetsflödet kan se ordnat ut på en instrumentpanel. Det har ändå nått den viktigaste frågan utan svar.

Delegering är inte att ansvar försvinner. Det är ansvar som görs svårare att se. En bra operativ design gör det lättare igen. Den anger vad det ursprungliga beslutet är, vad som kan delegeras, vilka villkor som följer med uppgiften, vem som kan godkänna en oåterkallelig eller konsekvensrik åtgärd, vilken dokumentation som finns kvar efter överlämningen, och hur en person eller ett system kan ingripa när vägen inte längre är säker. Tekniken förväntas inte besitta moralisk agens. Den förväntas lämna organisationens agens intakt.

Det är den praktiska innebörden av ansvarsskyldighet i ett arbetsflöde med flera agenter. Det är inte en dekorativ rad i en policy, och det är inte en retrospektiv jakt på närmaste anställd när något går fel. Det är en egenskap hos vägen innan arbetet börjar. Rätt person kan granska vad som föreslogs, förstå varför det föreslogs, utöva den auktoritet som tilldelats dem och lämna efter sig en dokumentation som kan ifrågasättas i efterhand.

Europas framväxande AI-regler är användbara här eftersom de är mindre intresserade av en teatralisk människa i slutet av ett flöde än av de förutsättningar under vilka tillsyn faktiskt kan fungera. AI-förordningens bestämmelser om mänsklig tillsyn gäller högrisksystem, inte all användning av en agent. Den gränsen spelar roll. Men de operativa frågorna i förordningen fungerar väl i andra sammanhang: kan en utsedd fysisk person förstå de relevanta förmågorna och begränsningarna, övervaka avvikelser och oväntad prestanda, undvika överberoende, tolka utdata, bortse från eller vända på dem, och avbryta systemet till ett säkert tillstånd? Ett arbetsflöde med många agenter gör inte dessa frågor mindre. Det multiplicerar de platser där svaret kan gå förlorat.

Delegering är en kedja, inte en dimma

Människor delegerar ständigt. En chef ber en kollega att förbereda en promemoria. En upphandlingsenhet ber en expert att granska en avtalsklausul. En kliniker ber ett laboratorium om ett resultat. Personen som tar emot uppgiften får en definierad roll i arbetet; de ärver inte automatiskt alla befogenheter som den som frågade har. Välfungerande organisationer gör denna vardagliga åtskillnad med hjälp av arbetsbeskrivningar, attestgränser, rutiner, funktionsseparering och dokumentation. De gör det eftersom förmåga och tillstånd är två olika saker.

Agentsystem tenderar att sudda ut den åtskillnaden, eftersom en agent kan beskriva, planera och utföra i ett enda samtalsgränssnitt. En modell kan kanske ta fram en övertygande plan för att kontakta en leverantör. En verktygsinpackning kan tekniskt sett skicka meddelandet. Ett orkestreringslager kan kanske anropa den inpackningen utan paus. Dessa fakta beskriver förmåga. De avgör inte om meddelandet bör skickas, om den föreslagna mottagaren ligger inom ramen, om informationen är lämplig att lämna ut, eller vem som ska ta emot konsekvensen om den föreslagna åtgärden är fel.

Det hjälper att skilja på fem frågor som ofta blandas samman. Vem gav uppgiften dess syfte? Vem får utföra förberedande arbete? Vem får delegera en deluppgift? Vem får besluta att en föreslagen åtgärd är acceptabel? Vem får göra åtgärden gällande i omvärlden? Ibland innehas flera av dessa svar korrekt av en och samma mänsklig roll. Ibland måste de skiljas åt. Poängen är inte att skapa en omständlig ceremoni för en promemoria med låg risk. Poängen är att undvika att tyst behandla en teknisk förmåga som en överföring av institutionell befogenhet.

En delegering bör därför bära mer än en instruktion. Den bör bära ett mandat. Mandatet identifierar målet, det avgränsade sammanhanget, de tillåtna indata, det förväntade resultatet, de åtgärder som förblir förbjudna, budgeten eller tidsgränsen där det är relevant, de villkor som kräver eskalering, och den person eller roll som är ansvarig för resultatet. Den mottagande agenten kan då utföra nyttigt arbete inom ett synligt ramverk. Den kan be en annan agent om analys. Den kan inte utöka ramverket bara för att ett rimligt nästa steg dyker upp.

Detta är inte ett argument för att göra varje interaktion till ett godkännandemöte. Det är ett argument för att välja den punkt där organisationen vill att ett beslut ska ske. Ett system kan utarbeta en förklaring utan att en människa granskar varje mening när syftet, målgruppen, källgränsen och publiceringsreglerna redan är fastställda. Ett system bör inte få makten att ändra en kunds förmån bara för att samma komponent har åtkomst till den relevanta databasen. Skillnaden är konsekvensen, inte modellens intelligens.

Den konsekvensen är ofta fördelad. En uppgift kan vara ofarlig i ett skede och konsekvensrik i nästa. Att läsa en fil kan vara rutin. Att kombinera den med en annan källa kan ändra materialets känslighet. Att förbereda en rekommendation kan vara rutin. Att trycka på en knapp som skapar ett juridiskt, ekonomiskt eller tjänsterelaterat utfall kanske inte är det. En styrningsdesign som bara frågar om en agent är autonom missar detta tillståndsskifte. Den användbara frågan är snävare: autonom för att göra vad, för vem, mot vilka villkor och med vems befogenhet?

Det finns en blygsam holländsk instinkt värd att behålla här. Om en process kräver ett dussin signaturer, stämplar och ett laminerat flödesschema för att fastställa vem som får trycka på en knapp, är det kanske ingen styrningstriumf. Men den motsatta ordningen, där en verktygsbehörighet behandlas som en konstitutionell uppgörelse, är inte heller någon triumf. Målet är en proportionerlig väg som gör konsekvensrik befogenhet tydlig utan att iscensätta en liten opera kring varje rutinåtgärd.

Europeisk tillsyn är ett operativt krav

AI-förordningen ger det tydligaste juridiska uttrycket för denna idé när det gäller AI-system med hög risk. Artikel 14 kräver att de utformas och utvecklas så att fysiska personer effektivt kan övervaka dem medan de används. Det angivna syftet är att förebygga eller minimera risker för hälsa, säkerhet och grundläggande rättigheter där sådana risker kan kvarstå trots andra krav. Åtgärderna måste stå i proportion till risk, autonomi och användningssammanhang. Det är en medvetet operativ standard. Den säger inte att en person någonstans i organisationen allmänt är intresserad av AI.

Bestämmelsen går längre än en generisk uppmaning att hålla en människa i loopen. Beroende på vad som är lämpligt och proportionerligt ska den person som ansvarar för tillsynen ges möjlighet att förstå relevanta förmågor och begränsningar, övervaka driften och upptäcka avvikelser, funktionsfel eller oväntad prestanda, förbli medveten om automatiseringsbias, tolka utdata, besluta att inte använda en utdata eller att bortse från, åsidosätta eller vända den, samt ingripa i eller avbryta systemet till ett säkert tillstånd. Lagen gör inte detta till en universell checklista för varje agentsystem. Den visar däremot varför en stämpel i slutet av processen är en dålig modell för tillsyn.

Lägg nu till delegering. Om en agent överlämnar en uppgift till en annan agent måste tillsynsrollen kunna se mer än den sista meningen som producerats av den senaste modellen. Den behöver tillräckligt med sammanhang för att förstå vilken agent som föreslog deluppgiften, vilka källor eller verktyg som användes, om en policygräns nåddes, om ett resultat ändrades av en granskare och om en senare agent utökade omfattningen. Annars kan människan se en utdata men inte vägen som producerade den. Det kan räcka för ett utkast med låg konsekvens. Det är inte en övertygande grund för att acceptera ett konsekvensrikt beslut.

Artikel 26 gör organisationspoängen ännu tydligare för leverantörer av system med hög risk. Den säger att leverantörer ska tilldela mänsklig tillsyn till fysiska personer med nödvändig kompetens, utbildning, befogenhet och stöd. Dessa ord hör ihop. Kompetens utan befogenhet skapar en välinformerad åskådare. Befogenhet utan kompetens skapar en formell ägare som inte kan utmana systemet. Båda utan stöd skapar en person som förväntas ingripa i en process de inte kan se, i en takt de inte kan hålla, med information de inte kan tolka.

För arbete med flera agenter omfattar stödet gränssnittets och postens utformning. En operatör behöver inte varje token som en modell genererat eller varje internt försök. De behöver den föreslagna åtgärden, det namngivna syftet, den materiella bevisningen, den policy och den gräns som gäller, de ändringar som gjorts sedan den senaste granskningspunkten, den förväntade effekten, den möjliga återställningsvägen och orsaken till att ärendet eskalerades. Det handlar mindre om att få en instrumentpanel att se betryggande ut än om att minska risken för att en person godkänner ett svar för att systemet har gjort alternativet uttröttande att hitta.

Europarådets ramkonvention om artificiell intelligens och mänskliga rättigheter, demokrati och rättsstatlighet skapar den bredare institutionella kopplingen. Dess syfte är att säkerställa att verksamheter i AI-systemens livscykel är förenliga med mänskliga rättigheter, demokrati och rättsstatlighet. Artiklarna 8 och 9 kräver transparens och tillsyn som är anpassade till specifika sammanhang och risker, samt ansvarsskyldighet och ansvar för negativa effekter. Konventionen föreskriver inte ett mönster för agentorkestrering. Den utgör dock en användbar korrigering till idén att en kedja av programvarukomponenter kan upplösa ansvaret hos den offentliga myndighet eller privata aktör som använder den.

Det bredare perspektivet är viktigt eftersom ett delegerat beslut kan påverka mer än teknisk prestanda. Det kan påverka en persons möjlighet att förstå ett beslut, överklaga det, få rättelse eller helt enkelt veta vilken organisation som är ansvarig. Ett arbetsflöde kan bestå av komponenter från flera leverantörer, modeller från flera leverantörer, verktyg som drivs av ett annat team och en tjänst som levereras under ett offentligt kontrakt. Att kedjan är tekniskt distribuerad gör inte att påverkan på individen blir mindre verklig. I praktiken gör den en tydlig ansvarsfördelning viktigare.

Dataskydd ger samma varning från ett annat håll. Europeiska dataskyddsstyrelsens arbete med AI-modeller betonar att dataanalysen förblir kontextuell: organisationer måste fastställa sin roll, identifiera den behandling som är involverad och tillämpa de relevanta skyldigheterna i stället för att behandla etiketten AI-modell som ett undantag från vanlig ansvarsskyldighet. När ett arbetsflöde med flera agenter rör personuppgifter bör delegering inte dölja vem som bestämmer ändamålen och medlen för behandlingen, vilken agent eller vilket verktyg som tar emot vilka uppgifter och om nästa överlämning är nödvändig för uppgiften. En deluppgift är fortfarande ett behandlingssteg. Att kalla den för en delegering får den inte att försvinna.

Inget av detta ger ett magiskt svar på varje svårt fall. De rättsliga skyldigheterna beror på användningen, aktörerna, uppgifterna och sektorn. En artikel kan inte klassificera ett specifikt system. Men den kan ange en disciplinerad princip: om ett arbetsflöde fördelar arbete bör det fördela det på ett sätt som bevarar förmågan att identifiera auktoritet, ingripa i tid, redogöra för vägen och svara på de personer som påverkas av resultatet.

Personen i loopen behöver en verklig loop

Mänsklig tillsyn reduceras lätt till en skärm med en godkännandeknapp. Den skärmen kan vara användbar. Den kan också vara ett ceremoniellt föremål. Frågan är om personen som använder den har ett meningsfullt val. Ett val är inte meningsfullt bara för att gränssnittet visar två knappar. Det beror på om personen har tillräckligt med tid, information, kompetens och institutionellt tillstånd att besluta annorlunda.

Tid är den minst glamorösa delen av designen och ofta den mest avgörande. Om systemet skickar hundratals förslag under en period där en granskare rimligen bara skulle kunna hinna granska en bråkdel, har organisationen skapat en kö, inte tillsyn. Om förslaget upphör att gälla innan granskaren hinner få sammanhang, har systemet gjort hastigheten till den faktiska beslutsfattaren. Om ett team belönas enbart för genomströmning, har det fått en tyst instruktion om vilken knapp som ska tryckas. Programvara kan inte bota dessa arrangemang genom att lägga till en konfidenspoäng i en annan nyans av grönt.

Information måste vara proportionerlig, inte uttömmande. En granskare som bara får en slutsats kan inte utmana den. En granskare som får en rå utskrift av varje agentinteraktion kan vanligtvis inte utmana den heller. Den användbara mitten är ett beslutsunderlag. Det identifierar vilken åtgärd som föreslås, varför den ligger inom det angivna syftet, vilka materiella bevis som stöder den, vilken osäkerhet som återstår, vilken policy eller regel som är relevant, vad den föreslagna effekten är och vad som skulle hända om åtgärden inte godkänns. Underlaget bör länka till djupare bevis, men det bör inte kräva en arkeologisk expedition för det vanliga fallet.

Kompetens innebär mer än en generisk kurs om AI. För den aktuella uppgiften måste granskaren förstå typen av utdata, de kända begränsningar som kan vara relevanta, hur arbetsflödet är tänkt att fungera och de tecken som kräver eskalering. En person som kan känna igen en felaktig leverantörsfaktura kan vara väl lämpad att granska ett fakturarelaterat förslag. Samma person kanske inte är väl lämpad att bedöma en modells språktäckning eller en dataskyddskonsekvens. Att tilldela tillsyn är därför också ett bemanningsbeslut.

Institutionellt tillstånd är det test som många designer tyst misslyckas med. Granskaren måste kunna vägra, pausa eller ändra den föreslagna vägen utan att behandlas som källan till ett systemfel. De behöver tillgång till en person eller roll som kan besluta vad som händer härnäst. De behöver ett sätt att registrera att ärendet eskalerades. Och systemet behöver ett säkert tillstånd där arbete kan vänta utan att oavsiktligt genomföras av ett försök igen, en timeout eller en annan agent som tar den ursprungliga instruktionen som oavslutat arbete.

Säkerhetsteknik har länge behandlat mänsklig prestation som en del av systemet, snarare än ett sista lager av lack. Storbritanniens Health and Safety Executive beskriver mänskliga faktorer som uppgiften, individen och organisationen tillsammans, och varnar för att betrakta dem isolerat. Det är en förnuftig ram för agenttillsyn. En granskare är inte en abstrakt mänsklig formgjuten plugg för ett programvarugap. De utför en specifik uppgift, med specifik information och verktyg, inom en specifik organisation med specifika påfrestningar och begränsningar. Kvaliteten på kontrollen beror på allt detta.

Av den anledningen börjar en bra design med människan i loopen innan knappen visas. Den definierar vilka beslut som behöver en mänsklig grind, vem som ska hålla grinden, vilka bevis de ska få, hur mycket tid uppgiften tillåter, vad som händer när de är frånvarande och om grinden har auktoritet över själva åtgärden eller bara över en förklaring av åtgärden. Om organisationen inte kan svara på dessa frågor en lugn tisdag, kommer det inte att bli tydligare när ett fall med höga konsekvenser anländer. Det borde inte heller behöva en imaginär kris för att märka det.

En uppgift, flera typer av befogenhet

En kompakt befogenhetsmodell kan göra ett agentarbetsflöde lättare att hantera. Den behöver inte vara storslagen. Börja med skillnaden mellan att läsa, föreslå, delegera, genomföra och stoppa. En roll som får läsa kan granska det material som krävs för en uppgift. En roll som får föreslå kan förbereda en möjlig åtgärd. En roll som får delegera kan tilldela avgränsat arbete till en annan aktör. En roll som får genomföra kan verkställa en konsekvensrik åtgärd. En roll som får stoppa kan pausa eller avbryta en väg när dess villkor inte längre är uppfyllda.

Detta är inte bara nivåer. En regelefterlevnadsgranskare kan ha möjlighet att stoppa ett arbetsflöde men inte att genomföra ett kundresultat. En specialistagent kan ha möjlighet att föreslå en väg men inte att delegera nytt arbete utanför sitt område. En chef kan vara ansvarig för syftet med en tjänst men ändå inte vara den person som är behörig att frigöra en viss betalning. Den användbara egenskapen är inte en hierarki för dess egen skull. Det är att systemet kan bedöma om en viss aktör har relevant befogenhet för en viss åtgärd i det aktuella sammanhanget.

Sammanhanget gör mycket av arbetet. Samma föreslagna åtgärd kan vara vanlig i en omständighet och konsekvensrik i en annan. Att skicka en redan godkänd mall till en känd intern adress kan ligga inom ett rutinmässigt kommunikationsmandat. Att skicka ett nyskapat meddelande med personuppgifter till en ny mottagare är annorlunda. En återbetalning inom ett definierat tröskelvärde kan delegeras till en väletablerad process. En ändring av en förmån, en radering av data eller ett externt åtagande kan kräva ett namngivet mänskligt beslut. Policyn bör uttrycka den skillnaden innan modellen ombeds planera utifrån den.

Det finns också en viktig skillnad mellan ett godkännande och en bekräftelse. En bekräftelse registrerar att någon har sett ett meddelande. Ett godkännande registrerar att en behörig person har accepterat en definierad åtgärd, med relevant sammanhang, vid en definierad punkt i vägen. I ett konversationssystem kan dessa se likadana ut. Registret bör inte göra det. Om en senare granskare inte kan avgöra vilken åtgärd som godkändes och vilken effekt som förväntades, har organisationen loggat en konversation snarare än fångat ett beslut.

Delegeringen i sig behöver gränser. En agent som får i uppgift att jämföra tre befintliga förslag kan få tillåtas att be en forskningsagent att extrahera relevanta villkor. Den bör inte behandla den behörigheten som en inbjudan att kontakta leverantörer, införskaffa ny data eller omformulera upphandlingsmålet. Gränsen kan uttryckas i policy, i verktygets omfattning, i ett strukturerat uppdragskontrakt eller i alla tre. Det som spelar roll är att den är tillräckligt verkställbar för att begränsa vägen snarare än att bara beskriva det önskade beteendet i efterhand.

Delegationsdjup är ytterligare en gräns värd att nämna. En människa kan ge en agent en uppgift och fortfarande ha en tydlig bild av dess första överlämning. Efter flera kapslade överlämningar kan det ursprungliga syftet vara tekniskt närvarande i metadata men praktiskt taget osynligt. Organisationer kan sätta en maximal delegationsdjup för en viss typ av arbete, kräva granskning vid en viss nivå eller förbjuda en delegat att skapa ytterligare delegater utan ett nytt godkännande. Detta är designval, inte universella krav. De är mest användbara där en längre kedja gör det svårt att se vilken aktör som introducerade ett nytt antagande eller ändrade den faktiska omfattningen.

Verktygsbehörighet måste också vara åtskild från modellbehörighet. En modell kan välja ett verktyg baserat på en plan. Verktygsintegrationen bör ändå kontrollera om den begärda åtgärden, målet, datakategorin, resursgränsen och arbetsflödets tillstånd tillåter anropet. Detta är inte misstro mot modellen i moralisk mening. Det är vanlig gränsdesign. En välformulerad plan kan fortfarande vara olämplig för det aktuella fallet, och en dåligt formulerad plan bör inte bli verklig bara för att den nådde en inloggning med bred åtkomst.

Detsamma gäller återställning. Ett försök på nytt är inte alltid ofarligt. Att försöka igen med en begäran om att läsa ett offentligt dokument skiljer sig från att försöka igen med en begäran som skickar ett meddelande eller gör en debitering. När en delegerad uppgift misslyckas behöver ett arbetsflöde ett tydligt val mellan att försöka igen, omdirigera, eskalera, pausa och kontrollerat misslyckande. Att behandla dem som en generisk felhanterare är hur ett operativt beslut tyst fattas av standardinställningar. Agentens körningsmiljö kan göra alternativen tillgängliga. Organisationen måste besluta vilket alternativ som gäller för vilken åtgärdsklass.

Misslyckande är ofta ett uteblivet beslut

När människor hör misslyckande föreställer de sig ofta en agent som producerar ett falskt påstående eller ett verktyg som tar timeout. Båda kan vara betydelsefulla. De mer avslöjande misslyckandena i delegerat arbete är ofta tystare. Uppgiften tilldelades utan en tydlig ägare. Förslaget korsade en gräns som ingen hade modellerat. Granskaren kunde se slutsatsen men inte bevisen. Ett försök på nytt fortsatte efter en paus. En människa märkte ett problem men hade ingen behörighet att stoppa åtgärden. Ett beslut fattades, men registret bevarade bara det slutliga resultatet och inte villkoret som gjorde det acceptabelt.

Dessa är inte påståenden om en namngiven incident. De är misslyckandelägen som härrör från delegeringens struktur i sig. De kan också återfinnas i mänskliga processer. I programvara kan de dock färdas i automatiseringens takt och upprepas mycket konsekvent. Den konsekvensen är inte en anledning att misströsta. Det är en anledning att behandla arbetsflödesdesign som en del av kontrollen, snarare än att anta att noggrannhetstestning av en modellkomponent avgör frågan.

Betrakta ytterligare en uttryckligen hypotetisk design. En agent ombeds att sammanställa en ärendesammanfattning. Den delegerar dokumentextraktion till en komponent och språknormalisering till en annan. En tredje komponent ser ett ofullständigt fält och använder en ansluten kunskapskälla för att fylla luckan. Den slutliga sammanfattningen läter smidig. Om arbetsflödet inte har registrerat det saknade fältet, källan som användes för att fylla det, den säkerhet eller osäkerhet som följde med det, och det faktum att den ursprungliga uppgiften endast tillät sammanfattning, kan en granskare inte avgöra om de godkänner en sammanfattning eller ett nyskapat faktapåstående. Problemet är inte att den sista meningen låter märklig. Problemet är att uppgiftens innebörd ändrades inuti rutten.

Ett sunt svar är inte att förbjuda delegering. Det är att lägga in ändringspunkter i loggen. En ny källa, ett nytt verktyg, en ny datakategori, en ny åtgärdsklass, en väsentlig förändring av förtroendet, en misslyckad kontroll, en delegeringskedja som är längre än tillåtet, eller ett förslag om att korsa en extern gräns kan var och en bli ett skäl att lyfta fram arbetet för granskning. De exakta utlösarna varierar beroende på sammanhanget. Principen är stabil: en förändring som skulle vara viktig för den ansvarige ägaren ska inte förbli osynlig bara för att den inträffade mellan komponenter.

Detta är ett ställe där säkerhetsfallsresonemang är användbart. Ett säkerhetsfall är inte ett löfte om att ingenting kan gå fel. Det är ett strukturerat argument om varför ett system är acceptabelt för ett definierat syfte under definierade villkor, med bevis, antaganden, kontroller och kvarvarande risker synliga. Tillämpat noggrant på ett agentarbetsflöde innebär det att påståendet inte är att agenter i allmänhet är säkra. Påståendet är snävare: den här vägen får användas för det här syftet, med dessa begränsningar, eftersom dessa kontroller och tillsynsarrangemang finns, och den måste omprövas när de angivna antagandena inte längre håller.

Arbetsflödet blir då lättare att ifrågasätta. En operatör kan fråga om åtgärdsklassen tilldelades korrekt. En riskägare kan fråga om granskaren fortfarande har tillräckligt med tid. En ingenjör kan fråga om ett försök på nytt kan skapa en dubbel effekt. En dataspecialist kan fråga om deluppgiften fortfarande är nödvändig och proportionerlig. En person som påverkas av ett resultat kan, där den tillämpliga ramen kräver det, ges en väg att ifrågasätta beslutet. Dessa frågor är inte byråkrati som lagts till efter det intressanta tekniska arbetet. De är arbetet med att göra det tekniska systemet ansvarigt i en organisation.

Mätvärden bör följa samma disciplin. Att räkna antalet delegerade uppgifter säger något om volym, inte om ansvarsfull drift. Mer användbara mått kan inkludera den takt med vilken ett arbetsflöde eskalerar för att en gräns ändrades, den tid ett beslut väntar vid en grind, andelen konsekvensåtgärder med ett komplett beslutsunderlag, antalet framgångsrika återföringar, eller antalet fall där en policykontroll vägrade ett verktygsanrop. Sådana mätningar behöver fortfarande en definition och ett sammanhang. De ska aldrig uppfinnas för en broschyr. Men att utforma loggarna så att de kan mätas är ett tecken på att ansvarsskyldighet behandlas som en driftsegenskap.

Loggen är där ansvaret överlever

Ett multiagentsystem producerar en besvärlig typ av historik. Den har meddelanden, verktygsanrop, mellanliggande utdata, policykontroller, modellversioner, tidsinformation, försök på nytt, ändrade tilldelningar och kanske mänskliga godkännanden. Att spara varje byte för alltid är varken nödvändigt eller ofta lämpligt. Att bara spara det slutliga svaret är vanligtvis för lite. Loggen måste bevara de beslut och bevis som förklarar hur arbetsflödet korsade från en begäran till ett resultat.

För en konsekvensåtgärd bör loggen normalt låta en granskare rekonstruera några grundläggande fakta. Vad var målet? Vilken policy eller vilket mandat gjorde arbetet tillåtet? Vem eller vad fick varje tilldelning? Vad föreslogs vid varje konsekvensgrind? Vilken information användes för att stödja förslaget? Vilka begränsningar, varningar eller misslyckanden påträffades? Vem hade befogenhet att godkänna, stoppa eller återföra åtgärden? Vilken åtgärd trädde i kraft, och vad hände därefter? Dessa är inte exotiska frågor. De är de frågor en organisation ställer när den vill veta om ett beslut var dess beslut.

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.

Ange vilka åtgärdsklasser som är tillåtna respektive förbjudna. En agent kan få tillåtelse att läsa en ärendefil, extrahera namngivna fält, jämföra mot en policy och ta fram ett utkast. Den kan vara förbjuden att ändra en källpost, kontakta en extern part, välja en ny källa eller genomföra en transaktion. Detta är inte enbart instruktioner i prompten. Verktygs- och arbetsflödeslagret bör upprätthålla dem där det är praktiskt möjligt. En policy som inte kan kontrolleras i själva åtgärdsögonblicket är fortfarande användbar som vägledning, men den är svagare som styrmedel.

Ange ägare och eskaleringsväg. Ägaren är inte nödvändigtvis den person som klickar i godkänn på varje åtgärd. Det är den roll som ansvarar för utfallet och för att besluta vad som händer när vägen når en olöst fråga. Eskaleringsvägen anger nästa instans när agenten upptäcker en gränsöverträdelse, otillräcklig bevisning, en konflikt mellan källor, en policyavvikelse eller ett villkor som systemet inte har behörighet att lösa. En kö utan en namngiven beslutsägare är bara en fördröjning med en optimistisk etikett.

Koppla en bevisregel till processen. Regeln kan ange vilka källor som är auktoritativa, om agenten får söka utanför dem, hur osäkerhet representeras, vad som måste citeras i förslaget och när en motstridig källa kräver granskning. Detta är särskilt viktigt för system som genererar flytande text. Flyt kan få en gränsöverträdelse att se ut som ett användbart slutförande. En bevisregel gör rätt fråga tillgänglig: höll sig arbetsflödet inom det material som det var auktoriserat att använda?

Sätt en gräns för tid, resurser och delegering där det har betydelse. En uppgift som kan pågå i all oändlighet kan skapa kostnader, operativ trängsel eller press att genomföra ett inaktuellt resultat. En uppgift som kan delegera upprepade gånger kan skapa en kedja som ingen ägare lätt kan överblicka. En avgränsad design anger hur länge uppgiften förblir giltig, hur mycket resurs den kan förbruka, om den får skapa en deluppgift, vilket maximalt djup som tillåts och vad som händer när en gräns nås. Svaret kan vara automatisk paus, eskalering eller kontrollerat fel. Det viktiga är att det beslutas innan gränsen passeras.

Definiera slutligen villkoret för slutförande. Slutfört betyder inte alltid att agenten har producerat text. Det kan betyda att en granskare har fått ett komplett paket, att en policygrind har accepterat en specifik åtgärd, att ett nedströms system har bekräftat en reversibel uppdatering, eller att en ansvarig ägare har valt att inte gå vidare. Slutförandevillkor håller arbetsflödet ärligt. De hindrar en agent från att behandla själva förslaget till beslut som om organisationen redan hade fattat det.

Dessa mönster är användbara oavsett om arbetsflödet innehåller en enda modellbaserad agent eller ett större team av specialiserade komponenter. Fler agenter kräver inte automatiskt mer process. Däremot kräver de att gränserna mellan roller uttrycks snarare än antyds. Kostnaden för att uttrycka dem är i allmänhet mycket lägre än kostnaden för att försöka rekonstruera auktoritet efter att flera system har utbytt ofullständiga instruktioner och ett av dem har rört omvärlden.

Delegering bör göra organisationen mer kapabel, inte mindre ansvarstagande

Agentsystem beskrivs ofta som om deras värde ligger i att ta bort organisation från arbetet. Den mer intressanta möjligheten är den motsatta. Ett omsorgsfullt utformat system kan göra organisatoriska åtaganden tydligare: en uppgift har en ägare, en delegering har en gräns, en viktig åtgärd har en auktoritet, en granskning har bevisning, ett stopp har ett säkert tillstånd och en post kan spelas upp igen. Det är inte ett hinder för användbar automatisering. Det är det som gör att automatisering kan ta sig an meningsfullt arbete utan att be människor att lita på en osynlig kedja.

Vi byggde Dweve Nexus utifrån denna distinktion. Dess lokala produktdokumentation beskriver varaktiga uppgifter, auktoritet som utvärderas mot runtime-kontext innan åtgärd, explicita samarbetsstrukturer inklusive delegering, och en logg som skrivs medan arbetet pågår. Det relevanta påståendet är medvetet blygsamt. Dessa är designegenskaper som syftar till att göra en delegerad väg inspekterbar. De är inte bevis på att en viss driftsättning är laglig, säker eller lämplig, och de undanröjer inte behovet för en organisation att själv besluta om sitt syfte, sin auktoritet och sin mänskliga tillsyn.

Den bredare lärdomen beror inte på en enda produkt. En modell kan besluta hur en uppgift ska delas upp. En agent kan be en annan agent om arbete. Ett verktyg kan utföra en åtgärd. Organisationen måste ändå besluta var auktoriteten ligger. Den måste göra det innan delegeringen börjar, inte efter att ett slutresultat har putsats till något som är svårt att ifrågasätta.

Det är svaret på titeln. Ägaren av ett beslut är inte den agent som råkade tala sist. Det är den person eller roll som organisationen tilldelade auktoriteten att acceptera beslutets konsekvens, med tillräcklig information och makt att avböja det. Delegering är användbar när den gör den personen mer kapabel. Den blir farlig när den gör personen omöjlig att hitta.

Källor

• Regulation (EU) 2024/1689, the Artificial Intelligence Act, EUR-Lex
• Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law
• EDPB Opinion 28/2024 on data-protection aspects of processing personal data in the context of AI models
• Human factors: introduction, UK Health and Safety Executive
• Dweve Nexus