EU:n tekoälyasetuksen hiljainen työ: asiakirjoja, ei iskulauseita

EU:n tekoälyasetuksen vaikein osa ei ole periaatteiden toistaminen, vaan riskien, dokumentoinnin, lokituksen, ihmisen valvonnan ja korjausten muuttaminen...

EU:n tekoälyasetuksen hiljainen työ: asiakirjoja, ei iskulauseita

Päätöksen jälkeen saapuva tallenne

Automaattisen suosituksen hyväksymisen jälkeen on hetki, jolloin huoneen muoto muuttuu. Näyttö näyttää edelleen tuloksen. Keskustelu on siirtynyt siihen, mitä tapahtuu seuraavaksi. Joku kysyy, mikä järjestelmän versio tuotti tuloksen, mitä tietoja oli tuolloin saatavilla, olisiko käyttäjä voinut hylätä sen ja mikä sääntö teki reitistä sallitun. Nämä kysymykset eivät ole dramaattinen hyökkäys teknologiaa vastaan. Ne ovat tavallisia kysymyksiä, joita instituutiot esittävät, kun toiminta saa seurauksen.

Kuvittele yhdistelmätapaus, jossa ei tarkoituksella mainita nimettyä organisaatiota, järjestelmää tai tapausta. Julkinen elin käyttää suuren riskin tekoälyjärjestelmää avustamaan päätöksessä, joka vaikuttaa henkilöön. Koulutettu henkilökunnan jäsen vastaa edelleen päätöksestä. Malli antaa tuloksen, henkilökunnan jäsen tarkistaa sen ja päätös tehdään. Myöhemmin esihenkilön on ymmärrettävä polku. Tulos itsessään on olemassa. Päätös on olemassa. Niiden välinen ketju ei ole. Ei ole selkeää tallennetta voimassa olleista ohjeista, käytetystä syötteestä, käyttöönotetusta versiosta, saatavilla olleesta interventiosta tai syystä, jonka vuoksi ihminen hyväksyi tuloksen. Mikään tässä kuvauksessa ei edellytä näyttävää toimintahäiriötä. Puuttuva tallenne riittää muuttamaan tarkastelun rekonstruointiharjoitukseksi.

Euroopan unionin tekoälysäädöstä käsitellään usein kieltojen, luokkien ja seuraamusten luettelona. Nämä osat ovat tärkeitä, mutta ne eivät ole koko työ. Säädös kuvaa myös hiljaisemman todisteiden infrastruktuurin: dokumentoidun ja ylläpidetyn riskienhallinnan, datakäytännöt, joilla on alkuperä ja tarkoitus, arvioitavissa olevan teknisen dokumentaation, olennaiset tapahtumat tallentavat lokit, ohjeet, jotka kertovat käyttöönottajalle, miten järjestelmää tulkitaan, inhimillisen valvonnan, jolla on todellista toimivaltaa, ja tallenteet, jotka pysyvät saatavilla, kun kysymys tulee myöhemmin. Laki pyytää instituutiota muistamaan tarkoituksella.

Tämä on vähemmän elokuvallinen tehtävä kuin mallin julkaiseminen. Se on myös se paikka, jossa vastuullisuus muuttuu todelliseksi. Iskulause voi todeta, että organisaatio ottaa vastuun. Tallenne voi osoittaa, miltä vastuu näytti tiettynä ajankohtana. Se voi osoittaa rajan, epävarmuuden, hyväksynnän, kieltäytymisen, korjauksen tai puutteen. Se ei voi tehdä lainvastaista päätöstä lailliseksi olemalla olemassa jälkikäteen, eikä se voi yksinään korjata henkilön menetystä. Se voi tehdä polusta riittävän tarkasteltavan korjausta, oikaisua ja parempaa päätöstä seuraavasta versiosta varten.

Tämä artikkeli käsittelee tuota hiljaista työtä. Se lukee tekoälysäädöksen tallentamis- ja dokumentointivelvoitteet toimintavaatimuksina eikä julkaisuun liitettynä paperityönä. Se kysyy, mitä tallenteet voivat osoittaa, mitä ne eivät voi osoittaa, miten tallenne saa merkityksen kontekstista, miksi täydellisyys ei ole sama asia kuin määrä ja miten organisaatio voi rakentaa rutiinin, joka jättää todisteita muuttamatta jokaista ihmisten välistä vuorovaikutusta pysyväksi valvontakohteeksi. Esimerkit, joita ei ole otettu suoraan mainitusta lähteestä, on merkitty ehdotetuiksi, hypoteettisiksi tai yhdistelmäesimerkeiksi. Tarinan lopussa ei odota keksittyä tapausta. Tarkoitus on välttää sellaisen tarvetta.

Asetuksen velvoitteet eivät ole erillisiä hyllyjä. Ne muodostavat reitin tarkoituksesta ja riskistä näyttöön, valvontaan ja oikeussuojakeinoihin.

Miksi huomaamaton työ on tärkeää

Tallenteita on helppo ymmärtää väärin, koska niitä on lähes jokaisessa organisaatiossa. Tietokantarivi, tiketti, muutospyyntö, allekirjoitettu päätös, aikaleima ja lokirivi näyttävät kaikki tallenteilta. Niiden olemassaolo yksinään kertoo hyvin vähän. Tallenteesta tulee hyödyllinen, kun se vastaa määriteltyyn kysymykseen riittävällä kontekstilla erottaakseen sen, mitä tapahtui, siitä, mitä joku nyt uskoo tapahtuneen. Tämä erottelu on erityisen tärkeä tekoälyssä, koska näkyvä tulos usein peittää alleen sen, kuinka monta muunnosta sitä edelsi.

Tavanomainen ohjelmistojärjestelmä voi jättää jäljen, joka on sen käyttäjille tuttu. Pyyntö saapuu, palvelu validoi kentät, sääntö suoritetaan, tila muuttuu ja vastaus lähtee. Tekoälyjärjestelmät voivat lisätä pääteltyjä luokkia, haettua kontekstia, luonnollisen kielen ohjeita, todennäköisyyksiin perustuvia tulosteita, työkalujen kutsuja, ihmisen muokkauksia ja mukautuvaa tilaa. Lisäjoustavuus voi olla hyödyllistä. Se myös luo enemmän mahdollisuuksia sille, että tosiasia menettää alkuperänsä tai että ohjeesta tulee auktoritatiivinen ilman, että sitä tunnistetaan sellaiseksi. Tallenteen on säilytettävä ne erottelut, jotka käyttöliittymä mielellään häivyttää.

Tekoälyasetus ei edellytä, että organisaatio säilyttää jokaisen tavun, joka on koskaan kulkenut mallin läpi. Sen vaatimukset liittyvät tarkoitukseen, riskiin, jäljitettävyyteen, elinkaareen ja hallintaan. Tämä on hyödyllinen lähtökohta. Se sanoo, että näytön on oltava oikeassa suhteessa aiottuun tarkoitukseen ja riskeihin, mutta silti riittävän perusteellinen kyseisen velvoitteen kannalta. Vähäriskisen luonnosluonnoksen tallennetta ei pitäisi käsitellä kuin se olisi täydellinen asiakirja perusoikeuksiin vaikuttavasta päätöksestä. Toisaalta tärkeää päätöstä ei voida tehdä vastuulliseksi tallentamalla vain yksi lopullinen lause ja vihreä valintamerkki.

Huomaamaton työ alkaa siis ennen kuin järjestelmä otetaan käyttöön. Jonkun on määriteltävä, mihin järjestelmä on tarkoitettu, missä sitä ei ole tarkoitus käyttää, ketkä ihmiset ja mitkä ympäristöt kuuluvat soveltamisalaan, mitä syötettä se voi vastaanottaa, kuka voi toimia tuloksen perusteella ja mitä tapahtuu, kun järjestelmä on epävarma tai käytettävissä. Nämä eivät ole vain suunnittelukysymyksiä. Ne ovat ehtoja, jotka antavat myöhemmille tallenteille merkityksen. Ilman niitä aikaleima kertoo, milloin jotain tapahtui, mutta ei sitä, oliko se sallittua, odotettua vai poikkeus.

On olemassa institutionaalinen syy ottaa tämä vakavasti. Henkilö, joka pyytää näyttöä, ei useinkaan ole se, joka rakensi järjestelmän. Toimivaltainen viranomainen, sisäinen arvioija, asianomainen henkilö tai seuraava tiimi voi kohdata tallenteen sen jälkeen, kun henkilöstö, toimittajat ja mallit ovat vaihtuneet. Näyttö, joka on ymmärrettävää vain sen alkuperäiselle tekijälle, on hauras vastuullisuuden muoto. Asetuksen vaatimus selkeästä dokumentaatiosta, ymmärrettävistä ohjeista ja viranomaisten pääsystä on vastaus tähän haurauteen. Se kohtelee jatkuvuutta osana vaatimustenmukaisuutta.

Lue asetus kokonaisuutena, ei iskulauseena

Asetuksen korkean riskin vaatimukset voidaan lukea kysymysten sarjana. Mitä järjestelmän on tarkoitus tehdä. Mitä riskejä se voi aiheuttaa tässä yhteydessä. Mitkä tiedot ja oletukset tukevat sitä. Miten järjestelmä rakennettiin ja testattiin. Mitä käyttöönottajan on tiedettävä. Mitkä tapahtumat on kirjattava. Kuka voi valvoa, ohittaa tai pysäyttää sen. Mitä tapahtuu, kun järjestelmä ei ole vaatimustenmukainen tai aiheuttaa riskin. Sarja ei ole siisti ohjelmistoputki. Se on vastuuketju, joka palaa takaisin, kun näyttö muuttuu.

10 artiklassa riskienhallinta kuvataan jatkuvana, toistuvana prosessina, joka suunnitellaan ja toteutetaan koko korkean riskin tekoälyjärjestelmän elinkaaren ajan. Se on perustettava, pantava täytäntöön, dokumentoitava ja pidettävä yllä. Tällä sanamuodolla on käytännön seuraus. Riskinarviointi ei ole seremoniallinen asiakirja, joka jää eläkkeelle julkaisupäivänä. Se on elävän prosessin tallenne, joka tunnistaa ja arvioi tunnetut ja kohtuudella ennakoitavissa olevat riskit, ottaa huomioon markkinoille saattamisen jälkeisestä seurannasta saadut tiedot ja toteuttaa kohdennettuja toimenpiteitä. Tallenteen pitäisi antaa myöhemmälle lukijalle mahdollisuus nähdä, mitä on otettu huomioon, mitä ei ole voitu poistaa, mikä on jäänyt jäännösriskiksi ja kuka on hyväksynyt tämän aseman.

10 artikla asettaa tiedot ja tietohallinnon saman kurinalaisuuden piiriin. Asiaankuuluvia käytäntöjä ovat suunnitteluvalinnat, tietojen alkuperä, valmistelutoimet, oletukset siitä, mitä tiedot edustavat, saatavuus ja soveltuvuus, mahdollinen harha, tietoaukot ja toimenpiteet, joilla niihin puututaan. Tämä on erilainen ajatus kuin se, että aineisto oli puhdas. Puhdas on johtopäätös. Alkuperä, valmistelu, oletukset ja aukot ovat näyttöä siitä, miten johtopäätökseen päädyttiin ja missä se voi lakata olemasta luotettava. Tallenne, joka säilyttää vain laatuleiman, on unohtanut kysymykset, jotka tekivät laadusta merkityksellistä.

11 artikla edellyttää teknisen dokumentaation laatimista korkean riskin tekoälyjärjestelmästä ennen sen saattamista markkinoille tai käyttöönottoa ja edellyttää, että dokumentaatio pidetään ajan tasalla. Sen on tarkoitus antaa kansallisille toimivaltaisille viranomaisille ja ilmoitetuille laitoksille tiedot, joita ne tarvitsevat vaatimustenmukaisuuden arvioimiseksi. Tärkeä seikka ei ole se, että jokaisesta lukijasta tulisi liitteen asiantuntija. Se on se, että järjestelmällä on oltava selvitys itsestään, joka on riittävän selkeä ja kattava ulkoista arviointia varten. Tällä selvityksellä on oltava versio, tarkoitus ja suhde aikaisempiin versioihin. Asiakirja, joka kuvaa järjestelmää, jota ei enää ole olemassa, on arkisto, ei ajantasaista näyttöä.

12 artikla tekee sitten järjestelmän toiminnasta itsestään osan näyttöä. Korkean riskin tekoälyjärjestelmien on teknisesti mahdollistettava tapahtumien automaattinen kirjaaminen koko niiden elinkaaren ajan. Lokitusominaisuuksilla on kirjattava tapahtumat, jotka ovat merkityksellisiä sellaisten tilanteiden tunnistamiseksi, jotka voivat aiheuttaa riskin tai olennaisen muutoksen, helpottaen markkinoille saattamisen jälkeistä seurantaa ja toiminnan seurantaa käyttöönottajan velvollisuuksien mukaisesti. Vaadittu jäljitettävyyden taso liittyy aiottuun käyttötarkoitukseen. Laki ei pyydä lokia olemaan ihmiselämän päiväkirja. Se pyytää järjestelmää jättämään riittävästi toiminnallista muistia asiaankuuluvia kysymyksiä varten.

Articles 13 and 14 connect that memory to people. A high-risk system must be transparent enough for deployers to interpret its output and use it appropriately, and it must be accompanied by instructions for use. Human oversight must be effective and proportionate to risk, autonomy and context. The people assigned to oversight must be able to understand capacities and limitations, notice anomalies and unexpected performance, avoid over-reliance, interpret outputs, disregard or override them and, where appropriate, interrupt the system safely. These capabilities cannot live only in a training slide. A serious record should make it possible to tell what the human could know and do at the moment of the decision.

Articles 15 through 21 complete the arc from performance to remedy. Accuracy, robustness and cybersecurity are lifecycle properties. Providers must maintain a quality management system that is documented in an orderly manner and includes data procedures, risk management, post-market monitoring, incident reporting, communications, record-keeping and an accountability framework. Documentation and logs have to remain available for the periods and purposes the Regulation specifies. Corrective action and cooperation with competent authorities are duties, not optional public relations. The result is not a slogan about trustworthy AI. It is a set of artefacts that let an institution demonstrate, investigate, correct and explain.

Three things a record can do

First, a record can establish an event. It can show that a system was invoked, that a particular version was active, that an input was received, that a tool call was proposed, that a human approval was registered, that an action was completed or that a system was stopped. Event evidence is the layer most people imagine when they hear the word log. It matters because a disputed action cannot be investigated if the organisation cannot tell whether the action occurred. It is also the least complete layer if it stands alone.

An event record needs a stable identity, a time reference, an actor or accountable role, a system or component identity and enough state to avoid ambiguity. The exact fields depend on purpose and law. A timestamp without a time basis can be confusing across systems. A user identifier without a role says little about authority. A model name without a version cannot establish which behaviour was in scope. A record can be technically authentic and still be institutionally thin.

Second, a record can establish a basis. It can show which purpose, rule, instruction, data source, policy version or assessment supported an action. Basis evidence is what prevents a decision from becoming a free-floating output. It does not have to reproduce every internal computation. It does have to identify the conditions that made the output meaningful and the boundaries that limited what a person was allowed to do with it. When the basis is missing, an organisation may know what it did without knowing why it was entitled to do it.

Third, a record can establish a response. It can show that an anomaly was noticed, that an operator rejected an output, that a risk was escalated, that a system was suspended, that a correction was applied or that a complaint was received and routed. Response evidence is often overlooked because teams focus on the model’s first output. In practice, accountability lives in what happens after uncertainty becomes visible. A system that can produce a record of a problem but has no record of the response has built a sensor without a brake.

Nämä kolme toimintoa ovat päällekkäisiä, mutta niitä ei pidä yhdistää. Lähdeviittaus voi luoda perustan osoittamatta, että lähdettä on todella käytetty ajossa. Ihmisen hyväksyntä voi luoda vastauksen osoittamatta, että arvioija näki täyden asiayhteyden. Malliversio voi luoda identiteetin osoittamatta, että versio toimi johdonmukaisesti. Hyvät tallenteet tekevät niistä väitteistä, joita ne voivat tukea, yksiselitteisiä. Ne eivät lainaa auktoriteettia naapuritallenteilta ja kutsu järjestelyä ketjuksi.

Täydellisyys ei ole tavumäärä. Se on kyky vastata niihin kysymyksiin, jotka järjestelmän tarkoitus ja seuraukset synnyttävät.

Mitä tallenne ei voi tehdä

Tallenne ei voi muuttaa kiellettyä käytäntöä sallituksi. Jos käyttö itsessään on lain ulkopuolella, täydellinen lokitus ei ole puolustus. Todisteet voivat paljastaa väärän päätöksen, mutta ne eivät voi jälkikäteen myöntää auktoriteettia, jota ei koskaan ollut. Siksi dokumentaatiota ei pidä koskaan esittää korvikkeena oikeudelliselle analyysille, perusoikeusarvioinnille tai selkeälle tarkoitukselle. Kauniisti indeksoitu rikkomus on silti rikos. Indeksi vain helpottaa sen löytämistä.

Tallenne ei voi todistaa, että päätös oli oikeudenmukainen pelkästään siksi, että kentät on täytetty. Oikeudenmukaisuus ei ole ominaisuus, joka ilmestyy, kun lomake saavuttaa sataprosenttisen täyttöasteen. Olennainen kysymys on, kohteliko järjestelmä, data, työnkulku ja inhimillinen harkinta ihmisiä tavalla, joka kunnioittaa sovellettavia oikeuksia ja velvollisuuksia. Tallenne voi säilyttää todisteita tästä kysymyksestä. Se voi näyttää, mitä tietoa käytettiin, mitä sääntöä sovellettiin, mitä poikkeuksia harkittiin ja miten valitus käsiteltiin. Se ei voi yksin ratkaista moraalista ja oikeudellista kysymystä.

Tallenne ei voi tehdä heikosta selityksestä merkityksellistä lisäämällä teknisiä yksityiskohtia. Päätöksen kohteena oleva henkilö voi tarvita selkeän kuvauksen siitä, mikä rooli tekoälyllä oli ja mitkä olivat päätöksen pääelementit. Sisäisten tunnisteiden, raakojen token-jälkien tai ruudullisen koneen telemetrian kaataminen tämän henkilön päälle ei automaattisesti ole läpinäkyvyyttä. Todisteiden muodon on vastattava kysymystä ja yleisöä. Auktoriteetti tarvitsee arvioitavaa dokumentaatiota. Käyttäjät tarvitsevat käyttökelpoisia ohjeita. Päätöksen kohteena olevat ihmiset tarvitsevat ymmärrettävän reitin ymmärtää ja haastaa.

Mikään tallenne ei voi säilyttää tulevaisuutta. Se on näkymä tietystä ajankohdasta, joka on tehty silloin vallinneiden tietojen ja järjestelmän tilan perusteella. Tämä rajoitus ei ole vika. Se on syy tallentaa versiot, voimassaoloajat ja epävarmuus. Jos käytäntö muuttui päätöksen jälkeen, tallenteen ei pitäisi hiljaa näyttää uutta käytäntöä ikään kuin se olisi ohjannut vanhaa toimintaa. Jos lähdettä korjattiin, aiemman syötteen pitäisi pysyä tunnistettavissa samalla kun korjaus ja sen vaikutus tallennetaan. Aika on osa merkitystä, ei koriste kojelaudan oikeassa reunassa.

Mikään tallenne ei voi kertoa organisaatiolle sitä, mitä se ei tallentanut. Tämä kuulostaa itsestään selvältä, mutta se on tärkeä raja aikakaudella, jolloin selityksiä tuotetaan koneellisesti. Mallilta voidaan pyytää kertomaan menneestä päätöksestä. Tuloksena syntyvä teksti voi olla hyödyllinen hypoteesina tai yhteenvetona. Ellei se perustu säilytettyyn näyttöön, se ei ole aikakone. Turvallisempi käytäntö on merkitä rekonstruktio rekonstruktioksi, tunnistaa puuttuva näyttö ja välttää uskottavan selityksen esittämistä havaittuna. Rehellinen epätäydellisyys on hyödyllisempää kuin täydellinen fiktio.

Lokit ovat näyttöä, eivät moraalinen alibi

Lokitus on houkuttelevaa, koska se tuntuu objektiiviselta. Rivi aikaleimoineen ja järjestelmätunnisteineen näyttää neutraalimmalta kuin ihmisen kirjoittama merkintä. Se ei ole neutraali. Joku päätti, mitä tallennetaan, mitä jätetään pois, mitkä kentät säilytetään, miten niitä suojataan, miten aika synkronoidaan ja kuka voi tarkastella tulosta. Lokitus on tekninen valinta, jolla on oikeudellisia ja inhimillisiä seurauksia. EU:n tekoälyasetuksen kirjanpitovelvoitteet tekevät tästä valinnasta näkyvän, mutta ne eivät poista tarvetta suunnitella sitä huolellisesti.

Ensimmäinen suunnittelukysymys on tarkoitus. 12 artikla nimeää jäljitettävyyden, riskien tunnistamisen, markkinoille tulon jälkeisen seurannan ja toiminnan seurannan syiksi tallentaa olennaiset tapahtumat. Kukin syy voi edellyttää erilaista näkymää. Käyttäjä voi tarvita tiiviin selityksen kieltäytymisestä ja reitin esihenkilölle. Turvallisuusasiantuntija voi tarvita versio- ja syötehistorian. Toimivaltainen viranomainen voi tarvita dokumentaatiota ja lokit, jotka riittävät vaatimustenmukaisuuden arviointiin. Tietosuojavastaava voi tarvita tiedon siitä, mitä henkilötietoja loki sisältää ja miksi niitä säilytetään. Yksi erittelemätön virta voi olla yhtä aikaa liian meluisa ihmiselle ja liian heikko tutkintaa varten.

Toinen kysymys on laajuus. Hyödyllinen loki tallentaa tapahtumat, joilla on merkitystä käyttötarkoituksen ja riskin kannalta, ei jokaista satunnaista elettä. Järjestelmässä, joka vain luonnostelee sisäistä tekstiä, olennainen tapahtuma voi olla kutsu, lähdejoukko, mallin versio, ohjeiden versio, ihmisen hyväksyntä ja lopullinen käsittely. Järjestelmässä, joka voi muuttaa ulkoista tallennetta, tilasiirtymät ja työkalujen kuittaukset tulevat olennaisiksi. Järjestelmässä, joka tukee vaikutuksiltaan merkittävää päätöstä, syötteen laajuus, tulos, ihmisen tarkistus ja korjausreitti ovat tärkeämpiä kuin koristeellinen token-laskuri. Tallenteen tulee seurata seurauksia.

Kolmas kysymys on eheys. Tallenne, jota voi muokata huomaamatta, voi silti olla hyödyllinen operatiivisesti, mutta se antaa heikomman kuvan historiasta. Eheyden suojauksia voivat olla käyttöoikeusrajoitukset, lisäysvain-tallennus, tarkistussummat, allekirjoitukset, riippumattomat aikaviitteet, hallitut korjaukset ja dokumentoitu säilytys. Sopiva mekanismi riippuu riskistä. Tärkeää on kertoa, mitä mekanismi suojaa ja mitä se ei suojaa. Manipuloinnin jäljet voivat osoittaa, että tallenne muuttui. Ne eivät voi osoittaa, että alkuperäinen tallenne oli täydellinen tai että tallennettu tapahtuma oli lainmukainen.

Neljäs kysymys on yksityisyys. Lokit voivat sisältää kehotteita, tunnisteita, lähdeotteita, mallien tuotoksia, työkaluargumentteja ja ihmisten tekemiä merkintöjä. Niiden säilyttäminen ikuisesti voi luoda toisen ongelman samalla, kun se ratkaisee ensimmäisen. Asetus itse kytkee kirjaamisvelvollisuudet muuhun unionin ja kansalliseen lainsäädäntöön, mukaan lukien tietosuojaan. Järkevä suunnittelu erottaa operatiivisen näytön tarpeettomasta sisällöstä, rajoittaa pääsyä, määrittelee säilytysajan ja mahdollistaa oikaisun tai poiston tarvittaessa. Minimointi ei ole vastuullisuuden vihollinen. Se on se, mikä estää vastuullisuutta muuttumasta luvaksi kerätä yksityinen elämäkerta jokaisesta käyttäjästä.

Viides kysymys on toistettavuus. Toistettavuus ei aina tarkoita todennäköisyysmallin ajamista uudelleen ja saman lauseen odottamista. Se voi tarkoittaa olennaisen tilan rekonstruoimista: malli- ja käytäntöversiot, lähdeviittaukset, syötteen luokittelu, ohjeisto, tuotos, ihmisen toimet, työkalun tulos ja myöhempi toiminta. Toisto voi paljastaa, että täsmällinen toistaminen on mahdotonta, koska etäinen riippuvuus on muuttunut. Tämäkin tulos on näyttöä, jos järjestelmä kertoo, mitä säilytettiin, mitä ei ja miksi. Rehellinen toiston raja on arvokkaampi kuin teatraalinen painike, jossa lukee toista.

Lopuksi lokeilla on oltava omistaja. Kenttä ilman omistajaa muuttuu orvoksi lupaukseksi. Jonkun on päätettävä, mitkä tapahtumat ovat olennaisia, varmistettava, että kirjaaminen toimii, seurattava kirjauspolun vikoja, suojattava pääsy, testattava hakua ja poistettava tietueet ilmoitetun tarkoituksen mukaisesti. Omistaja voi olla tiimi eikä henkilö, mutta vastuuta ei voi siirtää tallennustilalle. Tallennustila ei osallistu arviointikokoukseen. Sen käsitys suhteellisuudesta on myös valitettavan heikko.

Dokumentaatio on elävä kuvaus

Teknistä dokumentaatiota kohdellaan joskus paikkana, jossa insinööritiimi selittää tuotteen itselleen. AI-asetuksen mukaan sillä on laajempi yleisö. Sen on tarjottava tietoa, jota kansallinen toimivaltainen viranomainen tai ilmoitettu laitos voi käyttää vaatimustenmukaisuuden arviointiin. Tämä muuttaa asiakirjan sävyä. Se ei saa olla järjestelmän mainos, eikä se saa olla yksityinen muistikirja, joka on täynnä viittauksia, joita kukaan muu ei pysty seuraamaan. Se on hallittu kuvaus tarkoituksesta, suunnittelusta, toiminnasta, rajoista, tiedoista, testauksesta ja muutoksista.

Elävällä kuvauksella on suhde järjestelmän identiteettiin. Se nimeää tarjoajan, käyttötarkoituksen ja olennaiset versiot. Se selittää, miten järjestelmä toimii vuorovaikutuksessa muiden ohjelmistojen ja laitteistojen kanssa. Se kuvaa komponentit ja prosessit, jotka vaikuttavat vaatimuksiin. Se kirjaa testit ja validoinnin, jotka tukevat suorituskykyväitteitä. Se tunnistaa ennakoitavissa olevat olosuhteet, jotka voivat muuttaa käyttäytymistä. Se ilmoittaa rajapinnat ja valvontatoimet, joita käyttöönottoa tekevä tarvitsee. Tämä ei tarkoita, että asiakirjan on paljastettava liikesalaisuuksia umpimähkäisesti. Se tarkoittaa, että luottamuksellisuudesta ei voi tulla tekosyytä sille, ettei arvioitavaa selvitystä ole.

Versiointi on ratkaiseva kohta. Asiakirja, joka muuttuu ilman historiaa, voi piilottaa muutoksen saamalla uuden tilan näyttämään vanhalta. Historia, joka kirjaa jokaisen välimerkkimuokkauksen, voi haudata merkittävän muutoksen harmittoman kohinan joukkoon. Hyödyllinen muutosloki kertoo, mikä muuttui, miksi se muuttui, kuka sen hyväksyi, mikä arviointi toistettiin, mitkä myöhemmät materiaalit on päivitettävä ja milloin uusi tila tuli voimaan. AI-asetus viittaa olennaiseen muutokseen useassa kohdassa. Organisaatio tarvitsee tavan huomata muutos ennen kuin nimityksestä tulee kiistan aihe.

Provenanssi koskee myös oletuksia. Järjestelmä voi nojautua oletukseen aineiston edustamasta väestöstä, lähteen tuoreudesta, kentän merkityksestä tai käyttöönottajan osaamisesta. Oletukset eivät ole noloja puutteita, jotka pitäisi piilottaa alaviitteeseen. Ne ovat järjestelmän väitteen reunat. Niitä nimeävä tallenne antaa käyttäjälle mahdollisuuden tunnistaa, milloin reuna on saavutettu. Ne piilottava tallenne kutsuu käyttämään järjestelmää olosuhteissa, joissa sen näyttö ei enää ollut mielekästä.

Dokumentaation pitäisi tehdä epävarmuudesta luettavaa teeskentelemättä, että kaikki tuntematon voidaan määrällistää. Osa epävarmuudesta on numeerista. Muu koskee puuttuvaa kattavuutta, ratkaisemattomia ristiriitoja, muuttuvaa lainsäädäntöä, uudenlaisia syötteitä tai testaamatonta vuorovaikutusta toisen osan kanssa. Hyvä kuvaus voi sanoa, että ehtoa ei arvioitu, että lopputulos riippuu inhimillisestä harkinnasta tai että järjestelmää ei pitäisi käyttää nimettyyn tarkoitukseen. Nämä toteamukset eivät ole merkki heikosta järjestelmästä. Ne ovat tietoa, jonka avulla vahva järjestelmä pysyy toimivaltansa rajoissa.

Rajoituksen ja kieltäytymisen välillä on ero. Rajoitus kertoo, missä järjestelmän väite muuttuu epäluotettavaksi. Kieltäytyminen kertoo, että järjestelmä ei etene jossakin ehdossa. Molemmat pitäisi dokumentoida. Jos käyttäjä näkee vain yleisen virheilmoituksen, organisaatio menettää mahdollisuuden selittää, suojaako rajoitus turvallisuutta, yksityisyyttä, oikeuksia, laatua vai kapasiteettia. Selkeät kieltäytymistallenteet tukevat myös parantamista. Toistuvat kieltäytymiset voivat osoittaa, että työnkulku pyytää järjestelmää tekemään työtä, johon sitä ei koskaan suunniteltu.

Ihmisen valvonnan ympärille tarvitaan näyttöä

AI-asetuksen ihmisen valvontaa koskevia säännöksiä on helppo tiivistää ja vaikea toteuttaa. Henkilön nimeäminen ei ole sama asia kuin valvonnan mahdollistaminen. Henkilö tarvitsee osaamista, koulutusta, toimivaltaa ja tukea. Hänen on ymmärrettävä kyvykkyydet ja rajoitukset, havaittava poikkeamat, vältettävä automaatioharhaa, tulkittava tuotosta ja päätettävä olla käyttämättä, ohittaa, kumota tai pysäyttää järjestelmä. Nämä ovat operatiivisia valtuuksia. Henkilö, joka on teknisesti nimetty tarkastajaksi mutta ei näe syötettä, voi muuttaa lopputulosta tai keskeyttää työnkulun, on todistaja, ei valvoja.

Tallenteet voivat osoittaa, oliko valvonnalla hampaita. Ne voivat yksilöidä määrätyn roolin, esitetyn tiedon, näytetyn varoituksen tai rajoituksen, tarkastajan toimen ja lopullisen käsittelytavan. Ne voivat säilyttää syyn ohitukselle pakottamatta henkilöä kirjoittamaan esseetä joka kerta. Ne voivat myös osoittaa, milloin järjestelmä ei ollut käytettävissä tai milloin tarkastusreitti ohitettiin. Ihmisen toimen puuttuminen ei ole automaattisesti väärinkäytöstä. Se on signaali tutkia, tekikö suunnittelu toimen mahdolliseksi, tarpeelliseksi ja näkyväksi.

Tarkastellaan ehdotettua toimintamallia raportoidun tapahtuman sijaan. Järjestelmä tuottaa suosituksen ja lyhyen näyttöpaneelin. Tarkastaja voi hyväksyä, muokata, hylätä tai nostaa asian eteenpäin. Käyttöliittymä tallentaa järjestelmäversion, lähdeviittaukset, käytäntötilan, tarkastajan roolin ja käsittelytavan. Jos tarkastaja hylkää suosituksen, tallenne säilyttää hallitun syyn ja lähettää tapauksen jatkokäsittelyyn, kun toimintamalli viittaa toistuvaan vikaan. Tämä ei ole väite, että toimintamalli riittää kaikissa korkean riskin yhteyksissä. Se osoittaa, miten käyttöliittymä voi muuttaa ihmisen valvonnan valintaruudusta päätöksen havaittavaksi osaksi.

Ihmisen suorittama arviointi tarvitsee suojaa myös väsymystä ja sosiaalista painetta vastaan. Tietue, joka näyttää tuhansia hyväksyntöjä mutta ei yhtään merkityksellistä puuttumista, voi kertoa siitä, että työnkulku on terve, tai siitä, että arvioija ei voi realistisesti haastaa tuotosta. Pelkät luvut eivät ratkaise asiaa. Toimiva seurantakäytäntö yhdistää käsittelytavat otantaan, virhelöydöksiin, eskalaation laatuun, käytettävissä olevaan aikaan, koulutukseen ja väärän vastauksen seurauksiin. Mittaamisen pitäisi valaista työtä, ei luoda kiintiötä, joka opettaa ihmisiä hyväksymään nopeammin.

Valvontaan on kuuluttava oikeus pysäyttää. Artiklassa 14 kuvataan puuttuminen tai keskeytys pysäytyspainikkeella tai vastaavalla menettelyllä, jonka avulla järjestelmä voi pysähtyä turvalliseen tilaan. Pysäytyshallinta, joka on olemassa vain toimintaohjekirjassa, ei ole sama asia kuin hallinta, johon valtuutettu henkilö yltää paineen alla. Tietueen pitäisi näyttää, oliko pysäytys käytettävissä, kuka sitä saattoi käyttää, mikä tila seurasi ja miten työnkulku jatkui. Järjestelmä, joka voidaan pysäyttää mutta joka ei osaa kertoa, mitä pysäytettiin, on ratkaissut vain puolet ongelmasta.

Tässä todistusaineistossa on inhimillinen puoli. Kun lopputulosta haastetaan, tietueet voivat suojata sekä arvioijaa että asianomaista henkilöä. Ne voivat osoittaa, että arvioija näki rajoituksen, noudatti menettelyä, eskalaatioi ristiriidan tai pysäytti riskialttiin toimenpiteen. Se ei tee jokaisesta päätöksestä oikeaa. Se tekee harkinnan edellytykset näkyviksi. Vastuullisuus ei ole lähimmän ihmisen sormenjäljen metsästystä. Se on yritystä ymmärtää ketju riittävän hyvin, jotta sitä voidaan parantaa.

Paperityön takana oleva laatujärjestelmä

Artikla 17 edellyttää, että suuririskisten tekoälyjärjestelmien tarjoajat ottavat käyttöön laatujärjestelmän ja dokumentoivat sen järjestelmällisesti ja johdonmukaisesti politiikkojen, menettelyjen ja ohjeiden avulla. Sen luettelo on tarkoituksella laaja. Se kattaa sääntelyn noudattamisen ja muutostenhallinnan, suunnittelun ja kehityksen valvontatoimet, testauksen ja validoinnin, tekniset eritelmät, tietojen hallinnan, riskienhallinnan, markkinoille tulon jälkeisen seurannan, vakavien vaaratilanteiden raportoinnin, viestinnän viranomaisten ja muiden toimijoiden kanssa, kirjanpidon, resurssien hallinnan sekä johdon ja henkilöstön vastuukehyksen.

Kokonaisuutena luettuna tämä ei ole vaatimus vielä yhdestä vaatimustenmukaisuuskansiosta. Se on vaatimus siitä, että organisaatio pystyy yhdistämään päätöksensä. Testausmenettelyn pitäisi olla yhteydessä riskiin. Tietoprosessin pitäisi olla yhteydessä aiottuun käyttötarkoitukseen. Muutosprosessin pitäisi olla yhteydessä dokumentaatioon. Seurantaprosessin pitäisi olla yhteydessä korjaaviin toimenpiteisiin. Vastuukehyksen pitäisi olla yhteydessä ihmisiin, jotka voivat todella muuttaa järjestelmää. Jos jokaista asiakirjaa ylläpidetään erillään, laatujärjestelmästä tulee arkisto toisiinsa liittymättömiä hyviä aikomuksia.

Hyödyllinen laatutietue vastaa neljään käytännön kysymykseen. Mitä piti tapahtua. Mitä todella tapahtui. Miten ero havaittiin. Mikä muuttui seurauksena. Vastaus voi jakautua riskirekisterin, testiraportin, muutostietueen, vaaratilanneraportin ja julkaisupäätöksen kesken. Se on hyväksyttävää, jos yhteydet ovat pysyviä ja ymmärrettäviä. Se ei ole hyväksyttävää, jos arvioijan on arvattava, mitkä tiedostot kuuluvat samaan järjestelmän tilaan tai mitä testitulosta käytettiin tietyn julkaisun tukemiseen.

Järjestelmä tarvitsee myös tavan kirjata päätös olla muuttamatta. Riski voidaan arvioida ja todeta hyväksyttäväksi dokumentoitujen edellytysten puitteissa. Ehdotettu ominaisuus voidaan hylätä, koska näyttö on riittämätöntä. Julkaisu voi odottaa, koska arviointi on keskeneräinen. Nämä ovat päätöksiä, joilla on peruste, eivät tyhjää tilaa kalenterissa. Niiden kirjaaminen estää myöhempää lukijaa sekoittamasta tarkoituksellista rajaa vahingossa tapahtuneeseen puutteeseen. Se auttaa myös tiimiä vastustamaan painetta muuttaa jokainen ratkaisematon kysymys julkaisusuunnitelmaksi.

Laadunhallinnalla on aikadimensio. Prosessi, joka toimi staattisessa mallissa, ei välttämättä toimi, kun järjestelmä oppii käyttöönoton jälkeen, muuttaa hakemistoaan tai saa uuden työkalun. Prosessi, joka toimii sisäisessä avustajassa, ei välttämättä toimi, kun sama komponentti integroidaan päätöksentekoprosessiin. Asiakirjan tulisi siksi yksilöidä tarkistuksen laukaisevat tekijät: malliversio, tietolähde, käyttötarkoitus, käyttäjäjoukko, työkaluoikeus, lakisääteinen vaatimus, poikkeama tai seurannassa havaittu kaava. Laukaiseva tekijä on osa hallintaa.

Suhteellisuus on tässäkin tärkeää. Asetuksessa edellytetään, että täytäntöönpano on oikeassa suhteessa palveluntarjoajan organisaation kokoon, kuitenkin noudattaen vaadittavaa huolellisuutta ja suojaa. Suhteellisuus ei tarkoita epävirallisuutta. Pieni palveluntarjoaja voi käyttää tiivistä, hyvin suunniteltua asiakirjakokonaisuutta sen sijaan, että se jäljentäisi suuren laitoksen koneiston. Sen on silti tiedettävä, kuka vastaa kustakin päätöksestä, missä todisteet säilytetään, miten muutokset arvioidaan ja miten viranomainen saa tarvitsemansa tiedot. Pienuus ei tarkoita vapautusta muistista.

Säilytys on suunnitteluratkaisu

18 artikla edellyttää, että palveluntarjoajat pitävät määritellyt asiakirjat kansallisten toimivaltaisten viranomaisten saatavilla kymmenen vuotta siitä, kun korkean riskin tekoälyjärjestelmä on saatettu markkinoille tai otettu käyttöön. 19 artikla koskee automaattisesti tuotettuja lokitietoja ja edellyttää niiden säilyttämistä, siltä osin kuin ne ovat palveluntarjoajan hallinnassa, käyttötarkoitukseen soveltuvan ajan ja vähintään kuusi kuukautta, ellei muussa laissa, mukaan lukien tietosuojalainsäädäntö, toisin säädetä. Nämä ovat oikeudellisia vaatimuksia, joilla on tarkat soveltamisalat. Niitä ei tulisi huolettomasti yleistää koskemaan kaikkia asiakirjoja kaikissa tekoälytyönkuluissa.

Käytännön opetus on, että säilytys on suunniteltava asiakirjaluokittain. Teknisellä dokumentaatiolla, laadunhallintajärjestelmän asiakirjoilla, vaatimustenmukaisuusaineistolla, lokitiedoilla, lähdedatalla, ihmisten tekemillä muistiinpanoilla, arviointiaineistoilla, poikkeamatodisteilla ja julkisilla selvityksillä voi olla erilaiset tarkoitukset ja elinkaaret. Yksi oletussäilytysasetus on arkkitehtoninen oikotie, ei hallintastrategia. Se voi hävittää todisteet liian aikaisin tai säilyttää arkaluonteista aineistoa kauan sen jälkeen, kun sen tarkoitus on päättynyt. Järjestelmän tulisi tietää, mitä kerrosta se pitää hallussaan ja miksi.

Säilytyksellä on myös oltava alku ja loppu. Asiakirja, joka sanoo säilytettäväksi kymmenen vuotta määrittelemättä tapahtumaa, josta ajanjakso alkaa, ei ole toiminnallisesti täydellinen. Loki, jota säilytetään kuusi kuukautta ilman, että todetaan, alkaako ajanjakso tapahtumasta, julkaisusta vai seurantajakson päättymisestä, aiheuttaa tarpeetonta epäselvyyttä. Lainsäädäntö antaa asiaankuuluvat kiinnekohdat yksittäisille velvoitteille. Organisaation on kuvattava nämä kiinnekohdat järjestelmän tiloihin ja tehtävä kuvaus tarkastettavaksi.

Asiakirjan poistaminen on itsessään tapahtuma. Jos toimiva kehote poistetaan, koska sen tarkoitus on päättynyt, järjestelmän on ehkä säilytettävä viite, joka osoittaa poiston tapahtuneen ja minkä säilytyssäännön nojalla se tehtiin. Jos virhe korjataan, alkuperäisen todisteen on ehkä pysyttävä saatavilla hallitussa historiassa sen sijaan, että se katoaisi ilman selitystä. Jos henkilötietoja poistetaan, johdannaiset artefaktit ja pääsypolut voivat vaatia erillisen analyysin. Poistosta tehtyä merkintää ei tule sekoittaa todisteeksi siitä, että jokainen kopio on hävinnyt. Se on todiste hallitusta toimenpiteestä määritellyn rajan sisällä.

Säilytys voi myös suojata organisaation oppimista. Poikkeamatarkastelu, joka säilyttää vain lopullisen johtopäätöksen, menettää olosuhteet, jotka tuottivat ongelman. Arviointiasiakirja, joka säilyttää vain pistemäärän, menettää työmäärän, käyttäjäjoukon, menetelmän ja rajoitukset, jotka tekivät pistemäärästä tulkittavan. Korjausasiakirja, joka säilyttää vain uuden arvon, menettää tiedon siitä, että virheellinen arvo kulki järjestelmän läpi. Kaiken säilyttäminen ei ole ratkaisu. Oikean todisteen säilyttäminen kysymystä varten on.

Kun todisteita puuttuu

Hyödyllisimmät tietojärjestelmät on suunniteltu puutteita varten. Ne osaavat kertoa, että lähde oli saavuttamaton, että kenttä oli poistettu, että versiotunnus oli tuntematon, että ihmisen tekemää tarkistusta ei tehty, että työkalun kuittaus epäonnistui tai että toistoa ei voida suorittaa loppuun. Tämä ei ole kutsu keksiä siistiä paikkatietoa. Se on tapa estää puuttuvan näytön muuttuminen hiljaisesti luottamukseksi.

Puutteella on tyyppejä. Ei kerätty tarkoittaa, että järjestelmä ei koskaan yrittänyt säilyttää kenttää. Ei saatavilla tarkoittaa, että kenttä oli olemassa muualla, mutta sitä ei voitu hankkia. Ei sovellettavissa tarkoittaa, että ehto ei kuulunut työnkulkuun. Poistettu tarkoittaa, että näyttö on olemassa, mutta se on rajoitettu säännön nojalla. Ristiriitainen tarkoittaa, että kaksi lähdettä ovat eri mieltä. Tuntematon tarkoittaa, että organisaatio ei ole vahvistanut vastausta. Nämä merkinnät ovat ehdotettua toimintasanastoa, eivät tekoälyasetuksen määräämiä termejä. Niiden arvo on siinä, että ne estävät eri ongelmia sulautumasta yhdeksi tyhjäksi soluksi.

Täydellisyyden tarkastajan tulisikin kysyä kysymyksiä, ei laskea kenttiä. Käykö tietueesta ilmi järjestelmän tila. Näkyykö siitä tarkoitus ja syötteen laajuus. Löytyykö lähde tai toimintapolitiikan perusta. Onko ihmisen auktoriteetti näkyvissä. Onko epävarmuus ja poikkeukset nimetty. Voiko henkilö korjata, valittaa, keskeyttää tai poistaa sovellettavan rajan puitteissa. Vastaukset riippuvat asiayhteydestä. Tietue voi olla täydellinen operatiiviselle hälytykselle ja epätäydellinen yksittäiselle päätökselle. Täydellisyys on näytön ja seurauksen välinen suhde.

Puuttuvien tietueiden pitäisi laukaista riskiä vastaava toimenpide. Vähämerkityksinen puuttuva merkintä voidaan korjata seuraavassa julkaisussa. Seurauksellisen päätöksen puuttuva malliversio voi edellyttää päätöksen uudelleentarkastelua tai työnkulun keskeyttämistä. Puuttuva loki tilaa muuttavasta työkalukutsusta voi edellyttää tutkintaa mallitiimin ulkopuolella. Organisaation tulisi päättää näistä kynnyksistä ennen tapausta, koska päättäminen kiivaan tarkastelun aikana tuottaa yleensä adrenaliinista tehdyn toimintapolitiikan.

Puutospolulla on myös oltava omistaja ja aikaleima. Jos vaadittua tietuetta ei voida tuottaa, jonkun tulisi tietää, kuka vastaa tutkinnasta, kuka voi päättää, jatkuuko työ, mitä näyttöä etsitään ja milloin tila tarkistetaan. Tämä muuttaa aukon hallituksi tilaksi. Se ei tee aukosta vaaratonta. Se estää laitosta teeskentelemästä, että puuttuva sivu on tyhjä sivu.

Tekoälytoimisto ja tulkinnan työ

Tekoälyasetus luo toimielimiä ja menettelyjä, jotka auttavat muuttamaan asetuksen käytännöksi. Komission tekoälytoimistolla on rooli yleiskäyttöisten tekoälymallien velvoitteiden valvonnassa ja täytäntöönpanossa, kun taas kansallisilla toimivaltaisilla viranomaisilla ja markkinavalvontaviranomaisilla on vastuita laajemmassa kehyksessä. Tekoälyasetuksen palvelupiste tarjoaa 12 artiklan selityksen, joka tiivistää kirjaamisvelvollisuuden ja ohjaa lukijat viralliseen tekstiin. Sen yhteenveto on nimenomaisesti sitomaton. Tämä erottelu kannattaa säilyttää.

Ohjeistus voi tehdä säännöstä käyttökelpoisen muuttamalla oikeudellisen vaatimuksen esimerkeiksi, kysymyksiksi ja toteutusvaihtoehdoiksi. Se ei voi korvata asetusta. Organisaation tulisi pystyä osoittamaan, mikä väite tulee sitovasta tekstistä, mikä ohjeistuksesta ja mikä on sen oma valvontapäätös. Tämä lähdediscipliini ei ole akateemista nipottamista. Se estää hyödyllistä esimerkkiä muuttumasta kuvitteelliseksi velvoitteeksi ja estää vapaaehtoisen käytännön markkinoinnin sisäisesti lakisääteisenä vähimmäisvaatimuksena.

Komission AI@EC-tiedonanto tarjoaa hyödyllisen institutionaalisen esimerkin väittämättä kuvaavansa jokaista julkista toimielintä. Tammikuussa 2024 komissio esitti lähestymistavan omaan tekoälyn kehittämiseensä ja käyttöönsä, mukaan lukien sisäiset toimintaohjeet, riskiperusteisen arvioinnin ja luokittelun, sellaisten järjestelmien välttämisen, jotka ovat ristiriidassa eurooppalaisten arvojen kanssa tai uhkaavat oikeuksia ja turvallisuutta, sekä organisatoriset rakenteet velvoitteiden täyttämiseksi. Tarkoitus ei ole se, että tiedonanto ratkaisisi täytäntöönpanon. Tarkoitus on se, että tekoälyä käyttöön valmistelevan toimielimen on valmisteltava myös oma kykynsä hallita käyttöä.

Tämä kyky rakentuu rekistereistä, jotka voivat kulkea mukana. Käytännön tulisi osoittaa omistaja. Riskinarvioinnin tulisi osoittaa järjestelmän identiteetti. Teknisen kuvauksen tulisi osoittaa julkaisu. Koulutusrekisterin tulisi osoittaa rooli ja osaaminen. Seurantasignaalin tulisi osoittaa toimenpide. Valituksen tulisi osoittaa reitti. Kun nämä suhteet ovat eksplisiittisiä, ohjeita voidaan soveltaa keksimättä erillistä paperityön maailmaa. Kun ne eivät ole, jokaisesta uudesta ohjeesta tulee jälleen yksi asiakirja, jonka organisaatio toivoo jotenkin muuttavan käyttäytymistä.

Eurooppalaisella lainsäädännöllä on erityinen institutionaalinen rakenne. Vastuut jakautuvat unionin toimielinten, jäsenvaltioiden, viranomaisten, tarjoajien, käyttöönottoon oikeutettujen ja muiden toimijoiden kesken. Rekisterin on tehtävä tämä jakautuminen näkyväksi sen sijaan, että se litistäisi jokaisen toimijan yleiseksi järjestelmän omistajaksi. Kysymys ei ole vain siitä, kuka rakensi mallin. Kysymys on siitä, kuka otti sen käyttöön, kuka hallitsee syötteitä, kuka määräsi valvonnan, kuka voi keskeyttää käytön ja kenen on tehtävä yhteistyötä viranomaisen kanssa. Nimillä ja sopimuksilla on merkitystä, mutta myös toiminnallisilla valtuuksilla, jotka rekisteri voi paljastaa.

Lakikielestä arjen rutiineiksi

Laki muuttuu käytännölliseksi, kun organisaatio muuntaa jokaisen velvoitteen pieneksi joukoksi toistettavia rutiineja. Tämä on ehdotettu toimintamalli, ei laillinen tarkistuslista. Vastaanotossa luokitellaan tarkoitettu käyttötarkoitus, vaikutuksen kohteena olevat henkilöt, tietoluokat, autonomia, työkalut ja päätösvalta. Ennen julkaisua sidotaan järjestelmän identiteetti, versio, ohjeistuksen tila, tietolähteet, testit, rajoitukset, valvontarooli ja pysäytysreitti. Käytön aikana kirjataan olennaiset tapahtumat, seurataan riskejä ja tehdään epävarmuus näkyväksi. Muutoksen tai poikkeaman jälkeen tutkitaan, korjataan, päivitetään kuvaus ja päätetään, jatkuuko käyttö.

Huomaa, mitä tämä malli ei sano. Se ei sano, että kaikki viestit kerätään ikuisesti. Se ei sano, että automaattinen loki on sama asia kuin selitys. Se ei sano, että kojelauta todistaa turvallisuuden. Se ei sano, että ihmisen nimi työnkulussa todistaa valvonnan. Se sanoo, että järjestelmällä tulisi olla rekisteri niistä edellytyksistä, joilla sen on sallittu toimia, ja niistä tapahtumista, jotka voivat osoittaa, täyttyivätkö nämä edellytykset.

Hyvällä rutiinilla on alku ja loppu. Rekisteri luodaan, kun merkityksellinen tila alkaa, sitä päivitetään, kun näyttö tai valtuudet muuttuvat, ja se suljetaan, kun tarkoitus tai tarkastelujakso päättyy. Sulkemistapahtumalla on merkitystä, koska avoimista rekistereistä tulee hiljalleen pysyviä. Siinä tulisi todeta, onko järjestelmä julkaistu, hylätty, keskeytetty, korvattu, korjattu vai poistettu käytöstä. Jos rekisteriä ei voida sulkea, organisaation tulisi tietää miksi. Päättymätön väliaikainen tila on kohtelias tapa välttää päätöstä.

Rutiinien tulisi myös erottaa tosiasiat tulkinnoista. Loki voi kirjata, että malli palautti tulosteen. Arvioija voi kirjata, että tuloste hylättiin, koska lähde oli ristiriidassa käytännön kanssa. Poikkeamaryhmä voi myöhemmin päätellä, että hakumuutos vaikutti ristiriitaan. Päätelmä voi olla vahva, mutta se ei ole samanlaista näyttöä kuin tapahtuma. Merkityt kerrokset tekevät myöhemmästä tutkinnasta rehellisempää. Ilman niitä jokainen johtopäätös kovettuu vähitellen tosiasiaksi, koska kukaan ei muista, mikä lause havaittiin ja mikä kirjoitettiin kokouksessa.

Omistajuuden tulisi olla näkyvissä kenttätasolla, kun se on käytännössä mahdollista. Palveluntarjoaja voi omistaa teknisen dokumentaation. Käyttöönottaja voi omistaa syötteen relevanssin ja operatiivisen seurannan. Data-asiantuntija voi omistaa lähdeoikeudet ja laadun. Ihmisvalvontarooli voi omistaa päätöksen hyväksyä, ohittaa tai pysäyttää. Arkistotoiminto voi omistaa säilytyksen ja pääsyn. Jakautuminen vaihtelee kontekstin ja sopimuksen mukaan. Tallenteen tulisi mahdollistaa kysymyksen esittäminen oikealle omistajalle ilman, että lähetetään sähköpostia koko organisaatiolle.

Rutiinin testaaminen on yhtä tärkeää kuin sen kirjoittaminen. Ehdotettua valvontatoimea tulisi harjoitella turvallisella, selkeästi merkityllä skenaariolla. Saako tiimi tallenteen haettua järjestelmäversion mukaan? Näkeekö operaattori julkaisuhetkellä käytetyn ohjeistuksen tilan? Voiko arvioija hylätä tuotoksen ja säilyttää syyn? Jättääkö pysäytyspolku selkeän tilan? Saako toimivaltainen viranomainen asiaankuuluvan dokumentaation ilman aarteenmetsästystä? Nämä ovat harjoituksia, eivät raportoituja poikkeamia. Niiden tulokset tulisi kirjata testeinä, ja rajoitukset tulisi ilmaista suoraan.

Rutiini tulisi suunnitella hiljaista päivää varten. Jos se toimii vain silloin, kun asiantuntija on hereillä, toimittaja vastaa nopeasti ja kaikki muistavat käyttöönottokäytännön, se ei ole rutiini. Se on kollektiivinen muisti palvelutasosopimuksella. Vakava tallennusjärjestelmä antaa tavalliselle henkilökunnalle tavan vastata tavallisiin kysymyksiin, ja se antaa asiantuntijoille syvemmän polun, kun kysymyksestä tulee merkittävä. Hiljainen päivä on se, jolloin järjestelmä ansaitsee luottamuksen meluista päivää varten.

On houkutus tehdä tallenteista kauniita. Selkeä muotoilu auttaa ihmisiä käyttämään niitä, mutta visuaalinen viimeistely ei ole todiste. Värillinen tila, kypsyyspistemäärä tai täydellisen näköinen kortti voi piilottaa puuttuvat kentät. Käyttöliittymän tulisi tehdä epävarmuudesta, vanhentuneesta datasta ja vahvistamattomista väitteistä vaikeampaa jättää huomiotta. Sen tulisi tukea tylsiä toimintoja, jotka pitävät tallenteen totuudenmukaisena: version kiinnittäminen, lähteen tunnistaminen, roolin nimeäminen, rajoituksen merkitseminen, korjauksen linkittäminen ja tilan sulkeminen. Hyvä muotoilu antaa tallenteelle kahvat. Se ei anna tallenteelle valtuuksia, joita se ei ole ansainnut.

Pieni huomautus meiltä

Dwevellä Trust Centre on järjestetty saman kysymyksen ympärille: mitä toisen henkilön tulisi voida tarkastaa mallista ja sen toiminnasta. Julkinen hakemisto yhdistää mallin identiteetin, koulutussisällön, arvioinnit, riskienhallinnan, markkinoille tulon jälkeisen seurannan, poikkeamat, datahallinnon ja teknisen dokumentaation. Tämä järjestely ei ole väite siitä, että julkinen sivu todistaisi vaatimustenmukaisuuden, eikä se korvaa viranomaisen arviointia. Se on tietoinen yritys pitää tallenteet ja niiden rajat näkyvillä. Ledger-työmme esittää vastaavan argumentin operatiivisella tasolla: tallenteen tulisi sisältää riittävästi identiteettiä ja historiaa, jotta myöhempi lukija voi tarkistaa, mikä muuttui. Hyödyllinen testi ei ole se, näyttääkö sivu rauhoittavalta. Se on se, kertooko todisteaineisto totuuden siitä, mitä se voi ja ei voi osoittaa.

Tallenteet ovat osa instituutiota

Syvin virhe on kohdella tekoälyasetuksen tallennevaatimuksia innovaation verona. Ne on parempi ymmärtää kuvauksena siitä, mitä instituutio tarvitsee käyttääkseen tehokasta, muuttuvaa järjestelmää luovuttamatta muistiaan. Malli voi tuottaa tuotoksen nopeasti. Instituution on päätettävä, kuuluuko tuotos päätökseen, voiko joku haastaa sen, voiko korjaus kulkea järjestelmän läpi ja voiko tuleva lukija ymmärtää polun.

Tämän vuoksi tietoja ei voi jättää arkkitehtuurin reuna-alueille. Ne kuuluvat datan, ohjeiden, malliversioiden, työkalujen, rajapintojen, ihmisten roolien ja korjaustoimien yhteyteen. Tieto on se yhdistävä kudos, jonka ansiosta nämä osat voivat vastata toisilleen. Se muuttaa riskilausuman tarkistettavaksi ehdoksi. Se muuttaa lähteen jäljitettäväksi perustaksi. Se muuttaa ihmisen hyväksynnän havaittavaksi teoksi. Se muuttaa korjauksen muutokseksi, joka voidaan tarkistaa. Se muuttaa puuttuvan kentän hallituksi kysymykseksi sen sijaan, että se olisi tyhjä kohta, jota kukaan ei omista.

Työ on hiljaista, koska se näyttää tavalliselta. Nimeä järjestelmä. Määritä tarkoitus. Kirjaa versio. Säilytä lähderaja. Testaa loki. Anna tarkastajalle valtuudet. Merkitse, mikä on tuntematonta. Säilytä vastaus. Poista tieto käytöstä, kun tarkoitus päättyy. Missään tässä ei ole julkaisuvideon glamouria. Sillä on kuitenkin arvokkaampi ominaisuus: se kestää henkilöstön vaihtumisen, mallin vaihtumisen, toimittajan vaihtumisen ja kysymyksen sellaiselta, joka ei ollut huoneessa.

Erimielisyyksiä tulee edelleen olemaan AI-asetuksen tulkinnasta, yksityiskohtaisuuden tasosta ja siitä, miten standardit kääntävät lainsäädännön vaatimukset teknisiksi käytännöiksi. Tiedot eivät poista näitä väittelyitä. Ne tekevät niistä täsmällisempiä. Organisaatio voi osoittaa, mihin tekstiin se nojasi, minkä oletuksen se teki, mitä näyttöä sillä oli, minkä hallintakeinon se valitsi ja missä sen epävarmuus edelleen on. Tämä on parempi lähtökohta sääntelijälle, kollegalle, asianomaiselle henkilölle ja itse organisaatiolle.

Käytännön opetus on yksinkertainen. Älä kysy vain, voiko tekoälyjärjestelmä tuottaa tuloksen. Kysy, pystyykö organisaatio muistamaan tuloksen edellytykset, osoittamaan merkityksellisen näytön, nimeämään toimineen viranomaisen, tunnistamaan jäljellä olevan epävarmuuden ja saamaan korjauksen etenemään. Jos vastaus on ei, järjestelmä voi silti olla teknisesti vaikuttava. Se ei ole vielä institutionaalisesti valmis.

EU:n tekoälyasetuksen hiljainen työ ei siis ole teknologian kuulostamista vakavalta. Se on vakavuuden tekemistä havaittavaksi. Tiedot eivät ole iskulauseita aikaleimoilla. Ne ovat rajattua näyttöä, joka on luotu tarkoitusta varten, kytketty vastuuseen ja avoin korjauksille. Kun ne rakennetaan huolella, organisaatio voi käyttää tekoälyä ilman, että sujuvuuden annetaan korvata muistia. Kun ne jätetään jälkikäteisajatteluksi, ensimmäinen vaikea kysymys paljastaa, että järjestelmä säilytti tuotoksensa mutta hukkasi historiansa.

Lähteet