Pilotin ja tuotannon välissä ei ole ketään
Olemme olleet mukana kolmessa selvitystyössä, joissa on kartoitettu tekoälyn käyttöä suomalaisessa sote-järjestelmässä. Niiden aikana olemme haastatelleet kymmeniä tutkijoita, kliinikoita, tietohallinnon asiantuntijoita ja johtajia, ja kysyneet muun muassa sitä, mitä heidän kehittämilleen malleille on tapahtunut.
Odotimme kuulevamme teknisistä ongelmista. Niistä ei juuri puhuttu.
Yliopistosairaaloissa kehitetään hyviä malleja kuvantamiseen, kirjaamisen automatisointiin ja kliiniseen ennakointiin. Ne toimivat. Tutkimusta tehdään kiihtyvään tahtiin ja osaamista on. Puuttuu ihminen, jonka työnkuvaan kuuluisi viedä valmis malli tutkimuksesta käyttöön.
Sama havainto toistui niin monta kertaa, että lopetimme sen merkitsemisen erikseen muistiin.
Julkisuudessa kiertää luku, jonka mukaan noin 95 prosenttia generatiivisen tekoälyn piloteista ei päädy tuotantoon.¹ Sen voi lukea todisteeksi siitä, että teknologia on ylimyyty. Meidän aineistomme kertoo toista: pilotit tekevät sen mitä niiltä pyydetään, ja sitten ne loppuvat.
Pilotti tekee juuri sen mitä pitää
Pilotin tehtävä on osoittaa, että ratkaisu voi toimia rajatussa ympäristössä. Tuotantovalmius ei kuulu siihen tehtävään. Tutkimusryhmä ei vastaa jatkuvasta käytöstä, ylläpidosta eikä vaatimustenmukaisuudesta, eikä sen pitäisikään.
Vika on siinä mitä tapahtuu seuraavaksi.
Haastatteluissa kuvio toistui lähes poikkeuksetta. Pilotti päättyy. Hanke päättyy. Ratkaisu jää odottamaan seuraavaa vaihetta, jonka kriteerejä ei ole kirjoitettu ja jolle ei ole nimetty omistajaa. Jonkin ajan päästä seuraava hanke aloittaa saman polun uudestaan vähän eri lähtökohdista.
Siitä seuraa päällekkäistä työtä ja oppien katoamista organisaatioiden välillä. Olemme nähneet useaan kertaan, miten samantyyppisiä ratkaisuja kehitetään rinnakkain eri alueilla. Yllättävintä on ollut se, miten yllättyneitä ihmiset ovat, kun heille kerrotaan siitä.
Uusien pilottien käynnistäminen ennen jatkopolun määrittelyä lisää sirpaloitumista.
Miksi hyöty katoaa matkalla
Tehtävätasolla mitatut hyödyt ovat todellisia. Asiakaspalvelussa ongelmanratkaisu on nopeutunut keskimäärin 14 prosenttia, ja heikommin suoriutuvien työntekijöiden tuottavuus on parantunut jopa 34 prosenttia.² Ohjelmistokehityksessä tuotetun koodin määrä on kasvanut jopa 98 prosenttia.³
Organisaatiotasolla vaikutusta ei näy.
Sama koodimäärää mitannut tutkimus raportoi katselmointiaikojen pidentyneen jopa 91 prosenttia.³ Yhden työvaiheen nopeuttaminen siirsi pullonkaulan seuraavaan. Makrotasolla jotkin arviot ennustavat alle prosentin tuottavuuskasvua seuraavalle vuosikymmenelle.⁴
Tämä ei ole uutta. Robert Solow huomautti 1987, että tietokoneiden aikakausi näkyy kaikkialla paitsi tuottavuusluvuissa.⁵ Sähkön ja tietokoneen kaltaisilta yleiskäyttöisiltä teknologioilta on historiallisesti mennyt vuosikymmeniä ennen kuin vaikutus näkyi kansantalouden tasolla.⁶ Organisaation sisällä sama ilmiö tunnetaan tuottavuuden J-käyränä: uusi teknologia vaatii investointeja osaamiseen, toimintatapoihin ja prosesseihin, ja alkuvaiheessa tuottavuus voi jopa laskea ennen kuin se nousee.⁷
Boston Consulting Group esittää onnistuneelle käyttöönotolle suhdetta 10–20–70. Kymmenen prosenttia algoritmeihin, kaksikymmentä teknologiaan ja dataan, seitsemänkymmentä prosessien ja ihmisten työn muuttamiseen.⁸ Valtaosa niistä organisaatioista, joiden työtä olemme nähneet sisältä, käyttää resurssinsa päinvastaisessa suhteessa.
Mitä tuotantoon vieminen vaatii
Tuotantokäyttö ei ole yksi este. Samaan aikaan pitää olla kasassa sääntelyosaaminen, tietosuojaosaaminen, tuotantoympäristö, tietoturva, elinkaaren hallinta sekä hankinta- ja sopimusmalli joka sopii tämäntyyppiseen työhön.
Jos yksikin puuttuu, ratkaisu jää kokeiluksi. Yksittäisellä sairaalalla tai hyvinvointialueella ei tyypillisesti ole resursseja, mandaattia eikä rakennetta pitää kaikkia näitä yhtä aikaa pystyssä. Harvalla toimittajallakaan ne ovat koossa.
Osa vaatimuksista ei ole vapaaehtoisia. EU:n tekoälyasetuksen 4. artikla velvoittaa organisaatiot varmistamaan henkilöstönsä riittävän tekoälyosaamisen, ja kentällä tätä velvoitetta tunnetaan kokemuksemme mukaan huonosti. GDPR:n ja EHDS:n minimointivaatimukset ovat puolestaan suorassa jännitteessä sen kanssa, että datalähtöisessä tutkimuksessa halutaan laajoja aineistoja uusien yhteyksien löytämiseksi. Se jännite ei ratkea vaatimalla toiselta osapuolelta enemmän. Se ratkeaa silloin, kun tutkimuskysymys osataan kääntää konkreettiseksi datatarpeeksi, ja se on harvinaisempi taito kuin luulisi.
Turvallisuus on oma kerroksensa, ja se on muuttunut. Kielimallit tuovat mukanaan uuden hyökkäyspinnan: luonnollisen kielen. Olemme törmänneet tuotannossa olleisiin, julkiverkkoon avattuihin botteihin, joiden puutteet löytyvät suoraan OWASPin kielimallisovellusten top 10 -listalta — kehoteinjektio, järjestelmäkehotteen vuotaminen, rajoittamaton kulutus.⁹ Kun samalle botille annetaan vielä pääsy organisaation dataan ja työkaluihin, riskiluokka on toinen. Kannattaa olettaa, että jokainen botti joutuu ennemmin tai myöhemmin kehoteinjektion kohteeksi, ja rajata sen oikeudet siitä oletuksesta käsin.
Se mitä tilalle tarvitaan
Toistettava rakenne. Nämä toimivat yhdessä, eivät erillisinä toimenpiteinä.
Turvallinen kokeiluympäristö, jossa malleja voi testata oikealla datalla ilman tuotantovaikutusta. Ja siitä sovittu portti tuotantoon. Ilman porttia ympäristö muuttuu itse pysyväksi kokeiluksi.
Mallirekisteri: mitä malleja on käytössä ja kehitteillä, versiot, omistajat, käyttötarkoitus, validointitila, riskiluokka, tuotantostatus. Rekisteri alkaa toimia siinä vaiheessa kun sitä käytetään priorisointiin ja hyväksyntään, ei siinä vaiheessa kun se on täytetty.
Referenssiarkkitehtuuri: miten tekoäly liitetään ympäristöön — datavirrat, käyttöoikeudet, lokitus, monitorointi, MLOps. Ilman tätä jokainen hanke rakentaa saman perustan uudelleen ja vähän eri tavalla.
Hyväksyntäportit ja päätösrytmi. Go/no-go-kriteerit sovitaan etukäteen, ja säännöllisin välein päätetään jatketaanko, suunnataanko uudelleen vai lopetetaanko. Lopetuskriteerien puuttuminen on yhtä kallista kuin etenemiskriteerien, koska resurssit jäävät kiinni hankkeisiin joiden edellytykset eivät täyty.
Elinkaaren operointi. Tämä unohtuu useimmin. Epäonnistuminen tapahtuu tyypillisesti ylläpitovaiheessa, ei kehitysvaiheessa. Mallin ajautuminen, päivitykset, versionhallinta, palvelutaso ja jatkuva monitorointi ovat tuotantopalvelun ominaisuuksia, eivät projektin viimeinen tehtävä.
Näiden päälle tarvitaan sisältöomistajuutta, ja siitä paras esimerkki on intran älykäs haku. Se on teknisesti helppo ja nopea demota. Pohjimmiltaan se on datalaatu- ja sisältökuriprojekti. Jos ohjeet ovat ristiriitaisia, vanhentuneita tai vailla metatietoja, malli palauttaa epävarmoja vastauksia, ja käyttäjälle syntyy tunne että tekoäly keksii omiaan. Se vain heijastaa lähdeaineiston sekavuutta. Hakumalli ei tuota yhtä totuutta lähteistä joissa niitä on useita.
Mittaa se työ joka siirtyi näkymättömiin
Yksi asia ansaitsee erillismaininnan, koska se on halpa tehdä ja koska se muuttaa arvioinnin luonteen.
Pilotti voi näyttää toimivalta, vaikka työ on vain siirtynyt paikkaan jossa sitä ei lasketa: manuaalisiin tarkistuksiin, kiertoteihin ja ihmisten tekemään paikkaukseen. Siksi kiertoteiden, manuaalityön ja operatiivisen kitkan mittaaminen kuuluu pilotin arviointiin samalla tavalla kuin tarkkuusluvut. Ilman sitä skaalataan ratkaisua, jonka todelliset kustannukset selviävät vasta sadannen käyttäjän kohdalla.
Ja onnistumisen määritelmän on oltava todennettu käyttö. Hankkeella on omistaja, ratkaisu on käytössä, ja hyötyä seurataan. Jos nämä kolme eivät täyty, hanke on tuottanut tietoa.
Sama havainto muualta
Abdelwanisin ym. (2026) systemaattinen kirjallisuuskatsaus kokosi 92 tutkimusta ja tunnisti 16 estettä tekoälyn käyttöönotolle terveydenhuollossa. Esteet jäsentyvät Human–Organization–Technology-kehykseen, ja painopiste on sama kuin meidän aineistossamme: keskeiset ongelmat ovat rakenteellisia ja organisatorisia.¹⁰
Se on hyvä uutinen, koska rakenteet ovat päätettävissä. Kriteerit, vastuut ja omistajuus voidaan sopia ennen seuraavaa pilottia.
Yhteen kysymykseen meillä ei ole vastausta. Emme tiedä, kenelle se puuttuva rooli kuuluu — tilaajalle, toimittajalle vai kansalliselle toimijalle. Kaikkia kolmea on kokeiltu jossain, eikä yksikään malli ole vielä osoittautunut selvästi paremmaksi. Sen verran voi sanoa, että niin kauan kuin rooli on kaikkien ja siksi ei kenenkään, jokainen uusi pilotti on sijoitus jonka tuotto riippuu siitä, sattuuko joku innostumaan siitä kylliksi tehdäkseen sen oman työnsä ohessa.
Lähteet
- MIT NANDA (2025). The GenAI Divide: State of AI in Business 2025.
- Brynjolfsson, E., Li, D. & Raymond, L. (2025). Generative AI at Work. QJE 140(2), 889–942.
- Faros (2025). The AI Productivity Paradox Report 2025.
- Acemoglu, D. (2025). The simple macroeconomics of AI. Economic Policy 40(121), 13–58.
- Solow, R. (1987). “We’d better watch out.” New York Times Book Review, 12.7.1987.
- David, P. (1990). The Dynamo and the Computer. American Economic Review 80(2).
- Brynjolfsson, E., Rock, D. & Syverson, C. (2021). The Productivity J-Curve. AEJ: Macroeconomics 13(1), 333–372.
- Boston Consulting Group, 10–20–70-periaate.
- OWASP Top 10 for LLM Applications; Traficom & Huoltovarmuuskeskus: Tekoälyagenttien kyberturvallisuus.
- Abdelwanis, M., Simsekler, M. C. E., Gabor, A. F., Sleptchenko, A. & Omar, M. (2026). Artificial intelligence adoption challenges from healthcare providers’ perspectives.