Mitä Eurooppa voi oppia turvallisuusselvityksistä

Turvallisuusperustelu on elävä argumentti vaaroista ja oletuksista todisteisiin, jäännösriskiin ja päätökseen. Se tarjoaa tekoälytiimeille rehellisemmän...

Mitä Eurooppa voi oppia turvallisuusselvityksistä

Tiedosto, jonka on vastattava ennen kuin juna lähtee

Eurooppalaiset rautatieturvallisuussäännöt alkavat epäkiitollisesta kysymyksestä: mikä muuttui. Muutos voi olla tekninen, toiminnallinen tai organisatorinen. Se voi koskea laitteistoa, menettelyä, henkilöstöjärjestelyä tai organisaatioiden välistä rajapintaa. Yhteinen turvallisuusmenetelmä riskinarviointia ja -arviointia varten edellyttää, että muutoksen esittäjä arvioi muutoksen merkittävyyden, soveltaa riskienhallintaprosessia tarvittaessa ja käyttää riippumatonta arviointielintä varmistaakseen, että prosessi ja sen tulokset on sovellettu oikein. Sääntöä ei kiinnosta, ilmoitettiinko muutoksesta varmuudella. Sitä kiinnostaa, voidaanko perustelut toiminnan jatkamiselle tarkastaa.

Tämä tapa kannattaa viedä tekoälyyn. Järjestelmästä ei tule turvallista siksi, että sen malli on älykäs, sen käyttöliittymä on rauhallinen tai sen toimittaja on tuottanut hyvännäköisen testiraportin. Siitä tulee puolustettava määriteltyyn käyttöön, kun organisaatio voi selittää, mitä se väittää, mitkä vaarat ovat väitteen takana, mitkä oletukset tekevät väitteestä mahdollisen, mitkä todisteet tukevat jokaista lenkkiä, kuka hyväksyi jäljellä olevan riskin ja mikä avaisi päätöksen uudelleen. Tulosta kutsutaan yleisesti turvallisuusperusteluksi: rakenteellinen argumentti, jota todisteet tukevat, jota ehdot rajaavat ja jota ylläpidetään muutosten kautta.

Turvallisuusperustelu ei ole tarina kuvitteellisesta onnettomuudesta. Se on tapa kieltäytyä siitä, että onnettomuus kantaisi kaiken todistusaineiston. Se kysyy vaikeat kysymykset silloin, kun suunnitteluun, hankintaan ja käyttökäytäntöihin voidaan vielä vaikuttaa. Tämä tekee siitä hyödyllisen rautateille, ilmailulle, lääkinnällisille laitteille, teollisuuden ohjausjärjestelmille ja kriittiselle infrastruktuurille. Se tekee siitä hyödyllisen myös tekoälylle, jossa komponentti voi olla tilastollisesti vaikuttava ja toiminnallisesti käyttövalmis samaan aikaan. Malli voi läpäistä testin, vaikka sen ympärillä olevalla järjestelmällä ei ole turvallista vastausta epävarmuuteen, ei vastuullista käyttäjää eikä reittiä huonon päätöksen perumiseen.

Erottelu on tärkeä Euroopassa, koska tekoälyasetus edellyttää jo korkean riskin järjestelmillä jatkuvaa, dokumentoitua riskienhallintaprosessia. Artikla 9 kuvaa riskien tunnistamista, arviointia, arvioimista ja käsittelyä toistuvasti koko järjestelmän elinkaaren ajan, mukaan lukien kohtuullisesti ennakoitavissa oleva väärinkäyttö ja markkinoille tulon jälkeisestä seurannasta saadut tiedot. Artikla 11 edellyttää teknistä dokumentaatiota ennen järjestelmän saattamista markkinoille ja toteaa, että sitä on pidettävä ajan tasalla. Nämä säännökset eivät käytä turvallisuusperustelua yleisenä nimikkeenä. Ne kuvaavat kuitenkin niitä käytäntöjä, jotka tekevät turvallisuusperustelusta uskottavan.

Turvallisuusperustelu tekee reitin turvallisuusväitteestä julkaisupäätökseen riittävän näkyväksi, jotta sitä voidaan haastaa.

Turvallisuusperustelu ei ole testiraportti

Testiraportti vastaa kysymykseen testistä. Se kertoo, mitä testattiin, missä olosuhteissa, millä tuloksella ja, jos työ on hyvää, millä rajoituksilla. Se on arvokasta. Turvallisuusperustelu kysyy toista kysymystä: onko olemassa riittävästi tuettu argumentti siitä, että tämä järjestelmä on hyväksyttävä tähän tarkoitukseen, tässä kontekstissa, näiden ihmisten, hallintakeinojen ja jäljellä olevien riskien kanssa. Testitulos voi olla yksi osa tuota argumenttia. Se ei voi huomaamatta muuttua koko argumentiksi vain siksi, että taulukossa on vihreitä soluja.

Oletetaan, että luokittelijaa on testattu merkittyä aineistoa vastaan. Raportti voi kertoa, miten se suoriutui kyseisestä aineistosta, ehkä luokittain, kynnysarvon tai toimintapisteen mukaan. Se ei itsessään kerro, onko tuotannossa saapuvalla syötteellä sama merkitys, onko vaikutuksen kohteena oleva väestö edustettuna, voiko arvioija tunnistaa heikon tuloksen, onko valitusmahdollisuutta, voiko toimittaja muuttaa mallia ilman ilmoitusta tai voiko organisaatio pysäyttää ja kumota myöhemmän toimenpiteen. Nämä kysymykset kuuluvat järjestelmään ja sen käyttöön, eivät vain komponenttiin.

Myös vastakkainen virhe on yleinen. Laaja varmennusaineisto voi sisältää satoja sivuja ja silti epäonnistua argumentin tekemisessä. Luettelo testeistä, käytännöistä ja kokousmuistiinpanoista ei ole turvallisuusperustelu, jos mikään väite ei yhdistä niitä. Näytöllä on oltava tehtävä. Testi voi tukea väitettä kestävyydestä. Tehtäväkuvaus voi tukea väitettä toimivallasta. Palautusharjoitus voi tukea väitettä palautumisesta. Audit trail voi tukea väitettä jäljitettävyydestä. Ilman väitteen ja näytön välistä suhdetta tiedosto on arkisto toiminnasta, ei selitys turvallisuudesta.

Siksi turvallisuusperustelu voi olla yhdessä kohdassa lyhyempi kuin testiraportti ja toisessa laajempi. Se kasvaa vaarojen ja päätösten ympärille. Vähäriskinen luonnostelutyökalu voi tarvita vaatimattoman argumentin, joka kattaa soveltamisalan, tietojenkäsittelyn, tarkastuksen ja korjaamisen. Järjestelmä, joka liittyy kliinisiin, liikenteen, talouden tai julkisten palvelujen päätöksiin, tarvitsee enemmän näyttöä, koska useammat ihmiset riippuvat lopputuloksesta ja koska oikaisun tie voi olla vaikea. Laajuus seuraa seurauksia ja epävarmuutta, ei mallikortin muodikasta pituutta.

Argumentin tulisi myös erottaa komponenttinäyttö toiminnallisesta näytöstä. Komponenttinäyttö koskee mallia, algoritmia tai anturia erillään tai hallitussa integraatiossa. Toiminnallinen näyttö koskee varsinaista työnkulkua: pääsyä, tietojen ajantasaisuutta, ihmisen tekemää tarkastusta, jonoja, työkaluoikeuksia, poikkeamien käsittelyä ja muutostenhallintaa. Malli voi olla vakaa, kun jono romahtaa. Työnkulku voi olla hyvin suunniteltu, kun toimittaja muuttaa syötteen rakennetta. Turvallisuusperustelut pakottavat molemmat näkökulmat samalle sivulle, mikä on hieman hankalaa ja siksi tervettä.

Aloita väitteestä, jolla on reunat

Jokainen turvallisuusperustelu alkaa ylimmän tason väitteestä. Väitteen tulee olla riittävän kapea testattavaksi ja riittävän hyödyllinen ohjaamaan päätöstä. Lause tämä tekoäly on turvallinen ei ole väite, jolla on reunat. Turvallinen kenelle, tekemään mitä, missä olosuhteissa ja millä hallintakeinoilla. Parempi väite voisi sanoa, että määritelty päätöksenteon tukitoiminto on hyväksyttävä nimetylle koulutettujen käyttäjien ryhmälle edellyttäen, että järjestelmää käytetään vain suosituksiin, että näyttö ja epävarmuus esitetään, että toimivaltainen ihminen tarkastaa tuloksen ja että määritellyt pysäytys- ja korjausreitit ovat käytettävissä.

Tuo lause on vähemmän markkinoitava ja paljon arvokkaampi. Se tunnistaa tarkoituksen, toimijan, rajan ja ehdot. Se myös paljastaa, mikä tekisi väitteestä epätoden. Jos sama toiminto liitetään suoraan automaattiseen päätökseen, väite ei enää kata sitä. Jos käyttäjät eivät ole koulutettuja tai eivät voi haastaa tulosta, väite heikkenee. Jos tietolähde muuttuu eikä sitä voida jäljittää, väitteen näyttö voi vanhentua. Hyvä ylimmän tason väite kantaa mukanaan oman listansa tavoista tulla avatuksi uudelleen.

Väitteet voidaan purkaa osiin. Järjestelmä pysyy aiottuun käyttötarkoitukseensa rajatussa toiminnassa. Syötteet täyttävät ilmoitetut laatu- ja käyttöoikeusehdot. Mallin tuotos tulkitaan tavalla, joka ei luo turvatonta automaatioharhaa. Seurauksiltaan merkittävät toimet saavat riskinsä suhteessa olevan tarkastuksen. Käyttäjät voivat jättää tuotoksen huomiotta tai kumota sen. Organisaatio pystyy havaitsemaan merkityksellisen poikkeaman. Muutosta ei julkaista tarkistamatta sen vaikutusta oletuksiin, joihin se kohdistuu. Jokaisella osaväitteellä on oltava kontrollit ja näyttö. Puu ei ole havainnekuva kalvoa varten, vaan reitti, jonka avulla arvioija voi paikantaa heikon kohdan.

Väitteen tulisi myös kertoa, mitä se ei pyri todistamaan. Tapaus voi tukea turvallista käyttöä yhdessä tehtävässä ilman, että se todistaa yleistä älykkyyttä, yleispätevää oikeudenmukaisuutta tai soveltuvuutta kaikille käyttäjäryhmille. Se voi tukea julkaisua määritellyssä käyttöönottoasetelmassa ilman, että se todistaa tallentamattoman konfiguraation toimivan samalla tavalla. Ei-väitteet eivät ole vaatimattomuuden koristeita. Ne estävät kapean tuloksen leviämisen organisaatiossa paljon suurempana lupauksena.

Tämän tarkkuuden taustalla on hyödyllinen eurooppalainen vaisto. Asetus 402/2013 edellyttää, että rautatiealan hakija päättää, onko muutos merkittävä, valitsee riskin hyväksymisperiaatteen ja käyttää tarvittaessa riippumatonta arviointia. Hakijaa ei vaadita todistamaan, että jokainen kuviteltavissa oleva tuleva rautatien tila on turvallinen. Hakijaa vaaditaan tekemään nykyinen muutos ja sen rajapinnat riittävän ymmärrettäviksi oikeasuhtaista päätöstä varten. AI-tiimit voivat omaksua saman kurinalaisuuden. Nimeä muutos, nimeä käyttöympäristö ja tee raja näkyväksi.

Vaarat ovat olosuhteita, eivät otsikoita

Vaara on olosuhde, joka voi johtaa haittaan. Erottelu on hyödyllisempi kuin miltä se ensin vaikuttaa. Väärä etuuspäätös on lopputulos. Vaara voi olla puutteellinen tietue yhdistettynä järjestelmään, joka esittää perustelemattoman suosituksen hyväksyntää valmiina. Viivästynyt huoltovaroitus on lopputulos. Vaara voi olla vanhentunut anturisyöte, jota työnkulku käsittelee ajantasaisena. Tietosuojaloukkaus on lopputulos. Vaara voi olla liian laaja hakukäyttöoikeus yhdistettynä työkaluun, joka kopioi lähdemateriaalin pysyvään tietueeseen.

Vaarojen kirjoittaminen tällä tavalla siirtää huomion ylävirtaan. Se mahdollistaa suunnittelu- ja toiminnalliset kontrollit. Jos vaara on perusteeton suositus, jolle annetaan aiheetonta auktoriteettia, kontrolli voi edellyttää lähdenäyttöä, tuoda epävarmuuden näkyviin, rajoittaa toimenpidettä ja tarjota arviointireitin. Jos vaara on vanhentunut syöte, kontrolli voi tarkistaa ajantasaisuuden, merkitä datan tilan, estää toimenpiteen tai ohjata sen henkilölle. Jos vaara on liiallinen pääsy, kontrolli voi rajoittaa hakua, erottaa identiteetit, poistaa sisältöä tuotoksesta ja tallentaa pääsypäätöksen. Kontrollin tulee kohdistua olosuhteeseen, ei vain luvata huolellisuutta lopputuloksen ympärillä.

Vaara-analyysin tulee kattaa ennakoitavissa oleva väärinkäyttö, ei vain hankinta-asiakirjaan kirjattua käyttötarkoitusta. AI-asetus tekee tämän nimenomaiseksi korkean riskin järjestelmille. Artikla 9 edellyttää riskien arviointia, kun järjestelmää käytetään aiottuun tarkoitukseen ja kohtuullisesti ennakoitavissa olevan väärinkäytön vallitessa. Väärinkäyttö ei tarkoita jokaista järjetöntä pyyntöä. Se tarkoittaa käyttötapoja, jotka pätevä tiimi voisi ennakoida käyttöliittymän, kannustimien, ohjeiden ja ympäröivän työnkulun perusteella. Jos nopein reitti järjestelmässä on hyväksyä suositus lukematta sen näyttöä, tämä reitti kuuluu analyysiin, vaikka käytäntö edellyttäisi tarkistusta.

Vaarat elävät myös rajapinnoissa. Malli voi tuottaa rajatun suosituksen, mutta integraatio voi muuttaa sen rajaamattomaksi ohjeeksi. Toimittaja voi tarjota versioidun rajapinnan, mutta käyttöönotto voi tallentaa vastauksia välimuistiin kelpoisuusajan yli. Julkinen viranomainen voi säilyttää päätösvastuun, mutta sopimus voi tehdä toimittajasta ainoan osapuolen, joka voi tarkastaa jäljitysketjun. Turvallisuusperustelun järjestelmäraja on vedettävä kausaalista polkua pitkin seuraukseen asti. Rajan vetäminen pelkän mallin ympärille on tehokas tapa jättää huomaamatta se työ, joka tekee mallista merkityksellisen.

Kaikki vaarat eivät ansaitse samaa käsittelyä. Osa voidaan vähentää suunnittelulla. Osa vaatii menettelyllisiä kontrolleja tai ihmisen tekemää tarkastelua. Osa voidaan seurata ja hyväksyä ehdoin. Osa kertoo, että suunniteltu käyttö ei ole asianmukaista. Turvallisuusperustelun tulee näyttää päättely, ei piilottaa sitä yleisen riskipisteytyksen taakse. Eurooppalainen rautatieliikenteen menetelmä sallii erilaisia riskinhyväksyntäperiaatteita, kuten hyvän käytännön säännöt, vertailun järjestelmän vastaaviin osiin ja nimenomaisen riskinarvioinnin. Opiksi ei jää se, että jokin yksittäinen menetelmä voittaa kaikkialla. Opiksi jää se, että menetelmä ja sen soveltuvuus muutokseen on kirjattava.

Oletukset kantavat kuormaa

Jokainen turvallisuusperustelu nojaa oletuksiin. Käyttäjä on koulutettu. Lähde on ajantasainen. Kynnysarvo tarkoittaa sitä, mitä tiimi sen luulee tarkoittavan. Hälytyksen vastaanottaja ehtii toimia. Ulkoinen palvelu on saatavilla tai on olemassa varajärjestelmä. Tulos pysyy suosituksena eikä muutu tosiasialliseksi päätökseksi. Organisaatio huomaa, jos mallipäivitys muuttaa toimintaa. Monet turvallisuuspoikkeamat eivät johdu siitä, että oletus olisi kohtuuton. Ne johtuvat siitä, että oletus on näkymätön.

Oletus kuuluu perusteluun omistajan ja tarkistustavan kanssa. Jos perustelu nojaa koulutettuihin tarkastajiin, perustelussa on kerrottava vaadittava osaaminen, miten se osoitetaan ja mitä tapahtuu, kun henkilöstö vaihtuu. Jos perustelu nojaa siihen, että lähde pysyy tuoreusikkunan sisällä, järjestelmän on tallennettava tuoreus ja tarvittaessa sidottava toiminta siihen. Jos perustelu nojaa siihen, että integraatio säilyttää kentän, rajapintasopimuksen ja testin on tehtävä riippuvuus näkyväksi. Oletus, jota ei voi tarkistaa, on riski pehmeämmällä nimellä.

Oletukset voivat koskea myös ulkomaailmaa, eivät vain ohjelmistoa. Sairaala voi olla riippuvainen kliinisestä hoitopolusta. Rautatieoperaattori voi olla riippuvainen opastinrajapinnasta. Julkinen toimija voi olla riippuvainen lakisääteisestä menettelystä ja siitä, että inhimillinen päätöksentekijä säilyttää toimivaltansa. Valmistaja voi olla riippuvainen siitä, että huolto tehdään määrätyin väliajoin. Turvallisuusperustelu ei hallitse jokaista ulkoista ehtoa. Sen on kuitenkin kerrottava, mitä ehtoja se olettaa, kuka ne omistaa ja miten muutos tunnistetaan.

Kun oletukset muuttuvat, perustelu ei saa venyä huomaamatta. Tiimi voi aloittaa vain suosituksia tuottavasta käytöstä ja lisätä sitten automaattisen siirron, koska suositus on hyväksytty usein. Malli ei ole muuttunut, mutta toimivalta ja vaara ovat. Datatoimittaja voi lisätä uuden luokan, joka vaikuttaa harmittomalta, kunnes se muuttaa alemman tason säännön merkitystä. Käyttöönotto voi siirtyä koulutetuilta asiantuntijoilta yleiselle tukitiimille. Nämä ovat perustelun muutoksia, vaikka mallin versionumero pysyisi samana.

Oletukset ovat erityisen tärkeitä todennäköisyyspohjaisissa järjestelmissä, koska vakaa keskiarvo voi kätkeä epävakaan reunan. Perustelussa on kerrottava, missä järjestelmän odotetaan olevan epävarma, mikä näyttö kertoo epävarmuudesta ja mikä inhimillinen tai tekninen kontrolli ottaa ohjat. Tavoitteena ei ole teeskennellä, että epävarmuus voidaan poistaa. Tavoitteena on estää sanomaton varmuuden odotus muuttumasta toimintapolitiikaksi.

Näyttö ei ole passi jokaiseen asiayhteyteen. Sen oletukset määrittävät, minne se voi kulkea.

Näytöllä on oltava säilytysketju

Näyttö turvallisuusperustelussa on enemmän kuin taulukkoon kopioitu tulos. Sillä on identiteetti, soveltamisala, päivämäärä, menetelmä, vastuuhenkilö tai vastuutiimi sekä suhde väitteeseen, jota se tukee. Testillä on oltava määritelty syöte ja konfiguraatio. Katselmoinnilla on oltava kysymys ja päätös. Harjoituksella on oltava odotettu vaste ja havainto. Lokilla on oltava riittävästi asiayhteyttä, jotta sitä voidaan tulkita ilman muistin varassa toimimista. Lähdetietueella on oltava alkuperäpolku. Yksityiskohdat vaihtelevat toimialoittain, mutta periaate on vakaa: näytön on oltava tarkasteltavissa myös sen kokouksen jälkeen, jossa se kuulosti vakuuttavalta.

AI-asetus antaa tälle periaatteelle oikeudellisen painoarvon suuririskisissä järjestelmissä. 11 artikla edellyttää, että tekninen dokumentaatio on saatavilla ennen järjestelmän saattamista markkinoille ja että sitä pidetään ajan tasalla. 12 artikla edellyttää olennaisten tapahtumien automaattista tallentamista järjestelmän koko elinkaaren ajalta, ja kirjaamisvalmiuksien on oltava oikeassa suhteessa käyttötarkoitukseen sekä hyödyllisiä riskien tunnistamisessa, markkinoille saattamisen jälkeisessä seurannassa ja toiminnan valvonnassa. 13 artikla edellyttää tietoja, joiden avulla käyttöönottajat voivat ymmärtää ominaisuudet, rajoitukset, ennakoitavissa olevat riskit, ihmisen valvonnan ja syötteitä koskevat vaatimukset. Turvallisuusperustelu yhdistää nämä tietueet sen sijaan, että ne jäisivät erillisiin vaatimustenmukaisuuslaatikoihin.

Näytön on säilytettävä ehtonsa. Suorituskykytulos ilman testauspopulaatiota voidaan tulkita väärin. Robustisuustulos ilman käytettyjä häiriöitä voidaan yliarvioida. Ihmistekijöiden katselmus ilman työnkulkua ja aikapainetta, joissa se tehtiin, voi muuttua yleiseksi kehuksi. Tapahtumaloki ilman voimassa ollutta versiota, tietotilaa ja käyttöoikeuksia voi tuottaa houkuttelevan mutta väärän perussyyn. Mitä merkittävämpi päätös, sitä vähemmän hyväksyttävää on irrottaa tulos olosuhteista, jotka tekivät siitä totta.

Näyttö voi olla laadullista tai määrällistä. Dokumentoitu asiantuntija-arvio voi olla pätevää näyttöä, kun kysymys on asianmukainen, asiantuntemus on yksilöity ja perustelut on kirjattu. Numeerinen pistemäärä voi olla heikkoa näyttöä, kun nimittäjä, kynnysarvo tai testiolosuhteet ovat epäselvät. Ei ole olemassa moraalista hierarkiaa, jossa luku automaattisesti ohittaisi huolellisen havainnon. Perustelussa on selitettävä käyttökelpoisuus ja epävarmuus, ei kumarruttava desimaalien edessä.

Jäljitettävyys tekee myös erimielisyydestä tuottavaa. Arvioijan pitäisi pystyä sanomaan, mitä väitettä ei ole tuettu, mikä oletus on liian optimistinen tai mitä kontrollia ei ole harjoitettu. Tapauksesta tulee tällöin yhteinen haastamisen kohde eikä seremoniallinen hyväksyntäpaketti. Tämä on yksi syy siihen, miksi turvallisuuskriittiset toimialat panostavat riippumattomaan arviointiin ja rakenteellisiin varmennusraportteihin. Tavoitteena ei ole tehdä erimielisyydestä mukavaa. Tavoitteena on tehdä erimielisyydestä paikannettavaa.

Jäännösriski on päätös, ei jäännös

Riski ei katoa siksi, että kontrolleja on lisätty. Kontrollien jälkeen jäljelle jäävä riski on jäännösriski. Se on kuvattava ja hyväksyttävä sellaisen toimivaltaisen tahon toimesta, joka pystyy ymmärtämään näytön, asettamaan ehtoja ja lopettamaan käytön, kun ehdot eivät täyty. Riskin kutsuminen hyväksyttäväksi ei ole sama asia kuin sen sanominen pieneksi. Se tarkoittaa, että organisaatio on tehnyt harkitun päätöksen jäljellä olevasta altistumisesta määritellyssä kontekstissa eikä ole piilottanut päätöksen perustaa.

AI-asetuksen 9 artikla käyttää tätä kieltä suoraan korkean riskin järjestelmiin. Kunkin vaaran kannalta olennainen jäännösriski ja kokonaisjäännösriski on arvioitava hyväksyttäviksi. Asetus edellyttää myös poistamista tai vähentämistä, kun se on teknisesti mahdollista, sekä lieventämis- ja hallintatoimenpiteitä, kun riskejä ei voida poistaa. Tämä on hyödyllinen järjestys. Muuta ensin suunnittelua, kun se on mahdollista. Lisää sitten kontrolleja. Kirjaa sitten, mitä jää jäljelle. Varoitusmerkintä ei ole tekosyy pitää ehkäistävissä oleva vaara arkkitehtuurissa.

Jäännösriskiin tulisi sisältyä palautuvuus. AI-asetuksen riskikriteerit tarkastelevat, voidaanko lopputulos korjata tai kumota, ja toteavat, että haitallisia vaikutuksia terveyteen, turvallisuuteen tai perusoikeuksiin ei tulisi pitää helposti korjattavina pelkästään siksi, että tekninen kumoamispainike on olemassa. Tämä on huomaamaton mutta tärkeä erottelu. Luonnoksen voi korjata. Menetetty etu, evätty palvelu tai julkinen syytös voi olla paljon vaikeampi korjata. Tapauksessa tulisi kohdentaa vahvempia kontrolleja silloin, kun henkilö, johon vaikutus kohdistuu, ei voi realistisesti kieltäytyä tai kumota lopputulosta.

Hyväksyntään on liitettävä ehtoja. Järjestelmä voidaan hyväksyä rajattuun pilottiin, koulutetulle tiimille, nimettyyn tietolähteeseen ja arviointireittiin. Sitä ei voida hyväksyä eri väestöryhmälle, valvomattomaan työnkulkuun tai integraatioon, joka poistaa näytön. Ehdot on kirjoitettava niin, että käyttäjä pystyy arvioimaan, ovatko ne edelleen voimassa. Jos ehtona on vain se, että käyttäjät käyttävät harkintaa, tapaus ei ole kertonut, miten järjestelmä tukee harkintaa tai mitä tapahtuu, kun työmäärä tekee harkinnasta vaikeaa.

Jäännösriskipäätökseen tarvitaan myös vanhentumis- tai tarkistustriggeri. Kiinteä kalenteripäivä voi auttaa, mutta tapahtumat ovat yleensä informatiivisempia: mallimuutos, uusi lähde, olennainen poikkeama, ajautumissignaali, muutos käyttäjissä, uusi lakisääteinen velvoite tai kontrolliharjoituksen epäonnistuminen. Päätös ei ole julkaisun päälle asetettu loitsu. Se on lupa, johon liittyy ylläpitoaikataulu.

Ihmisen valvonnalla on oltava toimivaltaa

Ihmisen valvonnasta puhutaan usein ikään kuin se, että joku ihminen seisoo jossain lähellä tuotosta, tekisi järjestelmästä turvallisen. AI-asetus on vaativampi. 14 artiklan mukaan korkean riskin järjestelmät on suunniteltava siten, että luonnolliset henkilöt voivat valvoa niitä tehokkaasti käytön aikana. Valvonnan on oltava oikeassa suhteessa riskiin, autonomiaan ja kontekstiin. Valvontaan osoitettujen henkilöiden tulisi ymmärtää ominaisuudet ja rajoitukset, havaita poikkeamat, tunnistaa automaatioharha, tulkita tuotosta, päättää olla käyttämättä tai ohittaa se sekä puuttua tilanteeseen tai pysäyttää järjestelmä turvallisen menettelyn kautta.

Nämä ovat yhtä lailla suunnitteluvaatimuksia kuin henkilöstövaatimuksia. Arvioija ei voi tulkita tuotosta, jos todisteet ovat piilossa. Arvioija ei voi haastaa suositusta, jos käyttöliittymä tarjoaa hyväksynnän ainoana vaivattomana vaihtoehtona. Arvioija ei voi pysäyttää järjestelmää, jos pysäytystoiminto edellyttää lupaa, jota kukaan ei ole myöntänyt. Arvioija ei voi harjoittaa mielekästä valvontaa, jos häntä mitataan vain läpimenon perusteella. Turvallisuusperustelun tulisi siksi käsitellä ihmisen roolia säätimenä, jolla on syötteet, toimivalta, työmäärä, koulutus ja havaittava käyttäytyminen.

Toimivalta on yksityiskohta, jonka kohteliaat kuvaukset jättävät pois. Kuka saa keskeyttää työnkulun. Kuka saa kumota toimenpiteen. Kuka voi julistaa, että oletus ei enää päde. Kuka voi ottaa yhteyttä toimittajaan. Kuka omistaa tallenteen. Kuka päättää, onko jäännösriski edelleen hyväksyttävä. Jos kenelläkään ei ole toimivaltaa, ihmisen silmukassa -kuvaus on teatteria. Henkilö voi nähdä tuotoksen, mutta näkeminen ei ole hallitsemista.

Hyvä valvonta on myös valikoivaa. Tavoitteena ei ole lähettää jokaista triviaalia luonnosta komitealle. Tavoitteena on kohdentaa inhimillinen harkinta sinne, missä seuraukset, epävarmuus tai kiistanalaisuus sitä edellyttävät. Jotkin tapaukset voidaan hoitaa rakenteellisilla tarkistuksilla. Jotkin vaativat koulutetun asiantuntijan. Jotkin vaativat kaksi riippumatonta vahvistusta sovellettavan lain mukaisesti. Jotkin tulisi kieltäytyä. Perustelun tulisi selittää valinta ja osoittaa, että valittu reitti on käytettävissä todellisessa toiminnassa, ei vain menettelykäsikirjassa.

Tällaisessa suunnittelussa on vaatimaton kunnioituksen muoto. Se hyväksyy, että ihmiset väsyvät, että jonot kasvavat, että käyttöliittymät muokkaavat tarkkaavaisuutta ja että varoitus, joka näkyy sata kertaa, voi lakata olemasta varoitus. Turvallisuustekniikka on oppinut tämän kokemuksen kautta liikenteessä ja teollisuudessa. Tekoälytiimien ei tarvitse toistaa jokaista oppituntia suorittamalla estettävissä oleva koe julkisuudessa.

Muutos kävelee jatkuvasti perustelun sisään

Turvallisuusperustelu on elävä, koska järjestelmä on elävä. Mallin versio voi muuttua, mutta myös kehote, hakemistohakuindeksi, taksonomia, politiikka, laitteisto, henkilöstö, käyttöliittymä, tietolähde tai toimittaja voi muuttua. Pieni muutos voi mitätöidä oletuksen tai siirtää säätimen. Seurauksena oleva riski voi olla suurempi, pienempi tai yksinkertaisesti erilainen. Oikea vastaus ei ole jäädyttää järjestelmää ikuisesti. Se on tehdä muutos näkyväksi, luokitella sen merkitys ja päättää, mitkä osat perustelusta on tarkasteltava uudelleen.

Rautatiekäytäntö tarjoaa selkeän mallin. Asetus 402/2013 soveltaa yhteistä menetelmäänsä, kun tekniset, toiminnalliset tai organisatoriset muutokset vaikuttavat rautatiejärjestelmään. Muutoksen ehdottaja arvioi muutoksen merkityksen ja käyttää tarvittaessa riskin hyväksymisperiaatteita ja riippumatonta arviointia. Asetus varoittaa myös, että kaikkien edellisen riskiprosessin jälkeisten muutosten kokonaisuus voi olla merkityksellinen. Useat pienet muutokset voivat yhdessä muodostaa merkittävän muutoksen. Tekoälyn hallinnassa tarvitaan sama epäluulo vaarattoman näköisiä lisäyksiä kohtaan.

Tekoälyn osalta muutostietueen tulisi tunnistaa, mikä muuttui ja mikä ei. Muuttuivatko mallin painot. Muuttuiko todisteiden keruu. Muuttuivatko työkalujen käyttöoikeudet. Muuttuiko käyttäjäjoukko. Siirtyikö kynnysarvo. Tuliko työnkulusta automaattinen kohdassa, joka oli aiemmin neuvoa-antava. Pysyikö varareitti käytettävissä. Tavoittiko arviointi uuden tilan. Tietueen tulisi liittää jokainen vastaus asianomaiseen väitteeseen, vaaraan, säätimeen tai oletukseen ja määritellä testit tai tarkistukset, jotka tarvitaan ennen julkaisua.

Muutoksenhallinnan tulisi sisältää turvallinen julkaisumoodi. Varjotestiajo, vaiheistettu reitti, rajattu käyttäjäjoukko, nimenomainen palautusehto tai ihmisen vahvistus voivat estää uutta käyttäytymistä tulemasta koko laitoksen kattavaksi tosiasiaksi ennen kuin kukaan on tutkinut sitä. Nämä mekanismit eivät ole todiste siitä, että järjestelmä on heikko. Ne ovat todiste siitä, että organisaatio ymmärtää uuden käyttäytymisen tarvitsevan paikan oppia.

Markkinoille tulon jälkeinen seuranta jatkaa tapauksen käsittelyä julkaisun jälkeen. Artikla 9 viittaa artiklan 72 kautta kerättyyn tietoon, ja artikla 72 edellyttää dokumentoitua seurantajärjestelmää suuren riskin järjestelmille koko niiden elinkaaren ajan. Seurannassa tulisi etsiä väitteen kannalta merkityksellisiä signaaleja: muuttuneita virhekuvioita, epätavallisia kieltäytymisiä, odottamatonta käyttöä, valitusten lopputuloksia, puuttuvaa näyttöä, tietoturvatapahtumia ja inhimillisten valvontatoimien pettämistä. Hallintapaneeli, joka raportoi vain käytettävyyttä, on iloinen tapa ohittaa turvallisuusongelma.

Riippumaton arviointi on hyödyllinen hankaluus

Järjestelmän rakentaneet tuntevat sen tyylikkyyden, sen oikopolut ja paineet, joiden alla se toimitettiin. Tämä tieto on välttämätöntä. Se ei riitä riskin hyväksymiseen. Riippumaton arviointi luo tilaa sille, että joku voi haastaa perustelun kantamatta samoja lanseerauskannustimia. Riippumattomuus ei edellytä vihamielisyyttä tai ulkoista logoa jokaisella sivulla. Se edellyttää pätevyyttä, toimivaltaa, pääsyä näyttöön ja valtuutta kirjata eriävä näkemys, jota omistaja ei voi yksinkertaisesti poistaa.

Eurooppalainen rautatietoimintatapa tekee tästä erottelusta konkreettisen. ERA kuvaa arviointielimen, joka vastaa riskinarviointiprosessin ja sen tulosten oikean soveltamisen tarkistamisesta, ja asettaa vaatimuksia pätevyydelle, akkreditoinnille tai tunnustamiselle. Asetus sallii riippumattoman ja pätevän ulkoisen tai sisäisen toimijan, kunhan se täyttää kriteerit. Ratkaisu on oikeasuhtainen eikä teatraalinen. Se tunnustaa, että varmennus voi olla sisäistä, kun riippumattomuus on todellista, ja että merkki ei pelasta arvioijaa, joka ei näe olennaista näyttöä.

Tekoälyn kohdalla riippumattomuus voi olla kerroksittaista. Toimialueen omistaja varmistaa, että käyttö on asianmukaista ja että vaara-analyysi vastaa tehtyä työtä. Tekninen arvioija tarkistaa integraation ja vikatilat. Tietoturva-arvioija testaa pääsy- ja manipulointipolkuja. Käytön arvioija tarkistaa työmäärän, eskalaation ja palautumisen. Hallinto- tai vaatimustenmukaisuustoiminto tarkistaa asiakirjat ja velvollisuudet. Suuren vaikutuksen käyttötapauksissa ulkoinen arviointi tai ilmoitetun laitoksen reitti voi tulla kyseeseen sovellettavan oikeudellisen kehyksen mukaan. Turvallisuusperustelussa tulee nimetä kunkin arvioijan rooli ja kysymykset, joita heillä on oikeus esittää.

Riippumattomuus on myös suoja toimittajan läpinäkymättömyyttä vastaan. Toimittajan raportti voi tukea väitettä, mutta käyttöönottajan on tiedettävä, mitä testattiin, millä kokoonpanolla ja mitkä rajoitteet jäävät voimaan. Jos kriittistä tulosta ei voi toistaa, tarkastaa tai siirtää sopimuksen päättyessä, riippuvuus kuuluu perusteluun. Hankinnassa tulisi vaatia pääsyä näyttöön, versiotunnistetta, tapahtumailmoituksia, muutosilmoituksia, vientiä, palautusta ja käytännöllistä poistumistietä. Sana käytännöllinen tekee tässä paljon työtä. Oikeus, jota ei voi käyttää aikapaineen alla, ei ole juurikaan valvontakeino.

Hyvä arviointi tuottaa enemmän kuin hyväksymisleiman. Se kirjaa ehdot, avoimet havainnot, näytön aukot, jäännösriskin ja vaaditut jatkotoimet. Joskus oikea päätös on julkaista rajoituksin. Joskus se on viivyttää. Joskus se on hylätä ehdotettu käyttö. Turvallisuuskulttuuri ei ole sellainen, jossa jokainen tapaus läpäisee. Se on sellainen, jossa päätös seuraa perustelua.

Mitä tekoälyasetus tuo perusteluun

Tekoälyasetus ei muuta jokaista tekoälyn käyttöönottoa rautatieksi. Se kuitenkin luo eurooppalaisen sanaston riskienhallinnalle, tekniselle dokumentaatiolle, lokitukselle, läpinäkyvyydelle, inhimilliselle valvonnalle, tarkkuudelle, vankkuudelle ja kyberturvallisuudelle suuren riskin järjestelmissä. Turvallisuusperustelu voi auttaa organisaatiota yhdistämään nämä velvollisuudet toiminnalliseksi selitykseksi sen sijaan, että jokaista artiklaa käsiteltäisiin erillisenä vaatimustenmukaisuustehtävänä.

8 artikla sitoo vaatimustenmukaisuuden käyttötarkoitukseen ja yleisesti tunnustettuun tekniikan tasoon ja mahdollistaa tarpeellisten testausten, raporttien, tietojen ja dokumentaation yhdistämisen olemassa oleviin unionin yhdenmukaistamismenettelyihin, jos tuote kuuluu jo niiden piiriin. Tämä on tärkeää turvallisuustekniikan kannalta. Siinä tunnustetaan, että järjestelmällä voi jo olla kypsä varmennusprosessi ja että tiedostojen kopioiminen on vähemmän hyödyllistä kuin niiden yhdistäminen. Tapauksessa olisi osoitettava, missä tekoälyä koskeva näyttö sijoittuu laajemmassa tuote- tai palveluperustelussa.

11 artikla ja liite IV antavat tekniselle asiakirja-aineistolle laajan rakenteen. Siihen kuuluvat käyttötarkoitus, versiot, rajapinnat, laitteisto, kehitysmenetelmät, arkkitehtuuri, tietojen alkuperä ja ominaisuudet, ihmisen suorittama valvonta, ennalta määrätyt muutokset, validointi- ja testausmenettelyt, mittarit, testilokit ja kyberturvallisuustoimenpiteet. Tämä ei ole sama asia kuin turvallisuusperustelu, mutta se tarjoaa monia niistä kohteista, joita turvallisuusperustelu tarvitsee. Tiimi voi kartoittaa kunkin kohteen väitteeseen ja tuoda esiin sen, mille ei vielä ole omistajaa tai näyttöä.

12 artiklan lokivaatimus on erityisen käytännönläheinen. Jos suuririskisen järjestelmän on teknisesti mahdollistettava tapahtumien automaattinen tallentaminen koko sen elinkaaren ajan, julkaisupäätöksessä olisi kysyttävä, mitä järjestelmä voi todella rekonstruoida. Mitkä syötteet, mallit, kokoonpanot, näytöt, työkalujen kutsut, ihmisen toimet ja myöhemmät toimenpiteet voidaan yhdistää toisiinsa. Mitkä lokit ovat tarjoajan hallinnassa ja mitkä käyttöönottajan. Miten niitä suojataan ja säilytetään. Voiko asianomainen henkilö tai viranomainen ymmärtää olennaisen polun ilman, että hänelle luovutetaan valtava määrä asiaan liittymätöntä henkilötietoa.

15 artikla lisää elinkaarinäkökulman tarkkuuteen, vankkuuteen ja kyberturvallisuuteen, mukaan lukien sietokyky virheille, vioille ja epäjohdonmukaisuuksille sekä tarvittaessa varajärjestelmät tai vikasietosuunnitelmat. Turvallisuusperustelu antaa näille sanoille paikan, johon ne voivat asettua. Väite ei ole se, että pistemäärä on korkea. Väite on se, että järjestelmä toimii johdonmukaisesti käyttötarkoitustaan varten, että tunnetut vikatilanteet ovat rajattuja ja että työnkulussa on turvallinen toimintatapa niiden ilmetessä. Näytössä on ilmoitettava ne olosuhteet, joissa johtopäätös pätee.

Asetuksen velvoitteet soveltuvat järjestelmän, tarjoajan, käyttöönottajan ja käytön mukaan. Turvallisuusperustelun ei pitäisi teeskennellä, että yleinen malli ratkaisee luokittelun tai oikeudellisen neuvonnan. Siinä olisi kirjattava sovellettavuuspäätös, sen perustelut ja seikat, jotka muuttaisivat sitä. Tämä on toinen eksplisiittisten oletusten etu. Kun jokin tosiasia muuttuu, organisaatio tietää, mihin osaan perustelua on kiinnitettävä huomiota, sen sijaan että se joutuisi paniikissa kartoittamaan koko oikeudellisen kentän uudelleen.

Ilmailu käsittelee oppimista osana varmennusta

Euroopan unionin lentoturvallisuusviraston tekoälyä käsittelevä Concept Paper -asiakirjan toinen painos on hyödyllinen, koska se ei kuvaa tekoälyn turvallisuutta yksittäisen mallin ominaisuutena. Asiakirja tarkentaa ohjeistusta tason 1 sovelluksille, jotka parantavat ihmisen toimintakykyä, ja syventää työtä oppimisen varmennuksen, tekoälyn selitettävyyden ja etiikkaan perustuvan arvioinnin parissa. Se käsittelee myös tason 2 järjestelmiä, joissa tekoäly voi tehdä päätöksiä automaattisesti ihmisen valvonnassa, ja nostaa esiin ihmisen ja tekoälyn yhteistyön sekä turvallisen vuorovaikutuksen suunnittelun.

Tärkeä ajatus ei ole se, että jokaisen organisaation pitäisi kopioida ilmailualan terminologiaa. Se on se, että varmennuksen on seurattava järjestelmän ja ihmisen työn välistä suhdetta. Malli, joka auttaa koulutettua käyttäjää, ei ole sama turvallisuusongelma kuin malli, joka päättää sillä aikaa, kun ihminen vain valvoo. Käyttäjän kyky ymmärtää, puuttua asiaan ja toipua on osa järjestelmää. Samoin ovat oppimisen, päivitysten ja näytön rajat. EASA:n asiakirja antaa tekoälytiimeille eurooppalaisen esimerkin toimialasta, joka pyrkii tekemään näistä suhteista näkyviä ennen käyttöönottoa.

Oppimisvarmuus on hyödyllinen ilmaus, koska koneoppiminen voi muuttaa tavanomaista näyttökertomusta. Perinteinen ohjelmistojulkaisu voidaan testata määriteltyä toteutusta vasten. Mukautuva järjestelmä voi muuttaa käyttäytymistään, kun data, tila tai ympäristö muuttuu. Turvallisuusperustelun on siksi kerrottava, mitä saa oppia, mikä on jäädytetty, miten muutos havaitaan, mikä näyttö päivitetään ja milloin järjestelmä palaa hyväksyntäprosessiin. Jos oppiminen on perustelun ulkopuolella, perustelu koskee eilisen järjestelmää.

Ihmisen ja tekoälyn yhteistyö muuttaa myös valvonnan merkitystä. Ihminen ei ole hätäjarru, joka on kiinnitetty koneeseen, joka on suunniteltu ilman kuljettajaa. Tiimi on sosiotekninen järjestely, johon kuuluu rooleja, odotuksia, signaaleja, auktoriteettia ja koulutusta. Turvallinen vuorovaikutus voi edellyttää, että kone selittää rajoitteensa, pyytää vahvistusta, kieltäytyy toiminnosta tai tekee epävarmuuden näkyväksi. Se voi edellyttää, että ihminen haastaa koneen ja että organisaatio palkitsee tästä haastamisesta. Näytön tulisi tutkia vuorovaikutusta eikä päätellä sitä politiikkalauseesta.

Jälleen kerran keksittyä lentoa tai onnettomuutta ei tarvita asian havainnollistamiseen. Julkisen viraston konseptipaperi riittää osoittamaan, että eurooppalainen turvallisuusajattelu on siirtymässä kohti oppimista, ihmisen vuorovaikutusta ja varmuutta yhtenä suunnitteluongelmana. Tekoälytiimit voivat lukea materiaalin kehotuksena kysyä, mitä heidän oma järjestelmänsä oppii, mitä käyttäjä voi nähdä ja mikä näyttö säilyy muutoksen jälkeen.

Yhdistetty julkaisuportti, sellaisena nimettynä

Havainnollistava yhdistelmä, ei raportoitu tapahtuma: kuvitellaan julkinen palvelu, joka harkitsee tekoälytyökalua, joka auttaa henkilökuntaa järjestämään saapuvia käsittelymateriaaleja ennen kuin ihminen tekee päätöksen. Työkalu ei ole valtuutettu päättämään kelpoisuudesta, lähettämään ilmoitusta tai sulkemaan asiaa. Ehdotettu turvallisuusväite on kapea: koulutettu henkilökunta voi käyttää työkalua käsittelyjonon valmisteluun, kun lähdeasiakirja on täydellinen, näyttöpaneeli on näkyvissä, suositus on selvästi merkitty suositukseksi ja henkilökunnan jäsen voi ohittaa, keskeyttää tai poistaa sen.

Perustelun ensimmäinen haara nimeää vaarat. Epätäydelliselle asiakirjalle voitaisiin antaa näennäisen johdonmukainen prioriteetti. Vanhentunut politiikka-asiakirja voisi muokata suositusta. Jono voisi painostaa käsittelijää hyväksymään järjestyksen tarkistamatta. Käyttöoikeusvirhe voisi paljastaa yhden henkilön materiaalin toisessa asiassa. Toimittajan päivitys voisi muuttaa luokan merkitystä. Nämä eivät ole väitteitä siitä, että tällainen tapahtuma on sattunut. Ne ovat ehtoja, jotka tiimi voi kohtuudella ennakoida ehdotetusta suunnittelusta.

Seuraava haara nimeää hallintatoimet. Syötteen täydellisyys ja ajantasaisuus tarkistetaan ennen suosituksen näyttämistä. Suosituksen perustana käytetty näyttö on näkyvissä asian vieressä. Toiminto pysyy luonnoksena, kunnes koulutettu henkilö hyväksyy tai muuttaa sen. Puuttuva lähde ohjaa kohteen eri polulle. Käyttöoikeudet testataan hakurajapinnassa, ei vain käyttöliittymässä. Työnkulussa on keskeytyshallinta ja manuaalinen reitti. Versiomuutos toimii rajoitetussa tilassa ja se voidaan palauttaa. Asia kirjaa, miksi kukin hallintatoimi on olemassa ja mihin vaaraan se vastaa.

Näytön on sitten harjoitettava hallintatoimia. Datatesti syöttää epätäydellisiä ja vanhentuneita asiakirjoja ja kirjaa tuloksen. Käytettävyyskatsaus kysyy, löytävätkö työntekijät näytön ja ymmärtävätkö he suosituksen realistisessa työkuormassa. Käyttöoikeustesti tarkistaa, ettei asia voi hakea materiaalia toimialueensa ulkopuolelta. Julkaisuharjoitus varmistaa, että keskeytys- ja palautuspolut toimivat. Muutoskatsaus vahvistaa, etteivät uusi luokka ja politiikka mitätöi jonologiikkaa. Nämä ovat hypoteettisia testejä tässä yhdistelmässä, eivät raportteja nimetyn palvelun suorittamista testeistä.

Päätös on ehdollinen. Työkalua voidaan käyttää jonon valmisteluun määritellyssä laajuudessa. Sitä ei voida käyttää aineellisen päätöksen tekemiseen tai välittämiseen. Ehto, jonka mukaan henkilöstöllä on oltava valtuudet ohittaa päätös, on määritetty roolille. Ehtoa siitä, että lähteen ajantasaisuus kirjataan, seurataan. Muutos malliin, käytäntöön, datan käyttöehtoihin, käyttäjäjoukkoon tai jatkotoimiin avaa asian uudelleen. Jos organisaatio ei voi osoittaa näitä ehtoja täytetyiksi, julkaisuportti pysyy suljettuna. Kertomus on hyödyllinen juuri siksi, että kenenkään ei tarvitse teeskennellä, että jokin tietty kaupunki, tiimi tai tiistai on ollut olemassa.

Pieni esimerkki Trust Centeristämme

Julkinen Trust Center Dwevessä tekee arviointitietueessaan vastaavan erottelun. Arviointisivu esittelee menetelmän, joka yksilöi mallin, tarkan testisarjan, kokoonpanon, tallennetun tilan, näytön ja arvioijan päätöksen. Se erottaa arvioinnin identiteetin muuttuvasta mallin tilasta, erottaa valmistellun kattavuuden varsinaisesta tuloksesta ja kuvaa toiston sopimuksena, joka riippuu tallennetusta artefaktista, suorituskaaviosta, reitityksestä, järjestyksestä, tilasta, rajoitteista, työkaluista ja näytöstä. Sivulla todetaan myös, että ensimmäistä ulkoista julkaisutulosta ei ollut olemassa 1. elokuuta 2026, koska julkaisua ei ollut tapahtunut.

Tämä on pieni esimerkki, ei todiste siitä, että turvallisuusperustelu on tehty järjestelmiemme kaikkeen käyttöön. Sen arvo on rajassa. Menetelmä ei ole tulos. Luokka ei ole pistemäärä. Suunniteltu julkaisu ei ole historiallinen suoritus. Toistettavissa oleva tallennettu tila ei ole sama kuin elävä maailma, jonka näyttö ja mukautuva tila ovat muuttuneet. Nämä erottelut ovat juuri sitä, mitä turvallisuusperustelu tarvitsee sanoessaan, mihin näyttö soveltuu ja missä se loppuu.

Eurooppalaiselle teknologiayritykselle tällaisten rajojen julkaiseminen voi tuntua siltä, että hyödyllistä markkinointitilaa jää käyttämättä. Se on hyödyllisempää kuin tilan täyttäminen numerolla, jota kukaan ei voi puolustaa. Sama kurinalaisuus koskee julkista viranomaista, toimittajaa, tutkimusryhmää tai sisäistä alustatiimiä. Kerro, mikä näyttö on olemassa, mikä on valmisteltu, mikä on suojattu, mitä ei kerätty ja mikä tuleva tapahtuma loisi uuden tuloksen. Lukija voi sitten päättää, mitä näyttö tukee.

Esimerkkimme osoittaa myös, miksi Trust Centeriä tulisi lukea näyttöhakemistona eikä lupauksena. Julkinen sivu osoittaa identiteetin, menetelmän, tallennuksen, arvioinnin ja julkaisun rajat. Se ei poista tarvetta tarkastella tiettyä käyttöönottoa, käyttötarkoitusta tai vaikutusten kohteena olevaa väestöä. Turvallisuusperustelu lisäisi paikallisen kontekstin, varsinaisen työnkulun vaarat ja päätöksen tekijän toimivallan. Julkinen läpinäkyvyys on lähtöpinta, ei yleispätevä todistus.

Mitä turvallisuusperustelu voi osoittaa

Hyvä turvallisuusperustelu voi tukea rajattua päätelmää. Se voi osoittaa, että järjestelmä on suunniteltu nimettyyn tarkoitukseen, että ennakoitavissa olevat vaarat on tunnistettu, että hallintakeinot kohdistuvat näihin vaaroihin, että näyttö on kerätty ilmoitetuissa olosuhteissa, että jäännösriskit on arvioitu, että toimivaltainen viranomainen on hyväksynyt tai hylännyt käytön ja että organisaatiolla on tapa havaita muutokset ja käsitellä päätös uudelleen. Se voi tehdä väitteestä riittävän tarkasteltavan haastamista ja ylläpitoa varten.

Se voi myös osoittaa, mikä on epävarmaa. Perustelu voi osoittaa vahvan näytön yhdelle väestölle ja rajallisen näytön toiselle. Se voi osoittaa, että järjestelmä on vakaa määritellylle virheellisen syötteen luokalle, mutta ei tuntemattomalle luokalle. Se voi osoittaa, että ihminen voi puuttua asiaan, kun henkilöstö ja käyttöoikeudet ovat määritellyt. Se voi osoittaa, että varajärjestelmä on olemassa, mutta sitä ei ole vielä testattu täydessä operatiivisessa mittakaavassa. Totuudenmukainen perustelu ei piilota näitä epäsymmetrioita. Se tekee niistä käytön ehtoja.

Turvallisuusperustelu voi tukea myös hankinta- ja hallintopäätöksiä. Ostaja voi verrata toimittajan tarjoamaa näyttöä siihen näyttöön, jota työnkulku edellyttää. Valvoja näkee, mitkä väitteet on tuettu ja mitkä tiedot puuttuvat. Hallitus ymmärtää, missä jäännösriski sijaitsee ja kuka sen omistaa. Käyttäjä tietää, minkä signaalin pitäisi aiheuttaa pysäytys. Vaikutuspiirissä olevilla ihmisillä on selkeämpi reitti kyseenalaistaa tulos. Perustelusta tulee vastuun kartta, ei pelkkä tekninen artefakti.

Se voi tukea muutosta teeskentelemättä, että muutos olisi ilmaista. Yhdistämällä väitteet, vaarat, oletukset, hallintakeinot ja näytön organisaatio voi tunnistaa pienimmän merkityksellisen uudelleenarvioinnin, kun jokin osa muuttuu. Se on tehokkaampaa kuin jokaisen testin sokea toistaminen ja turvallisempaa kuin olettaminen, ettei uudelleenarviointia tarvita. Suhteellisuus toimii vain, kun rakenne on näkyvissä. Muuten tiimi joko suorittaa rituaaleja tai ottaa oikoteitä.

Mitä turvallisuusperustelu ei voi todistaa

Turvallisuusperustelu ei voi todistaa, ettei haittaa koskaan tapahdu. Todelliset järjestelmät kohtaavat olosuhteita, joita ei ennakoitu, ja ihmiset reagoivat kannustimiin ja paineisiin tavoilla, joita mikään kaavio ei voi täysin ennustaa. Tarkoitus ei ole varmuus. Se on kurinalainen perusta toiminnalle, oppimiselle ja pysäyttämiselle silloin, kun perusta ei enää päde.

Se ei voi todistaa, että malli on yleisesti älykäs, yleisesti oikeudenmukainen tai turvallinen kaikilla alueilla. Näytöllä on rajansa. Testi yhdellä aineistolla ei ratkaise suorituskykyä toisella. Onnistunut arviointi yhdessä työnkulussa ei vakiinnuta samaa auktoriteettia toisessa. Hyvin suunniteltu pysäytysreitti ei todista, että jokainen käyttäjä käyttää sitä ilman koulutusta, aikaa tai organisaation tukea. Perustelun on vastustettava kiusausta muuttaa paikallinen näyttö maailmanlaajuiseksi adjektiiviksi.

Se ei voi siirtää vastuuta toimittajalle, auditoijalle tai sertifiointimerkille. Näytön voi tuottaa joku muu, mutta käyttöönotto-organisaatiolla on silti käyttötarkoitus, työnkulku ja ihmisiä, jotka ovat riippuvaisia lopputuloksesta. Sopimuksilla voidaan jakaa velvollisuuksia ja järjestää pääsy. Ne eivät voi tehdä organisaatiosta tietämätöntä järjestelmästä, jota se käyttää. Eikä sertifikaatti voi hyvittää muutosta, joka vie järjestelmän arvioidun soveltamisalan ulkopuolelle.

Se ei voi tehdä kielletystä tai soveltumattomasta käytöstä hyväksyttävää lisäämällä paperityötä. Jos vaaraa ei voida hallita hyväksyttävälle tasolle, vastaus voi olla käyttötarkoituksen muuttaminen tai käyttöönotosta luopuminen. Turvallisuusperusteluja kuvataan usein varmistukseksi, mutta arvokkain lopputulos voi olla hyvin perusteltu ei. Täydellinen asiakirja voi silti tukea huonoa päätöstä, jos perustelu on heikko. Asiakirjan tarkoitus on parantaa päätöstä, ei vain tehdä siitä jälkikäteen helpommin luettavaa.

Lopuksi se ei voi korvata lakia, ammatillista harkintaa tai demokraattista vastuuvelvollisuutta. Se on tekninen ja hallinnollinen väline. Sen pitäisi auttaa ihmisiä ymmärtämään päätös ja sen ehdot, ei teeskennellä ratkaisevansa kysymyksiä, jotka kuuluvat tuomioistuimille, valvojille, kliinikoille, viranomaisille tai vaikutuspiirissä oleville ihmisille.

Kysymyksiä eurooppalaiseen julkaisukokoukseen

Tiimin ei tarvitse odottaa täydellistä standardia tai 400-sivuista kansiota aloittaakseen. Se voi esittää sarjan yksinkertaisia kysymyksiä. Mitä tarkalleen väitämme tämän järjestelmän saavan tehdä. Keihin vaikuttaa, kun se on väärässä. Mitkä vaarat ovat järjestelmän ja työnkulun ehtoja eivätkä epämääräisiä huonoja lopputuloksia. Minkä oletusten on pysyttävä totta. Mikä näyttö tukee kutakin väitettä, ja missä kokoonpanossa ja missä populaatiossa. Mikä jää epävarmaksi. Kuka hyväksyy jäännösriskin. Kuka voi pysäyttää järjestelmän. Mikä tapahtuma avaisi perustelun uudelleen.

Kokouksessa pitäisi olla tilaa epämukavammalle kysymykselle: mikä saisi meidät kieltäytymään julkaisusta. Jos ainoa vastaus on huonompi pistemäärä, tiimi ei todennäköisesti ole kuvannut riskejään. Kieltäytymisen voi laukaista puuttuva näyttö, omistamaton oletus, epäonnistunut palautusharjoitus, saavuttamaton arvioija, rajaton integraatio tai muutos, jota ei voi toistaa. Kieltäytymisehtojen nimeäminen muuttaa turvallisuuden toiminnalliseksi ohjaukseksi tunnelman sijaan.

Kysy, miten tapaus kulkee järjestelmän mukana. Löytääkö käyttäjä käyttötarkoituksen, rajoitukset ja pysäytysreitin. Pystyykö tapaturmatutkija tunnistamaan mallin, näytön, käyttöoikeudet ja inhimilliset päätökset, joilla oli merkitystä. Voiko ostaja viedä tiedot mukanaan, jos toimittaja vaihtuu. Saako viranomainen tiedot, joita vaatimustenmukaisuuden arviointi edellyttää. Ymmärtääkö uusi tiimi, miksi ohjaus on olemassa, ilman että sen täytyy haastatella lähtenyttä henkilöä. Turvallisuusperustelu, joka elää vain yksityisessä kansiossa, on hauras muisto, ei elävä argumentti.

Kysy, miten tapaus muuttuu. Mikä on arvioinnin laukaisin mallipäivitykselle, lähdemuutokselle, käytäntömuutokselle, uudelle käyttäjäryhmälle, uudelle työkalulle, uudelle lainkäyttöalueelle tai uudelle jatkotoimelle. Mitkä arvioinnit toistetaan ja mitkä oletukset tarkistetaan. Mitä tapahtuu, kun seuranta havaitsee heikon signaalin mutta ei vielä vakavaa tapausta. Onko olemassa turvallinen, omistettu reitti pysähtyä ja tutkia. Hyvin johdettu organisaatio pystyy vastaamaan ilman, että sen täytyy keksiä kriisi tehdäkseen prosessista todellisen tuntuisen.

Ja kysy, voivatko ihmiset, joiden päätöstä näytön on tarkoitus tukea, lukea sen. Tekninen asiakirja, jota kukaan ei osaa tulkita, ei ole läpinäkyvä. Käytäntö, jota kukaan ei osaa soveltaa, ei ole ohjaus. Hallintapaneeli täynnä vihreitä soluja, joka piilottaa nimittäjän, ei ole vakuutus. Eurooppalainen turvallisuuskäytäntö on parhaimmillaan silloin, kun se tekee päättelyn saataville vastuussa olevalle henkilölle, ei vain sille, joka kokosi asiakirjan.

Rehellisen argumentin hiljainen etu

Turvallisuusperustelut näyttävät etäältä byrokraattisilta, koska ne sisältävät tietueita, rooleja, ehtoja ja tarkistuspisteitä. Läheltä ne ovat tapa pitää suunnittelutyö rehellisenä, kun järjestelmistä tulee vakuuttavia. Ne estävät testiä esiintymästä päätöksenä, oletusta tosiasiana, suunniteltua arviointia tuloksena ja ihmisen läsnäoloa auktoriteettina.

Euroopalla on jo osia tästä kurinalaisuudesta instituutioissaan. Rautatiet käsittelevät teknistä, toiminnallista ja organisatorista muutosta riskikysymyksenä ja käyttävät yhteisiä menetelmiä ja riippumatonta arviointia. Ilmailun ohjeistuksessa käsitellään oppimisvarmuutta, selitettävyyttä ja ihmisen ja tekoälyn yhteistyötä. AI-asetus yhdistää elinkaaririskien hallinnan dokumentaatioon, lokitietoihin, läpinäkyvyyteen, ihmisen valvontaan ja elinkaaren suorituskykyyn. Nämä eivät ole samanlaisia viitekehyksiä, eikä niitä pidä litistää yhdeksi tarkistuslistaksi. Niitä yhdistää kunnioitus ehtoja, näyttöä ja vastuuta kohtaan.

Käytännön opetus on riittävän yksinkertainen vietäväksi maanantaipalaveriin. Aloita väitteestä, jolla on rajat. Nimeä riskit, jotka voisivat tehdä siitä epätoden. Kirjaa oletukset, joiden varassa se seisoo. Aseta ohjaukset sinne, missä työ todella tapahtuu. Liitä näyttöön tunniste ja laajuus. Arvioi jäännösriski sen sijaan, että piilottaisit sen. Anna henkilölle todellinen valta puuttua asiaan. Avaa argumentti uudelleen, kun järjestelmä tai konteksti muuttuu. Anna riippumattoman arvioijan olla hankala. Julkaise rajoitukset yhtä huolellisesti kuin onnistumiset.

Tämä lähestymistapa ei tee kaikista tekoälyjärjestelmistä turvallisia, eikä se muuta epävarmuutta varmuudeksi. Se tekee epävarmasta luottamuksesta vaikeammin ylläpidettävää. Se antaa käyttäjille reitin pysähtyä, arvioijille konkreettista haastettavaa ja asianosaisille paremman selityksen siitä, missä vastuu on. Se myös helpottaa hyvien järjestelmien parantamista, koska organisaatio näkee, mikä osa argumentista muuttui.

A safety case is therefore not a final paragraph after the engineering. It is the thread that ties purpose, design, people, evidence and change together. Europe can learn from safety cases because they offer a civic version of engineering discipline: no slogan is accepted without a route, no route is accepted without evidence, and no evidence is allowed to travel farther than its assumptions.

Sources