Ajatusjohtajat

Ihminen silmän alla ei ole hallintoa

mm
Lisää Unite.AI suosikkilähteisiisi Google-palvelussa

Ilmeinen vastaus AI-riskeihin on “laittaa ihminen silmän alle.” Mutta tämä lause piilottaa vaikean osan.

Ihminen silmän alla toimii vain, jos silmä on suunniteltu. Muuten ihminen muuttuu kolmenlaisiksi virheiksi:

  • Pullonkaulaksi, koska AI-virheen tarkastelu kestää yhtä kauan kuin työn tekeminen käsin.
  • Gummitarraksi, koska tarkastaja on ylikuormittunut, ei voi nähdä todisteita, ei ymmärrä liiketoimintayhteyksiä ja hyväksyy työn vain jatkaakseen jonon liikkeessä.
  • Tai kolmas virhe: rypistysvyöhyke. Laittamalla ihminen silmän alle, laitos nimeää vastuullisen henkilön, mutta antaa hänelle mitään valtaa, aikaa, valtuuksia, mahdollisuuksia pysäyttää järjestelmää tai muuttaa seuraavaa suoritusta. Seuraus kuormittaa ihmistä, kun taas päätösten perusta pysyy muuttumattomana.

Tässä kohtaa suurin osa yritysten AI-keskusteluista menee pieleen. Puhumme siitä, pitäisikö ihmisen tarkastaa työtä, mutta emme puhu siitä, miten tarkastus on suunniteltu. Oletamme, että ihmisen lisääminen luo hallinnon. Se ei kuitenkaan tee sitä. Hallinto edellyttää sitä, että tarkastaja on merkityksellinen valvonta, näkyvyys ja mahdollisuus parantaa järjestelmää päätöksen jälkeen.

Ihmisten tarkastus on arvokasta, mutta vain silloin, kun se on sijoitettu sellaiseen kohtaan, jossa tuomio on merkityksellistä ja tuetaan riittävällä asiayhteydellä.

Validointivaihe on enemmän kuin tarkastusvaihe

Vaihe ei ole pelkästään keskeytysnappi. Se on vahvistusliittymä.

Kun agentti tai automaatio tuottaa ehdotuksen – luonnoksen, suositellun toimen, luokittelun, maksuvahvistuksen, asiakirjan, palautuspyynnön tai kieltämis kirjeen – tarkastajan tulisi heti ymmärtää, mitä tapahtuu ja miksi.

Oikea validointivaihe on näyttää, mitä on merkityksellistä: ehdotettu toimenpide; taustat; tarkastetut säännöt; liiketoimintasiirtymä, joka tapahtuu; valtuutus, jota käytetään; kirjattu audit-tiedosto; epävarmuus tai poikkeus, joka laukaisi tarkastuksen; ja saatavilla olevat valinnat: hyväksy, muokkaa, hylkää tai eskaloita.

Kunkin näistä elementeistä on olemassa jokin syy. Ehdotettu toimenpide selittää, mitä järjestelmä aikoo tehdä. Taustatiedot selittävät, miksi. Säännöt ja valtuutus osoittavat, sopiiko suositus organisaation politiikkaan. Epävarmuus kertoo tarkastajalle, miksi työ päätyi ihmisen silmän alle ensinnäkin. Yhdessä ne muuttavat tarkastuksen arvaamisesta vahvistukseksi.

Jos tarkastajan on rakennettava kaikki tämä manuaalisesti, portti ei ole rakennettu.

Portin tarkoitus ei ole ainoastaan estää virheitä ennen kuin ne tapahtuvat. Sen toinen tarkoitus on tärkeämpi. Se kaappaa institutionaalisen tuomion.

Tässä yritysten käyttöönotto alkaa kerryttää. Jokainen oikea hyväksyntä, muokkaus, hylkäys tai eskaloituneiden päätösten kaappaa institutionaalisen tuomion – mutta vain, jos portti kaappaa sen, miksi.

Hyväksymiset eivät ole dataa, vaan vahvistukset ovat.

Gummitarraksen leimaus ei kaappaakaan mitään hyödyllistä. Tarkastettu, muokattu, hylätty tai eskaloitunut päätös, jossa on syykoodi, kaappaa signaalin, jonka seuraava järjestelmäversio voi oppia. Jos tarkastaja hyväksyy ilman tarkastelua, järjestelmä ei opi mitään. Jos tarkastaja muokkaa, hylkää, eskaloittaa ja antaa syyn, instituutio kaappaa tuomion.

Näiden tuomioiden myötä instituutio oppii, missä kohdissa politiikat ovat epäselviä, missä työnkulut murtuvat jatkuvasti, missä poikkeukset tapahtuvat useimmin ja missä automaatio tulisi olla luottavaisempi – tai rajoitettu. Tavoitteena ei ole ainoastaan automatisoida enemmän työtä, vaan parantaa tulevien päätösten laatua kaappaamalla, miten kokeneet ihmiset harjoittavat tuomiovaltaa tänään.

Vastuu edellyttää enemmän kuin nimeämisen

Tämä ero muuttaa sitä, miten organisaatiot tulisi ajatella vastuusta.

Portti ei ole tarpeeksi. Nimeämisen ei ole tarpeeksi. Audit-loki ei ole tarpeeksi.

Vastuu edellyttää seuraamusta: virheen on oltava jossakin, joka voi muuttaa tulevaa käyttäytymistä.

Ennen kuin yritys ottaa AI:n käyttöön, se tulisi kysyä itseltään viisi kysymystä:

  1. Kuka vastaan virheen, jos tämä toimenpide on väärä?
  2. Oliko vastuullisella henkilöllä tai järjestelmällä merkityksellistä valtaa ennen toimenpidettä?
  3. Voiko vastuullinen omistaja tarkastaa, rajoittaa, ohittaa tai pysäyttää agentin tai automaation?
  4. Onko vastuun omistajan vastuu suhteessa siihen valtaan, jota hänellä todella oli?
  5. Mitä muuttuu ennen seuraavaa suoritusta: taito, sääntö, valtuutus, työnkulku, automaatio, validointivaihe, syykoodi, koulutus tai luottamuksen luokka?

Ihminen portissa ilman merkityksellistä valtaa ei ole hallintoa. Se on rypistysvyöhyke.

Silmä ei ole suljettu, kunnes kaapattu tuomio muuttaa jotakin: taitoa, sääntöä, valtuutusta, eskaloitumiskynnystä, automaatiota, testiä, tarkastusliittymää, koulutussuunnitelmaa, auditinäytettä tai luottamuksen luokkaa. Seuraus, joka ei muuta seuraavaa suoritusta, on vain tapaus, ei oppimista. Organisaatiot paranevat, kun jokainen merkityksellinen tarkastus muuttaa järjestelmän seuraavaa versiota, olipa se sääntöjen tarkennusta, valtuuksien kiristämistä, automaation parantamista tai vahvistuskokemuksen vahvistamista itsessään.

Suojavarustukset estävät virheitä. Arviot rakentavat luottamusta.

Organisaatioiden on myös erottava suojavarustukset ja arvioinnit. Ne ratkaisevat erilaisia ongelmia, joille on ratkaisuja.

  1. Suojavarustukset pakottavat käyttäytymistä suoritusaikana. Schematarkastukset, epäturvallisten parametrejen esto, valtuutustarkastukset, PII-poisto, kehotuspuolustus ja työkalun käytön rajoitukset ovat olemassa estämään vaarallista käyttäytymistä ennen kuin se tapahtuu.
  2. Arvioinnit mitattavat suorituskykyä ajan myötä. Ne tarkastelevat laatua, aikaa, työkalun valintaa, eskaloitumisen laatua, kustannuksia, viivettä ja sääntöjen noudattamista. Ne kertovat organisaatiolle, onko järjestelmä edelleen luotettava.

Yksi suojelee nykyistä päätöstä. Toinen parantaa tulevia päätöksiä.

Suojavarustukset ja arvioinnit palvelevat eri tarkoituksia, ja niin tekevät myös niistä vastuussa olevat ihmiset. Alusta pakottaa sääntöjä. Toimijat arvioivat tuloksia. Yhdessä he luovat palautekehän, joka sallii järjestelmän parantaa ilman hallinnon uhraamista.

Järjestelmä hakee sääntöjä, vaatimusten kirjaa, tukidokumentteja, aiempia tapauksia ja organisaation pelikirjaa. Se valmistaa triage-paketin, ehdottaa vakavuutta, tunnistaa puuttuvat todisteet ja avaa petosalitapauksen, jos säännöt vaativat sitä. Sovittaja näkee ehdotetun liikkeen, tukitodisteet, syykoodin, audit-merkinnän ja hyväksymisen seuraamuksen. Sen sijaan, että sovittaja joutuisi rakentamaan tapauksen useista järjestelmistä, tarkastaja voi keskittyä itse ehdotuksen vahvistamiseen. Vain vahvistuksen jälkeen automaatio päivittää tapausta, lähettää maksun, pyytää lisäasiakirjoja tai sulkee työn.

Vahinko-työnkulku osoittaa, miten tämä toimii käytännössä. Agentti ei muistanut prosessia. Se toimi julkaistun kartan sisällä.

Arkkitehtuuri tulisi seurata työtä

Sama periaate pätee riippumatta siitä, miten työ on järjestetty. Kaikki yritysten ongelmat eivät ole samanmuotoisia, ja hallinto tulisi heijastaa sitä. Jotkut työt alkavat tavoitteesta. Jotkut alkavat tapauksesta; jotkut alkavat vakaasta työnkulusta. Arkkitehtuuri tulisi seurata työtä, ei toisinpäin.

Tavoitteellinen käyttöönotto alkaa tuloksesta eikä määrätystä polusta. Ratkaise tämä asiakkaan eskaloitunut ongelma. Vähennä asiakkaan churn-riskiä. Tutki tämä petostunniste. Valmistele tämä uudistamissuunnitelma. Kohde on selvä, mutta reitti voi muuttua, kun uutta tietoa tulee saataville. Pääagentti hajottaa työn, käyttää hyväksyttyjä agenteja ja työkaluja, kutsuu hyväksyttyjä automaatioita ja määrittää ihmistyön hallitun rajojen sisällä. Sen vahvuus on sopeutumiskyky. Sen riski on, että sopeutumiskyky ilman selkeää rajoitusta muuttuu ennakoiduksi.

Siksi joustavat järjestelmät vaativat vahvempaa hallintoa, ei vähempää. Selkeät työnkulun rajoitukset, automaation valtuudet, päätösoikeudet, audit-merkinnät ja eskaloitumissäännöt tulevat tärkeämmiksi, mitä enemmän AI:ta käytetään. Mitä enemmän agentilla on vapautta määritellä oma polkunsa, sitä tarkemmin instituutio on määriteltävä rajoitukset, joissa se voi toimia.

Yritysten AI ei onnistu, koska jokaisessa päätöksessä on jossakin vaiheessa ihminen mukana.

Se onnistuu, koska instituutiot oppivat rakentamaan silmän itse.

Daniel Dines on UiPathin (NYSE: PATH) perustaja ja toimitusjohtaja, joka on maailmanlaajuinen liiketoimintakoordinoinnin ja automaation johtaja. Dines on toiminut myös yhtiön innovaatiojohtajana. Dines perusti UiPathin vuonna 2005 tavoitteenaan luoda yhtiö, joka auttaa ihmisiä vähentämään aikaa ja stressiä, jotka johtuvat arkisista ja toistuvista tehtävistä. UiPath laajentaa perustaaan maailman johtavana automaatiolaitteistona ja tavoittelee agenteille suunnattujen automaatiopalvelujen johtajuutta kehittämällä älyteknologiaa, joka heijastaa ihmisen älykkyyttä jatkuvasti kasvavan monimutkaisuuden kanssa, muuttaen siten, miten yritykset toimivat, innovoivat ja kilpailevat. Turvallisuuden, tarkin ja joustavuuden takaamiseksi UiPath on sitoutunut muokkaamaan maailmaa, jossa älykkyys parantaa ihmisen potentiaalia ja vallankumouksellistaa teollisuutta.