Hvad er en AI-agent – og hvornår giver den mening?

“AI-agent” er blevet et ord, der bliver sat på næsten alt. Nogle kalder en chatbot med et par ekstra funktioner for en agent. Andre mener et system, der selv kan læse mail, slå noget op i et system og vælge næste handling. Det gør det svært at tale præcist om både muligheder og risici.

Assistent, arbejdsgang eller agent?

Den nyttige forskel er ikke navnet, men hvem der vælger næste skridt. I en almindelig assistent vælger brugeren: spørg, læs svar, gør noget. I en fast arbejdsgang er trinnene bestemt på forhånd i kode eller regler, og en model kan løse enkelte af dem. I et agentisk system får modellen lov til at vælge mellem flere værktøjer eller handlinger undervejs.

En brugbar arbejdsdefinition er, at en agent er et system, hvor en model løbende vælger handlinger og værktøjer for at nå et mål, bruger resultaterne som ny kontekst og fortsætter, indtil en stopbetingelse eller en menneskelig overdragelse nås. Agenten er altså ikke et svarfelt. Den er en løkke, der læser, beslutter, handler og observerer.

Modellen er kun én af seks dele i et sådant system. Der er værktøjerne – søgning, databaseopslag, mail, kalender, filer, kodekørsel – som giver den faktiske handlekraft. Der er de data, systemet arbejder på, hvoraf noget er betroet, og noget kan være fejlbehæftet eller direkte fjendtligt. Der er tilstanden: arbejdshukommelse, gemte planer og tidligere resultater. Der er tilladelserne, som bestemmer, hvor langt en fejl kan nå. Og der er evalueringen, som er det eneste, der kan fortælle, om systemet løser opgaven eller bare afslutter den.

Hvornår giver en agent faktisk mening?

Det kan være stærkt, når vejen til målet ikke kan beskrives helt på forhånd. Men fleksibiliteten er også det, der gør systemet sværere at teste. Hvis en fast arbejdsgang kan løse opgaven, er den ofte lettere at forklare, logge, begrænse og fejlfinde. “Mere agentisk” er derfor ikke det samme som “mere moden”.

Tilføj dynamiske valg, når de løser et dokumenteret problem, som en enklere arbejdsgang ikke løser. En demonstration, hvor modellen vælger det rigtige værktøj én gang, siger hverken noget om adgangskontrol, om håndtering af forældet tilstand eller om adfærd i grænsetilfælde.

Et eksempel fra support og administration

En supportmail kommer ind. Den første idé er ofte en agent, der læser hver mail, finder kundens oplysninger, vurderer emnet, opdaterer sagen og sender et svar. Men i den afgrænsede del af indbakken, hvor henvendelserne ligner hinanden, følger arbejdet fire kendte trin: klassificér efter en godkendt liste, udtræk de aftalte felter, slå sagen op og lav et udkast, som en medarbejder godkender.

Her giver en fast arbejdsgang et tydeligere design. Klassifikationen kan testes for sig. Manglende felter sender sagen i en menneskelig kø. Opslaget kræver kun læseadgang, mens skrivning kræver godkendelse. Først hvis en væsentlig del af de legitime sager kræver uforudsigelige undersøgelser på tværs af flere datakilder, kan en agent give reel mening i netop den del af forløbet.

Eksemplet viser også, at det ikke er et enten-eller for hele processen. En løsning kan være fast i indgangen, agentisk i en lukket researchfase og fast igen ved validering og godkendelse.

Værktøjer, rettigheder og prompt injection

Når et system får værktøjer, bliver tilladelser vigtigere end prompten. Kan det kun læse, eller også skrive? Må det sende mail? Hvilke mapper kan det se? Kan en tekst i en mail forsøge at instruere modellen til noget andet end det, I bad om? Jo større handlekraft, desto tydeligere skal grænser, logning og menneskelig godkendelse være.

Det sidste spørgsmål er ikke teoretisk. En agent læser ofte tekst fra steder, brugeren ikke kontrollerer: en mail, en hjemmeside, et dokument, et værktøjsresultat. Den tekst kan indeholde instruktioner, der forsøger at ændre målet eller bruge agentens rettigheder til noget helt andet. OWASP beskriver både direkte og indirekte prompt injection og fremhæver, at risikoen vokser, når modeloutput kan drive værktøjer. En strengere systemprompt er ikke en sikkerhedsgrænse. Ikke-betroet indhold skal markeres som data, værktøjskald skal begrænses i betroet kode, og agenten bør ikke samtidig have bred adgang til følsomme data og mulighed for at sende dem ud.

Fire andre fejlmønstre ændrer designet lige så meget. For stor handlefrihed: et system, der kun skal foreslå et mødetidspunkt, behøver ikke ret til at slette aftaler eller invitere eksterne deltagere. Forkert brug af et legitimt værktøj: agenten kan vælge den forkerte kunde eller sende en korrekt formuleret mail til en forkert modtager, så identitet, parametre og forretningsregel skal valideres umiddelbart før udførelsen. Forældet tilstand: en gemt plan kan bygge på en pris eller en sagsstatus, der siden er ændret, så kritiske forhold skal hentes på ny før en uigenkaldelig handling. Og kaskader: i en løkke bliver ét forkert mellemresultat til kontekst for det næste, så der skal være loft over trin, kald, tid og beløb.

Fem kontroller bør derfor tegnes ind, før man overhovedet diskuterer modelvalg: mindst mulige rettighed, en godkendelsesport placeret før den handling, der skaber konsekvensen, en log der kan undersøges bagefter, en afbryder som en navngiven ejer har prøvet af, og hårde grænser for forbrug. Ligger godkendelsen efter afsendelsen, er den overvågning – ikke godkendelse.

Vælg den enkleste løsning der virker

Mit udgangspunkt er derfor enkelt: vælg den mindst komplekse arkitektur, der kan løse den dokumenterede opgave. Hvis en almindelig automatisering gør arbejdet, så er det ikke et nederlag. Det er sandsynligvis et bedre system.

Skal en agent alligevel i drift, så byg en stige med mulighed for at gå ned igen. Start i simulering med kontrollerede data og uden mulighed for at handle. Kør derefter i skygge, hvor handlingerne ikke udføres, men sammenlignes med den normale proces. Lad så agenten foreslå værktøjskald, som et menneske udfører. Først derefter godkendt udførelse af afgrænsede handlinger, og til allersidst begrænset autonomi for det, der har dokumenteret lav konsekvens. En ændring i model, prompt, værktøj eller datakilde kan udløse en ny test eller et trin ned ad stigen.

Skal ledergruppen først finde ud af, hvor det overhovedet er værd at prøve noget, beskriver artiklen om at få hul på AI uden et års strategiarbejde en fremgangsmåde med få, afgrænsede forsøg.

En agent er et modelstyret handlingsforløb, ikke en mere veltalende assistent. Kan trinnene beskrives på forhånd, så beskriv dem. Kan de ikke, så design model, værktøjer, data, tilstand, rettigheder og evaluering som ét system, og læg godkendelsen før konsekvensen. Flere tekster om det står under temaet AI-agenter og automatisering.

En god instruktion hjælper med selve opgaven, men erstatter ikke adgangskontrol, og arbejdsdelingen mellem model og menneske afgør, hvor godkendelsen skal ligge. Skal en konkret opgave prøves af i praksis, er workshoppen Fra én opgave til en brugbar AI-arbejdsgang det rigtige format.

Kilder og videre læsning

• OWASP: Top 10 for Agentic Applications 2026, om blandt andet goal hijack, værktøjsmisbrug, rettigheder, hukommelse og kaskaderende fejl.
• OWASP GenAI Security Project: LLM01:2026 Prompt Injection, den aktuelle kanoniske beskrivelse og dens forsvar i dybden.
• NIST: Generative AI Profile til AI Risk Management Framework, med anbefalinger om test, menneske-AI-konfiguration og risikostyring.
• Anthropic: Building Effective Agents, leverandørens arkitektoniske skel mellem faste workflows og modelstyrede agenter.
• ENISA: Multilayer Framework for Good Cybersecurity Practices for AI, om sikkerhed på tværs af grundlag, AI-specifikke forhold og anvendelseskontekst.