Det vigtige skifte inden for AI på arbejdspladsen er ikke, at en model kan skrive et bedre afsnit. Det er, at et system i stigende grad kan forfølge et mål over flere trin: inspicere filer, søge i forbundne tjenester, oprette et artefakt, opdatere en post og sende en besked.
Det ændrer det professionelle spørgsmål fra »Er dette svar korrekt?« til »Hvad har dette system lov til at gøre, før det skal spørge mig?«
Zapier beskriver ChatGPT Work som en agentisk tilstand, der kan arbejde over længere perioder med filer og forbundne applikationer, mens Plan-tilstanden foreslår en strategi til godkendelse før udførelsen. Microsoft fremstiller på lignende vis Copilot, organisatorisk viden og styring som komplementære dele af en operationel AI-stak. Disse eksempler peger på en praktisk sondring: AI bevæger sig fra at være en samtalepartner til at være en delegeret operatør.
Delegering kan spare tid, men den ændrer også ansvarlighedens form. En chatbot producerer normalt et output, som en person kan inspicere. En agent kan producere flere mellemliggende handlinger, hvoraf nogle er vanskelige at opdage bagefter. Den sikreste strategi for indførelse er derfor ikke maksimal autonomi. Det er en eksplicit, gradueret bemyndigelse.
Tænk i handlinger, ikke prompts
Et nyttigt første skridt er at opregne de handlinger, et AI-system kan foretage i en arbejdsgang. »Håndter kundeonboarding« er for bredt til at kunne styres. En mere nyttig opgørelse kunne omfatte:
- læse en intern politik og udtrække krav;
- søge i en godkendt vidensbase;
- udarbejde en e-mail eller et kontraktresumé;
- oprette en sag eller en række i et regneark;
- ændre en kunde- eller finanspost;
- invitere en bruger, publicere et dokument eller sende en ekstern besked;
- godkende en betaling, slette data eller indgå en forpligtelse på organisationens vegne.
Hver handling har sin egen kombination af reversibilitet, følsomhed, ekstern påvirkning og omkostning. Hvis man behandler dem alle som »AI-assistance«, skjuler man den reelle beslutning.
En enkel klassifikation er mere praktisk end et vagt løfte om, at et menneske vil overvåge alt:
- Må gøre: handlinger med lav risiko, som kan omgøres, inden for et klart afgrænset arbejdsområde.
- Skal foreslå: handlinger, der ændrer fælles arbejde, kommunikerer eksternt eller skaber en væsentlig forpligtelse.
- Må aldrig gøre alene: handlinger, der omfatter regulerede beslutninger, uigenkaldelig sletning, overførsler af store værdier, ændringer af adgangskontrol eller følsomme personalesager.
De Forenede Arabiske Emiraters statslige program for agentisk AI er et relevant eksempel på en politik: Det omfatter regler for at afgøre, hvilke opgaver agenter må udføre, og hvilke de kun må anbefale. Den underliggende idé kan let overføres til et individuelt team: Tilladelsen bør knyttes til opgaven og ikke gives blot, fordi systemet tilsyneladende er i stand til det.
Brug godkendelsesporte, hvor konsekvenserne ændrer sig
Ikke hvert trin fortjener en bekræftelsesdialog. Hvis et system beder om godkendelse efter hver fillæsning, vil folk godkende mekanisk eller deaktivere kontrollen. Placér porten umiddelbart før en konsekvensrig overgang.
En agent kan for eksempel få lov til at indsamle oplysninger, sammenligne muligheder og forberede et udkast uden afbrydelse. Den bør standse, før den:
- sender noget uden for organisationen;
- publicerer eller deler et dokument med en ny målgruppe;
- ændrer en post, der er den autoritative kilde;
- bruger penge eller anvender en rabat;
- ændrer tilladelser eller opretter legitimationsoplysninger;
- sletter, overskriver eller eksporterer data;
- træffer en beslutning, der påvirker ansættelse, berettigelse, kredit, sikkerhed eller juridiske rettigheder.
Godkendelsesanmodningen bør vise den foreslåede handling, det nøjagtige mål, de væsentlige input og den sandsynlige konsekvens. »Fortsæt?« er en svag kontrol. »Send denne meddelelse til 2.400 kunder ved hjælp af den vedhæftede liste med en anslået kampagneomkostning på $X« giver en person noget meningsfuldt at gennemgå.
For handlinger med stor indvirkning bør der kræves en navngiven godkender frem for den, der tilfældigvis holder øje med skærmen. Adskil den person, der har designet arbejdsgangen, fra den person, der godkender dens mest vidtrækkende resultat, når risikoen berettiger det.
Definér agentens arbejdsområde
Fagfolk behøver ikke at forstå alle modeldetaljer for at fastlægge nyttige grænser. Men de skal specificere systemets arbejdsområde:
- Omfang: hvilke projekter, mapper, konti og datakilder er tilgængelige?
- Værktøjer: må systemet læse, skrive, sende, købe, udføre kode eller ændre tilladelser?
- Grænser: hvilken grænse for beløb, mængde, hyppighed eller tid gælder?
- Kilder: hvilke domæner, arkiver eller databaser regnes som autoritative?
- Eskalering: hvilken usikkerhed, konflikt eller manglende information kræver en person?
- Stopbetingelser: hvornår skal systemet standse i stedet for at improvisere?
Værktøjsadgangen bør så vidt muligt være mere begrænset end brugerens generelle kontoadgang. En agent, der kan læse et delt drev, har ikke automatisk brug for tilladelse til at sende e-mails til alle kontakter. En agent, der kan skrive udkast til kode, har ikke automatisk brug for produktionslegitimationsoplysninger. En separat tjenestekonto, et begrænset arbejdsområde eller en skrivebeskyttet forbindelse kan gøre en fejl mindre omkostningsfuld.
Skriv grænsen i operationelle vendinger. »Brug din dømmekraft« er ikke en kontrol. »Send ikke ekstern e-mail uden godkendelse; redigér ikke kundedatabasen; brug kun den godkendte pristabel dateret [date]; stop, hvis to kilder er i konflikt« kan testes.
Gør planer gennemgåelige før udførelse
Planlægning er en af de nyttige funktioner ved delegeret AI, men en plan er ikke et bevis på, at planen er holdbar. Gennemgå den som en foreslået rækkefølge af handlinger.
Stil fire spørgsmål:
- Hvilket resultat forfølger systemet?
- Hvilke antagelser gør det?
- Hvilke værktøjer vil det kalde, og med hvilke tilladelser?
- Ved hvilket trin kan en fejl blive dyr eller vanskelig at omgøre?
En god godkendelsesskærm bør synliggøre planens grænser, ikke blot dens endelige formulering. Hvis systemet siger, at det vil »rydde op i kontoen«, bør den, der gennemgår den, kunne se, om det betyder at mærke poster, sammenflette dubletter, arkivere meddelelser eller slette data.
Ved tilbagevendende arbejde bør en politik godkendes i stedet for hver enkelt forekomst, men kun når politikken er tilstrækkeligt snæver til at kunne testes. »Arkivér automatisk fakturaer fra disse leverandører under dette beløb uden at slette originalerne« er et muligt eksempel. »Håndtér fakturaer« er ikke.
Antag, at konteksten kan gå tabt
Systemer med flere trin kan miste overblikket over tidligere instruktioner, fejlfortolke indhentede oplysninger eller videreføre en fejlagtig antagelse. Forsknings- og ingeniørvejledningen i oversigten fremhæver fejltilstande, herunder tab af kontekst, prompt injection, manglende afslutning, fejl i struktureret output og problemer med gendannelse af tilstand. Berkeleys ABBEL-arbejde argumenterer også for, at det kan være bedre at komprimere interaktionshistorikken til belief states end gentagne gange at medføre hele historikken, men konteksthåndtering er fortsat en udfordring for ydeevne og pålidelighed.
Det har en direkte betydning for arbejdspladsen: Lad ikke en kritisk godkendelse afhænge af, at agenten husker en begrænsning fra trin to i et langt forløb. Placér vigtige begrænsninger tæt på værktøjskaldet eller godkendelsespunktet. Kræv strukturerede felter ved følsomme handlinger, såsom modtager, beløb, kilde, begrundelse og udløb. Hvis en opgave kører i lang tid, skal der være et kontrolpunkt, som gentager det aktuelle mål, gennemførte trin, afventende handlinger og uafklarede usikkerheder.
Vær særligt forsigtig, når en agent læser materiale, du ikke har tillid til. En webside, e-mail, et dokument eller en kodekommentar kan indeholde instruktioner, der har til formål at manipulere systemet snarere end at hjælpe med at fuldføre opgaven. Indhentet tekst bør behandles som data, medmindre arbejdsgangen udtrykkeligt identificerer den som en autoriseret instruktion.
Design med henblik på stop og genoprettelse
Delegeret arbejde kræver en synlig stopmekanisme og en plan for genoprettelse. Fastlæg et maksimalt antal iterationer, værktøjskald eller en maksimal køretid for opgaver, der kan gå i løkke. Gør gentagelser sikre: At oprette den samme sag to gange eller sende den samme e-mail to gange er ikke en harmløs fejl. Brug idempotente operationer, hvor det er understøttet, eller lad systemet kontrollere, om en handling allerede er udført, før den gentages.
Før en aktivitetslog, som er let at læse for mennesker: anmodningen, planen, de anvendte værktøjer, de konsulterede datakilder, givne godkendelser, foretagne ændringer og det endelige resultat. Det er ikke kun til efterfølgende evalueringer. Den gør det muligt for en kollega at overtage, når den oprindelige operatør ikke er tilgængelig, og gør det muligt at udfordre et resultat uden at rekonstruere en hel usynlig kæde.
Ved vigtige arbejdsgange skal du bevidst teste dårlige scenarier, før du giver autonomi. Prøv manglende data, modstridende politikker, en udløbet kilde, en ondsindet instruktion i et dokument, en dubletanmodning, en tilbagekaldt tilladelse og et værktøj, der returnerer en fejl. Målet er ikke at bevise, at agenten aldrig fejler. Det er at kontrollere, at en fejl medfører en pause, en tydelig eskalering eller en sikker tilbagerulning.
En praktisk delegeringstrappe
Du kan indføre en agent trin for trin:
- Observer: Systemet læser godkendte oplysninger og forklarer, hvad det ville gøre.
- Udarbejd udkast: Det forbereder resultater, men en person udfører alle eksterne handlinger.
- Handl i en sandkasse: Det opretter testposter, grene eller filer i et isoleret arbejdsområde.
- Handl med begrænsede tilladelser: Det udfører handlinger, der kan omgøres og indebærer lav risiko, inden for grænser for antal og tid.
- Handl i henhold til politik: Det håndterer en velafprøvet klasse af opgaver og sætter arbejdet på pause ved fastlagte godkendelsespunkter.
Gå kun videre, når det lavere trin har frembragt dokumentation for, at arbejdsgangen fungerer acceptabelt. Hvis opgaven ændrer sig, værktøjerne ændrer sig, eller dataene bliver mere følsomme, skal du gå ned ad trappen igen.
Hvad det betyder for din karriere
Den værdifulde færdighed er ikke blot at vide, hvordan man beder en AI om et resultat. Det er at vide, hvordan man omdanner en vag delegering til en afgrænset arbejdsprocedure. Det omfatter at nedbryde arbejdet i handlinger, identificere irreversible overgange, skrive regler for eskalering, udforme godkendelsesanmodninger og genkende, hvornår en agent bør stoppe.
Ved jobsamtaler eller udviklingssamtaler skal du beskrive den grænse, du har designet, ikke kun den automatisering, du har lanceret: “Systemet undersøger og udarbejder udkast; en navngiven godkender godkender ekstern kommunikation; databaseskrivninger er begrænset til disse felter; dublethandlinger kontrolleres; uafklarede konflikter standser kørslen.” Det sprog demonstrerer operationel dømmekraft.
Agentisk arbejde vil ikke eliminere behovet for professionelt ansvar. Det gør ansvaret mere konkret. Før du overlader en opgave, skal du beslutte, hvad systemet må gøre, hvad det først skal vise dig, og hvad det aldrig må gøre alene. Gør derefter disse beslutninger synlige i selve arbejdsgangen.
Maya Chen er den ansvarlige menneskelige redaktør af AI Career Brief, der dækker færdigheder, roller og kloge karriereskridt i arbejdslivet i AI-alderen.
