Tie, sairaala ja malli jakavat yhden ongelman: näyttö

Turvallisuuskriittiset järjestelmät epäonnistuvat eri tavoin, mutta ne vaativat saman kurinalaisuuden: väitteen sidottuna kontekstiin, todisteet, joita...

Tie, sairaala ja malli jakavat yhden ongelman: näyttö

Näytön on kestettävä luovutus

Tiesuunnittelija, sairaalatiimi ja mallintarjoaja voivat kaikki tuottaa vakuuttavan demonstraation. Liittymä voi näyttää siistiltä suunnitelmassa. Kliininen näyttö voi näyttää rauhalliselta työpajassa. Malli voi antaa järkevän vastauksen huolellisesti valitulla esimerkkijoukolla. Mikään näistä ei ratkaise sitä kysymystä, joka merkitsee, kun järjestelmä siirtyy tavalliseen arkeen: mikä näyttö tukee tätä nimenomaista toimenpidettä, näille ihmisille, näissä olosuhteissa, ja kenellä on oikeus muuttaa suuntaa, kun näyttö ei enää päde?

Tämä kysymys on hyödyllisempi kuin väittely siitä, onko tie, sairaala tai tekoälyjärjestelmä ”turvallinen”. Turvallisuus ei ole ominaisuus, joka saapuu pahvilaatikossa laitteen mukana. Se on jatkuva suhde tarkoituksen, ympäristön, ihmisjoukon, järjestelmän rajojen ja sen työn välillä, jota tehdään, kun raja saavutetaan. Tien on sovitettava yhteen ihmiset, jotka tekevät virheitä, ja olosuhteet, jotka muuttuvat. Kliinisen palvelun on säilytettävä harkintakyky, kun tieto on puutteellista, kiireellistä tai kiistanalaista. Tekoälyjärjestelmän on pysyttävä riittävän ymmärrettävänä, jotta ihminen voi nähdä, milloin sen tuotos on lakannut olemasta hyödyllinen panos päätökseen.

Euroopalla on jo osia tästä kurinalaisuudesta eri paikoissa. Tieinfrastruktuurin säännöt edellyttävät menettelyjä, kuten vaikutustenarviointia, auditointeja, turvallisuustarkastuksia ja koko tieverkon kattavaa arviointia. Tekoälysäädös edellyttää suuren riskin järjestelmillä elinkaarista riskienhallintaa, teknistä dokumentaatiota, lokitietoja, ihmisen valvontaa, asianmukaista tarkkuutta, vankkuutta ja kyberturvallisuutta. Eurooppalaiset terveydenhuollon toimijat käsittelevät turvallisuutta, oikeudenmukaisuutta, hallintoa, henkilöstön valmiutta ja vastuullisuutta yhdessä sen sijaan, että kohtelisivat kliinistä mallia ohjelmistona, joka muuttuu vaarattomaksi, koska sen käyttöliittymässä on stetoskooppi.

Yhteinen säie on näyttö. Ei näyttö paksuna kansiona, joka kootaan kerran, eikä näyttö tulostauluna imartelevine keskiarvoineen. Näyttö jonakin, joka on kiinnitetty väitteeseen, asiayhteyteen ja päätökseen. Hyödyllinen näyttötietue kertoo, mitä järjestelmän oli tarkoitus tehdä, missä väite pätee, mitkä havainnot tukevat sitä, mitkä oletukset sen alla ovat, mikä on edelleen epävarmaa, kuka voi puuttua asiaan ja mikä muutos tarkoittaa, että väite on harkittava uudelleen.

Tämä on vähemmän loistokas ajatus kuin autonomia. Se on myös kestävämpi. Se antaa insinööreille tavan ilmaista rajansa teeskentelemättä, että testijoukko on täydellinen maailma. Se antaa esihenkilöille tavan kysyä, mitä he todella hyväksyvät. Se antaa käyttäjille jotakin parempaa kuin kojelaudan, joka syttyy, kun päätöksestä on jo tullut vaikea. Tärkeintä on, että se antaa järjestelmän vaikutuspiirissä oleville ihmisille reitin lopputuloksesta takaisin niihin syihin ja olosuhteisiin, jotka sen tuottivat.

Kolme toimialaa, yksi hankala kysymys

Tie, sairaala ja malli eivät ole sama järjestelmä. Niiden haitat, lakisääteiset velvoitteet, näyttöperustat ja ammattikulttuurit eroavat toisistaan. Kukaan ei saa kopioida tieauditointia kliiniseen työnkulkuun tai liimata lääkinnällisen laitteen tarkistuslistaa kielimalliin ja julistaa työtä valmiiksi. Tarkoitus ei ole tasoittaa eroja. Tarkoitus on huomata yhteinen suunnitteluongelma: automatisoitu tai puoliautomatisoitu järjestelmä toimii laajemman ihmisten, menettelyjen, käyttöliittymien, ympäristöjen ja oletusten kokonaisuuden kautta.

Tie on erityisen selvä muistutus, koska se ei tee päätöksiä ihmisen mielessä. Se muovaa niitä. Geometria, näkymät, erottelut, risteykset, merkinnät, nopeuden hallinta, kunnossapito ja ympäröivä verkosto vaikuttavat siihen, mitä ihmiset näkevät, mistä he voivat toipua ja kuinka vakavaksi virhe muodostuu. Hyvä liikenneturvallisuuskäytäntö ei perustu fantasiaan jatkuvasti valppaasta ja täydellisesti informoidusta tienkäyttäjästä. Sen tavoitteena on tehdä ennakoitavista virheistä epätodennäköisempiä ja vähemmän rangaistavia. Euroopan tieinfrastruktuurin turvallisuuden hallinnan kehys heijastaa tätä järjestelmänäkökulmaa toistettavien arviointi- ja tarkastusprosessien kautta, ei yksittäisenä julistuksena siitä, että reitti on hyväksytty.

Sairaala on erilainen, mutta myös se elää puhtaan kuvauksen ja muuttuvan todellisuuden välisen eron kanssa. Kliinisellä hoitopolulla on henkilöstörooleja, luovutuksia, tietoja, laitteita, prioriteetteja, keskeytyksiä ja ihminen, jonka tila ei välttämättä muistuta sitä keskimääräistä tapausta, joka muokkasi protokollan. Suositus voi olla hyödyllinen ja silti riittämätön. Varoitus voi olla teknisesti oikea ja silti saapua hetkellä, jolloin sen mukaan ei voi turvallisesti toimia. Järjestelmä voi parantaa yhtä osaa työnkulusta ja samalla luoda uuden taakan jonnekin muualle. Siksi keskustelu tekoälystä terveydenhuollossa ei voi pysähtyä mallin näennäiseen suorituskykyyn. Sen on katettava hallinto, kliininen vastuu, tietojen laatu, koulutus, julkinen luottamus sekä keinot vahingon tunnistamiseen ja korjaamiseen.

Malli istuu samanlaisessa järjestelyssä. Se on koulutettu tai määritetty jossakin, yhdistetty tietoihin jossakin muualla, sille annetaan kehote tai tehtävä ihmisen toimesta, se asetetaan käyttöliittymän taakse, jotkut ihmiset seuraavat sitä ja toiset eivät. Se tuottaa tulosteen, mutta tulosteesta tulee merkityksellinen vasta, kun joku kohtelee sitä syynä toimia. Tulosteen ja toiminnan välissä ovat kynnykset, auktoriteetti, aikapaine, pääsy lähdemateriaaliin, koulutus, kannustimet ja eriävän mielipiteen mahdollisuus. Nämä eivät ole koristeellisia toiminnallisia yksityiskohtia. Ne ratkaisevat, pysyykö teknisesti pätevä osa suuremman järjestelmän turvallisena osana.

Ajattele seuraavaa nimenomaisesti hypoteettisena yhdistelmänä, ei kuvauksena todellisesta tiestä, sairaalasta, potilaasta, työntekijästä tai tapahtumasta. Paikallinen viranomainen harkitsee järjestelmää, joka merkitsee sijainteja liikenneturvallisuuskatsausta varten. Sairaala harkitsee työkalua, joka auttaa lajittelemaan hallinnollisia asiakirjoja ennen kuin kliininen henkilöstö näkee ne. Kolmas organisaatio harkitsee mallia, joka luonnostelee riskitiivistelmän infrastruktuurin hallinnoijalle. Kussakin ympäristössä varhainen esittely osoittaa, että järjestelmä voi löytää kaavoja olemassa olevista tiedoista. Esittely ei vielä vastaa siihen, edustavatko tiedot niitä olosuhteita, joita palvelu kohtaa ensi kuussa, voidaanko epätavallinen tapaus tunnistaa, onko suosituksen vastaanottajilla riittävästi aikaa ja auktoriteettia sen kyseenalaistamiseen, tai huomaako organisaatio haitallisen kaavan ennen kuin siitä tulee normaalia työtä. Todisteongelma alkaa täsmälleen siitä.

Helppo virhe on pyytää yhtä lukua. Mikä on tarkkuus? Kuinka paljon aikaa se säästää? Kuinka monta riskiä se havaitsee? Nämä kysymykset ovat oikeutettuja mutta epätäydellisiä. Luku tarvitsee nimittäjän, otoksen, määritelmän, päivämäärän, käyttötarkoituksen ja selvityksen siitä, mikä jätettiin pois. Se tarvitsee myös yhteyden seuraavaan päätökseen. Korkea pistemäärä kapeassa ja vakaassa tehtävässä voi tukea kapeaa ja vakaata väitettä. Se ei voi hiljaisesti valtuuttaa erilaista työnkulkua, erilaista väestöä tai päätöstä, jolla on erilaiset seuraukset.

Todisteet eivät ole koristeellinen lisä

Näytöstä tulee hyödyllistä, kun se voi muuttaa jonkun mielipiteen. Se kuulostaa itsestäänselvyydeltä, mutta monet näyttökokonaisuudet rakennetaan näyttämään kattavilta sen sijaan, että ne tekisivät päätöksestä haastettavan. Ne sisältävät kuvakaappauksia, toimintaperiaatteita, testitiivistelmiä ja allekirjoituksia, mutta eivät osoita, mitä väitettä kukin kohta tukee, mikä ehto rajaa väitettä tai mitä pitäisi tapahtua, jos ehto muuttuu. Tuloksena on asiakirjoja, joilla on seremoniallinen rooli. Ne voivat todistaa, että kokous pidettiin. Ne eivät välttämättä kerro käyttäjälle, mitä tehdä kello 07:40, kun palvelu on ruuhkautunut, tiedot ovat myöhässä ja suositus ei sovi käsillä olevaan tapaukseen.

Parempi lähtökohta on nimetty päätös. Ei "otetaan tekoäly käyttöön vastuullisesti" eikä "parannetaan liikenneturvallisuutta", vaan rajattu väite. Esimerkiksi: tämä järjestelmä voi priorisoida määritellyn luokan arviointitehtäviä määritellyssä toimintaympäristössä, kun nimetty rooli vastaa suosituksen hyväksymisestä tai hylkäämisestä. Tai: tämä suunnitelma voidaan avata liikenteelle, kun tunnistetut vaarat on arvioitu vaaditun prosessin mukaisesti ja tunnistetut hallintatoimet ovat käytössä. Sanamuoto on tarkoituksella vähemmän jännittävä kuin tuotejulistus. Se on sopimus todellisuuden kanssa.

Kun päätös on nimetty, muulle tallenteelle on paikka, johon kiinnittyä. Tarkoitettu käyttötarkoitus kertoo lukijalle, mitä ei pidä päätellä. Konteksti kertoo, millä toimipaikalla, missä työnkulussa, keille käyttäjille ja minkä tiedon, laitteiston ja ympäröivän prosessin osalta asia on merkityksellinen. Näyttö tallentaa testit, havainnot, lähdemateriaalin, arvioinnit ja harjoitukset. Oletukset tekevät riippuvuudet näkyviksi: ehkä käyttäjällä on koulutus, ehkä lähderekisteri on ajan tasalla, ehkä tietty hälytys tavoittaa tietyn roolin ajoissa. Omistaja määrittää, kuka saa tulkita materiaalia ja puuttua asiaan. Arvioinnin laukaisijat kertovat, mikä signaali, muutos tai oletuksen pettäminen edellyttää uutta tarkastelua.

Näytöstä tulee toiminnallista, kun lukija voi jäljittää väitteen sen ehtoihin, toimivaltaan ja arviointireittiin.

Tällä rakenteella on tärkeä seuraus. Se estää näytön irtaantumisen käytöstä. Testi ei ole vain tallennettu "validointi"-kategoriaan. Se on yhdistetty väitteeseen tietystä käyttäytymisestä määritellyissä olosuhteissa. Auditointi ei ole vain todiste siitä, että auditoija kävi. Siitä tulee tallenne siitä, mitä tutkittiin, mitä löydettiin, mikä jäi epävarmaksi ja mikä toimivalta päätti, mitä seuraavaksi tapahtuu. Mallin arviointi ei ole yleinen merkki. Se on rajattu havainto, jonka merkitys riippuu mallin versiosta, tehtävästä, tiedosta, kokoonpanosta ja käyttöönotto-olosuhteista.

Sama tietue tekee poissaolon näkyväksi. Jos kukaan ei ole testannut järjestelmää epätavallisella mutta seurauksiltaan merkittävällä syötteellä, se ei ole pieni nolous, joka pitäisi piilottaa keskiarvon alle. Se on todisteiden raja. Jos ihminen voi teknisesti ohittaa suosituksen, mutta hänellä ei ole aikaa, pääsyä tai valtuuksia tehdä niin todellisessa työnkulussa, se ei ole merkityksellistä valvontaa. Se on suunnittelun aukko. Jos tieliikenneturvallisuustarkastus havaitsee toistuvan olosuhteen, mutta mikään organisaatio ei omista korjaavaa työtä, havainto ei ole vielä muuttunut hallintakeinoksi. Vakavissa järjestelmissä puuttuva todiste on tulos. Se kertoo organisaatiolle, missä se ei voi vielä tehdä väitettä.

Tieliikenneturvallisuus tarjoaa käytännön opetuksen nöyryydestä

Tieliikenneturvallisuus on oppinut vuosikymmenten aikana, että haitta selittyy harvoin yksittäisellä huonolla toimijalla tai yksittäisellä huonolla osalla. Liian nopeasti ajava henkilö, vaikeasti luettava ylityspaikka, ajoneuvo, sää, valaistus, kunnossapidon tila, liikenteen koostumus ja hätätoimet voivat kaikki vaikuttaa. Tämä ei poista yksilön vastuuta. Se estää pinnallisen johtopäätöksen, että jokainen epäonnistuminen voidaan korjata kehottamalla ihmisiä kiinnittämään enemmän huomiota. Järjestelmä, joka toimii vain silloin, kun kukaan ei tee ennakoitavissa olevaa virhettä, ei ole vaikuttavan tiukka järjestelmä. Se on hauras.

EU:n tieliikenneinfrastruktuurin turvallisuuden hallintaa koskevat säännöt tarjoavat hyödyllisen vastapainon ajatukselle, että hyväksyntä on kertaluonteinen tapahtuma. Ne järjestävät turvallisuustyön menettelyjen ympärille, jotka tarkastelevat ennakoitavia seurauksia, suunnittelua, käyttöä ja olemassa olevaa verkkoa. Tarkka oikeudellinen soveltamisala on tärkeä, ja sääntöjä tulisi lukea tieliikenneinfrastruktuurin lainsäädäntönä eikä yleisenä mallina jokaiselle teknologialle. Silti niiden taustalla oleva tapa on laajalti arvokas: tarkasta järjestelmä olosuhteissa, joissa se toimii, etsi kaavoja sen sijaan, että odotat dramaattista tapahtumaa, ja kohtele tietoa syynä järjestelyn säätämiseen.

Tämä tapa ei ole yksinkertaisesti "kerää lisää dataa". Data ilman kysymystä on erittäin tehokas tapa varastoida hämmennystä. Tieliikenneturvallisuuden kysymys voi koskea sitä, missä ylityspaikka luo konfliktin, ketkä ihmiset ovat sille alttiina, kuinka usein olosuhteet esiintyvät, millainen virhe on ennakoitavissa, mitkä fyysiset tai toiminnalliset toimenpiteet vähentävät riskiä ja miten organisaatio tietää, onko toimenpide muuttanut tilannetta. Merkityksellinen todiste on siis monimuotoista. Se sisältää liikenneolosuhteet, suunnitteluasiakirjat, tarkastushavainnot, kunnossapitotiedot, haittaraportit ja ammatillisen harkinnan. Kartta yksinään ei voi kantaa väitettä. Eikä yksittäinen törmäystilasto voi.

Tässä on hyödyllinen inhimillisten tekijöiden näkökohta. Järjestelmä on suunniteltava ihmisille sellaisina kuin he ovat, ei kuvitteelliselle käyttäjälle, joka lukee jokaisen merkin, arvioi jokaisen nopeuden täydellisesti eikä koskaan saavu häiriintyneenä, väsyneenä, kokemattomana, kiireisenä, sairaana tai yksinkertaisesti yllättyneenä. Tämä ei ole tekosyy huolimattomalle käytökselle. Se on tunnustus siitä, että turvallisuustekniikan on toimittava aikeen ja todellisen inhimillisen kyvykkyyden välisessä tilassa. Kun järjestelmä luottaa siihen, että ihminen huomaa, ymmärtää ja toimii, nämä kolme vaihetta tarvitsevat omaa näyttöään. Voiko signaalin nähdä? Voiko sen merkityksen ymmärtää? Voiko ihminen toimia ajoissa ja riittävillä valtuuksilla?

Tekoälytiimit jäävät usein paitsi tästä, koska ihminen esitetään laatikona vuokaavion päässä. Laatikko sanoo "arvioija", "käyttäjä" tai "ihminen silmukassa", ja siksi se näyttää ratkaisevan ongelman. Mutta roolin nimi ei kuvaa vuorovaikutusta. Hyödyllisen arvioinnin suunnittelun on kerrottava, mitä ihminen näkee, mitä hän ei näe, mitä todisteita hän voi tarkastella, voiko hän pyytää toista reittiä, milloin hänen odotetaan olevan eri mieltä, mitä erimielisyyden jälkeen tapahtuu ja miten organisaatio oppii siitä. Nämä kysymykset ovat yhtä tavallisia kuin sen tarkistaminen, voiko ylityspaikkaa käyttää turvallisesti sateessa tai pimeässä. Ne ovat myös paljon informatiivisempia kuin lupaus siitä, että ihminen pysyy mukana.

Sairaala ei voi saada epävarmuutta katoamaan

Terveydenhuollossa todisteiden ongelma tulee erityisen näkyväksi, koska seuraukset ovat henkilökohtaisia ja toimintaympäristö on monimutkainen. Hyödyllinen kliininen tai hallinnollinen järjestelmä voi auttaa henkilökuntaa löytämään tietoa, vähentämään toistuvaa työtä, huomaamaan mahdollisen kaavan tai valmistelemaan aineistoa tarkastelua varten. Se ei tee siitä kliinistä auktoriteettia. Siirtymä tiedosta hoitoon, priorisointiin tai hoidon epäämiseen sisältää velvollisuuksia, joita ei voi ulkoistaa käyttöliittymälle. Hoidosta vastuussa olevan henkilön on tiedettävä, mitä järjestelmä teki, mitä se ei tehnyt ja miten toimia, kun tulos on ristiriidassa tapauksessa käytettävissä olevien tosiasioiden kanssa.

WHO/Europe:n työ tekoälystä terveydenhuollossa kehystää asian sille kuuluvalla sanastolla: turvallisuus, vaikuttavuus, oikeudenmukaisuus, ihmisoikeudet, läpinäkyvyys, vastuullisuus, hallinto ja henkilöstön valmius. Ei ole tarkoitus, että jokaisesta kliinisestä työntekijästä tulisi koneoppimisen asiantuntija. Tarkoitus on, että järjestelmää ei voi käyttää vastuullisesti, jos ihmisillä, joiden odotetaan luottavan siihen, valvovan sitä tai haastavan sen, ei ole käyttökelpoista käsitystä sen rajoista. Koulutus on osa valvontaympäristöä. Samoin ovat eskalointireitit, vastuujärjestelyt, näyttö todellisesta toiminnasta ja tapa, jolla potilaat ja ammattilaiset voivat tuoda huolensa esiin joutumatta ensin teknologian asiantuntijoiksi.

Euroopan komissio sijoittaa tekoälyn terveydenhuollossa vastaavasti laajempaan sääntely- ja toimintaympäristöön. Sen kansanterveysaineistossa todetaan, että lääketieteelliseen käyttöön tarkoitettu tekoälyohjelmisto voi kuulua tekoälyasetuksen suuren riskin vaatimusten piiriin, mukaan lukien riskien vähentäminen, tietojen laatu, käyttäjätiedot ja ihmisen valvonta. Tämä ei ole väite siitä, että jokainen sairaalassa käytetty työkalu saisi saman oikeudellisen luokituksen. Se on muistutus siitä, että sana "terveys" ei pehmennä huolellisen käyttötarkoitusanalyysin tarvetta. Mitä merkittävämpi käyttö on, sitä vähemmän uskottavaa on luottaa laajoihin vakuutteluihin.

Kliininen käytäntö osoittaa myös, miksi interventiokynnysten tulisi olla yksiselitteisiä. Järjestelmälle voidaan sallia lähteen hakeminen, yhteenvedon valmistelu, puuttuvan kentän merkitseminen tai ehdotus siitä, että tapaus ansaitsee huomiota. Nämä ovat erilaisia tekoja. Jokainen siirtyy hieman kauemmas tiedosta kohti vaikuttamista. Jossain vaiheessa järjestelmälle voidaan sallia rajattu toiminnallinen askel, ehkä säännöillä, jotka rajoittavat laajuutta, ja lokilla, joka tekee askeleesta peruutettavan. Tämän pisteen jälkeen sitä voidaan pyytää toimimaan ilman samanaikaista ihmisen päätöstä. Näillä tasoilla tarvittava näyttö, auktoriteetti ja palautussuunnittelu eivät ole keskenään vaihdettavissa.

Tämä ei tee automatisoinnista mahdotonta. Se tekee väitteistä oikeasuhteisia. Organisaatio voi valita vaatimattoman, hyvin rajatun tehtävän ja tehdä siitä luotettavan ennen kuin se kuvittelee laajan. Se voi pitää lähdemateriaalin saatavilla sen sijaan, että yhteenvedosta tulisi ainoa tallenne. Se voi antaa kliinikolle tai muulle vastuuhenkilölle todellisen keinon pysäyttää järjestelmä, ei teoreettista painiketta, joka on piilotettu toimintaohjeeseen. Se voi seurata, mitä käyttöönoton jälkeen tapahtuu, ja kohdella odottamatonta käytöstä todisteena siitä, että alkuperäinen perustelu vaatii tarkistusta. Tämä on hitaampaa kuin julistaminen, että malli on ottanut vallan. Se on yleensä nopeampaa kuin päätöksen rekonstruoiminen sen jälkeen, kun luottamus on jo menetetty.

Malli ei ole koko järjestelmä

AI-säädös on tässä arvokas, koska sen korkean riskin säännökset eivät kohtele mallia ainoana merkityksellisenä kohteena. 9 artiklassa vahvistetaan dokumentoitu, ylläpidetty ja jatkuva iteratiivinen riskinhallintaprosessi. 10 artikla koskee dataa ja datan hallintaa. 11 artikla ja liite IV käsittelevät teknistä dokumentaatiota. 12 artikla koskee merkityksellisten tapahtumien automaattista tallentamista. 14 artikla koskee tehokasta ihmisen suorittamaa valvontaa, mukaan lukien kykyä ymmärtää merkitykselliset rajoitteet, ohittaa tai kumota tuloste asianmukaisesti ja pysäyttää järjestelmä turvallisesti. 15 artikla koskee tarkkuutta, häiriönsietokykyä ja kyberturvallisuutta. Nämä eivät ole keskenään vaihdettavia paperityön luokkia. Yhdessä ne osoittavat järjestelmään, joka on ymmärrettävä koko sen elinkaaren ajan.

Laki ei tee teknistä arviota jokaisen organisaation puolesta. Se ei ilmoita, että tietty suorituskykymittari riittää, eikä se tee toimijasta pätevää nimeämällä hänet asiakirjassa. Se tekee jotakin vaativampaa. Se edellyttää tapaa yhdistää aiottu tarkoitus, riski, dokumentaatio, tallenteet, ihmisen suorittama valvonta ja jatkuva seuranta. Juuri tämä yhteys katoaa, kun tekoälyprojekti kuvataan mallin hankintana eikä toiminnallisena muutoksena.

Otetaan yleinen väite, jonka mukaan ihminen voi ohittaa mallin. Ohittaa mitä tarkalleen? Todennäköisyyden, järjestyksen, tuotetun kappaleen, reitityspäätöksen, automaattisen ilmoituksen, resurssien kohdistuksen vai fyysisen toimen? Ennen kuin se tulee voimaan vai sen jälkeen? Millä tiedoilla? Missä aikarajassa? Näkeekö ihminen, miksi järjestelmä päätyi tulosteeseen, vai ainoastaan sen, että se päätyi siihen? Onko eri mieltä olemisesta seurauksia? Tallennetaanko erimielisyys? Tarkastellaanko sitä mahdollisena malli-, data- vai työnkulkuhäiriönä? Totuudenmukainen vastaus näihin kysymyksiin on rauhoittavampi kuin kiiltävä vakuuttelu, koska se kuvaa valvontaa, jota voidaan todella käyttää.

Ihmisen suorittamaa valvontaa kohdellaan joskus moraalisena lisävarusteena: lisää prosessiin ihminen, niin järjestelmästä tulee inhimillinen. Se on parempi ymmärtää teknisenä suhteena. Ihmisellä on oltava merkityksellinen mahdollisuus havaita rajoite, toimivalta puuttua asiaan, toimi, joka muuttaa lopputuloksen, ja järjestelmän tila, joka pysyy turvallisena, kun toimi tehdään. Vallaton tarkastelija on todistaja. Tarkastelija, joka näkee tulosteen vasta, kun se on peruuttamaton, on jo tehdyn päätöksen auditoija. Kumpikaan järjestely ei vastaa valvontaa.

Näytön on siis kasvettava harkintavallan ja peruuttamattomuuden kasvaessa. Hakutyökalulla, joka auttaa ammattilaista löytämään lähdemateriaalia, on yhdenlainen näyttövaatimus. Järjestelmällä, joka asettaa työt tärkeysjärjestykseen huomion saamiseksi, on toisenlainen, koska järjestys vaikuttaa siihen, mikä saatetaan nähdä myöhään tai ei lainkaan. Rajoitetulla järjestelmällä, joka suorittaa toiminnallisen tehtävän automaattisesti, on oltava selkeät rajat, seuranta ja palautumisreitti. Järjestelmä, joka toimii ilman reaaliaikaista päätöstä, vaatii tiukimman tapauksen: kapean tarkoituksen, näytön toimintaympäristöstä, vikasietoisen käyttäytymisen, riippumattoman haastamisen asianmukaisesti, selkeän omistajuuden ja jatkuvan tarkastelun. Nimitys on vähemmän tärkeä kuin periaate. Suurempi autonomia on suurempi väite, ei markkinointipäivitys.

Kun automaattinen järjestelmä siirtyy ihmisen informoinnista itsenäiseen toimintaan, näytön, puuttumisen ja palautumisen vaatimusten on vahvistuttava, ei heikentymistä.

Kynnykset estävät hyödyllistä työkalua muuttumasta omistajattomaksi päätökseksi

Puuttumiskynnys on käytännöllinen vastaus käytännölliseen kysymykseen: milloin järjestelmä saa toimia ja milloin sen on palautettava asia ihmiselle? Sen pitäisi olla näkyvissä ennen käyttöönottoa, ei vasta valituksen kautta löydettynä. Kynnys voi riippua luottamuksesta, mutta luottamus yksinään ei riitä. Se voi riippua päätöksen tyypistä, virheen seurauksista, tiedon laadusta ja tuoreudesta, ristiriitaisen näytön olemassaolosta, pätevän henkilön saatavuudesta, palautumiskyvystä sekä siitä, missä määrin tapaus pysyy määritellyn tarkoituksen sisällä.

Kynnykset eivät ole todiste siitä, että järjestelmä on turvallinen. Ne ovat tapa estää järjestelmää vaatimasta enemmän toimivaltaa kuin sen näyttö voi tukea. Malli voi tiivistää asiakirjan, mutta ei arvioida sen täydellisyyttä. Se voi tunnistaa termin, mutta ei määrittää sen oikeudellista merkitystä. Se voi tuottaa uskottavan selityksen, mutta ei vahvistaa selityksen paikkansapitävyyttä. Se voi tunnistaa rutiininomaisen kaavan ja olla silti soveltumaton epätavallisiin tapauksiin, ristiriitaisiin lähteisiin tai tilanteisiin, joissa pienen virheen korjaaminen olisi vaikeaa. Kynnys on se kohta, jossa organisaatio muuttaa nämä erottelut toiminnaksi.

Tiehallinnon kohdalla kynnys voi tarkoittaa, että tarkastushavaintojen ja määriteltyjen riski-indikaattorien yhdistelmä johtaa muodolliseen arviointiin, kun taas toinen yhdistelmä edellyttää kiireellistä väliaikaista toimenpidettä. Tarkat kriteerit kuuluvat asiaankuuluvaan oikeudelliseen ja ammatilliseen viitekehykseen. Siirrettävä ajatus on se, että reitti havainnosta toimenpiteeseen ei saisi riippua yksinomaan siitä, kuka sattuu olemaan vuorossa tai mikä huoli muistetaan elävimmin kokouksessa. Näyttö ei korvaa ammatillista harkintaa. Se antaa harkinnalle yhteisen kirjauksen ja toistettavan reitin.

Sairaalan kohdalla kynnys voi erottaa työkalun, joka valmistelee aineistoa arviointia varten, järjestelmästä, joka voi suorittaa rajatun hallinnollisen toimenpiteen. Jälkimmäinen tarvitsee selkeän kirjauksen toimivaltuuksistaan, tavan havaita poikkeus, nimetyn vastuuhenkilön poikkeukselle ja tavan palauttaa edellinen tila, jos toimenpide oli virheellinen. Jos järjestelmä koskettaa kliinisesti merkittävää päätöstä, kynnyksen on otettava huomioon asiaankuuluvat kliiniset, oikeudelliset ja ammatilliset velvoitteet. Vastuuhenkilöltä ei saa edellyttää läpinäkymättömän automaatiotuloksen korjaamista ilman lähdejälkeä ja ilman aikaa sen tarkastamiseen.

Infrastruktuurin tekoälyjärjestelmässä kynnys voi erottaa ennusteen ohjaustoimesta. Ennuste voi varoittaa käyttäjää tilasta, jota kannattaa tarkistaa. Ohjaustoimi voi muuttaa fyysistä tai toiminnallista tilaa. Jälkimmäinen väite edellyttää huomattavasti vahvempaa selvitystä syötteen laadusta, järjestelmän rajoista, ympäristöolosuhteista, seurannasta, valtuuksista, varajärjestelyistä ja palautumisesta. Tämä ei ole byrokratiaa, joka on tuotu vaivaamaan insinöörejä. Se on tekninen kuvaus siitä, mitä tapahtuu, kun virheen hinta ei ole pettymystä aiheuttava vastaus chat-ikkunassa.

Hyödyllisin kynnys on usein kieltäytymiskynnys. Mikä saisi järjestelmän kieltäytymään toimimasta? Minkä puuttuvan syötteen, ristiriidan, myöhästyneen tietueen, jakauman ulkopuolisen tilan, tavoittamattoman tarkastajan tai testaamattoman muutoksen pitäisi laukaista turvallinen pysähdys? Organisaatiot kuvaavat mielellään, mitä toivovat järjestelmänsä tekevän. Ne ovat vähemmän halukkaita kirjaamaan, milloin sen on pysähdyttävä. Järjestelmän pysähtymiskäyttäytyminen paljastaa usein enemmän sen kypsyydestä kuin sen esittelykäyttäytyminen. Kyky sanoa "tämä tapaus on näytön ulkopuolella" ei ole vika. Se on osoitus siitä, että raja on olemassa.

Inhimilliset tekijät ovat osa näyttöä, eivät alaviite

Inhimilliset tekijät pelkistetään joskus havainnoksi siitä, että ihmiset ovat erehtyväisiä. Se on totta, mutta ei yksinään kovin hyödyllistä. Tekninen kysymys on, miten työ on järjestetty todellisen inhimillisen tarkkaavaisuuden, muistin, havainnoinnin, työkuorman, viestinnän ja valtuuksien ympärille. Varoitus, jota ei voi huomata, ei ole varoitus. Monimutkainen selitys, jota ei voi ymmärtää aikapaineessa, ei ole merkityksellistä läpinäkyvyyttä. Pysäytyshallinta, joka vaatii hyväksynnän henkilöltä, joka ei ole tavoitettavissa, ei ole pysäytyshallinta. Tarkastelunäkymä, joka piilottaa taustalla olevan tietueen, ei ole näyttöpinta.

Tiesuunnittelu tekee tämän konkreettiseksi. Ihmiset liikkuvat fyysisessä ympäristössä rajallisen ajan puitteissa nähdäkseen, tulkitakseen ja toimiakseen. Järjestelmää ei voi arvioida vain kuvailemalla sen tarkoitetut signaalit. Sitä on arvioitava tarkastelemalla, voivatko asiaankuuluvat ihmiset käyttää niitä todellisessa ympäristössä. Terveydenhuolto esittää saman asian eri rekisterissä. Hälytyksen tai suosituksen lukija voi joutua keskeytetyksi, käsitellä kilpailevia prioriteetteja, tuurata kollegaa tai kohdata tapauksen, joka ei istu prosessiin siististi. Tekoäly lisää uuden kerroksen, koska sujuva tuotos voi luoda virheellisen vaikutelman, että järjestelmä on punninnut näyttöä, jonka se on vain toistanut.

Vastaus ei ole vaatia yli-inhimillistä keskittymistä. Se on suunnitella ja testata luovutus. Mitä järjestelmä näyttää ensin? Minkä lähteen henkilö voi tarkastaa? Miten se ilmaisee epävarmuuden? Voiko henkilö pyytää toista reittiä? Erottako käyttöliittymä vahvistetun tietueen päätelmästä? Voiko henkilö tietää, onko malli, tietolähde, sääntö tai määritys muuttunut? Mitä palautteelle tapahtuu? Nämä ovat empiirisiä ja organisatorisia kysymyksiä. Ne ansaitsevat harjoituksia, havainnointia, käyttäjätutkimusta ja käyttöönoton jälkeistä arviointia, eivät vain toteamusta siitä, että käyttöliittymä on suunniteltu käyttäjä mielessä.

Vastuullinen näyttötietueen tulisi tallentaa inhimillinen järjestely muuttumatta yksittäisten työntekijöiden henkilökansioksi. Se voi tallentaa roolin, valtuudet, koulutusvaatimuksen, odotetun toimenpiteen, käytettävissä olevan ajan, tietopinnan, eskalaatioreitin ja harjoituksen tuloksen. Se voi tallentaa, että prosessi on testattu ilmoitetussa skenaariossa, teeskentelemättä, että skenaario todistaa kaikki tulevat olosuhteet. Se voi säilyttää päätöspolun käyttämättä seurantaa tekosyynä tarpeettomaan valvontaan. Nämä tasapainot ovat vaikeita. Ne on silti parempi käsitellä avoimesti kuin jättää epämääräisen ohjeen varaan, että ihmisten tulisi "käyttää harkintaansa".

Alankomaalaisella vaistolla tehdä monimutkaisista järjestelmistä luettavia on käyttöä myös tässä. Pyöräilyristeys, julkinen rekisteri tai hyvin merkitty prosessi ei muutu hyväksi pelkästään siksi, että se on selkeä, mutta selkeys auttaa ihmisiä näkemään, missä vastuu sijaitsee. Hyvällä hallinnolla on samanlainen vaatimattomuus. Se ei lupaa, ettei vaikeita päätöksiä tule. Se tekee vaikean päätöksen reitin näkyväksi ennen kuin sitä tarvitaan. Hyvin määritellylle eskalointipolulle ei järjestetä nauhanleikkausseremoniaa, mikä on ehkä syy siihen, että se jätetään niin usein myöhemmäksi.

Näytöllä on säilyvyysaika

Näyttöön perustuvan työn vaikein osa on hyväksyä, että eilinen näyttö voi olla paikkansapitävää mutta ei enää riittävää. Malli muuttuu. Tietolähde muuttuu. Toimittaja vaihtaa komponentin. Työnkulku organisoidaan uudelleen. Uusi ihmisryhmä käyttää palvelua. Tietä muutetaan, kunnossapidetään eri tavalla tai se altistuu erilaiselle liikennevirralle. Sairaala vaihtaa henkilöstöä, ohjelmistoja, triage-järjestelyjä tai tietoja. Alkuperäinen testi voi säilyä pätevänä historiallisena havaintona, mutta sen varaan rakennettu väite voi tarvita erilaiset rajat.

Siksi versiohistoria ei ole hallinnollinen hienous. Lukija, joka ei pysty tunnistamaan, mikä versio mallista, konfiguraatiosta, tietolähteestä, politiikasta tai käyttöliittymästä tuotti tuloksen, ei voi rekonstruoida päätöksen olosuhteita. Tiimi, joka ei kirjaa olennaisia muutoksia, ei voi erottaa uutta ongelmaa vanhasta. Organisaatio, joka kohtelee julkaisua varmistuksen loppuna, joutuu lopulta selvittämään uudelleen, miksi sen luottamus oli perusteltua, täsmälleen sillä hetkellä kun vastauksella on eniten merkitystä.

AI-asetuksen mukainen markkinoille saattamisen jälkeinen seuranta tunnistaa tämän elinkaaritodellisuuden korkean riskin järjestelmissä. Vaatimus ei ole lupaus siitä, että seuranta poistaa epävarmuuden. Se on tunnustus siitä, että tietoa saapuu käyttöönoton jälkeen ja sillä on oltava reitti takaisin riskienhallintaan. Vastaava opetus liikenneturvallisuudessa on tuttu: järjestelmiä tulisi tarkastaa ja arvioida niiden toimiessa, eikä olettaa niiden pysyvän turvallisina, koska ne kerran täyttivät suunnitteluvaatimuksen. Terveydenhuollossa tosielämän käyttö, henkilöstön kokemus, potilasvaikutukset ja hallintojärjestelyt ovat merkityksellisiä käyttöönottoa edeltävän arvioinnin rinnalla.

Arvioinnin laukaisimen tulisi olla riittävän täsmällinen, jotta sitä voidaan käyttää. ”Arvioi säännöllisesti” on kohtelias tapa pyytää tulevia kollegoita arvaamaan. Parempi laukaisin nimeää olennaisen tapahtuman: uuden mallin version, muutoksen tulolähteessä, uuden käyttöönottopaikan, muuttuneen käyttäjäryhmän, ratkaisemattoman ristiriidan, valituskuvion, turvallisuussignaalin, kyvyttömyyden suorittaa valvontavaihe tai muutoksen päätöksen omistavassa viranomaisessa. Luettelo on erilainen jokaisessa järjestelmässä. Olennaista on, että alkuperäinen perustelu nimeää olosuhteet, jotka voisivat tehdä siitä vanhentuneen.

Tämä muuttaa myös auditointijäljen merkitystä. Auditointijäljen ei tulisi olla varasto täynnä tapahtumia, joita kukaan ei osaa tulkita. Sen tulisi olla reitti järjestelmän historian läpi. Mikä väite oli voimassa? Mikä näyttö tuki sitä silloin? Mikä versio tuotti tuloksen? Kuka henkilö tai rooli teki merkittävän toimenpiteen? Mitä tapahtui, kun järjestelmää haastettiin? Mikä ongelma ratkaistiin ja mikä jäi avoimeksi? Tietojen on oltava oikeasuhteisia. Niiden on myös kyettävä vastaamaan todelliseen kysymykseen ilman sankarillista arkeologista tutkimusmatkaa sovelluslokeihin.

Miltä vakava näyttöä koskeva kysymys kuulostaa

Kun organisaatio arvioi turvallisuuskriittistä järjestelmää, hyödyllinen kysymys on harvoin ”toimiiko se?”. Kenelle se toimii, mihin päämäärään, millä ehdoilla, mihin verrattuna ja millä seurauksella, jos se epäonnistuu? Nämä kysymykset voivat tuntua hitaalta, koska ne estävät helpon kyllä-vastauksen. Ne ovat myös kysymyksiä, jotka tekevät myöhemmästä kyllä-vastauksesta jotakin arvokasta.

Hyvä arviointi kysyy siis ketjua eikä kokoelmaa. Se pyytää tiimiä nimeämään tarkoitetun käyttötarkoituksen ja sitä seuraavan päätöksen. Se kysyy, mitkä haitat ja vikatilat ovat olennaisia. Se kysyy, mikä näyttö tukee kutakin keskeistä väitettä ja mitä tuo näyttö ei osoita. Se kysyy, joiden oletusten on pysyttävä voimassa. Se kysyy, kenellä on valtuudet valvoa, ohittaa, keskeyttää ja korjata. Se kysyy, miten järjestelmä toimii, kun näyttö puuttuu tai tapaus on soveltamisalan ulkopuolella. Se kysyy, mitä seurataan julkaisun jälkeen ja mikä muutos laukaisee uudelleenarvioinnin.

Ei ole olemassa yleispätevää pistemäärää, joka päättäisi tämän harjoituksen. Tiellä on yksi konteksti, sairaalalla toinen ja mallilla jälleen kolmas. Hyvin suunnitellulla pienellä järjestelmällä voi olla vahvempi näyttöperusta kuin laajalla järjestelmällä, jota on kuvattu suuremmalla varmuudella. Kapea väite, jolla on selkeä raja, ei ole heikko väite. Se on rehellisen väitteen alku.

Siksi myös tutkimussivumme kuvaavat eksplisiittisiä kysymyksiä, näytön rajoja ja saatavuustilaa sen sijaan, että esittäisivät tutkimusmateriaalin oletusarvoisesti valmiina ominaisuutena. Menetelmä on vaatimaton: tunnista kysymys, tee näytön raja näkyväksi ja pidä julkaisutila luettavana. Se ei todista, että tuote soveltuu tiettyyn käyttöönottoon, eikä se korvaa toimialakohtaista varmennusta. Se on silti hyödyllinen tapa. Jos organisaatio ei osaa sanoa, mitä sen näyttö tukee, mitä se ei tue ja kuka sitä voi haastaa, se ei ole vielä ansainnut vahvempaa väitettä.

Tiellä, sairaalalla ja mallilla on kuitenkin yksi yhteinen ongelma. Jokainen tarvitsee tavan muuttaa tieto toiminnaksi piilottamatta niitä ehtoja, joiden vallitessa toiminta on perusteltua. Vastaus ei ole seremoniallinen tiedosto, keskimääräinen pistemäärä tai painike, jossa lukee ihmisen valvonta. Se on näyttökäytäntö, joka pysyy yhteydessä tarkoitukseen, ihmisiin, valtaan ja muutokseen. Se työ ei ole glamouria. Se on tapa, jolla järjestelmästä tulee vastuullinen ennen kuin siitä on tultava selitettävä.

Lähteet