Tekoälyprojektin epäonnistuminen harvoin johtuu tekniikasta. Useimmiten syy löytyy lähtötilanteesta: tavoite on epämääräinen, data on huonossa kunnossa tai kukaan ei omista uutta työnkulkua käyttöönoton jälkeen. Tämä artikkeli on tarkoitettu PK-yrityksen toimitusjohtajalle, myyntijohtajalle tai kehityspäällikölle, joka suunnittelee ensimmäistä tai toista AI-projektiaan. Artikkeli käy läpi yleisimmät epäonnistumisen syyt ja kertoo, miten ne tunnistaa ennen kuin rahaa ja kuukausia on jo kulunut.
Miltä epäonnistunut tekoälyprojekti näyttää käytännössä
Harva tekoälyprojekti kaatuu näyttävästi. Tyypillisempää on, että projekti hiipuu hiljaa.
Otetaan esimerkiksi 30 hengen tukkukauppa Tampereella. Yritys rakennuttaa automaation, joka lukee saapuvat tilaussähköpostit ChatGPT:n avulla ja vie rivit ERP-järjestelmään. Demossa kaikki toimii. Kolmen kuukauden päästä myyntisihteeri tarkistaa jokaisen rivin käsin, koska kaksi virheellistä toimitusta ehti jo aiheuttaa reklamaation. Automaatio on yhä päällä, mutta aikaa ei säästy yhtään. Kukaan ei nimittäisi projektia epäonnistuneeksi, mutta todellisuudessa se on epäonnistunut.
Tämä on yleisin kaava: tekninen toteutus onnistuu, mutta liiketoimintahyöty jää syntymättä.
Tekoälyprojektin epäonnistumisen viisi pääsyytä
Kun projekteja käydään jälkikäteen läpi, samat syyt toistuvat toimialasta riippumatta.
1. Ratkaisu etsii ongelmaa. Projekti alkaa lauseella ”meidänkin pitäisi tehdä jotain tekoälyllä”. Silloin valitaan näyttävä kohde eikä se, joka oikeasti vie eniten aikaa. Kokenut konsultti aloittaa kysymällä, mihin tiimi käyttää viikossa eniten toistuvaa käsityötä, eikä sitä, mitä tekoäly osaa.
2. Onnistumista ei ole määritelty numeroina. Jos tavoite on ”tehostaa asiakaspalvelua”, projektia ei voi arvioida. Jos tavoite on ”vastausaika 24 tunnista 4 tuntiin ja 30 % tiketeistä ratkeaa ilman ihmistä”, sen voi. Ilman lähtötason mittausta ennen käyttöönottoa myöhemmin ei pysty todistamaan edes onnistumista.
3. Data on hajallaan tai epäsiistiä. CRM:ssä on samasta asiakkaasta kolme versiota, tuotekoodit on kirjattu Exceliin kahdella eri logiikalla ja puolet tiedosta on jonkun sähköpostissa. Tekoäly ei korjaa tätä, se vain monistaa sotkun nopeammin.
4. Poikkeuksia ei ole suunniteltu. Automaatio rakennetaan 80 % tapauksia varten, ja loput 20 % kaatavat luottamuksen. Mitä tapahtuu, kun asiakas liittää tilauksen PDF:nä, kirjoittaa ruotsiksi tai rajapinta ei vastaa? Jos vastaus on ”ei mitään”, käyttäjät palaavat vanhaan tapaan.
5. Omistaja puuttuu käyttöönoton jälkeen. Ulkopuolinen toimittaja rakentaa n8n- tai Make-työnkulun, projekti päättyy ja laskut maksetaan. Puolen vuoden päästä rajapinta muuttuu tai promptia pitäisi päivittää, eikä talon sisällä kukaan tiedä, miten kokonaisuus toimii.
Myytti: parempi malli korjaa ongelman
Hyvin yleinen väärinkäsitys on, että heikot tulokset johtuvat väärästä työkalusta. Kun GPT-mallin tuotos ei miellytä, vaihdetaan Claudeen tai Geminiin ja odotetaan ihmettä.
Käytännössä mallin vaihto parantaa tuloksia harvoin enemmän kuin muutaman prosenttiyksikön. Selvästi suuremmat erot syntyvät siitä, millaista kontekstia mallille annetaan, kuinka selkeä ohjeistus on ja tarkistetaanko tuotos ennen kuin se menee eteenpäin. Tilausautomaatio, joka saa mukaansa asiakkaan aiemmat tilaukset ja tuotekoodilistan, toimii paremmin heikommallakin mallilla kuin huippumalli ilman taustatietoa.
Poikkeuksiakin on. Jos tehtävä vaatii pitkien dokumenttien analysointia, kuvantunnistusta tai tarkkaa suomen kielen tuottamista, mallien välillä on aitoja eroja, ja silloin testaaminen kannattaa.
Näin rakennat projektin, joka ei hiivu
Ammattilainen jakaa tekoälyprojektin pieniin vaiheisiin, joista jokainen todistaa hyödyn ennen seuraavaa investointia. Tarkemman vaiheistuksen löydät artikkelista tekoälyn käyttöönotto vaiheittain, mutta runko on tämä.
Ensimmäiset 1-2 viikkoa käytetään nykytilan mittaamiseen. Kuinka monta tilausta, tikettiä tai tarjousta käsitellään viikossa, kauanko yksi vie ja paljonko virheitä syntyy? Pelkkä tämä vaihe paljastaa usein, että oletettu pullonkaula on väärässä paikassa.
Seuraavat 3-6 viikkoa rakennetaan pilotti yhteen rajattuun työnkulkuun. Tässä vaiheessa ihminen hyväksyy jokaisen tekoälyn tuotoksen. Kyse ei ole hitaudesta vaan datasta: jokainen hylätty tai korjattu tuotos kertoo, missä ohjeistus tai syötedata ontuu.
Kun hyväksymisprosentti pysyy tasaisesti yli sovitun rajan, esimerkiksi 95 %:ssa kahden viikon ajan, tarkistus voidaan kohdistaa vain epävarmoihin tapauksiin. Mittausta jatketaan, ja tuloksia verrataan lähtötasoon. Laskentamalliin löytyy apua artikkelista tekoälyinvestoinnin ROI:n mittaaminen.
Kustannukset pysyvät pilotissa yleensä maltillisina. ChatGPT:n tai Clauden tiimilisenssi maksaa noin 25-30 € käyttäjältä kuukaudessa, ja n8n:n tai Maken perustaso muutamia kymmeniä euroja kuukaudessa. Suurin kustannus on asiantuntijatyö ja oman henkilöstön aika, ei ohjelmistot.
Yleisimmät virheet, jotka kannattaa välttää
Liian suuri ensimmäinen projekti. Koko asiakaspalvelun korvaaminen chatbotilla kuulostaa houkuttelevalta, mutta se koskettaa kymmeniä prosesseja kerralla. Kun jokin menee pieleen, koko hanke leimautuu epäonnistuneeksi. Yksi tarkasti rajattu työnkulku, kuten tarjouspyyntöjen luokittelu, antaa näytön nopeammin.
Loppukäyttäjät jätetään sivuun. Johto päättää, IT tai toimittaja rakentaa, ja asiakaspalvelija kuulee muutoksesta maanantaiaamuna. Ne ihmiset, jotka tekevät työtä päivittäin, tuntevat poikkeukset. Heidän mukaan ottamisensa jo määrittelyvaiheessa säästää viikkoja korjaustyötä myöhemmin.
Dokumentointi jätetään tekemättä. Kun työnkulun logiikka, käytetyt promptit ja virhetilanteiden käsittely on kirjattu ylös, seuraava tekijä pääsee jatkamaan. Ilman dokumentaatiota yksikin henkilövaihdos voi pysäyttää koko automaation.
Rajatapauksena mainittakoon, että hyvin pienessä, 2-5 hengen yrityksessä raskas projektimalli on usein ylimitoitettu. Silloin riittää, että yrittäjä itse kokeilee työkalua viikon ajan todellisella työllä ja kirjaa ylös, paljonko aikaa säästyi.
UKK
Kuinka nopeasti tekoälyprojektin pitäisi tuottaa tulosta?
Rajatun pilotin hyödyn pitäisi näkyä mitattavasti 6-10 viikossa. Jos kolmen kuukauden jälkeen ei ole lukua, johon osoittaa, tavoite tai rajaus kannattaa arvioida uudelleen.
Pitääkö datan olla täydellisessä kunnossa ennen aloittamista?
Ei tarvitse. Riittää, että pilotissa käytettävä data on johdonmukaista. Datan siivoaminen kannattaa kohdistaa siihen osaan, jota ensimmäinen työnkulku oikeasti tarvitsee, eikä koko järjestelmään kerralla.
Voiko epäonnistuneen tekoälyprojektin pelastaa?
Usein voi. Ensin selvitetään, missä vaiheessa hyöty katoaa: syötedatassa, mallin tuotoksessa vai siinä, miten tulos siirtyy työnkulkuun. Tavallisesti korjaus on ohjeistuksen tarkentaminen tai ihmisen tarkistusvaiheen lisääminen, ei koko ratkaisun uudelleenrakentaminen.
Aloita ongelmasta, ei työkalusta
Tekoälyprojektit epäonnistuvat samoista syistä kuin muutkin kehityshankkeet: tavoite on epäselvä, lähtötasoa ei mitata ja vastuu katoaa käyttöönoton jälkeen. Tekniikka on harvoin se heikko lenkki.
Ennen seuraavaa projektia kannattaa kirjoittaa yhdelle A4-sivulle kolme asiaa: mikä työ halutaan vähentää, millä luvulla onnistuminen mitataan ja kuka omistaa ratkaisun puolen vuoden päästä. Jos yksikin kohta jää tyhjäksi, projekti ei ole vielä valmis aloitettavaksi.