Miksi agenttisen tekoälyn hankkeita perutaan ja mitä kahdeksan viikon pilotissa tehdään oikein

Asiakas pyytää hyvitystä, ja agentti löytää tilauksen CRM-järjestelmästä, tarkistaa palautuskäytännön ja laatii vastauksen alle minuutissa. Sitten se pysähtyy, koska hyvityksen hyväksyntä hoidetaan talousjärjestelmässä, johon agenttia ei ole yhdistetty, eivätkä asiakkaan osoitetiedot täsmää kahdessa tietokannassa. Tällaiset puutteet tulevat harvoin esiin demossa, mutta ne ratkaisevat, kuinka paljon agentin käyttö maksaa ja voiko siihen luottaa. Siksi agenttisen tekoälyn suurempi riski piilee siinä yrityksessä, johon agentti otetaan käyttöön, ei mallissa.

Gartner arvioi, että yli 40 % agenttisen tekoälyn hankkeista perutaan vuoden 2027 loppuun mennessä kustannusten kasvun, epäselvän liiketoiminta-arvon ja puutteellisten riskienhallintakeinojen vuoksi. Tarkemmin tarkasteltuna ennuste kertoo siitä, miten hankkeet hyväksytään demon perusteella, vaikka niiden nykyisistä kustannuksista tai tulosten vastuuhenkilöistä ei ole juurikaan tietoa.

Kysyisin jokaiselta johtoryhmältä, pystyykö yritys tukemaan agenttia sen päivittäisessä työssä sellaisin kustannuksin ja riskein, jotka se voi hyväksyä. Vastaus edellyttää sen tarkkaa arviointia, mitä kutsun automaation jälkeiseksi työksi: kaikkea sitä, mitä ihmisten on edelleen tehtävä agentin osuuden valmistuttua. Kahdeksan viikon pilotti on käytännöllinen tapa mitata tätä ennen sitoutumista laajamittaiseen käyttöönottoon.

Yrityksen agentille asettamat haasteet

Agentti toimii harvoin yksin, sillä yksinkertaiselta vaikuttava tehtäväkin liittyy asiakastietoihin, pariin liiketoimintasovellukseen ja yleensä hyväksyntävaiheeseen. Jokainen yhteys rajoittaa sitä, mitä agentti voi nähdä ja tehdä. Jos tiedot ovat ristiriitaisia tai kukaan ei ole varma, kuka hyväksyy työn, agentti perii tehtävän mukana myös epäselvyydet.

Tavanomaiset tapaukset ovat harvoin ongelma; poikkeukset ovat, sillä niihin kasaantuvat toimintakustannukset, ja juuri ne demosta pyritään välttämään. Deloitten vuoden 2026 tutkimuksessa havaittiin, että vain 5 % organisaatioista arvioi liiketoimintaprosessiensa olevan erittäin hyvin valmistautuneita tekoälyagentteihin. Tämä luku kertoo enemmän kuin mikään mallin vertailutesti, sillä se viittaa siihen, että tekoäly on valmis paljon ennen useimpia prosesseja.

Liiketoimintaperustelussa on huomioitava automaation jälkeinen työ

Agentin tuottaman tuloksen nopeuden mittaaminen on helpoin tapa liioitella sen arvoa, sillä olennaista on se, kuinka paljon työtä koko tehtävän suorittaminen vaatii. Oletetaan, että työntekijältä kuluu pyynnön käsittelyyn 20 minuuttia ja agentti lyhentää ensimmäisen käsittelyvaiheen kahteen minuuttiin. Näyttää siltä, että aikaa säästyy 18 minuuttia, kunnes joku käyttää 15 minuuttia tuloksen tarkistamiseen ja virheiden korjaamiseen. Kolmen minuutin säästö on vaatimaton hyöty, kun vastapainoksi lasketaan agentin käyttökustannukset.

McKinseyn analyysi pankin asiakaspalveluagentista osoittaa saman ilmiön laajassa mittakaavassa: tokenit muodostivat 20–25 % muuttuvista käyttökustannuksista ja ihmisten tekemä valvonta 70–75 %, joten suurin osa kustannuksista syntyi mallin ulkopuolella. Jos lähtötasoa ei määritetä ennen koodin kirjoittamista, pilotti voi osoittaa huomattavaa teknistä edistystä, mutta investoinnin perustelut jäävät silti testaamatta. Vähintään liiketoiminnasta vastaavan henkilön on pystyttävä vastaamaan selkeästi seuraaviin kysymyksiin:

• Volyymi: kuinka usein prosessi suoritetaan ja kuinka moni ihminen osallistuu siihen.
• Suoritusaika: kuinka kauan koko tehtävän tekeminen kestää tarkistuksineen ja korjauksineen.
• Tarkkuus: kuinka usein tapahtuu virheitä tai tehtävä on tehtävä uudelleen.
• Tehtäväkohtaiset kustannukset: mitä yhden onnistuneesti suoritetun tehtävän tekeminen maksaa nykyisin.
• Vaikutus liiketoimintaan: mitä todellinen parannus muuttaisi asiakkaiden, henkilöstön tai yrityksen kannalta.

Agentin on ansaittava paikkansa työnkulussa

Käyttöönotto niputetaan yleensä muutosjohtamisen alle, vaikka oman kokemukseni mukaan asia ratkeaa paljon aiemmin sen perusteella, mihin kohtaan työnkulkua agentti sijoitetaan. Eräs kansainvälinen asiantuntijapalveluyritys oli kehittänyt tukityöhön ja vaatimustenmukaisuuteen agentteja. Sen tukiagentti pystyi hakemaan tietoja useista sisäisistä järjestelmistä, mutta sen käyttö edellytti erillisen sovelluksen avaamista, joten ihmiset eivät yleensä viitsineet käyttää sitä. Kun sama työnkulku siirrettiin yrityksen olemassa olevaan tukialustaan, se tuli näkyviin tikettiin, jota työntekijät jo käsittelivät. Vaatimustenmukaisuuden tarkistusagentti siirrettiin samalla tavalla Salesforceen, jossa se käynnistyi aina uuden tapauksen luonnin yhteydessä.

Itse agenteissa ei muuttunut mikään, vaan niiden paikka työnkulussa muuttui. Työntekijöillä oli jo syy avata tiketti tai luoda tapaus, joten agentin tuominen heidän luokseen juuri siinä vaiheessa ei vaatinut heiltä ylimääräistä vaivaa. Sijoittelu on siis yhtä lailla arkkitehtuuria kuin käyttöönottoa koskeva päätös, sillä agentti tarvitsee työn tekemiseen liittyvän asiayhteyden ja sen tuloksen täytyy siirtyä työn seuraavaan vaiheeseen ilman, että joku kopioi sen sinne käsin.

Autonomia muuttaa tietoturvan riskiasetelmaa

Pelkästään tietoja lukevaan agenttiin liittyy yhdenlaisia riskejä, kun taas tietueita muuttava tai asiakkaille sähköpostia lähettävä agentti tuo mukanaan aivan toisenlaisia riskejä. Siksi hallintakeinojen on vastattava sitä, mitä agentin todella sallitaan tehdä. Liialliset käyttöoikeudet ja arkaluonteisten tietojen vuotaminen ovat tunnettuja riskejä, mutta erityistä huomiota on kiinnitettävä kehoteinjektioon: agentti voi poimia asiakirjaan tai sähköpostiin piilotettuja ohjeita hoitaessaan täysin asiallista työtehtävää.

Gartnerin toukokuussa 2026 antama ohjeistus agenttien hallinnasta jakaa autonomian neljään tasoon, mikä tarjoaa käytännöllisen tavan arvioida, kuinka tiukkoja hallintakeinojen tulee olla:

1. Havainnointi: agentti hakee tietoa ja tunnistaa malleja, mutta sillä on vain lukuoikeudet.
2. Neuvonta: agentti suosittelee toimintatapaa, mutta työntekijä tekee päätöksen.
3. Toiminta hyväksynnän jälkeen: agentti valmistelee tai käynnistää toiminnon, jonka ihminen hyväksyy ennen sen suorittamista.
4. Itsenäinen toiminta: agentti suorittaa hyväksyttyjä toimia itse ennalta asetettujen rajojen puitteissa. Poikkeustilanteita valvotaan ja ne siirretään tarvittaessa eteenpäin.

Jokaisella tasolla agentti tarvitsee oman tunnisteen, tehtävänsä kannalta rajatut käyttöoikeudet ja lokitiedon jokaisesta tekemästään toimesta. Organisaatioiden on myös määriteltävä, miten tietoja käsitellään ja säilytetään, selvennettävä, mitä tietoja päätyy ulkopuolisille mallipalvelujen tarjoajille, ja nimettävä henkilö, jolla on valtuudet keskeyttää agentin toiminta ja poistaa sen käyttöoikeudet heti, kun jokin vaikuttaa olevan vialla.

Kaikki nämä hallintakeinot aiheuttavat jatkuvia kustannuksia, sillä laajemmat käyttöoikeudet, lisävalvonta ja toistuvat hyväksynnät kasvattavat niitä ajan mittaan. Sopivan autonomian tason valinta onkin turvallisuuskysymyksen lisäksi taloudellinen päätös. Oikea taso löytyy kohdasta, jossa agentti tuottaa hyödyllisen tuloksen liiketoiminnan hyväksymällä riskitasolla.

Valitse prosessi, joka perustelee agentin käytön

Monet tiimit lähtevät liikkeelle teknologiasta ja etsivät sille ongelmaa ratkaistavaksi. Parempi lähtökohta on prosessi, jonka kustannukset tai viiveet ovat jo selvästi niiden tiedossa, jotka tekevät työtä.

Kuvaus sopii erääseen maailmanlaajuiseen asiantuntijaverkostoyritykseen, jonka kanssa työskentelimme. Sen tiimi yhdisti kyselypyyntöjä asiantuntijoihin kolmessa järjestelmässä, jotka eivät keskustelleet keskenään, ja tarkisti jokaisen osuman kohdalla profiilit, aiemman osallistumisen ja vaatimustenmukaisuuden käsin. Rakensimme agentin, joka yhdisti semanttisen haun osallistumishistoriaan ja vaatimustenmukaisuussääntöihin. Tuotantokäytössä virheellisiin osumiin liittyvien tikettien määrä laski 80 %, kartoituksen tarkkuus parani 40 % ja tiimin työkapasiteetista vapautui 22 %.

Hanke onnistui, koska ongelma oli tarkasti rajattu: tieto oli hajallaan, sen yhdistäminen vaati käsityötä ja osumien laatua voitiin mitata ennen hanketta ja sen jälkeen. Tarkka rajaus auttaa myös ratkaisemaan, tarvitseeko prosessi ylipäätään agenttia. Kiinteiden sääntöjen ohjaamat työt hoituvat yleensä edullisemmin perinteisellä automaatiolla. Tekoälyavustaja puolestaan sopii usein hyvin työhön, jossa lähinnä etsitään ja tiivistetään tietoa. Agentin lisäkustannukset ja riskit ovat perusteltuja silloin, kun sen on tulkittava asiayhteyttä, valittava sallituista toimintavaihtoehdoista ja ketjutettava useita vaiheita tavoitteen saavuttamiseksi.

Kahdeksan viikon pilotti ja selkeät päätöspisteet

Koko pilotin onnistuminen riippuu yhdestä kaupallisesta kysymyksestä: voiko agentti parantaa prosessia niin paljon, että sen käyttöönotto laajassa mittakaavassa kannattaa? Kahdeksan viikkoa riittää liiketoimintaperustelun ja teknologian testaamiseen sekä sen selvittämiseen, pystyykö organisaatio hallitsemaan rakentamaansa ratkaisua.

Viikot 1–2: Määritä, mitä on parannettava

Aloita dokumentoimalla prosessin nykytila: kirjaa työmäärä, valmistumisaika, virheprosentti, uudelleentyöstö ja kustannukset. Merkitse muistiin, mitä järjestelmiä prosessissa käytetään, kuka vastaa sen kustakin vaiheesta ja mitkä poikkeustilanteet edellyttävät ihmisen puuttumista. Pyydä sitten liiketoiminnasta vastaavaa henkilöä ja teknistä tiimiä sopimaan yhdestä tuloksesta, jota agentin on tarkoitus parantaa. Päätöspiste: jatka, kun ongelma, lähtötaso, vastuuhenkilö ja onnistumisen mittarit ovat selvillä.

Viikko 3: Määritä agentin toiminnan rajat

Tässä vaiheessa määritetään agentin rajat: sen tunniste, käyttöoikeudet, pääsy tietoihin, hyväksytyt työkalut ja autonomian aste. Testaa agentti kehoteruiskutuksia, luvatonta käyttöä, arkaluonteisten tietojen paljastumista ja työkalujen väärinkäyttöä vastaan. Ota käyttöön lokitus ja toimintamalli poikkeamien varalle sekä varmista, että agentin toiminnan voi keskeyttää tai sen käyttöoikeudet poistaa. Päätöspiste: jatka, kun hallintakeinot ja puuttumismenettelyt on todella testattu ja kaikki tietävät, mitä agentti saa tehdä.

Viikot 4–6: Testaa tilanteet, jotka paljastavat demon heikkoudet

Anna agentille nyt realistisia tehtäviä, joissa on puutteellisia tietoja, ristiriitaisia tietoja, epätavallisia pyyntöjä ja silloin tällöin järjestelmävika. Seuraa, kuinka monta tehtävää agentti suorittaa, kuinka tarkka se on ja kuinka paljon ihmisten täytyy korjata sen jälkiä. Laske sitten, mitä onnistuneesti suoritettu tehtävä todella maksaa, kun mukaan lasketaan mallin käyttö, integraatiot, valvonta ja tarkistustyö. Päätöspiste: siirry käytön testaamiseen, kun agentti saavuttaa sovitut kynnysarvot ja tiimi ymmärtää sekä sen käyttökustannukset että sen toimintavirheet.

Viikot 7–8: Ota agentti oikeiden käyttäjien käyttöön

Anna agentti pienen työntekijäryhmän käyttöön rajatussa osassa oikeita työtehtäviä. Säilytä vanha prosessi varalla siltä varalta, ettei agentti pysty hoitamaan tehtävää. Seuraa, käyttävätkö työntekijät agenttia todella, helpottaako se heidän työtään ja luottavatko he sen tuottamiin tuloksiin.

Vertaa lopuksi tuloksia ensimmäisen viikon lähtötasoon. Tarkastele tuottavuutta, tarkkuutta, käyttöönottoa, ihmisten puuttumiskertojen määrää, kokonaiskäyttökustannuksia ja mahdollisia avoimia tietoturvariskejä. Päätä sitten, laajennetaanko käyttöä, korjataanko yksittäiset puutteet ja testataanko uudelleen vai lopetetaanko hanke. Pilotti on tehnyt tehtävänsä myös silloin, jos se osoittaa agentin olevan liian kallis tai epäluotettava kyseiseen työhön, sillä näin on vältetty arvailuun perustuva huomattavasti suurempi investointi.

Mittaa tulokset ja päätä sitten, kuinka itsenäisesti agentti saa toimia

Pelkkä agentin käsittelemien tehtävien laskeminen kertoo vain vähän, sillä järjestelmä voi käsitellä tuhansia pyyntöjä, mutta työntekijät joutuvat silti tarkistamaan, korjaamaan tai viimeistelemään niistä suurimman osan. Onnistuneesti suoritetun tehtävän kustannus yhdessä tarkkuuden ja poikkeamien määrän kanssa kertoo paljon paremmin, onko prosessi parantunut alusta loppuun.

Samat mittarit tarjoavat perusteen agentin toimintavallan lisäämiselle. Jos agentti hoitaa rutiinipyynnöt luotettavasti sovittujen rajojen puitteissa, sen voi antaa käsitellä ne itsenäisesti. Jos se taas kohtaa toistuvasti monitulkintaisia tapauksia, ihmisen on hyväksyttävä nämä päätökset, ja käyttöoikeuksia arvioidaan uudelleen näytön karttuessa.

Laajenna käyttöä, kun liiketoiminta pystyy tukemaan agenttia

Yhdessä tiimissä hyvin toimivan agentin on ennemmin tai myöhemmin kyettävä toimimaan myös muiden osastojen ja sovellusten kanssa sekä huomioimaan niiden hyväksyntäketjut. Käytön laajentaminen edellyttää selkeää vastuutahoa, yhdenmukaisia pääsynhallintakäytäntöjä ja toimivaa tapaa käsitellä poikkeuksia. Lisäksi tarvitaan budjetti agentin pitämiseksi ajan tasalla, kun sitä ympäröivät prosessit muuttuvat.

Kaiken tämän taustalla on päätös siitä, kuinka paljon vastuuta organisaatio on valmis siirtämään agentille. Päätöksen on perustuttava todellisesta työstä saatuun näyttöön, ei onnistuneeseen esittelyyn. Kahdeksan viikon päätteeksi johdon pitäisi tietää, mistä agentti selviytyy, missä ihmisten on edelleen puututtava työhön ja paljonko agentin käyttö maksaa. Agenttipohjaisen tekoälyn avulla muita edelle pääsevät yritykset suunnittelevat jo ensimmäisestä viikosta lähtien, mitä automatisoinnin jälkeen tehtävälle työlle tapahtuu, ja kohdentavat agenttien rahoituksen tehtäviin, jotka ne todella suorittavat.