Dine AI-agenter har brug for jobbeskrivelser, ikke bedre prompts

Spørger man en virksomhed, hvad en ny medarbejder i kreditorbogholderiet må gøre, får man et præcist svar. Hun arbejder i disse systemer med disse leverandører, og alt over en godkendelsesgrænse på eksempelvis 10.000 $ sendes til hendes leder til underskrift. Hun er på prøve i sine første par måneder. Alt dette fremgår som regel af en bemyndigelsesmatrix, som den interne revision gennemgår hvert år.

Spørger man den samme virksomhed, hvad dens nye fakturaagent må gøre, får man ofte et skærmbillede af en prompt.

Det gab bekymrer mig mere end nogen modelbenchmark. Vi ansætter en digital arbejdsstyrke uden det ledelsessystem, vi har brugt et århundrede på at opbygge til mennesker: Ingen beskriver dens beføjelser, ingen afprøver dens dømmekraft, før den går i gang, og ingen har øvet sig i at slukke den.

Hvorfor en prompt ikke kan løse opgaven

En prompt beskriver hensigten. Den fortæller, hvad agenten skal bruges til. Den siger sjældent, hvad agenten aldrig må gøre, hvor dens grænser går, eller hvornår den skal stoppe og overlade beslutningen til et menneske.

Og selv når en prompt siger den slags, er der intet, der håndhæver det. En sætning, der beder en agent om ikke at udbetale refusioner på over 500 $, er en anmodning til et probabilistisk system. Ingen revisor ville godkende »vi bad analytikeren pænt om det« som en kontrolforanstaltning for et menneske, så jeg kan ikke se, hvorfor vi accepterer det for software.

Sikkerhedsfolk har allerede et navn for resultatet. OWASP Top 10 for LLM Applications udpeger for stor handlefrihed som en central risiko, der skyldes for mange funktioner, for omfattende tilladelser eller for stor autonomi. Sagt helt enkelt svarer det til at give en medarbejder nøglerne til det hele på den første dag. OWASP’s vejledning minder om en god leders tjekliste: Giv kun agenten de værktøjer, den har brug for, afgræns dens tilladelser, kræv menneskelig godkendelse af handlinger med stor indvirkning, og håndhæv autorisationen i de efterfølgende systemer i stedet for at stole på, at modellen selv holder styr på den.

Jeg ville sætte en streg under det sidste punkt. Bemyndigelsen skal være indlejret dér, hvor handlingen finder sted: i agentens egen tjenesteidentitet, dens værktøjstilladelser og forbrugsgrænsen ved API-gatewayen. At køre agenter på en delt tjenestekonto svarer til, at fem personer deler ét adgangskort. Når noget går galt, viser revisionsloggen, at tjenestekontoen gjorde det, og så må man gætte på, hvilken agent der var ansvarlig.

Aflysningerne ligner et ledelsesproblem

Gartner forudser, at over 40 % af projekter med agentisk AI vil blive aflyst inden udgangen af 2027, med henvisning til stigende omkostninger, uklar forretningsværdi og utilstrækkelige risikokontroller.

Hype og umodne produkter er en del af forklaringen. Prøv alligevel at læse de tre årsager, som en driftsdirektør ville gøre. Omkostningerne stiger, når ingen har fastsat et budget. Værdien forbliver uklar, når ingen har skrevet ned, hvad arbejdet skulle føre til. Risikokontrollen slår ikke til, når der hverken er grænser eller gennemgange, og ingen tydeligt står til ansvar. Gartner fremstiller det ikke sådan; det er min tolkning. Det er det samme, der sker, når folk får frie hænder uden et ledelsessystem, og det problem er langt ældre end AI.

Rammerne peger på det samme hul. NIST AI Risk Management Framework behandler Govern som den funktion, der går på tværs af Map, Measure og Manage, og Generative AI Profile viderefører den tilgang til generative systemer. Rammerne kan ikke give dig det praktiske maskineri: de bemyndigelser, test og gennemgange, som et team rent faktisk arbejder med en tirsdag. Uden dem bliver governance et PDF-dokument på et fællesdrev.

Sådan overføres de gamle ledelsesværktøjer til agenter

Begynd med jobbeskrivelsen, som for en agent bliver til en bemyndigelse. Før en agent får adgang til et aktivt system, bør nogen kunne skrive en side, der beskriver, hvad den må gøre, hvad den aldrig må gøre, dens godkendelsesgrænser, hvilket menneske der har ansvaret for den, og hvem der kan udvide dens beføjelser. I RACI-modellen er den ansvarlige part et menneske. Hvis du ikke kan skrive den side, er rollen ikke klar til at blive besat, og du ville sige det samme om en menneskelig ansættelse.

To gamle regler for delegering af beføjelser gælder stadig. Man kan ikke delegere beføjelser, man ikke selv har, så en underagent må aldrig få større beføjelser end den agent, der oprettede den. Funktionsadskillelse gælder også stadig. En agent, der både kan oprette en leverandør og betale den, ville udløse den samme revisionsbemærkning, som hvis en person gjorde det.

Så er der prøven ved ansættelsen. Vi tester for det meste agenter, som vi ville teste en lommeregner, ved at kontrollere, om svaret er korrekt. En prøve for en medarbejder ville undersøge, om vedkommende holdt sig inden for sine beføjelser, bad om godkendelse, når det var påkrævet, eskalerede sagen, når situationen lå uden for vedkommendes mandat, og stoppede, når det burde ske.

I min egen forskning har jeg været i gang med at opbygge en benchmark med 50 scenarier, der netop handler om disse fejl: at overskride godkendelsesgrænser, handle på forældede data, følge injicerede instruktioner, der udvider mandatet, og bevare adgangen efter et rolleskift. Indtil videre har jeg kun kørt den mod scriptstyrede agenter for at kontrollere, at scenarierne fungerer efter hensigten, så jeg har ingen modelresultater at rapportere. Det overraskede mig, mens jeg skrev dem, hvor almindelige de er. Det er de sædvanlige måder, medarbejdere går uden for deres mandat på, omskrevet til software. De fleste offentlige ranglister måler stadig, om opgaven bliver løst, og meget få måler, om agenten respekterede sine beføjelser.

Prøvetid og forfremmelse kan oversættes ret direkte. Når det gælder mennesker, starter vi med at give dem et snævert ansvarsområde og udvider det, efterhånden som de viser, at de har dømmekraften i orden. Agenter kan gøre sig fortjent til større råderum på samme måde: ved at vise, at de holder sig inden for rammerne, eskalerer sager på passende vis og stopper korrekt. Den historik kan lige så vel begrunde, at deres tilladelse indskrænkes.

Agenter har en ekstra udfordring, som mennesker ikke har. Når en leverandør opgraderer den underliggende model, står du reelt med en nyansat, der bærer det gamle adgangskort. Jeg ville behandle det som en ændring, der kræver en ny vurdering, og teste igen, før tilladelsen videreføres.

Opsigelse skal øves, før du får brug for den. Hvis du skulle standse denne agent og tilbagekalde dens adgang inden for den næste time, kunne du så gøre det? Hvem har beføjelse til at træffe den beslutning kl. 2 om natten? Hvad går i stykker længere nede i kæden, og hvilke igangværende forpligtelser skal nogen håndtere manuelt? Hvis ingen har gennemført den øvelse, håber du bare, at nødstopknappen virker.

Du kan holde en medarbejder ansvarlig. Du kan ikke holde en agent ansvarlig for noget som helst, og dér holder sammenligningen op med at fungere. Det er også derfor, tilladelsen skal håndhæves i systemerne, og derfor hver agent skal have en navngiven person, der har ansvaret for den. Uanset hvad ender nogen med ansvaret. Som regel er det den, der godkendte det, uanset om vedkommende vidste, hvad det var, der blev godkendt.

Hvad gennemgangen efter en hændelse vil spørge om

Nogle af disse agenter kommer før eller siden til at gøre noget, de ikke burde. Når det sker, vil gennemgangen efter hændelsen stille de samme spørgsmål, som man allerede stiller om mennesker. Hvad havde agenten tilladelse til at gøre, og hvor står det skrevet? Hvem godkendte, at dens adgang blev udvidet? Hvor lang tid tog det at standse den? Hvem havde ansvaret for den?

Hvis de ærlige svar er »en prompt«, »det kan ingen huske«, »timer« og »uklart«, ville en bedre model ikke have reddet dig.

Hvor fordelen ender med at ligge

Modeller bliver i stigende grad noget, man lejer som input og udskifter og opgraderer efter leverandørens tidsplan. To virksomheder kan bruge den samme model og alligevel ende meget forskellige steder. Den ene har agenter med budgetter, grænser, ansvarlige og et revisionsspor for hver handling med væsentlige konsekvenser, mens den anden har et dyrt pilotprojekt, der er på vej til at blive en del af nogens statistik over aflysninger.

Forskellen ligger i styringssystemet omkring modellen. Det bliver bygget gradvist, for det meste af mennesker, der tidligere har ledet organisationer.

Hvis din nyeste agent i morgen overskred sine beføjelser, ville nogen i din virksomhed så opdage det? Og kunne du skriftligt vise en revisor, hvor grænsen gik?