AI:n piilotetut kustannukset suuressa mittakaavassa

on 1. kesäkuuta 2026, GitHub lopetti pysyvästi tasahintaisten \”premium requests\” -pyyntöjen tarjoamisen Copilotille ja korvasi ne käyttöperusteisilla AI-krediiteillä. Kun ensimmäiset laskut uudessa mallissa saapuivat kuukauden kuluttua, jotkut agenttikäyttäjät näkivät odottamattomia laskuja: Yksi kehittäjä raportoi kuukausikustannusten nousevan $29:sta $750:aan raskaimmissa agenttityönkuluissa.

Se oli yksi näkyvä esimerkki laajemmasta muutoksesta AI-työkalumarkkinoilla vuoden 2026 aikana – ja yksi, joka saattaa odottaa organisaatioita, jotka edelleen maksavat tasahintaa.

Organisaatiot laskevat säästämänsä tunnit. Monet niistä eivät laske sitä, mitä tasahinta pitää piilossa: kontekstin kulutuksen ja uudelleenyrittämiset epäonnistumisen jälkeen. Muita kustannuksia ei lainkaan näy toimittajan laskussa, kuten aika, jonka käyttää tuotoksen tarkastamiseen ja kehotteiden ylläpitoon. Kun laskutus siirtyy todelliseen kulutukseen, organisaatiot ilman kustannuskurinalaisuutta riskivät laskun, joka yllättää heidät samalla tavalla kuin Copilotin uusi malli yllätti jotkut käyttäjät.

Konteksti, jota kukaan ei hinnoittele

AI tarvitsee selvästi kontekstia; se ei ole kiistassa. Kysymys on, onko lähetetty konteksti relevantti vai vain kätevästi saatavilla. Koko asiakirjan lähettäminen on nopein tapa antaa mallille tietoa. Se ei automaattisesti ole edullisin tai paras tapa.

Toukokuu 2026, Stanfordin Digital Economy Lab julkaisi analyysin agenttisista koodaustehtävistä kahdeksan huipputason mallin välillä ja havaitsi, että nämä tehtävät kuluttavat jopa tuhat kertaa enemmän tokeneita kuin yksinkertainen koodikeskustelu, ja pääasiallinen syy ei ole mallin tuotos vaan syötteen konteksti, jonka se lähettää uudelleen ja uudelleen. Agentti lukee koko historiansa uudelleen jokaisessa seuraavassa vaiheessa. Sama tehtävä, suoritettuna useita kertoja, vaihteli token-kulutuksessa jopa kolmekymmentäkertaisesti.

Tarkkuus ei myöskään skaalaudu lineaarisesti kontekstimäärän kanssa: se usein huipentuu kohtuullisessa määrässä ja sen jälkeen lisää vain kustannuksia ilman lisäarvoa.

Token-sokeus ei siis liity siihen, että AI ei tarvitse kontekstia. Kyse on siitä, että ilman mittaamista kukaan ei kysy, onko kaikki tuo konteksti todella tarpeellista. Tasahinnassa kysymystä on helppo sivuuttaa. Kulutuspohjaisessa laskutuksessa siitä tulee osa kustannusta.

Kun maksat epäonnistumisesta kahdesti

Agenttityönkulut sisältävät toisen kustannuksen, joka lähes ei koskaan näy ROI-laskelmissa. Kuvittele yksinkertaistettu kymmenen askeleen ketju, jossa jokaisella on 95 prosentin mahdollisuus toimia oikein itsenäisesti. Se kuulostaa riittävän luotettavalta, mutta peräkkäin asetettuna tällä ketjulla on vain noin 60 prosentin mahdollisuus läpäistä koko suoritus ilman yhtään virhettä.

Työnkulussa, joka lähettää kerätyn kontekstin uudelleen jokaisessa kutsussa, jokainen epäonnistuminen ja sen jälkeinen uudelleenyrittäminen eivät vain aiheuta toistuvan askeleen kustannusta: maksat myös uudelleen kaikesta, mikä on lähetetty ennen sitä.

Se on yleinen kipupiste, jonka lähes kaikki kokevat rakentaessaan ensimmäistä agenttiputkea. Kävin sen läpi itse. Alussa, kun oli vain pari agenttia, sillä ei ollut suurta merkitystä. Mutta kun putki kasvoi, jokainen epäonnistunut suoritus tuli kalliimmaksi, ja se sai minut alkamaan kysyä, mitä kontekstia kukin agentti tarvitsee ja miten se voidaan välimuistiin, sen sijaan että kysyisin vain, onnistuiko suoritus.

Sama analyysi laskee, että kymmenen askeleen agentti, jonka jokaisen askeleen luotettavuus on 95 prosenttia, kuluttaa noin 40 prosenttia enemmän tokeneita uudelleenyrittämisissä kuin täysin luotettava järjestelmä. Tämä on kustannus, jonka näet laskussa, mutta todennäköisesti ei löydy missään ROI-taulukossa.

Valvonta ei ole virhe. Se kuuluu budjettiin

Tämä kohta on esitettävä tarkasti, koska se on helppo ymmärtää väärin. AI:n tuotoksen tarkastaminen ei ole järjestelmävirhe; se on laillinen, odotettu osa AI:n kanssa työskentelyä, aivan kuten koodikatselmointi on laillinen osa kehittäjien kanssa työskentelyä. Ongelma ei ole se, että tuotosta tehdään tarkastus. Ongelma on, että tämä työ lähes koskaan ei sisälly laskelmaan siitä, kuinka paljon AI todellisuudessa säästi.

Gleanin Work AI Institute tutki 6 000 työntekijää ja havaitsi, että automaatio säästää heille noin 11 tuntia viikossa, mutta lähes kuusi ja puoli tuntia niistä menee ylläpitotehtäviin: AI-järjestelmille kontekstin antaminen, niiden työn tarkistaminen ja virheiden korjaaminen. Nettosäästö on siis lähempänä neljää ja puolta tuntia – vähemmän kuin puolet otsikkoluvusta. AI säästää edelleen aikaa, mutta ei niin paljon kuin ensimmäinen luku antaa ymmärtää.

Kehotteet tarvitsevat ylläpitoa, ei vain kirjoittajaa

Kehotteet käyttäytyvät nykyään enemmän kuin tuotantokoodi: mallipäivitys, kontekstin muutos tai näennäisesti pieni muokkaus voi muuttaa niiden suorituskykyä. Ilman versionhallintaa ja testausta nämä muutokset voivat hiljaisesti aiheuttaa ongelmia. Koodille tavanomaiset regressiotestit jätetään usein tekemättä myös kehotteiden tarkistuksessa. Muutos, joka näyttää pieneltä muokkaukselta yhteen lauseeseen, voi päätyä tuotantoon ja heikentää tarkkuutta ilman, että kukaan huomaa, ennen kuin ongelma on kerääntynyt näkyväksi.

Oikean arviointikehyksen rakentaminen – mukaan lukien testijoukko ja automaattiset regressiotestit jokaiselle muutokselle – on lisätyötä, joka lähes koskaan ei näy \”AI säästää aikaa\” -laskelmassa.

Halvemmat tokenit, korkeammat laskut

GitHub Copilot ei ollut poikkeus. CFO Dive:n viittaama tutkimus havaitsi, että lähes seitsemästä kymmenestä Yhdysvaltain yrityksestä raportoi vähintään osittaisia AI-budjettiylityksiä viimeisen vuoden aikana, enimmäkseen ennen täyttä siirtymistä kulutuspohjaiseen laskutukseen, ei sen jälkeen.

Bain & Company, kesäkuun token-taloustieteellisessä analyysissaan, lisää paradoksin, joka kuvaa tilannetta parhaiten: tokenin hinta putosi puoleen vuoden aikana, kun taas kulutus kasvoi samana ajanjaksona 4,5-kertaisesti.

Malli tuli halvemmaksi, mutta lasku pysyy itsepintaisesti korkeana. Yritykset siirtyivät uudempiin malleihin, antoivat agenteille monimutkaisempia tehtäviä ja löysivät niille lisää työnkulkuja. Halvempi token ei tarkoittanut pienempiä kuluja; se tarkoitti, että kulutuksen syitä oli enemmän.

Kuinka valmistautua ennen kuin lasku saapuu

Seuraava kehys ei koske AI:n vähemmän käyttöä. Kyse on AI:n kustannusten tuntemisesta ennen kuin päätät skaalata sitä edelleen.

1. Hanki näkyvyys ensin

Kunnes sinulla on kulutus jaettu tiimin, työnkulun, sovelluksen ja valmiin tehtävän mukaan, jokainen laajennus on sokea veto. Tämä näkyvyys ei ole ilmaista myöskään: erityisesti agenttipohjaisissa työnkuluissa jokaisen askeleen jäljittäminen, tapahtumien ja syiden kirjaaminen sekä hallitsemattomien silmukoiden valvominen vie omaa insinööri‑aikaa ja työkaluja. Budjetoi se osaksi AI:n käyttökustannuksia, älä jälkikäteen lisättynä siihen.

2. Laske ROI uudelleen nettoperusteella

Vähennä tarkasteluun, korjauksiin ja promptin ylläpitoon kulunut aika raportoituista säästötunneista. Jos ajansäästö on käyttötapauksen tarkoitus ja nettotulos on negatiivinen tai tarkistamaton, se ei ole valmis skaalautumaan. Jos taas tavoiteltu hyöty on laatu, kapasiteetti, riskien vähentäminen tai liikevaihto, mittaa kyseinen tulos suoraan.

3. Sovella kustannuskurinalaisuutta, mutta ei tasaisesti

Kova kulutusraja on järkevä, kun epäonnistuminen on halpaa: sisäiset työkalut, kokeelliset agentit, kehitysympäristöt. Kriittiselle, asiakaspalvelua koskevalle toiminnolle – esimerkiksi asiakaspalveluassistentti – kova raja ei ole toteuttamiskelpoinen, koska se aiheuttaa katkoksen riskin. Siellä tarvitaan porrastettuja varajärjestelmiä halvempaan malliin ja varhaisia varoitusilmoituksia, ei nollaan asti sulkemista.

4. Käsittele promptit ja arvioinnit insinööri‑omaisuuksina

Versioi ne, testaa ne ja tarkista muutokset ennen käyttöönottoa, samalla tavalla kuin hallitsisit tuotantokoodia.

Käy uusimiskierroksilla omien tietojesi kanssa

Toimittajan hinnoittelu on vaikea arvioida ilman omia käyttödataa. Ennen uudistusta tai mallin vaihtoa, laske, mitä nykyiset työnkulut maksaisivat ehdotetuilla ehdoilla. Tavoitteena ei ole vain neuvotella alempaa hintaa. Tavoitteena on tietää, miten hinta käyttäytyy todellisessa kulutustasossasi sen sijaan, että selviäisi laskusta.

Kolme asiaa, jotka voit tehdä tällä viikolla: tarkista, voitko jakaa AI‑kulutuksen tiimin ja työnkulun mukaan; valitse yksi käyttötapaus ja aseta tarkasteluun kulunut aika verrattuna raportoituun säästöön; ja selvitä, missä kova kulutusraja voisi aiheuttaa katkoksen sen sijaan, että se rajoittaisi kustannusta.

AI‑kustannuksia voidaan hallita. Vain ei silloin, kun opit niistä ensimmäistä kertaa laskusta.