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

Ordet AI-agent bliver brugt om alt fra en chatbot til et system, der kan læse mail, opdatere sager og sende svar. Det gør samtalen unødigt uklar. Det afgørende er ikke produktets etiket, men hvem der vælger næste skridt, hvilke værktøjer systemet kan bruge, og om handlingerne får virkning uden en ny menneskelig beslutning.

En brugbar arbejdsdefinition er: En AI-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 dermed ikke kun et svarfelt. Den indgår i en løkke, der kan læse, beslutte, handle og observere.

Tre systemer, der skal holdes adskilt

En fast arbejdsgang er ofte det bedre design, når trinnene er kendte. Den er lettere at teste, forklare og afbryde, og dens mulige veje kan gennemgås på forhånd. Agenten giver fleksibilitet, men fleksibiliteten udvider også det område, hvor modellen kan vælge forkert. Brug derfor ikke agentarkitektur som et modenhedstegn. Tilføj kun dynamiske valg, når de løser et dokumenteret problem, som en enklere arbejdsgang ikke løser.

Seks dele under agentens overflade

Et agentisk system er mere end modellen. Når man vurderer det som en samlet løsning, bliver seks dele synlige:

• Model: fortolker målet, vælger et muligt næste skridt og formulerer input til et værktøj. Modellen kan variere mellem kørsler og kan producere ubegrundede antagelser.
• Værktøjer: søgning, databaseopslag, mail, kalender, filsystem, kodekørsel eller andre API’er. Værktøjet skaber den faktiske handlekraft.
• Data: brugerens instruktion, dokumenter, søgeresultater og værktøjsoutput. Noget er betroet, andet kan være fejlbehæftet eller fjendtligt.
• Tilstand: arbejdshukommelse, historik, gemte planer og tidligere resultater. Tilstanden fortæller agenten, hvor den tror, den er i forløbet.
• Tilladelser: de konti, nøgler, mapper, data og handlinger, agenten faktisk har adgang til. Tilladelser bestemmer fejlens mulige rækkevidde.
• Evaluering: testopgaver, acceptkriterier, loggennemgang og produktionsmålinger. Uden dem ved organisationen ikke, om systemet løser opgaven eller blot afslutter den.

Arkitekturen skal beskrive alle seks. En demonstration, hvor modellen vælger det rigtige værktøj én gang, dokumenterer hverken adgangskontrol, håndtering af forældet tilstand eller adfærd på grænsetilfælde.

Et tænkt eksempel: fælles indbakke

Tænkt eksempel: En servicefunktion vil håndtere en fælles indbakke. Den første idé er en agent, der læser hver mail, finder kundens oplysninger, vurderer emnet, opdaterer sagen og sender et svar. I den afgrænsede del af den tænkte indbakke følger henvendelserne fire kendte trin: klassificér efter en godkendt liste, udtræk aftalte felter, slå sagen op og lav et udkast. En medarbejder skal godkende ændring og afsendelse.

I dette tænkte eksempel giver en fast arbejdsgang et tydeligere design. Klassifikationen kan testes separat. Manglende felter sender sagen til en menneskelig kø. Opslaget er læseadgang, og skrivning kræver godkendelse. Først hvis en væsentlig gruppe af legitime sager kræver uforudsigelige undersøgelser på tværs af kilder, er det relevant at teste en begrænset agent i den del af forløbet.

Eksemplet viser også, at »agent eller ej« 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.

Fem fejlmønstre, der ændrer designet

1. Prompt injection

En agent læser ofte tekst fra steder, brugeren ikke kontrollerer: en mail, en hjemmeside, et dokument eller et værktøjsresultat. Teksten kan indeholde instruktioner, der forsøger at ændre modellens mål eller få den til at bruge sine rettigheder på en anden måde. OWASP beskriver både direkte og indirekte prompt injection og fremhæver, at risikoen bliver større, når modeloutput kan drive værktøjer.

En stærkere systemprompt er ikke en tilstrækkelig 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.

2. For stor handlefrihed

Hvis agenten har flere funktioner, tilladelser eller selvstændige beslutninger end opgaven kræver, kan en misforståelse få stor virkning. Et system, der kun skal foreslå et mødetidspunkt, behøver ikke ret til at slette kalenderaftaler eller invitere eksterne deltagere uden godkendelse. Begræns funktion, tilladelse og autonomi hver for sig.

3. Forkert brug af et legitimt værktøj

Et værktøj kan fungere præcis som programmeret og stadig blive brugt forkert. Agenten kan vælge forkert kunde, overskrive det forkerte felt eller sende en korrekt formuleret mail til en forkert modtager. Valider derfor identitet, parametre, omfang og forretningsregel umiddelbart før udførelse. Modelteksten er input, ikke autorisation.

4. Forældet eller forgiftet tilstand

En gemt plan kan bygge på en pris, en adgang eller en sagsstatus, der siden er ændret. Langtidshukommelse kan også indeholde en tidligere fejl eller manipuleret tekst. Giv tilstand tidsstempel, kilde og udløb, og hent kritiske forhold på ny før en uigenkaldelig handling. Brug ikke hukommelse som sandhedskilde, bare fordi den ligger tæt på modellen.

5. Kaskaderende fejl

I en løkke bliver ét forkert mellemresultat til kontekst for næste trin. I et system med flere agenter kan fejlen brede sig gennem delegation, gentagne forsøg eller delte lagre. Sæt grænser for antal trin, kald, tid og omkostning. Kontrollér mellemresultater ved kritiske overgange, og lad ikke en underagent udvide sin egen adgang.

Kontrolarkitekturen før modelvalget

Fem kontroller bør tegnes ind, før man diskuterer, hvilken model der skal bruges:

• Mindst mulige rettighed: Agenten får kun de data, værktøjer og handlinger, den konkrete opgave kræver. Læsning og skrivning bruger adskilte rettigheder, og adgangsnøgler er afgrænsede og kan trækkes tilbage.
• Godkendelsesporte: Et menneske skal godkende, før systemet sender, betaler, sletter, publicerer, ændrer en rettighed eller på anden måde skaber væsentlig ekstern virkning. Godkendelsen viser mål, data, foreslået handling og konsekvens – ikke kun en vag knap.
• Logning: Registrér model- og promptversion, datakilder, værktøjskald, parametre, resultater, godkendelser, fejl og stopårsag i et format, der kan undersøges. Beskyt loggen og undgå unødige følsomme oplysninger.
• Kill switch: En navngiven ejer kan straks stoppe nye kørsler, tilbagekalde nøgler og forhindre ventende handlinger. Funktionen skal prøves; et telefonnummer i en plan er ikke en teknisk afbrydelse.
• Ressourcegrænser: Maksimér ikke friheden. Sæt loft over trin, gentagelser, samtidige handlinger, beløb, datamængde og tid, og send overskridelser til et menneske.

Et godkendelsespunkt skal placeres før den handling, der skaber konsekvensen. Hvis agenten allerede har sendt mailen eller ændret sagen, er efterfølgende menneskelig gennemgang overvågning, ikke godkendelse.

Byg et evalueringssæt, før I bygger selvtillid

Start med et afgrænset sæt opgaver fra den virkelige anvendelse, renset for unødige persondata og fortrolighed. Medtag almindelige forløb, manglende oplysninger, modstridende kilder, forældet tilstand, værktøjsfejl, forsøg på prompt injection og tilfælde, hvor den korrekte handling er at stoppe. Skriv det forventede resultat og de tilladte værktøjskald, før agenten testes.

Mål slutresultatet og vejen dertil hver for sig: Blev opgaven løst? Var alle handlinger tilladte? Blev den rigtige identitet og kilde brugt? Stoppede systemet ved den aftalte grænse? Kunne loggen forklare forløbet? Var menneskets godkendelse informeret? Gentag relevante opgaver, fordi en enkelt vellykket kørsel ikke beskriver variationen.

En udrulningsstige med mulighed for at gå ned igen

1. Simulering: Agenten bruger syntetiske eller kontrollerede data og falske værktøjer. Ingen produktionshandling er mulig.
2. Skygge: Agenten kører på realistiske input, men dens handlinger udføres ikke. Resultatet sammenlignes med den normale proces.
3. Forslag: Agenten foreslår værktøjskald; et menneske udfører dem manuelt.
4. Godkendt udførelse: Systemet kan udføre afgrænsede handlinger efter en informeret menneskelig godkendelse.
5. Begrænset autonomi: Kun handlinger med dokumenteret lav konsekvens kan ske uden forhåndsgodkendelse; stikprøver, overvågning og grænser fortsætter.

Hvert trin kræver egne tærskler og en vej tilbage. En model-, prompt-, værktøjs- eller datakildeændring kan udløse ny test eller et trin ned. Hvis gevinsten kun findes på det højeste autonominiveau, mens fejlene ikke kan opdages og begrænses, er anvendelsen ikke klar til den udrulning.

Artiklen Sådan skriver du en prompt, der faktisk kan bruges hjælper med selve instruktionen, men en god prompt erstatter ikke adgangskontrol. Til en fælles introduktion kan foredraget Fra chatbot til AI-agent gøre de tre systemtyper konkrete. Og når en arbejdsgang skal afprøves på egne opgaver, er workshoppen fra idé til testet AI-arbejdsgang det mere praktiske format.

Konklusion: En agent er et modelstyret handlingsforløb, ikke bare en mere veltalende assistent. Brug en fast arbejdsgang, når trinnene kan kendes på forhånd. Hvis fleksibiliteten kræver en agent, så design model, værktøjer, data, tilstand, tilladelser og evaluering som ét system. Begræns rettigheder, læg godkendelsen før konsekvensen, log forløbet, prøv afbrydelsen og gå kun op ad udrulningsstigen på dokumenteret adfærd.

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.