Hvad er en AI-agent? Forklaring, eksempler og forskellen på chatbots

Hvad er en AI-agent? Forklaring, eksempler og forskellen på chatbots

Hvad er en AI-agent?

En AI-agent er et system, der arbejder mod et mål ved at observere en situation, forstå en opgave, planlægge handlinger og udføre dem mere eller mindre autonomt.

Hvor en klassisk chatbot primært svarer på spørgsmål, kan en AI-agent typisk:

  • få et overordnet mål (fx “forbered et salgsmøde i morgen”)
  • samle information fra forskellige systemer
  • planlægge flere trin for at nå målet
  • gennemføre handlinger på tværs af værktøjer og platforme

Det afgørende kendetegn er altså, at agenten ikke kun genererer tekstsvar, men også kan handle på dine vegne inden for nogle aftalte rammer. Hvor autonom den er, afhænger af designet: fra “foreslår næste skridt” til “kører fulde workflows selv”.

AI-agent, AI-assistent og chatbot – hvad er forskellen?

De tre begreber bliver ofte blandet sammen, men de dækker forskellige niveauer af funktion og autonomi.

Chatbot: samtale og svar

En chatbot er et dialogsystem. Den er typisk:

  • spørgsmål/svar-drevet – du spørger, den svarer
  • afgrænset til én kanal – fx en chatboks på en hjemmeside
  • ofte bundet til faste flows – ja/nej-knapper, simple FAQ-svar

Moderne chatbots bruger ofte store sprogmodeller, men de gør stadig mest det samme: de holder en samtale og hjælper dig med information.

Eksempel: En kunde skriver “Hvornår har I åbent?” i en webchat, og chatbotten svarer med åbningstiderne.

AI-assistent: hjælp til opgaver

En AI-assistent er et skridt videre. Den:

  • hjælper dig med konkrete opgaver, når du beder om det
  • kan arbejde lidt mere “hands-on” (skrive, omskrive, strukturere)
  • er stadig primært brugerdrevet – den gør noget, når du siger til

Eksempel: Du beder en assistent: “Skriv et udkast til en mail til kunden om forsinket levering i en venlig, professionel tone”, og den producerer teksten. Den sender ikke selv mailen.

AI-agent: mål, plan og handling

En AI-agent går længere end både chatbot og assistent. En agent:

  • får et mål i stedet for et enkelt spørgsmål
  • kan planlægge flere skridt for at nå målet
  • har adgang til værktøjer og systemer (fx CRM, kalender, mailsystem)
  • kan handle autonomt inden for rammer, du har sat

Eksempel: Du siger: “Forbered mit salgsmøde med Kunde X i morgen”. Agenten kan så:

  • slå kunden op i CRM
  • hente tidligere mails og mødenoter
  • analysere kundens købshistorik
  • foreslå dagsorden og lave en præsentation
  • lægge udkast i din kalender eller sende kladden til dig

Den store forskel er altså graden af autonomi og systemadgang. Chatbotten svarer. Assistenten hjælper, når du beder om det. Agenten arbejder aktivt mod et defineret mål og kan selv tage næste skridt.

Hvordan fungerer en AI-agent teknisk?

Inde i maskinrummet består en AI-agent typisk af flere lag, der arbejder sammen. Detaljerne varierer fra system til system, men den overordnede idé går ofte igen.

1. Sprogmodel: forstå og beslutte

Kernen er næsten altid en sprogmodel (LLM), som kan:

  • forstå brugerens input og konteksten
  • dele opgaven i mindre delopgaver
  • vælge, hvilke værktøjer der skal bruges hvornår

Det er den del, der vurderer: “Hvad er det egentlige mål her, og hvad er et fornuftigt næste skridt?”

2. Planlægning: fra mål til trin

Når målet er forstået, laver agenten typisk en plan:

  • Hvilke delopgaver skal løses?
  • I hvilken rækkefølge?
  • Hvad kræver menneskelig godkendelse, og hvad kan køre selv?

Nogle agenter planlægger eksplicit (“først A, så B, så C”), andre arbejder mere iterativt og justerer løbende ud fra resultaterne, de får tilbage.

3. Værktøjskald og orkestrering

For at kunne handle skal agenten kunne kalde værktøjer. Det kan fx være:

  • REST-API’er til CRM, ERP, ticket-systemer osv.
  • eget backend-system, databaser eller søgetjenester
  • webhooks, der udløser baggrundsjob eller eksterne workflows

Selve “hvem kaldes hvornår” styres af et lag af orkestrering. Det er koden, der binder sprogmodellen sammen med dine systemer, sørger for autentificering, fejl-håndtering, retries, tidsgrænser osv.

Hvis du vil forstå den del mere teknisk, er det tæt beslægtet med at bygge andre API-integrationer. Her kan du fx læse om, hvordan du stopper med at være bange for REST-API’er og om robust håndtering af webhook endpoints.

4. RAG: hente viden før modellen svarer

Mange agenter bruger RAG (Retrieval-Augmented Generation):

  • agenten søger først i dine dokumenter, databaser eller systemer
  • de relevante bidder (fx tekstuddrag) sendes ind til sprogmodellen
  • modellen genererer så et svar eller næste skridt baseret på både prompt og de hentede data

RAG er en måde at undgå at “lære modellen alt på forhånd” og i stedet slå op i din viden, når det er nødvendigt. Det stiller krav til god datatilgang, caching og validitet af kilderne. Ellers risikerer du, at cachen lyver oftere end din kode.

5. MCP og lignende protokoller

Der findes også standardiserede måder at give agenten adgang til værktøjer på, fx protokoller som MCP (Model Context Protocol) og andre værktøjs- og plugin-økosystemer. Pointen er den samme: i stedet for at bygge alle integrationer fra bunden, beskriver du værktøjerne i et format, som agenten kan forstå og kalde på en struktureret måde.

6. Udførelse, logning og feedback

Til sidst udfører agenten handlingerne og logger, hvad der er sket:

  • hvilke værktøjer blev kaldt?
  • hvilke data blev læst og skrevet?
  • hvad blev foreslået til brugeren, og hvad blev gennemført?

De logs er vigtige for både fejlfinding og styring. Hvis du har arbejdet med observability, kender du logik som i logs vs. mavefornemmelse. Det samme gælder her: du vil kunne se, hvad agenten faktisk gjorde – ikke kun hvad du håber, den gjorde.

Hvilke typer AI-agenter findes der?

“AI-agent” er et bredt ord. I praksis taler man ofte om forskellige typer, der varierer i, hvor meget de forstår, og hvor autonome de er.

Simple refleks-agenter

Reagerer direkte på nuværende input uden at tænke på historie eller fremtid.

  • “Hvis bruger spørger om X, så gør Y”
  • kan godt bruge en sprogmodel, men logikken er stadig enkel
  • minder om avancerede regler med lidt mere fleksibel sprogforståelse

Modelbaserede agenter

Har en intern model af tilstanden: hvad der allerede er sket, hvilke data der findes, og hvad der er vigtigt lige nu.

  • kan huske tidligere trin i et workflow
  • kan vurdere, om noget skal gentages eller forbedres
  • er typisk mere robuste i længere forløb

Målorienterede agenter

Får et mål og vælger derefter selv handlinger.

  • optaget af: “Kommer dette skridt tættere på målet?”
  • kan selv foreslå nye delmål
  • bruges ofte til opgaver, hvor slutresultatet er vigtigere end præcis vej derhen

Utility-baserede agenter

Forsøger at maksimere en slags “nytteværdi” (utility). Det kan være:

  • kundetilfredshed
  • indtjening
  • risiko reduceret til et tal

De vælger blandt mulige handlinger ud fra, hvad der giver højest forventet værdi ifølge den model, de har.

Lærende agenter

Lærende agenter justerer deres adfærd over tid.

  • bruger feedback fra brugere og systemer
  • kan forbedre planer og strategier automatisk
  • kan både være målorienterede og utility-baserede

I praksis ender mange rigtige løsninger som en blanding: lidt refleks (simple regler), lidt model (tilstand), et mål og noget læring. Det vigtigste for dig er at vide, at “AI-agent” ikke kun er én skarp kategori – det er et spænd fra simple reaktive flows til meget sofistikerede, selvtilpassende systemer.

Eksempler på AI-agenter i praksis

Det bliver først rigtigt interessant, når agenter binder flere trin sammen i konkrete processer. Her er nogle typiske anvendelser, som går igen i researchen.

Salg og salgsforberedelse

  • samle kundedata fra CRM, mails og mødenoter
  • analysere tidligere interaktioner og købsmønstre
  • generere mødeagenda og skræddersyede argumenter
  • forberede udkast til tilbud eller opfølgningsmails

Her arbejder agenten som en “research- og forberedelsesmaskine” for sælgeren, som stadig træffer den endelige beslutning.

Kundeservice og support

  • klassificere indkomne henvendelser
  • slå relevant viden op i dokumentation og historik
  • foreslå svar til medarbejderen eller sende svar i simple sager
  • oprette, opdatere og lukke sager i ticket-systemet

En almindelig chatbot kan svare på simple spørgsmål. En agent kan arbejde tværs over kanaler og systemer, fx oprette en sag, følge op og sende besked, når noget er løst.

HR, onboarding og intern support

  • guide nye medarbejdere gennem onboarding-opgaver
  • bestille udstyr, oprette brugere og sende relevante dokumenter
  • svare på spørgsmål om interne processer og politikker
  • mindes om frister – fx prøveperioder eller kurser

Her kan agenten aflaste HR med mange gentagne, standardiserbare trin, men med mulighed for at sende sager videre til et menneske ved tvivl.

Research og dokumentation

  • samle information fra interne og eksterne kilder
  • lave første udkast til rapporter, notater eller oversigter
  • linke til kilder og dokumenter i jeres egne systemer
  • opdatere vidensbaser med nye svar, når der laves ændringer

Her er RAG særligt relevant: agenten henter viden fra jeres dokumenter og sikrer, at svaret afspejler den nyeste dokumentation.

Produktbeskrivelser og marketing-workflows

  • læse data om nye produkter fra et PIM-system eller regneark
  • generere produkttekster i forskellige varianter (lang/kort, dansk/engelsk)
  • tilpasse tone til forskellige kanaler (webshop, nyhedsbrev, SoMe)
  • lægge udkast ind i CMS eller marketingværktøjer

Agenter kan også holde styr på, hvilke tekster der allerede er publiceret hvor, så du undgår manuelt copy-paste-arbejde (og fejl).

Administrative workflows

  • læse indkomne mails og fordele dem til rette system
  • udfylde felter i formularer og sager
  • tjekke, om der mangler information, og bede om det
  • lukke simple sager automatisk og eskalere komplekse

Det er her, AI-agenter for alvor begynder at ligne klassisk procesautomatisering – bare med mere fleksibel sprogforståelse og bedre håndtering af det “u-strukturerede” (mails, PDF’er, noter).

Hvornår er en chatbot nok – og hvornår giver en AI-agent mening?

Det giver ikke mening at bygge en fuld AI-agent til alt. Nogle problemer er bedst løst med en simpel, robust chatbot.

Vælg en chatbot, når:

  • brugerne primært har korte, simple spørgsmål (åbningstider, priser, basale vilkår)
  • der stort set ikke skal handles i andre systemer – information er nok
  • du vil starte forsigtigt med AI i en tydelig og afgrænset use case
  • du har begrænset tid og budget til integrationer

Vælg en AI-agent, når:

  • opgaven er målstyret og flertrins (fx “opret en sag, indhent manglende data, følg op og luk den”)
  • der skal arbejdes på tværs af flere systemer og kanaler
  • der er mange gentagne workflows, som følger nogenlunde samme struktur
  • du er klar til at investere i integration, sikkerhed og overvågning

En tommelfingerregel: Hvis du kan beskrive opgaven som en lille proces med flere tydelige trin på tværs af systemer, er en agent relevant at overveje. Hvis du mest vil aflaste support med simple svar, så start med en chatbot eller en mere “passiv” AI-assistent.

Begrænsninger, risici og governance

AI-agenter kan være kraftfulde – og netop derfor kræver de styring. Autonomi gør behovet for kontrol større, ikke mindre.

Hallucinationer og fejl

Sprogmodeller kan “hallucinere”: finde på svar, der lyder overbevisende, men er faktuelt forkerte. I en agent er det ekstra alvorligt, fordi fejl ikke kun giver forkerte svar, men også kan føre til forkerte handlinger:

  • forkert opdatering af kundedata
  • fejl i beregninger eller rapporter
  • mails sendt til forkerte modtagere

Du bør altid have sikkerhedsnet:

  • klare grænser for, hvad agenten gøre autonomt
  • menneskelig godkendelse til risikofyldte handlinger
  • kontrol af kritiske felter og beregninger

Adgangskontrol og rettigheder

Agenter virker fristende at give “super-adgang”, så de kan løse mest muligt. Det er ofte en dårlig idé.

  • begræns rettigheder til mindste nødvendige niveau
  • adskil læse- og skriveadgang, hvor det er muligt
  • brug separate servicekonti med egne nøgler og tokens

Hvis du vil gå mere praktisk til værks med nøgler og tokens, er det værd at læse om sikker håndtering af API-nøgler, hvorfor secrets skal være kedelige og hvordan du undgår at gemme tokens tilfældigt i din webapp.

Logning, sporbarhed og ansvar

Når en agent handler på dine vegne, skal du kunne svare på:

  • hvorfor blev denne beslutning taget?
  • hvilke data blev brugt?
  • hvad blev der faktisk gjort hvornår?

Det kræver:

  • detaljerede logs og sporbarhed
  • en klar governance-model for, hvem der ejer og justerer agentens adfærd
  • processer for revision, tests og godkendelse, når agentens “regler” ændres

Her minder arbejdet meget om almindelig softwaredrift og compliance, bare med et ekstra lag af sandsynlighed og usikkerhed ovenpå.

Data, privatliv og samtykke

AI-agenter arbejder ofte på følsomme data: kundedata, medarbejderdata, forretningshemmeligheder. Du skal forholde dig til:

  • hvilke data sendes gennem hvilke LLM-API’er?
  • hvordan opfylder du GDPR-krav til oplysning og sletning?
  • hvornår kræver det samtykke, hvis data bruges til træning eller forbedring?

Hvis agenten interagerer med brugerdata i webapplikationer, hænger det også sammen med, hvordan du håndterer cookies, tracking og databehandling generelt – fx ikke at fake dit cookie-banner eller undervurdere, hvor meget din lille webapp ved om folk.

Autonomi er et valg, ikke en pligt

Det er værd at understrege: Du kan (og bør ofte) starte med lav autonomi:

  • agenten foreslår – et menneske godkender
  • agenten udfører kun “ufarlige” handlinger selv
  • autonomien øges gradvist, når du har data og erfaring til at bakke det op

Det er bedre at have en lidt mindre “smart” agent, du stoler på, end en super-autonom agent, du er utryg ved.

Kort om pris, implementering og drift

Priserne på AI-agenter varierer meget. Der findes ingen officiel “listepris”, men researchen peger på nogle typiske niveauer, som du kan bruge som grovt pejlemærke – ikke som faste tal.

Udvikling og projekter

  • Konsulenttimer: omkring 900 – 1600 kr. pr. time ekskl. moms for IT-/softwarekonsulenter, afhængigt af erfaring og firma (estimat fra Perplexity-research, ikke en officiel takst)
  • Discovery/PoC: fx 40.000 – 90.000 kr. for at afklare use case, lave prototype og teste idéen
  • MVP: fx 120.000 – 300.000 kr. for en første version i drift med basale integrationer

Det er meget grove intervaller, og rigtige projekter kan ende både under og over, afhængigt af kompleksitet, krav til sikkerhed og hvor mange systemer, der skal med.

Drift og licenser

  • LLM-API-forbrug: ofte i størrelsesordenen 200 – 2.000 kr. pr. måned for en mindre eller mellemstor virksomhedsagent, afhængigt af brug
  • Cloud-hosting og infrastruktur: fra få hundrede til få tusinde kroner om måneden, afhængigt af skala
  • Vedligehold og videreudvikling: fx 5.000 – 30.000 kr. pr. måned til løbende tilpasninger, overvågning og forbedringer

Dansk Industri har i et eksempel nævnt AI-softwareomkostninger omkring 200 – 500 kr. pr. medarbejder pr. måned. Det er ét konkret scenarie, ikke en generel markedspris.

Pointen er: Der er både en projektomkostning (at komme i gang) og en driftsomkostning (at holde agenten sikker, opdateret og nyttig). Hvis du står foran et AI-agentprojekt, er det ofte værd først at overveje, om processen i det hele taget giver mening at automatisere – lidt ligesom når man skal vurdere, om det er nu, man skal optimere performance, eller om man skal vente, som diskuteret i artiklen om at lade være med blindt at jagte Bun-hastighed.

Sådan kan du tænke dine første skridt med AI-agenter

Nogle praktiske tommelfingerregler, hvis du overvejer AI-agenter:

  • Start med en konkret proces, der allerede fungerer nogenlunde stabilt manuelt.
  • Begynd ofte med en AI-assistent eller chatbot, der foreslår og hjælper – før du giver fuld autonomi.
  • Byg de tekniske fundamenter ordentligt: API-adgange, tokens, baggrundsjob, rate limiting og logning. Mange af de samme mønstre går igen som i artiklerne om baggrundsjob uden drama, rate limiting i praksis og asynkronitet.
  • Design din governance fra starten: hvem ejer agenten, hvem godkender ændringer, og hvordan måler I, om den hjælper eller skader?

Hvis du først vil have flere grundbegreber på plads, kan du også dykke videre ned i kategorien om it- og teknologiforståelse eller se, hvilke nye værktøjer og trends der lige nu driver udviklingen inden for AI-agenter.

Giv kun de API-tokens og scopes, agenten konkret behøver, brug kortlivede credentials og en mellemservice der filtrerer og masker følsomme felter. Implementer input/output-sanitization og data-loss-prevention, så agenten aldrig får rå adgang til fulde databaser eller persondata uden eksplicit godkendelse.
Log alle forespørgsler, valgte værktøjer og det rationale modellen bruger til at vælge handlinger, og gem disse logs i en revisionsdatabase. Tilføj versionsstyring af prompts og mulighed for at reproducere beslutningsstien, og brug menneskelig godkendelse for kritiske trin.
Byg et lille POC med ét klart mål, f.eks. 'forbered møde' med integration til kalender og CRM, og hold handlingerne sandboxed eller i udkast-tilstand. Brug en simpel stack som Python + en LLM-klient (fx LangChain), en lille REST-endpoint og en database til logs, så du hurtigt kan måle tid sparet og fejlrate.
Design operationer som idempotente hvor muligt, tilbyd preview- eller udkast-mode før irreversible handlinger, og implementer undo-endpoints eller kompensationsjobs for ændringer. Sørg også for løbende backups og monitoring med alerts, så du kan opdage og reagere på uventede handlinger hurtigt.

Sara Vestergaard er selvlært kode-nørd, der stille og roligt er gået fra at rode med en enkelt HTML-side til at bygge små værktøjer, scripts og hjemmesider til sig selv og vennerne. Hun startede med at lave en simpel band-hjemmeside som teenager og opdagede, hvor tilfredsstillende det er, når noget, du har skrevet, pludselig lever på skærmen.

For Sara handler kodning ikke om store ord eller imponerende titler, men om meget konkrete problemer: den kedelige opgave, der tager for lang tid, den ven der mangler en lille porteføljeside, eller den liste, der burde sortere sig selv. Hun elsker at pille ting fra hinanden – også kode – for at se, hvad der egentlig foregår, og hun har brugt utallige aftener på at google fejlbeskeder, teste små eksempler og langsomt bygge sin forståelse op.

På Coding Class deler hun den tilgang videre. Hun skriver til dig, der gerne vil lære at kode ved at gøre det i praksis: små projekter, korte kodebidder og forklaringer, der hænger sammen med det, du faktisk sidder med på skærmen. Hun skærer ind til benet, viser typiske fejl og deres løsninger og giver altid et forslag til, hvordan du kan bygge en tand videre, når grundideen først virker.

Når hun ikke skriver til Coding Class eller nørkler med nye små projekter, hænger Sara på klatrevæggen, vander sine altanplanter eller spiller gamle Nintendo-spil. Men hun ender næsten altid tilbage ved tasterne – for der er altid endnu en lille ting, der kunne være smartere, hurtigere eller bare lidt sjovere at bruge.

Send kommentar

You May Have Missed