Hvad koster AI i drift? Budget der holder i 2026

Hvorfor AI ofte bliver dyrt efter lancering

Der er et klassisk mønster, jeg ser igen og igen hos danske virksomheder. Man bruger tid og energi på at få en AI løsning til at virke, man ser resultaterne i en testfase, og så trykker man på den store grønne knap. Projektet er live. Alle er glade.

Og så, tre måneder senere, er der pludselig nogen der kigger på fakturaen og spørger: "Hvad fanden er det her?"

Det er ikke fordi løsningen er dårlig. Det er fordi ingen lavede et realistisk AI budget, inden man skalerede op. AI drift er ikke som at købe et stykke software én gang og så er man færdig. Det er en levende maskine med løbende AI omkostninger, og dem kan man godt begynde at forstå fra dag ét, hvis man ved hvad man kigger efter.

Den her artikel er til dig, der enten er ved at planlægge et AI projekt, eller allerede har ét i drift og gerne vil have styr på hvad det egentlig koster over tid. Vi ser på de synlige poster, de skjulte poster og giver dig en enkel model til at lave en total cost of ownership for AI, der rent faktisk holder.

Når en proof of concept bliver til daglig drift

En proof of concept, altså en testversion af en AI løsning, er normalt billig at lave. Man sender måske hundrede forespørgsler om dagen, data er ryddelig, og der er én person der holder øje med det hele. Det er overkommeligt og sjovt.

Men når samme løsning skal køre for rigtige medarbejdere, rigtige kunder og rigtige data, ændrer forudsætningerne sig fundamentalt. Pludselig er der tusindvis af forespørgsler, dokumenter i mange formater, fejlbeskeder der skal håndteres, og ingen der har tid til at sidde og kigge på logs.

LLM omkostninger, altså udgifterne til de store sprogmodeller som GPT eller Claude, skalerer direkte med brugen. Og det gør driftsomkostningerne ved AI også. En løsning der koster 500 kroner om måneden i test, kan sagtens koste 5.000 til 15.000 kroner om måneden i reel drift, afhængigt af volume og kompleksitet.

Det er ikke en skrækhistorie. Det er bare virkelighed. Og det er virkelighed man kan planlægge for, hvis man kender strukturen.

Når flere teams begynder at bruge samme løsning

Noget af det der typisk overrasker mest er, hvad der sker når en AI løsning begynder at sprede sig internt i virksomheden. Det starter måske med salgsafdelingen, der bruger den til at besvare kundehenvendelser. Så opdager marketingafdelingen den. Så HR. Og pludselig har du en løsning der er designet til ét formål, men bruges til fem.

Det er egentlig et tegn på succes. Men det medfører en række driftsomkostninger, der ikke var med i det oprindelige budget. Token forbrug stiger. Hosting af AI infrastrukturen skal skaleres. Der opstår behov for adgangsstyring, fordi ikke alle medarbejdere må se de samme data. Og der skal laves et ordentligt setup til logning af AI kald, så man kan se hvem der bruger hvad og hvornår.

Hvis man ikke har taget højde for dette fra starten, ender man med at betale for genopbygning af noget man allerede har bygget én gang. Det er frustrerende og dyrt. Løsningen er ikke at bremse adoptionen. Løsningen er at tænke skalering ind fra begyndelsen, også selv om man starter småt.

De synlige omkostninger, modelkald og infrastruktur

Lad os starte med de poster, der faktisk står på fakturaen. De er synlige, men det betyder ikke de er lette at forudsige. AI drift bygger på en prissætning der er fundamentalt anderledes end traditionel software, og den forskel er vigtig at forstå, inden man laver sit AI budget.

Traditionel software koster typisk en fast månedlig pris, uanset om du bruger det lidt eller meget. AI løsninger baseret på store sprogmodeller er derimod forbrugsbaseret. Bruger du løsningen meget, betaler du meget. Bruger du den lidt, betaler du lidt. Det giver fleksibilitet, men det giver også usikkerhed, og den usikkerhed skal budgetteres for.

Tokenforbrug og pris pr. forespørgsel

Når man taler om pris på ChatGPT API eller andre store sprogmodeller som Claude og Gemini, handler det om tokens. Et token er cirka fire tegn eller tre fjerdedele af et ord. Både din forespørgsel til modellen og dens svar tæller med i det samlede tokenforbrug.

Prisen pr. million tokens varierer meget afhængigt af hvilken model du bruger. En simpel og billig model koster måske én til to dollar pr. million tokens, mens de mest avancerede modeller kan koste 15 til 75 dollar pr. million tokens. Det lyder måske ikke af meget, men det løber hurtigt op når en AI assistent håndterer hundredvis eller tusindvis af daglige forespørgsler.

En konkret regnestykke: Hvis du har en AI assistent der håndterer 500 kundehenvendelser om dagen, og hver forespørgsel bruger 2.000 tokens i input og 500 tokens i output, er du oppe på lidt over 37 millioner tokens om måneden. Med en gennemsnitspris på 10 dollar pr. million tokens, giver det en månedlig LLM udgift på ca. 370 dollar, altså ca. 2.500 kroner. Og det er kun modellen. Resten af infrastrukturen kommer oveni.

Det er også her, valg af model og optimering af dine prompts bliver en direkte økonomi. Kortere, præcise prompts er ikke bare god praksis. De er penge i lommen.

Hosting, database og netværk

Ud over selve LLM omkostningerne er der en hel infrastruktur der skal køre. Hosting af AI løsningen kræver enten en cloud platform som AWS, Google Cloud eller Azure, eller en selvhosted løsning på eksempelvis en Hetzner VPS.

Self hosting AI kan være billigere i ren serverudgift, men kræver mere teknisk vedligehold. Cloud hosting er nemmere at skalere, men priserne kan stige hurtigt ved høj belastning. Ingen af løsningerne er gratis, og cloud omkostninger skal estimeres løbende, ikke bare ved opstart.

Hvis din løsning bruger RAG, altså Retrieval-Augmented Generation, hvor AI en henter relevant information fra en vidensbase, kommer vector database omkostning oveni. En vector database som Pinecone, Weaviate eller Supabase med pgvector har sine egne driftsomkostninger, både i opbevaring og i forespørgsler. RAG drift er ikke gratis, og det bør stå som en separat post i dit budget.

Netværkstrafik er en tredje post, der tit glemmes. Data der sendes frem og tilbage mellem din applikation, sprogmodellen og databasen koster penge i de fleste cloud setups. Det er ikke en stor post isoleret set, men det er en post.

Skalering når usage pludselig stiger

Et af de steder mange virksomheder bliver overraskede er, hvad der sker med cloud omkostningerne når brugen af en løsning pludselig topper. Det kan være en kampagne der sender mange forespørgsler på én gang, en ny medarbejdergruppe der begynder at bruge systemet, eller bare organisk vækst over tid.

Uden en klar skaleringsplan kan du ende med enten at løsningen fejler under pres, fordi den ikke er dimensioneret til det, eller at du betaler for overkapacitet det meste af måneden. Begge dele er spild.

Den rigtige tilgang er at designe løsningen med kendte grænser og målte belastninger fra dag ét. Sæt et loft for GPU omkostninger og CPU omkostninger via automatiske alarmer i dit cloud setup. Definér hvad "normal" belastning er, og hvad der udløser en skaleringsregel. Så undgår du overraskelser på fakturaen, og du har data til at justere budgettet løbende.

De skjulte omkostninger, tid, kvalitet og kontrol

De poster vi lige har gennemgået er synlige. De fremgår direkte af fakturaer fra dine leverandører. Men de skjulte omkostninger ved AI drift er dem, der typisk fælder projekter der ellers ser fornuftige ud på papiret.

Disse poster dukker ikke op på en faktura. De dukker op som brugt tid, faldende kvalitet og menneskelig frustration. Og de er mindst ligeså reelle som token priser og serverregninger. Faktisk er det ofte dem der trækker den samlede total cost of ownership op, uden at nogen lægger mærke til det, fordi ingen har budgetteret for dem.

Hvad vi taler om her er kort sagt:

• Overvågning og fejlhåndtering i løbende drift
• Vedligehold af de prompts løsningen bygger på
• Menneskelig godkendelse der sluger mere tid end forventet
• Dataoprensning og rettigheder til de dokumenter løsningen bruger

Lad os gå dem igennem én efter én.

Overvågning, alarmer og fejlretning

En AI løsning der kører i produktion, kræver monitorering. Det er ikke valgfrit. Sprogmodeller kan svare forkert. Integrationer kan gå ned. Dataflows kan fejle lydløst, uden at nogen opdager det, fordi der ikke kom en åbenlys fejlmeddelelse.

Monitorering af AI handler om at have øjne på systemet, også når ingen sidder og kigger aktivt. Det kræver opsætning af alarmer, dashboards og logning af AI kald, så du kan se hvornår noget går galt, og helst inden dine brugere eller kunder opdager det.

Logning er i sig selv en omkostning, dels i opbevaring, dels i den tid det tager at analysere logs og reagere på hændelser. Incident håndtering, altså at identificere, afhjælpe og lære af fejl, kræver kompetence og tid. Og det er en fast driftspost, ikke en engangsudgift.

Driftsikkerhed for AI kræver altså en plan for hvem der reagerer, hvornår og hvordan. Har du ikke den plan, er det din tid eller din freelancers tid der bruges på brandslukning, og det er dyrt.

Prompt vedligehold når virkeligheden ændrer sig

Prompts er de instruktioner der styrer hvordan din AI løsning opfører sig. De er ikke sat en gang for alle. De skal vedligeholdes løbende, og det er her mange undervurderer den reelle indsats.

Virksomheden ændrer sin tone of voice. Produktsortimentet opdateres. Lovgivningen ændrer sig. En ny model fra OpenAI eller Anthropic fortolker instruktionerne anderledes end den gamle. Alt dette betyder at vedligehold af prompts er en løbende opgave, ikke noget man laver én gang ved opstart.

Og model opdateringer er en særlig faldgrube. Når leverandøren opdaterer sin model, kan det ændre adfærden i din løsning, selvom du ikke har ændret noget. Kvalitetssikring af AI kræver derfor regelmæssige tests og evalueringer, også i perioder hvor alt tilsyneladende fungerer fint.

Menneskelig godkendelse der tager længere end forventet

Mange AI løsninger er bygget med et menneske i løkken. Det vil sige, at AI en udkaster et svar eller en handling, og en medarbejder godkender eller afviser det, inden det sendes videre. Det er en god og sikker model. Men den koster tid.

I planlægningsfasen estimerer man ofte godkendelsestiden lavt. "Det tager to minutter at tjekke." I virkeligheden tager det ofte længere, fordi medarbejderen skal sætte sig ind i konteksten, forstå hvad AI en har gjort og tage ansvar for outputtet.

Når man skalerer antallet af kald, skalerer godkendelsesopgaven tilsvarende. Og hvis løsningen i praksis kræver menneskelig godkendelse på 80 procent af alle output, er automatiseringsgevinsten markant lavere end forventet. Det er et reelt problem, og det bør kortlægges grundigt, inden man godkender et AI budget.

Dataoprensning og rettigheder til dokumenter

For RAG-baserede løsninger, altså systemer der henter viden fra dokumenter og databaser, er datakvaliteten afgørende. Og data er sjældent klar fra dag ét. Dokumenter har forkert format. Viden er forældet. Rettigheder til at bruge materialet er uklare.

Dataoprensning er en konkret og tidskrævende opgave. Det er ingen der taler om i salgsmøder, men det er en af de poster der sluger flest timer i en rigtig AI implementering. Og den skal gentages, fordi data ikke er statisk.

Sikkerhed og compliance der ikke kan springes over

Når man taler om AI omkostninger, er det fristende at fokusere på det tekniske og glemme de juridiske og sikkerhedsmæssige krav. Det er en fejl der kan blive meget dyr, ikke bare i penge, men i tillid og omdømme.

Sikkerhed i AI løsninger og overholdelse af GDPR er ikke valgfrie tilføjelser. De er forudsætninger for at måtte drive en AI løsning med persondata i Danmark og EU. Og de har en pris, både at etablere og at vedligeholde.

De fleste danske virksomheder er faktisk klar over at GDPR gælder. Udfordringen er at forstå, at en ny AI løsning typisk introducerer nye dataflows, nye leverandører og nye risici, som alle kræver ny vurdering og dokumentation. Det er ikke noget man tager fra hylden.

Adgangsstyring og logning af brugerhandlinger

Et grundlæggende krav til enhver AI løsning der bruges af medarbejdere, er ordentlig adgangsstyring. Ikke alle medarbejdere må se alle data. Ikke alle må bruge alle funktioner. Og det skal håndhæves teknisk, ikke bare via en intern aftale.

Adgangsstyring koster tid at designe og vedligeholde. Medarbejdere skifter roller. Nye ansatte skal onboardes. Og adgange skal fjernes hurtigt når nogen forlader virksomheden.

Logning af brugerhandlinger er tæt forbundet hermed. Du skal kunne dokumentere hvem der har haft adgang til hvad, og hvornår. Det er en GDPR-forpligtelse, men det er også god praksis i forhold til driftsikkerhed for AI og intern kontrol. Logfiler tager plads og skal opbevares struktureret. Det er en løbende post i dit AI budget.

Persondata, sletning og opbevaring

Hvis din AI løsning behandler personoplysninger, hvad enten det er kundedata, medarbejderoplysninger eller noget helt tredje, er du forpligtet til at have styr på opbevaring og sletning. Det er en del af GDPR omkostningerne, og det er hverken teknisk simpelt eller juridisk valgfrit.

Persondata må ikke opbevares længere end nødvendigt. Men i en AI løsning kan data flyde mange steder: til modelleverandøren, til logfiler, til vector databasen, til backups. Alle disse steder skal kortlægges, og der skal være en klar sletningsrutine.

Den tekniske implementering af sletningsrutiner er en fast driftsopgave. Og den juridiske vurdering af opbevaringstider og grundlag kræver enten juridisk rådgivning eller en grundig intern proces. Ingen af delene er gratis.

Leverandører, underdatabehandlere og kontrakter

Når du bruger en ekstern AI leverandør som OpenAI, Anthropic eller Google, er de underdatabehandlere i GDPR forstand, hvis de behandler persondata på dine vegne. Det kræver en databehandleraftale for AI, og den skal gennemgås og opdateres løbende.

Mange leverandører tilbyder standardaftaler, men de passer ikke altid til din specifikke løsning. Og nogle leverandører træner deres modeller på de data du sender dem, medmindre du aktivt fravælger det. Det er et punkt man skal være meget opmærksom på, både af hensyn til fortrolighed og GDPR.

SLA for AI, altså de serviceniveauaftaler du har med dine leverandører, er en anden vigtig post. Hvad sker der, hvis OpenAI har nedetid i to timer på en hverdag, og din AI drevne kundesupport er offline? Har du en beredskabsplan? Hvem betaler for tabt driftstid? Det er spørgsmål der skal besvares, inden løsningen er live. En hurtig oversigt over de vigtigste compliance-poster:

Område	Krav	Hyppighed
Databehandleraftale	Skal indgås med alle leverandører der behandler persondata	Ved opstart og ved ændringer
Adgangsstyring	Rollebaseret adgang og løbende oprydning	Løbende
Sletningsrutiner	Automatisk eller manuel sletning iht. opbevaringsfrister	Løbende
Logning	Dokumentation af brugerhandlinger og AI kald	Løbende og ved revision
SLA gennemgang	Vurdering af leverandørens oppetid og ansvar	Mindst én gang årligt

En enkel måde at lave et realistisk AI budget på

Nu har vi kigget på alle de poster der udgør den samlede AI drift. Nu er det tid til at sætte dem sammen til noget brugbart. Et realistisk AI budget er ikke en præcis forudsigelse. Det er en model der hjælper dig med at træffe gode beslutninger og opdage problemer tidligt.

Den vigtigste regel er: antag aldrig at driften koster det samme som testen. Det er aldrig tilfældet. En god tommelfingerregel er at budgettere med to til tre gange testomkostningerne som udgangspunkt for første kvartal i drift, og derefter justere ud fra faktisk forbrug.

Total cost of ownership for AI skal indeholde alle de poster vi har gennemgået. Ikke bare modellen og serveren, men også tid til vedligehold, compliance, overvågning og kvalitetssikring. Hvis du ikke kan få alle poster til at give positiv forretningscase, bør du overveje om løsningen er klar til fuld drift, eller om den skal redesignes.

Tre scenarier, lav, normal og høj belastning

Den bedste måde at gøre et AI budget robust er at planlægge for tre scenarier. Det giver dig et realistisk spænd at arbejde inden for, og det hjælper dig med at kommunikere til ledelsen hvad der er det forventede og hvad der er worst case.

Lav belastning er det scenarie hvor løsningen bruges under forventet, måske fordi adoption er langsom, eller fordi et bestemt team bruger den til simple forespørgsler. Her er token priser og cloud omkostninger lave, men faste poster som hosting, logning og compliance løber stadig. Det er her mange løsninger har negativt ROI i de første måneder.

Normal belastning er det budgetterede scenarie baseret på din bedste vurdering af daglig brug. Det er dette tal der skal bruges som baseline i din TCO beregning, og det er her du sætter alarmgrænser for hvornår omkostningerne begynder at afvige fra planen.

Høj belastning er det scenarie der opstår ved vækst, kampagner eller uplanlagt intern spredning. Her stiger LLM omkostninger, GPU omkostninger og CPU omkostninger markant, og du skal vide hvad det koster, inden det sker. Sæt et loft og en eskaleringsplan.

Tjekpunkter der afslører om løsningen kan betale sig

Et AI projekt er ikke en investering du vurderer én gang. Det er noget du evaluerer løbende. Sæt konkrete tjekpunkter ved 30, 90 og 180 dage efter lancering, hvor du besvarer tre spørgsmål:

Et: Hvad er den faktiske TCO for AI i perioden, sammenlignet med det budgetterede?

To: Hvad er den målbare gevinst, i sparet tid, flere behandlede forespørgsler, reducerede fejl eller andre KPI er der var defineret fra starten?

Tre: Er der omkostninger der vokser hurtigere end gevinsten, og hvad er årsagen?

Hvis du ikke kan svare på disse spørgsmål fordi du ikke har data, er det et tegn på at monitorering af AI ikke er på plads. Og det er faktisk en større risiko end høje token priser.

Hvad du måler på, så du opdager driftspres tidligt

De tre vigtigste måleparametre i løbende AI drift er forbrug, kvalitet og tid. Forbrug er det letteste at måle: token forbrug, cloud omkostninger og n8n drift omkostninger kan alle logges automatisk og vises i et simpelt dashboard.

Kvalitet er sværere, men vigtigere. Mål andelen af forespørgsler der kræver menneskelig korrektion eller eskalering. Mål brugertilfredshed med output. Og mål om løsningen faktisk bruger de rigtige dokumenter i sit svar, hvis du kører RAG drift. Disse målinger afslører hurtigt om prompt vedligehold er nødvendigt, eller om en model opdatering har ændret adfærden.

Tid er den tredje parameter. Mål svartider. Mål ventetid i godkendelsesflows. Og mål hvor lang tid det tager dine folk at håndtere undtagelser og fejl. Hvis disse tal vokser, vokser dine skjulte omkostninger med dem.

AI drift er forudsigeligt, hvis du kigger de rigtige steder

Den her artikel har taget dig igennem hele strukturen i hvad AI drift egentlig koster, fra de synlige poster som LLM omkostninger, token pris og hosting af AI, til de skjulte poster som prompt vedligehold, menneskelig godkendelse og dataoprensning, og videre til compliance kravene i form af GDPR, adgangsstyring og databehandleraftaler.

Hovedbudskabet er enkelt: AI projekter dør ikke fordi teknologien ikke virker. De dør fordi ingen har lavet et realistisk AI budget, der tager hele total cost of ownership for AI med. Og det kan du gøre nu, inden det bliver dyrt.

Brug de tre scenarier til at sætte dit spænd. Definer dine tjekpunkter. Sæt alarmer på forbrug. Og sørg for at kvalitetssikring af AI er en fast post i kalenderen, ikke noget der kun sker når noget går galt.

Den kunstige intelligens der faktisk skaber værdi over tid er ikke den smarteste model. Det er den løsning der er bygget til at blive driftet, overvåget og forbedret løbende med en plan og et budget, der holder.