Tekoälypiloteista vastuulliseen toimintaan
Lentäjä, joka voitti jatkuvasti
Pilotti onnistui niin kuin pilotit usein onnistuvat. Huone oli pieni, käyttäjät olivat ystävällisiä, tapaukset oli valittu huolella, toimittajan tiimi oli avulias, malli käyttäytyi riittävän hyvin, ja lopun diassa oli prosenttiluku, joka sai kaikki nojaamaan eteenpäin. Avustaja vähensi luonnosteluun kuluvaa aikaa. Luokittelija löysi useampia olennaisia tapauksia. Hakutyökalu toi esiin asiakirjoja, joiden olemassaolon ihmiset olivat unohtaneet. Johtopäätös oli ilmeinen: laajennetaan.
Sitten pilotti kohtasi maanantain. Maanantaina oli puuttuvaa dataa, väsynyttä henkilökuntaa, reunatapauksia, vanhoja käytäntöjä, hämmentyneitä käyttäjiä, jonopainetta, hidas verkko, esimies, joka pyysi raporttia puoleenpäivään mennessä, ja yksi tapaus, joka ei sopinut mihinkään pilotissa käytettyyn luokkaan. Maanantaina ohjelmisto lakkaa olemasta mahdollisuus ja siitä tulee vastuu. Se on myös paikka, jossa monet tekoälypilotit hiljaa menettävät sen viehätyksen, joka niillä oli huoneessa.
Pilotin ja operatiivisen toiminnan välinen kuilu ei johdu pääasiassa mallin laadusta. Se johtuu omistajuudesta. Pilotissa poikkeukset ovat kiinnostavia. Operatiivisessa toiminnassa poikkeuksiin liittyy asiakkaita, potilaita, kansalaisia, kollegoita, laskuja ja määräaikoja. Pilotissa projektitiimi seuraa tarkasti. Operatiivisessa toiminnassa järjestelmää on seurattava ihmisten, joilla on muutakin työtä tehtävänään. Pilotissa menestys tarkoittaa, että idea ansaitsee huomiota. Operatiivisessa toiminnassa menestys tarkoittaa, että organisaatio voi luottaa siihen teeskentelemättä, että todellisuudesta on tullut helpompaa.
Vastuullinen operatiivinen toiminta on tekoälypilotin aikuismuoto. Se määrittelee, kuka omistaa työnkulun, mitä toimintoja järjestelmä saa tukea, mitä näyttöä vaaditaan, miten viat havaitaan, milloin järjestelmä pysähtyy, miten ihmiset valittavat, miten muutokset hyväksytään ja miten arvoa mitataan sen jälkeen, kun uutuudenviehätys on haihtunut. Vähemmän jännittävää kuin pilotti, totta kai. Myös vähemmän todennäköisesti aikaansaa kauniisti rahoitetun sotkun.
Pilotti saa olla keskeneräinen
Hyvä pilotti on tarkoituksella keskeneräinen. Se testaa yhtä kysymystä. Pystyykö tämä malli luokittelemaan nämä asiakirjat riittävän hyvin jatkaakseen. Pystyykö tämä avustaja vähentämään luonnosteluun kuluvaa aikaa. Pystyykö tämä hakumalli tuomaan esiin olennaista näyttöä. Pystyykö tämä suunnittelutapa parantamaan aikataulua. Pilotilla on oltava rajaukset, sen on oltava riittävän nopea oppimaan ja sen on oltava rehellinen olosuhteista, joissa se toteutettiin. Sen ei pidä teeskennellä olevansa operatiivinen malli, jossa on vähemmän kokouksia.
Ongelma alkaa, kun pilottivaiheen todisteita nostetaan niiden toimivaltaa laajemmalle. Valittu tapausten joukko muuttuu todisteeksi tuotannon laadusta. Myönteiset käyttäjät muuttuvat todisteeksi käyttöönotosta. Hallitussa työnkulussa säästetty aika muuttuu liiketoimintaperusteeksi sekavalle osastolle. Toimittajan tukema integraatio muuttuu todisteeksi siitä, että sisäiset tiimit osaavat toimia. Projektitiimin päivittäin seuraama kojelauta muuttuu todisteeksi siitä, että seurantaa on olemassa. Pilotti ei valehdellut. Organisaatio ylitulkitsi.
Pilotit usein välttelevät vaikeimpia kysymyksiä, koska juuri niin pilotit etenevät nopeasti. Kuka omistaa mallin julkaisun jälkeen. Kuka päivittää kehotteen. Kuka käsittelee valituksen. Mitä tapahtuu, kun tietoja puuttuu. Mitä tapahtuu, kun malli kieltäytyy. Mitä tapauksia ei saa koskaan automatisoida. Miten poikkeama havaitaan. Miten järjestelmä pysäytetään. Mikä on palautuspolku. Mikä budjetti maksaa ylläpidon. Nämä kysymykset voivat odottaa tutkimusvaiheessa. Ne eivät voi odottaa operatiivisessa toiminnassa.
Ei ole häpeällistä, että pilotti on keskeneräinen. Häpeällistä on kutsua sitä valmiiksi, koska se oli viehättävä. Pilotti ansaitsee seuraavan vaiheen, kun se tuottaa oppimista, ei silloin, kun se tuottaa innostusta. Innostusta on helppo synnyttää hallitussa tilassa. Operatiivinen toiminta vaatii toisenlaista valuuttaa.
Sallittu käyttö on ensimmäinen operatiivinen päätös
Ennen tekoälyjärjestelmän laajentamista määrittele sallittu käyttö. Ei epämääräisellä kielellä, kuten paranna tuottavuutta tai tue päätöksentekoa. Nimeä toiminto. Laadi sisäisiä muistioita. Tiivistä todisteet käsittelyä varten. Järjestä tapaukset huomion mukaan. Ehdota reitti. Hyväksy matalan riskin tapahtuma. Hylkää pyyntö. Lähetä viesti. Jokaisella verbillä on erilaiset seuraukset. Operatiivinen toiminta ei voi ohjata sumua.
Sallitun käytön tulisi sisältää rajat. Mitä tietolähteitä saa käyttää. Mitkä tapaukset ovat soveltamisalan ulkopuolella. Mikä luottamus- tai todistekynnys vaaditaan. Mitkä toimet vaativat ihmisen hyväksynnän. Mitkä toimet ovat vain neuvoa-antavia. Mitkä tuotokset voivat poistua organisaatiosta. Mitkä käyttäjät saavat nähdä ne. Mitkä päätökset edellyttävät säilytettävää kirjausta. Raja ei ole juristinen koriste. Se on kartta, jota operaattorit käyttävät, kun järjestelmä kohtaa tapauksen, jota pilotti ei kutsunut.
Tämä on erityisen tärkeää, koska tekoälyjärjestelmät pyrkivät laajenemaan mukavuuden kautta. Sisäisiä tiivistelmiä laativa työkalu alkaa laatia asiakasvastauksia. Luokitteluun käytetty luokitin alkaa vaikuttaa kelpoisuuteen. Asiantuntijoiden käyttämä hakutyökalu alkaa vastata aloittelijoille. Englanniksi arvioitua mallia käytetään käännettyyn aineistoon. Kukaan ei välttämättä ilmoita uudesta käytöstä. Siitä vain tulee hyödyllinen uudessa paikassa. Hyödyllinen ei ole sama kuin valtuutettu.
Vastuullinen operatiivinen toiminta edellyttää käyttörekisteriä, jota todella käytetään. Sen tulisi yhdistää käyttö, seuraukset, todisteet, omistaja, valvonta, seuranta ja arviointi. Kun joku kysyy, voiko järjestelmä tukea uutta toimintoa, vastauksen tulisi tulla rekisterin ja muutosprosessin kautta, ei käytäväkeskustelun kautta määräajan kanssa.
Omistajuuden on kestettävä projektitiimiä pidempään
Pilotteja kantaa usein erityinen ihmisryhmä, joka ymmärtää kontekstin, muistaa poikkeukset ja vastaa kysymyksiin nopeasti, koska kalenterissa on vielä projektin tuoksu. Toiminta ei voi nojata siihen. Ihmiset vaihtuvat. Toimittajat lähtevät. Sponsorit siirtyvät eteenpäin. Innostunut analyytikko saa ylennyksen, mikä on ihanaa, kunnes kaikki huomaavat, että kehotekirjasto oli enimmäkseen hänen päässään.
Operatiivinen omistajuus tarvitsee rooleja, ei sankareita. Liiketoiminnan omistaja omistaa tarkoituksen ja hyväksyttävän riskin. Datan omistaja omistaa lähdelaadun, korjaukset ja alkuperän. Tekninen omistaja omistaa käyttöönoton, suorituskyvyn, tietoturvan ja integraatiot. Mallin omistaja omistaa arvioinnin, seurannan ja muutokset. Operatiivinen omistaja omistaa toimintaohjeet, tuen, häiriöiden hallinnan ja käyttäjäpalautteen. Hallinnon omistaja omistaa todisteet, tarkastelun ja sallitun käytön noudattamisen. Pienissä organisaatioissa yksi henkilö voi hoitaa useita rooleja. Roolit tarvitsevat silti nimet.
Omistajuus tarvitsee myös valtuudet. Ei riitä, että joku asetetaan vastuulliseksi, jos häneltä evätään mahdollisuus keskeyttää työnkulku, vaatia todisteita, hylätä muutos, varata ylläpitoon aikaa tai nostaa riski esiin. Se ei ole omistajuutta. Se on koristeellista syyn varastointia. Vastuullinen toiminta edellyttää valtuuksia, jotka vastaavat vastuuta.
Budjetti on osa omistajuutta. Piloteilla on usein erillinen rahoitus. Toiminta tarvitsee ylläpitorahoitusta: seurantaa, uudelleenkoulutusta tai uudelleenarviointia, tukea, käyttäjäkoulutusta, datan laadun korjauksia, tietoturvatarkastuksia, häiriöharjoituksia ja säännöllistä hallintoa. Jos liiketoimintaperustelu rahoittaa vain käynnistyksen, se ei ole toiminnan liiketoimintaperustelu. Se on juhlat, joiden laskut on piilotettu pöytäliinan alle.
Tuotantodata ei ole pilotin dataa, jossa on enemmän rivejä
Tuotantodatalla on luonne. Se saapuu myöhässä, puutteellisena, monistettuna, käännettynä, käsin korjattuna, väärin luokiteltuna, komiteoiden uudelleen nimeämänä, kannustimien muovaamana ja joskus sellaisen henkilön syöttämänä, jolla on huono päivä. Pilottien datajoukot ovat usein puhtaampia, koska joku valitsi ne, siivosi ne tai ainakin välitti niistä muutaman viikon. Ero on merkittävämpi kuin tiimit odottavat.
Dataomistajuus operatiivisessa toiminnassa on katettava ajantasaisuus, alkuperäketju, korjausoikeudet, puuttuvat tiedot, ajautuminen, pääsyoikeudet, säilytys ja johdetut tiedot. AI-järjestelmät tuottavat johdettua materiaalia: upotuksia, yhteenvetoja, pisteytyksiä, tunnisteita, ominaisuuksia, välimuisteja ja palautetta. Nämä voivat vaikuttaa tuleviin päätöksiin. Jos kukaan ei omista niitä, toimintaan syntyy toinen dataomaisuus, joka on ensimmäistä näkymättömämpi ja joskus vaikutusvaltaisempi. Erittäin tehokasta, jos tavoitteena on yllättyminen.
Operatiivisen seurannan tulisi siis tarkkailla muutakin kuin mallin tarkkuutta. Seuraa lähdetietojen ajantasaisuutta, puuttuvia kenttiä, poikkeavia jakaumia, haun kattavuutta, päällekkäisyyksiä, kielen muutoksia, käyttäjien käyttäytymistä, ohitusperusteita, valitusten lopputuloksia, viivettä ja kustannuksia. Malli voi olla teknisesti kunnossa, vaikka sen ympärillä oleva data ei enää tarkoittaisi sitä, mitä se tarkoitti pilottivaiheessa. Järjestelmä ei tiedä, että pilotti on päättynyt. Se vain vastaanottaa syötteitä.
Myös korjauspoluilla on merkitystä. Kun käyttäjä huomaa, että lähde on virheellinen, voidaanko lähde korjata. Päivittyvätkö johdetut tiedot. Näkyykö päätösrekisterissä vanha tila. Opettaako korjattu tapaus mallia tai työnkulkua. Jos korjaus muuttaa vain näkyvää rekisteriä, mutta piilotetut ominaisuudet jäävät vanhentuneiksi, toiminnasta tulee vanhojen virheiden museo, jolla on tuore maalipinta.
Seurannan on ymmärrettävä, mitä toiminta tarkoittaa
Monet AI-seurantasuunnitelmat alkavat teknisistä mittareista: käytettävyys, viive, virheprosentti, tokenien käyttö, mallin pisteytys, ajautumismittari. Nämä ovat välttämättömiä, mutta eivät riittäviä. Vastuullinen toiminta seuraa sitä toimintaa, jota järjestelmä tukee. Jos järjestelmä reitittää tapauksia, seuraa virhereitityksiä, jonovaikutuksia, asiantuntijoiden ylikuormitusta, viivästynyttä eskalaatiota ja käyttäjien ohituksia. Jos se luonnostelee vastauksia, seuraa korjaustyön määrää, asiakkaiden hämmennystä, käytäntörikkomuksia ja toistuvia muokkauksia. Jos se suosittelee päätöksiä, seuraa valituksia, kumoamisia, alaryhmien tuloksia ja näytön puutteita.
Seurannan kysymys ei ole vain se, toimiiko malli. Se on se, ansaitseeko työnkulku edelleen luottamuksen. Malli voi pysyä vakaana, kun käytäntö muuttuu. Viive voi olla erinomainen, kun näytön laatu heikkenee. Tarkkuus voi olla keskimäärin korkea, kun yksi tapaustyyppi romahtaa. Kustannukset voivat laskea, kun uudelleentyö kasvaa muualla. Seuranta, joka näkee vain komponentin, jättää huomaamatta toiminnassa elävät viat.
Operatiivinen seuranta tarvitsee myös kynnysarvoja ja omistajia. Ketä hälytetään, kun lähdetietojen ajantasaisuus pettää. Mitä tapahtuu, jos ohitusprosentit nousevat. Mikä ajautumistaso käynnistää tarkistuksen. Mikä valituskuvio pysäyttää automatisoinnin. Mikä kustannusten nousu vaatii arkkitehtuurikatselmoinnin. Mikä häiriön vakavuus vaatii viestintää asianomaisille. Hallintapaneeli ilman toimintasääntöjä on maalaus numeroilla.
Parhaat seurantaketjut sisältävät käyttäjät. Käyttäjät tietävät, milloin järjestelmä tekee väärästä asiasta helppoa, milloin selitys on hyödytön, milloin uusi tapaustyyppi ilmestyy tai milloin työnkulkua pelataan. Kerää palautetta lähellä työtä. Käsittele sitä operatiivisena signaalina, ei tunnelmana. Ihmiset, jotka ovat lähimpänä työtä, ovat usein ensimmäisiä ajautumisen havaitsijoita, vaikka he harvoin saavat siitä tittelin.
Poikkeamiin vastaaminen ei ole valinnaista, vaikka malli olisi älykäs
Tekoälypoikkeamat eivät aina ole räjähdyksiä. Ne voivat olla hiljaisia: väärät yhteenvedot toistuvat viikon ajan, hakemisto ei löydä tiettyä asiakirjaluokkaa, luokittelija ajautuu yhdellä alueella, käyttäjän kehotteen muutos muuttaa säänneltyjen vastausten sävyä, malli kieltäytyy liian harvoin, malli kieltäytyy liian usein, jono täyttyy reunatapauksista, joita kukaan ei omista. Hiljaiset poikkeamat ovat silti poikkeamia, jos ne vaikuttavat ihmisiin tai velvoitteisiin.
Operatiiviseen valmiuteen kuuluvat poikkeamakäsikirjat. Mikä lasketaan tekoälypoikkeamaksi. Kuka voi julistaa sellaisen. Miten järjestelmä pysäytetään. Mikä näyttö säilytetään. Mitkä päätökset vaativat arvioinnin. Mitkä käyttäjät informoidaan. Mikä toimittajan käyttöoikeus tarvitaan ja miten sitä rajataan. Miten palautus tehdään. Miten asianosaisiin otetaan yhteyttä. Miten poikkeama suljetaan. Jos vastaus on, että kootaan tiimi, tiimi on jo myöhässä.
Toimintaohjeita pitää harjoitella. Palautussuunnitelma, jota ei ole koskaan toteutettu, on toivomusasiakirja. Mallin palautus, jota kukaan ei ole kokeillut, on koristeellinen hätäuloskäynti. Valitusprosessi, joka ei pysty hakemaan asiaankuuluvaa päätöskirjausta, on teatteria. Harjoitukset paljastavat tylsät ongelmat ennen kuin niistä tulee julkisia: puuttuvat käyttöoikeudet, epäselvät omistajat, vanhentunut dokumentaatio, kojelaudat, joihin kukaan ei pääse, ja yksi korvaamaton henkilö lomalla Frieslandissa erinomaisin rajoin.
Poikkeuksen jälkeisen arvioinnin pitäisi keskittyä järjestelmän oppimiseen. Minkä vaaran missasimme. Mikä signaali jätettiin huomiotta. Mikä hallintakeino petti. Mikä inhimillinen kiertotapa esti asioita pahenemasta. Mikä mittari piilotti ongelman. Mikä päätöskirjaus oli puutteellinen. Mikä muutos tarvitaan. Lähimmän operaattorin syyttäminen on emotionaalisesti tehokasta ja operatiivisesti heikkoa. Poikkeamat ovat kalliita opettajia. Lue ainakin oppitunti.
Muutoksenhallinta on se paikka, jossa piloteista tulee vakavia
Tekoälyjärjestelmät muuttuvat usein. Mallit päivittyvät. Kehotteet muuttuvat. Hakulähteet laajenevat. Käytännöt liikkuvat. Käyttäjät sopeutuvat. Dataputket muuttuvat. Toimittajan komponentit kehittyvät. Pilotti voi sietää muutosta tarkalla huomiolla. Operatiivinen toiminta tarvitsee muutoksenhallintaa. Ei byrokraattista suota, vaan kurinalaisen polun, joka kysyy, mihin muutos vaikuttaa ja miten organisaatio tietää, jos se menee pieleen.
Jokaisen merkittävän muutoksen yhteydessä on nimettävä vaikutusalue, näyttö, testit, palautus, viestintä ja omistaja. Vähäriskisen luonnostelun kehote-muutos voi vaatia nopean tarkistuksen ja otannan. Kelpoisuussuositusten mallimuutos voi vaatia arviointiosioita, varjokokeen, hyväksynnän, päätöstietueen yhteensopivuuden ja palautuskriteerit. Uusi tietolähde voi vaatia alkuperän tarkastelun, tietosuoja-arvion ja tuoreuden seurannan. Oikeasuhtaisuus on tärkeää. Samoin on tärkeää olla teeskentelemättä, että kaikki muutokset ovat pieniä, koska tekstimuokkaus näytti pieneltä.
Versiointi on ratkaisevan tärkeää. Päätösten tulisi tietää, minkä mallin, kehotteen, tietolähteen, käytännön, kynnyksen ja rajapinnan versio on vaikuttanut niihin. Ilman versiointia organisaatio ei voi selittää, miksi yksi tapaus käyttäytyi eri tavalla kuin toinen. Se ei voi tutkia ajautumista puhtaasti. Se ei voi palauttaa luottavaisesti. Versiointi ei ole glamour-työtä. Se on lanka, jonka avulla toiminnot voivat purkaa neuleen ilman, että väittävät neuletta huiviksi.
Muutostenhallinta estää myös laajuuden kasvamisen. Jos tiimi haluaa käyttää järjestelmää uuteen toimintoon, muutospolun tulisi kysyä, pätevätkö olemassa oleva arviointi, kontrollit, näyttö ja omistajuus edelleen. Usein ne eivät päde. Se ei tarkoita ei koskaan. Se tarkoittaa ei vahingossa.
Arvoa on mitattava aplodien jälkeen
Pilottihankkeet mittaavat usein arvoa siellä, missä se on helpointa nähdä: säästetty aika, parantunut tarkkuus, löydetyt asiakirjat, tuotetut luonnokset, tyytyväiset käyttäjät. Toimintojen on mitattava arvoa aplodien jälkeen. Vähenikö uudelleentyö. Parantuiko laatu vaikeissa tapauksissa. Tuliko henkilöstön kuormituksesta kestävää. Saitko käyttäjät selkeämpää palvelua. Muuttuivatko valitukset. Siirtyivätkö kustannukset vai vain liikkuivatko ne. Vähensikö järjestelmä riskiä vai piilottiko se sen. Tuliko päätöksistä helpompia selittää.
Säästetty aika on erityisen petollista. Jos työkalu säästää kymmenen minuuttia luonnostelussa, mutta lisää kahdeksan minuuttia tarkistusta, kaksi minuuttia korjausta ja myöhemmin uudelleen avatun tapauksen, arvo ei ole kymmenen minuuttia. Jos se säästää asiantuntijoiden aikaa siirtämällä työtä nuoremmalle henkilöstölle, arvo voi olla henkilöstöharha. Jos se nopeuttaa helppoja tapauksia mutta huonontaa reunatapauksia, keskiarvo voi parantua ja toiminta voi muuttua epäoikeudenmukaisemmaksi. Arvo vaatii koko työnkulun tarkastelun.
Arvo sisältää myös vältetyn haitan. Kieltäytyminen, joka estää huonon päätöksen, on arvokasta. Seurantahälytys, joka havaitsee ajautumisen, on arvokas. Päätöstietue, joka ratkaisee valituksen nopeasti, on arvokas. Palautuspolku, joka rajoittaa häiriön, on arvokas. Näitä hyötyjä on vaikeampi asettaa pilottikalvolle, koska ne näyttävät asioilta, joita ei tapahtunut. Toimintojen tulisi silti laskea ne. Vakavat järjestelmät osoittavat usein arvonsa tekemällä tylsistä viikoista todennäköisempiä.
Taloudellisen omistajuuden tulisi kuvastaa kokonaiskuvaa. Jos automaatio säästää yhden tiimin aikaa ja luo tarkistuskuormaa toiselle, liiketoimintatapauksen tulisi osoittaa molemmat. Jos ylläpito ehkäisee tulevia häiriöitä, budjetin ei tulisi kohdella ylläpitoa valinnaisena koristeena. Vastuullinen toiminta vaatii kirjanpitoa, joka seuraa työtä, ei vain projektikoodia.
Käyttökatselmus
Ennen kuin pilotti siirtyy tuotantoon, pidetään käyttökatselmus. Asialistan tulisi olla käytännönläheinen. Mikä tarkka käyttötarkoitus on hyväksytty. Kuka omistaa kunkin kerroksen. Mitkä tietolähteet ovat soveltamisalassa. Mitkä päätökset vaativat kirjauksia. Mitkä tulokset ovat neuvoa-antavia. Mitkä tapaukset on rajattu pois. Mitkä hallintatoimet pysäyttävät vaarallisen toiminnan. Mitkä mittarit ovat olennaisia. Mitkä kynnysarvot käynnistävät tarkastelun. Ketkä on koulutettu. Mitkä toimintaohjeet ovat olemassa. Mikä peruutus on testattu. Mikä budjetti rahoittaa ylläpidon.
Tähän katselmukseen tulisi osallistua työn lähellä olevia ihmisiä. Käyttäjiä, tukipalvelua, alan asiantuntijoita, riskinomistajia, datan omistajia, tietoturvaa, lakiasioita ja tarvittaessa vaikuttavien käyttäjien edustajia. Tavoitteena ei ole luoda väkijoukkoa. Tavoitteena on estää projektitiimiä luulemasta omaa tarkkaavaisuuttaan toimintamalliksi. Ihmiset, jotka elävät järjestelmän kanssa, tietävät kysymyksiä, joita pilottitiimi ei tiennyt kysyä.
Katselmuksessa saa sanoa, ettei olla valmiita. Ei rangaistuksena, vaan hyödyllisenä tilana. Ehkä datan korjauspolku puuttuu. Ehkä todistekirjaukset ovat puutteellisia. Ehkä ihmisen tekemä tarkistus on liian hidasta. Ehkä sallittu käyttö on epämääräistä. Ehkä seuranta tarkkailee vääriä asioita. Ehkä arvolaskelma jättää korjaustyön huomiotta. Ei valmiita on halvempaa ennen käynnistystä kuin sen jälkeen, kun institutionaalinen riippuvuus on muodostunut.
Kun katselmus sanoo valmis, sen tulisi sanoa, mihin valmis. Valmis neuvoa-antavaan käyttöön yhdessä työnkulussa. Valmis rajoitettuun tuotantoon otannalla. Valmis automatisoituun toimintaan seurausten kynnysarvon alapuolella. Valmis laajempaan käyttöönottoon kahden kuukauden seurannan jälkeen. Valmius ei ole mitali. Se on käyttöön liitetty ehto.
Opinkappale
Siirtyminen tekoälypiloteista vastuulliseen toimintaan ei ole tekninen käyttöönottovaihe. Se on vastuun siirto. Kysymys muuttuu muodosta voiko tämä toimia muotoon voimmeko omistaa tämän silloin, kun se toimii, kun se epäonnistuu, kun se muuttuu, kun ihmiset luottavat siihen ja kun joku pyytää meitä selittämään sen. Se on paljon parempi kysymys ja vähemmän mukava.
Pilotit ovat edelleen arvokkaita. Ne auttavat organisaatioita oppimaan nopeasti ja halvalla. Ne paljastavat potentiaalia. Ne vähentävät abstraktia väittelyä. Ne auttavat tiimejä löytämään, mitä malli, työnkulku tai käyttöliittymä voisi tehdä. Mutta pilotti ei ole todiste toiminnallisesta vastuusta. Se on kutsu suunnitella se.
Vastuullinen toiminta edellyttää sallittua käyttöä, omistajuutta, datan hallintaa, seurantaa, poikkeamiin reagointia, muutostenhallintaa, todisteaineistoja, käyttäjäpalautetta, budjettia ja arvon mittaamista koko työnkulun ajalta. Se edellyttää ihmisiä, jotka voivat pysäyttää, korjata, selittää ja parantaa. Se edellyttää hallintoa, joka toimii myös silloin, kun kukaan ei taputa.
Maanantai tulee. Se tulee aina. Kysymys on siitä, saapuuko tekoälyjärjestelmä maanantaina menestyneenä pilottina fanikerhon kanssa vai vastuullisena toimintona, jolla on tehtävä.