Organisaatiot ajattelevat usein, että niiden rooli on kiinteä: me olemme käyttäjä, toimittaja on tarjoaja, ja siinä se. Tämä oletus ei useinkaan pidä paikkaansa, tai se pitää paikkansa tänään mutta ei enää huomenna. Rooli, joka organisaatiolla on suhteessa AI-järjestelmään, ei ole organisaation pysyvä ominaisuus. Se on lopputulos siitä, mitä järjestelmälle tapahtuu: kuka sen tekee, kuka sitä muokkaa, kuka tuo sen markkinoille ja millä nimellä. Jos yksi näistä tekijöistä muuttuu, myös rooli voi muuttua, ja sen mukana siihen liittyvät velvoitteet.
Tämä tekee luokittelusta jotain muuta kuin hetkellisen tilannekuvan. Rooli, joka oli oikein määritelty hankintahetkellä, voi olla virheellinen vuotta myöhemmin, ilman että organisaation sisällä on tietoisesti päätetty mitään.
Luokittelu riippuu rajallisesta joukosta tekijöitä, mutta kaikki nämä tekijät eivät ole sen osapuolen hallinnassa, joka käyttää järjestelmää. Merkitystä on esimerkiksi sillä, onko järjestelmä kehitetty itse vai hankittu ulkoa, otetaanko hankittu järjestelmä käyttöön muuttamattomana tai muokataanko sitä, ja vaikuttaako muokkaus järjestelmän riskiprofiiliin. Merkitystä on myös sillä, millä nimellä järjestelmä tuodaan ulkomaailmaan: järjestelmä, joka myydään edelleen tai kehitetään edelleen omalla tuotemerkillä, voi tuoda mukanaan erilaisen roolin kuin ulkoisen tuotteen käyttäminen muuttamattomana. Näiden kahden asetelman tarkkaa rajaa käsittelee sivu siitä, mitä muuttuu, kun organisaatio muokkaa hankittua mallia itse, ja perustavanlaatuiseen kysymykseen siitä, kumpi päärooleista pätee, vastaa sivu, joka selittää mistä valinta tarjoajan ja käyttäjän välillä tarkalleen riippuu.
Luokittelu ei siis ole asia, jonka organisaatio määrittää kertaalleen ja arkistoi sen jälkeen. Se on luokittelu, joka on arvioitava uudelleen aina, kun sen taustalla olevat tosiseikat muuttuvat.
Jos rooli muuttuu, muuttuu myös se, mitä organisaatiolta odotetaan. Osapuolella, joka on puhtaasti käyttäjä, on erilaiset velvoitteet kuin osapuolella, joka on (osittain) vastuussa järjestelmän syntymisestä. Tämä ei koske vain paperityötä. Se koskee myös sitä, mihin organisaatiossa järjestelmästä koituva vastuu kuuluu sijoittaa, kuka siitä raportoi ja millainen valvonnan taso on asianmukainen.
Tämä muutos vaikuttaa siihen, miten painavaksi järjestelmä on sisäisesti arvioitava. Roolimuutos voi johtaa siihen, että järjestelmä, jota aiemmin pidettiin hallittavana, on arvioitava uudelleen riskitason kannalta — kysymys, jota käsitellään erikseen sivulla siitä, mitä korkea riskitaso tarkoittaa järjestelmää käyttävälle tai tarjoavalle organisaatiolle. Toisaalta roolimuutos voi myös johtaa siihen, että järjestelmä jää nimenomaan tiettyjen velvoitteiden soveltamisalan ulkopuolelle, tai päinvastoin tulee juuri sen sisään. Mitkä sovellukset tarkalleen jäävät soveltamisalan ulkopuolelle ja mitkä ovat vain hieman sen sisäpuolella, selitetään sivulla siitä, mitkä AI-sovellusten tyypit jäävät velvoitteiden soveltamisalan ulkopuolelle.
Tekijät, jotka aiheuttavat roolimuutoksen, tapahtuvat useimmiten tasolla, jota johto, lakiasiainosasto tai riskienhallinta ei automaattisesti näe. Tiimi, joka hienosäätää hankittua mallia omalla datallaan. Osasto, joka välittää ulkoisen chatbot-tuotteen asiakkaille omalla tuotenimellä. Integraatio, joka yhdistää toimittajan mallin omiin sääntöihin ja tarjoaa sen yhdistelmän sen jälkeen ulkoisesti. Mikään näistä vaiheista ei automaattisesti kulje keskitetyn rekisterin läpi, ja IT:n hyväksyttyjen työkalujen luettelo ei useimmiten rekisteröi tämäntyyppistä muutosta, koska muutosta ei tunnisteta ”uudeksi hankinnaksi” vaan jonkin jo hyväksytyn asian muokkaukseksi.
Tämä on syy siihen, miksi roolimuutokset tulevat usein näkyviin vasta, kun jotain menee pieleen, tai kun ulkopuolelta vaaditaan selvitystä. Kysymykseen ”mikä on roolimme tämän järjestelmän kohdalla” vastataan silloin jälkikäteen, hetkellä, jolloin liikkumavara muutosten tekemiseen on pienempi kuin se olisi ollut, jos kysymys olisi esitetty aiemmin.
Koska luokittelu voi muuttua, on erottelu sen välillä, mikä vaatii huomiota juuri nyt ja mikä on arvioitava uudelleen myöhemmin, merkityksellinen governance-työn suunnittelun kannalta. Kaikki, mitä roolimuutos tuo mukanaan, ei vaadi välitöntä toimintaa; osa on suunniteltavissa. Mikä osa se on ja mikä osa ei voi odottaa, käsitellään sivulla siitä, mitä on hoidettava nyt ja mitä voidaan aikatauluttaa myöhempään ajankohtaan. Tiiviin yhteenvedon itse luokittelukysymyksestä, mukaan lukien tärkeimmät käännekohdat, tarjoaa sivu, joka syventyy tarkkoihin olosuhteisiin, joissa rooli muuttuu.
Kysymys siitä, mikä rooli organisaatiolla on suhteessa AI-järjestelmään, on läheistä sukua toiselle kysymykselle, joka harvoin saa yhtä paljon huomiota: kuinka suuri osa organisaation tosiasiallisesta työstä tehdään jo AI:n avulla, on suunnitteilla tehtäväksi AI:n avulla, tai on jo siirtynyt AI:lle kenenkään sitä varsinaisesti kirjaamatta. Siinä missä roolikysymys koskee vastuuta suhteessa järjestelmään, FTE TO AI:n työskannaus koskee itse tehtävänjakoa: tehtävittäin lasketaan, kuinka suuri osa on AI:n otettavissa hoidettavakseen, riippumatta siitä, mikä rooli organisaatiolla siinä muodollisesti on. Näillä kahdella kysymyksellä on yhteys toisiinsa, sillä muutos tehtävänjaossa on usein syy roolin muutokseen.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.