Det viktige skiftet innen KI på arbeidsplassen er ikke at en modell kan skrive et bedre avsnitt. Det er at et system i økende grad kan forfølge et mål gjennom flere trinn: inspisere filer, søke i tilkoblede tjenester, opprette et dokument eller annet resultat, oppdatere en post og sende en melding.

Det endrer det faglige spørsmålet fra «Er dette svaret riktig?» til «Hva har dette systemet lov til å gjøre før det må spørre meg?»

Zapier beskriver ChatGPT Work som en agentisk modus som kan arbeide over lengre perioder med filer og tilkoblede applikasjoner, mens Plan-modusen foreslår en strategi for godkjenning før gjennomføring. Microsoft fremstiller på lignende måte Copilot, organisatorisk kunnskap og styring som komplementære deler av en operativ KI-stakk. Disse eksemplene peker mot et praktisk skille: KI beveger seg fra å være en samtalepartner til å bli en delegert operatør.

Delegering kan spare tid, men den endrer også ansvarets form. En chatbot produserer vanligvis et resultat som en person kan kontrollere. En agent kan utføre flere mellomliggende handlinger, hvorav noen er vanskelige å oppdage i etterkant. Den tryggeste strategien for innføring er derfor ikke maksimal autonomi. Det er eksplisitt, trinnvis myndighet.

Tenk i handlinger, ikke spørsmål

Et nyttig første skritt er å liste opp handlingene et KI-system kan utføre i en arbeidsflyt. «Håndter kundeonboarding» er for bredt til å kunne styres. En mer nyttig oversikt kan omfatte:

  • lese en intern policy og trekke ut krav;
  • søke i en godkjent kunnskapsbase;
  • utarbeide et utkast til en e-post eller et kontraktsresymé;
  • opprette en sak eller en rad i et regneark;
  • endre en kunde- eller økonomipost;
  • invitere en bruker, publisere et dokument eller sende en ekstern melding;
  • godkjenne en betaling, slette data eller inngå en forpliktelse på vegne av organisasjonen.

Hver handling har en ulik kombinasjon av reverserbarhet, sensitivitet, ekstern påvirkning og kostnad. Hvis man behandler dem alle som «KI-assistanse», skjules den egentlige beslutningen.

En enkel klassifisering er mer praktisk enn et vagt løfte om at et menneske skal føre tilsyn med alt:

  • Kan gjøre: handlinger med lav risiko som kan reverseres, innenfor et tydelig avgrenset arbeidsområde.
  • Må foreslå: handlinger som endrer delt arbeid, kommuniserer eksternt eller skaper en vesentlig forpliktelse.
  • Må aldri gjøre alene: handlinger som innebærer regulerte beslutninger, irreversibel sletting, overføringer av store verdier, endringer i tilgangskontroller eller sensitive personalsaker.

De forente arabiske emiratenes statlige program for agentisk KI er et relevant politisk eksempel: Det omfatter regler for å avgjøre hvilke oppgaver agenter kan fullføre, og hvilke de bare kan anbefale. Grunntanken kan enkelt overføres til et individuelt team: Tillatelsen bør knyttes til oppgaven, ikke gis bare fordi systemet virker i stand til å utføre den.

Bruk godkjenningspunkter når konsekvensene endres

Ikke alle trinn fortjener en bekreftelsesdialog. Hvis et system ber om godkjenning etter hver fil det leser, vil folk godkjenne mekanisk eller deaktivere kontrollen. Plasser kontrollpunktet umiddelbart før en overgang med konsekvenser.

En agent kan for eksempel få lov til å innhente informasjon, sammenligne alternativer og klargjøre et utkast uten avbrudd. Den bør stanse før den:

  • sender noe utenfor organisasjonen;
  • publiserer eller deler et dokument med et nytt publikum;
  • endrer en autoritativ post;
  • bruker penger eller benytter en rabatt;
  • endrer tillatelser eller oppretter påloggingsopplysninger;
  • sletter, overskriver eller eksporterer data;
  • tar en beslutning som påvirker ansettelse, kvalifisering, kreditt, sikkerhet eller juridiske rettigheter.

Godkjenningsforespørselen bør vise den foreslåtte handlingen, det nøyaktige målet, de vesentlige inndataene og den sannsynlige konsekvensen. «Fortsette?» er en svak kontroll. «Send denne meldingen til 2 400 kunder ved hjelp av den vedlagte listen, med en beregnet kampanjekostnad på $X» gir en person noe meningsfylt å vurdere.

For handlinger med stor innvirkning bør det kreves en navngitt godkjenner, ikke bare den som tilfeldigvis følger med på skjermen. Skill personen som utformet arbeidsflyten, fra personen som godkjenner det mest inngripende resultatet, når risikoen tilsier det.

Definer agentens arbeidsområde

Fagpersoner trenger ikke å forstå alle modelldetaljer for å etablere nyttige grenser. Men de må spesifisere systemets arbeidsområde:

  • Omfang: hvilke prosjekter, mapper, kontoer og datakilder er tilgjengelige?
  • Verktøy: kan systemet lese, skrive, sende, kjøpe, kjøre kode eller endre tillatelser?
  • Begrensninger: hvilken grense gjelder for beløp, mengde, hyppighet eller tid?
  • Kilder: hvilke domener, arkiver eller databaser regnes som autoritative?
  • Eskalering: hvilken usikkerhet, konflikt eller manglende informasjon krever at en person involveres?
  • Stoppbetingelser: når må systemet stanse i stedet for å improvisere?

Verktøytilgangen bør være snevrere enn brukerens generelle kontotilgang når det er mulig. En agent som kan lese en delt stasjon, trenger ikke automatisk tillatelse til å sende e-post til alle kontakter. En agent som kan utarbeide kode, trenger ikke automatisk produksjonslegitimasjon. En separat tjenestekonto, et begrenset arbeidsområde eller en skrivebeskyttet tilkobling kan gjøre en feil mindre kostbar.

Skriv grensen i operasjonelle termer. «Bruk skjønn» er ikke en kontroll. «Ikke send ekstern e-post uten godkjenning; ikke endre kundedatabasen; bruk bare den godkjente pristabellen datert [date]; stans hvis to kilder er i konflikt» kan testes.

Gjør planer gjennomgåelige før utførelse

Planlegging er en av de nyttige funksjonene ved delegert KI, men en plan er ikke et bevis på at planen er god. Vurder den som en foreslått handlingssekvens.

Still fire spørsmål:

  1. Hvilket resultat forsøker systemet å oppnå?
  2. Hvilke antakelser gjør det?
  3. Hvilke verktøy vil det kalle, og med hvilke tillatelser?
  4. Ved hvilket trinn kan en feil bli kostbar eller vanskelig å reversere?

Et godt godkjenningsskjermbilde bør synliggjøre planens grenser, ikke bare den endelige teksten. Hvis systemet sier at det skal «rydde opp i kontoen», bør den som vurderer dette, kunne se om det betyr å merke poster, slå sammen duplikater, arkivere meldinger eller slette data.

For gjentakende arbeid bør en policy godkjennes i stedet for hver enkelt forekomst, men bare når policyen er tilstrekkelig avgrenset til å kunne testes. «Arkiver automatisk fakturaer fra disse leverandørene under dette beløpet, uten å slette originalene» er et mulig alternativ. «Administrer fakturaer» er det ikke.

Anta at konteksten kan svikte

Systemer med flere trinn kan miste oversikten over tidligere instruksjoner, feiltolke innhentet informasjon eller videreføre en feilaktig antakelse. Forsknings- og ingeniørveiledningen i sammendraget fremhever feilmønstre som tap av kontekst, promptinjection, manglende terminering, feil i strukturerte utdata og problemer med gjenoppretting av tilstand. Berkeleys ABBEL-arbeid argumenterer også for at det kan være bedre å komprimere interaksjonshistorikk til trosoppfatninger enn å ta med en full historikk hver gang, men konteksthåndtering er fortsatt en utfordring for ytelse og pålitelighet.

Dette har en direkte konsekvens på arbeidsplassen: Ikke gjør en kritisk godkjenning avhengig av at agenten husker en begrensning fra trinn to i en lang kjøring. Plasser viktige begrensninger nær verktøykallet eller godkjenningspunktet. Krev strukturerte felt for sensitive handlinger, som mottaker, beløp, kilde, begrunnelse og utløp. Hvis en oppgave kjører over lang tid, må du kreve et kontrollpunkt som gjentar det aktuelle målet, fullførte trinn, ventende handlinger og uavklarte usikkerheter.

Vær spesielt forsiktig når en agent leser materiale du ikke stoler på. En nettside, e-post, et dokument eller en kodekommentar kan inneholde instruksjoner som tar sikte på å manipulere systemet, snarere enn å bidra til at oppgaven blir fullført. Innhentet tekst bør behandles som data med mindre arbeidsflyten uttrykkelig identifiserer den som en autorisert instruksjon.

Utform for stans og gjenoppretting

Delegerte oppgaver trenger en synlig stoppmekanisme og en plan for gjenoppretting. Angi et maksimalt antall iterasjoner, verktøykall eller kjøretid for oppgaver som kan gå i løkke. Gjør nye forsøk trygge: Å opprette den samme saken to ganger eller sende den samme e-posten to ganger er ikke en ufarlig feil. Når det støttes, bør du bruke idempotente operasjoner eller la systemet kontrollere om en handling allerede har skjedd, før den gjentas.

Før en aktivitetslogg som er lett å forstå for mennesker: forespørselen, planen, verktøyene som ble brukt, datakildene som ble konsultert, godkjenningene som ble gitt, endringene som ble gjort og det endelige resultatet. Dette er ikke bare for etteranalyser. Det gjør det mulig for en kollega å overta når den opprinnelige operatøren ikke er tilgjengelig, og gjør det mulig å stille spørsmål ved et resultat uten å rekonstruere en hel usynlig kjede.

For viktige arbeidsflyter bør du med hensikt teste dårlige tilfeller før du gir autonomi. Prøv manglende data, motstridende retningslinjer, en utløpt kilde, en ondsinnet instruksjon i et dokument, en duplikatforespørsel, en tilbakekalt tillatelse og et verktøy som returnerer en feil. Målet er ikke å bevise at agenten aldri feiler. Det er å verifisere at en feil fører til en pause, en tydelig eskalering eller en trygg tilbakeføring.

En praktisk delegeringstrapp

Du kan innføre en agent trinnvis:

  1. Observer: systemet leser godkjent informasjon og forklarer hva det ville gjort.
  2. Utarbeid utkast: det klargjør resultater, men en person utfører alle eksterne handlinger.
  3. Handle i en sandkasse: det oppretter testoppføringer, grener eller filer i et isolert arbeidsområde.
  4. Handle med begrensede tillatelser: det utfører handlinger som kan reverseres og innebærer lav risiko, innenfor grenser for mengde og tid.
  5. Handle i henhold til retningslinjer: det håndterer en grundig testet oppgaveklasse og stanser ved definerte godkjenningspunkter.

Gå bare videre når det lavere trinnet har fremskaffet dokumentasjon på at arbeidsflyten fungerer på en akseptabel måte. Hvis oppgaven endres, verktøyene endres eller dataene blir mer sensitive, går du nedover i trappen igjen.

Hva dette betyr for karrieren din

Den verdifulle ferdigheten er ikke bare å vite hvordan man ber en KI om et resultat. Det er å vite hvordan man gjør en vag delegering om til en avgrenset arbeidsprosedyre. Det innebærer å dele opp arbeidet i handlinger, identifisere irreversible overganger, skrive regler for eskalering, utforme godkjenningsforespørsler og gjenkjenne når en agent bør stanse.

I jobbintervjuer eller medarbeidersamtaler bør du beskrive grensen du utformet, ikke bare automatiseringen du lanserte: «Systemet undersøker og utarbeider utkast; en navngitt kontrollør godkjenner ekstern kommunikasjon; skrivinger til databasen er begrenset til disse feltene; dupliserte handlinger kontrolleres; uavklarte konflikter stanser kjøringen.» Dette språket viser operasjonelt skjønn.

Agentisk arbeid vil ikke eliminere behovet for profesjonelt ansvar. Det gjør ansvaret mer konkret. Før du overlater en oppgave, må du bestemme hva systemet kan gjøre, hva det først må vise deg, og hva det aldri må gjøre alene. Gjør deretter disse beslutningene synlige i selve arbeidsflyten.

Maya Chen er ansvarlig redaktør for AI Career Brief, som dekker ferdigheter, roller og smarte valg for arbeid i KI-alderen.