Hvad koster en AI-agent at udvikle?
At udvikle en AI-agent der handler i jeres systemer, koster normalt 530.000 DKK–2,1 mio. DKK. Evaluering og test er den største omkostningspost fordi agenter fejler på uforudsigelige måder. Guardrails og menneskelig kontrol af kritiske beslutninger skal indgå i ethvert seriøst tilbud.
En AI-agent adskiller sig fra en chatbot på ét afgørende punkt: Den svarer ikke bare på spørgsmål, den gør ting. Den læser i jeres systemer, træffer delbeslutninger og udfører handlinger: booker, opdaterer, opretter, sender. Det gør agenter til den AI-kategori hvor værdien kan blive størst, og hvor en sjusket udvikling kan blive dyrest. Prislappen for en seriøst bygget agent ligger i 2026 normalt på 530.000 DKK–2,1 mio. DKK.
Hvad der indgår i prisen
| Omkostningspost | Andel af budgettet | Kommentar |
|---|---|---|
| Evaluering og test | 30–40 % | Testscenarier, måling af resultater, regressionstest ved hver ændring |
| Integrationer med jeres systemer | 20–30 % | API-integrationer, adgangsrettigheder, datakvalitet |
| Agentlogik og prompts | 15–25 % | Opgavedesign, valg af værktøjer, ræsonnementskæder |
| Guardrails og human-in-the-loop | 10–20 % | Adgangsgrænser, godkendelsesflows, eskaleringsveje |
| Drift og overvågning | Løbende | Logning, alarmer, kvalitetsopfølgning over tid |
Læg mærke til hvad der ligger øverst. Selve agentlogikken, det der ser imponerende ud i en demo, er en af de mindre poster. Det er alt det udenom der koster, og det er det der afgør om agenten er til at stole på.
Derfor er evaluering den største omkostningspost
Traditionel software fejler forudsigeligt: Den samme bug giver den samme fejl hver gang. En agent fejler uforudsigeligt. Den kan løse nioghalvfems sager perfekt og i sag nummer hundrede drage en konklusion som ingen havde forudset fordi den ræsonnerer sig frem i stedet for at følge faste regler.
Det kan ikke testes væk med nogle få manuelle stikprøver. En seriøs leverandør bygger en evalueringsopsætning: hundredvis af virkelige scenarier med facit, automatiske kørsler ved hver ændring og målepunkter for både slutresultatet og de enkelte trin undervejs. Opsætningen koster, men den er også det der gør at I tør give agenten mere ansvar over tid. Spørg hver leverandør: “Hvordan ved vi at agenten er blevet bedre og ikke dårligere efter en ændring?” Den der mangler et godt svar, har ikke bygget agenter i produktion.
Guardrails og human-in-the-loop er ikke tilvalg
En agent der handler i jeres systemer, har brug for tekniske værn, uanset hvor god modellen er:
- Adgangsgrænser. Agenten får kun adgang til de systemer og de data som opgaven kræver.
- Handlingsgrænser. Definér hvad agenten aldrig må gøre på egen hånd, f.eks. overføre penge, slette data eller kommunikere eksternt uden godkendelse.
- Human-in-the-loop. Kritiske beslutninger skal forbi et menneske. I begyndelsen gælder det ofte de fleste beslutninger; efterhånden som resultatdataene opbygger tillid, kan tærsklen hæves.
- Eskalering og stop. Når agenten er usikker, skal den give opgaven videre, ikke gætte. Og der skal være en tydelig nødbremse.
Ser du et tilbud hvor disse poster mangler eller er gemt væk i en fodnote, så bed om en revideret udgave. Det er ikke ekstraudstyr, det er forudsætningen for produktion.
Et konkret regneeksempel
Et ejendomsselskab vil have en agent der håndterer fejlmeldinger: læse meldingen, klassificere sagen, slå ejendommen op i ejendomssystemet, oprette en arbejdsordre og booke den rette håndværker. En PoC til 270.000 DKK viser at klassificering og opslag fungerer. Udviklingen af agenten lander på 1,3 mio. DKK, hvoraf godt en tredjedel går til evalueringsopsætningen og test mod historiske sager. Det første halve år godkender en ejendomsadministrator hver booking; derefter klarer agenten standardsager selv mens usædvanlige tilfælde eskaleres. Det er dyrere end en chatbot, men den erstatter et helt manuelt flow, ikke bare svarene på spørgsmål om det.
Regn baglæns fra værdien
En agent til 1,6 mio. DKK er billig hvis den aflaster tre fuldtidsstillinger, og dyr hvis den sparer en time om ugen. Begynd derfor med processen: volumen, tidsforbrug, fejlomkostninger. Regn også driften med: Agenter foretager ofte mange modelkald pr. opgave, så omkostningen pr. håndteret sag skal estimeres før beslutningen og ikke opdages på den første månedsfaktura. Det klogeste er at begynde med en afgrænset PoC der tester det sværeste trin i kæden før hele agentudviklingen finansieres. Vi hos Weapp bygger AI-løsninger og agenter med evaluering og værn som en del af grundleverancen og hjælper gerne med at regne på netop jeres case. Kontakt os, så tager vi den derfra.
Ofte stillede spørgsmål
Hvad adskiller en AI-agent fra en chatbot?
En chatbot svarer på spørgsmål. En agent udfører opgaver: Den kan slå information op i jeres systemer, træffe delbeslutninger og gennemføre handlinger som at opdatere en sag eller oprette en ordre. Det er evnen til at handle der gør agenter mere værdifulde og dyrere at bygge sikkert.
Hvorfor er test så meget dyrere for agenter end for anden software?
Traditionel software gør det samme hver gang og kan testes med forudsigelige testcases. En agent ræsonnerer sig frem til sine handlinger og kan vælge forskellige veje ved samme input. Derfor kræves systematisk evaluering på tværs af store mængder scenarier, måling over tid og test af kæder af beslutninger, ikke kun af enkelte svar.
Hvad er guardrails i en AI-agent?
Tekniske værn der begrænser hvad agenten må gøre: hvilke systemer den har adgang til, hvilke beløb den må håndtere, hvilke handlinger der kræver menneskelig godkendelse og hvad der sker når den er usikker. Guardrails er forskellen på en agent man tør sætte i produktion, og et eksperiment.
Kan vi starte med en enklere version af en agent?
Ja, og det er ofte klogt. En almindelig model er at agenten i første omgang kun foreslår handlinger som et menneske godkender. Når resultatdataene viser at forslagene holder høj kvalitet, kan flere trin automatiseres. Så opbygger I tillid og testdata samtidig med at risikoen holdes nede.
Hvilke processer egner sig bedst til en første AI-agent?
Opgaver med klart definerede trin, adgang til gode systemdata og begrænset skade hvis noget går galt, f.eks. forberedelse af sager, indsamling af information forud for beslutninger eller rutineopdateringer i systemer. Undgå at begynde med processer hvor en enkelt fejl er dyr eller uoprettelig.