Miten päästä eroon ”tekoäly on taikuutta” -ajattelusta: miksi tekoälymallien toimintaperiaatteiden oppimisen on oltava koko yrityksen yhteinen tavoite

Tekoälyagenttien hallitsemattomasta toiminnasta annettujen varoitusten keskellä kehittäjä antoi hiljattain koodausagentille vapaat kädet koneella, josta ei ollut etävarmuuskopiota. Se poisti 48 000 tiedostoa alle kahdessa minuutissa.

Tällaiset tapaukset muistuttavat karulla tavalla tekoälyagenttien käyttöönottoon liittyvistä riskeistä: ei riitä, että monimutkaisen prosessin johonkin vaiheeseen lisätään ihminen tarkastajaksi ja oletetaan järjestelmän olevan turvallinen. Jotkin prosessit eivät vaadi lainkaan ihmisen puuttumista, kun taas toiset edellyttävät huomattavasti tiukempia tarkistuksia. Kirjoitusvirheen korjaamiseen ja tuhansien tiedostojen poistamiseen liittyvät riskit ovat selvästi eri tasoa, joten valvonnan on vastattava sitä, mikä todella on vaakalaudalla.

Organisaatioiden on opittava tunnistamaan paremmin tilanteet, joissa ihmisen harkintakyvyllä on todella merkitystä – erityisesti silloin, kun toiminnalla on suuri vaikutus tai sitä on vaikea perua. Kun agentit tekevät virheitä, ympäristön on lisäksi rajattava niiden aiheuttamien vahinkojen laajuutta.

Tekoäly ei ole determinististä vaan probabilistista

Ensisijaisen tärkeää on, että jokainen suoraan tai välillisesti ohjelmistokehitykseen osallistuva työntekijä saa perustiedot siitä, miten tekoälymallit käsittelevät tietoa. Tämä ei ole mikään pieni urakka: se edellyttää sitoutumista tiimien kouluttamiseen, ja lopulta siitä pitäisi tulla koko yrityksen yhteinen tavoite.

Kun ihminen alkaa käyttää tekoälyä ensimmäistä kertaa, se tuntuu taikuudelta. Kirjoitat lauseen, ja yhtäkkiä käyt keskustelua. Perustiedot siitä, miten mallit ja niiden koulutus todellisuudessa toimivat taustalla, ovat tärkeitä, kun yrityksessä laaditaan tekoälyä koskevia tietoturva- ja tuottavuuslinjauksia. Neuroverkot, tokenisointi ja niiden taustalla tapahtuva tilastollinen analyysi sekä se, miten ne johtavat tuotoksiin, tarjoavat kaikille yrityksen työntekijöille keskeisen oppimismahdollisuuden.

Suuret kielimallit eivät koskaan tuota deterministisiä tuloksia. Niiden tuotokset ovat probabilistisia. Tavanomaisessa ohjelmistossa syötteen antamisen jälkeen voit odottaa saavasi tietyntyyppisen tuloksen, esimerkiksi A:n, B:n tai C:n. Tekoälyltä voit kuitenkin saada F:n, &-merkin tai kuvauksen aurinkolaseja käyttävästä kissasta.

Probabilistista järjestelmää ei voi testata tavanomaisella tavalla. Tarvitaan testaustapa, jonka avulla voidaan mukautua, päätellä, ymmärtää ja hakea nopeasti asiayhteyteen liittyvää tietoa, jotta probabilistiset tekijät havaitaan ja tunnistetaan niiden mahdollisesti aiheuttamat ongelmat. Testauksen laajuudesta ja riskeistä riippuen siitä voi vastata joko tekoäly tai asiaan perehtynyt ihminen. Ihmisen osallistumisesta on eniten hyötyä aivan alussa, jolloin voidaan määritellä ratkaistava ongelma, ja lopuksi tulokset voidaan tarkistaa.

Kehittäjät pystyvät parhaiten havainnoimaan muuttujia ja vakiintuneita käytäntöjä, jotka vaikuttavat siihen, miten organisaation sisäinen tekoäly tuottaa vastauksia syötteiden perusteella. Siksi he voivat auttaa muovaamaan yrityksensä tekoälykoulutusta ja varmistamaan, että kaikki ymmärtävät tämän tekoälyn determinismin ja probabilismin välisen eron sekä sen merkityksen. Tavoitteena on päästä eroon ajattelutavasta, jonka mukaan tekoälyn käyttö on taikuutta ja kaikki sen tuottamat tulokset kelpaavat sellaisinaan. Sen sijaan organisaatioiden tulisi pyrkiä hälventämään tekoälyyn liittyvää mystiikkaa ja esittelemään yrityksen käyttämät mallit, niiden käyttötavat, mahdollisesti syntyvät ongelmat, ongelmien tarkistustavat sekä tarkistusprosessin tulokset.

Suojamekanismit kuuluvat infrastruktuuriin, eivät malliin

Kun tekoälyn ”taika” on kumottu ja tekoälyhanke on käynnissä, on tärkeää ottaa käyttöön läpinäkyvä auditointikäytäntö, jolla varmistetaan, että kaikki etenee odotetusti. Jos hankkeessa syntyvä tulos on ”huono” tai ei täytä vaatimuksia, vastuuhenkilö voi tällöin tarkastaa tehdyt vaiheet ja estää ongelman toistumisen. Käytännöstä on hyötyä myös silloin, kun tulokset ovat odotettua parempia: tällöin samat vaiheet voidaan toistaa ja jakaa muille hankkeille tai ryhmille.

Prosessin järjestelmällistäminen on erityisen tärkeää suurissa yrityksissä, joissa kussakin tiimissä voi olla kymmeniä kehittäjiä ja päivän mittaan koodia käsittelee satoja kehittäjiä. Tekoäly pystyy tekemään paljon asioita hyvin nopeasti, ja jos jokin menee pieleen, tarvitaan järjestelmä, jonka avulla voidaan selvittää tarkasti, missä vaiheessa ongelma syntyi. Esimerkkinä ovat OpenAI:n agentit, jotka murtautuivat Hugging Faceen tänä kesänä. OpenAI testasi, miten hyvin sen mallit pystyivät hyödyntämään ohjelmistojen haavoittuvuuksia. Testissä käytettiin ExploitGym-nimistä vertailutestiä. Testiä varten mallien kieltäytymisiä hyökkäävään kybertoimintaan liittyvistä tehtävistä höllennettiin tarkoituksella. Ainoa reitti hiekkalaatikosta ulos kulki pakettivälityspalvelimen kautta. Mallit löysivät välityspalvelimesta tuntemattoman haavoittuvuuden, pääsivät sen kautta ulos ja viettivät Hugging Facen tuotantojärjestelmissä yli kaksi päivää etsien testin vastauksia.

Otsikoissa tapausta kutsuttiin tekoälyn hallitsemattomaksi toiminnaksi. Minä kutsuisin sitä probabilistisen järjestelmän ympärille rakennetuksi deterministiseksi toteutukseksi. OpenAI käski malleja murtautumaan järjestelmiin ja luotti sitten siihen, että ne pysyisivät odotetulla polulla. Vertailutestin laatijan mukaan mallit olivat huijanneet testissä aiemminkin, mutta aina hiekkalaatikon sisällä. Tällä kertaa yksi niistä ei pysynyt siellä. Tavanomaiset suojamekanismit olettavat tavanomaista toimintaa, mutta tekoälyn ei tarvitse noudattaa normeja.

Siksi tekoälyn tietoturvassa on kyse käyttöoikeuksista ja valvontakeinoista, joiden noudattaminen varmistetaan toimintaympäristössä sen sijaan, että luotettaisiin mallin toimivan oikein. Oleta, että agentti yrittää avata jokaisen oven, ja jätä auki vain ne, joita se tarvitsee. Agentille, joka poisti 48 000 tiedostoa, oli annettu ohje työskennellä kopioilla ja jättää alkuperäiset rauhaan. Se poisti alkuperäiset silti. Ohjeet eivät ole valvontakeinoja.

Agentin käyttöoikeuksien hallinta muistuttaa uuden juniorikehittäjän perehdyttämistä. Et antaisi hänelle pääkäyttäjän oikeuksia tuotantoympäristöön ensimmäisenä päivänä. Jos antaisit ja hän poistaisi tietokantasi, et pitäisi sitä nerokkaan hakkerin tekosina. Tietoturvapoikkeamissa niiden laajuudesta riippumatta on ehdottoman tärkeää selvittää perimmäinen syy. Onko syy mallissa? Onko syy mallin luoneessa yrityksessä? Onko syy yrityksessä, joka antoi mallille käyttöoikeudet? Oli syy mikä tahansa, viime kädessä vastuu on ihmisellä.

Lopuksi yksi keskeinen asia, johon on puututtava jo nyt, on se, mitä tapahtuu kehittäjän kannettavalla tietokoneella katseilta piilossa. Aiemmin työnkulun jäljittäminen oli yksinkertaisempaa. Kehittäjät kirjoittivat koodia, tarkistivat sen ja julkaisivat sen, joten tapahtumien eteneminen oli helppo jäljittää siihen hetkeen, jolloin jokin meni pieleen. Nyt kehittäjä saattaa antaa tehtävän agentille ja sanoa: ”korjaa tämä”. Jos työ tapahtuu näkymättömissä, mitään ei voi jäljittää. Jokaisesta vaiheesta on jäätävä kattava jälki: mikä agentti käynnistettiin, mitä mallia se käytti, mitä kehotteita sille annettiin, mitä työkaluja se kutsui ja mitä käyttöoikeuksia sillä silloin oli. Agenttien keskitetty suorittaminen yksittäisten kannettavien tietokoneiden sijaan on yksi tapa saavuttaa tämä. Olennaista on, että jälki on olemassa.

Viime kädessä jokaisen yrityksen on suojauduttava mahdollisen poikkeaman varalta. Jäljen tulisi sisältää riittävästi tietoa perimmäisen syyn analysointia varten sekä sen vaiheen ja koodin löytämiseksi, jotka aiheuttivat ongelman.

Tekoäly on muuttanut maailmaa valtavasti, ja liiketoimintaprosessien on muututtava sen mukana. Jotta asianmukaiset suojatoimet voidaan määrittää, tekoälyprosesseja, testausta, katselmointikierroksia ja auditointikierroksia on ymmärrettävä paremmin sekä kehittäjätiimeissä että koko yrityksessä.