Ennen kuin riskitaso, velvoite tai hallintatoimenpide saa merkitystä, on selvitettävä, mitä roolia organisaationne näyttelee. Sillä, jos organisaatio saattaa AI-järjestelmän markkinoille, on erilaiset vastuut kuin sillä, joka ottaa käyttöön toisen rakentaman järjestelmän. Tähän käytetty termi on tunnettu: tarjoaja verrattuna käyttäjään. Mutta itse luokittelu ei ole kiinteä organisaatiokaavion asia. Se riippuu siitä, mitä organisaatio tekee tietyn järjestelmän kanssa, ja se voi vaihdella järjestelmän, osaston ja ajankohdan mukaan.
Ydinkysymys ei ole se, kuka on ostanut tai asentanut järjestelmän, vaan kuka on saattanut sen markkinoille tai asettaa sen saataville omalla nimellään. Organisaatio, joka hankkii ohjelmiston ja käyttää sitä sellaisenaan, on yleensä käyttäjä. Organisaatio, joka kehittää järjestelmän, teettää sen kehitettäväksi omalla nimellään, tai muokkaa olemassa olevaa järjestelmää niin, että siitä tulee toiminnallisesti jotain muuta, voi tällöin joutua tarjoajan rooliin. Tämä jälkimmäinen on usein kohta, missä organisaatiot laskevat väärin: mallin hienosäätö, oman kerroksen rakentaminen ulkoisen järjestelmän päälle, tai chatbotin kouluttaminen omalla datalla voi siirtää roolia kenenkään kokematta sitä tietoisena valintana. Se, mikä täsmälleen lasketaan muutokseksi, joka muuttaa roolia, on kuvattu sivulla mikä muuttuu, kun muokkaatte mallia itse.
Useimmat organisaatiot eivät ole yksinomaan tarjoajia tai yksinomaan käyttäjiä. Pankki, joka käyttää ulkoista kielimallia asiakaspalvelussa, on siinä käyttäjä, mutta jos samainen pankki asettaa sisäisesti kehitetyn riskimallin toisen osaston tai asiakkaan käyttöön, syntyy tälle järjestelmälle tarjoajan rooli. Tämä tarkoittaa, että luokittelu on tehtävä sovelluskohtaisesti, ei kertaalleen koko organisaatiolle. Inventaario, jossa kirjataan järjestelmäkohtaisesti kuka sen on rakentanut, kuka sitä on muokannut ja kuka sitä käyttää, on siksi ainoa tapa vastata tähän kysymykseen rakenteellisesti sen sijaan, että se tehtäisiin satunnaisesti.
Rooli ei ole organisaation kiinteä ominaisuus vaan tila, joka on alttiina muutokselle. Toimittaja voi muuttaa järjestelmäänsä tavalla, joka vaikuttaa riskiprofiiliin. Sisäinen kehittäjä voi kehittää sisäisen apuvälineen edelleen joksikin, joka tarjotaan organisaation ulkopuolelle. Järjestelmä, joka aikanaan otettiin käyttöön yksinkertaisena työkaluna, voi päivityksen jälkeen suorittaa tehtäviä, jotka sijoittavat sen toiseen riskiluokkaan. Milloin tämä siirtymä käytännössä tapahtuu ja mitä se merkitsee sille, joka on siitä vastuussa, on selitetty sivulla milloin roolinne muuttuu. Organisaatioille, jotka haluavat ymmärtää, mitä siirtymä kohti korkeampaa riskitasoa käytännössä tarkoittaa, sivu mitä korkea riskitaso tarkoittaa organisaatiollenne tarjoaa lisää syvennystä.
Ei kaikki sovellukset, joita kutsutaan tekoälyksi, kuulu kehykseen, jonka puitteissa rooliluokittelu on relevantti. Osa järjestelmistä jää tämän luokittelun soveltamisalan ulkopuolelle, ja organisaatiolle on yhtä tärkeää tietää, mikä jää soveltamisalan ulkopuolelle, kuin tietää, mikä kuuluu sen sisään. Muuten aikaa kuluu jonkin luokitteluun, joka ei olisi tarvinnut luokittelua, tai jotain jää huomaamatta, koska sen katsottiin olevan liian vähäistä. Mitkä sovellukset jäävät tämän kehyksen ulkopuolelle ja miksi, on kuvattu sivulla mitkä sovellukset jäävät soveltamisalan ulkopuolelle.
Roolin määrittäminen on ensimmäinen askel, ei hallintaprosessin lopputulos. Luokittelun jälkeen seuraa kysymys siitä, mitä kunkin roolin ja riskitason kohdalla tosiasiallisesti tulee tehdä, ja tämä kysymys jakautuu kahteen luokkaan: siihen, mikä vaatii välitöntä huomiota, ja siihen, mikä voidaan aikatauluttaa pidemmälle aikavälille. Näitä kahta luokkaa sekoitetaan usein toisiinsa, jonka seurauksena kiireelliset asiat jäävät odottamaan, kun aikaa käytetään johonkin, joka ei ole vielä ajankohtaista. Yhteenveto siitä, mille tässä on annettava etusija, löytyy sivulta mitä on tehtävä nyt ja mitä voidaan suunnitella. Sille, joka haluaa syventää kysymystä rooliluokittelusta entisestään, tarkkoja kriteereitä, jotka määrittävät tarjoajan ja käyttäjän välisen rajan, löytyy sivulta oletteko tarjoaja vai käyttäjä: mistä se riippuu.
Tämä luokittelu on mielekäs vain, kun sitä sovelletaan siihen, mitä organisaatiossa todella on käytössä, ei siihen, mikä on hyväksytyllä listalla. Järjestelmät, jotka on otettu käyttöön luvatta, lasketaan yhtä lailla mukaan, ja niihin liittyvä rooli on määritettävä yhtä huolellisesti. Tämä vaatii inventaarion, joka menee IT-hallinnon rekisteriä pidemmälle.
Kun on selvää, mitä roolia organisaatio näyttelee järjestelmäkohtaisesti, huomio siirtyy luonnollisesti toiseen kysymykseen: mitä nämä järjestelmät oikeastaan tekevät, ja kuinka suuren osan työstä ne ottavat hoitaakseen. Tämä kysymys sijaitsee hallinnointiskannauksen ulkopuolella, mutta liittyy siihen suoraan. FTE TO AI:n työskannaus laskee tehtäväkohtaisesti, kuinka suuri osa työstä on siirrettävissä AI:n hoidettavaksi, ja antaa siten kuvan järjestelmän vaikutuksesta sen velvoitteita koskevan kuvan rinnalla.
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.