AI-prisændringer truer din business case

De store AI-leverandører justerer prisstrukturen med kort varsel og uden den forudsigelighed, virksomheder er vant til fra andre it-indkøb. Nogle gange betyder det lavere priser per token, når konkurrencen strammer til. Andre gange betyder det nye tiers, hvor den funktionalitet, I byggede jeres løsning på, flyttes op i et dyrere niveau. Jeg har set eksempler, hvor en virksomheds forventede driftsomkostning ændrede sig markant inden for et kvartal, uden at der var sket noget som helst i deres eget setup.

Det er ikke ondskabsfuldt fra leverandørernes side. Det er en konsekvens af, at markedet for store sprogmodeller og AI-infrastruktur stadig er ungt og i hastig bevægelse. Men konsekvensen for jer som kunde er den samme: en ROI-beregning, der var retvisende ved projektstart, kan være misvisende et halvt år senere.

De fleste business cases regner ROI ud fra en fast antagelse om driftsomkostning per måned eller per transaktion. Når den antagelse ændrer sig, ændrer hele regnestykket sig med. Et projekt, der var beregnet til at tjene sig hjem på tolv måneder, kan pludselig kræve atten. Et projekt med tynd margin fra start kan gå fra positivt til negativt ROI, uden at nogen i organisationen har truffet en aktiv beslutning om det.

Det farlige er, at den slags forskydninger sjældent bliver opdaget i tide. Business casen blev godkendt, projektet blev sat i drift, og så bliver den økonomiske forudsætning aldrig genbesøgt. Jeg anbefaler altid, at driftsomkostninger til AI behandles som en variabel, der skal revurderes løbende, ikke som en fast linje i budgettet man sætter og glemmer.

Det gælder især for virksomheder, der har bygget løsninger med tung afhængighed af én bestemt model eller ét bestemt API. Jo mere hardcodet jeres arkitektur er til en specifik leverandørs prisstruktur, jo mere sårbar er jeres business case over for netop den leverandørs beslutninger.

Den mest effektive fremtidssikring er at bygge ROI-beregningen med en buffer fra start. Jeg anbefaler, at man regner med et prisscenarie, der er 20-30 procent dyrere end den aktuelle sats, og ser om projektet stadig giver mening under det scenarie. Hvis business casen kun holder ved den billigste tænkelige pris, er den for skrøbelig til at stå alene.

Det næste skridt er at gøre løsningen modeluafhængig, hvor det er praktisk muligt. En arkitektur, der kan skifte mellem flere modeller eller leverandører uden større ombygning, giver jer reel forhandlingskraft, når priserne ændrer sig. Det er ikke altid muligt at holde en løsning fuldstændig leverandøragnostisk, men selv delvis fleksibilitet gør en stor forskel, når markedet bevæger sig. Det er præcis den slags routing-lag, jeg endte med at bygge hos Agent Enterprise, efter regningen overraskede os.

Endelig bør business casen indeholde et fast revisionspunkt, for eksempel hvert kvartal, hvor de faktiske driftsomkostninger holdes op mod den oprindelige beregning. Det lyder banalt, men det er præcis den øvelse, de fleste organisationer springer over, fordi AI-projektet betragtes som færdigt, når det går i drift.

Når I vælger leverandør, er prisen i dag mindre interessant end prisens forudsigelighed over tid. Se på, hvor ofte leverandøren historisk har ændret sin prisstruktur, og hvor gennemsigtige de har været om varsling. Nogle leverandører giver kunder god tid til at omstille sig, andre implementerer ændringer med kort varsel.

Jeg anbefaler også at kigge på kontraktvilkårene, ikke kun listeprisen. Nogle leverandører tilbyder prislåsning for en periode mod en forpligtelse på volumen eller varighed. Det kan være den rigtige løsning for en virksomhed med et stabilt, forudsigeligt forbrug, men det kan også binde jer til en pris, der senere viser sig ugunstig, hvis markedet falder.

Den mest holdbare tilgang er sjældent at vælge den billigste leverandør her og nu. Det er at vælge den arkitektur og de leverandørforhold, der gør jer i stand til at reagere, når markedet ændrer sig, for det gør det med sikkerhed igen.