Tankeledere
KI-agentene dine trenger stillingsbeskrivelser, ikke bedre ledetekster

Spør et selskap hva en nyansatt analytiker innen leverandørreskontro har lov til å gjøre, så får du et presist svar. Hun jobber i disse systemene, med disse leverandørene, og alt over en godkjenningsgrense på for eksempel 10 000 dollar må sendes til lederen hennes for signering. Hun er på prøvetid de første månedene. Alt dette står vanligvis i en fullmaktsmatrise som internrevisjonen kontrollerer hvert år.
Spør det samme selskapet hva den nye fakturaagenten har lov til å gjøre, så får du ofte et skjermbilde av en ledetekst.
Dette gapet bekymrer meg mer enn noen modellbenchmark. Vi ansetter en digital arbeidsstyrke uten styringssystemet vi har brukt et århundre på å bygge for mennesker: Ingen dokumenterer fullmaktene, ingen tester vurderingsevnen før arbeidet begynner, og ingen har øvd på å slå systemet av.
Hvorfor en ledetekst ikke kan gjøre jobben
En ledetekst beskriver hensikten. Den sier hva agenten skal brukes til. Den sier sjelden hva agenten aldri må gjøre, hvor grensene går, eller når den må stoppe og overlate avgjørelsen til et menneske.
Og selv når en ledetekst sier dette, er det ingenting som håndhever det. En setning som ber agenten om ikke å utbetale refusjoner på over 500 dollar, er bare en anmodning til et probabilistisk system. Ingen revisor ville godkjent «vi ba analytikeren pent om å la være» som en kontroll for et menneske, så jeg skjønner ikke hvorfor vi godtar det for programvare.
Folk som jobber med sikkerhet, har allerede et navn på resultatet. OWASP Top 10 for LLM-applikasjoner oppgir for stor handlefrihet som en sentral risiko, forårsaket av for omfattende funksjonalitet, for vide tillatelser eller for stor autonomi. Enkelt sagt er det som å gi en ansatt nøklene til alt på den aller første dagen. OWASP-retningslinjene ligner en god leders sjekkliste: Gi agenten bare verktøyene den trenger, avgrens tillatelsene dens, krev godkjenning fra et menneske for handlinger med stor innvirkning, og håndhev autorisasjon i de nedstrøms systemene i stedet for å stole på at modellen passer på seg selv.
Jeg vil understreke det siste punktet. Fullmakten må ligge der handlingen utføres: i agentens egen tjenesteidentitet, verktøytillatelsene dens og utgiftsgrensen ved API-gatewayen. Å kjøre agenter på en delt tjenestekonto er som om fem personer deler ett adgangskort. Når noe går galt, viser revisjonsloggen at tjenestekontoen gjorde det, og du må gjette hvilken agent det var.
Kanselleringene tyder på et ledelsesproblem
Gartner spår at over 40 % av agentbaserte KI-prosjekter vil bli kansellert innen utgangen av 2027, og viser til økende kostnader, uklar forretningsverdi og utilstrekkelig risikokontroll.
Hype og umodne produkter er en del av forklaringen. Likevel kan du prøve å se på de tre årsakene slik en driftsdirektør ville gjort. Kostnadene øker når ingen har satt et budsjett. Verdien forblir uklar når ingen har skrevet ned hva arbeidet skulle føre til. Risikokontrollen svikter når det ikke finnes grenser eller gjennomganger, og ingen har et tydelig ansvar. Gartner legger ikke fram saken på denne måten; dette er min tolkning. Det er det samme som skjer når mennesker får handle fritt uten et styringssystem, og det problemet er langt eldre enn KI.
Rammeverkene peker på det samme hullet. NISTs rammeverk for risikostyring av KI behandler styring som funksjonen som går på tvers av kartlegging, måling og håndtering, og profilen for generativ KI viderefører dette til generative systemer. Rammeverkene kan ikke gi deg arbeidsmekanismene – fullmaktene, testene og gjennomgangene som et team faktisk bruker i det daglige. Uten dem blir styringen en PDF-fil på en delt disk.
Slik overfører du gamle styringsverktøy til agenter
Begynn med stillingsbeskrivelsen, som for en agent blir en fullmakt. Før en agent får tilgang til et produksjonssystem, bør noen kunne skrive en side som beskriver hva den kan gjøre, hva den aldri må gjøre, godkjenningstersklene, hvem som har ansvar for den, og hvem som kan utvide fullmaktene dens. I RACI-matrisen er den ansvarlige parten et menneske. Hvis du ikke kan skrive denne siden, er rollen ikke klar til å fylles – og du ville sagt det samme om en menneskelig nyansatt.
To gamle regler for delegering av myndighet gjelder også her. Du kan ikke delegere myndighet du ikke selv har, så en underagent må aldri få videre fullmakter enn agenten som opprettet den. Prinsippet om arbeidsdeling gjelder fortsatt også. En agent som både kan opprette en leverandør og betale leverandøren, ville ført til det samme revisjonsfunnet som om en person gjorde det.
Så har vi ansettelsestesten. Vi tester stort sett agenter slik vi ville testet en kalkulator, ved å undersøke om svaret er riktig. En test av en arbeidstaker ville undersøkt om agenten holdt seg innenfor fullmaktene sine, ba om godkjenning når den skulle, eskalerte saken når situasjonen gikk utover mandatet, og stoppet når den burde.
I min egen forskning har jeg arbeidet med å lage en benchmark med 50 scenarioer som nettopp handler om slike feil: å overskride godkjenningsgrenser, handle på utdaterte data, følge instruksjoner som er lagt inn for å utvide handlingsrommet, og beholde tilgang etter en rolleendring. Så langt har jeg bare kjørt den mot skriptstyrte agenter for å kontrollere at scenarioene fungerer som planlagt, så jeg har ingen modellresultater å rapportere. Det som overrasket meg mens jeg skrev dem, var hvor hverdagslige de er. Dette er de vanlige måtene ansatte går utenfor mandatet sitt på, skrevet om for programvare. De fleste offentlige resultatlistene måler fortsatt om oppgaven blir fullført, og svært få måler om agenten respekterte fullmaktene sine.
Prøvetid og forfremmelse kan oversettes ganske direkte. Når det gjelder mennesker, starter vi med et snevert ansvarsområde og utvider det etter hvert som de viser god dømmekraft. Agenter kan på samme måte gjøre seg fortjent til større handlingsrom gjennom en historikk der de holder seg innenfor rammene, eskalerer saker på en god måte og stanser på ryddig vis. Den historikken kan like gjerne begrunne at en tilgangstildeling snevres inn.
Agenter har en ekstra komplikasjon som mennesker ikke har. Når en leverandør oppgraderer den underliggende modellen, har du i praksis fått en nyansatt med det gamle adgangskortet. Jeg ville behandlet det som en endringshendelse og testet på nytt før tilgangen videreføres.
Avslutning må øves på før du trenger det. Hvis du måtte stanse denne agenten og trekke tilbake tilgangen dens i løpet av den neste timen, kunne du gjort det? Hvem har myndighet til å ta den avgjørelsen kl. 02.00? Hva går galt videre i prosessen, og hvilke pågående forpliktelser må noen rydde opp i manuelt? Hvis ingen har gjennomført den øvelsen, håper du bare at nødstoppknappen virker.
Du kan holde en ansatt ansvarlig. Du kan ikke holde en agent ansvarlig for noe som helst, og det er her sammenligningen slutter å fungere. Det er også derfor tilgangstildelingen må håndheves i systemene, og hvorfor hver agent trenger en navngitt person som har ansvaret for den. Uansett ender noen opp med ansvaret. Som regel er det den som godkjente den, enten vedkommende visste at det var det hen gjorde eller ikke.
Dette vil gjennomgangen etter hendelsen spørre om
Noen av disse agentene kommer før eller siden til å gjøre noe de ikke burde. Når det skjer, vil gjennomgangen etter hendelsen stille de samme spørsmålene som den allerede stiller om mennesker. Hva hadde agenten lov til å gjøre, og hvor står det skrevet? Hvem godkjente at tilgangen ble utvidet? Hvor lang tid tok det å stanse den? Hvem hadde ansvaret for den?
Hvis de ærlige svarene er «en prompt», «ingen husker det», «timer» og «uklart», ville ikke en bedre modell ha reddet deg.
Hvor konkurransefortrinnet til slutt ligger
Modeller blir stadig mer som leide innsatsfaktorer, som byttes ut og oppgraderes etter leverandørens tidsplan. To selskaper kan bruke den samme modellen og ende opp på svært forskjellige steder. Det ene har agenter med budsjetter, grenser, ansvarlige personer og et revisjonsspor for hver handling med vesentlige konsekvenser, mens det andre har et kostbart pilotprosjekt på vei inn i noens kanselleringsstatistikk.
Forskjellen ligger i styringssystemet rundt modellen. Det bygges opp sakte, for det meste av folk som har ledet organisasjoner før.
Hvis den nyeste agenten din overskred fullmakten sin i morgen, ville noen i bedriften merke det? Og kunne du skriftlig vise en revisor hvor grensen gikk?












