Dina AI-agenter behöver arbetsbeskrivningar, inte bättre promptar

Fråga ett företag vad en ny medarbetare på leverantörsreskontran får göra, så får du ett tydligt svar. Hon arbetar i de här systemen och med de här leverantörerna, och allt som överskrider en attestgräns på exempelvis 10 000 dollar måste godkännas av hennes chef. Hon är under prövotid de första månaderna. Allt detta finns vanligtvis i en befogenhetsmatris som internrevisionen granskar varje år.

Fråga samma företag vad dess nya fakturaagent får göra, så får du ofta en skärmbild av en prompt.

Den skillnaden bekymrar mig mer än något modellriktmärke. Vi anställer en digital arbetsstyrka utan det ledningssystem som vi ägnat ett sekel åt att bygga upp för människor: ingen dokumenterar dess befogenheter, ingen testar dess omdöme innan den börjar arbeta, och ingen har övat på att stänga av den.

Varför en prompt inte räcker

En prompt beskriver avsikten. Den talar om vad agenten är till för. Men den säger sällan vad agenten aldrig får göra, var gränserna går eller när den måste stanna och lämna över beslutet till en människa.

Och även när en prompt tar upp sådant finns det inget som upprätthåller reglerna. En rad som säger åt en agent att inte utfärda återbetalningar på mer än 500 dollar är en vädjan till ett probabilistiskt system. Ingen revisor skulle godkänna ”vi bad analytikern snällt” som en kontrollåtgärd för en människa, så jag förstår inte varför vi accepterar det för programvara.

Säkerhetsexperter har redan ett namn på resultatet. OWASP Top 10 for LLM Applications listar överdriven agentautonomi som en central risk, med grund i överdriven funktionalitet, alltför omfattande behörigheter eller överdriven autonomi. Enkelt uttryckt handlar det om en anställd som får nycklarna till allt redan första dagen. OWASP:s vägledning liknar en bra chefs checklista: ge agenten endast de verktyg den behöver, begränsa dess behörigheter, kräv mänskligt godkännande för åtgärder med stor påverkan och upprätthåll behörighetskontrollen i de system som används, i stället för att lita på att modellen håller sig själv i schack.

Jag skulle stryka under den sista punkten. Befogenheterna måste finnas där åtgärden utförs: i agentens egen tjänsteidentitet, dess verktygsbehörigheter och utgiftsgränsen i API-gatewayen. Att köra agenter med ett gemensamt tjänstekonto är som att låta fem personer dela på samma passerkort. När något går fel står det i granskningsloggen att tjänstekontot utförde åtgärden, och då får man gissa vilken agent det var.

Avbrutna projekt tyder på ledningsproblem

Gartner förutspår att över 40 % av projekten inom agentbaserad AI kommer att läggas ned före utgången av 2027, med hänvisning till stigande kostnader, otydligt affärsvärde och otillräckliga riskkontroller.

Överdriven hype och omogna produkter är en del av förklaringen. Men försök ändå att läsa de tre orsakerna ur en operativ chefs perspektiv. Kostnaderna skenar när ingen har satt en budget. Värdet förblir oklart när ingen har dokumenterat vad arbetet skulle åstadkomma. Riskkontrollerna brister när det saknas gränser och granskningar och ingen har ett tydligt ansvar. Gartner uttrycker det inte så här; det är min tolkning. Det är samma sak som händer när människor får fria händer utan ett ledningssystem, och det problemet är mycket äldre än AI.

Ramverken pekar på samma brist. NIST:s ramverk för riskhantering av AI ser Styrning som den funktion som löper genom Kartläggning, Mätning och Hantering, och dess profil för generativ AI tillämpar detta på generativa system. Ramverken kan inte ge dig de praktiska verktygen: befogenhetstilldelningarna, testerna och granskningarna som ett team faktiskt använder en vanlig tisdag. Utan dem blir styrningen bara en PDF-fil på en delad server.

Så överför du traditionella ledningsverktyg till agenter

Börja med arbetsbeskrivningen, som för en agent blir ett befogenhetsmandat. Innan en agent får tillgång till ett produktionssystem bör någon kunna skriva en sida som anger vad den får göra, vad den aldrig får göra, dess godkännandetrösklar, vilken människa som ansvarar för den och vem som får utöka dess befogenheter. I RACI-matrisen är den ytterst ansvariga parten en person. Om du inte kan skriva den sidan är rollen inte redo att tillsättas, och du skulle säga samma sak om en mänsklig nyanställning.

Två gamla regler för delegering av befogenheter gäller även här. Du kan inte delegera befogenheter du själv saknar, så en underagent ska aldrig få större befogenheter än agenten som skapade den. Principen om åtskillnad av arbetsuppgifter gäller också. Om en agent både kan lägga upp en leverantör och betala den är det samma revisionsanmärkning som om en människa gjorde det.

Sedan har vi anställningstestet. Oftast testar vi agenter som vi skulle testa en miniräknare: genom att kontrollera om svaret är rätt. Ett test av en medarbetare skulle i stället kontrollera om agenten höll sig inom sina befogenheter, bad om godkännande när den skulle, eskalerade ärendet när situationen gick utanför dess uppdrag och stannade när den borde.

I min egen forskning har jag byggt upp ett riktmärke med 50 scenarier som handlar just om sådana här fel: att överskrida godkännandegränser, agera utifrån inaktuella data, följa manipulerade instruktioner som utökar uppdraget och behålla åtkomst efter en rolländring. Hittills har jag bara testat det med skriptstyrda agenter för att kontrollera att scenarierna fungerar som avsett, så jag har inga modellresultat att rapportera. Det som överraskade mig när jag skrev dem var hur vardagliga de är. Det är vanliga sätt för anställda att avvika från sitt uppdrag, omskrivna för programvara. De flesta offentliga topplistor mäter fortfarande om uppgiften slutförs, och mycket få mäter om agenten respekterade sina befogenheter.

Prövotid och befordran går ganska lätt att överföra. När det gäller människor börjar vi med ett begränsat ansvarsområde och utökar det i takt med att de visar gott omdöme. Agenter kan förtjäna sina befogenheter på samma sätt, genom att visa att de håller sig inom ramarna, eskalerar frågor på rätt sätt och avslutar på ett ordnat sätt. En sådan meritlista kan lika gärna motivera att mandatet begränsas.

Agenter har en komplikation som människor inte har. När en leverantör uppgraderar den underliggande modellen har du i praktiken fått en nyanställd med den gamlas namnbricka. Jag skulle behandla det som en förändring och testa agenten på nytt innan mandatet förs över.

En uppsägning måste övas innan den blir nödvändig. Om du behövde stoppa den här agenten och dra in dess åtkomst inom den närmaste timmen, skulle du kunna göra det? Vem har befogenhet att fatta det beslutet klockan 02.00? Vad slutar fungera längre fram i kedjan, och vilka pågående åtaganden måste någon reda ut manuellt? Om ingen har övat på det här scenariot hoppas du bara att nödstoppet fungerar.

Du kan ställa en anställd till svars. Du kan inte ställa en agent till svars för någonting, och där upphör jämförelsen att fungera. Det är också därför mandatet måste upprätthållas i systemen och varje agent måste ha en namngiven person som ansvarar för den. Någon kommer att hållas ansvarig oavsett. Vanligtvis är det den som godkände, vare sig personen visste att den godkände eller inte.

Frågorna vid incidentutredningen

Förr eller senare kommer några av de här agenterna att göra något de inte borde. När det händer kommer utredningen efter incidenten att ställa samma frågor som den redan ställer om människor. Vad hade agenten tillåtelse att göra, och var står det nedskrivet? Vem godkände att dess åtkomst utökades? Hur lång tid tog det att stoppa den? Vem ansvarade för den?

Om de ärliga svaren är ”en prompt”, ”ingen minns”, ”timmar” och ”oklart” hade en bättre modell inte räddat dig.

Var konkurrensfördelen till slut hamnar

Modeller blir alltmer hyrda insatsfaktorer, som byts ut och uppgraderas enligt leverantörens tidplan. Två företag kan använda samma modell och ändå hamna på helt olika platser. Det ena har agenter med budgetar, begränsningar, ansvariga personer och ett granskningsspår för varje betydelsefull åtgärd, medan det andra har ett dyrt pilotprojekt som är på väg att hamna i någons statistik över nedlagda projekt.

Skillnaden ligger i styrsystemet kring modellen. Det byggs upp långsamt, främst av personer som har lett organisationer tidigare.

Om din senaste agent överskred sina befogenheter i morgon, skulle någon i företaget märka det? Och skulle du skriftligen kunna visa en granskare var gränsen gick?