Regningen etter byggingen: hva et AI-system egentlig koster å drifte

De fleste AI-budsjetter stopper ved lansering. Tilbudet dekker kartlegging, bygging, integrasjon og en dato for produksjonssetting. Så går systemet i to år, og ingen har skrevet ned hva de to årene koster. Her er det som faktisk havner på fakturaen.

Modellregningen er den delen du kan regne ut

Modellkostnader måles per token — omtrent per ord inn og per ord ut. Det gjør dem forutsigbare hvis du gjør regnestykket én gang.

Ta en intern kundestøtteassistent som håndterer 8 000 samtaler i måneden, med seks vekslinger hver. Det er 48 000 kall til modellen. Hvert kall bærer med seg instruksjonene dine, de hentede dokumentene og samtalen så langt — si 5 000 tokens inn — og returnerer rundt 400 tokens ut. Du kjøper 240 millioner input-tokens og 19 millioner output-tokens i måneden. Med prising på mellomklassemodeller lander det nær 1 000 dollar i måneden, og prompt-caching på de gjentatte instruksjonene kan redusere det merkbart.

To ting overrasker folk. For det første dominerer input: du betaler for alt du sender, hver veksling, og lang kontekst er den viktigste kostnadsdriveren du selv styrer. For det andre legger nye forsøk, evalueringskjøringer og intern testing 15–30 % oppå produksjonstrafikken. Budsjetter med bruttotallet, ikke det pene.

Modellprisene per token har falt jevnt og trutt. Totalforbruket stiger som regel likevel, fordi bruken vokser og nyere modeller tas i bruk til tyngre oppgaver. Planlegg for volum, ikke for pris.

Regningene ingen tok med i tilbudet

Modellkostnadene er sjelden den største posten. Resten av driftskostnaden er alminnelig operativt arbeid som AI-systemer tilfeldigvis trenger mer av:

• Menneskelig kontroll. Noen leser et utvalg av faktiske svar hver uke og vurderer om kvaliteten holder. For et kundevendt system, regn med noen timer i uken, permanent.
• Infrastruktur rundt modellen. Søkeindekser, vektorlagre, logging og pipelinen som holder dokumentene dine oppdatert. Beskjedent hver for seg, konstant til sammen.
• Endringsarbeid. Nye produkter, nye retningslinjer, nye grensetilfeller systemet håndterer dårlig. Vent en liten, jevn strøm av justeringer snarere enn sporadiske store lanseringer.
• Endringer hos leverandøren. Modeller utfases etter offentliggjorte tidsplaner. Å migrere til en etterfølger betyr å teste på nytt alt den gamle gjorde bra, typisk én gang i året.
• Etterlevelse og dokumentasjon. Lagringstid, tilgangsstyring og sporet som viser hva systemet fortalte en kunde i mars.

Forfallet er posten som overrasker folk

Programvare feiler høylytt. AI-systemer forfaller stille, og de er like selvsikre hele veien ned.

Virksomheten din endrer seg først. Priser endres, et produkt utgår, en retningslinje skrives om. Systemet svarer videre ut fra den versjonen det fikk, flytende og feil, helt til noen legger merke til det.

Brukerne dine endrer seg deretter. Når folk har lært hva systemet håndterer, presser de over i tilgrensende områder det aldri var laget for. Trafikk som så ut som svar på vanlige spørsmål blir til tolkning av kontrakter, og treffsikkerheten du målte ved lansering beskriver ikke lenger det som faktisk skjer.

Innholdet ditt endrer seg også. Gjenfinning som fungerte over 400 dokumenter blir vagere over 4 000, fordi flere nesten-treff trenger det riktige svaret ut av resultatlisten.

Ingenting av dette utløser et varsel. Det dukker opp måneder senere som flere eskaleringer, fallende bruk, eller en klage fra en kunde som handlet på noe systemet sa. Da koster rettingen mer enn overvåkingen ville gjort.

Forsvaret er lite glamorøst og billig: ta stikkprøver av 50 til 100 faktiske interaksjoner i måneden, vurder dem mot hva en god medarbeider ville sagt, og følg poengsummen over tid. Én person, en halv dag, hver måned. Den ene vanen fanger opp nesten alle feilmåtene over mens de fortsatt er små.

Et budsjett som overlever møtet med virkeligheten

Planlegg årlig driftskostnad til 30–50 % av byggekostnaden de første to årene. Under 20 % blir systemet forsømt, og kvalitetskurven vil vise det. Over 60 % er enten byggingen etterlatt med for mye ugjort, eller så er bruksområdet reelt mer omskiftelig enn det så ut til.

Del tallet i tre bøtter: bruk (modellkostnader og infrastruktur, som skalerer med volum), forvaltning (kontroll, overvåking, dokumentasjon — omtrent fast) og endring (tilpasning til virksomheten din og leverandørens veikart). Bøttene oppfører seg forskjellig, så ett samlet tall vil villede deg første gang volumet dobler seg.

Utpek så en eier. Et AI-system uten en navngitt eier og en fast budsjettpost blir ikke vedlikeholdt; det blir tålt til det stille forlates. Det er den virkelige kostnaden ved å hoppe over denne øvelsen — ikke å bruke for mye, men å betale for en bygging to ganger.

Regn ut driftskostnaden før byggingen, ikke etter. Tallet endrer ofte hva du bestemmer deg for å bygge, og det er nettopp det det er til for. Det er den første beregningen vi gjør med en kunde, og av og til er det grunnen til at vi anbefaler et mindre system enn det de kom for å be om.