Sääntelijä ja liikkuva maali

Kyllä, mutta ei teeskentelemällä, että mukautuva järjestelmä on staattinen objekti. Auditointi edellyttää tallennettua tilaa, rajattua väitettä, ehdollista...

Sääntelijä ja liikkuva maali

Auditointi saa ottaa valokuvan

Liikkuva kohde ei ole tarkastelun ulottumattomissa. Se on vain sellaisen tarkastelun ulottumattomissa, joka kysyy yhden ajattoman kysymyksen ja odottaa yhtä ajatonta vastausta. Tällä erolla on merkitystä. AI-järjestelmät muuttuvat usealla tavalla yhtä aikaa. Palveluntarjoaja julkaisee uuden malliversion. Käyttöönottaja muuttaa kehotetta tai päätöskynnystä. Hakukorpus saa uuden politiikka-asiakirjan. Identiteettisääntö muuttaa sitä, kuka saa kutsua työkalua. Työkalu saa uuden kentän, menettää kentän tai alkaa palauttaa eri merkityksen saman kentän nimen alla. Ihmistiimi muuttaa toimintatapaansa. Maailma, joka toimittaa syötteet, muuttuu kysymättä kenenkään julkaisupäällikön lupaa.

Mikään tästä ei tee auditoinnista turhaa. Se tekee auditoinnin kohteesta tarkemman. Kysymys ei ole siitä, voiko organisaatio todistaa, että järjestelmä pysyy muuttumattomana ikuisesti. Se olisi outo lupaus jopa tietokantaan yhdistetylle laskimelle. Kysymys on siitä, voiko organisaatio osoittaa, mikä järjestelmä oli toiminnassa olennaisena ajankohtana, mitä sen oli tarkoitus tehdä, mikä näyttö tuki käyttöä, mitkä ehdot rajastivat näytön, kuka omisti päätöksen ja minkä myöhemmän muutoksen pitäisi johtaa päätöksen avaamiseen uudelleen.

Auditointi saa ottaa valokuvan. Sen ei vain pidä kutsua valokuvaa maisemaksi. Asianmukainen tallenne tunnistaa tilan, jota tarkastettiin, ja säilyttää reitin siitä tilasta seuraavaan. Se voi sitten sanoa jotakin hyödyllistä: tämä arviointi koski tätä mallia, näitä asetuksia, tätä datarajaa, näitä työkaluja, tätä politiikkaa, tätä työnkulkua ja tätä julkaisupäätöstä. Se voi myös sanoa jotakin vähemmän mukavaa ja arvokkaampaa: johtopäätös ei siirtynyt automaattisesti seuraavaan tilaan.

Tämä on parempi lähtökohta kuin tuttu muuttumattomien merkkien teatteri. Merkki antaa ymmärtää, että joku on ratkaissut asian. Auditointitallenteen pitäisi tehdä mahdolliseksi nähdä, mikä ratkaistiin, millä perusteella, mihin käyttöön ja kuinka kauan peruste pysyi sovellettavissa. Sääntelijä ei tarvitse jäädytettyä organisaatiota. Sääntelijä tarvitsee organisaation, joka osaa erottaa jäädytetyn tallenteen toimivasta palvelusta käsittelemättä kumpaakaan mystisenä kohteena.

Euroopan AI-säännöt osoittavat jo tähän suuntaan. Korkean riskin AI-järjestelmissä tekoälyasetus edellyttää teknistä dokumentaatiota ennen järjestelmän saattamista markkinoille tai käyttöönottoa ja edellyttää sen pitämistä ajan tasalla. Se edellyttää myös olennaisten tapahtumien automaattista tallentamista järjestelmän elinkaaren ajalta sekä dokumentoitua markkinoille saattamisen jälkeistä seurantajärjestelmää, joka on oikeassa suhteessa teknologiaan ja riskiin. Nämä eivät ole ohjeita yhden seremoniallisen kuvakaappauksen ottamiseen. Ne ovat ohjeita säilyttää näyttöpolku muutoksen läpi.

Liikkuva kohde on yleensä järjestelmä

On houkuttelevaa kuvata AI-järjestelmä mallina ja käsitellä sitten versiointia ikään kuin uusi mallipainotiedosto olisi koko tarina. Tämä on kätevää esityskalvoille ja epätarkkaa useimpiin operatiivisiin kysymyksiin. Malli on tärkeä osa. Se on harvoin se täydellinen kohde, jonka käyttäytyminen vaikuttaa ihmiseen, työnkulkuun tai oikeudelliseen velvoitteeseen.

Tarkastellaan tavallista päätöksenteon tukireittiä, joka kuvataan tässä hypoteettisena esimerkkinä eikä kuvauksena todellisesta käyttöönotosta. Käyttäjä lähettää pyynnön. Palvelu hakee asiakirjat, joita se saa käyttää. Malli luonnostelee suosituksen. Sääntö tarkistaa, onko vaadittu näyttö läsnä. Koulutettu arvioija voi hyväksyä, muuttaa tai hylätä suosituksen. Työnkulku tallentaa sitten toiminnon. Havaittu lopputulos riippuu muustakin kuin mallista. Se riippuu lähdeversioista, hakujen asetuksista, käyttöoikeuksista, käyttöliittymän sanamuodosta, kynnyksistä, jonosäännöistä, ihmisen toimivallasta ja toiminnan rajasta.

Jos lähdeaineisto muuttuu, malli voi saada erilaisen tosiasiapohjan ilman että yksikään parametri muuttuu. Jos kehote muuttuu, mallia voidaan pyytää tekemään erilainen arviointi. Jos arvioijan näyttö lakkaa näyttämästä epävarmuutta, riskitiedostossa kuvattu ihmisen suorittama valvonta ei välttämättä enää ole sitä valvontaa, jota ihmiset todellisuudessa harjoittavat. Jos integraatio alkaa soveltaa suosituksia automaattisesti, järjestelmä on saanut uuden toimivallan, vaikka mallin vastaus olisi tavu tavulta identtinen.

Siksi järkevä auditointitietue alkaa käyttötarkoituksesta ja järjestelmän rajauksesta. AI-asetuksen liitteen IV teknisen dokumentaation vaatimuksiin kuuluvat kuvaukset käyttötarkoituksesta, versioista, seuranta- ja ohjaustoiminnoista, validoinnista ja testauksesta, riskienhallinnasta, elinkaaren aikana tehdyistä muutoksista sekä olennaisista suorituskykymittareista. Ei ole tarkoitus, että jokainen järjestelmä tarvitsee paperivuoren. Tarkoitus on, että arvioija ei voi arvioida väitettä, jos väitteen kohteena oleva asia muuttaa hiljaa muotoaan.

Laajemman kokonaisuuden kutsuminen järjestelmäksi ei ole tapa saada työ kuulostamaan mahtipontisemmalta. Se on tapa välttää kategoriavirhe. Mallin arviointi voi vastata mallia koskevaan kysymykseen. Järjestelmäauditoinnin on vastattava järjestelmää koskevaan kysymykseen. Ensimmäinen voi osoittaa, miten komponentti käyttäytyi määritellyissä olosuhteissa. Jälkimmäisen on osoitettava, miten komponentti oli kytketty ihmisiin, tietoihin, sääntöihin, työkaluihin ja seurauksiin. Kumpikaan ei korvaa toista. Mallin pistemäärä ei ole työnkulun kuvaus, aivan kuten hyvä rengastesti ei ole reittisuunnitelma.

Mitä auditoija todellisuudessa yrittää selvittää

Muuttuvan järjestelmän auditointi ei tarkoita sen elämän joka hetken toistamista kokoushuoneessa. Se tarkoittaa tiettyjen väitteiden tekemistä tarkastettaviksi. Käytettiinkö järjestelmää ilmoitetun käyttötarkoituksen mukaisesti? Tukeeko julkaisupäätöstä tähän tarkoitukseen soveltuva näyttö? Säilyttikö organisaatio tiedot, joita tarvitaan kiistellyn lopputuloksen selvittämiseen? Käynnistivätkö merkitykselliset muutokset uudelleenarvioinnin? Tekikö seuranta näkyväksi eron harmittoman päivityksen ja olennaisen muutoksen välillä? Pystyivätkö vastuuhenkilöt pysäyttämään, rajoittamaan tai korjaamaan reitin, kun näyttö ei enää pitänyt?

Nämä ovat käytännöllisiä kysymyksiä, koska jokaiseen niistä löytyy havaittava vastine. Käyttötarkoitus kuuluu tietueeseen. Arvioinnilla on testisarja, konfiguraatio, testipopulaatio tai syöterajaus, menetelmä, tulos ja rajoitus. Julkaisupäätöksellä on omistaja ja ehdot. Muutoksella on identiteetti, päivämäärä, syy ja arvioitu vaikutus. Seurannalla on nimetyt signaalit, kynnysarvot tai tarkistuslaukaisimet. Pysäytysreitillä on toimivalta ja toiminta. Yksityiskohdat vaihtelevat, mutta auditoitavuus syntyy siitä, että abstraktit vakuuttelut muutetaan asioiksi, joita joku muu voi tarkastaa.

Tässä on tärkeä raja. Auditointi ei todista, että jokainen tuleva tuotos on oikea, oikeudenmukainen tai haitaton. Se ei voi muuttaa epävarmaa maailmaa deterministiseksi. Se voi osoittaa, tekikö organisaatio väitteitä, jotka olivat riittävän rajattuja tutkittaviksi, keräsikö se näyttöä, joka pystyi tukemaan näitä väitteitä, ja säilyttikö se kyvyn harkita niitä uudelleen. Se voi kuulostaa vaatimattomalta. Se on myös se kohta, josta vastuullisuus alkaa.

Erolla näytön ja vakuuttelun kielen välillä on merkitystä. Sen sanominen, että malli on arvioitu, ei vielä ole näyttöä hyödyllisestä arvioinnista. Sana tarvitsee kohteen. Arvioitu mihin tehtävään, mihin kriteereihin ja mihin aineistoon nähden? Millä mallilla ja missä järjestelmän tilassa? Missä käyttöolosuhteissa? Kuka tarkisti menetelmän? Mikä jäi rajauksen ulkopuolelle? Mikä tekisi tuloksesta vanhentuneen? Ilman näitä kysymyksiä arviointi on vain rauhoittava mennyt aikamuoto.

Euroopan komission aiemmat luotettavan tekoälyn eettiset ohjeet määrittelivät toistettavuuden yksinkertaisesti: tekoälykokeen pitäisi tuottaa sama käyttäytyminen, kun se toistetaan samoissa olosuhteissa. Tämä on hyödyllinen määritelmä, koska se sisältää oman rajansa. Samat olosuhteet tekevät todellista työtä. Toistettu koe voi osoittaa, onko kirjattu väite toistettavissa. Se ei voi osoittaa, että muuttumaton käyttäytyminen syntyy, kun tietolähde, käytäntö tai käyttöönottoreitti muuttuu. Toistettavuus ei siis ole lupaus siitä, että maailma pysyy paikallaan. Se on kurinalaista tapaa kertoa tarkasti, mitä tapahtui.

Tallennettu arviointi on ajankuva. Auditista tulee kestävä, kun seuraavaa tilaa voidaan verrata siihen.

Versionumero on välttämätön mutta ei riittävä

Versionumerot ovat hyödyllisiä, koska ne estävät tallennetta väittämästä, että nimet riittävät. Versiotarra voi kuitenkin myös luoda väärää varmuutta. Esimerkiksi versio 4.2 voi yksilöidä ohjelmistojulkaisun, mutta se ei välttämättä yksilöi tekoälyreitin todellista tilaa. Konfiguraatioarvo voi sijaita mallivaraston ulkopuolella. Hakemisto voidaan rakentaa uudelleen muuttuvista asiakirjoista. Ominaisuuslippu voi valita eri työkalupolun. Käytäntömoottori voi muuttaa sallittua toimintoa. Palvelulla voi siis olla moitteettomasti muotoiltu versionumero ja se voi silti olla vaikea rekonstruoida.

Ratkaisevaa on väitteeseen sopiva identiteetti. Jos väite koskee offline-mallin vertailuarvoa, mallin artefakti, päättelykoodi, parametriasetukset, tietoaineiston versio, metriikan määritelmä ja suoritusympäristö voivat olla olennaisia. Jos väite koskee reaaliaikaista päätöksenteon tukipalvelua, tallenteeseen voi lisäksi olla tarpeen sisällyttää kehote tai mallipohja, hakukonfiguraatio, lähdetunnisteet ja tuoreus, käyttöoikeustila, työkalumallit, käytäntöversio, arvioijan käyttöliittymä ja työnkulkusääntö. Audit-paketin ei tarvitse sisältää jokaista tavua jokaisesta järjestelmästä. Sen on sisällettävä tai luotettavasti osoitettava ne elementit, jotka voivat muuttaa väitteen merkitystä.

Siksi manifesti on usein hyödyllisempi kuin kiintolevylle kaadettu arkisto. Manifesti kertoo, mitkä artefaktit kuuluvat yhteen, niiden tunnisteet, niiden eheysviittaukset, niiden suhteet ja niiden käyttöehdot. Sen avulla auditoija voi paikantaa asiaankuuluvan paketin ilman oletusta, että kaikki lähteet voidaan kopioida rajoittamattomaan kansioon. Osa todisteista sisältää henkilötietoja, tietoturvan kannalta arkaluonteisia tietoja, lisensoitua materiaalia tai liikesalaisuuksia. Auditoitavuus edellyttää hallittua pääsyä ja mielekästä jäljitettävyyttä, ei pakollista julkista paljastamista kaikesta, mikä saa järjestelmän toimimaan.

Liite IV noudattaa samanlaista käytännönläheistä lähestymistapaa. Se ei käsittele teknistä dokumentaatiota lyhyenä tuotekuvauksena. Se edellyttää tietoja järjestelmästä ja sen elinkaaresta, mukaan lukien kehityksen aikana ja markkinoille saattamisen jälkeen tehdyt muutokset, seuranta- ja valvontatoiminnot, validointi- ja testausmenettelyt sekä niiden tulokset, riskinhallintatoimenpiteet ja suorituskykymittareiden kuvaus. Dokumentin on oltava riittävän selkeä, jotta kansalliset toimivaltaiset viranomaiset ja ilmoitetut laitokset voivat arvioida vaatimustenmukaisuuden. Toisin sanoen tiedot on järjestettävä tarkastelua varten, ei pelkästään kerättävä siksi, että tallennusjärjestelmä oli käytettävissä.

Tämän kaiken taustalla on pieni mutta ratkaiseva suunnittelukysymys: mitä pitäisi muuttua, jotta aiempi näyttö ei enää voisi tukea nykyistä väitettä? Vastaus luo versiorajan. Jos uusi hakulähde muuttaa suositusten tosiasiallista perustaa, se kuuluu identiteettiin. Jos uusi arvioijan käyttöliittymä peittää varoituksen, se kuuluu identiteettiin. Jos kosmeettinen tekstimuokkaus ei voi vaikuttaa arvioituun käyttäytymiseen, se kuuluu todennäköisesti muutoshistoriaan mutta ei arvioinnin sormenjälkeen. Hyvä versiointi ei ole maksimaalista keräämistä. Se on harkittua relevanssia.

Tallenna sopimus, ei vain tuotosta

Tuotos on näyttöä jostakin, mutta se ei aina ole näyttöä riittävästä. Kuvakaappaus voi osoittaa, mitä näytöllä näkyi. Se ei usein voi osoittaa, mikä malli tuotti sen, mikä lähde haettiin, mitä työkalu palautti, mitä sääntöä sovellettiin, mitkä syötteet jätettiin pois tai peittikö näkymä varoituksen. Tämä on yksi syy siihen, miksi kuvakaappaukset kertyvät vaatimustenmukaisuuskansioihin arkeologisten löytöjen vakavuudella mutta huomattavasti vähäisemmällä selitysvoimalla.

Tallennettu sopimus on rikkaampi. Se sitoo lopputuloksen olosuhteisiin, joissa järjestelmän odotettiin toimivan. Arvioinnin osalta se voi sisältää tarkan testisarjan, syötteet tai suojatun viittauksen niihin, odotetut vahvistukset, malli- ja palvelukokoonpanon, asiaankuuluvat käytäntö- ja työkaluversiot, suoritusympäristön siltä osin kuin se vaikuttaa tulokseen, ja hyväksymissäännön. Reaaliaikaisen suorituksen osalta se voi sisältää pyynnön identiteetin, valtuutetun laajuuden, lähde- ja hakutiedot, mallin reitin, työkalujen kutsut, hallintatoimet, ihmisen puuttumisen ja tuloksena olevan tilamuutoksen. Tavoitteena ei ole tallentaa loputonta päiväkirjaa. Tavoitteena on säilyttää riittävästi kausaalisesti relevanttia tietoa, jotta myöhemmin voidaan esittää vakava kysymys.

On hyödyllistä tehdä erottelu. Arvioinnin tallenne osoittaa väitteen määritellystä testistä tai harjoituksesta. Operatiivinen tallenne auttaa rekonstruoimaan tietyn tapahtuman tai päätöksen. Julkaisutallenne selittää, miksi organisaatio salli järjestelmän määritellylle reitille. Muutostallenne selittää, mitä myöhemmin muutettiin. Nämä tallenteet ovat päällekkäisiä, mutta niitä ei pidä sekoittaa keskenään. Tuotantolokin kohteleminen vertailuarvona tai vertailuarvon kohteleminen näyttönä tuotantoprosessista on tehokas tapa saada jokainen tallenne kantamaan enemmän kuin se kestää.

AI-asetuksen lokitusvaatimus korkean riskin järjestelmille on samalla tavoin sidottu tarkoitukseen. 12 artikla edellyttää asiaankuuluvien tapahtumien automaattista tallentamista järjestelmän elinkaaren ajan, ja lokitusominaisuuksien on oltava tarkoitukseen sopivat. Asetus viittaa järjestelmän toiminnan jäljitettävyyteen, toiminnan seurantaan ja markkinoille saattamisen jälkeiseen seurantaan. Se ei edellytä summittaista tallennustapaa. Se edellyttää tallenteita, joilla on tehtävä.

Tuon ilmauksen, tietueet työtehtävän kanssa, ohjaa paremmin kuin yleinen vaatimus havaittavuudesta. Mallitunniste voi auttaa erottamaan päivityksen. Syötedatan alkuperä voi selittää yllättävän suosituksen. Säännön versio voi selittää, miksi tulos estettiin. Arvioijan ohitus voi selittää, miksi operatiivinen toimenpide poikkeaa mallin ehdotuksesta. Aikaleima voi vahvistaa järjestyksen. Yksityisyyttä kunnioittava suunnittelu kysyy silti, onko jokainen kenttä tarpeellinen, oikeasuhteinen, säilytetäänkö sitä määritellyn ajan ja onko se suojattu siltä järjestelmältä, jota sen on tarkoitus tarkastaa.

Toistettavuudella on kaksi rehellistä muotoa

Ihmiset käyttävät usein sanaa toistettava tarkoittamaan monia eri asioita. Sekaannus on ymmärrettävää. Tiimi voi tarkoittaa, että se pystyy ajamaan kiinteän arvioinnin uudelleen ja saamaan saman tuloksen. Tutkija voi tarkoittaa, että toinen tiimi pystyy suorittamaan kuvatun menetelmän ja tarkastelemaan tulosta. Operaattori voi tarkoittaa, että tutkinta pystyy luomaan uudelleen tiettyä päätöstä varten käytetyn tilan. Asiakas voi tarkoittaa, että työnkulku kohtelee johdonmukaisesti eikä muutu mielivaltaisesti tiistaista torstaihin. Nämä ovat toisiinsa liittyviä tavoitteita. Ne eivät ole yksi ominaisuus, jolla on monta hattua.

Ensinnäkin on tallennetun suorituksen toistettavuus. Jos artefakti, konfiguraatio, syötteet, olennainen tila ja suoritusolosuhteet pidetään kiinteinä, toisto tuottaa dokumentoidun tuloksen järjestelmän lupaamissa olosuhteissa. Jotkin järjestelmät voivat esittää vahvemman deterministisen väitteen määritellylle suorituspolulle. Toiset luottavat hallittuun satunnaisuuteen, hajautettuun infrastruktuuriin tai kolmannen osapuolen palveluihin ja voivat esittää vain suppeamman väitteen. Vastuullinen kieli on täsmällistä. Se kertoo, mikä on kiinteää, mitä mitataan, mikä vaihtelu on edelleen mahdollista ja miten vertailu suoritetaan.

Toiseksi on arviointiperustelun toistettavuus. Arvioijan on voitava nähdä, miksi testisarja edustaa väitettä, onko mittarilla kuvattu merkitys, onko hyväksymiskynnys perusteltu ja voiko näyttö siirtyä operatiiviseen kontekstiin. Tätä ei ratkaise tarkistussumma. Tarkistussumma voi vahvistaa, että tiedosto ei ole muuttunut. Se ei voi vahvistaa, että tiedosto testasi oikeaa kysymystä, että populaatio oli asianmukainen tai että pistemäärä tukee siihen liitettyä päätöstä.

Näiden kahden muodon tulisi kohdata. Täydellisesti toistettava testi, joka mittaa väärää asiaa, on silti väärä testi. Hienostunut perustelu, joka on liitetty ei-toistettavaan suoritukseen, jättää arvioijat kykenemättömiksi erottamaan havainnon onnekkaasta iltapäivästä. Hyödyllinen standardi ei ole abstrakti vaatimus täydellisestä toistettavuudesta. Se on näkyvä vastaavuus väitteen, menetelmän, tallennettujen olosuhteiden, havaitun tuloksen ja käytön välillä, jonka organisaatio haluaa sallia.

Komission ohjeistus yleiskäyttöisten tekoälytarjoajien velvoitteista pitää myös arvioinnin yhteydessä dokumentaatioon ja riskiin. Se kuvaa teknisen dokumentaation viranomaisille ja erillisen tiedon jatkokäyttäjille, mukaan lukien ominaisuudet, rajoitukset ja integraatiotiedot. Yleiskäyttöisille tekoälymalleille, joihin liittyy systeeminen riski, 55 artikla edellyttää arviointia standardoituja protokollia ja huippuluokan työkaluja käyttäen, mukaan lukien dokumentoitu haitallisuustestaus systeemisten riskien tunnistamiseksi ja lieventämiseksi. Arviointi, joka ei kerro, mitä testattiin, missä olosuhteissa ja millä rajoituksilla, ei muutu hyödyllisemmäksi siksi, että sitä kutsutaan standardoiduksi.

Näytöllä on vanhentumisehto

Todisteet eivät vanhene siksi, että joku on päättänyt olla hankala. Ne vanhenevat, kun olosuhteet, joiden ansiosta ne pystyivät tukemaan väitettä, ovat muuttuneet niin paljon, ettei yhteyttä voida enää olettaa. Tämä on tavallista päättelyä. Sillan suunnittelun testi ei automaattisesti kata eri materiaalia. Elintarviketurvallisuustarkastus ei kata uutta toimittajaa pelkän optimismin voimalla. Tekoälyreitin arvioinnin ei pitäisi automaattisesti kattaa muuttunutta mallia, muuttunutta datarajaa, muuttunutta työkalun valtuutusta tai muuttuneita päätöksen seurauksia.

Vaikea työ on päättää, mitkä muutokset ovat merkityksellisiä. Tämä on teknistä harkintaa, riskianalyysiä ja hallintoa koskeva asia, ei yksittäinen prosenttiluku, joka on kirjoitettu käytäntöön. Korjaus, joka muuttaa painikkeen väriä, ei välttämättä vaikuta arviointiin. Muutos, joka tekee varoituksesta vähemmän näkyvän, voi olla olennainen, jos turvallisuusperustelu riippuu siitä, että arvioija näkee sen. Lähdekorpuksen indeksoinnin uusiminen voi olla harmitonta yhdelle tehtävälle ja kriittistä toiselle. Uusi mallipäätepiste voi säilyttää laajan toimintakyvyn ja samalla muuttaa viivettä, kieltäytymiskäyttäytymistä, kielikattavuutta tai työkalun käyttötapoja, joilla on merkitystä reitille.

Hyödyllinen muutoksenhallinta alkaa siksi vaikutuskysymyksestä, ei julkaisurituaalista. Mihin väitteeseen tämä muutos voisi vaikuttaa? Minkä oletuksen se häiritsee? Mitkä todisteet olivat ehdollisia vanhalle tilalle? Vastaako rajattu tarkistus kysymykseen, vai tarvitseeko reitti uuden arvioinnin ja julkaisupäätöksen? Kuka saa tehdä tämän päätöksen, ja kuka voi haastaa sen? Vastaukset tulisi kirjata, koska muuten seuraavan arvioijan on pääteltävä ne tikettien otsikoista, perimätiedosta ja pienestä muutoksesta julkaisunhallintanäkymän fontissa.

Tässä myös seurannasta tulee osa todisteita sen sijaan, että se olisi erillinen havainnoinnin harrastus. Artikla 72 edellyttää, että suuririskisten tekoälyjärjestelmien tarjoajat keräävät, dokumentoivat ja analysoivat aktiivisesti ja järjestelmällisesti asiaankuuluvaa suorituskykyä koskevaa dataa koko järjestelmän elinkaaren ajan, jotta ne voivat arvioida jatkuvaa vaatimustenmukaisuutta. Markkinoille saattamisen jälkeinen seurantasuunnitelma on osa teknistä dokumentaatiota. Seuranta ei siis ole pelkästään tapa tietää, onko palvelu kiireinen. Se on tapa oppia, pitävätkö alkuperäisen väitteen taustalla olevat olosuhteet edelleen paikkansa.

Seuranta ei tee jokaisesta tuloksesta itsestään selvää. Arvioijien ja järjestelmän välisten erimielisyyksien kasvulla voi olla monia syitä. Muutos lähteiden tuoreudessa voi kuvastaa dataputkiongelmaa mallin ajautumisen sijaan. Korkeampi kieltäytymisaste voi tarkoittaa turvallisempaa käytäntöä, rikkinäistä integraatiota tai uutta pyyntöpopulaatiota. Tallenteen tulisi säilyttää riittävästi kontekstia ihmisen tekemää tutkimusta varten. Mittarit ovat signaaleja. Ne eivät ole todistajia.

Todisteet ovat voimassa määritellyssä kontekstissa. Olennainen muutos luo kysymyksen arviointia varten, ei porsaanreikää arvioinnin ohi.

Olennainen muutos vaatii päätöspolun

Ilmaus material change käsitetään usein niin, että se nimeäisi itsestään selvän ominaisuuden. Näin ei ole. Material mihin nähden, väitteeseen, riskiin ja käyttäjään? Vastauksen on oltava riittävän täsmällinen, jotta sitä voi käyttää väsyneenä, myöhään ja innokkaana kutsumaan muutosta vähäiseksi. Hyvä politiikka ei lupaa luokitella etukäteen jokaista mahdollista päivitystä. Se nimeää tekijät, jotka ratkaisevat, tarvitaanko uudelleenarviointia.

Näihin tekijöihin kuuluvat yleensä käyttötarkoitus, vaikutuksen kohteena olevat henkilöt, reitille myönnetty toimivalta, tietolähteet ja niiden laadunvalvonta, malli- tai järjestelmäarkkitehtuuri, arvioinnin laajuus, päätöskynnykset, seurantasignaalit, ihmisen suorittama valvonta, tietoturvavalvonta ja palautumispolut. Muutos, joka vaikuttaa johonkin näistä, voi olla olennainen tai olla olematta. Ratkaisevaa on, voiko se muuttaa näyttöä, jota olemassa oleva väite edellyttää, tai kontrollien jälkeen jäljellä olevaa riskiä.

AI-asetus sisältää nimenomaisen vastuun, joka liittyy olennaiseen muutokseen. Sen täsmällinen oikeudellinen soveltaminen riippuu järjestelmästä ja toimijoista, joten sitä ei pidä tiivistää iskulauseeksi. Operatiivinen opetus on yksinkertaisempi ja laajempi: organisaation on tiedettävä, milloin muutos siirtää tai luo vastuuta, milloin olemassa oleva dokumentaatio ei enää riitä ja milloin järjestelmä on arvioitava uudelleen ennen kuin uutta käyttöä jatketaan. Se on vähemmän jännittävää kuin ominaisuuden julkaisu. Se myös tuottaa vähemmän todennäköisesti hankalan tilanteen, jossa kaikki ovat yhtä mieltä siitä, että järjestelmä on muuttunut, mutta kukaan ei omista päätöstä.

Päätöspolku antaa muutokselle paikan, johon se voi mennä. Yksi polku voi sallia dokumentoidun toteamuksen, jonka mukaan vaikutusta ei ole. Toinen voi edellyttää kohdennettua regressioarviointia. Kolmas voi edellyttää laajempaa riskikatsausta, käyttöohjeiden muutosta, tarkistettua seurantasuunnitelmaa tai uutta julkaisuhyväksyntää. Vakavin polku voi edellyttää, että reitti pidetään rajoitettuna tai keskeytettynä, kunnes näyttöä on saatavilla. Tarkoitus ei ole tehdä jokaisesta muokkauksesta kallista. Tarkoitus on tehdä tärkeästä muokkauksesta mahdotonta naamioida rutiininomaiseksi ylläpidoksi.

Tässä on tyydyttävä romantiikan puute. Muutostietue voi näyttää aiemman tilan, ehdotetun tilan, vaikutuksen kohteena olevat väitteet, tarkastellun näytön, päätöksen, toimivallan ja julkaisun jälkeiset ehdot. Se on hallintoa työvaatteissaan. Se ei koskaan näytä yhtä vaikuttavalta kuin mallin esittely. Sillä on hyödyllisempi ominaisuus: se auttaa organisaatiota selittämään itseään, kun esittelystä on tullut todellinen palvelu.

Arvioinnin on voitava epäonnistua julkisesti tai ainakin tiedostossa

Arvioinnista tulee performatiivista, kun jokaisen tuloksen oletetaan olevan julkaisutulos. Kypsän arviointiohjelman on voitava todeta, että näyttö on puutteellista, että kynnys alitettiin, että tunnettu rajoitus estää ehdotetun käytön tai että väitettä on rajattava. Nämä eivät ole noloja poikkeuksia prosessista. Ne ovat prosessin tuotoksia.

Tämä on erityisen tärkeää mukautuville tai ulkoisesti kytketyille järjestelmille. Tiimi voi havaita, että testisarja ei enää edusta elävää syötepopulaatiota. Työkalusopimus voi muuttua liian epävakaaksi tukemaan toistoväitettä. Mallipäivitys voi parantaa yhtä tehtävää mutta vaikeuttaa suojatun reitin valvontaa. Operatiivinen signaali voi osoittaa, että siirto järjestelmältä tarkastajalle epäonnistuu tavanomaisessa työkuormassa. Oikea vastaus ei välttämättä ole dramaattinen alasajo. Se voi olla rajoitus, tarkistettu työnkulku, lisätesti, uusi hyväksymisehto tai päätös olla esittämättä alkuperäistä väitettä.

Tallenteen on annettava arvioijan nähdä tuo negatiivinen tulos. Muuten organisaatio rakentaa erittäin tehokkaan koneen, joka kerää vain sellaista näyttöä, josta se pitää. Artiklan 17 laadunhallintavaatimukset ovat tässä olennaisia. Ne kattavat muun muassa suunnittelun, kehityksen ja laadunvalvonnan tekniikat ja menettelyt; tarkastuksen, testauksen ja validoinnin; tietojen hallinnan; riskienhallinnan; markkinoille saattamisen jälkeisen seurannan; vaaratilanteista ilmoittamisen; sekä yhteydenpidon viranomaisiin. Laadunhallintajärjestelmä ei ole kansio, joka saa epäonnistumiset katoamaan. Se on tapa havaita, dokumentoida ja käsitellä ne.

Sama periaate ohjaa pääsyä. Ulkopuolinen sääntelijä, ilmoitettu laitos tai valtuutettu arvioija voi tarvita teknistä näyttöä, jota ei voida julkaista avoimesti. Julkinen yhteenveto voi sopia muihin tallenteen osiin. Nämä ovat eri pääsyreittejä, eivät eri tosiasioita. Yleisölle ei pidä tarjota iloista kertomusta, kun valvottu tallenne kuvaa kapeamman ja ehdollisemman todellisuuden. Luottamuksellisuus voi olla perusteltua. Ristiriita on hallinnon epäonnistuminen.

Dwevellä julkinen Trust Centre tarjoaa pienen, tarkoituksella rajatun esimerkin tästä erottelusta. Sen arviointisivu kertoo, että arviointi yksilöi mallin, tarkan testisarjan, kokoonpanon, tallennetun tilan, näytön ja arvioijan päätöksen. Se kertoo myös, että toistetun tallennetun sopimuksen pitäisi tuottaa tavallisesti identtiset tulokset tuetuilla arkkitehtuureilla, kun taas reaaliaikainen uudelleenajo voi poiketa, jos ulkoinen näyttö tai mukautuva tila muuttuu. Sivu erottaa julkisen menetelmän täytetystä markkinointituloksesta. Se ei ole todiste mallin laadusta. Se on yksinkertaisesti oikean muotoinen väite arviointitallenteista.

Reaaliaikainen seuranta ei korvaa julkaisua edeltävää päätöstä

Seurantaa kuvataan joskus vastaukseksi epävarmuuteen: julkaise järjestelmä, seuraa kojelautaa, paranna jatkuvasti. Tuossa lauseessa on hyödyllinen vaisto. Järjestelmiä on tarkkailtava julkaisun jälkeen, koska käyttöönotto tuottaa tietoa, jota laboratorio ei voi. Mutta seuranta ei voi jälkikäteen tukea päätöstä, jonka näyttö ei ollut koskaan riittävää. Se ei voi kertoa henkilölle, jota virheellinen korkean seurauksen toimi koskee, että organisaatio oppii ensi kuussa kuvaajasta.

Julkaisua edeltävä arviointi ja julkaisun jälkeinen seuranta vastaavat eri kysymyksiin. Arviointi kysyy, onko organisaatiolla riittävästi näyttöä määritellyn käytön sallimiseen nyt. Seuranta kysyy, pitävätkö luvan taustalla olevat ehdot edelleen paikkansa ja ilmaantuuko uusia riskejä tai epäonnistumisia. Ensimmäinen asettaa aloitusrajan. Toinen tarkkailee rajaa toiminnassa. Uskottava järjestelmä tarvitsee molemmat sekä reitin, jolla data ja toiminnallinen oppiminen palaavat riskinarviointiin, dokumentointiin ja muutostenhallintaan.

Tämä silmukka muuttaa staattisen vakuutuspaketin eläväksi tallenteeksi. Arviointi antaa lähtötason. Käyttöönottotallenne kertoo, mikä lähtötaso otettiin käyttöön. Lokitus ja seuranta osoittavat asiaankuuluvaa käyttäytymistä. Muutos voi muuttaa lähtötasoa tai paljastaa sen rajat. Tarkastelu päivittää sitten väitteen, sen näytön, sen rajoitteet tai sen tilan. Järjestelmä liikkuu. Tallenne liikkuu sen mukana, mutta ei kirjoita omaa menneisyyttään uusiksi. Tilintarkastaja näkee sekä nykyisen tilanteen että polun, jota pitkin siihen on päädytty.

Suuren riskin järjestelmissä tekoälysäädös edellyttää nimenomaisesti, että markkinoille saattamisen jälkeisen seurannan on kerättävä ja analysoitava asiaankuuluvaa suorituskykytietoa koko elinkaaren ajan ja mahdollistettava jatkuvan vaatimustenmukaisuuden arviointi. Se edellyttää myös, että käyttöönottajat seuraavat toimintaa käyttöohjeiden mukaisesti ja ilmoittavat toimittajalle ja asianomaiselle viranomaiselle ilman aiheetonta viivytystä, jos niillä on syytä katsoa, että käyttö voi aiheuttaa riskin. Nämä vaatimukset eivät poista ammatillisen harkinnan tarvetta. Ne antavat ammatilliselle harkinnalle tallenteet, laukaisimet ja reitit.

Organisaatioita houkuttaa usein ajatella, että monitorointi kuuluu operatiiviselle tiimille ja arviointi mallitiimille. Tämä jako kaatuu ensimmäiseen merkitykselliseen kysymykseen tuotantoreitistä. Malliasiantuntija voi tietää, miksi testi valittiin. Operaattori voi tietää, että lähteet olivat vanhentuneita. Policy-omistaja voi tietää, että päätössääntö muuttui. Arvioija voi tietää, että käyttöliittymä aiheuttaa automaatioharhaa. Audit trailin tulisi yhdistää heidän todisteensa teeskentelemättä, että yksi henkilö näkee koko järjestelmän.

Voiko sääntelijä toistaa päätöksen?

Joskus vastauksen tulisi olla kyllä, määritellyssä laajuudessa. Jos organisaatio väittää, että päätös tai arviointi voidaan toistaa, sen on määriteltävä, mitä toistaminen tarkoittaa. Tarkoittaako se mallikutsun toistamista samalla kehotteella? Tarkoittaako se koko hakujen ja työkalujen sekvenssin uudelleenrakentamista? Tarkoittaako se sen tallenteen rekonstruoimista, jonka arvioija näki? Tarkoittaako se deterministisen laskennan vahvistamista säilytetyistä syötteistä? Jokainen näistä on hyödyllinen. Jokaisella on erilaiset tekniset ja juridiset edellytykset.

Merkityksellinen toisto alkaa säilytetystä identiteetistä. Arvioijan on tiedettävä, mikä järjestelmäversio ja -konfiguraatio olivat voimassa, mitkä syötteet ja lähdeversiot olivat hyväksyttäviä, mitkä policyt ja käyttöoikeudet olivat voimassa, mitkä ulkoiset riippuvuudet vastasivat ja mitkä ihmisen toimet muuttivat polkua. Jotkin elementit on ehkä tallennettava suoraan. Toisiin voidaan viitata pysyvillä tunnisteilla ja rekonstruoida hallittujen järjestelmien kautta. Ei ole hyväksyttävää kutsua harjoitusta toistettavaksi, jos se riippuu live-verkkohausta, ylikirjoitetusta tietokantarivistä ja insinöörin kannettavalta muistetusta asetuksesta.

Silloinkin toisto voi toistaa tallenteen pikemminkin kuin maailman. Live-lähde voi päivittyä tai poistua. Kolmannen osapuolen palvelu voi muuttua. Mukautuva palvelu voi kerryttää uutta hallittua tilaa. Ihminen voi tehdä erilaisen päätöksen samojen tietojen perusteella. Nämä eivät ole toiston idean vikoja. Ne ovat eroja, jotka tallenteen on säilytettävä. Toisto voi näyttää, mitä järjestelmä teki tallennetun sopimuksen puitteissa. Se ei väitä, että nykyinen maailma on identtinen tuon sopimuksen kanssa.

Siksi ihmisen päätöstallenteet kuuluvat teknisten tallenteiden rinnalle, kun ihmisen valvonta on osa turvallisuus- tai oikeusperustetta. Auditointi voi edellyttää tietoa siitä, että ihminen arvioi suosituksen, mitä tietoja hänellä oli käytettävissään, mitä hän valitsi ja mikä toimivalta hänellä oli. Sen ei tarvitse tehdä jokaisesta arvioijasta valvonnan kohdetta tai säilyttää rajoittamatonta henkilökohtaista materiaalia. Sen on kuitenkin kerättävä riittävästi tietoa sen osoittamiseksi, että luvattu valvonta toteutui kyseisessä tapahtumassa.

Toistettavuus on siis tikapuut, ei ylvästely. Yhdellä askelmalla arvioija voi tunnistaa julkaisun. Seuraavalla hän voi tarkastella todisteita. Ylempänä hän voi luoda testin uudelleen tai analysoida live-päätöspolkua. Organisaation tulisi kertoa, millä askelmalla se toimii, missä rajat ovat ja mitkä osat edellyttävät valtuutettua pääsyä. Vaatimaton, testattava toistoväite on paljon vahvempi kuin epämääräinen vakuutus siitä, että kaikki on jäljitettävissä.

Auditoinnit tarvitsevat tallenteita, jotka ovat eri mieltä keskenään

Organisaation julkinen statustallenne, sisäinen julkaisutallenne, arviointiraportti, operatiiviset lokit ja poikkeamarekisteri eivät saa kertoa eri asioita samasta perustilasta. Mutta niiden ei tulisi olla identtisiä asiakirjojakaan. Jokaisella on eri yleisö ja tarkoitus. Julkinen tallenne voi kertoa aiottuun käyttötarkoitukseen, tilaan, tunnettuihin rajoituksiin ja reitin lisätietoihin. Tekninen tiedosto voi sisältää yksityiskohtaisen arkkitehtuurin, tiedot, testit ja kontrollit. Operatiivinen tallenne voi sisältää tapahtumatason jäljitettävyyden. Muutostiedosto voi selittää, miksi aiempi johtopäätös otettiin uudelleen tarkasteluun.

Eheys syntyy vastaavuudesta. Jos julkinen sivu sanoo, että reitti on rajoitettu suositukseen, tekniset ja toiminnalliset tietueet eivät saa kuvata automaattista toimintaa. Jos arviointi koskee rajattua lähdejoukkoa, julkaisutietue ei saa hiljaisesti soveltaa sitä myöhempään joukkoon. Jos muutostietue sanoo, että mallipäivitys oli merkityksetön, vaikutusarvion on kerrottava, mitä väitettä ja näyttöä se koskee. Jos valvontasignaali nostaa asian tarkasteluun, sitä seuraavan päätöksen on oltava jäljitettävissä. Asiakirjat voivat erota tarkkuudessa. Ne eivät saa olla eri mieltä todellisuudesta.

Tämä vastaavuus on hyödyllistä sääntelijöille, koska se vähentää tarvetta luottaa yhteen kiillotettuun tuotokseen. Tarkastaja voi verrata tietueita. Se on hyödyllistä organisaatioille, koska se paljastaa eroavaisuuksia tiimien välillä ennen kuin ulkoinen auditointi tekee sen. Ja se on hyödyllistä asianomaisille, koska julkinen selitys voi muodostua todelliseksi tilivelvollisuuden väyläksi sen sijaan, että se olisi koristeellinen kerros erillisen yksityisen järjestelmän päällä.

Arkkitehtuurin ei tarvitse olla monimutkainen. Pieni organisaatio voi käyttää hallittua rekisteriä, versioituja asiakirjoja, allekirjoitettuja vientitiedostoja ja kurinalaisia muutostarkastuksia. Suurempi organisaatio voi käyttää jäsenneltyjä manifesteja, append-only-lokeja, politiikkamoottoreita ja automatisoitua todisteiden keruuta. Tärkeä kysymys on, pystyykö menetelmä luotettavasti yhdistämään väitteen, tilan, todisteet, päätöksen ja myöhemmän muutoksen. Valtava työkalujärjestelmä, joka menettää tämän suhteen, on vain kalliimpi tapa olla epämääräinen.

Erityisen eurooppalainen hyve on tehdä tietueesta tarkasteltava tekemättä siitä teatraalista. Kaikki vastaukset eivät kuulu julkiselle kojelaudalle. Kaikki dokumentoitu epävarmuus ei tarvitse iloista kuvaketta. Mutta kun organisaatio on tehnyt merkittävän väitteen mukautuvasta järjestelmästä, sen pitäisi pystyä osoittamaan sääntelijälle, missä väite sijaitsee, mihin tilaan se viittasi ja miten organisaatio tietäisi, että väite on vanhentunut.

Auditointikysymys muuttaa suunnittelukysymyksen

Kysy varhain, voisiko sääntelijä auditoida järjestelmän sellaisena kuin se todella toimii. Vastaus muuttaa suunnitteluratkaisuja jo kauan ennen virallisen auditoinnin alkua. Se suosii vakaita tunnisteita epämääräisten nimikkeiden sijaan. Se suosii eksplisiittisiä politiikkaversioita proosaan upotettujen sääntöjen sijaan. Se suosii työkalujen rajapintoja, jotka voidaan tallentaa ja testata. Se suosii lähdeperäisyyden ja tuoreuden merkkejä. Se suosii selkeää rajaa suosituksen ja toiminnan välillä. Se suosii tarkastelunäkymiä, jotka säilyttävät tarkastajan tarvitsemat tiedot. Se suosii pysäytys- ja palautusmekanismeja, joilla on nimetty toimivalta.

Se muuttaa myös hankintaa. Toimittajan lausunto siitä, että mallia parannetaan säännöllisesti, ei riitä, kun käyttöönotto riippuu määritellystä arvioidusta tilasta. Ostajan on tiedettävä, miten muutoksista ilmoitetaan, mitkä tuotokset voidaan tunnistaa, mitä tietoja on saatavilla vaikutusarviointia varten, pysyvätkö historialliset tietueet tulkittavina ja miten reitti voidaan rajoittaa tai pysäyttää. Nämä eivät ole eksoottisia vaatimuksia. Ne ovat käytännön ehtoja, joilla organisaatio pysyy vastuullisena järjestelmästä, joka sisältää toimittajan komponentin.

Sama kysymys muuttaa arvioinnin suunnittelua. Hyödyllisellä arviointikokonaisuudella on identiteetti ja perustelu. Sen syötteet tai viittaukset ovat hallittuja. Sen mittarit ja kynnysarvot määritellään ennen tuloksen lukemista. Sen poissulkemiset ovat näkyvissä. Sen tulokset liittyvät siihen järjestelmän tilaan, jota todella käsitellään. Sen epäonnistumisilla on reitti päätökseen. Sen uudelleenajon ehdot ovat selkeät. Arviointi, jolla on nämä ominaisuudet, voidaan haastaa. Se on ominaisuus, ei valitettava sivutuote perusteellisuudesta.

Ennen kaikkea kysymys muuttaa muutoksen roolin. Muutos lakkaa olemasta häpeä, jonka dokumentaatio yrittää piilottaa. Siitä tulee ensiluokkainen tapahtuma järjestelmän todisteiden mallissa. Jotkin muutokset vaativat tuskin muuta kuin merkinnän. Jotkin käynnistävät testin. Jotkin avaavat julkaisupäätöksen uudelleen. Kurinalainen organisaatio ei sekoita näitä luokkia keskenään, eikä sen tarvitse odottaa tulevaa tapausta huomatakseen, että ne olivat olemassa.

Joten kyllä: sääntelijä voi tarkastaa liikkuvaa kohdetta. Tarkastus alkaa kieltäytymällä väärästä valinnasta jäädytetyn mallikortin ja täysin tuntemattoman reaaliaikaisen palvelun välillä. Tallenna tila. Esitä väite. Säilytä ehdot. Yhdistä todisteet päätökseen. Kirjaa, mikä muuttuu. Arvioi uudelleen, kun yhteys ei enää pidä. Kohde voi liikkua. Jäljen on pysyttävä luettavana.

Lähteet