Ledere og procesansvarlige, der vil afprøve en AI-agent i en konkret arbejdsgang
Vælg en agent, når opgaven kræver fleksible valg
En chatbot svarer i en samtale. Et traditionelt workflow følger et aftalt forløb. En AI-agent kan vælge næste handling ud fra situationen og bruge værktøjer til at gennemføre den. I praksis kan en løsning kombinere alle tre.
Hvis opgaven kan løses stabilt med faste regler, er der ofte ingen fordel ved at lade en model vælge frit. Hvis indholdet varierer, kan AI hjælpe med eksempelvis at forstå en henvendelse og foreslå næste skridt. Selve registreringen kan stadig følge faste regler.
Beskriv derfor, hvor vurderingen er nødvendig. “Sortér alle indgående mails” er bredt. “Find henvendelser om eksisterende ordre, hent tilladt status og lav et svarudkast” er mere præcist. Det sidste kan testes og afgrænses.
Find en opgave med et tydeligt facit
En god første pilot har tilstrækkeligt mange lignende opgaver til, at I kan lære noget, men konsekvenserne af fejl skal kunne håndteres. Vælg gerne et forløb, hvor resultatet kan kontrolleres af den medarbejder, der allerede kender arbejdet.
Et eksempel er at forberede et udkast til en sagsregistrering på baggrund af en henvendelse. Agenten foreslår kategori og de nødvendige felter; medarbejderen godkender, før sagen oprettes. I kan efterfølgende se, hvilke felter der blev rettet, og hvor meget tid kontrollen tog.
Undgå at gøre piloten afhængig af fem nye integrationer eller en stor oprydning i hele virksomheden. Hvis datagrundlaget er utilstrækkeligt, kan pilotens første resultat være en beslutning om at forbedre det.
| Spørgsmål | Godt udgangspunkt | Tegn på mere afklaring |
|---|---|---|
| Kan resultatet bedømmes? | En fagperson kan godkende det | “Det skal bare være intelligent” |
| Er data tilgængelige? | Afgrænset kilde med kendt ejer | Spredte data uden adgang eller ejer |
| Kan fejl håndteres? | Udkast og reversible handlinger | Uoprettelige handlinger uden kontrol |
| Er der nok eksempler? | Repræsentative normale og svære sager | Kun én perfekt demonstrationssag |
Mål den nuværende arbejdsgang før I ændrer den
Registrér, hvor lang tid en opgave tager fra input til godkendt resultat. Skeln mellem aktiv arbejdstid og ventetid. Notér også fejl, genåbnede sager og de oplysninger, der typisk mangler. Brug et repræsentativt udsnit frem for kun de letteste sager.
Aftal derefter pilotens målepunkter. Det kan være andelen af korrekte felter, antallet af uacceptable handlinger, medarbejderens kontroltid og andelen af sager, der må håndteres manuelt. Et gennemsnit kan skjule alvorlige fejl, så vis også problemtyperne.
Definér succeskriterier inden testen starter. Ellers risikerer I at vælge de mål, der tilfældigvis ser bedst ud bagefter. En hurtig agent er ikke en gevinst, hvis en medarbejder bruger længere tid på at rette den.
Fra første afklaring til noget, der virker.
Afgræns og mål
Vælg én opgave, adgang og baseline. Eksempelplanen tilpasses projektet.
Afgræns data, værktøjer og handlinger
Tegn, hvilke systemer agenten må læse fra, og hvilke den må ændre. Start gerne med læsning og forslag. Giv kun skriveadgang, når der er en tydelig begrundelse og en passende kontrol. Tilladelser skal håndhæves i systemet, ikke kun beskrives i en prompt.
Eksterne mails, dokumenter og websites kan indeholde tekst, der prøver at påvirke agentens instruktioner. Det kaldes prompt injection. OpenAI beskriver både dette og utilsigtet datalækage som risici ved agenter.
I en pilot kan I reducere konsekvensen gennem afgrænsede værktøjer, validerede felter, godkendelse af handlinger og en måde at stoppe kørslen på. Gem tilstrækkelig hændelseshistorik til at forstå en fejl, men undgå unødvendig opbevaring af personoplysninger.
Hvor meget tid er der i opgaven?
Et regneeksempel til prioritering. Beregningen viser frigjort kapacitet før udgifter til udvikling, drift og kontrol.
Formel: opgaver × minutter ÷ 60 × frigjort andel. Kapacitet er ikke automatisk en kontant besparelse. Afprøv antagelserne i en pilot, og fratræk omkostningerne.
En 30-dages eksempelplan fra opgave til beslutning
De første dage bruges på afgrænsning, adgang og en baseline. Derefter bygges et lille forløb, som afprøves på godkendte eksempler. En fagperson gennemgår både gode og dårlige resultater, før agenten får lov til at indgå i en begrænset arbejdssituation.
I den sidste del af piloten sammenlignes resultatet med udgangspunktet. Medtag tid til kontrol, driftsfejl og de opgaver, der blev sendt tilbage til manuel behandling. Aftal, hvilke ændringer der skal til, før flere medarbejdere eller sagstyper tilføjes.
Tredive dage er her en planlægningsramme, ikke en leveringstidsgaranti. Manglende systemadgang, få testeksempler eller særlige datahensyn kan ændre planen. Det afgørende er, at hver fase giver et konkret grundlag for den næste.
Test også situationer, agenten skal stoppe i
Testlisten skal omfatte mere end normale opgaver. Indsæt eksempelvis et manglende kundenummer, to mulige match, et system der ikke svarer, og en henvendelse med instruktioner om at ignorere reglerne. Angiv det forventede udfald for hver test.
Ved en tvetydig sag kan det korrekte resultat være at bede om hjælp. Ved et utilgængeligt system kan det være at lægge opgaven i en synlig kø. Ved en allerede registreret sag bør agenten undgå en dublet. Bedøm altså også gode stop, ikke kun gennemførte handlinger.
Gem testmaterialet og versionsoplysninger, så I kan gentage kontrollen ved ændringer. OpenAI beskriver evaluering som en løbende metode til at teste output mod aftalte kriterier. Jeres konkrete kriterier skal afspejle arbejdsgangen.
- Manglende eller modstridende oplysninger
- Utilgængeligt system og udløbet adgang
- Gentaget input og risiko for dubletter
- Forsøg på at få agenten uden for dens mandat
Afslut med en beslutning om at udvide, ændre eller stoppe
Pilotens resultat bør kunne forklares på én side: opgave, datagrundlag, testomfang, kvalitet, samlet tidsforbrug, omkostninger og åbne problemer. Skeln mellem det observerede og det, I forventer ved større volumen.
Hvis piloten skal fortsætte, skal en procesansvarlig eje den. Aftal, hvem der følger fejl, ændrer regler og godkender en ny version. Hvis værdien ikke er tydelig, kan I vælge en mindre opgave eller beholde en enklere automatisering. At stoppe en uegnet pilot er også en brugbar beslutning.
Det bliver vi ofte spurgt om.
Skal en AI-agent have adgang til alle vores systemer?
Nej. Den bør kun have den adgang, der er nødvendig for den afgrænsede opgave. En første pilot kan ofte arbejde med læsning og udkast, som et menneske godkender.
Kan alle AI-piloter gennemføres på 30 dage?
Nej. Planen er et eksempel på et afgrænset forløb. Systemadgang, datakvalitet, godkendelser og testomfang bestemmer den konkrete tidsplan.
Hvad er forskellen på en agent og almindelig automatisering?
Almindelig automatisering følger et aftalt forløb. En agent kan vælge handlinger ud fra situationen. Mange gode løsninger kombinerer AI til vurdering med faste regler til registrering og kontrol.
Hvordan ved vi, om piloten har været en succes?
Sammenlign kvalitet, samlet arbejdstid og omkostninger med den tidligere proces. Vurder både normale sager og fejl. Brug de kriterier, I fastlagde før testen, som grundlag for beslutningen.
Læs videre ved kilden.
Vores beslutningsmodeller er rådgivning fra Mosel Studio. Tekniske fakta og rammer understøttes af kilderne her.
- OpenAI: Safety in building agents
Baggrund om prompt injection, datalækage og handlingskontrol.
- OpenAI: Working with evals
Principper for test af modeloutput mod aftalte kriterier.
