Hvem ejer beslutningen, når en agent delegerer?
En overdragelse tømmer ikke stolen
En agent delegerer en opgave. En anden agent indsamler materiale, sammenligner registreringer, kalder et værktøj eller forbereder en anbefaling. En tredje agent kontrollerer resultatet. Arbejdet bevæger sig, og den bevægelse kan være nyttig. Den kan også skabe et meget gammelt ledelsesproblem i en ny form: alle har gjort noget, men ingen kan sige, hvem der havde ret til at træffe beslutningen.
Det fristende svar er den agent, der foretog det sidste kald. Det er også som regel det mindst nyttige svar. En softwarekomponent kan vælge en rute, bede om mere arbejde og sende en instruktion til et tilsluttet system. Ingen af disse ting fastslår, hvem der accepterede formålet, hvem der satte grænsen, hvem der kunne have afvist handlingen, eller hvem der skulle informeres, når betingelserne ændrede sig. Det fastslår blot, at et program var i kæden.
Den skelnen bliver skarp, når en arbejdsgang har konsekvenser. Et foreslået svar kan blive en kundekommunikation. En klassificering kan blive grunden til, at en sag placeres i en bestemt kø. En sammenligning kan blive en indkøbsanbefaling. En udkastet betalingsinstruks kan blive en betaling. Hvert trin kan være teknisk kompetent og stadig være organisatorisk ufuldstændigt. Systemet har udført delegeringens arbejde uden at udføre autoritetens arbejde.
Der er ingen grund til at opfinde en dramatisk fejl for at se problemet. Tag en bevidst hypotetisk arbejdsgang. En triageagent modtager et spørgsmål, beder en forskningsagent om at inspicere det relevante materiale, sender resultatet til en gennemgåer og forbereder derefter en handling i et sagsbehandlingssystem. Forskningsagenten er ikke autoriseret til at handle. Gennemgåeren er ikke autoriseret til at gøre sagens udfald effektivt. Triageagenten har en værktøjslegitimation. Organisationen har ikke specificeret, om denne legitimation tillader agenten at forpligte resultatet. Arbejdsgangen kan se velordnet ud på et dashboard. Den har ikke desto mindre nået det vigtigste spørgsmål uden et svar.
Delegering er ikke ansvarets forsvinden. Det er ansvar gjort sværere at se. Et godt operationelt design gør det lettere igen. Det siger, hvad den indledende beslutning er, hvad der kan delegeres, hvilke betingelser der følger med opgaven, hvem der kan godkende en irreversibel eller konsekvensrig handling, hvilken registrering der forbliver efter overdragelsen, og hvordan en person eller et system kan gribe ind, når ruten ikke længere er sikker. Teknologien bliver ikke bedt om at besidde moralsk handlekraft. Den bliver bedt om at lade organisationens handlekraft forblive intakt.
Det er den praktiske betydning af ansvarlighed i en multiagent-arbejdsgang. Det er ikke en dekorativ linje i en politik, og det er ikke en retrospektiv jagt på den nærmeste medarbejder, når noget går galt. Det er en egenskab ved ruten, før arbejdet begynder. Den rette person kan inspicere, hvad der blev foreslået, forstå, hvorfor det blev foreslået, udøve den autoritet, der er tildelt vedkommende, og efterlade en registrering, der kan udfordres bagefter.
Europas nye AI-regler er nyttige her, fordi de er mindre interesserede i et teatralsk menneske for enden af en strøm end i de betingelser, hvorunder tilsyn faktisk kan fungere. AI-forordningens bestemmelser om menneskeligt tilsyn gælder for højrisikosystemer, ikke for enhver brug af en agent. Den begrænsning betyder noget. Men de operationelle spørgsmål i forordningen fungerer godt: kan en udpeget fysisk person forstå de relevante kapaciteter og begrænsninger, overvåge for uregelmæssigheder og uventet ydeevne, undgå overdreven tillid, fortolke output, se bort fra eller omgøre det og afbryde systemet til en sikker tilstand? En arbejdsgang med mange agenter gør ikke disse spørgsmål mindre. Den multiplicerer de steder, hvor svaret kan gå tabt.
Delegation er en kæde, ikke en tåge
Folk delegerer konstant. En leder beder en kollega om at udarbejde et notat. Et indkøbsteam beder en ekspert om at gennemgå en kontraktklausul. En kliniker beder et laboratorium om et resultat. Den person, der modtager opgaven, får en defineret rolle i arbejdet; de arver ikke automatisk enhver autoritet, som den, der bad om det, har. Gode organisationer gør denne dagligdags sondring med jobbeskrivelser, godkendelsesgrænser, procedurer, funktionsadskillelse og registreringer. De gør det, fordi kompetence og tilladelse er to forskellige ting.
Agentsystemer har en tendens til at sløre den sondring, fordi en agent kan beskrive, planlægge og udføre i én samtaleflade. En model kan måske generere en overbevisende plan for at kontakte en leverandør. En værktøjsindpakning kan teknisk set være i stand til at sende beskeden. Et orkestreringslag kan måske kalde den indpakning uden en pause. Disse fakta beskriver kompetence. De afgør ikke, om beskeden skal sendes, om den foreslåede modtager er inden for rammen, om oplysningerne er passende at videregive, eller hvem der skal acceptere konsekvensen, hvis den foreslåede handling er forkert.
Det hjælper at adskille fem spørgsmål, der ofte er bundtet sammen. Hvem gav opgaven dens formål? Hvem må udføre forberedende arbejde? Hvem må delegere en delopgave? Hvem må beslutte, at en foreslået handling er acceptabel? Hvem må gøre den handling effektiv i den ydre verden? Nogle gange rummer én menneskelig rolle med rette flere af disse svar. Nogle gange skal de adskilles. Pointen er ikke at skabe et indviklet ritual for et notat med lav risiko. Pointen er at undgå stille og roligt at behandle en teknisk evne som en overførsel af institutionel autoritet.
En delegation bør derfor bære mere end en instruks. Den bør bære et mandat. Mandatet identificerer målet, den afgrænsede kontekst, de tilladte input, det forventede output, de handlinger, der forbliver forbudte, budgettet eller tidsgrænsen, hvor det er relevant, de betingelser, der kræver eskalering, og den person eller rolle, der er ansvarlig for resultatet. Den modtagende agent kan derefter udføre nyttigt arbejde inden for en synlig ramme. Den kan bede en anden agent om analyse. Den kan ikke udvide rammen blot fordi et plausibelt næste skridt falder den ind.
Dette er ikke et argument for at gøre enhver interaktion til et godkendelsesmøde. Det er et argument for at vælge det punkt, hvor organisationen ønsker, at en beslutning skal ske. Et system kan udarbejde en forklaring uden at et menneske ser på hver sætning, når formålet, målgruppen, kildeafgrænsningen og publiceringsreglerne allerede er fastlagt. Et system bør ikke få magten til at ændre en kundes rettighed blot fordi den samme komponent har adgang til den relevante database. Forskellen er konsekvensen, ikke modellens intelligens.
Den konsekvens er ofte fordelt. En opgave kan være harmløs på ét trin og konsekvensrig på det næste. Det kan være rutine at læse en fil. Kombinerer man den med en anden kilde, kan materialets følsomhed ændre sig. Det kan være rutine at udarbejde en anbefaling. Det er måske ikke rutine at trykke på en knap, der skaber et juridisk, økonomisk eller servicemæssigt resultat. En governance-design, der kun spørger, om en agent er autonom, overser denne tilstandsændring. Det nyttige spørgsmål er snævrere: autonom til hvad, for hvem, under hvilke betingelser og med hvis autoritet?
Der er en beskeden hollandsk instinkt værd at bevare her. Hvis en proces kræver et dusin underskrifter, stempler og et lamineret flowchart for at fastslå, hvem der må trykke på én knap, er det måske ikke en triumf for governance. Men det modsatte arrangement, hvor et værktøjs-credential behandles som en forfatningsmæssig aftale, er heller ikke en triumf. Målet er en proportionel vej, der gør konsekvensrig autoritet klar uden at iscenesætte en lille opera omkring enhver rutinehandling.
Europæisk tilsyn er et driftskrav
AI-forordningen giver det klareste juridiske udtryk for denne idé for højrisiko-AI-systemer. Artikel 14 kræver, at de designes og udvikles, så fysiske personer effektivt kan føre tilsyn med dem, mens de er i brug. Det angivne formål er at forebygge eller minimere risici for sundhed, sikkerhed og grundlæggende rettigheder, hvor disse risici kan bestå på trods af andre krav. Foranstaltningerne skal stå i forhold til risiko, autonomi og brugskontekst. Det er en bevidst operationel standard. Den siger ikke, at en person et sted i organisationen generelt er interesseret i AI.
Bestemmelsen går videre end en generel instruks om at holde et menneske i loopet. Afhængigt af hvad der er passende og proportionelt, skal den person, der er tildelt tilsyn, have mulighed for at forstå relevante kapaciteter og begrænsninger, overvåge drift og opdage anomalier, fejlfunktioner eller uventet ydeevne, forblive opmærksom på automatiseringsbias, fortolke output, beslutte ikke at bruge et output eller at se bort fra, tilsidesætte eller omgøre det samt gribe ind eller afbryde systemet til en sikker tilstand. Loven gør ikke disse til en universel tjekliste for ethvert agentsystem. Den viser dog, hvorfor et stempel i slutningen af processen er en dårlig model for tilsyn.
Tilføj nu delegation. Hvis en agent overdrager en opgave til en anden agent, skal tilsynsrollen kunne se mere end den endelige sætning produceret af den sidste model. Den har brug for nok kontekst til at forstå, hvilken agent der foreslog delopgaven, hvilke kilder eller værktøjer der blev brugt, om en politikgrænse blev nået, om et resultat blev ændret af en reviewer, og om en senere agent udvidede omfanget. Ellers kan mennesket se et output, men ikke den vej, der producerede det. Det kan være tilstrækkeligt for et udkast med lave konsekvenser. Det er ikke et overbevisende grundlag for at acceptere en konsekvensrig beslutning.
Artikel 26 gør organisationspointen endnu tydeligere for udbydere af højrisikosystemer. Den siger, at udbydere skal tildele menneskeligt tilsyn til fysiske personer med den nødvendige kompetence, træning, autoritet og støtte. Disse ord hører sammen. Kompetence uden autoritet skaber en velinformeret tilskuer. Autoritet uden kompetence skaber en formel ejer, der ikke kan udfordre systemet. Begge uden støtte skaber en person, der forventes at gribe ind i en proces, de ikke kan se, i et tempo, de ikke kan følge, ved hjælp af information, de ikke kan fortolke.
Ved multi-agent-arbejde omfatter supporten formen på grænsefladen og registreringen. En operatør har ikke brug for alle de tokens, en model genererede, eller alle de interne forsøg. De har brug for den foreslåede handling, det navngivne formål, de materielle beviser, den politik og den grænse, der gælder, de ændringer, der er foretaget siden sidste gennemgangspunkt, den forventede effekt, den mulige tilbageføringsvej og grunden til, at sagen blev eskaleret. Dette handler mindre om at få et dashboard til at se betryggende ud end om at reducere risikoen for, at en person godkender et svar, fordi systemet har gjort alternativet udmattende at finde.
Europarådets rammekonvention om kunstig intelligens og menneskerettigheder, demokrati og retsstatsprincipper skaber den bredere institutionelle forbindelse. Formålet er at sikre, at aktiviteter i AI-systemers livscyklus er i overensstemmelse med menneskerettigheder, demokrati og retsstatsprincipper. Artikel 8 og 9 kræver gennemsigtighed og tilsyn, der er tilpasset specifikke sammenhænge og risici, samt ansvarlighed og ansvar for negative virkninger. Konventionen foreskriver ikke et bestemt mønster for agentorkestrering. Den fungerer dog som en nyttig korrektion til idéen om, at en kæde af softwarekomponenter kan opløse ansvaret for den offentlige myndighed eller private aktør, der anvender den.
Det bredere perspektiv betyder noget, fordi en delegeret beslutning kan påvirke mere end teknisk ydeevne. Den kan påvirke en persons evne til at forstå en beslutning, bestride den, opnå oprejsning eller blot vide, hvilken organisation der er ansvarlig. En arbejdsgang kan bestå af komponenter fra flere leverandører, modeller fra flere udbydere, værktøjer, der drives af et andet team, og en tjeneste, der leveres under en offentlig kontrakt. At kæden er teknisk distribueret, gør ikke påvirkningen af den enkelte mindre reel. I praksis gør det en klar rollefordeling vigtigere.
Databeskyttelse giver samme advarsel fra en anden vinkel. Det Europæiske Databeskyttelsesråds arbejde med AI-modeller understreger, at databeskyttelsesanalysen forbliver kontekstuel: organisationer skal fastlægge deres rolle, identificere den behandling, der er involveret, og anvende de relevante forpligtelser frem for at behandle betegnelsen AI-model som en fritagelse fra almindeligt ansvar. Når en multi-agent-arbejdsgang berører personoplysninger, bør delegation ikke sløre, hvem der fastlægger formålene og midlerne for behandlingen, hvilken agent eller hvilket værktøj der modtager hvilke data, og om den næste overdragelse er nødvendig for opgaven. En delopgave er stadig et behandlingstrin. At kalde det en delegation får den ikke til at forsvinde.
Intet af dette giver et magisk svar på enhver vanskelig sag. De juridiske forpligtelser afhænger af anvendelsen, aktørerne, dataene og sektoren. En artikel kan ikke klassificere et bestemt system. Men den kan formulere et disciplineret princip: hvis en arbejdsgang fordeler arbejde, bør den fordele det på en måde, der bevarer evnen til at identificere autoritet, gribe ind i tide, redegøre for forløbet og reagere over for de mennesker, der berøres af resultatet.
Personen i loopet skal have et reelt loop
Menneskeligt tilsyn reduceres nemt til en skærm med en godkend-knap. Den skærm kan være nyttig. Den kan også være et ceremonielt objekt. Spørgsmålet er, om personen, der bruger den, har et reelt valg. Et valg er ikke reelt, blot fordi grænsefladen viser to knapper. Det afhænger af, om personen har tilstrækkelig tid, information, kompetence og institutionel tilladelse til at beslutte anderledes.
Tid er den mindst glamourøse del af designet og ofte den mest afgørende. Hvis systemet sender hundredvis af forslag i en periode, hvor en enkelt reviewer med rimelighed kun kunne gennemgå en brøkdel, har organisationen skabt en kø, ikke et tilsyn. Hvis forslaget udløber, før reviewer kan få kontekst, har systemet gjort hastighed til den reelle beslutningstager. Hvis et team kun belønnes for gennemløb, har det givet en stille instruks om, hvilken knap der skal trykkes. Software kan ikke kurere disse forhold ved at tilføje en konfidensscore i en anden nuance af grøn.
Information skal være proportionel, ikke udtømmende. En reviewer, der kun får en konklusion, kan ikke udfordre den. En reviewer, der får en rå udskrift af alle agentinteraktioner, kan som regel heller ikke udfordre den. Den brugbare mellemvej er en beslutningspakke. Den identificerer, hvilken handling der foreslås, hvorfor den er inden for det angivne formål, hvilke væsentlige beviser der understøtter den, hvilken usikkerhed der er tilbage, hvilken politik eller regel der er relevant, hvad den foreslåede effekt er, og hvad der ville ske, hvis handlingen ikke godkendes. Pakken bør linke til dybere beviser, men den bør ikke kræve en arkæologisk ekspedition i det almindelige tilfælde.
Kompetence betyder mere end et generisk kursus om AI. Til den aktuelle opgave skal reviewer forstå typen af output, de kendte begrænsninger, der kan have betydning, den måde workflowet er beregnet til at opføre sig på, og de tegn, der kalder på eskalering. En person, der kan genkende en mangelfuld leverandørfaktura, kan være godt placeret til at gennemgå et fakturarelateret forslag. Den samme person er måske ikke godt placeret til at vurdere en models sprogdækning eller en databeskyttelsesimplikation. At tildele tilsyn er derfor også en bemandingsbeslutning.
Institutionel tilladelse er den test, mange designs stille og roligt fejler. Reviewer skal kunne afvise, pause eller ændre den foreslåede rute uden at blive behandlet som kilden til en systemfejl. De har brug for adgang til en person eller rolle, der kan beslutte, hvad der sker derefter. De har brug for en måde at registrere, at sagen blev eskaleret. Og systemet har brug for en sikker tilstand, hvor arbejde kan vente uden at blive ved et uheld forpligtet af en gentagelse, en timeout eller en anden agent, der tager den oprindelige instruks som uafsluttet arbejde.
Sikkerhedsteknik har længe behandlet menneskelig præstation som en del af systemet, snarere end et sidste lag fernis. UK Health and Safety Executive beskriver menneskelige faktorer som opgaven, individet og organisationen sammen og advarer mod at betragte dem isoleret. Det er en fornuftig ramme for agenttilsyn. En reviewer er ikke en abstrakt menneskelig formet prop til et softwarehul. De udfører en bestemt opgave, med bestemt information og værktøjer, inden for en bestemt organisation med bestemte pres og grænser. Kontrollens kvalitet afhænger af alt dette.
Af den grund begynder et godt human-in-the-loop-design, før knappen vises. Det definerer, hvilke beslutninger der kræver en menneskelig port, hvem der skal holde porten, hvilke beviser de vil modtage, hvor meget tid opgaven tillader, hvad der sker, når de er fraværende, og om porten har autoritet over selve handlingen eller kun over en forklaring af handlingen. Hvis organisationen ikke kan besvare disse spørgsmål på en stille tirsdag, bliver det ikke klarere, når en sag med høje konsekvenser ankommer. Og det bør ikke kræve en imaginær krise at lægge mærke til det.
Én opgave, flere former for autoritet
En kompakt autoritetsmodel kan gøre en agent-workflow lettere at drive. Den behøver ikke at være storladen. Start med forskellen mellem at læse, foreslå, delegere, gennemføre og stoppe. En rolle, der må læse, kan inspicere det materiale, der er nødvendigt for en opgave. En rolle, der må foreslå, kan forberede en mulig handling. En rolle, der må delegere, kan tildele afgrænset arbejde til en anden aktør. En rolle, der må gennemføre, kan gøre en konsekvensrig handling effektiv. En rolle, der må stoppe, kan sætte en rute på pause eller standse den, når dens betingelser ikke længere er opfyldt.
Disse er ikke blot rangtrin. En compliance-revisor kan måske standse en workflow, men ikke gennemføre et kundeudfald. En specialistagent kan måske foreslå en rute, men ikke delegere nyt arbejde uden for sit domæne. En leder kan være ansvarlig for formålet med en tjeneste, men ikke være den person, der er bemyndiget til at frigive en bestemt betaling. Den nyttige egenskab er ikke et hierarki for sin egen skyld. Det er, at systemet kan vurdere, om en bestemt aktør har den relevante autoritet til en bestemt handling i den aktuelle kontekst.
Konteksten gør meget af arbejdet. Den samme foreslåede handling kan være almindelig i én sammenhæng og konsekvensrig i en anden. At sende en allerede godkendt skabelon til en kendt intern adresse kan være inden for et rutinemæssigt kommunikationsmandat. At sende en nyligt udarbejdet besked med personoplysninger til en ny modtager er noget andet. En refusion inden for en defineret grænse kan delegeres til en veltestet proces. En ændring af en rettighed, en datasletning eller en ekstern forpligtelse kan kræve en navngiven menneskelig beslutning. Politikken bør udtrykke denne skelnen, før modellen bliver bedt om at planlægge ud fra den.
Der er også en vigtig forskel mellem en godkendelse og en kvittering. En kvittering registrerer, at nogen har set en besked. En godkendelse registrerer, at en bemyndiget person har accepteret en defineret handling med den relevante kontekst på et defineret punkt i ruten. I et samtalebaseret system kan disse ligne hinanden. Registreringen bør ikke. Hvis en senere revisor ikke kan se, hvilken handling der blev godkendt, og hvilken effekt der var forventet, har organisationen logget en samtale snarere end fanget en beslutning.
Delegering har i sig selv brug for grænser. En agent, der får en opgave med at sammenligne tre eksisterende forslag, kan få lov til at bede en forskningsagent om at udtrække relevante vilkår. Den bør ikke behandle denne tilladelse som en invitation til at kontakte leverandører, indhente nye data eller omformulere indkøbsmålet. Grænsen kan udtrykkes i politik, i værktøjets omfang, i en struktureret opgavekontrakt eller i alle tre. Det vigtige er, at den er håndhævbar nok til at begrænse ruten snarere end blot at beskrive den ønskede adfærd bagefter.
Delegationsdybde er endnu en grænse, der er værd at nævne. Et menneske kan give én agent en opgave og stadig have et klart overblik over den første videregivelse. Efter flere indlejrede videregivelser kan det oprindelige formål være teknisk til stede i metadata, men i praksis usynligt. Organisationer kan fastsætte en maksimal delegationsdybde for en type arbejde, kræve gennemgang på en bestemt dybde eller forbyde en delegeret at oprette yderligere delegerede uden en ny godkendelse. Disse er designvalg, ikke universelle krav. De er mest nyttige, hvor en længere kæde gør det svært at se, hvilken aktør der introducerede en ny antagelse eller ændrede det effektive omfang.
Værktøjsautoritet skal også være adskilt fra modelautoritet. En model kan vælge et værktøj baseret på en plan. Værktøjsintegrationen skal stadig kontrollere, om den anmodede handling, målet, datakategorien, ressourcegrænsen og arbejdsgangens tilstand tillader kaldet. Dette er ikke mistillid til modellen i moralsk forstand. Det er almindelig grænsedesign. En velformuleret plan kan stadig være upassende for den aktuelle sag, og en dårligt formuleret plan bør ikke blive til virkelighed blot, fordi den nåede en legitimationsoplysning med bred adgang.
Det samme gælder for genoprettelse. Et forsøg igen er ikke altid harmløst. At prøve igen med en anmodning om at læse et offentligt dokument er forskelligt fra at prøve igen med en anmodning, der sender en besked eller foretager en betaling. Når en delegeret opgave fejler, har en arbejdsgang brug for et eksplicit valg mellem at prøve igen, omdirigere, eskalere, sætte på pause og kontrolleret fejl. At behandle dem som én generisk fejlhåndtering er sådan, en operationel beslutning stille og roligt træffes af standardindstillinger. Agentkørselsmiljøet kan gøre mulighederne tilgængelige. Organisationen skal beslutte, hvilken mulighed der gælder for hvilken handlingstype.
Fejl er ofte en manglende beslutning
Når folk hører fejl, forestiller de sig ofte en agent, der producerer en falsk erklæring, eller et værktøj, der overskrider tidsgrænsen. Begge kan have betydning. De mere afslørende fejl i delegeret arbejde er ofte mere stille. Opgaven blev tildelt uden en klar ejer. Forslaget krydsede en grænse, som ingen havde modelleret. Anmelderen kunne se konklusionen, men ikke beviserne. Et forsøg igen fortsatte efter en pause. Et menneske bemærkede et problem, men havde ingen autoritet til at stoppe handlingen. En beslutning blev truffet, men registreringen bevarede kun det endelige output og ikke den betingelse, der gjorde det acceptabelt.
Disse er ikke påstande om en navngiven hændelse. De er fejltilstande, der stammer fra strukturen i delegering selv. De kan også findes i menneskelige processer. I software kan de dog bevæge sig med automatiseringens hast og gentages meget konsekvent. Denne konsekvens er ikke en grund til fortvivlelse. Det er en grund til at behandle arbejdsgangsdesign som en del af kontrollen i stedet for at antage, at nøjagtighedstestning af én modelkomponent afgør spørgsmålet.
Overvej et andet eksplicit hypotetisk design. En agent bliver bedt om at forberede et resumé af en sag. Den delegerer dokumentekstraktion til én komponent og sprognormalisering til en anden. En tredje komponent ser et ufuldstændigt felt og bruger en tilsluttet videnskilde til at udfylde hullet. Det endelige resumé læses glat. Hvis arbejdsgangen ikke har registreret det manglende felt, kilden brugt til at udfylde det, den tillid eller usikkerhed, der fulgte med det, og det faktum, at den oprindelige opgave kun tillod opsummering, kan en anmelder ikke afgøre, om de godkender et resumé eller en nyskabt faktuel påstand. Problemet er ikke, at den sidste sætning lyder mærkelig. Problemet er, at betydningen af opgaven ændrede sig inde i ruten.
Et fornuftigt svar er ikke at forbyde delegation. Det er at lægge ændringspunkter ind i registreringen. En ny kilde, et nyt værktøj, en ny datakategori, en ny handlingsklasse, en væsentlig ændring i konfidens, en fejlet kontrol, en længere end tilladt delegationskæde eller et forslag om at krydse en ekstern grænse kan hver især blive en grund til at lade arbejdet komme til gennemsyn. De præcise udløsere vil variere efter sammenhæng. Princippet er stabilt: en ændring, der ville have betydning for den ansvarlige ejer, bør ikke forblive usynlig, blot fordi den skete mellem komponenter.
Dette er et sted, hvor sikkerhedsargumentation er nyttig. En sikkerhedsargumentation er ikke et løfte om, at intet kan gå galt. Det er et struktureret argument for, hvorfor et system er acceptabelt til et defineret formål under definerede betingelser, med dokumentation, antagelser, kontroller og resterende risici synlige. Anvendt forsigtigt på en agentarbejdsgang betyder det, at påstanden ikke er, at agenter generelt er sikre. Påstanden er snævrere: denne rute kan bruges til dette formål med disse begrænsninger, fordi disse kontroller og tilsynsordninger findes, og den skal genovervejes, når de angivne antagelser ikke længere holder.
Arbejdsgangen er så lettere at udfordre. En operatør kan spørge, om handlingsklassen blev tildelt korrekt. En risikoejer kan spørge, om revieweren stadig har tilstrækkelig tid. En ingeniør kan spørge, om et forsøg igen kunne skabe en duplikeret effekt. En databeskyttelsesspecialist kan spørge, om delopgaven stadig er nødvendig og proportional. En person, der er berørt af et resultat, kan, hvor den gældende ramme kræver det, få en mulighed for at anfægte beslutningen. Disse spørgsmål er ikke bureaukrati tilføjet efter det interessante tekniske arbejde. De er arbejdet med at gøre det tekniske system ansvarligt i en organisation.
Målinger bør følge samme disciplin. At tælle antallet af delegerede opgaver fortæller os noget om volumen, ikke om ansvarlig drift. Mere nyttige målinger kan omfatte den hastighed, hvormed en arbejdsgang eskalerer, fordi en grænse ændrede sig, den tid en beslutning venter ved en port, andelen af væsentlige handlinger med en komplet beslutningspakke, antallet af vellykkede tilbageførsler eller antallet af tilfælde, hvor en politikontrol afviste et værktøjskald. Sådanne målinger kræver stadig en definition og en sammenhæng. De bør aldrig opfindes til en brochure. Men at designe registreringerne, så de kunne måles, er et tegn på, at ansvarlighed behandles som en driftsegenskab.
Registreringen er, hvor ansvaret overlever
Et multiagentsystem producerer en akavet slags historik. Det har meddelelser, værktøjskald, mellemliggende output, politikontroller, modelversioner, tidsoplysninger, forsøg igen, ændrede tildelinger og måske menneskelige godkendelser. At gemme hver eneste byte for evigt er hverken nødvendigt eller ofte passende. At gemme kun det endelige svar er normalt for lidt. Registreringen skal bevare de beslutninger og den dokumentation, der forklarer, hvordan arbejdsgangen krydsede fra en anmodning til et resultat.
For en væsentlig handling bør registreringen normalt lade en reviewer rekonstruere et par grundlæggende fakta. Hvad var målet? Hvilken politik eller bemyndigelse gjorde arbejdet tilladt? Hvem eller hvad modtog hver tildeling? Hvad blev foreslået ved hver væsentlig port? Hvilke oplysninger blev brugt til at understøtte forslaget? Hvilke begrænsninger, advarsler eller fejl blev stødt på? Hvem havde autoritet til at godkende, stoppe eller tilbageføre handlingen? Hvilken handling trådte i kraft, og hvad skete der bagefter? Disse er ikke eksotiske spørgsmål. De er de spørgsmål, en organisation stiller, når den vil vide, om en beslutning var dens beslutning.
Registreringen bør adskille en operationel kendsgerning fra en forklaring, der er lavet senere. Hvis et system siger, at en reviewer godkendte en handling, bør hændelsen registrere reviewerens identitet eller rolle, den handling, de fik vist, den relevante kontekst og det tidspunkt, hvor godkendelsen blev knyttet til handlingen. Hvis systemet siger, at en model valgte en delegeret, bør registreringen bevare udvælgelsesreglen, kandidaterne eller kriterierne på det niveau, der passer til brugen, og den resulterende tildeling. En senere fortælling kan hjælpe en læser, men den bør ikke erstatte den hændelse, der fandt sted.
Versionering er vigtig her. En agents output kan blive genereret igen. En politik kan blive opdateret. Et værktøjsskema kan ændre sig. Et modelendepunkt kan blive udskiftet. Hvis en beslutning afhænger af en bestemt version af en prompt, politik, model, videnskilde eller integration, har registreringen brug for en stabil reference til den version. Ellers bliver afspilning en forestilling: den gengiver, hvad organisationen tilfældigvis har nu, og kalder resultatet en forklaring på, hvad der skete dengang.
Reversibilitet fortjener lige så meget opmærksomhed. AI-forordningen henviser udtrykkeligt, i forbindelse med tilsyn med højrisikosystemer, til muligheden for at se bort fra, tilsidesætte eller omgøre et output og afbryde et system, så det standser i en sikker tilstand. I en multi-agent-rute er den sikre tilstand ikke nødvendigvis en standset modelproces. Det kan betyde, at ingen ekstern kommunikation sendes, at en køet handling holdes tilbage, at et downstream-system ikke opdateres, at midlertidige legitimationsoplysninger ikke længere kan bruges til opgaven, og at de beviser, der er nødvendige for at beslutte, hvad der skal ske nu, bevares. Det er en operationel slutning fra tilsynskravet, ikke et citat fra loven. Det er også en nyttig designtest.
Sikker betyder ikke frosset for evigt. En standset arbejdsgang har brug for en kontrolleret genoptagelsesvej. Nogen skal beslutte, om opgaven skal ændres, forslaget kasseres, en afgrænset del af arbejdet køres igen, et andet værktøj bruges, yderligere beviser indhentes, eller ruten opgives. En ren registrering gør det valg lettere, fordi den fortæller den næste person, hvad der vides, hvad der blev forsøgt, hvorfor arbejdet stoppede, og hvilke virkninger der er og ikke er sket. Uden den registrering bliver genopretning endnu en ustruktureret delegation, som normalt foretages under større pres end den første.
Det er derfor, opbevaring og adgang har brug for deres egne beslutninger. Ikke alle aktører skal kunne læse alle spor. En registrering kan indeholde personoplysninger, kommercielt følsomt materiale eller sikkerhedsrelevante detaljer. Men kontrolleret adgang er ikke det samme som ingen registrering. Europarådets konventions vægt på gennemsigtighed, tilsyn, ansvarlighed og ansvar er en nyttig påmindelse om, at grænsen bør designes snarere end antages. En organisation kan bevare en ansvarlig rute, mens den begrænser adgangen til de detaljer, som en bestemt reviewer reelt har brug for.
Hvad en delegationskontrakt bør gøre synligt
En delegationskontrakt kan være en datastruktur, et arbejdsgangsskema, en underskrevet godkendelsespakke eller en kombination af disse. Dens form betyder mindre end dens indhold. Den bør fortælle den modtagende aktør, hvad den har lov til at gøre, hvad den ikke har lov til at gøre, og hvordan arbejdet vil blive vurderet. Når disse begrænsninger er fraværende, har agenter en tendens til at kompensere med stadig mere detaljerede instruktioner. Det kan forbedre en bestemt kørsel. Det skaber ikke en organisatorisk grænse, som et værktøj, en reviewer eller en revisor kan håndhæve.
Begynd med det tilsigtede formål. Et formål bør være konkret nok til at udelukke lignende opgaver. Sammenlign vilkårene i de fremsendte forslag er forskelligt fra find den bedste leverandør. Opsummer de modtagne dokumenter er forskelligt fra fastlæg de manglende fakta. Udkast et svar til gennemsyn er forskelligt fra kommuniker en beslutning. Kontrasten kan virke pedantisk, indtil en agent bruger en bred instruktion til at tage et rimeligt, men uautoriseret næste skridt. Så er det forskellen mellem nyttigt initiativ og et ubegrænset mandat.
Angiv de tilladte og forbudte handlingsklasser. En agent kan få lov til at læse en sagsmappe, udtrække navngivne felter, sammenligne med en politik og udarbejde et udkast. Det kan være forbudt at ændre en kildepost, kontakte en ekstern part, vælge en ny kilde eller gennemføre en transaktion. Dette er ikke blot prompt-instruktioner. Værktøjs- og workflowlaget bør håndhæve dem, hvor det er praktisk muligt. En politik, der ikke kan kontrolleres i handlingsøjeblikket, er stadig nyttig som vejledning, men den er svagere som kontrol.
Angiv ejeren og eskaleringsvejen. Ejeren er ikke nødvendigvis den person, der klikker godkend på hver handling. Det er rollen, der er ansvarlig for resultatet og for at beslutte, hvad der sker, når vejen når frem til et uafklaret spørgsmål. Eskaleringsvejen identificerer den næste autoritet, når agenten opdager en grænseoverskridelse, utilstrækkelig dokumentation, en konflikt mellem kilder, en politikafvigelse eller en tilstand, som systemet ikke har tilladelse til at løse. En kø uden en navngivet beslutningsejer er blot en forsinkelse med en optimistisk etiket.
Knyt en dokumentationsregel til. Reglen kan angive, hvilke kilder der er autoritative, om agenten må søge ud over dem, hvordan usikkerhed repræsenteres, hvad der skal citeres i forslaget, og hvornår en konfliktende kilde kræver gennemgang. Dette er særligt vigtigt for systemer, der genererer flydende prosa. Flydende sprog kan få en grænseoverskridelse til at ligne en nyttig fuldførelse. En dokumentationsregel gør det korrekte spørgsmål tilgængeligt: forblev workflowet inden for det materiale, det var autoriseret til at bruge?
Fastsæt en grænse for tid, ressourcer og delegation, hvor det har betydning. En opgave, der kan fortsætte i det uendelige, kan skabe omkostninger, operationel overbelastning eller pres for at forpligte sig til et forældet resultat. En opgave, der gentagne gange kan delegere, kan skabe en kæde, som ingen ejer nemt kan inspicere. Et afgrænset design angiver, hvor længe opgaven forbliver gyldig, hvor mange ressourcer den kan forbruge, om den må oprette en underopgave, hvilken maksimal dybde der er tilladt, og hvad der sker, når en grænse nås. Svaret kan være automatisk pause, eskalering eller kontrolleret fejl. Det vigtige er, at det er besluttet, før grænsen overskrides.
Definer endelig fuldførelsesbetingelsen. Fuldført betyder ikke altid, at agenten har produceret tekst. Det kan betyde, at en gennemgående person har modtaget en komplet pakke, at en politikgate har accepteret en specifik handling, at et downstream-system har bekræftet en reversibel opdatering, eller at en ansvarlig ejer har valgt ikke at fortsætte. Fuldførelsesbetingelser holder workflowet ærligt. De forhindrer en agent i at behandle det at foreslå en beslutning, som om organisationen havde truffet en.
Disse mønstre er nyttige, uanset om workflowet indeholder en enkelt modelbaseret agent eller et større team af specialiserede komponenter. Flere agenter kræver ikke automatisk mere proces. De kræver, at grænserne mellem roller udtrykkes snarere end underforstås. Omkostningen ved den udtrykkelse er generelt meget lavere end omkostningen ved at forsøge at rekonstruere autoritet, efter at flere systemer har udvekslet delvise instruktioner, og et af dem har rørt den ydre verden.
Delegation bør gøre organisationen mere dygtig, ikke mindre ansvarlig
Agentsystemer beskrives ofte, som om deres værdi ligger i at fjerne organisation fra arbejdet. Den mere interessante mulighed er det modsatte. Et omhyggeligt designet system kan gøre organisatoriske forpligtelser tydeligere: en opgave har en ejer, en delegation har en grænse, en væsentlig handling har en autoritet, en gennemgang har dokumentation, en standsning har en sikker tilstand, og en registrering kan afspilles. Det er ikke en hindring for nyttig automatisering. Det er det, der gør det muligt for automatisering at påtage sig meningsfuldt arbejde uden at bede folk om at stole på en usynlig kæde.
Vi byggede Dweve Nexus omkring denne sondring. Dens lokale produktdokumentation beskriver varige opgaver, autoritet vurderet mod runtime-kontekst før handling, eksplicitte samarbejdsstrukturer inklusive delegation, og en registrering skrevet i takt med at arbejdet udføres. Den relevante påstand er bevidst beskeden. Det er designegenskaber, der har til formål at gøre en delegeret rute inspicerbar. De er ikke bevis for, at en bestemt implementering er lovlig, sikker eller egnet, og de fjerner ikke behovet for, at en organisation selv beslutter sit formål, sin autoritet og sin menneskelige tilsyn.
Den bredere lære afhænger ikke af ét produkt. En model kan beslutte, hvordan en opgave skal opdeles. En agent kan bede en anden agent om arbejde. Et værktøj kan udføre en handling. Organisationen skal stadig beslutte, hvor autoriteten ligger. Det skal ske, før delegationen begynder, ikke efter at et endeligt resultat er poleret til noget, der er svært at betvivle.
Det er svaret på titlen. Ejeren af en beslutning er ikke den agent, der tilfældigvis talte sidst. Det er den person eller rolle, som organisationen har tildelt autoriteten til at acceptere beslutningens konsekvens, med tilstrækkelig information og magt til at afvise den. Delegation er nyttig, når den gør denne person mere i stand. Den bliver farlig, når den gør personen umulig at finde.
Kilder
- 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