Ei jokainen organisaation AI-sovellus vaadi samaa nopeutta. Jotkin asiat vaativat välitöntä huomiota, toiset voidaan sisällyttää normaaliin suunnittelusykliin. Ongelma on, että tätä jaottelua tehdään harvoin näkyväksi. Ilman luokittelua kaikki saa saman kiireellisyyden, tai — useammin — ei minkäänlaista kiireellisyyttä.
Kysymys siitä, onko jokin tehtävä nyt vai voiko se odottaa, ei ole makuasia. Se riippuu useista tekijöistä, jotka yhdessä määrittävät, kuinka painavaksi sovellus muodostuu.
Sovelluksen riskitaso on ensimmäinen tekijä. Järjestelmä, joka tekee ihmisiä koskevia päätöksiä — rekrytointi, luotonanto, palveluihin pääsy — painaa eri vaakakupissa kuin työkalu, joka tiivistää tekstiä sisäiseen käyttöön. Se, mitä korkea riskitaso tarkalleen tarkoittaa organisaation velvoitteiden kannalta, ja miksi se ei ole samanlainen jokaisen sovelluksen kohdalla, on kuvattu sivulla mitä korkea riskitaso tarkoittaa organisaatiollenne.
Organisaation rooli on toinen tekijä. Organisaatio, joka kehittää tai muokkaa AI-järjestelmää itse, kantaa erilaisia vastuita kuin organisaatio, joka ottaa käyttöön valmiin järjestelmän. Tämä rooli voi myös muuttua ilman, että sen taustalla on tietoinen valinta: se, joka hienosäätää, muokkaa tai ottaa mallin käyttöön tarkoituksesta poikkeavalla tavalla, voi siirtyä käyttäjästä tarjoajaksi. Missä tämä raja kulkee, on selitetty sivuilla mikä muuttuu, kun muokkaatte mallia itse ja oletteko tarjoaja vai käyttäjä, mistä se riippuu.
Kolmas tekijä on se, kuuluuko sovellus soveltamisalaan. Ei jokainen järjestelmä, jota kutsutaan AI:ksi, kuulu samojen velvoitteiden alle; joitakin sovelluksia on suljettu pois tai ne kuuluvat kevyemmän sääntelyn piiriin. Mitkä sovellukset jäävät soveltamisalan ulkopuolelle ja miksi, on kuvattu sivulla mitkä sovellukset jäävät soveltamisalan ulkopuolelle.
Nämä kolme tekijää — riskitaso, rooli, soveltamisala — määrittävät yhdessä, mihin kohtaan aikajanaa sovellus sijoittuu. Korkean riskin sovellus, jossa organisaatio toimii tarjoajana, vaatii eri nopeutta kuin matalan riskin sovellus, joka saattaa pian jäädä soveltamisalan ulkopuolelle.
Jaottelu ei ole pysyvä. Sovellus, joka tänään katsotaan hallittavaksi, ei välttämättä ole sitä huomenna — ei siksi, että säännöt muuttuisivat, vaan siksi, että sovellus itse muuttuu. Malli, jota muokataan, järjestelmä, joka saa uuden tehtävän, työkalu, joka siirtyy sisäisestä pilotista tuotantoon: mikä tahansa näistä askelista voi muuttaa roolia tai riskitasoa.
Myös organisatoriset muutokset vaikuttavat asiaan. Fuusio, uusi toimittaja, käytön laajentaminen toiseen osastoon — kaikki tällaiset tapahtumat voivat siirtää sovelluksen, joka aiemmin luokiteltiin 'voidaan aikatauluttaa', kategoriaan 'on tehtävä nyt'. Milloin rooli muuttuu ja missä tämä käännekohta tarkalleen sijaitsee, on selitetty sivulla milloin roolinne muuttuu, mistä se riippuu.
Tämä tarkoittaa, että kertaluonteinen jaottelu ei riitä. Se, mikä tänään on aikataulutettu esityslistan kohta, voi organisaation muualla tapahtuvan muutoksen seurauksena saada erilaisen painoarvon. Säännöllinen, toistuva uudelleenarviointi on siksi osa jokaista jaottelua, jonka on tarkoitus pitää paikkansa — ei ylimääräisenä vaiheena, vaan edellytyksenä jaottelun ajantasaisuuden säilyttämiselle.
Selkeä jaottelu estää kaksi vastakkaista virhettä. Ensimmäinen on, että kaikkea käsitellään kiireellisenä, jolloin prioriteetit hämärtyvät ja huomio hajaantuu sovelluksiin, joihin liittyy vähän riskiä. Toinen on, että mitään ei pidetä kiireellisenä, jolloin todellista riskiä kantavat sovellukset pysyvät vuosia tutkan alla — usein siksi, ettei kukaan ole koskaan luokitellut niitä.
Jaottelu itsessään ei ole kertaluonteinen asiakirja, vaan rakenne, joka liikkuu organisaation mukana. Se tuottaa yleiskuvan siitä, mikä vaatii huomiota lyhyellä aikavälillä, mikä voidaan sisällyttää säännölliseen prosessiin, ja — ratkaisevasti — mikä on arvioitava uudelleen tilanteen muuttuessa. Juuri tämä erottelu, ja kysymys siitä, mistä se riippuu, on käsitelty tarkemmin sivulla mitä on tehtävä nyt ja mitä voidaan aikatauluttaa, mistä se riippuu.
Tämä jaottelu edellyttää, että tiedetään, mitä sovelluksia on olemassa. Käytännössä näin ei aina ole. IT:n tai hankinnan kautta hyväksyttyjen järjestelmien lisäksi käytännössä kaikissa organisaatioissa on käytössä työkaluja, joita kukaan ei ole pyytänyt eikä rekisteröinyt — laskentataulukkoassistentti täällä, tekstigeneraattori tuolla, käyttöön otettuna ihmisten toimesta, jotka halusivat ratkaista ongelman eivätkä halunneet käydä läpi menettelyä. Tämä varjo-AI ei näy IT-listalla, ja se, joka kysyy siitä käyttäjälle vaarantamatta mitään, saa todennäköisemmin rehellisen vastauksen kuin se, joka uhkaa välittömästi seuraamuksilla. Ilman tätä inventaariota jokainen kiireellisyyden mukainen jaottelu koskee vain osaa todellisuudesta, ei sitä kokonaisuudessaan.
Tämä sivu käsittelee luokittelua: mikä painaa paljon, mikä painaa vähän, mikä vaatii huomiota nyt ja mikä voi odottaa. Toinen, täydentävä kysymys on, mitä AI-sovellus tehtävän sisällä todellisuudessa tuottaa. FTE TO AI:n työkalukartoitus laskee tehtäväkohtaisesti, kuinka suuri osa työstä on siirrettävissä AI:lle, ja tarjoaa siten konkreettisen kuvan hallintajaottelun rinnalle: ei vain sitä, kantaako sovellus riskiä, vaan myös sitä, mitä se tuottaa itse työhön.
Responsible AI Scan on kehitteillä. Se, joka haluaa käyttää inventaariota, luokittelua ja hallintapakettia niiden valmistuttua, voi ilmoittautua odotuslistalle.
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.