En bedrift kan ende opp med å betale for KI-bruk den aldri har bestilt. Hvis kriminelle får tak i tilgangen et program bruker for å koble seg til en KI-tjeneste, kan de kjøre sine egne oppgaver på bedriftens regning. En uvanlig høy faktura kan være det første tegnet på at noe er galt.
Dette handler både om sikkerhet og om å holde tjenestene i gang. Norske ledergrupper bør vite hvilke løsninger som kan påføre bedriften kostnader, hvem som får varsel om uvanlig bruk, og hvem som kan stenge tilgangen uten å vente til neste arbeidsdag.
Dette fant sikkerhetsforskerne
I en rapport publisert 2. november 2026 beskriver Googles sikkerhetsselskap Mandiant flere saker der angripere tok over virksomheters tilgang til store språkmodeller. Mandiant opplyser at urettmessig bruk i enkelte tilfeller førte til kostnader på over 100 000 amerikanske dollar på ett døgn. Hos noen virksomheter nådde de samlede kostnadene én million dollar før tilgangen ble stengt.
Dette er Mandiants observasjoner fra sakene selskapet selv har undersøkt. Rapporten viser ikke hvor vanlige slike tap er, hva kundene til slutt faktisk betalte, eller hvor sannsynlig det er at en bestemt norsk bedrift blir rammet. Sakene gjelder flere leverandører og regioner, og er ikke en representativ undersøkelse av norske virksomheter. De høye beløpene er en grunn til å undersøke egen risiko, ikke en prognose for en vanlig konto.
Mandiant kaller metoden «LLMjacking». I sakene selskapet undersøkte, var stjålne eller eksponerte skykontoer og tilgangsnøkler en vanlig vei inn. Angriperne kunne bruke tilgangen til KI-tjenester eller opprette nye tilganger. En stjålet nøkkel kan derfor gi både uventede kostnader og grunn til å undersøke om flere deler av kontoen er rammet.
Risikoen er særlig relevant for virksomheter som bruker KI gjennom et programmeringsgrensesnitt, ofte kalt et API. En API-nøkkel er en hemmelig tilgangskode som lar programvare sende forespørsler til tjenesten. Bedrifter som bare bruker et vanlig abonnement på en samtalerobot, bør også sikre kontoene sine, men kan ikke gå ut fra at fakturering og sikkerhetsinnstillinger fungerer på samme måte i alle produkter.
Et budsjettvarsel er ikke nødvendigvis en grense
Dette skillet er lett å overse: Et varsel forteller at forbruket har passert en grense. Det stanser ikke nødvendigvis tjenesten.
Google Cloud skriver i sin dokumentasjon at et budsjett som bare sender varsler, ikke automatisk setter tak på forbruket. Microsofts veiledning for Azure-budsjetter sier tilsvarende at budsjettvarsler ikke i seg selv stanser bruken. Begge beskriver andre tiltak og muligheter for automatisering, avhengig av tjenesten og oppsettet.
OpenAIs API-dokumentasjon skiller mellom et varsel og en valgfri, håndhevet månedsgrense. Når en slik grense trer i kraft, blir forespørsler som omfattes av den, avvist. Håndhevingen skjer ikke umiddelbart, så registrerte kostnader kan bli noe høyere enn grensen. Innstillinger, fakturering og avtalevilkår varierer. Undersøk derfor den konkrete tjenesten og kontoen bedriften bruker.
En automatisk stopp har også en kostnad: En tjeneste kundene er avhengige av, kan slutte å virke. Den laveste grensen er derfor ikke alltid den riktige. Ledelsen bør avgjøre hvilke tjenester som trenger en stoppgrense, hvem som kan endre den, hvor raskt varsler skal følges opp, og hvordan kundene skal få hjelp hvis tjenesten stopper.
Avklar hva som skjer før regningen kommer
Tenk deg en norsk bedrift som bruker et KI-API til å lage utkast til kundesvar. Eksemplet er oppdiktet. Bedriften forventer normalt å bruke 15 000 kroner i måneden. Ledelsen setter et varsel ved 20 000 kroner og en håndhevet stoppgrense på 30 000 kroner, dersom leverandøren og kontoen støtter det. Beløpene illustrerer valget og er verken anbefalte grenser eller tall fra Mandiants saker.
Varslet fra leverandøren går til en felles innboks hos økonomiavdelingen. Fredag kveld blir en tilgangsnøkkel stjålet, og bruken øker raskt. Hvis ingen leser innboksen før mandag, fører ikke varslet til handling. Når stoppgrensen nås, kan utkasttjenesten slutte å virke. Sluttbeløpet kan også avvike på grunn av forsinkelser i rapportering og håndheving.
En bedre løsning avtales på forhånd. Tjenesteansvarlig og økonomiavdelingen bør avklare hvem som mottar varslet, hvem som kontakter den tekniske leverandøren, hvem som kan stenge den berørte tilgangen, og hvordan kundeservice arbeider mens tilgangen gjenopprettes. Test varslingsveien på en trygg og avtalt måte. Ikke send en ekte hemmelig nøkkel på e-post for å teste den.
Et varsel ved 20 000 kroner garanterer ikke at tapet stopper der. En stoppgrense på 30 000 kroner er på sin side et bevisst valg som kan påvirke tilgjengeligheten, ikke et bevis på at kontoen er sikret. Undersøk hva grensen faktisk dekker, og hvor raskt den virker etter avtalen dere har.
Begrens hva én stjålet nøkkel gir tilgang til
Be den teknisk ansvarlige eller leverandøren kartlegge KI-tjenestene i drift og nøklene eller skykontoene som kan bruke dem. Registrer hvem som har ansvaret, og hvilken tjeneste hver tilgang brukes til. Skill utvikling fra produksjon der det er praktisk mulig, fjern tilganger som ikke lenger trengs, og gi hvert system bare rettighetene det trenger.
Ikke legg aktive API-nøkler i programmer som kjører i nettleseren, åpne kodelagre eller vanlige dokumenter. Bruk leverandørens anbefalte løsning for oppbevaring av hemmelige nøkler, og begrens hvem og hva som har tilgang. En nøkkel som har ligget åpent i kode, bør regnes som kompromittert selv om den senere er fjernet fra teksten.
Forbered både utskifting og stenging. OpenAIs veiledning for API-nøkler beskriver hvordan man oppretter en ny nøkkel, oppdaterer tjenesten, kontrollerer at den virker og trekker tilbake den gamle. Ved et pågående angrep kan hendelsesteamet måtte stenge tilgangen straks, før en erstatning er klar. Rekkefølgen avhenger av situasjonen og konsekvensene av å la tilgangen være aktiv.
Ved mistanke om misbruk bør virksomheten sikre relevante logger, kontakte leverandøren og følge beredskapsplanen. Undersøk om den kompromitterte kontoen også ga tilgang til data, andre nøkler eller flere tjenester. Det at én nøkkel er byttet, viser ikke at angriperens opprinnelige inngang er stengt. Kontakt kunder eller myndigheter når hendelsen og pliktene som gjelder, krever det. Et kostnadsvarsel alene viser ikke at det har skjedd et meldepliktig personvernbrudd.
Gi økonomi og IT et felles ansvar
Ledelsen bør sørge for at økonomiavdelingen og den teknisk ansvarlige har en felles oversikt over de viktigste kontoene: forventet forbruk, hvem som kan godkjenne økning, hvilke varsler som er aktive og hvem som kan handle utenfor arbeidstid. Spør leverandøren om kostnadene kan fortsette etter et varsel, hvilke forsinkelser eller begrensninger som gjelder, og hvordan hver tjeneste kan stenges og settes i drift igjen.
Et lite AS kan starte med kontoen bak én viktig kundetjeneste. En virksomhet med flere skyleverandører bør ikke gå ut fra at ett budsjett dekker alle abonnementer, modeller og leverandører. Ta med kostnaden ved å undersøke varsler og holde en reserveløsning klar når dere vurderer lønnsomheten. Artikkelen om forbruk i KI-tjenester tar opp et annet problem: at vanlig bruk tømmer en avtalt kvote. Både vanlig etterspørsel og misbruk kan avbryte arbeidet.
Styret bør spørre om ledelsen kan vise at noen har ansvar for de viktigste KI-kontoene og kostnadene, at alvorlige avvik når frem til noen som kan handle, og at virksomheten har en løsning for kritiske tjenester. Styret skal ikke administrere enkeltnøkler eller godkjenne hver beløpsgrense.
Still ett spørsmål på neste leverandørmøte: Hvis denne KI-kontoen begynner å påføre oss uventede kostnader i kveld, hvem får beskjed, hvem kan stanse den, og hvordan hjelper vi kundene i mellomtiden?
Kildene er kontrollert 4. november 2026. Den norske bedriften og kronebeløpene er oppdiktede eksempler. Tallene fra Mandiant er knyttet til selskapets egne undersøkelser, ikke et norsk gjennomsnitt. Produktinnstillinger og avtaler kan endres. Illustrasjonen er laget med KI.