Joku tiimi halusi kokeilla jotain. Chatbotin asiakaskysymyksiin, skriptin joka tiivistää raportteja, kytkennän kielimalliin sähköpostien lajittelua varten. Siihen ei tarvittu suurta päätöstä: jollakin oli tunnus, API-avain tai ilmainen kokeilujakso, ja saman iltapäivän aikana jokin oli käynnissä. Pilotti toimi, tai toimi riittävän hyvin, ja kenelläkään ei ollut enää syytä sammuttaa sitä.
Tämä ei ole poikkeus. Se on tavallinen tapa, jolla AI tulee organisaatioon sisään. Ei hankinnan tai hyväksytyn budjetin kautta, vaan koeasetelman kautta, joka elää pidempään kuin oma koestatuksensa. Testivaihetta ei koskaan virallisesti päätetty, koska sillä ei koskaan ollut virallista alkuakaan päätettäväksi.
Pilotti, joka toimii, otetaan käyttöön. Ja se, mitä käytetään, muuttuu riippuvuudeksi. Tiimi, joka rakensi raporttien tiivistäjän, on saattanut lähteä, mutta tiivistelmä saapuu edelleen joka viikko. Kenelläkään ei ole toimeksiantoa sammuttaa sitä, ja kukaan ei halua ottaa riskiä, että jokin lakkaa toimimasta tietämättä, mikä tulee sen tilalle.
Lisäksi koeasetelmalla ei tavallisesti ole omistajaa siinä merkityksessä, jota hallintarakenne edellyttää. Riskiluokitusta ei ole tehty, data-analyysiä ei ole suoritettu, päätöstä ei ole tehty siitä, kuka on vastuussa, jos jokin menee pieleen. Pilotti elää välitilassa: liian käytetty jätettäväksi huomiotta, liian epämuodollinen hallittavaksi. Se on juuri se kaava, joka johtaa tilanteeseen, jossa työntekijät käyttävät työkalua, jota kukaan ei ole hyväksynyt — mutta tässä tapauksessa tiimitasolla eikä yksilötasolla.
Refleksi, kun luvattoman koeasetelman havaitsee, on usein: kuka tämän salli, ja miksi me emme tienneet tästä. Se kysymys on ymmärrettävä, mutta se toimii päinvastaiseen suuntaan. Se, joka tuntee ensimmäisessä keskustelussa syyllistämisen olevan tulossa, ei kerro seuraavalla kerralla enää mitään. Ja seuraava koeasetelma — jota epäilemättä syntyy — katoaa näkyvistä yhtä lailla kuin tämä.
Luottamukselle rakennettu inventaari tuottaa enemmän kuin valvonnalle rakennettu tarkastus. Ei siksi, että ihmisillä ei olisi mitään salattavaa, vaan koska tarvittava tieto on käyttäjällä, ja se käyttäjä puhuu vain, jos häntä ei aseteta vastuuseen siitä, mitä hän löytää.
Kun koeasetelma on tullut näkyviin, ensimmäinen kysymys ei ole, saako se jäädä olemassaolevaksi, vaan mitä se tarkalleen ottaen tekee. Mikä data siihen menee, kuka käyttää tulosta, ja mitä tapahtuu, jos tulos on virheellinen. Ne ovat samat kysymykset, jotka pätevät mihin tahansa muuhun AI-sovellukseen, ja vastaus määrittää, onko kyse epämuodollisesta apuvälineestä vai riskistä, joka ansaitsee huomiota.
Sen jälkeen tulee luokitus: sopiiko sovellus jo olemassa olevaan riskiluokkaan, vai vaatiiko se uuden harkinnan. Sitten: mitä on kirjattava, jotta voidaan osoittaa, että organisaatio tietää, mitä on käynnissä ja miksi. Juuri siihen paneutuu mitä teidän on kirjattava sovelluskohtaisesti — ei ylimääräisenä byrokratiana, vaan minimidokumentaationa, joka tarvitaan pilotin erottamiseksi riskistä.
Koeasetelma, joka läpäisee tämän testin, voi jäädä olemaan, nyt omistajan ja luokituksen kanssa. Koeasetelma, joka ei läpäise testiä, on ajettava alas — mutta se on hallittu prosessi, ei erottaminen henkilölle, joka sen aikoinaan käynnisti.
Koeasetelma, jota ei koskaan sammutettu, on yksi muoto laajemmasta kaavasta. Ajatelkaa selainlaajennusta, jolla on pääsy sähköpostiinne ja jonka joku joskus asensi säästääkseen aikaa, tai yritysdataa, joka päätyy ilmaiseen chat-ikkunaan, koska se kävi nopeammin kuin virallinen työkalu. Kaikilla näillä tilanteilla on yksi yhteinen piirre: ne ovat syntyneet käytännön tarpeesta, ei politiikkavalinnasta, ja ne pysyvät olemassa niin kauan kuin kukaan ei kysy niistä.
IT:n hyväksytyn ohjelmiston lista ei siis ole inventaarin lähtökohta — se on lähtökohta etsinnälle, joka kohdistuu siihen, mikä jää sen listan ulkopuolelle. Sille, joka haluaa tietää, miltä tämä etsintä näyttää, löytyy lähestymistapa kohdasta miten rakennat AI-inventaarin.
Esiin tuleva koeasetelma herättää tavallisesti jatkokysymyksen, joka ulottuu hallintaa pidemmälle: miksi tämä toimi oikeastaan niin hyvin, että kukaan ei uskaltanut sitä pysäyttää? Se on kysymys itse työstä, ei vain riskistä. FTE TO AI:n työscan laskee tehtäväkohtaisesti, kuinka suuri osa työstä on AI:n siirrettävissä, ja tekee näin näkyväksi sen, mitä koeasetelma jo implisiittisesti osoitti: että osa työstä voidaan järjestää toisin. Siinä missä Responsible AI Scan kartoittaa, mikä on käynnissä ja millä riskitasolla, työscan näyttää, mistä tuo käyttö on peräisin ja mitä se rakenteellisesti tarkoittaa tehtäväjaon kannalta.
Responsible AI Scan, sisältäen yllä kuvatut inventaarin, luokituksen ja hallintakokonaisuuden, on kehitteillä. Se, jolla on tämän kanssa jo tekemistä ja joka haluaa tulla informoiduksi heti kun työkalu on saatavilla, 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.