OpenAI-tall utløser ny kostnadsrisiko i AI-infrastrukturen

OpenAI skal ha bommet på egne mål for inntekter og brukervekst, ifølge Wall Street Journal, omtalt av CNBC 28. april.

CNBC skriver at rapporten sendte AI-infrastrukturaksjer ned samme dag: Oracle falt mer enn 6 prosent, CoreWeave rundt 7 prosent, og flere chip-aksjer falt om lag 3–5 prosent. Reuters omtalte den samme WSJ-rapporten tidligere på dagen. Dette er ikke et offisielt OpenAI-regnskap, men det er et tydelig markedssignal om at investorer nå tester regnestykket bak AI-kapasiteten.

Fakta: OpenAI har inngått svært store kapasitetsavtaler, blant annet en femårig Oracle-avtale omtalt av CNBC til 300 milliarder dollar. Når selskapet samtidig rapporteres å ligge bak interne vekstmål, flytter spørsmålet seg fra modellkvalitet til betalingsvilje, marginer og hvem som faktisk bærer risikoen i verdikjeden.

For norske CIO-er og CFO-er er konsekvensen enkel: AI-roadmapet må regnes som en portefølje av variable kostnader, ikke som et vanlig SaaS-abonnement. Prispresset kan komme begge veier. Leverandører kan senke modellpriser for å vinne volum, men også stramme inn kvoter, flytte kunder til bruksbasert fakturering eller pakke kapasitet inn i dyrere enterprise-avtaler.

Vurdering: Dette svekker ikke behovet for AI. Det svekker ideen om at dagens kapasitets- og prismodeller er stabile. Norske ledergrupper bør derfor be om tre ting før større AI-forpliktelser: tydelige forbruksgrenser, rett til å flytte arbeidslaster mellom modeller og skyplattformer, og månedlig rapportering på kost per prosess, ikke bare antall tokens eller brukere.

Styrer bør også skille mellom produktivitetscase og infrastrukturcase. Et Copilot- eller kundeservicecase kan være lønnsomt selv om AI-infrastrukturaksjer faller. Men hvis strategien forutsetter én modellleverandør, én neosky eller én hyperscaler over flere år, bør risikoen behandles som leverandørbinding og finansiell eksponering.

Praktisk råd nå: sett en terskel for når AI-prosjekter må gjennom økonomisk arkitekturreview. Den bør utløses av forventet årlig forbruk, datakritikalitet og grad av låsing til proprietære API-er. Det er billigere å bygge exit-planen før produksjonsvolumet kommer.