Tekoälyratkaisu vs. räätälöity, koodiin perustuva järjestelmä – kuka kantaa vastuun, kun jokin menee pieleen ohjelmiston kanssa?

Ongelma syntyy silloin, kun liiketoimintakriittinen prosessi rakentuu kokonaan kolmannen osapuolen suoriutumisen varaan, pahimmillaan ilman omaa hallintaa.
Kuka kantaa vastuun, kun jokin menee pieleen AI-ohjelmiston kanssa?

Aloitetaan esimerkillä. Kuvittele tilanne, jossa olet varannut Airbnb-majoituksen ulkomailta ja ehtinyt jo lentää kohteeseen, mutta majoituksen omistaja-host aivan yllättäen peruuttaakin tekemäsi varauksesi samana päivänä, jolle check-in oli sovittu.

Matkustajan roolissa tällainen kokemus lähentelee monelle jo pahinta mahdollista skenaariota: olla nyt vieraassa maassa ja yhtäkkiä täysin ilman majoitusta!

Mutta kenen vastuulla tilanteen ratkaiseminen on?

Tämä esimerkki on tositarina, jossa tosielämän Airbnb sanoi, ettei ongelma ole heidän, koska he vain välittävät jonkun muun tuottamaa palvelua. Kolmas osapuoli, eli majoituksen omistaja petti luottamuksesi, mutta sinä matkustajana maksat hinnan ja kannat vastuun.

Sama logiikka ikävä kyllä pätee vauhdikkaassa AI-muutoksessa useisiin IT-hankkeisiin, kun koko ratkaisu saatetaan rakentaa nojaamaan laajaan kielimalliin.

Kolmannen osapuolen aiheuttamat ongelmat koskevat usein juuri tekoälyratkaisuja

Useimmat ohjelmistot rakentuvat jonkun muun tekemien komponenttien päälle tai vähintäänkin joutuvat toimimaan niiden kanssa yhteistyössä. On normaalia hyödyntää erilaisia kirjastoja ja rajapintoja, koska pyörää ei luonnollisestikaan kannata keksiä uudelleen.

Ongelma syntyy silloin, kun liiketoimintakriittinen prosessi rakentuu kokonaan kolmannen osapuolen suoriutumisen varaan – ja pahimmillaan ilman omaa hallintaa.

Tekoälyratkaisuissa tämä riski on erityisen konkreettinen, koska käyttäjällä ei ole mitään hallintaa niiden taustalla olevaan teknologiaan. Teknologiat ovat täysin OpenAIn, Googlen, Microsoftin tai jonkun muun suuren toimijan hallussa, ja nämä toimijat tekevät täysin omia päätöksiään niin hinnoista, saatavuudesta kuin toimintatavoistakin. Osa hinnoista on jo noussut ja yleinen kohu tekoälytokenien hintojen laajoista korotuksista kiihtyy.

Kun organisaatio ottaa käyttöön tekoälypohjaisen ratkaisun, jota pyöritetään jonkin monikansallisen tekoäly-yhtiön kielimallin varassa, kuka kantaa vastuun, jos asiat muuttuvatkin yhtäkkiä radikaalisti? Kysymys ei ole mitenkään teoreettinen.

Millaiset sopimukset sinulla on käyttämiisi työkaluihin tai järjestelmiin? Voivatko niihin liittyvät kustannuksesi tuplaantua vain siksi, että tekoälyn käytöstä tulee yhtäkkiä kallista?

Tällä hetkellä tekoälypalvelut ovat poikkeuksellisen halpoja, mutta halpa hinta perustuu osin siihen, että markkinaosuutta vielä rakennetaan aggressiivisesti. Kun markkina on saatu haltuun, on todennäköistä, että hinnoittelu muuttuu.

Jos siis liiketoimintasi kriittisimmät prosessit nojaavat tekoälyyn, jonka hinnoittelupäätökset eivät ole sinun käsissäsi vaan globaalin toimijan vallassa, olet rakentanut riippuvuuden, jonka seurauksia et hallitse.

Lue myös: Tarvitaanko uusia järjestelmiä tai ohjelmistokehittämistä enää ollenkaan, eikö kaikki pian ratkea agenteilla? | Steve the Clerk

Tekoäly on probabilistinen — mitä se tarkoittaa ja mitä riskejä siitä syntyy?

Koodi tekee mitä käsketään. Aina, täsmälleen samalla tavalla, joka kerta. Siksi sitä sanotaan deterministiseksi. Tekoäly puolestaan tekee todennäköisimmän asian useimmiten aika lähelle oikein, mutta ei aina – kyseessä on siis probabilistinen työkalu.

Esimerkiksi 98 prosentin tarkkuus tekoälyprosessissa kuulostaa hyvältä, kunnes lasketaan mitä se tarkoittaa käytännössä. Eli jos järjestelmä käsittelee sata tapahtumaa päivässä, kaksi menee pieleen joka päivä, ja yhteensä se tekee joka vuosi yli 700 virhettä.

Onko tuo virhemäärä hyväksyttävä? Riippuu täysin siitä, mitä prosessia 98 % tarkkuudella toimivalla järjestelmällä ollaan automatisoimassa.

Asiakasviestinnässä tai tulkinnoissa probabilistinen tekoäly on todennäköisesti työkalu paikallaan. Mutta tarjouslaskennassa, jossa yksi virhe tarkoittaa väärää hintaa (ja huonoja katteita) tai riskienhallinnassa, jossa sääntelyrikkomus voi johtaa sanktioon, on deterministinen järjestelmä turvallisempi valinta.

Kysymys ei siis alkuunkaan ole siitä, onko tekoäly hyvä vai huono vaan siitä, missä asioissa sitä kannattaa käyttää ja missä sen probabilistisesta luonteesta syntyvät riskit ovat sallittavia. Millaisista tekoälyn mokista sinä olet valmis kantamaan vastuun?

Lue myös: Miksi koodi tekee mitä käsketään, mutta AI usein vähän mitä sattuu? Ymmärrä koodin ja kielimallien suurin ero | Steve the Clerk

Mitä ”vastuu” oikeasti tarkoittaa järjestelmähankinnassa

Hämmentävänkin normaali käytäntö ohjelmistoalalla on, että jos ohjelmisto ei toimi sovitulla tavalla, sitä toki korjataan (yleensä pitkään ja hartaasti) mutta korjaamisesta sujuvasti laskutetaan lisää (yleensä todella paljon). Toimittaja on toki ennen tätä jo saanut rahansa alkuperäisestä toimituksesta, mutta uusi ongelma on aina uusi laskutusperuste.

Tällainen toimintamalli on ollut peruslähtökohta jo niin kauan, että yleensä asiakkaat joutuvat nöyrtymään ajatellen, että näin IT-hankkeet vain toimivat.

Me Steve the Clerkillä näemme asian toisin. Vastuu tarkoittaa meille sitä, että toimitetaan se, mitä on luvattu ja sovittu. Sopimus on toki tärkeä, mutta pohjimmiltaan se on epäluottamuspaperi: sitä luetaan silloin, kun luottamus on jo murentunut. Meille tärkeintä on kumppanuus, jossa molemmat osapuolet haluavat onnistua yhdessä.

Tutustu referenssitarinaan: SKAL loi kuljetusalaa palvelevan konfiguraattoriperheen: ”Yritysten ei pidä kuluttaa energiaansa sääntöviidakon selvittämiseen”

Lue myös: Ohjelmistohanke ilman ikuisuusprojektia? Näin viet pilotin läpi organisaatiossasi ilman, että siitä tulee liian iso mörkö

Datan omistajuus: tiedätkö miten organisaatiosi hyödyntämä ohjelmisto käyttää sille annettua tietoa?

2020-luvulla totta ovat olleet myös tekoälyprojektit, joiden sopimuksessa on pienellä todettu, että palveluntarjoajalla on oikeus hyödyntää asiakkaan sinne viemää dataa omiin tarkoituksiinsa.

Mitä se tarkoittaa käytännössä? Parhaimmillaan ei mitään. Pahimmillaan se tarkoittaa, että teidän prosessidatanne, asiakastietonne tai tuotetietonne voi päätyä kilpailijoidenne käyttöön jonkun muun palvelun harjoitusdatana tai analytiikan lähteenä.

Onko tämä tavallista IT-alalla? Perinteisten järjestelmien kohdalla ei. Tekoälyratkaisuiden kohdalla pelottavankin yleistä.

Tutustu suomalaiseen järjestelmäalustaamme Steve the Clerk HUBiin

Tekoälyratkaisuja käyttäessä vastuunjako hämärtyy – oletko valmis kohtaamaan riskit?

Kun räätälöidyssä järjestelmässä jokin menee pieleen, tiedetään kuka vastaa: toimittaja, joka on rakentanut järjestelmän, tai asiakas, joka on antanut väärät lähtötiedot. Vastuu on siis paikannettavissa.

Kun tekoälypohjainen ratkaisu tekee virheen, vastuu hämärtyy: onko vika mallissa, promptissa, datassa, integraatiossa vai käyttäjässä, joka luotti tulokseen tarkistamatta?

Tähän ei ole yhtä oikeaa vastausta, mutta toistaiseksi syyttävä sormi on kääntynyt suoraan tekoälyä käyttävään ihmiseen ja hänen edustamaansa organisaatioon.

Oletko sinä valmis ulkoistamaan liiketoimintakriittisten virheiden vastuunkannon henkilöstöllesi tai yritystäsi toivottavasti suojaaville vastuuvapautussopimuksille?

Me Steve the Clerkillä emme lähtökohtaisesti suosittele tekemään niin. Ymmärrämme, että AI:lla on toden totta oma paikkansa työn tehostamisessa, mutta seisomme vahvasti sillä kannalla, että myös tekoälyaikakaudella deterministisillä, tekoälyyn pohjaamattomilla ydinjärjestelmillä ja laadukkaalla pohjadatalla on paikka lähes aivan jokaisessa organisaatiossa.

Lue myös: Kustannustehokkuutta vai rahan tuhlaamista? Tehoton tekoäly ja huono data muodostavat IT-hankkeen kalleimmat virheet | Steve the Clerk

Ohjelmistoteknologian valinta on aina myös vastuuvalinta – millaisen vastuun sinä haluat kantaa?

Me Steve the Clerkillä autamme sinua arvioimaan, milloin kannattaa luottaa koodin tarkkuuteen ja millä tavalla siihen voisi yhdistää myös tekoälyn tuomaa joustavuutta.

Varaa tapaaminen, niin näytämme miten auttaisimme sinua. Rakennamme pilotin lyhyessä ajassa, jotta pääset näkemään, miltä ratkaisu näyttää käytännössä. Ratkaisumme pohjaa vaan yli kymmenen vuoden aikana rakentamaamme suomalaiseen, erittäin muuntuvaan järjestelmäalustaan, Steve the Clerk HUBiin.

Varaa tapaaminen kanssamme – keskustellaan, millä tavalle me voisimme ratkaista organisaatiosi resursseja hukkaavan ongelman.

Tutustu myös referensseihimme!

Muita artikkeleita, jotka voisivat kiinnostaa sinua

Useimmat järjestelmät rakennetaan yhä erilaisten arjen oireiden eikä niiden todellisen aiheuttajan ympärille...
Järjestelmäuudistus lähestyy vääjäämättä mutta tekoälyn kehittymisen mahdolliset vaikutukset hankintaan aiheuttavat epämääräistä oloa? Tutustu tuhtiin tietopakettiimme ohjelmistokehityksen ja tekoälyn tärkeimmistä teemoista!..
Rikkinäiset prosessit ärsyttävät, mutta niiden korjaaminen jää aina sivuun jonkun isomman uudistuksen tieltä. Näin käynnistät kevyen pilotin ilman ikuisuusprojektia...
Mikä on roolikohtainen työkalu ja missä positioissa työskenteleville se on tarkoitettu? Mistä datasta tässä puhutaan? Millaisille organisaatioille tällaisesta on hyötyä?..