De skjulte omkostninger ved AI i stor skala

Den 1. juni 2026, GitHub afskaffede permanent flatrate-“premium requests” for Copilot og erstattede dem med forbrugsbaserede AI-kreditter. Da de første fakturaer under den nye model ankom en måned senere, så nogle agentbaserede brugere regninger, de ikke var forberedte på: En udvikler rapporterede månedlige omkostninger sprang fra $29 til $750 for de tungeste agentbaserede arbejdsgange.

Det var et tydeligt eksempel på en bredere ændring på AI‑værktøjsmarkedet i løbet af 2026 – og en, der kan vente på organisationer, der stadig betaler en flatrate i dag.

Organisationer tæller de timer, de sparer. Mange af dem tæller ikke, hvad en flatrate holder usynligt: forbrug af kontekst og genforsøg efter fejl. Andre omkostninger vises aldrig på leverandørens faktura overhovedet, herunder den tid, der bruges på at gennemgå output og vedligeholde prompts. Når faktureringen skifter til faktisk forbrug, risikerer organisationer uden omkostningsdisciplin en regning, der overrasker dem på samme måde, som Copilots nye model overraskede nogle brugere.

Den kontekst, ingen prissatte

AI har åbenbart brug for kontekst; det er ikke til tvivl. Spørgsmålet er, om den kontekst, der sendes, er relevant, eller blot bekvemt tilgængelig. At sende et helt dokument er den hurtigste måde at give en model information på. Det er ikke automatisk den billigste eller den bedste måde.

I maj 2026 offentliggjorde Stanford’s Digital Economy Lab en analyse af agentbaserede kodningsopgaver på tværs af otte frontier-modeller og fandt, at disse opgaver forbruger op til tusind gange flere tokens end en simpel kode-chat, hvor den primære drivkraft ikke er modellens output, men den input-kontekst, den gensender igen og igen. Agenten læser sin komplette historik igen ved hvert efterfølgende trin. Den samme opgave, kørt flere gange, varierede i token-forbrug op til tredive-fold.

Nøjagtighed skalerer heller ikke lineært med kontekstvolumen: den topper ofte ved en moderat mængde og tilføjer derefter kun omkostninger uden at tilføre værdi.

Token‑blindhed handler altså ikke om, at AI ikke har brug for kontekst. Det handler om, at uden måling stiller ingen spørgsmålet om, hvorvidt al den kontekst egentlig er nødvendig. Under en flatrate er spørgsmålet let at overse. Under forbrugsbaseret fakturering bliver det en del af omkostningerne.

Når du betaler for fejl to gange

Agentbaserede arbejdsgange medfører en anden omkostning, der næsten aldrig fremgår af ROI‑beregninger. Forestil dig en forenklet kæde på ti trin, hvor hvert trin alene har 95 % chance for at køre korrekt. Det lyder pålidelig nok, men når de sættes sammen, har den kæde kun omkring 60 % chance for at komme igennem hele kørslen uden en eneste fejl.

I en arbejdsgang, der sender den akkumulerede kontekst igen ved hvert kald, koster hver fejl og den efterfølgende genforsøg ikke kun det gentagne trin: du betaler også igen for alt, der blev sendt før.

Det er en almindelig smerte, som næsten alle oplever, når de bygger deres første agentbaserede pipeline. Jeg gik selv igennem den. Tidligt, med kun et par agenter, betød det ikke så meget. Men efterhånden som pipelinen voksede, blev hver mislykket kørsel dyrere, og det var det, der fik mig til at begynde at spørge, hvilken kontekst hver agent havde brug for, og hvordan man cachede den, i stedet for blot om kørslen gik igennem.

Den samme analyse beregner, at en ti‑trins agent med 95 % pålidelighed pr. trin forbrænder cirka 40 % flere tokens på genforsøg end et fuldstændigt pålideligt system. Dette er en omkostning, du vil se på fakturaen, men sandsynligvis ikke vil finde i nogen ROI‑regneark.

Tilsyn er ikke en fejl. Det hører til i budgettet

Dette punkt skal formuleres præcist, fordi det er let at tage fejl af. Gennemgang af AI‑output er ikke en systemfejl; det er en legitim, forventet del af arbejdet med AI, på samme måde som kodegennemgang er en legitim del af arbejdet med udviklere. Problemet er ikke, at output bliver gennemgået. Problemet er, at dette arbejde næsten aldrig indregnes i beregningen af, hvor meget AI faktisk har sparet.

Glean’s Work AI Institute undersøgte 6.000 medarbejdere og fandt, at automatisering sparer dem omkring 11 timer om ugen, men næsten seks og en halv af de timer går til vedligeholdelsesopgaver: at give AI‑systemer kontekst, kontrollere deres arbejde og rydde op i fejl. Den netto‑besparelse er derfor tættere på fire og en halv time – mindre end halvdelen af hovedtallet. AI sparer stadig tid, blot ikke så meget som det første tal antyder.

Prompts kræver vedligeholdelse, ikke kun en forfatter

Prompts opfører sig i dag mere som produktionskode: en modelopdatering, en ændring i kontekst eller en tilsyneladende mindre redigering kan ændre deres ydeevne. Uden versionering og test kan disse ændringer stille og roligt introducere problemer. De regressions‑tests, der er standardpraksis for kode, springes stadig ofte over, når det gælder verifikation af prompts. En ændring, der ser ud som en mindre redigering af en enkelt sætning, kan nå produktion og reducere nøjagtigheden uden at nogen bemærker det, indtil problemet er ophobet til noget synligt.

Opbygning af et korrekt evalueringsrammeværk – inklusive et testsæt og automatiserede regressions‑tests for hver ændring – er ekstra arbejde, der næsten aldrig fremgår af beregningen “AI sparer tid”.

Billigere tokens, højere regninger

GitHub Copilot var ingen undtagelse. En undersøgelse citeret af CFO Dive fandt, at næsten syv ud af ti USA-virksomheder rapporterede mindst delvise AI-budgetoverskridelser i det forløbne år, for det meste før en fuld overgang til forbrugsbaseret fakturering, ikke efter den.

Bain & Company tilføjer i sin juni-analyse af tokenøkonomi et paradoks, der bedst indfanger hele situationen: prisen pr. token faldt med halvdelen i løbet af året, mens forbruget i samme periode steg 4,5 gange.

Modellen blev billigere, men regningen forbliver stædigt høj. Virksomheder skiftede til nyere modeller, gav agenter mere komplekse opgaver og fandt flere arbejdsgange til dem. En billigere token betød ikke lavere forbrug; det betød, at der var flere grunde til at forbruge en.

Sådan forbereder du dig, inden regningen ankommer

Rammen, der følger af dette, handler ikke om at bruge mindre AI. Den handler om at kende AI-omkostningerne, før du beslutter dig for at skalere den yderligere.

1. Få først overblik

Indtil du har forbruget opdelt efter team, arbejdsgang, applikation og færdiggjort opgave, er hver udvidelse er et blindt væddemål. Den synlighed er heller ikke gratis: for agentbaserede arbejdsgange især kræver sporing af hvert trin, logning af hvad der skete og hvorfor, samt overvågning af løbende løkker sin egen ingeniørtid og værktøjer. Budgetér for det som en del af omkostningerne ved at drive AI, ikke som en eftertanke ovenpå.

2. Genberegn ROI på nettobasis

Træk den tid, der bruges på gennemgang, rettelser og promptvedligeholdelse fra de rapporterede sparetimer. Hvis tidsbesparelse er formålet med brugsscenariet, og det nettoresultat er negativt eller ikke kan verificeres, er det ikke klar til at blive skaleret. Hvor den tilsigtede fordel i stedet er kvalitet, kapacitet, risikoreduktion eller indtægt, mål så dette resultat direkte.

3. Anvend omkostningsdisciplin, men ikke ensartet

En hård udgiftsgrænse giver mening, hvor fejl er billige: interne værktøjer, eksperimentelle agenter, udviklingsmiljøer. For kritisk, kundeorienteret funktionalitet – for eksempel en kundeserviceassistent – er en hård grænse ikke holdbar, fordi den skaber risiko for nedbrud. Der har du brug for lagdelte fallback‑løsninger til en billigere model og tidlige advarsler, ikke en nul‑afbrydelse.

4. Behandl prompts og evalueringer som ingeniørmæssige aktiver

Versionér dem, test dem og gennemgå ændringer før implementering, på samme måde som du ville håndtere produktionskode.

Gå ind i fornyelser med dine egne data

Leverandørpriser er svære at vurdere uden dine egne forbrugsdata. Før en fornyelse eller modelændring, beregn hvad dine eksisterende arbejdsgange vil koste under de foreslåede vilkår. Målet er ikke kun at forhandle en lavere pris. Det er at vide, hvordan den pris vil opføre sig på dit faktiske forbrugsniveau, i stedet for at opdage det fra fakturaen.

Tre ting du kan gøre i denne uge: tjek om du kan opdele AI-forbruget efter team og arbejdsgang; vælg ét brugsscenarie og sæt den tid, der bruges på gennemgang, ved siden af de rapporterede sparetimer; og find ud af, hvor en hård udgiftsgrænse kan skabe et nedbrud i stedet for at kontrollere en omkostning.

AI-omkostninger kan styres. Bare ikke når du først finder ud af, hvad de er, fra regningen.