Suuririskinen järjestelmä ei ole suuririskinen malli

Risk ei asu mallin sisällä kuin varoitustarra. Se syntyy käyttötarkoituksesta, käyttöönotosta, auktoriteetista, rajapinnoista ja ihmisistä, joiden on...

Suuririskinen järjestelmä ei ole suuririskinen malli

Merkintä kiinnitetään käyttötarkoitukseen, ei laatikkoon

Malli voidaan kopioida palvelimelta toiselle ilman, että se oppii mitään. Sen painot, koodi ja mainostetut ominaisuudet voivat pysyä muuttumattomina. Silti kysymys, jonka Eurooppa esittää sen ympärillä olevasta asiasta, voi muuttua täysin. Mihin sitä käytetään? Kuka sitä käyttää? Kenen asemaa se voi muuttaa? Mikä tietue päätyy työnkulkuun? Kuka voi kyseenalaistaa vastauksen, korjata sen, pysäyttää sen tai selvittää myöhemmin, miksi sitä noudatettiin?

Tämä ei ole yritys tehdä yksinkertaisesta aiheesta suurempaa kuin se on. Kyse on tavallisesta erosta komponentin ja järjestelmän välillä. Jarrulevy ei ole maantieajoneuvo. Taulukkolaskennan kaava ei ole veropäätös. Yleiskäyttöinen tekoälymalli ei itsessään ole jokainen tekoälyjärjestelmä, joka sen ympärille voidaan myöhemmin rakentaa. Eroa on helppo nyökytellä hyväksyen, mutta se on hämmästyttävän helppo menettää, kun hankintakokouksessa aletaan puhua mallista ikään kuin se sisältäisi jo koko tulevan käyttöönoton.

EU:n tekoälyasetus pitää eron näkyvillä. Se määrittelee tekoälyjärjestelmän ja erikseen yleiskäyttöisen tekoälymallin. Sen korkean riskin säännöt koskevat tekoälyjärjestelmiä erityisissä olosuhteissa, mukaan lukien järjestelmiä, jotka ovat säänneltyjen tuotteiden turvakomponentteja, sekä järjestelmiä, joita käytetään luetelluilla aloilla. Asetus tekee myös käyttötarkoituksesta keskeisen tekoälyjärjestelmän luokittelussa ja dokumentoinnissa. Se ei kehota tiimiä osoittamaan mallin nimeä, kiinnittämään punaista, keltaista tai vihreää merkintää ja julistamaan työtä tehdyksi.

Tämän pitäisi olla vapauttavaa yhtä lailla kuin vaativaa. Mallilla ei ole pysyvää moraalista horoskooppia. Huolellinen analyysi voi olla kapea, kun käyttötarkoitus on kapea, ja se voi muuttua vakavaksi, kun auktoriteetti, altistuminen ja seuraukset muuttuvat vakaviksi. Ongelma on siinä, että analyysin on seurattava todellista järjestelmää. Ei demoa. Ei toimittajan esitystä. Ei sitä harmitonta tehtävää, jolla projekti aloitettiin kuusi kuukautta sitten. Järjestelmää, joka vastaanottaa syötteitä, asettaa tuotokset saataville, muokkaa päätöstä ja jota käytetään tavallisena tiistaina.

Tarkastellaan tarkoituksella hypoteettista esimerkkiä. Sama kielimalli yhdistetään ensin sisäiseen tiedonhakutyökaluun. Se hakee politiikan kohtia koulutetulle kollegalle, joka voi avata alkuperäisen lähteen ja kirjoittaa oman vastauksensa. Myöhemmin organisaatio yhdistää mallin ilmoittautumislomakkeeseen, asettaa sen suosituksen tapausrekisterin kärkeen, soveltaa ajastinta tapaukseen ja tekee suosituksen hyväksymisestä nopeimman tavan tyhjentää jono. Muutoksen näkemiseen ei tarvita kuvitteellista lautakuntaa, potilasta, työntekijää tai tapausta. Malli voi olla identtinen. Tuotoksen rooli, datapolku, kannustin, asianomainen henkilö ja käyttöliittymän käytännön auktoriteetti eivät ole.

Tämä on artikkelin väite: korkean riskin järjestelmä ei ole korkean riskin malli. Malli voi olla tärkeä osa järjestelmää, ja sillä voi olla omia velvollisuuksiaan. Mutta riskianalyysistä tulee merkityksellinen vasta, kun se ulottuu käyttötarkoitukseen, käyttöönoton kontekstiin, käyttäjiin, asianomaisiin henkilöihin ja jatkointegraatioon. Nämä yksityiskohdat eivät ole suunnittelun jälkeen liitettyä paperityötä. Ne ovat olosuhteita, jotka antavat tuotokselle institutionaalisen voiman.

Kohdista tai valitse kerros. Malli on yksi kerros; seuraus syntyy vasta, kun kerrokset kohtaavat.

Eurooppa käyttää tietoisesti kahta eri substantiivia

Ero alkaa asetuksen määritelmistä. Tekoälyjärjestelmä on konepohjainen järjestelmä, joka on suunniteltu toimimaan vaihtelevalla autonomian tasolla ja joka voi osoittaa mukautumiskykyä käyttöönoton jälkeen, ja joka päättelee syötteistä, miten tuottaa ennusteita, sisältöä, suosituksia tai päätöksiä, jotka voivat vaikuttaa fyysiseen tai virtuaaliseen ympäristöön. Yleiskäyttöinen tekoälymalli on erilainen: se on tekoälymalli, joka pystyy suoriutumaan pätevästi laajasta joukosta erilaisia tehtäviä riippumatta siitä, onko se saatettu markkinoille, ja joka voidaan integroida monenlaisiin alavirran järjestelmiin tai sovelluksiin.

Nämä määritelmät menevät arkikeskustelussa päällekkäin, koska sama sana, tekoäly, tekee paljon palkatonta työtä. Arvioinnissa niiden ei pitäisi mennä päällekkäin. Yleiskäyttöinen malli on tehty liikkumaan. Sen mahdolliset käyttötarkoitukset ovat tarkoituksella laajat. Tekoälyjärjestelmä on toiminnallinen järjestely, jonka kautta tuotokset vaikuttavat ympäristöön. Sillä on käyttötarkoitus, konfiguraatio, rajapinta ja toimintaympäristö. Se voi sisältää mallin, useita malleja, deterministisiä sääntöjä, tietokantoja, antureita, ihmisiä, prosesseja ja suuren määrän pieniä päätöksiä, joita kukaan ei kutsu tekoälyksi ennen kuin ne epäonnistuvat.

Siksi yleiskäyttöisen tekoälymallin tarjoaja ja tekoälyjärjestelmän tarjoaja tai käyttöönottaja eivät voi vain vaihtaa tarkistuslistoja keskenään. Komission ohjeistus yleiskäyttöisistä tekoälymalleista edellyttää, että mallin tarjoajien on asetettava tiedot ja dokumentaatio alavirran tekoälyjärjestelmien tarjoajien saataville, jotta nämä voivat ymmärtää mallin ominaisuudet ja rajoitteet ja täyttää omat velvoitteensa. Tämä virke on kiinnostavampi kuin miltä se ensin näyttää. Se olettaa, että alavirran tarjoajalla on työtä, jota mallin tarjoaja ei voi tehdä loppuun. Mallin dokumentaatio kulkee matkassa, mutta se ei vie matkaa loppuun.

Tässä on käytännön nöyryyttä. Mallin tarjoaja voi kuvata arkkitehtuurin, koulutusprosessin, arvioinnin, aiottuja tehtäviä, integrointivaatimukset, syötteet ja tuotokset, rajoitteet ja tunnetut ehdot. Alavirran tiimi tietää, onko käyttäjä koulutettu asiantuntija, voiko vaikutuksen kohteena oleva henkilö riitauttaa lopputuloksen, onko suositus nimellisesti neuvoa antava mutta käytännössä sitova, muuttaako kutsu ulkoiseen palveluun tietuetta ja voidaanko virheellinen toimenpide peruuttaa. Kummallakaan osapuolella ei ole yksin täydellistä kuvaa.

Jako ei ole porsaanreikä. Se on vastuun kartta. Se sanoo, että järjestelmää ei voi hallita pyytämällä mallin tarjoajaa lupaamaan hallintaa käyttöönotosta, jota he eivät operoi eivätkä näe. Se sanoo myös, että integroija ei voi vedota tietämättömyyteen silloin, kun dokumentaatio tekee merkittävän rajoitteen näkyväksi. Tarkoitus ei ole järjestää siistiä luovutusta oikeushenkilöiden välillä. Tarkoitus on olla kadottamatta kysymystä niiden väliseen rakoon.

Ensimmäisen erottelun rinnalle kannattaa pitää toinen. Korkean riskin luokitus ei sinänsä merkitse lupaa, turvallisuutta, oikeudenmukaisuutta tai lainmukaisuutta. Euroopan tietosuojaneuvosto ja Euroopan tietosuojavaltuutettu korostivat alkuperäistä komission ehdotusta koskevassa yhteisessä lausunnossaan, että luokittelu korkean riskin järjestelmäksi ei välttämättä tarkoittanut, että järjestelmä olisi sellaisenaan lainmukainen tai että sen käyttäjä voisi ottaa sen sellaisenaan käyttöön. Lopullinen säädös on muuttanut oikeudellista maisemaa tuon lausunnon jälkeen, mutta taustalla oleva varoitus on edelleen hyödyllinen. Luokittelu on sääntelyyn liittyvä ehto. Se ei ole kuitti siitä, että toimielin voi lopettaa ajattelemisen.

Tämä on merkityksellistä, koska korkean riskin merkintä voi johtaa kahteen vastakkaiseen virheeseen. Toinen tiimi voi pitää sitä pysyvänä leimana mallissa ja päättää, että ratkaisu on yksinkertaisesti olla katsomatta pidemmälle. Toinen voi pitää suoritettua vaatimustenmukaisuusprosessia lupalappuna mihin tahansa myöhempään käyttöyhteyteen. Molemmat lähestymistavat korvaavat merkinnän perustelulla. Eurooppa on valinnut hankalamman lähestymistavan: tunnista järjestelmä, sen käyttötarkoitus ja sen rooli, ja tarkastele sitten asiaankuuluvia riskejä ja velvoitteita sen elinkaaren ajan.

Käyttötarkoitus antaa analyysille suunnan

Käyttötarkoitus kuulostaa vaatimattomalta, melkein hallinnolliselta. Se ei ole sitä. Säädös määrittelee sen käytöksi, johon tekoälyjärjestelmä on sen tarjoajan tarkoittama, mukaan lukien tarjoajan toimittamissa tiedoissa määritellyt erityinen käyttöyhteys ja käyttöehdot. Toisin sanoen käyttötarkoitus ei ole iskulause tuotesivulla. Se sisältää käyttöyhteyden ja ehdot, joissa tarjoaja ilmoittaa järjestelmää käytettävän. Hyödyllisellä käyttötarkoituksen kuvauksella on rajat. Se kertoo, mitä järjestelmä tekee, kenelle, millä syötteillä, missä työnkulussa ja missä sen toimivalta päättyy.

Vertaa kahta kuvausta. Ensimmäinen sanoo, että järjestelmä käyttää tekoälyä auttaakseen organisaatioita tekemään parempia päätöksiä. Se on riittävän laaja sopiakseen konferenssitaustalle ja liian laaja toimiakseen. Toinen sanoo, että järjestelmä esittää lähdeviitteisiin sidottuja luonnosyhteenvetoja olemassa olevasta asiakirja-aineistosta koulutetuille tarkastajille; se ei voi tehdä, välittää tai toimeenpanna päätöstä; tarkastajan on varmistettava viitatut lähteet ennen yhteenvedon käyttöä; ja toiminto ei ole käytettävissä luokissa, jotka edellyttävät erillistä lakisääteistä menettelyä. Toinen kuvaus on vähemmän jännittävä. Se on myös sellainen, josta insinööri, hankintavastaava, vaatimustenmukaisuudesta vastaava kollega ja asianomainen henkilö voivat eri mieltä konkreettisin termein.

Käyttötarkoituksen ei tarvitse olla yksi lause. Vakavassa järjestelmässä se on yleensä tiivis kokonaisuus: tehtävä, tuotos, käyttäjä, kohderyhmä, toimintaympäristö, toimivalta, poikkeukset, riippuvuudet ja ehdot. Säädöksen teknistä dokumentaatiota koskevat vaatimukset jättävät tilaa juuri tällaiselle kuvaukselle. Liitteessä IV pyydetään yleiskuvausta tekoälyjärjestelmästä, mukaan lukien käyttötarkoitus, henkilöt ja ryhmät, joihin sitä on tarkoitus kohdistaa, sekä erityiset versiot tai muodot, joissa se saatetaan markkinoille. Siinä pyydetään myös kuvauksia järjestelmäarkkitehtuurista, datavaatimuksista, ihmisen valvontaa koskevista toimenpiteistä, elinkaaren seurannasta ja riskinhallintatoimenpiteistä. Dokumentaatiolla on tämä laajuus, koska pelkkä mallikortti ei voi kuvata käyttöönottoa.

Käyttötarkoitus on myös se kohta, jossa tiimi huomaa kuvanneensa kunnianhimoa eikä toimintaa. Ilmaus "tuemme käsittelijöitä" voi kätkeä tusinan erilaisia järjestelyjä. Etsiikö työkalu asiakirjoja, järjestääkö se työtä, luonnosteleeko se vastauksen, suositteleeko luokkaa, hylkääkö hakemuksen, nostaa hälytyksen, asettaako prioriteetin vai kutsuuko se toista palvelua? Käyttääkö kollega sitä ennen oman riippumattoman näkemyksen muodostamista vai sen jälkeen? Onko tuotos ehdotus sivupaneelissa vai kenttä, joka on pakko tyhjentää ennen kuin tietue voi edetä? Onko vaikutus välitön, viivästynyt, peruutettavissa vai vaikeasti havaittavissa? Vastaus muuttaa järjestelmää, vaikka käyttöliittymä näyttäisi tutulta.

Palveluntarjoajan ilmoittama käyttötarkoitus ei voi saada todellisuutta katoamaan. Tiimi ei voi antaa järjestelmälle laajaa käytännön toimivaltaa, kuvata sitä vaarattomaksi avustajaksi ja odottaa, että kuvaus ratkaisee asian. Mutta asianmukaisesti rajattu käyttötarkoitus on silti hallintakeino. Se kertoo käyttäjille, mitä näyttöä on otettu huomioon, kertoo integroijille, mitä he eivät saa huolettomasti laajentaa, ja kertoo arvioijille, mikä muutos avaisi arvioinnin uudelleen. Epämääräinen käyttötarkoitus muuttaa jokaisen myöhemmän kysymyksen väittelyksi siitä, mitä on tarkoitettu. Rajattu käyttötarkoitus antaa organisaatiolle mahdollisuuden kysyä, tekeekö se edelleen sitä, minkä se hyväksyi.

Tämä korostuu erityisesti silloin, kun organisaatio tekee olennaisen muutoksen. Asetuksessa on säännöksiä tilanteista, joissa jakelija, maahantuoja, käyttöönotaja tai muu kolmas osapuoli voi tulla palveluntarjoajaksi, mukaan lukien tilanteet, joissa se saattaa järjestelmän markkinoille omalla nimellään, tekee olennaisen muutoksen tai muuttaa käyttötarkoitusta tavalla, joka saa järjestelmän muuttumaan suuren riskin järjestelmäksi. Tarkka lain soveltaminen riippuu tosiseikoista, ja se on tarkistettava asiayhteydessä. Toiminnallinen opetus on yksinkertaisempi: integraatiomuutos voi olla hallinnollinen tapahtuma. Mallin tuotoksen siirtäminen luonnosruudusta päätösjonoon voi olla samalla tuotemuutos, työnkulkumuutos ja vastuullisuusmuutos.

Konteksti ei ole kulissi

Käyttökontekstiin suhtaudutaan usein osana, joka tulee vasta varsinaisen työn jälkeen: luettelo maita, hosting-valinta, muutama käyttäjäpersoona, ehkä kaavio, jonka nuolet osoittavat kuuliaisesti vasemmalta oikealle. Mutta konteksti antaa riskille sen muodon. Samanlainen tuotos voi olla yhdessä ympäristössä harmiton ja toisessa seurauksiltaan merkittävä. Virheellinen täydennys kirjoitusavustimessa voidaan korjata seuraavassa lauseessa. Virheellinen priorisointi niukkojen resurssien työnkulussa voi ratkaista, minkä tiedoston henkilö näkee ensimmäisenä. Pistemäärä, joka näyttää yhdeltä monista syötteistä, voi muuttua ratkaisevaksi, jos kaikki muut syötteet ovat hitaita, epämääräisiä tai toisen tiimin takana.

Asetuksen suuren riskin lähestymistapa heijastaa tätä. 6 artikla yhdistää suuren riskin luokituksen järjestelmiin, jotka on tarkoitettu käytettäviksi tiettyjen tuotteiden turvallisuuskomponentteina, tai liitteessä III tarkoitettuihin järjestelmiin. Liite III luettelee alueita, joilla tekoälyjärjestelmät voivat olla suuren riskin järjestelmiä, koska ne on tarkoitettu määriteltyihin käyttötarkoituksiin, kuten tiettyihin biometrisiin käyttötarkoituksiin, kriittiseen infrastruktuuriin, koulutukseen ja ammatilliseen koulutukseen, työllisyyteen, keskeisten yksityisten ja julkisten palvelujen ja etuuksien saatavuuteen, lainvalvontaan, maahanmuuttoon ja rajavalvontaan sekä oikeuslaitoksen ja demokraattisten prosessien hallintoon. Oikeudellisella yksityiskohdalla on merkitystä, mutta myös kieliopilla. Siinä ei sanota, että tekninen artefakti olisi suuren riskin järjestelmä abstraktisti. Siinä toistetaan ilmaus tarkoitettu käytettäväksi.

6 artikla sisältää myös rajoituksen tietyille liitteessä III tarkoitetuille järjestelmille: niitä ei ole pidettävä suuren riskin järjestelminä, jos ne eivät aiheuta merkittävää riskiä haitasta luonnollisten henkilöiden terveydelle, turvallisuudelle tai perusoikeuksille, mukaan lukien se, etteivät ne vaikuta olennaisesti päätöksenteon tulokseen. Palveluntarjoajien on dokumentoitava tämä arviointi ennen järjestelmän saattamista markkinoille tai käyttöönottoa. Tämä ei ole yleinen poikkeuskortti. Se on muistutus siitä, että järjestelmän todellisella vaikutuksella on merkitystä. Hyödyllisessä analyysissa on riittävästi yksityiskohtia selittämään, miksi järjestelmä vaikuttaa tai ei vaikuta olennaisesti lopputulokseen. Jos tätä selitystä ei voi kirjoittaa ilman ympäripyöreitä ilmauksia, tiimi on oppinut jotain ennen julkaisua.

Kontekstiin kuuluu aika. Suosituksella laajan selvityksen alussa on erilainen vaikutus kuin suosituksella siinä vaiheessa, kun henkilöllä on yksi mahdollisuus toimittaa puuttuvaa materiaalia. Siihen kuuluu volyymi. Yksittäinen arvioija voi haastaa tuloksen, kun tapauksia saapuu viisi päivässä, ja noudattaa sitä oletusarvoisesti, kun niitä saapuu viisisataa ennen lounasta. Siihen kuuluu kieli. Arvioija, joka voi lukea todisteet omalla työkielellään, voi harjoittaa erilaista valvontaa kuin arvioija, joka saa jyrkän yhteenvedon materiaalista, jota hän ei voi itsenäisesti tarkastaa. Siihen kuuluvat paikallinen menettely, muutosoikeudet, henkilöstö, pääsy asiantuntijaan, varajärjestelyn saatavuus ja se, saavuttaako tulos henkilön, jolla on riittävästi toimivaltaa tehdä jotakin hyödyllistä.

Mikään tästä ei edellytä, että keksitty katastrofi olisi totta. Näin järjestelmät yksinkertaisesti toimivat. Muodollinen toimintaperiaate voi sanoa, että ihminen on mukana silmukkana, mutta järjestelmä voi silti olla toiminnallisesti automaattinen, jos henkilöllä ei ole aikaa, tietoa, toimivaltaa tai käytännön reittiä olla eri mieltä. Asetuksen 14 artikla puhuu siksi tehokkaasta ihmisen suorittamasta valvonnasta, joka on asianmukaista riskien, autonomian tason ja käyttökontekstin kannalta. Se edellyttää, että korkean riskin järjestelmät suunnitellaan ja kehitetään niin, että ihmiset voivat ymmärtää olennaiset ominaisuudet ja rajoitukset, pysyä tietoisina taipumuksesta luottaa automaattisesti tulokseen, tulkita tulosta oikein, päättää olla käyttämättä sitä, ohittaa tai kumota sen ja pysäyttää järjestelmä turvallisesti tarvittaessa. Nämä ovat toiminnallisia kysymyksiä. Niihin ei voi vastata pelkällä mallin vertailuarvolla.

Valitse käyttöönoton muoto. Malli pysyy paikallaan; järjestelmän raja, toimivalta ja tarvittava näyttö eivät pysy.

Käyttäjät ovat osa ohjauspintaa

On houkuttelevaa puhua käyttäjistä ikään kuin he istuisivat järjestelmän ulkopuolella näppäimistön ääressä ja hoitaisivat ihmisen osuuden. He ovat osa toimintajärjestelyä. Heidän tietonsa, työmääränsä, toimivaltansa, kannustimensa ja avun reitit määräävät, mitä tuloksella tehdään. Järjestelmä, joka on suunniteltu asiantuntijalle, joka voi tarkastaa lähdemateriaalin, ei ole automaattisesti sopiva yleisasiantuntijalle, jonka odotetaan työskentelevän vauhdikkaasti. Työkalu, joka on hyödyllinen arvioijalle, joka voi hylätä suosituksen, ei ole automaattisesti sopiva kollegalle, joka voi vain napsauttaa hyväksyä tai odottaa jotakuta muuta.

Tämä ei tarkoita, että käyttäjän pitäisi joka kerta kyseenalaistaa jokainen komponentti. Sellainen olisi outo määritelmä hyödylliselle teknologialle. Se tarkoittaa, että valvonnasta pitäisi suunnitella todellinen työtehtävä. Henkilön on tiedettävä, milloin järjestelmää käytetään, mikä olennainen rajoitus on, mitä näyttöä on saatavilla, minkälaisen eriävän kannan hän voi kirjata ja mitä kirjaamisen jälkeen tapahtuu. Hän tarvitsee vastuuta vastaavan toimivallan. Pyytää ihmistä valvomaan tulosta, jota hän ei voi keskeyttää, korjata tai ohjata, ei ole ihmisen valvontaa vaan ihmisen koristelua.

Asetuksessa käyttöönottajille on oma roolinsa. 26 artikla edellyttää, että suuririskisten järjestelmien käyttöönottajat toteuttavat asianmukaisia teknisiä ja organisatorisia toimenpiteitä varmistaakseen, että he käyttävät järjestelmiä mukana toimitettujen ohjeiden mukaisesti. Se edellyttää, että käyttöönottajat osoittavat ihmisen valvonnan luonnollisille henkilöille, joilla on tarvittava pätevyys, koulutus ja toimivalta, ja että he seuraavat toimintaa ohjeiden perusteella. Tietyissä tapauksissa se edellyttää myös automaattisesti luotujen lokien pitämistä heidän hallinnassaan. Tämä ei ole pyyntö pitää asiantuntevaa henkilöä lähettyvillä siltä varalta, että käyttöliittymä hermostuu. Se on vaatimus järjestää toimintatapa.

Koulutuksesta puhutaan usein kuin se olisi koko vastaus. Se ei ole. Koulutus voi auttaa henkilöä tunnistamaan rajoituksen, mutta se ei voi luoda lähderekisteriä, jonka käyttöliittymä piilottaa. Se ei voi luoda aikaa, jonka jonojen suunnittelu kuluttaa. Se ei voi luoda toimivaltaa, jonka sopimus varaa muualle. Se ei voi korjata integraatiota, joka muuttaa varovaisen suosituksen peruuttamattomaksi toimeksi. Organisaation pitäisi tietenkin kouluttaa ihmisiä. Sen pitäisi myös tehdä se tehtävä, johon heitä koulutetaan, mahdolliseksi siinä järjestelmässä, jonka he todella saavat.

On olemassa hyödyllinen testi: kuvaile käyttäjän toiminta käyttämättä verbiä tarkastella. Mitä he lukevat? Mitä vertailua he voivat tehdä? Mitä he voivat hylätä? Minne perustelu menee? Kuka sen näkee? Mitä suositukselle tapahtuu hylkäämisen jälkeen? Voiko henkilö, johon tulos vaikuttaa, kysyä, mitä tapahtui? Voiko myöhempi kollega rekonstruoida olennaisen tilan? Jos vastaukset jäävät yleisluonteisiksi, valvonnan suunnittelu on todennäköisesti myös yleisluonteista.

Tämä testi pätee myös suuririskisten järjestelmien ulkopuolella. Lailla on tarkka soveltamisala ja päivämäärät; hyvä operatiivinen harkinta ei odota luokkamerkintää ennen kuin kysyy, onko henkilö asetettu näennäiseen rooliin. On täysin mahdollista rakentaa vähävaikutteinen työkalu, joka tekee ihmisistä tyhmempiä oman työnsä suhteen, koska tulos on liian sulava haastettavaksi. On myös mahdollista rakentaa rajoitettu työkalu, joka lisää henkilön kykyä esittää hyviä kysymyksiä, koska se säilyttää näytön, rajoittaa omaa toimivaltaansa ja tekee epävarmuudesta näkyvää. Malli voi vaikuttaa kumpaan tahansa lopputulokseen. Järjestelmä päättää, kummalle lopputulokselle on tilaa tapahtua.

Asianosaiset istuvat konsolin ulkopuolella

Monet tärkeimmistä ihmisistä tekoälyjärjestelmässä eivät koskaan kosketa sitä. He voivat olla hakija, oppilas, työntekijä, potilas, matkustaja, asukas, asiakas, vaatimuksen esittäjä, lainanhakija, todistaja tai yleisön jäsen. He eivät välttämättä tiedä, että malli oli mukana. He saattavat kokea vain vastauksen, joka saapuu nopeasti, pyynnön, joka viivästyy, palvelun, joka muuttuu saavuttamattomaksi, prioriteetin, joka muuttuu, tai päätöksen, jota näyttää mahdottomalta ymmärtää. Heidän poissaolonsa käyttöliittymästä ei tee heistä poissaolevia järjestelmästä.

Tämä on yksi syy siihen, miksi asetuksen riskikehys viittaa terveyteen, turvallisuuteen ja perusoikeuksiin. Se suuntaa huomion seurauksiin, joita ei voi pelkistää siihen, pitikö sisäänkirjautunut kollega työkalusta. Se on myös syy siihen, miksi käyttötarkoituksen kuvauksessa pitäisi nimetä henkilöt ja ryhmät, joihin järjestelmää on tarkoitus kohdistaa, kuten liite IV edellyttää. Järjestelmä, joka on rakennettu käyttäjä-kategorian ympärille, voi hiljaa kätkeä eron käyttöliittymää käyttävän henkilön ja tuloksen kanssa elävän henkilön välillä.

Vahingoittuneet ihmiset muuttavat kysymyksiä, joita tiimin on esitettävä. Onko olemassa keinoa tietää, että järjestelmällä oli merkityksellinen rooli? Perustuuko päätös tietoon, jota voidaan korjata? Vaikeuttaako kieli, vammaisuus, laite, sijainti tai hallinnollinen asema osallistumista? Saako käyttötiimi signaaleja vahingoittuneilta ihmisiltä vai vain kojelaudalta? Saavuttaako korjaus tiedon, suosituksen, päätöksen ja kaiken sen pohjalta laaditun jatkokopion? Nämä kysymykset eivät ole pyyntö muuttaa jokaista järjestelmää julkiseksi kuulemiseksi. Ne ovat pyyntö seurata seurausta riittävän pitkälle, jotta toisessa päässä näkyy ihminen.

Tietosuojalainsäädäntö on merkityksellistä, kun henkilötietoja käsitellään, rinnakkain tekoälyasetuksen viitekehyksen kanssa. Euroopan tietosuojaneuvosto ja Euroopan tietosuojavaltuutettu toivat tämän selvästi esiin vuoden 2021 yhteisessä lausunnossaan ehdotuksesta: olemassa olevaa EU:n tietosuojalainsäädäntöä sovelletaan ehdotuksen soveltamisalaan kuuluvaan henkilötietojen käsittelyyn. Tarkka oikeudellinen analyysi riippuu käsittelystä ja asianomaisista toimijoista. Hallinnon opetus on yksinkertainen. Luokitteluharjoitus ei voi kattaa kaikkia muita velvoitteita. Yksityisyys, syrjimättömyys, toimialakohtaiset velvoitteet, hallinto-oikeuden vaatimukset, kuluttajasäännöt ja sopimusvelvoitteet eivät katoa siksi, että tiimi on laatinut hyvännäköisen riskirekisterin.

On myös perustavanlaatuinen kysymys luettavuudesta. Ihmisen ei tarvitse tulla koneoppimisen asiantuntijaksi ymmärtääkseen, miten korjausta haetaan. Mutta järjestelmä ei saa käyttää teknistä monimutkaisuutta syynä tehdä korjauksesta mahdotonta. Hyvä reitti erottaa, mitä järjestelmä tallensi, mitä ihminen päätti, mitä näyttöä harkittiin, mikä on edelleen epävarmaa ja mitä voidaan vielä muuttaa. Se ei väitä sellaista tarkkuutta, jota tallenteet eivät voi tukea. Tällä alueella rehellisyys ei ole vain sävy. Se on osa palvelua.

Integraatio on kohta, jossa vastuut vaihtavat omistajaa

Tiimit piirtävät joskus tekoälyarkkitehtuurin siistinä ketjuna: malli, kehote, vastaus, käyttäjä. Todelliset käyttöönotot muistuttavat enemmän kunnallista karttaa sen jälkeen, kun joku on muistanut palveluputket. On identiteettijärjestelmiä, hakusäilöjä, työkaluoikeuksia, jonoja, skeemoja, välimuisteja, havainnointialustoja, selainlaajennuksia, eräajoja, hyväksyntäsääntöjä, säilytysasetuksia, toimittajia ja ihmisiä, jotka perivät tehtävän, koska edellinen henkilö on lähtenyt lomalle. Malli on tärkeä. Se on harvoin yksin.

Jokainen integraatio voi muuttaa sitä, mihin järjestelmä pystyy ja miten virhe liikkuu. Haku voi saada mallin tuotoksen näyttämään perustellulta, vaikka lähde on vanhentunut, puutteellinen tai virheellisesti rajattu. Työkalukutsu voi muuttaa luonnoksen tilamuutokseksi. Jono voi muuttaa oikea-aikaisen suosituksen myöhäiseksi. Orkestrointikerros voi valita eri mallin tai keoteversion. Käyttöliittymä voi piilottaa alemmassa kerroksessa olevan epävarmuuden. Identiteetti-integraatio voi antaa hyödylliselle työkalulle pääsyn aineistoon, jota käyttäjä ei muuten voisi avata. Mikään näistä havainnoista ei syytä tiettyä tuotetta tai organisaatiota. Ne kuvaavat tavallisia järjestelmän ominaisuuksia, mikä on juuri syy siihen, miksi ne pitäisi dokumentoida ennen kuin niistä tulee yllätyksiä.

Komission GPAI-ohjeistus on hyödyllinen tässä, koska se asettaa tiedon luovutuskohtaan. Dokumentaatio on tarkoitettu auttamaan alavirran toimittajia ymmärtämään mallin ominaisuuksia ja rajoituksia, sen aiottuja tehtäviä, teknisiä integraatiovaatimuksia, syötteen ja tuotoksen määrittelyjä sekä koulutusaineistotietoja. Tämä tieto on välttämätöntä. Se ei riitä. Alavirran tiimien on silti päätettävä, miten mallia kehotetaan, näytetäänkö tuotos näytön kanssa, mitkä työkaluoikeudet sallitaan, miten muutos testataan, mitä lokit säilytetään ja voiko suositus vaikuttaa tiettyyn työnkulkuun.

Tästä syystä mallipalvelun hankinta ei ole täydellisen riskitilanteen hankinta. Palveluntarjoajan dokumentaatio voi kertoa tiimille, että mallilla on tunnettu rajoite tai että se on arvioitu tietyissä olosuhteissa. Se ei voi todistaa, että ostajan oma hakemisto on ajan tasalla, että ostajan henkilöstöllä on tarvittavat valtuudet tai että asianomaisella henkilöllä on pääsy haasteväylälle. Vastaavasti ostaja ei voi vaatia, että mallipalvelun tarjoaja tuntee kaikki paikalliset käytännöt tai jatkoprosessit. Vastuullista ei ole teeskennellä, että toinen osapuoli voi tuntea koko järjestelmän. Vastuullista on tehdä rajapinnasta selkeä ja pitää näyttö liikkeessä sen yli.

Asetuksen 25 artikla tarjoaa hyödyllisen oikeudellisen kiinnekohdan tälle toiminnalliselle todellisuudelle. Siinä määritellään tilanteet, joissa muu kuin alkuperäinen tarjoaja katsotaan suuririskisen tekoälyjärjestelmän tarjoajaksi. Näitä ovat järjestelmän saattaminen markkinoille tämän osapuolen nimellä tai tavaramerkillä, olennaisen muutoksen tekeminen tai käyttötarkoituksen muuttaminen siten, että järjestelmästä tulee suuririskinen. Säännös on tekninen ja tosiseikkoihin perustuva; kukaan ei saa luokitella itseään blogikirjoituksen perusteella. Mutta sen suunta on selvä. Integrointi ja käyttötarkoituksen muuttaminen voivat muuttaa sen, kuka kantaa tarjoajan velvoitteet. Jatkokäyttöasetelma ei ole ikuisesti jatkokäyttöasetelma vain siksi, että alkuperäinen malli on tullut muualta.

On institutionaalinen syy ottaa tämä vakavasti. Kun vastuu vaihtuu hiljaisesti, turvallisuudesta ja hyvityksestä tulee organisatorista pöytätennistä. Mallin tarjoaja osoittaa käyttöönottoon. Käyttöönottaja osoittaa malliin. Integraattori osoittaa pilvipalveluun. Palvelun omistaja osoittaa kokoonpanoon, jota ei enää ole olemassa. Asianomaiset saavat viimeistellyn selityksen siitä, miten monimutkaista kaikki on. Se voi olla paikkansapitävää, mutta se ei ole vastaus. Järjestelmä tarvitsee kirjauksen siitä, mikä organisaatio omistaa kysymyksen kullakin rajapinnalla, ja reitin, jota pitkin kysymys kulkee, kun vastaus on muualla.

Dokumentaation tulisi kuvata järjestelmää, joka voi vielä muuttua

Teknisellä dokumentaatiolla on maine, että se valmistuu projektin lopussa hienoisen paniikin tuoksuisena. Asetus kuvaa toisenlaisen roolin. Suuririskisten järjestelmien tekniset asiakirjat on laadittava ennen järjestelmän saattamista markkinoille tai käyttöönottoa ja pidettävä ajan tasalla. Liitteen IV luettelo ulottuu mallin käyttäytymistä pidemmälle: käyttötarkoitus, versiot, järjestelmäarkkitehtuuri, kehitys, tietovaatimukset, validointi ja testaus, ihmisen suorittama valvonta, tarkkuus ja kyberturvallisuustoimenpiteet, riskienhallinta, muutokset ja markkinoille saattamisen jälkeinen seuranta. Tämä ei ole koristeellinen liite. Se on yritys säilyttää riittävästi muistia, jotta joku voi tarkastaa järjestelmän sen jälkeen, kun lanseerauskokouksesta on tullut perimätietoa.

Dokumentaatio toimii vain, kun se pystyy osoittamaan suhteet. Malliversio on yhdistettävä järjestelmäversioon, joka sitä käytti. Testi on yhdistettävä sen syöttöolosuhteisiin ja tarkoitukseen. Käytäntö on yhdistettävä valvontapisteeseen. Käyttäjärooli on yhdistettävä siihen valtuuteen, joka sillä on käyttöliittymässä. Lokituskäytäntö on yhdistettävä tapahtumaan, jonka se voi rekonstruoida. Muutos on yhdistettävä arviointiin, jonka se laukaisi. Muuten tiimillä on kirjasto hyviä asiakirjoja, mutta ei tapaa vastata tiettyyn kysymykseen.

Lokit ovat samankaltainen tapaus. 12 artikla edellyttää, että suuren riskin tekoälyjärjestelmillä on tekniset valmiudet tapahtumien automaattiseen tallentamiseen järjestelmän koko elinkaaren ajalta, suhteessa käyttötarkoitukseen. Lokit voivat tukea jäljitettävyyttä, markkinoille tulon jälkeistä seurantaa ja operatiivista valvontaa. Ne eivät selitä päätöstä taianomaisesti. Loki voi kertoa myöhemmälle tutkijalle, että työkalua kutsuttiin, että tietty versio oli käytössä tai että arvioija napsautti säätöä. Se ei yksinään pysty osoittamaan, ymmärsikö arvioija todisteet, oliko syötelähde luotettava tai oliko prosessi oikeudenmukainen. Tallenteet ovat arvokkaita, koska ne antavat tutkinnalle rehellisen lähtökohdan, eivät siksi, että ne poistaisivat harkinnan tarpeen.

Markkinoille tulon jälkeinen seuranta täydentää kokonaiskuvaa. 72 artikla edellyttää, että suuren riskin järjestelmien tarjoajat perustavat ja dokumentoivat markkinoille tulon jälkeisen seurantajärjestelmän suhteessa teknologioiden luonteeseen ja suuren riskin tekoälyjärjestelmän riskeihin. Tällä on yksinkertainen seuraus käyttöönottotiimeille: julkaisu ei ole hetki, jolloin järjestelmästä tulee täysin tunnettu. Organisaation on kyettävä vastaanottamaan olennaista tietoa, erottamaan signaali johtopäätöksestä, päättämään, pitääkö käyttötarkoituksen rajaus edelleen, ja tekemään muutos tai lopettamaan käyttö, kun näyttö sitä edellyttää.

Tämä työ ei ole loistokasta. Se näyttää versiotunnisteilta, selkeiltä julkaisukriteereiltä, riippuvuuksien kirjaukselta, testiltä peruutusreitille, nimitetyltä omistajalta rajoitteelle ja päätökseltä, joka pysyy näkyvissä myös sen jälkeen, kun päätöksen tehnyt henkilö vaihtaa tehtävää. Se näyttää siltä, että kysytään, onko integraatio muuttunut, ennen kuin kysytään, onko malli muuttunut. Se näyttää siltä, että säilytetään riittävästi näyttöä seurauksen korjaamiseksi sen sijaan, että sitä vain selitettäisiin jälkikäteen. Tylsyys ei ole tässä kunnianhimon vastakohta. Se on se osa, joka sovittaa kunnianhimon instituution sisään.

Miten tarkastella koko järjestelmää teeskentelemättä varmuutta

Täysi analyysi ei ole yritys löytää yleispätevää riskipisteytystä. Se on kysymysten sarja, joka tarkentuu suunnittelun tarkentuessa. Ensimmäinen kysymys on käyttötarkoitus: mitä tämän järjestelmän on tarkoitus tehdä, ja mitä sen ei erityisesti ole tarkoitus tehdä? Toinen on seuraus: keihin voidaan vaikuttaa, miten ja minkä päätöksen tai palvelun kautta? Kolmas on toimivalta: mikä tuotos voi muuttaa tilaa, vaikuttaa päätökseen, asettaa prioriteetin tai muuttaa sitä, mitä henkilö saa? Neljäs on näyttö: mikä tukee järjestelmän käyttöä tässä yhteydessä, ja mitkä ehdot saavat sen näytön välittymään?

Sitten tulevat epämukavat kysymykset. Mitä tapahtuu, kun malli on epävarma, väärässä, poissa käytöstä tai sitä käytetään ilmoitetun rajauksen ulkopuolella? Mitä muuttuu, kun lähde on vanhentunut tai työkalu evätään? Entä jos käyttäjä on kiireinen, uusi tehtävässään tai ei pysty tarkastelemaan taustalla olevaa materiaalia? Entä jos asianomainen henkilö pyytää oikaisua? Entä jos päivitys muuttaa kehotetta, hakukorpuksen, käyttöliittymän oletusarvoa, malliversiota tai roolin käyttöoikeuksia? Vastaus on joskus tekninen hallintakeino, joskus menettely, joskus suppeampi käyttö, joskus eri omistaja ja joskus päätös olla ottamatta käyttöön. Hallintamalli, joka ei koskaan salli viimeistä vastausta, on vain hyväksyntä hienommissa vaatteissa.

On hyödyllistä pitää useat väitteet erillään. Vahvistettu tosiasia kertoo, mitä mallin tarjoaja on dokumentoinut tai mitä organisaatio on havainnut määritellyssä testissä. Päätelmä kertoo, miksi kyseinen tosiasia voi olla merkityksellinen tietyssä työnkulussa. Ehdotettu hallintakeino kertoo, mitä tiimi aikoo toteuttaa. Jäännösriski kertoo, mitä hallintakeinon jälkeen jää. Oikeudellinen johtopäätös kertoo, mitä laki edellyttää. Nämä eivät ole keskenään vaihdettavissa. Hyvä asiakirja nimeää ne, koska lukija saattaa joutua haastamaan yhden hylkäämättä muita.

Esimerkiksi on mahdollista sanoa: palveluntarjoajan dokumentaatio toteaa, että mallilla on tietty rajoite; käyttöönottotiimi päättelee, että rajoite voi vaikuttaa määriteltyyn käyttötarkoitukseen; tiimi ehdottaa lähdetarkistuksen porttia; porttia ei ole vielä testattu suunnitellulla kuormituksella; ja lakiosaston on arvioitava syntynyt käyttö sovellettavan lain mukaan. Tämä lause on vähemmän tyydyttävä kuin vihreä valintamerkki. Se on hyödyllisempi kuin vihreä valintamerkki, koska se ei jätä arvailun varaa siitä, mikä on selvitetty ja mikä ei.

Tiimien on syytä olla erityisen tarkkoja sanan ihminen kanssa. Ihmisen rooli voi olla valvontakeino, mutta vain silloin, kun siihen liittyy määritelty tehtävä, riittävä tieto, aika, koulutus, toimivalta ja reitti toimia. Ihmisen roolista voi myös tulla tapa siirtää vastuu lähimpänä ruutua olevalle henkilölle. Ero ei ole filosofinen. Se näkyy työnkulussa. Jos arvioija voi vain hyväksyä, jos erimielisyys katoaa valvomattomaan kommenttikenttään tai jos kukaan ei voi korjata lopputuloksen seurauksia, järjestelmä ei ole saanut merkityksellistä valvontaa pelkästään siksi, että joku on klikannut jotakin.

Sama varovaisuus koskee läpinäkyvyyttä. Pitkä dokumentti voi tehdä järjestelmästä kuvailtavan tekemättä siitä kiistanalaista. Hallintapaneeli voi tehdä siitä näkyvän tekemättä siitä ymmärrettävää. Tietosuoja-ilmoitus voi kertoa käyttäjälle, että tekoäly on mukana, kertomatta, mitä virheen sattuessa voi tehdä. Hyödyllinen kysymys on käytännöllinen: voiko asianomainen henkilö löytää rajan, näytön, vastuuroolin ja korjausreitin siitä kohdasta, jossa näillä on merkitystä? Jos ei, tieto on väärässä paikassa, jotta hallinta voisi toteutua.

Pieni huomautus meiltä

Dwevellä julkinen Trust Centre käsittelee mallirekisteriä ja sen jälkeistä integraatiota toisiinsa liittyvinä mutta erillisinä rekistereinä. Sen jälkeisen vaiheen sivulla todetaan, että Loomia integroivien tai käyttöönottavien tiimien on tiedettävä nykyiset ominaisuudet, rajoitteet, rajapinnat, arviointikonteksti ja muutokset, kun taas julkinen rekisteri toteaa, että malli on yksi säie laajemmassa komponenttien ja toimintarajojen kudelmassa. Tämä on dokumentaation asenne, ei väite siitä, että julkinen sivu luokittelisi kaikki mahdolliset käyttöönotot tai todistaisi vaatimustenmukaisuuden integraattorille. Erottelun tarkoitus on vaatimattomampi: mallirekisterin tulisi kulkea integraation mukana teeskentelemättä korvaavansa integraattorin omaa järjestelmäanalyysiä.

Tämä on standardi, josta kannattaa pitää kiinni. Mallin tarjoajan tulisi tarjota hyödyllistä tietoa. Organisaation, joka ottaa mallin käyttöön tai integroi sen, tulisi kuvata todellinen järjestelmä, jonka se on rakentanut: tarkoitus, ihmiset, data, rajapinnat, toimivalta, seuranta ja korjaus. Kumpikaan osapuoli ei saisi käyttää dokumentaatiota seremoniallisena vaihtona, jossa toinen osapuoli saa PDF-tiedoston ja toinen synninpäästön.

Vaikeampi kysymys on yleensä parempi

Kun tiimi kysyy, onko malli suuren riskin malli, se voi hakea nopeaa vastausta järkevään huoleen. Mutta hyödyllisempi kysymys on yleensä pidempi: minkä järjestelmän rakennamme tästä mallista, mihin tarkoitukseen, missä kontekstissa, keiden kanssa, ja mitä tapahtuu, kun se on väärässä? Siihen kysymykseen ei voi aina vastata yhdessä kokouksessa. Se voi paljastaa, että suunniteltu käyttö on odotettua rajallisempaa, että näyttö on puutteellista, että käyttäjäroolilta puuttuu toimivalta, että sopimus jättää tärkeän rajan omistamatta tai että jälkeinen integraatio on hiljaa muodostunut järjestelmän keskipisteeksi.

Mikään näistä havainnoista ei ole innovaation epäonnistumista. Ne ovat asioita, jotka organisaatio oppii ennen kuin se antaa järjestelmälle vallan muokata toisen ihmisen vaihtoehtoja. Eurooppalainen lähestymistapa kuvataan usein velvoitteiden joukkona. Se on myös nimeämisen kurinalaisuutta: nimeä tarkoitus, toimija, konteksti, versio, asianomainen henkilö, rajoitus, näyttö ja puuttumisen reitti. Kun nämä on nimetty, niitä voidaan testata, muuttaa ja haastaa. Ennen kuin ne on nimetty, ne tapaavat ilmaantua myöhemmin yllätyksenä.

Malli voi olla kykenevä, huolellisesti dokumentoitu ja arvokas. Se voidaan myös sijoittaa järjestelmään, joka vaatii siltä liikaa, piilottaa liikaa käyttäjiltään tai jättää liian vähän tilaa tuloksen vaikutuspiirissä olevalle henkilölle. Ero syntyy painojen ulkopuolella. Siellä vaikea työ sijaitsee, ja siellä on myös vakava mahdollisuus: rakentakaa järjestelmiä, joiden auktoriteetti vastaa niiden näyttöä, joiden rajat kestävät integraation ja joiden käyttäjät voivat edelleen sanoa ei.

Lähteet