Kun malli on väärässä, kuka saa pysäyttää sen?

Ihmisen valvonta ei tarkoita, että joku seisoo mallin vieressä. Se on auktoriteetti, todiste ja turvallinen tila, joiden avulla joku voi hylätä tuotoksen,...

Kun malli on väärässä, kuka saa pysäyttää sen?

Euroopan unionin tekoälysäädös käyttää yllättävän fyysistä sanaa digitaalisesta velvoitteesta. 14 artiklan mukaan henkilöiden, joiden tehtäväksi on annettu korkean riskin tekoälyjärjestelmän valvonta, on voitava puuttua toimintaan tai keskeyttää järjestelmä pysäytyspainikkeella tai vastaavalla menettelyllä, joka mahdollistaa järjestelmän pysäyttämisen turvalliseen tilaan. Lause koskee ohjelmistoa. Se vaikuttaa siltä, että joku on järkevästi muistanut, että koneet voidaan kytkeä pois päältä.

Tämä muistikuva on tärkeämpi kuin miltä se kuulostaa. Monissa organisaatioissa ihmisen suorittama valvonta tulkitaan henkilön läsnäoloksi jossakin järjestelmän läheisyydessä. Arvioija saa suosituksen. Käyttäjä voi avata kojelaudan. Esimies on nimetty käytäntöasiakirjaan. Valituksia varten on olemassa tukiosoite. Järjestelyä kutsutaan sitten ihmisen silmukassa -malliksi, ikään kuin ihminen olisi asetettu silmukan sisään ja silmukka olisi tämän seurauksena tullut viisaaksi.

Oikea kysymys on vaikeampi ja hyödyllisempi: kun malli on väärässä, epävarma, käyttötarkoituksensa ulkopuolella tai käyttäytyy tavalla, jota näyttö ei tue, kenellä on valtuudet pysäyttää työ? Kuka voi keskeyttää uudet toimet odottamatta toimittajaa? Kuka voi estää jo tuotettuja tulosteita muuttumasta päätöksiksi? Kuka voi säilyttää tutkittavan tilan? Kuka voi avata reitin uudelleen ja minkä näytön perusteella? Henkilö, joka huomaa ongelman mutta ei voi muuttaa järjestelmää, on todistaja. Henkilö, joka voi napsauttaa painiketta mutta ei tiedä, mitä painike pysäyttää, käyttää rekvisiittaa.

Siksi oikeus pysäyttää on suunniteltava ennen käyttöönottoa. Siihen tarvitaan nimetty rooli, soveltamisala, turvallinen tila, näyttöpolku, eskalaatioreitti ja tapa palata käyttöön siten, että sama vika ei huomaamatta toistu. Siihen tarvitaan riittävästi teknisiä yksityiskohtia, jotta se toimii silloin, kun järjestelmä on kiireinen, toimittaja ei ole tavoitettavissa ja alkuperäisen työnkulun rakentaja on siirtynyt toiseen projektiin. Siihen tarvitaan myös riittävää institutionaalista selkeyttä, jotta henkilö voi käyttää valtuuttaan joutumatta syytetyksi innovaation keskeyttämisestä.

Pysäytys on kyvykkyys, ei kohteliaisuus

Pysäyttäminen kuvataan usein viimeiseksi keinoksi, mikä antaa sille valitettavan seremoniallisen luonteen. Organisaatio lupaa, että joku voi pysäyttää järjestelmän, jos olosuhteet muuttuvat riittävän vakaviksi. Olosuhteet saapuvat. Henkilö etsii valtuutta. Valtuus osoittautuu dokumentin kappaleeksi, toisen tiimin hallussa olevaksi oikeudeksi tai eskalaatio-osoitteeksi, jota seurataan toimistoaikoina. Järjestelmä jatkaa toimintaansa hyvin kohteliaasti.

Pysäytys ei ole mielentila. Se on kyvykkyys, jolla on käyttöliittymä ja sopimus. Käyttöliittymä voi olla painike, komento, käytäntöportti, peruutettu tunnus, poistettu reitti, jonon pito tai hallittu sammutus. Sopimus kertoo, mitä toiminto tekee, mitä se ei tee, mikä työ estetään, minkä työn annetaan päättyä, mikä tila säilytetään, kenelle ilmoitetaan ja miten organisaatio tietää, että pysäytys on tapahtunut. Jos näihin kysymyksiin ei ole vastauksia, sana pysäytys tarkoittaa vain sitä, että kaikki ovat yhtä mieltä siitä, että pysäyttäminen olisi mukavaa.

Mallin pysäyttämisen ja seurauksen pysäyttämisen välillä on hyödyllinen ero. Malli voi olla käynnissä, kun sen tulosteet pidetään tarkistettavina. Palvelu voi pysyä saatavilla vähäriskistä luonnostelua varten, kun sen suositusreitti on suljettu. Työkalu voi palauttaa vain luku -tietoja, kun kirjoitusoikeus on peruutettu. Työnkulku voi ottaa vastaan uusia tapauksia mutta kieltäytyä siirtämästä niitä ulkoiseen päätöksentekoon. Nämä ovat erilaisia hallintapintoja. Kun niitä käsitellään yhtenä suurena punaisena kytkimenä, joko pysäytetään liian vähän tai tuhotaan enemmän työtä kuin on tarpeen.

Suhteellisuus on tärkeää, mutta suhteellisuus ei ole lupa tehdä pysäytyksestä epämääräinen. Vähäriskisessä avustajassa voi riittää paikallinen kieltäytyminen ja reitti ihmiselle. Suuririskisellä alalla käytettävässä järjestelmässä voi olla tarpeen kova este ennen kuin tuotos voi vaikuttaa henkilön oikeuksiin tai pääsyyn palveluun. Autonominen työkalu, joka voi muuttaa ulkoista tietuetta, voi tarvita erillisen interventiopolun verrattuna malliin, joka vain kirjoittaa luonnoksen. Riski, autonomian aste ja käyttökonteksti määräävät kontrollin vahvuuden. Ne eivät poista kontrollin tarvetta.

AI-asetuksen kieli on hyödyllistä juuri siksi, että se yhdistää ihmisen valvonnan todelliseen riskitavoitteeseen. Valvonnan tarkoitus on ehkäistä tai minimoida riskejä terveydelle, turvallisuudelle ja perusoikeuksille. Sen tehtävä ei ole koristella järjestelmää ihmisen hahmolla. Jos nimetty henkilö ei pysty tunnistamaan poikkeamaa, tulkitsemaan tuotosta, ohittamaan sitä tai pysäyttämään toimintaa turvallisesti, järjestely ei ole täyttänyt valvonnan käytännön tarkoitusta riippumatta siitä, kuinka monta allekirjoitusta projektitiedostossa on.

Lue 14 artikla teknisenä spesifikaationa

14 artikla koskee suuren riskin tekoälyjärjestelmiä, ei jokaista ohjelmistoa, joka on saanut tekoälytarransa. Sen ensimmäinen vaatimus on, että järjestelmä suunnitellaan ja kehitetään siten, että luonnolliset henkilöt voivat valvoa sitä tehokkaasti sen ollessa käytössä. Ilmaus sen ollessa käytössä on merkityksellinen. Hankinnan yhteydessä tehty tarkastus ei ole käytössä olevan järjestelmän valvontaa. Ennen käyttöönottoa pidetty koulutus ei ole muuttuneen mallin valvontaa. Jälkikäteen annettu selitys tapahtuneesta ei korvaa kontrollia, joka olisi voinut estää toiminnan.

Toinen vaatimus antaa valvonnalle tarkoituksen. Sen pitäisi ehkäistä tai minimoida riskejä, joita syntyy, kun järjestelmää käytetään sen aiottuun tarkoitukseen tai kohtuullisesti ennakoitavissa olevan väärinkäytön vallitessa. Tämä sanamuoto vastustaa kätevää temppua, jossa organisaatio kohtelee jokaista haitallista käyttöä ennakoimattomana yllätyksenä. Ihmiset käyttävät järjestelmiä paineen alla, puutteellisten tietojen varassa, käännösten kautta, epätavallisissa yhdistelmissä ja ohjeidensa rajoilla. Vakava suunnittelu kysyy, mikä väärinkäyttö on kohtuullisesti ennakoitavissa, ja antaa arvioijalle keinon reagoida ennen kuin tuotos saa institutionaalisen painoarvon.

Kolmas vaatimus tekee valvonnasta oikeassa suhteessa riskiin, autonomiaan ja kontekstiin. Tarjoaja voi rakentaa toimenpiteitä järjestelmään ja voi myös määritellä toimenpiteitä, jotka käyttöönotajan on toteutettava. Tämä on työnjako, ei vastuunjako. Tarjoaja ei voi luovuttaa järjestelmää ilman toimivaa keskeytystapaa ja osoittaa sormella käyttöönotajaa. Käyttöönotaja ei voi sivuuttaa toimitettuja rajoituksia ja väittää, että tarjoaja lupasi turvallisuutta abstraktilla tasolla. Kontrollin on säilyttävä toimitetun asian ja sen käyttötavan välisellä rajapinnalla.

Neljäs kohta on se, jossa oikeudellinen kieli muuttuu käytännön tarkistuslistaksi. Valvontaan määrättyjen henkilöiden on kyettävä ymmärtämään järjestelmän olennaiset ominaisuudet ja rajoitukset. Heidän on kyettävä seuraamaan sitä, myös poikkeamien, toimintahäiriöiden ja odottamattoman suorituskyvyn osalta. Heidän on oltava tietoisia automaatioharhasta eli taipumuksesta luottaa tai yliluottaa koneen tuotokseen. Heidän on kyettävä tulkitsemaan tuotos. Heidän on kyettävä päättämään olla käyttämättä sitä, jättää se huomiotta, ohittaa se tai kumota se. Lopuksi heidän on kyettävä puuttumaan toimintaan tai keskeyttämään se pysäytyspainikkeella tai vastaavalla menettelyllä, joka saattaa sen turvalliseen tilaan.

Jokainen verbi luo erilaisen suunnitteluvelvoitteen. Ymmärtäminen edellyttää käyttökelpoista tietoa soveltamisalasta ja rajoituksista. Valvonta edellyttää signaaleja, aikaa ja polkua niiden tarkasteluun. Automatisointiharhan tiedostaminen edellyttää koulutusta ja käyttöliittymää, joka ei muuta suositusta oletusarvoiseksi päätökseksi. Tulkinta edellyttää näyttöä ja asiayhteyttä. Ohittaminen edellyttää toimivaltaa ja kirjausta eriävästä kannasta. Keskeyttäminen edellyttää tilasiirtymää, joka on turvallisempi kuin jatkaminen. Yksi vihreä kojelauta ei voi täyttää viittä eri verbiä pelkällä koollaan.

Asetukseen sisältyy myös tarkempi sääntö tietyistä korkean riskin biometrisistä tunnistusjärjestelmistä. Säännöksen kattamissa tapauksissa päätöstä ei saa tehdä tunnistustuloksen perusteella, elleivät vähintään kaksi pätevää, koulutettua ja valtuutettua luonnollista henkilöä ole erikseen varmistaneet ja vahvistaneet tulosta, jollei säädetyistä poikkeuksista muuta johdu. Tämä on konkreettinen eurooppalainen esimerkki siitä, että valvonta ilmaistaan riippumattomana toimivaltana eikä yksinäisenä tarkastajana, joka klikkaa suosituksen läpi. Se osoittaa myös, miksi suunnittelussa on nimettävä päätöksen tyyppi ja sen edellyttämä näyttö.

14 artikla ei määrää yhtä yleispätevää henkilöstömallia. Se antaa rajan. Henkilöllä on oltava riittävä pätevyys, koulutus ja toimivalta tehtävän hoitamiseen. Tarjoajan ja käyttöönottajan on suhteutettava valvonta järjestelmään. Organisaation on edelleen päätettävä, mitkä roolit suorittavat mitkä toimet, milloin pysäytys on pakollinen, miten keskeytetty tapaus käsitellään ja mitä pidetään turvallisena jatkamisena. Laki voi vaatia oven. Se ei voi valita henkilöä, jolla on avain jokaiseen rakennukseen.

Pysäyttäminen ei ole hallinnan loppu. Se on siirtymä, joka mahdollistaa tutkinnan, korjaamisen ja puolustettavan jatkamisen.

Viisi valtaa sanan valvonta takana

On hyödyllistä käydä 14 artiklan viisi käytännön valtaa läpi yksi kerrallaan. Ensimmäinen on ymmärtäminen. Valvontarooli ei voi toimia iskulauseen varassa, kuten malli on yleensä tarkka. Rooli edellyttää käyttötarkoitusta, tunnetut rajoitukset, syöttöehdot, olennaisen suorituskykynäytön, vikatilat, päivityskäytännön ja tuloksen merkityksen varsinaisessa työnkulussa. Ymmärtäminen ei ole sama asia kuin mallikortin lukeminen. Se on kyky tunnistaa, milloin elävä tapaus jää niiden ehtojen ulkopuolelle, joissa järjestelmä on arvioitu.

Toinen on valvonta. Valvonta typistyy usein käytettävyyteen, viiveeseen ja mallin pisteytykseen. Nämä mittarit ovat tärkeitä, mutta palvelu voi olla käytettävissä ja silti väärässä. Malli voi säilyttää keskimääräisen suorituskykynsä, vaikka lähdekokoelma vanhenee, kielijakauma muuttuu, politiikan määräaika umpeutuu tai alavirran tiimi alkaa käyttää suositusta automaattisena päätöksenä. Operatiivinen valvonta seuraa seurausta. Se etsii odottamatonta suorituskykyä, muutoksia syötteissä, muutoksia reitissä, poikkeavia ohituskuvioita, estettyjä tapauksia, valituksia ja merkkejä siitä, että järjestelmää pyydetään tekemään työtä, jota sille ei annettu.

Kolmas on tulkinta. Ihminen ei voi käyttää valvontavaltaa, jos tulos saapuu ilman ehtojaan. Tulkinta voi edellyttää asiaankuuluvaa lähdettä, luottamustietoa, politiikan versiota, syötteen laatusignaalia, selitysmenetelmää tai vertailua turvalliseen perustasoon. Se ei edellytä mystistä näkymää jokaiseen parametriin. Se edellyttää riittävästi asiayhteyttä vastatakseen kysymykseen, josta henkilö on vastuussa: mitä tämä tulos tarkoittaa tässä, mitä se ei tarkoita ja mitä pitäisi tapahtua, jos näyttö on riittämätöntä?

Neljäs on kieltäytyminen ja kumoaminen. Artikla 14 antaa valvontaroolille nimenomaisesti mahdollisuuden päättää olla käyttämättä järjestelmää, jättää sen tulos huomiotta, ohittaa sen tai kumota sen. Tämä on vahvempaa kuin pyytää henkilöä lisäämään kommentti tuloksen hyväksymisen jälkeen. Se tarkoittaa, että työnkulun on sallittava erilaisen päätöksen säilyminen. Vaihtoehtoa ei saa kohdella poikkeuksena, joka katoaa seuraavassa automatisoidussa vaiheessa. Jos ihminen voi olla eri mieltä, mutta järjestelmä toteuttaa alkuperäisen suosituksen joka tapauksessa, ihmistä on kutsuttu ilmaisemaan mielipide, ei annettu valvontavaltaa.

Viides on keskeytys. Keskeytys vaikuttaa itse toimintaan. Se voi pysäyttää työkalukutsun ennen ulkoista muutosta, asettaa tapauksen odottamaan, estää uuden työn pääsyn reitille, peruuttaa käyttöoikeuden tai siirtää palvelun rajattuun varajärjestelmään. Tekninen menetelmä vaihtelee. Turvallisuusominaisuus ei vaihtele: toiminnan on päädyttävä määriteltyyn tilaan, jossa seuraava merkittävä toimenpide ei voi tapahtua pelkän vauhdin voimasta.

Nämä valtuudet liittyvät toisiinsa, mutta eivät ole vaihdettavissa keskenään. Ihminen voi ymmärtää järjestelmää, mutta vailla oikeuksia pysäyttää se. Ihmisellä voi olla pysäytyspainike, mutta ei hyödyllistä signaalia siitä, milloin sitä painaa. Ihminen voi ohittaa yhden tuloksen, kun taas eräprosessi tuottaa saman tuloksen kaikille muille. Ihminen voi pysäyttää uusien tapausten vastaanoton, kun olemassa olevat työt jatkavat kirjoittamista ulkoiseen järjestelmään. Valvontasuunnittelun on yhdistettävä nämä valtuudet työn todellisen elinkaaren yli.

Tämä yhteys on myös se, missä ihmisen roolista tulee arvokas. Arvioija ei ole siellä ottamassa vastaan järjestelmän epävarmuutta allekirjoituksellaan. Arvioija on siellä käyttämässä rajattua valtaa, jonka organisaatio on tietoisesti mahdollistanut. Työ voi silti olla vaikeaa. Se voi vaatia alan asiantuntemusta, harkintaa ja rohkeutta haastaa suosittu järjestelmä. Mutta vaikeus ei ole syy piilottaa hallintaa. Se on syy määritellä se.

Kuka saa avaimen?

Ei ole yhtä ainoaa ihmistä silmukassa. Yleensä on useita toimivaltaisia tahoja, joilla kullakin on eri syy puuttua asiaan. Tarjoaja hallitsee osia suunnittelusta ja julkaisusta. Käyttöönottaja hallitsee tarkoitusta, kokoonpanoa ja operatiivista käyttöä. Valvontaan määrätty henkilö hallitsee tiettyä päätöstä tai toimenpidettä suorituksen aikana. Toimialan omistaja hallitsee, onko tulos hyväksyttävä ammatillisessa yhteydessä. Turvallisuus- tai yksityisyysrooli voi hallita pääsyä todisteisiin tai tietoihin. Vaikutuksen kohteena olevalla henkilöllä voi olla oikeus haastaa lopputulos. Toimivaltainen viranomainen voi vaatia tietoja, korjaavia toimia tai peruuttamista. Kaikkien näiden kohteleminen yhtenä roolina saa järjestelmän kuulostamaan yksinkertaiselta ja vastuuvelvollisuuden mahdottomalta.

Palveluntarjoajan vastuu alkaa ennen kuin järjestelmä saavuttaa käyttäjän. Palveluntarjoaja päättää, mitkä hallintatoimet sisäänrakennetaan, mitkä rajoitukset dokumentoidaan, mitä lokitietoja voidaan tuottaa ja mitä muutoksia pidetään olennaisina. Palveluntarjoajan, joka sanoo, että käyttöönottaja voi yksinkertaisesti seurata järjestelmää, on osoitettava, miten käyttöönottaja voi tehdä sen toimitetun käyttöliittymän ja tietojen avulla. Jos pysäyttäminen edellyttää dokumentoimatonta sisäistä komentoa tai tukipyyntöä, jonka vastaus on epävarma, pysäytys ei ole käyttöönottajan kyvykkyys. Se on toivo siitä, että toimittaja pysyy hereillä.

Käyttöönottajalla on erilainen toimivalta. Käyttöönottaja päättää, missä järjestelmää käytetään, mihin tarkoitukseen, minkä tietojen kanssa, minkä työnkulun puitteissa ja ketkä vastaavat valvonnasta. Käyttöönottaja voi muuttaa neuvoa antavan tulosteen tosiasialliseksi päätökseksi käyttöliittymäsuunnittelun, kannustimien tai painostuksen avulla, vaikka palveluntarjoaja olisi kuvannut järjestelmän huolellisesti. Käyttöönottajan on siksi kartoitettava paikallinen reitti, ei vain toistettava toimittajan tarkoittamaa käyttötarkoitusta. Sama komponentti voi saada erilaisen riskiprofiilin, kun se liitetään eri toimenpiteeseen.

Käytönaikaisen valvonnan rooli tarvitsee kapeamman ja selkeämmän valtuutuksen. Tämä henkilö saa ehkä pitää tapausta hallussaan, hylätä suosituksen, pyytää lisänäyttöä, nostaa asian toimialueen omistajalle tai aktivoida turvallisen pysäytyksen. Hän ei saa ehkä muuttaa mallia, poistaa näyttöä, tehdä oikeudellista ratkaisua tai jatkaa keskeytettyä reittiä. Nämä rajat eivät ole loukkaus roolia kohtaan. Ne estävät sitä, joka voi pysäyttää prosessin, myös pyyhkimästä pois syytä pysäyttämiseen.

Toimivallan tulisi seurata seurausta. Arvioija, joka voi keskeyttää luonnoksen, ei välttämättä tarvitse oikeutta keskeyttää jokaista organisaation reittiä. Henkilö, joka voi pysäyttää turvallisuuden kannalta merkityksellisen toimenpiteen, saattaa tarvita pääsyn laajempaan poikkeamaryhmään ja selkeän ilmoitusvelvollisuuden. Toimialan asiantuntija voi olla ainoa, jolla on lupa kumota tuloste säännellyssä päätöksessä. Tietoturvaoperaattori voi eristää palvelun, kun taas toinen toimivaltainen taho päättää, pitäisikö käyttö jatkua. Tärkeää ei ole luoda suurta hierarkiaa. Tärkeää on tehdä luovutuksista yksiselitteisiä.

Eskalaatiota ei saa sekoittaa vastuunpakoiluun. Jos ensimmäinen arvioija lähettää jokaisen vaikean tapauksen komitealle, järjestelmä ei ole saanut valvontaa. Se on saanut hitaamman jonon. Eskalaatioreitin tulisi kertoa, mikä kysymys eskaloidaan, mitä työtä pidetään keskeytettynä vastausta odotettaessa, kenen on vastattava, mitkä todisteet kulkevat tapauksen mukana ja mitä tapahtuu, jos reitti ei ole käytettävissä. Ensimmäinen henkilö säilyttää vastuun tapauksen säilyttämisestä ja turvallisen oletusarvon käyttämisestä. Hänen ei tarvitse keksiä lopullista vastausta yksin.

Toimivallalla on myös oltava paluureitti. Pysäytys ilman tapaa palauttaa hallinta joko muuttuu pysyväksi käyttökatkoksi tai hiljaiseksi kiertotieksi. Paluureitin tulisi nimetä, kuka voi jatkaa, mitkä edellytykset on täytettävä, pysyykö tallennettu tila voimassa, mitkä keskeneräiset työt on arvioitava uudelleen ja miten käyttäjille kerrotaan, että reitti on muuttunut. Jatkaminen on toinen päätös. Se ansaitsee saman vakavuuden kuin keskeytys, vaikka se harvoin saa yhtä houkuttelevaa painiketta.

Pysäytyksen on oltava turvallinen

AI-säädöksen ilmaus turvallinen tila ansaitsee enemmän huomiota kuin pysäytyspainikkeen laitteistomielikuvat. Järjestelmä voi lopettaa uusien pyyntöjen lähettämisen ja silti jättää vaarallista työtä liikkeelle. Se voi päättää prosessin kesken tapahtuman. Se voi hylätä tulosteen kertomatta henkilölle, joka odotti päätöstä. Se voi poistaa näkyvän käyttöliittymän käytöstä, kun ajastettu työ jatkuu taustalla. Se voi pysäyttää mallin ja jättää välimuistiin tallennetun suosituksen seuraavan palvelun käytettäväksi. Pysäytys on turvallinen vain suhteessa järjestelmän todellisiin vaikutuksiin.

Määrittele tilat ennen ohjaimen valintaa. Käynnissä oleva reitti voi hyväksyä, arvioida, suositella ja toimia. Pidossa oleva reitti ei voi hyväksyä mitään uutta, mutta se säilyttää jo vastaanotetun materiaalin. Pysäytetty reitti voi hylätä kaiken merkittävän työn, mutta sallia valtuutetun tarkastuksen. Heikentynyt reitti voi tarjota rajoitetun vain luku - tai vain ihmisille tarkoitetun palvelun. Vedetty reitti voi vaatia uuden hyväksynnän ennen paluuta. Nämä ovat suunnitteluvalintoja, eivät yleismaailmallisia nimiä. Niistä tulee hyödyllisiä, kun ihmiset näkevät, missä tilassa he ovat ja mitä kukin tila sallii.

Kesken oleva työ tarvitsee oman sääntönsä. Jotkin toiminnot ovat peruutettavissa ja ne voidaan viimeistellä turvallisesti. Jotkin ovat jo ylittäneet ulkoisen rajan ja tarvitsevat korjaavan toimenpiteen. Jotkin on hylättävä ja luotava uudelleen, koska näyttö ei ole enää luotettavaa. Jotkin ovat vähävaikutteisia ja voivat jäädä luonnoksiksi. Järjestelmän ei pitäisi pakottaa käyttäjää arvaamaan yksittäisen tilamerkinnän perusteella. Sen pitäisi tuoda esiin työjoukko, sen siirtymäkohta ja toimenpide, joka tapahtuu, jos mitään muuta ei tehdä.

Turvallinen tila suojaa myös näyttöä. Järjestelmän pysäyttäminen poistamalla sen väliaikaistiedostot voi poistaa juuri sen kontekstin, jota tarvitaan vian ymmärtämiseen. Sen pysäyttäminen jättämällä salaisuuksia laajaan diagnostiikkavientiin voi aiheuttaa toisen tapahtuman. Ohjain tarvitsee näytön säilytyspolun, jossa on käyttörajoitukset, säilytyssäännöt ja nimetty omistaja. Turvallisuus ja yksityisyys eivät ole täällä kilpailijoita. Molemmat vaativat huolellista käsittelyä, eivät tuttua hätäkäytäntöä, jossa kaikki kopioidaan kansioon nimeltä urgent.

Pysäytyksen testaaminen on osa järjestelmän käyttöönottoa. Painike, jota on napsautettu vain esittelyssä, todistaa, että painiketta voi napsauttaa. Se ei todista, että syöttö pysähtyy, toiminnot asettuvat, tietueet pysyvät johdonmukaisina, ilmoitukset saavuttavat oikeat henkilöt tai että uudelleenkäynnistys ei toista työtä kahdesti. Testin pitäisi harjoittaa todellista reittiä, mukaan lukien osittainen vika ja käyttäjä, jolla on aiottu valtuutus mutta ei kehittäjän yksityistä tietoa. Jos pysäytystä ei voi harjoitella ilman erityistä suoritusta, se ei ole vielä operatiivinen ohjain.

Jono on osa päätöstä

Tekoälyjärjestelmän pysäyttäminen kuvitellaan usein mallin pysäyttämiseksi. Käytännössä malliin liittyvä jono on osa päätöstä. Työ voi odottaa pääsyä, mallin tulosta, ihmisen tarkistusta, jatkotyökalua tai ilmoitusta. Jokaisella paikalla on erilainen riski. Pysäytys, joka suojaa vain mallin, voi antaa ympäröivän jonon jatkaa vanhojen tulosten käsittelyä kelvollisina.

Odottava työ tarvitsee käytännön. Saako uusi pyyntö selkeän kieltäytymisen, viivästysilmoituksen vai ihmisreitin? Pysyykö ennen pysäytystä tuotettu tulos käyttökelpoisena? Merkitäänkö tapaukset, joita ei ole vielä tarkistettu, vaatimaan uutta arviointia? Erottako järjestelmä työn, jonka henkilö on keskeyttänyt, työstä, joka on epäonnistunut teknisesti? Voiko käyttäjä peruuttaa pyynnön sen ollessa pidossa? Yksityiskohdat riippuvat palvelusta, mutta päätöstä ei voi jättää jonon oletusarvoisen uudelleenyrityskäyttäytymisen varaan.

Uudelleenyritykset ovat erityisen paljastavia. Tekninen jono olettaa usein, että keskeneräinen toiminto pitäisi yrittää uudelleen. Hallintojono ei voi olettaa, että sama suositus pitäisi tuottaa uudelleen, kun pysäytyksen syy on epävarmuus, laajuus tai mahdollinen haitta. Uudelleenyritys voi olla turvallinen idempotentille lukutoiminnolle ja turvaton ulkoiselle toiminnolle. Pysäytyskäytännön pitäisi siksi sisältää syy ja sallittu seuraava vaihe, ei pelkkää punaista tilaa.

Olemassa olevat tuotokset tarvitsevat luokittelun. Jotkut ovat luonnoksia, joihin kukaan ei ole nojautunut. Jotkut on näytetty työntekijälle. Jotkut on kopioitu päätöstietueeseen. Jotkut ovat laukaisseet ilmoituksen tai muuttaneet järjestelmää tekoälyreitin ulkopuolella. Organisaatio ei voi päättää, mitä niille tehdään, ennen kuin se tietää, minkä rajan kukin tuotos on ylittänyt. Siksi jäljitettävyys ei ole toimistoteknistä koristelua. Se on kartta seurauksista, jotka pysäytyksen on pidettävä sisällään.

Jono muuttaa myös ihmisten työmäärää. Pysäytys voi suojata ihmisiä turvattomalta automatisoidulta toiminnalta ja samalla luoda suuren määrän tarkistustyötä. Tämä työ on tunnustettava, priorisoitava ja resursoitava. Muuten organisaatio lopulta avaa reitin uudelleen, koska pysäytetyistä tapauksista tuli hankalia, ei siksi, että näyttö olisi parantunut. Tauko, joka vain siirtää haitan uupuneeseen manuaaliseen jonoon, on hyvää tarkoittava lykkäys.

Ei ole häpeällistä, että jono hidastuu, kun vaihtoehtona on tutkimaton seuraus. Suunnitteluongelma on silloin, kun jonolla ei ole kapasiteettimallia, ei lajittelusääntöä eikä tapaa kertoa asianosaisille, mitä on tapahtumassa. Ihmisen valvonta ei ole ilmaista huomiota. Se on operatiivinen palvelu, jonka rajat tulisi tuntea ennen kuin koneelta pyydetään toimintaa laajassa mittakaavassa.

Pysäytyksen jälkeen muisti

Pysäytys on tapahtuma, joka muuttaa sitä, mitä organisaatio tietää ja mihin se on velvollinen. Tietueen tulisi sisältää laukaisin, aika, reitti, tila ennen puuttumista, käytetty valtuus, pysäytyksen laajuus, työ, johon se vaikuttaa, tallennettu näyttö, tehdyt ilmoitukset ja tarkistuksen edellytykset. Sen tulisi erottaa havainto johtopäätöksestä. Käyttäjä voi kirjata, että tuotos oli ristiriidassa toimitetun näytön kanssa, väittämättä, että tapaus on todistettu. Tarkkuus tietueessa suojaa sekä tutkintaa että asianosaisia.

Tekoälysäädös käsittelee tietojen säilytystä korkean riskin järjestelmien teknisenä ominaisuutena. 12 artikla edellyttää, että tällaiset järjestelmät mahdollistavat tapahtumien automaattisen tallentamisen koko elinkaaren ajan, ja lokitusominaisuuksien on tuettava jäljitettävyyttä, riskien tunnistamista, markkinoille tulon jälkeistä seurantaa ja toiminnan valvontaa. 19 artikla käsittelee automaattisesti luotujen lokien säilyttämistä tarjoajan hallinnassa, tarkoitetun käyttötarkoituksen ja sovellettavan tietosuojalainsäädännön mukaisesti. Tämä on hyödyllinen muistutus siitä, että pysäytys ei voi riippua jälkikäteen kootusta kuvakaappauksesta. Järjestelmän on kyettävä jättämään jälki toiminnan aikana.

Lokitus ei ole ohje kerätä kaikki henkilötiedot ikuisesti. Se on vaatimus tallentaa tapahtumat, jotka ovat olennaisia käyttötarkoituksen ja riskin kannalta. Hyvä pysäytystietue voi käyttää viitteitä, tiivisteitä, versiotunnisteita, poistettua sisältöä ja erillisiä käyttöoikeuksia. Se voi säilyttää toistoon tarvittavan syötteen suojatussa tallennustilassa sen sijaan, että se asetettaisiin tavalliseen kojelautaan. Tutkinta on voitava tehdä muuttamatta näytön tallennustilaa toiseksi hallitsemattomaksi dataomaisuudeksi.

Tarjoajan korjaavien toimien velvollisuus on myös merkityksellinen. Kun tarjoaja katsoo tai sillä on syytä katsoa, että korkean riskin järjestelmä ei ole vaatimustenmukainen, säädös edellyttää tarvittavia korjaavia toimia, joihin voi kuulua järjestelmän saattaminen vaatimustenmukaiseksi, sen poistaminen käytöstä, sen käytöstä poistaminen tai sen palauttaminen soveltuvin osin. Valinta ei ole markkinointipäätös. Se on vastaus, joka perustuu näyttöön, laajuuteen ja riskiin. Käyttöönottaja voi joutua pysäyttämään paikallisen reitin ennen kuin tarjoaja voi saattaa arvioinnin päätökseen. Tarjoaja voi joutua poistamaan käytöstä tai vetämään pois reitin, jonka käyttöönottaja on pitänyt toiminnassa. Näiden kahden toimivallan on kyettävä viestimään keskenään menettämättä muutosta selittävää näyttöä.

Markkinoille saattamisen jälkeinen seuranta laajentaa muistin yhden tapahtuman yli. Asetuksessa kuvataan järjestelmä, joka aktiivisesti ja järjestelmällisesti kerää, dokumentoi ja analysoi olennaista tietoa koko suuririskisen järjestelmän elinkaaren ajan. Tarkoitus ei ole, että valmistaja tuijottaisi kojelautaa. Tarkoitus on selvittää, täyttääkö järjestelmä edelleen vaatimukset ja onko sen ympäristö muuttunut. Pysäytys voi olla ensimmäinen hyödyllinen signaali tässä prosessissa. Sarja pieniä toimenpiteitä voi kertoa järjestelmän soveltuvuudesta enemmän kuin yksi siisti lanseerausarviointi.

Vakavilla vaaratilanteilla on asetuksessa oma ilmoitusmenettelynsä, johon kuuluu velvollisuus tutkia asia ja ryhtyä korjaaviin toimenpiteisiin ilmoituksen jälkeen. Artikla ei tee jokaisesta ohituksesta vakavaa vaaratilannetta. Tämä ero on tärkeä. Käyttäjä, joka kumoaa suosituksen, voi käyttää tervettä valvontaa, ei löytää ilmoitusvelvollista tapahtumaa. Tallenteen pitäisi säilyttää riittävästi tietoa, jotta organisaatio voi päättää, mitä tapahtui, sen sijaan että jokainen erimielisyys pakotettaisiin joko hiljaisuuteen tai dramaattiseen leimaan.

Eskalaatio on kysymyksen hallittua siirtämistä, ei kohteliasta tapaa saada vastuu katoamaan.

Eskalaatio on reitti, ei mielentila

Ihmiset sanovat usein, että vaikea tapaus pitäisi eskalaoida. Ilmaus kuulostaa vastuulliselta, mutta se ei sisällä juuri lainkaan toiminnallista tietoa. Kenelle eskalaoidaan? Mitä päätöstä varten? Millä näytöllä? Missä ajassa? Mitä pidetään jäissä, kun vastausta odotetaan? Mitä tapahtuu, jos kukaan ei vastaa? Reitti, joka ei vastaa yhteenkään näistä kysymyksistä, palkitsee sinnikkyyden eikä harkintakyvyn. Tapaus joko kiertää eteenpäin, kunnes määräajasta tulee päätös, tai se palautetaan hiljaa sille, joka ensimmäisenä huomasi ongelman.

Hyödyllinen eskalaatio alkaa kysymyksestä. Onko tuotos käyttötarkoituksen ulkopuolella? Onko näyttö puutteellista? Onko järjestelmä muuttunut arvioinnin jälkeen? Onko olemassa riski perusoikeudelle? Onko ulkoinen toimi jo tapahtunut? Onko ongelma tekninen, oikeudellinen, toimialakohtainen, tietoturvaan liittyvä vai näiden yhdistelmä? Kysymys määrittää, mikä rooli voi vastata siihen. Eskalaatio, joka lähettää saman erottelemattoman tapauksen jokaiselle tiimille, ei ole perusteellista. Se on ryhmäsähköposti futuurissa.

Paikallisen valvontaroolin tulee olla turvallinen oletusarvo sillä aikaa, kun kysymys on avoinna. Se voi olla pito, kieltäytyminen, paluu ihmisvetoiseen polkuun, luonnoksen säilyttäminen tai järjestelmän rajoittaminen vain luku -tilaan. Oletusarvon tulee olla näkyvissä henkilölle ja tarvittaessa myös asianomaiselle käyttäjälle. Hiljaisuus ei ole turvallinen oletusarvo, kun työnkulku jatkuu sen alla.

Näytön on kuljettava eskalaation mukana. Vastaanottavan roolin ei pitäisi joutua rekonstruoimaan tapausta mallin tulosteesta ja aikaleimasta. Sen tulisi saada asiaankuuluva syöteviite, tuloste, malli- ja käytäntöversiot, lähdemateriaali, luottamus- tai epävarmuussignaali, toiminnon tila, aiemmat toimenpiteet ja tarkka päätös, jota tarvitaan. Tässä kohtaa myös yksityisyyden kurinalaisuus korostuu. Lähetä tarpeeksi kysymykseen vastaamiseen, ei koko ihmisen elämää vain siksi, että vientipainike oli lähellä.

Eskalaatio tarvitsee kellon, mutta kaikki kellot eivät ole hyväksymisen määräaikoja. Vähämerkityksinen kysymys voi odottaa normaalia käsittelyä. Suurivaikutteinen toimenpide voi vaatia välitöntä pitoa ja päivystysreittiä. Ajoitussäännön tulee kertoa, mitä tapahtuu, kun vastausikkuna umpeutuu. Se voi pidentää pitoa, siirtää toimivallan, ilmoittaa esihenkilölle tai vaatia uuden päätöksen. Sen ei pitäisi hiljaisesti muuttaa puuttuvaa vastausta luvaksi.

Päättäminen on osa eskalaatiota. Tietueen tulee kertoa, mitä päätettiin, kuka päätti, minkä näytön perusteella, millä rajoituksilla ja mitä seurantaa tarvitaan. Jos vastaus on, että järjestelmä voi jatkaa vain rajatussa kontekstissa, uusi raja on otettava käyttöön, ei vain ihailla. Jos vastaus on, että järjestelmä on vedettävä pois, asianomaiselle työlle ja käyttäjille tarvitaan suunnitelma. Jos vastaus on, että poikkeama oli hyvänlaatuinen, näytön tulisi silti ohjata seurantaa ja koulutusta. Eskalaatio, joka katoaa kokouksen jälkeen, ei ole muuttunut institutionaaliseksi tiedoksi.

Hyvä eskalaatio suojaa myös henkilöä, joka nostaa asian esiin. Oikeus pysäyttää järjestelmä on hyödytön, jos sen käyttöä pidetään epälojaaliutena. Organisaatiot opettavat todelliset prioriteettinsa sillä, mitä tapahtuu sen jälkeen, kun joku sanoo ei. Jos vastaus on uteliaisuutta, näyttöä ja tukea, ihmiset oppivat, että valvonta on osa työtä. Jos vastaus on syyllistämistä, viivyttelyä ja pyyntö olla positiivisempi, järjestelmä saa vähemmän varoituksia ja saamansa varoitukset tulevat myöhemmin.

Ihmisen suorittama valvonta on työmäärä

Lain viittaus pätevyyteen, koulutukseen ja toimivaltaan on helppo lukea henkilöstöhallinnon vaatimukseksi. Se on myös kapasiteettivaatimus. Ihminen ei voi valvoa tekoälyjärjestelmää tehokkaasti, jos käyttöliittymä näyttää liikaa kohinaa, jono ei jätä aikaa tarkastukselle, näyttö saapuu eri työkalussa, päätöksiä mitataan vain nopeudella tai organisaatio on antanut työn henkilölle, jolla ei ole alan tietämystä. Rooli voi olla olemassa paperilla ja silti olla mahdoton suorittaa.

Koulutukseen tulisi sisältyä järjestelmän rajoitukset, hyväksytty käyttötarkoitus, odottamattoman suorituskyvyn merkit, epävarmuuden merkitys, ohituksen ja pysäytyksen mekaniikka, näytön yksityisyys ja reitti toimenpiteen jälkeen. Siihen tulisi sisältyä tapauksia, joissa tuloste näyttää uskottavalta. Valvontaa tarvitaan eniten silloin, kun vastaus ei ole tarpeeksi järjetön hylättäväksi heti. Kurssi, joka opettaa tunnistamaan karikatyyrimäisen väärän vastauksen, valmistaa ihmisiä demonstraatioon, ei toimivaan palveluun.

Automaatiovinouma ansaitsee käytännön huomiota. Suosituksesta voi tulla ankkuri ennen kuin arvioija on lukenut sitä tukevan näytön. Luottamusmerkintää voidaan tulkita todennäköisyytenä, vaikka se ei sitä olisi. Hiotusta selityksestä voi tulla itsenäisen vahvistuksen kaltainen, vaikka se on vain uudelleenmuotoilu. Käyttöliittymän järjestyksellä on merkitystä. Jos järjestelmä esittää vastauksensa ensin ja näytön vasta sen jälkeen, arvioija saattaa käyttää loppuprosessin alun vaikutelman puolustamiseen tai korjaamiseen. Pysäytyssäätimen piilottaminen saman työnkulun taakse kuin hyväksyntä kertoo myös siitä, mitä toimintaa organisaatio odottaa.

Työmäärärajat ovat turvallisuussäätimiä. Arvioija, jonka on tyhjennettävä suuri jono, voi oppia pitämään mallin oletusta nopeimpana turvallisena valintana. Asiantuntija, joka saa jokaisen epäselvän tapauksen, voi alkaa hyväksyä vain pitääkseen palvelun liikkeessä. Pieni tiimi, joka vastaa päivystysaikaisesta pysäytysreitistä, ei välttämättä ole tavoitettavissa silloin, kun järjestelmä todella toimii. Nämä eivät ole henkilökohtaisia epäonnistumisia. Ne ovat ennustettavia reaktioita käyttösuunnitteluun, joka edellyttää inhimillisen harkinnan kompensoivan rajoittamatonta automaatiota.

Mittaa valvontatyötä itseään. Kuinka usein tuloksia ohitetaan? Kuinka usein pysäytystä yritetään? Mitkä signaalit johtavat puuttumiseen? Kuinka kauan pidot pysyvät avoinna? Mitkä ryhmät tai kielet tuottavat enemmän epävarmuutta? Kuinka paljon korjausta tarvitaan ennen kuin tulosta voidaan käyttää? Mittarit eivät korvaa harkintaa, mutta ne voivat paljastaa, että luvatusta valvonnasta on tulossa pelkkä leimasin. Tavoitteena ei ole rangaista korkeasta ohitusasteesta. Tavoitteena on kysyä, mitä aste kertoo järjestelmästä ja työnkulusta.

Eurooppalaiset turvallisuusperinteet tuntevat tämän jo

Euroopan politiikkakieli luotettavasta tekoälystä ei alkanut tekoälyasetuksesta. Vuonna 2019 Euroopan komission tekoälyä käsittelevä asiantuntijaryhmä julkaisi Ethics Guidelines for Trustworthy AI -ohjeistuksen. Ohjeistus tunnistaa inhimillisen toimijuuden ja valvonnan yhdeksi seitsemästä vaatimuksesta ja kuvaa ihmisen silmukassa, ihmisen silmukan yllä ja ihmisen komennossa -lähestymistavat. Se myös yhdistää valvonnan tekniseen vankkuuteen, varasuunnitelmiin, läpinäkyvyyteen, jäljitettävyyteen ja vastuullisuuteen. Tärkeä seikka ei ole sanasto. Se on päätös kuvata luotettavuus joukkona ehtoja, joita voidaan arvioida.

Komission myöhempi arviointityö antaa organisaatioille tavan muuttaa nämä ehdot kysymyksiksi. Ovatko ihmiset tietoisia siitä, että he ovat vuorovaikutuksessa tekoälyjärjestelmän kanssa? Voivatko he ymmärtää järjestelmän kyvyt ja rajoitukset? Voivatko he puuttua asiaan ja päättää olla käyttämättä sitä? Onko olemassa muutoksenhakumekanismeja? Tarkistuslista ei tee toiminnasta turvallista. Se kuitenkin vaikeuttaa teeskentelyä siitä, että valvontaan määrätty henkilö on automaattisesti myös valtuutettu käyttämään valvontaa.

ENISAn työ tekoälyn kyberturvallisuudesta lähestyy aihetta elinkaaren ja mallin ympärillä olevan ekosysteemin kautta. Sen vuoden 2020 AI Threat Landscape -raportti kartoittaa resurssit, toimijat, uhat ja vaiheet vaatimuksista käyttöönottoon. Tämä näkökulma on arvokas pysäyttämisen kannalta, koska eristettävä kohde ei välttämättä ole malli. Se voi olla tietolähde, työkalun käyttöoikeus, käyttöönottopaketti, seurantapolku tai toimittajan komponentti. Mallin nimen ympärille suunniteltu pysäytys voi jättää todellisen toiminnon ennalleen muualle ketjussa.

Nämä ovat dokumentoituja eurooppalaisia lähestymistapoja, eivät väitteitä siitä, että Eurooppa olisi ratkaissut valvonnan. Ohjeistukset ja asetus asettavat odotuksia. ENISA kartoittaa tietoturvaongelman. Toteutustyö pysyy paikallisena, teknisenä ja väistämättömän arkipäiväisenä. Jonkun on silti päätettävä, mikä rooli voi pitää reittiä hallussaan iltapäivällä kolmelta, mitkä todisteet näkyvät heidän näytöllään ja kuka vastaa, kun pysäytystä on käytetty.

Hankinta päättää ennen kuin operaattorit tekevät

Monet pysäytysvirheet ovat hankintapäätöksiä, joilla on operatiivinen naamio. Sopimus voi sallia toimittajan vaihtaa mallin ilman käyttökelpoista ilmoitusta. Palvelu ei välttämättä tarjoa lokitietoja tai versiotunnistetta. Vienti voi jättää pois keskeneräiset työt ja interventiohistorian. Tukisopimus ei välttämättä tarjoa vastausreittiä turvallisuuskeskeytykselle. Ostaja on voinut hyväksyä väljän lausuman, jonka mukaan asiakas vastaa käytöstä, ilman että on hankkinut hallintakeinoja tämän vastuun toteuttamiseen. Siihen mennessä, kun käyttäjä kysyy sammutuskytkintä, sopimus on jo päättänyt, onko sellaista olemassa.

Hankinnan tulisi siksi kysyä operatiivisia kysymyksiä. Kumpi osapuoli voi poistaa käytöstä kunkin reitin? Voiko käyttöönoton tekijä pysäyttää seurauksellisen toimenpiteen odottamatta toimittajan tukea? Mitä tapahtuu käynnissä oleville ja jonossa oleville töille? Mikä tila tallennetaan? Miten muutokset ilmoitetaan? Voiko asiakas hakea lokit ja todisteet käyttökelpoisessa muodossa? Mikä on varajärjestely, kun palvelu ei ole käytettävissä? Mitkä roolit on koulutettu, ja kuka rahoittaa koulutuksen? Miten kiistetty tulos korjataan? Miten organisaatio poistuu järjestelmästä menettämättä aiempien päätösten selittämiseen tarvittavia tietoja?

Nämä kysymykset eivät ole yritys saada jokainen toimittaja käyttäytymään kuin julkinen viranomainen. Ne ovat tapa pitää toimivalta linjassa käytön kanssa. Jos organisaatiolla on velvollisuus suojella järjestelmän vaikutuspiirissä olevia ihmisiä, sen on voitava hallita reittiä riittävästi tämän velvollisuuden täyttämiseksi. Sopimus, joka jättää asiakkaan vastuulliseksi mutta operatiivisesti voimattomaksi, ei ole hallintomalli. Se on vastuunsiirto logolla.

Lyhyt huomautus meiltä

Dwevessä työmme tilapohjaisen vastuullisen tekoälyn parissa tekee saman vaatimattoman huomautuksen tekniikan puolelta: vastuullisessa työnkulussa on nimetyt tilat, suojaukset, tietueet, omistajat ja poistumiset. Tämä ei ole väite, että kaavio ratkaisisi hallinnon. Se on muistutus siitä, että periaatteet tarvitsevat paikan, johon ne asettuvat, kun järjestelmä on käynnissä. Olipa työkalu Dweve-komponentti, julkisen sektorin palvelu tai toimittajan malli, testi on sama. Näkeekö todellinen ihminen ongelman, käyttääkö hän toimivaltaa, pysäyttääkö hän seuraavan seurauksen, säilyttääkö hän todisteet ja palauttaako hän työn puolustettavaan tilaan?

Kysymyksiä ennen käyttöönottoa

Ennen kuin malli otetaan seuraukselliseen työnkulkuun, kysy pysäytyskysymykset siinä tilassa, jossa järjestelmä todella toimii. Älä jätä niitä politiikkakatsaukseen, joka ei koskaan näe jonoa, työkaluyhdyskäytävää tai henkilöä, joka vastaanottaa hälytyksen.

  • Mikä tarkalleen ottaen voidaan pysäyttää? Nimeä mallin reitti, työkalukutsu, jono, ilmoitus, kirjoitustoiminto ja alavirran palvelu. Jos vastaus on vain malliprosessi, etsi toiminto, joka jää jäljelle sen pysähtymisen jälkeen.
  • Kuka voi pysäyttää sen kysymättä rakentajalta? Nimeä suoritusympäristön rooli, sen valtuudet, sen varajärjestely ja sen rajat. Henkilön ei pitäisi tarvita yksityiskohtaista tietoa toteutuksesta käyttääkseen hallintaa.
  • Mikä signaali kehottaa heitä toimimaan? Määrittele poikkeavuudet, puuttuva näyttö, laajuusristiriita, ei-hyväksyttävä epävarmuus, politiikan muutos, tietoturvahuoli ja käyttäjän haaste sellaisin termein, joita käyttäjä voi havainnoida.
  • Mitä jo käynnissä olevalle työlle tapahtuu? Erottele uusi saapuva työ, jonotettu työ, käynnissä olevat toiminnot, ihmisille näytetyt tulokset ja jo suoritetut toimet. Määritä turvallinen käsittely jokaiselle.
  • Mikä on turvallinen tila? Kuvaile, mitä järjestelmä hyväksyy, hylkää, pitää hallussa, viimeistelee tai paljastaa keskeytyksen jälkeen. Testaa, että tila on todellinen eikä vain nimi ruudulla.
  • Mitkä todisteet säilyvät? Säilytä asiaankuuluva syöte, tulos, versiot, politiikka, lähdeviittaukset, ihmisten toimet, ajoitus ja ilmoitukset asianmukaisin yksityisyydensuojan hallintakeinoin.
  • Kuka vastaanottaa eskalaation? Ilmoita päätöskysymys, vastausikkuna, todistepaketti ja oletusarvo odotuksen aikana. Jakelulista ei ole valtuuskartta.
  • Kuka saa jatkaa, kaventaa tai peruuttaa reitin? Tee paluupäätös yksiselitteiseksi. Tunnista ehdot, uudelleenarviointi, käyttäjäviestintä ja tarkistuksen laukaiseva tekijä, jotka siihen liittyvät.
  • Mistä tiedät, että hallinta pettää? Tarkkaile ohitusmalleja, pitotilanteen kestoa, toistuvia tapauksia, epätasaisia vaikutuksia, jonopainetta, käyttäjävalituksia ja ympäröivän työnkulun ajautumista. Harvoin käytetty pysäytys voi tarkoittaa turvallista järjestelmää tai piilotettua hallintaa.

Kysymykset ovat tarkoituksella yksinkertaisia. Ne eivät korvaa riskiarviointia, vaatimustenmukaisuusprosessia, poikkeamasuunnitelmaa tai oikeudellista tarkastelua. Ne ovat se kohta, jossa nämä toimet muuttuvat käytännön toiminnaksi. Jos organisaatio ei pysty vastaamaan niihin, puuttuva työ ei ole filosofinen erimielisyys siitä, pitäisikö tekoälyyn luottaa. Se on puuttuva osa järjestelmää.

Valta pysäyttää on valta välittää

Malli voi olla väärässä tavalla, joka näyttää tavalliselta. Lähde on vanha. Syöte on puutteellinen. Reitti on laajentunut. Kynnysarvoa on siirretty. Käännös muutti merkityksen. Työkalun käyttöoikeus eli pidempään kuin sen tarkoitus. Arvioijalle näytetään johtopäätös, mutta ei näyttöä. Mikään hälytys ei soi, koska järjestelmä on edelleen käytettävissä ja kojelauta on edelleen vihreä. Haitta alkaa pienenä epäsuhtana sen välillä, mitä järjestelmän sallittiin tehdä ja mitä organisaatio nyt odottaa sen tekevän.

Ihmisen suorittama valvonta on organisaation vastaus tähän epäsuhtaan, mutta vain silloin, kun se on enemmän kuin läsnäoloa. Valvontarooli tarvitsee tietoa ongelman tunnistamiseen, aikaa sen tutkimiseen, valtuudet kieltäytyä tai keskeyttää, turvallisen tilan, joka tekee keskeytyksestä merkityksellisen, ja tallenteet, joiden avulla muut ihmiset voivat ymmärtää, mitä tapahtui. Se tarvitsee eskalaation, joka sisältää kysymyksen ja näytön, ei epämääräistä avunpyyntöä. Se tarvitsee jatkamisen, joka on päätös, ei käyttökatkoksen loppu.

Euroopan tekoälyasetus on oikeassa käyttäessään intervention ja turvallisen pysäyttämisen kieltä korkean riskin järjestelmistä. Se antaa hallinnolle konkreettisen reunan. Se pyytää järjestelmiä suunnittelevia ja käyttöön ottavia ihmisiä tekemään ihmisen hallinnan mahdolliseksi käytön aikana, ei vain periaatteessa ihailtavaksi. Komission aiempi luotettavaa tekoälyä koskeva työ ja ENISAn elinkaarilähestymistapa vahvistavat saman suunnan: valvonta kuuluu järjestelmän toimintaan, sen näyttöön ja sen ympäröivään toimitusketjuun.

At Dweve, we prefer the unromantic version of this idea. A serious system should know its states, its limits and its owner. It should be able to hold work, show why it held it, and stop honestly when the evidence is not enough. That is not a special virtue of one architecture. It is the minimum respect owed to the people who have to live with the result.

When the model is wrong, the decisive question is not whether a human was technically present. It is whether a named human authority could change what happened next, and whether the organisation could remember the change. If the answer is yes, oversight is doing its job. If the answer is no, the system has a person nearby, a button somewhere and no brake.

Sources