AI-agent er blevet et ord, der dækker alt fra en chatbot til et fuldautomatisk system. Denne artikel skiller begreberne ad og giver et praktisk grundlag for at vurdere, hvornår en agent er den rigtige løsning, og hvornår den ikke er.
I denne artikel
Det korte svar
En AI-agent er software, der arbejder mod et afgrænset mål ved selv at vælge mellem et begrænset sæt værktøjer og godkendte datakilder, styret af instrukser, rettigheder og stopregler.
Den giver mening, når en opgave kræver fortolkning af tekst, dokumenter eller andet ustruktureret input, kombineret med opslag i flere kilder, og når opgaven gentager sig ofte nok til, at det kan betale sig at bygge og drifte en løsning.
Den giver sjældent mening, når alle trin kan beskrives med faste regler. Så er et almindeligt automatiseret workflow billigere, mere forudsigeligt og lettere at teste. Resten af artiklen folder det svar ud.
Fire begreber, der ofte blandes sammen
I samtaler om AI i virksomheder dækker ordet "agent" ofte over fire forskellige ting, som har helt forskellig pris, risiko og driftsbyrde:
- Generisk AI-chat: svarer på spørgsmål i fri dialog. God til opslag og formulering, men kender normalt ikke jeres proces, ansvar eller systemgrænser, og den udfører ikke kontrollerede handlinger i jeres systemer.
- Automatiseret workflow: udfører kendte trin efter faste regler. Stabilt, billigt i drift og let at teste, men det fortolker ikke. Møder det et input, reglerne ikke dækker, stopper det eller fejler.
- Specialiseret AI-agent: fortolker input og vælger selv næste skridt inden for afgrænsede værktøjer, kilder og instrukser. Kan håndtere variation, men kræver kontrolmekanismer, fordi dens valg ikke er deterministiske.
- Custom app med agenter: samler brugerflade, processtatus, regler, integrationer og godkendelser i ét arbejdsredskab, hvor agenter løser afgrænsede delopgaver. Brugerfladen behøver ikke ligne en chat.
Mange skuffede AI-projekter er reelt et forkert valg mellem de fire, ikke dårlig teknologi. En virksomhed, der har brug for et stabilt workflow, køber en agent. En virksomhed med et fortolkningsproblem bygger regler. Begge dele fejler forudsigeligt.
Hvad en agent faktisk består af
En seriøs agent er ikke en prompt. Den er summen af en række designvalg, som skal træffes eksplicit:
- Et afgrænset mål: hvilken opgave skal løses, og hvordan ser et godt resultat ud?
- Godkendte datakilder: hvad må agenten læse, og mindst lige så vigtigt, hvad må den ikke se?
- Navngivne værktøjer: hvilke handlinger kan den udføre, og hvilke er eksplicit forbudt?
- Instrukser og kvalitetskrav: hvordan skal den arbejde, og hvad skal den aflevere?
- Rettigheder: hvilken identitet handler den med, og med hvor lidt adgang kan den nøjes (least privilege)?
- Stop- og eskaleringsregler: hvornår skal den stoppe og bede et menneske om hjælp i stedet for at gætte?
- Logning: kan et resultat spores tilbage til de kilder og valg, der skabte det?
Mangler et af punkterne, er det ikke et teknisk problem, men et styringsproblem. Det er også derfor, to agenter med samme model kan opføre sig vidt forskelligt: forskellen ligger i rammerne, ikke i modellen.
Et konkret eksempel: triage af indkommende henvendelser
Tag en fælles postkasse med blandede henvendelser: ordrer, reklamationer, servicespørgsmål og alt muligt andet. I dag åbner en medarbejder hver mail, vurderer den og fordeler den. Opgaven kræver fortolkning (fritekst), opslag (kunde- og sagshistorik) og gentager sig dagligt. Det er en klassisk agentkandidat.
En forsvarlig første version læser postkassen og sagssystemet, klassificerer henvendelsen, henter relevant historik og lægger et forslag til kategori, prioritet og svarudkast i en kø. Medarbejderen godkender, retter eller afviser. Agenten sender intet selv, og alt kan spores.
Bemærk, hvad der ikke sker: agenten svarer ikke kunden direkte, den opretter ikke ordrer, og den sletter intet. Handlekraften kan udvides senere, når kvaliteten er dokumenteret, og kun for de handlinger, hvor gevinsten står mål med risikoen.
Hvornår giver en agent mening?
Tre forhold skal typisk være til stede samtidig:
- Fortolkning: input er fritekst, dokumenter, billeder eller skøn, som ikke kan beskrives med faste regler.
- Opslag: svaret kræver, at der hentes og sammenholdes information fra flere kilder.
- Gentagelse: opgaven forekommer ofte nok til, at bygge- og driftsomkostningen tjener sig hjem.
Typiske mønstre ud over triage er udkast til dokumentation ud fra noter og systemdata, kontrol af leverancer mod definerede krav, statusopsamling på tværs af systemer og søgning i godkendte interne kilder med kildehenvisning. Fælles for dem er, at agenten laver udkast og forslag, mens et menneske beslutter.
Hvornår er en agent det forkerte valg?
- Når processen kan beskrives fuldt med regler: brug klassisk automation. Den er billigere, hurtigere og lettere at fejlsøge.
- Når konsekvensen ved fejl er høj, og der ikke findes en forsvarlig godkendelses- eller kontrolmekanisme mellem agentens forslag og handlingen.
- Når processen er uklar: en agent oven på en uklar proces gør fejlene hurtigere og mere konsekvente, ikke færre.
- Når opgaven er sjælden og lille: manuel håndtering kan være det ærlige og billigste svar.
Og et beslægtet fravalg: multi-agent arkitektur med mange specialiserede roller lyder imponerende, men hver ekstra agent tilføjer fejlkilder, omkostning og styringsbehov. Rolleopdeling giver mening, når indsamling, kontrol og integration reelt har forskellige krav til adgang og kvalitet, ikke som udgangspunkt. Den enkleste tilstrækkelige arkitektur vinder.
Handlekraft: fra læseadgang til handling
Agentens handlekraft bør vælges pr. workflow, ikke som et generelt princip. En praktisk skala har fire niveauer: læse, foreslå, handle med godkendelse og handle inden for faste, reversible grænser.
En pilot begynder normalt på de to første niveauer: agenten læser godkendte kilder og afleverer udkast. Først når kvaliteten er dokumenteret på rigtige opgaver, udvides handlekraften trin for trin. Kritiske, eksterne eller irreversible handlinger bør kræve menneskelig godkendelse, og håndhævelsen bør ligge i deterministisk kontrolkode, ikke i agentens egen vurdering af, hvad den må.
Det, der ofte glemmes: drift
En agent er ikke færdig, når den virker første gang. Kilder ændrer sig, systemer opdateres, og opgavens indhold glider. Derfor hører monitorering, stikprøvekontrol af kvalitet, loggennemgang og en fallback-plan med i beslutningen, ligesom det skal være aftalt, hvem der ejer løsningen i drift.
Regn driftsbyrden med, når casen vurderes. En lille agent med klar ejer og enkel drift slår en ambitiøs agent, ingen vedligeholder.
Sådan kommer I i gang
Start ikke med teknologien, men med ét konkret workflow: opgave, brugere, input, output og flaskehalse. Afklar dernæst data og risiko: hvilke kilder skal bruges, må de bruges, og hvad er konsekvensen ved fejl. Byg først derefter en read-only eller kladdebaseret pilot, og mål den mod en baseline.
Er der flere mulige workflows, eller er datagrundlaget uklart, er en afgrænset kortlægning det naturlige første skridt, før der investeres i udvikling.
Læs også
Usikker på, om jeres opgave kalder på en agent?
Beskriv ét konkret workflow, så vurderer vi, om en AI-agent, klassisk automation eller en kombination er den enkleste forsvarlige vej.
Vurdér et workflow →