Oikeus tietää, mikä muuttui

Julkinen päätös ei ole koskaan vain sen lopullinen lause. Se on sääntö, data, järjestelmä, työnkulku ja inhimillinen auktoriteetti, jotka tekivät lauseen...

Oikeus tietää, mikä muuttui

Dokumenttia, jota ei ollut

Maaliskuussa 2024 Euroopan oikeusasiamies aloitti selvityksen siitä, miten Euroopan komissio päättää tekoälyn käytöstä ja miten se sitä käyttää. Kysymykset koskivat kolmea tavallista hallinnollisen työn aluetta: palautteen analysointia, mahdollisten kilpailusääntöjen rikkomusten löytämistä ja valitusten käsittelyä. Oikeusasiamies kysyi automatisoinnista, tekoälyn käyttöä koskevasta päätöksestä, tähän päätökseen liittyvästä avoimuudesta ja vastuuvelvollisuudesta. Julkinen ilmoitus ei kuvannut dramaattista epäonnistumista. Se kuvasi tarvetta ymmärtää, miten toimielin tekee ja hallinnoi valinnan.

Tällä erottelulla on merkitystä. Kun viranomaiselta kysytään, miksi se käytti järjestelmää, hyödyllinen vastaus on harvoin lopullinen lehdistötiedote. Arvioijan on tiedettävä, mikä tarkoitus oli hyväksytty, mikä sääntö ja tietomääritelmä olivat voimassa, mitä järjestelmäversiota käytettiin, mitä käyttäjä pystyi näkemään ja kenellä oli valtuudet hyväksyä tai hylätä tulos. Selitys on reitti ajassa. Jos nykyhetki on pyyhkinyt reitin pois, toimielin voi tarjota uskottavan kuvauksen, mutta ei välttämättä sellaista, joka oli totta päätöstä tehtäessä.

Julkiset organisaatiot ovat ymmärtäneet tämän ongelman jo pitkään. Lupa, toimintaperiaateasiakirja, rekisterimerkintä, tuomioistuimen asiakirja ja ministerin päätös saavat merkityksensä historiastaan. Lailla on voimaantulopäivä. Julkisella asiakirjalla on laatija ja asiayhteys. Korjaus ei huomaamatta muutu alkuperäiseksi. Digitaaliset järjestelmät eivät ole poistaneet näitä tosiasioita. Ne ovat levittäneet ne julkaisujen, asetusten, lähdesyötteiden, jonojen, kehotteiden, käyttöoikeussääntöjen ja toimittajapalveluiden kesken. Lopullinen tila voi yhä olla näkyvissä. Polku, joka antoi sille auktoriteetin, voi olla kadonnut.

Oikeus tietää, mikä muuttui, ei siksi ole pyyntö jokaisesta näppäinpainalluksesta. Se on vaatimus vastuullisesta muistista. Ihmisten, joihin julkinen päätös vaikuttaa, pitäisi voida selvittää, mikä relevantin maailman versio tuotti sen, yksityisyyden, turvallisuuden ja muiden oikeutettujen etujen asettamissa rajoissa. Toimielimet tarvitsevat saman tiedon korjatakseen virheitä, vastatakseen valituksiin ja selittääkseen omaa toimintaansa. Historia ei ole päätöksen koristeellinen liite. Se on osa sitä, mikä tekee päätöksestä päätöksen eikä orvoksi jäänyttä tuotosta.

Muutosloki on kohteliaisuus; historia on todiste

Ohjelmistotiimit tuntevat muutoslokit. Julkaisutiedote kertoo, että käyttöliittymää parannettiin, virhe korjattiin tai riippuvuus päivitettiin. Hyvä muutosloki on hyödyllistä viestintää. Se auttaa käyttäjiä päättämään, kannattaako päivittää, ja antaa ylläpitäjille julkisen kuvauksen heidän työstään. Se ei sellaisenaan ole päätösasiakirja. Se kuvaa yleensä sen, mitä julkaisija pitää tärkeänä. Se ei lupaa toistaa jokaisen järjestelmän läpi kulkeneen tapauksen tilaa.

Päätöshistorialla on eri tehtävä. Sen on vastattava kysymykseen tietystä teosta tiettynä ajankohtana. Mitä kelpoisuussäännön versiota sovellettiin tähän hakemukseen. Mikä tulon määritelmä oli käytettävissä, kun pistemäärä laskettiin. Mikä malli ja kalibrointi tuottivat järjestyksen. Mikä työnkulkureitti vei tapauksen tämän arvioijan eteen. Mitkä todisteet arvioija näki. Mikä ilmoitus lähetettiin. Vastaus voi viitata muutoslokiin, mutta se ei voi pysähtyä siihen. Julkaisutiedote kuvaa muutoksen yleisesti. Historia yhdistää muutoksen siihen vaikuttaneeseen päätökseen.

Siksi vihreä rivi, joka kertoo päivitetty, ei riitä. Päivitetty milloin, kenen valtuutuksella, millä voimaantulopäivällä ja minkä tapausten osalta. Merkintä, joka kertoo toimintaperiaatetta parannettu, jättää avoimeksi, onko vanha toimintaperiaate edelleen merkityksellinen valituksen kannalta, tarvitseeko aiempi tulos uudelleenarviointia ja otettiinko muutos käyttöön kaikkialla samaan aikaan. Historia kantaa suhteita, ei adjektiiveja. Se yhdistää kohteen aiempaan tilaansa, seuraajaansa, siirtymän syyhyn ja ajanjaksoon, jolloin tila oli voimassa.

Kahden tallenteen kirjoittamisessa on käytännön ero. Muutosloki voidaan kirjoittaa teknisen työn jälkeen, koska sen lukija tarvitsee yhteenvedon. Päätöshistoria on luotava työn edetessä tai työn aikana syntyneistä tallenteista. Jälkikäteen kirjoitetut muistiinpanot ovat hyödyllisiä, mutta ne ovat tulkintaa. Ne eivät voi turvallisesti korvata silloisia asiayhteyksiä. Ero ei ole romanttinen. Toinen tallenne auttaa ihmisiä pysymään perillä tuotteesta. Toinen antaa instituutiolle mahdollisuuden seisoa tekonsa takana.

Päätöshistoria yhdistää lopputuloksen versioihin, jotka mahdollistivat sen, ja jättää sitten reitin korjaukselle.

Muutos on harvoin vain yksi asia

Kun päätöstä tarkastellaan uudelleen, ihmiset aloittavat usein näkyvimmästä osasta. Malli muuttui. Lomake muuttui. Käytäntösivulla on uusi otsikko. Toimittaja julkaisi päivityksen. Nämä väitteet voivat kaikki olla totta ja silti jättää huomiotta varsinaisen muutoksen. Julkinen päätös kootaan kerroksista, jotka liikkuvat eri nopeuksilla, joilla on eri omistajat ja erilaiset käsitykset siitä, mikä lasketaan julkaisuksi.

Tietokerros voi muuttua, kun lähdeviranomainen korjaa henkilön osoitteen, tilastollisen määritelmän, luokituskoodin tai viitetaulukon. Putki voi muuttaa tapaa, jolla se yhdistää tietueita tai käsittelee puuttuvia arvoja. Hakemisto voidaan rakentaa uudelleen eri kokoelmasta. Välimuisti voi säilyttää vanhemman tulkinnan sen jälkeen, kun lähde on siirtynyt eteenpäin. Yksikään näistä muutoksista ei tarvitse olla tekoälymuutos muuttaakseen tekoälyavusteisen työnkulun tulosta.

Sääntökerroksella on myös useampi kuin yksi pinta. Voi olla laki, sisäinen käytäntö, kirjallinen ohje, kynnysarvo konfiguraatiossa, poikkeustaulu ja koulutusmuistiinpano arvioijille. Julkaistu käytäntö voi pysyä sanasta sanaan samana, kun kynnysarvo muuttuu käyttöönottoitedostossa. Toisaalta käytäntö voi muuttua, kun vanha sääntö toimii edelleen yhdellä alueella, koska julkaisu on porrastettu. Henkilön, johon tulos vaikuttaa, ei pitäisi joutua tietämään, mikä tiimi omistaa minkäkin osan, ennen kuin hän voi kysyä, mitä tapahtui.

Järjestelmäkerros sisältää mallin, sen painot tai paketin, sen kehotteen tai mallipohjan, hakukonfiguraation, turvallisuusasetukset ja ohjelmiston, joka kutsuu sitä. Työnkulkukerros sisältää jonon, reitin, käyttöoikeudet, näytön ja luovutuksen. Arvioijan toiminta riippuu siitä, mitä käyttöliittymä esittää olennaisena ja mitä se mahdollistaa. Päätöskerros sisältää tuloksen, selityksen, ilmoituksen, vaikutuksen alavirtaan ja mahdollisen valituksen. Versiohistoria on kurinalaisuutta nimetä kerrokset, joilla oli merkitystä, ei yritys saada yksi jättimäinen versionumero tekemään institutionaalista taikaa.

Arkisto tietää jo, että versioilla on merkitystä

Alankomaiden kansallisarkisto käyttää määritelmää, joka on virkistävän selkeä: historiallinen versio on informaatioobjektin aiempi versio. Sen ohjeistuksessa on tavallisia esimerkkejä. Muistio voi siirtyä luonnoksesta konseptiksi ja edelleen hyväksytyksi tekstiksi. Lakia voidaan muuttaa. Lupahakemukseen voidaan lisätä tietoja. Henkilö voi muuttaa, jolloin rekisterin arvo muuttuu. Muutoksen merkityksestä riippuen aiemmat versiot on ehkä pidettävä saatavilla. Tämä ei ole koneoppimisen luoma uusi vaatimus. Se on asiakirjahallintaa sovellettuna digitaaliseen työhön.

Sama ohjeistus tekee kaksi huomiota, jotka on helppo hukata pilvijärjestelmiä koskevassa keskustelussa. Julkishallinnon tieto kuuluu soveltamisalaan riippumatta sen teknisestä muodosta. Se voi olla tietokantamerkintä, verkkosivu, viesti tai video, ei vain allekirjoitettu paperi. Eikä tiedon tallennuspaikka ratkaise sitä, onko se pidettävä saatavilla. Toimittajan palvelin ei tee asiakirjasta vähemmän merkityksellistä sitä käyttäneelle viranomaiselle. Yksityinen kannettava tietokone ei muuta virallista tietoa henkilökohtaiseksi muistoksi.

Nämä periaatteet ovat hyödyllisiä tekoälylle, koska tekoäly piilottaa tavallisen tiedon teknisten pintojen alle. Ominaisuuden määritelmä, mallikortti, arviointimuistio, kehotepohja, reitityssääntö tai hyväksymisviesti voi määrätä, miten julkinen palvelu toimii. Niiden kutsuminen konfiguraatioksi ei poista niiden hallinnollista vaikutusta. Se vain tekee niiden historiasta vaikeammin nähtävää. Arkistoajattelu kysyy paremman kysymyksen: mitä tietoa syntyi tai vastaanotettiin, kun organisaatio hoiti tehtäväänsä, ja minkä on pysyttävä käyttökelpoisena, jotta tehtävä voidaan myöhemmin ymmärtää.

Arkistointi ei ole sama asia kuin kaiken säilyttäminen. Kansallisarkisto kuvaa valintoja siitä, mitkä historialliset versiot pysyvät saatavilla. Luonnos ei välttämättä tarvitse samaa käsittelyä kuin hyväksytty päätös. Henkilötietokenttä voi vaatia erilaisen säilytyspolun kuin oikeusperusta. Tarkoitus on tehdä valinta harkiten ja kirjata syy. Historian poistaminen voi olla hyväksyttävää. Sen poistaminen tietämättä, onko se jonkin vaikutuksen alaisen päätöksen historiaa, on vain nopea tapa hävitä väittely myöhemmin.

GDPR vaatii vastuullisuutta, ei arkeologiaa

Yleinen tietosuoja-asetus ei määrää julkishallinnon viranomaisille yhtä tiettyä versiohallintatuotetta. Se tekee jotakin vaativampaa. Artiklan 5(2) mukaan rekisterinpitäjä on vastuussa ja sen on pystyttävä osoittamaan noudattavansa tietosuojaperiaatteita. Artikla 24 kuvaa vastuuta asianmukaisista teknisistä ja organisatorisista toimenpiteistä. Artikla 30 edellyttää käsittelytoimien rekisteriä asetuksessa määrätyissä olosuhteissa. Yhdessä nämä säännökset tekevät vastuuvelvollisuudesta ominaisuuden, joka organisaation on pystyttävä osoittamaan, ei vain uskomuksen, jonka se voi ilmaista.

Käsittelytoimien rekisteri ei ole täydellinen päätöshistoria. Se kuvaa tavallisesti käsittelytoimintaa organisaation tasolla: sen tarkoituksen, tietoryhmät ja henkilöt, vastaanottajat, säilytysajat ja turvatoimet. Tämä rekisteri vastaa eri kysymykseen kuin se, mikä lähdearvo oli voimassa yksittäisessä tapauksessa. Mutta vastuuvelvollisuusperiaate luo selvän syyn säilyttää suhteet, joiden avulla organisaatio voi osoittaa, mitä se teki. Versiohistoria on yksi tapa tehdä näistä suhteista tarkasteltavia. Se tukee lakisääteistä velvollisuutta; se ei täytä sitä taianomaisesti.

Tämä erottelu estää kaksi yleistä virhettä. Ensimmäinen on kohdella rekisteriä ikään kuin se olisi jokaisen päätöksen toisinto. Sivu, joka kertoo organisaation käsittelevän osoitetietoja palvelun tuottamiseksi, ei voi todistaa, mitä osoitetta tietyssä ilmoituksessa käytettiin. Toinen on kohdella yksityiskohtaisia lokitietoja ikään kuin ne olisivat automaattisesti lainmukaista näyttöä. Loki voi sisältää enemmän henkilötietoja kuin tarkoitus edellyttää, sitä voidaan säilyttää pidempään kuin on perusteltua, tai se voi olla sellaisten henkilöiden saatavilla, joilla ei ole tarvetta tietää. Tilivelvollisuuteen kuuluu sekä tietojen minimointi että tietoturva. Muistille on suunniteltava myös poistumistie, ei vain sisäänkäyntiä.

Tiimeille, jotka rakentavat tai hankkivat tekoälyä hyödyntäviä järjestelmiä, käytännön seuraus on määritellä pienin pysyvä tallenne, joka voi vastata ennakoitavissa olevaan kysymykseen. Se voi olla viittaus lähdeversioon koko lähteen kopioimisen sijaan. Se voi olla sinetöity todistusaineistokokonaisuus, johon on rajoitettu pääsy. Se voi olla säännön tunniste ja voimassaolojakso päätöksen rinnalla. Oikeudellinen testi ei ole se, keräsikö organisaatio vaikuttavan määrän telemetriaa. Se on se, voiko organisaatio osoittaa lainmukaista, oikeudenmukaista ja tarkoitussidonnaista käsittelyä tekemättä jokaisesta henkilöstä pysyvää datan jälkivirtaa.

AI-asetus tekee elinkaaren muistista vaatimuksen

AI-asetus on täsmällisempi tiettyjen järjestelmien teknisen muistin suhteen. 11 artikla edellyttää, että suuririskisen tekoälyjärjestelmän tekniset asiakirjat laaditaan ennen järjestelmän saattamista markkinoille tai käyttöönottoa, pidetään ajan tasalla ja ovat riittävän selkeitä, jotta viranomaiset ja ilmoitetut laitokset voivat arvioida vaatimustenmukaisuutta. 12 artikla edellyttää, että suuririskiset järjestelmät mahdollistavat teknisesti tapahtumien automaattisen tallentamisen järjestelmän koko elinkaaren ajalta siten, että lokitiedot liittyvät riskiin, markkinoille saattamisen jälkeiseen seurantaan ja käyttöön. Nämä ovat elinkaarivelvoitteita, eivät pyyntö julkaisupäivän esitteestä.

Asetuksen jäljitettävyyttä koskeva johdanto-osa selittää miksi. Tietoa siitä, miten suuririskinen järjestelmä on kehitetty ja miten se toimii elinkaarensa aikana, tarvitaan vaatimustenmukaisuuden arvioimiseksi ja toiminnan seuraamiseksi. Asiakirjojen odotetaan kattavan ominaisuudet, kyvykkyydet, rajoitukset, algoritmit, tiedot, koulutuksen, testauksen, validoinnin ja riskienhallinnan. Ilmaus pidetään ajan tasalla tekee tärkeää työtä. Asiakirja, joka kuvasi aiempaa järjestelmää mutta jota ei koskaan muutettu, on näyttöä aiemmasta tilasta, ei näyttöä siitä, että nykyinen tila on edelleen vaatimustenmukainen.

Liite IV tekee versioiden välisestä suhteesta konkreettisen. Suuririskisen järjestelmän yleiskuvaus sisältää sen nimen ja version sekä suhteen aiempiin versioihin sekä olennaiset ohjelmisto- tai laiteohjelmistoversiot ja päivitysvaatimukset. Versionumero ilman suhdetta on pelkkä nimilappu. Suhde antaa arvioijalle mahdollisuuden ymmärtää jatkuvuuden, muutokset ja laajuuden. Se on ero sen välillä, että sanotaan tämä on versio neljä, ja sen välillä, että näytetään, mitkä oletukset versio neljä peri, korvasi tai teki vanhentuneiksi.

Mikään tästä ei tarkoita, että jokainen julkinen päätös olisi automaattisesti suuririskinen tekoälytapaus asetuksen nojalla. Luokittelu riippuu järjestelmästä, tarkoituksesta ja käytöstä, jotka asetus määrittelee. Se kuitenkin tarkoittaa, että organisaatioiden tulisi lakata pitämästä jäljitettävyyttä vapaaehtoisena mukavuutena teknisesti edistyneimmille tiimeille. Kun laki edellyttää, että järjestelmä jättää käyttökelpoisen toimintahistorian, suunnittelukysymyksestä tulee käytännöllinen: mitkä tapahtumat, versiot ja toimivaltuudet lokin on yhdistettävä, jotta myöhempi tarkastelu voi selvittää, mitä tapahtui, ilman että alkuperäistä tiimiä pyydetään muistamaan se.

Julkinen päätös on pino

Kuvittele, että avaat kahden vuoden takaisen asian. Lopputulos on siellä. Henkilön tietue on nyt täydellisempi. Käytäntösivua on tarkistettu. Mallia on päivitetty kahdesti. Käyttöliittymässä on uusi tarkistuspaneeli. Toimittaja on muuttanut hosting-järjestelyään. Esimies sanoo, että tiimi teki aina henkilökohtaisen tarkistuksen. Jokainen väite voi olla tänään totta. Mikään niistä ei kerro, miltä asia näytti silloin, kun päätös ylitti rajan suosituksesta toimeksi.

Puolustettava tietue käsittelee päätöstä pinoaa. Pohjalla on lähdetila, jossa on identiteetti, kelpoisuus, alkuperä ja käyttöehdot. Sen yläpuolella ovat sovellettavat säännöt ja kynnysarvot. Järjestelmän tila yksilöi ohjelmiston, mallin, kehotteen, indeksin ja kokoonpanon. Työnkulun tila tallentaa reitityksen, käyttöoikeudet, jonopaikan ja ihmisen roolin. Päätöksen kuittaus yhdistää tuloksen, perustelun, ilmoituksen, toimen ja jatkoviitteen. Myöhempi korjaus voi sitten kulkea taaksepäin pinon läpi ja löytää, mitkä päätökset riippuivat muuttuneesta kerroksesta.

Pinon ei tarvitse paljastaa jokaista sisäistä yksityiskohtaa jokaiselle lukijalle. Julkinen ilmoitus voi olla ytimekäs, kun taas valtuutettu tarkistaja voi tutkia syvemmän tietueen. Olennaista on, että laitos ei ole yhdistänyt erillisiä merkityksiä yhteen kenttään nimeltä versio. Lähdeversio ei ole käytäntöversio. Malliversio ei ole työnkulun julkaisu. Tarkistajan rooli ei ole hyväksynnän peruste. Pitämällä ne erillään organisaatio voi jakaa oikean selityksen oikealle henkilölle ja välttää keksimästä yhtä tarinaa, jota mikään järjestelmä ei todellisuudessa tallentanut.

Tämä selkeyttää myös omistajuutta. Data-omistaja omistaa lähteen korjausreitin. Käytäntöomistaja omistaa voimassa olevan säännön. Tekninen tiimi omistaa julkaisuartefaktin. Operaatiotiimi omistaa työnkulun ja koulutuksen. Päätöksentekijä omistaa teon. Hallinto yhdistää tietueet ja asettaa säilytys- ja käyttörajat. Jos kukaan ei voi sanoa, kuka omistaa kerroksen, versiohistoria on lista tunnisteita ilman vastuullista ääntä.

Ajalla on useampi kuin yksi kello

Päivämäärät ovat välttämättömiä ja usein harhaanjohtavia. Käytäntö voidaan julkaista maanantaina, ottaa käyttöön perjantaina ja saavuttaa tietty palvelu seuraavana tiistaina. Lähde voidaan kerätä kello 09:10, korjata kello 11:00 ja käsitellä uudelleen kello 14:00. Mallipaketti voidaan hyväksyä yhdessä ympäristössä ja ottaa käyttöön toisessa. Tarkistaja voi avata asian ennen muutosta ja toimittaa sen sen jälkeen. Yksi aikaleima ei voi kantaa kaikkia näitä merkityksiä ilman apua.

Hyvä historia erottaa ainakin ajan, jolloin artefakti luotiin, ajan, jolloin se tuli voimaan, ajan, jolloin se havaittiin tai tallennettiin, ja ajan, jolloin sitä käytettiin. Se voi myös tarvita ajan, jolloin se poistettiin käytöstä, korjattiin tai havaittiin virheelliseksi. Nämä eivät ole pikkutarkkoja erotteluja. Valitus voi riippua siitä, sovellettiinko uutta kynnysarvoa hakemukseen, joka oli jätetty ennen sen voimaantulopäivää, tai siitä, pitäisikö korjauksen muuttaa jo annettua ilmoitusta. Vastaus kuuluu lainsäädännölle ja laitoksen käytännölle, mutta tosiasiat edellyttävät kelloja, jotka voivat näyttää järjestyksen.

Kelpoisuudella on myös laajuus. Alueellisella työnkululla voi olla yksi julkaisu Rotterdamissa ja toinen Lyonissa. Kielipaketti voi muuttua eri aikataulussa kuin päätössääntö. Malli voi olla käytettävissä luonnosteluun mutta kielletty lopullisessa toimessa. Tietue, joka sanoo aktiivinen sanomatta missä ja mihin tarkoitukseen, on kartta, josta puuttuvat liikennemerkit. Laajuus muuttaa yleisen version käyttökelpoiseksi tosiasiaksi.

Kellojen tulee olla ymmärrettäviä myös niille, jotka eivät ylläpidä käyttöönottoputkea. Asianomaisen ei pitäisi joutua opettelemaan rakennusjärjestelmää voidakseen kysyä, mitä sääntöä sovellettiin. Tekninen tallenne voi säilyttää tarkat tunnisteet, kun julkinen selitys kääntää ne voimaantulopäiväksi, nimetyksi politiikaksi ja selkeäksi kuvaukseksi siitä, mitä organisaatio voi edelleen tehdä. Tarkkuus ja selkokieli eivät ole vastakkain. Tarkkuus antaa selkokielelle jotakin konkreettista sanottavaa.

Toisto on menetelmä, ei painike

Sana toisto luo vaarallisen odotuksen. Se kuulostaa siltä, kuin organisaatio voisi painaa nappia ja katsoa menneisyyden toistuvan täsmälleen sellaisena kuin se tapahtui. Joskus rajattu järjestelmä voi päästä lähelle tätä. Useammin toisto tarkoittaa relevantin tilan uudelleenrakentamista tallennetuista syötteistä, versioista, säännöistä, käyttöoikeuksista ja toimista, ja sen osoittamista, missä rekonstruktio on tarkka ja missä epävarmuus säilyy.

Aito toistotallenne erottaa havaitun rekonstruoitavasta. Alkuperäinen syöte voi olla sinetöity. Sääntö- ja mallitunnisteet voivat olla tiedossa. Tarkkaa ulkoisen palvelun vastausta ei välttämättä ole säilytetty. Myöhempi lähdekorjaus voi olla saatavilla, mutta se ei ollut voimassa tapahtumahetkellä. Ihmisen tekemässä tarkastuksessa voi olla allekirjoitettu lopputulos, mutta ei täyttä näytön tallennetta. Toiston ei tule täyttää näitä aukkoja uudella varmalla kappaleella. Sen tulee merkitä ne. Rehellinen osittainen historia on hyödyllisempi kuin täydellinen fiktio.

Toisto ei myöskään ole sama asia kuin uudelleengenerointi. Kun nykyistä järjestelmää pyydetään vastaamaan vanhaan kysymykseen, se voi osoittaa, miten järjestelmä toimii tänään. Se ei todista, miten järjestelmä toimi silloin. Uusi tulos voi käyttää eri mallia, lähdettä, politiikkaa, kehotetta, reitityspäätöstä tai kieliesitystä. Se voi olla arvokas vertailukohta, edellyttäen että tallenne kertoo sen olevan vertailu. Myöhempi analyysi ei saa esiintyä aikalaisperusteena.

Toisto on todisteikkuna. Se näyttää, mitä voidaan palauttaa, mikä muuttui ja minne korjaus voi vielä kulkea.

Toistettava historia muuttaa valituksen laatua. Kysymys lakkaa olemasta miksi organisaatio uskoo tämän tapahtuneen, ja siitä tulee mitkä osat historiasta voimme varmistaa. Se on terveempi lähtökohta. Se antaa instituutiolle luvan sanoa, että tallenne on täydellinen säännön ja lopputuloksen osalta mutta epätäydellinen ulkoisen vastauksen osalta. Se antaa tarkastajalle keinon päättää, onko puuttuva osa olennainen. Se antaa insinööreille tarkan vian korjattavaksi sen sijaan, että he saisivat epämääräisen pyynnön lisää läpinäkyvyydestä.

Läpinäkyvyydellä on rajat, ei tekosyitä

Oikeus tietää, mikä on muuttunut, ei tarkoita oikeutta saada kaikki sisäiset asiakirjat raakamuodossa. Julkisyhteisöillä on edelleen velvollisuus suojella henkilötietoja, turvallisuuden kannalta arkaluonteisia tietoja, luottamuksellisia liiketoimintatietoja ja tutkintojen koskemattomuutta. Yksityiskohtainen historia voi paljastaa toisen henkilön tietoja tai helpottaa valvonnan kiertämistä. Hyödyllinen julkinen selvitys voi siksi olla kerroksellinen asiakirja: selkeä kuvaus sovellettavasta säännöstä ja aikataulusta, viittaus tarkastettavissa olevaan näyttökokonaisuuteen sekä hallittu reitti syvempään tarkasteluun.

Kerroksellisuus toimii vain, jos syvempi asiakirja on olemassa. Tietojen poistaminen ei korvaa alkuperäisen säilyttämistä. Jos laitos julkaisee yhteenvedon ja hävittää aineiston, jonka avulla valtuutettu tarkastaja voisi testata sitä, yhteenvedosta tulee pysyvä väite. Yleisöllä ei välttämättä ole oikeutta jokaiseen liitteeseen, mutta jonkun, jolla on asianmukainen rooli, on voitava tutkia perusta. Käyttöoikeuksien hallinta voi rajoittaa sitä, kuka näkee asiakirjan. Se ei voi tehdä olemattomasta asiakirjasta turvallista.

Läpinäkyvyyden merkityksen ympärillä on toinen raja. Versiotunniste ei ole selitys. Sen osoittaminen, että malli on muuttunut, ei kerro asianomaiselle, olisiko muutos voinut vaikuttaa lopputulokseen. Käytäntöeron näyttäminen ei kerro, mitä osaa sovellettiin. Hyvät selitykset yhdistävät muutoksen toimenpiteeseen, kertovat, mitä käytettiin, ja ilmaisevat, mitä oikeussuojakeinoa on saatavilla. Tarkoitus ei ole saada laitosta näyttämään teknisesti sivistyneeltä. Tarkoitus on antaa henkilön ymmärtää asemansa.

Julkiset rekisterit voivat auttaa tekemällä tärkeät järjestelmän tilat näkyviksi ennen kuin jonkun on pakko kysyä. AI-asetus sisältää rekisteröinti- ja dokumentointivelvoitteita määritellyissä yhteyksissä, kun taas kansallinen arkistokäytäntö käsittelee saatavuutta ja tulevaa käytettävyyttä osana asiakirjahallintaa. Nämä mekanismit eivät korvaa tapauskohtaista historiaa. Ne ovat ympäröivä kartta. Kartta on arvokas, mutta sitä ei pidä sekoittaa siihen tiehen, jota tietty henkilö kulki.

Kysely saapuu käyttöliittymän muututtua

Oikeusasiamiehen vuonna 2024 tekemä kysely komission tekoälyn käytöstä on hyvä esimerkki kysymyksestä, jonka kanssa laitokset kohtaavat yhä useammin. Julkinen kuvaus kysyy, miten komissio päättää käyttää tekoälyä, mitkä tehtävät automatisoidaan, miten päätös tekoälyn käytöstä tehdään ja miten vastuuvelvollisuus säilytetään. Se ei oleta, että algoritmin tuotos on koko päätös. Se kysyy järjestelmää ympäröivästä hallinnollisesta valinnasta.

Myös sillä valinnalla on historia. Laitos voi aloittaa kokeilulla, määritellä tarkoituksen, rajoittaa roolin, vaihtaa lähteen, laajentaa työmäärää, muuttaa tarkastusreittiä ja julkaista myöhemmän selityksen. Jos asiakirja sisältää vain nykyisen käytännön ja nykyisen käyttöliittymän, tarkastajan on pääteltävä aikaisempi raja. Laitos voi toimia vilpittömässä mielessä eikä silti pystyä osoittamaan, mitä se tiesi, hyväksyi tai salli tuolloin. Vilpitön mieli on arvokas ominaisuus. Se ei ole aikakone.

Kyselyt osoittavat myös, miksi asiakirjahallintaan on sisällytettävä epäviralliset kanavat. Päätöksiin voivat vaikuttaa työasiakirjat, viestit, ongelmaseurannat, kokoonpanotarkastukset ja keskustelut, joista ei koskaan tule virallista käytäntöä. Jokaista virkettä ei tarvitse säilyttää pysyvästi. Organisaatio tarvitsee kuitenkin säännön sen tunnistamiseen, mitkä viestit sisältävät institutionaalisen toimen tai sitoumuksen, ja tavan säilyttää tämä aineisto, kun sen merkitys käy selväksi. Muuten historia alkaa ensimmäisestä viimeistellystä asiakirjasta, kun tärkeä valinta on jo tehty.

Ratkaisu ei ole muuttaa julkishallintoa oman henkilökuntansa valvonta-arkistoksi. Ratkaisu on tehdä työn kannalta merkityksellinen tila näkyväksi. Päätöksellä tulisi olla omistaja, peruste, soveltamisala, voimaantulopäivä ja kirjaus muutoksesta, joka teki siitä erilaisen. Epävirallinen keskustelu voi pysyä keskusteluna. Kun se muuttaa toimivaltaa, tietoja, käytäntöä tai toimintaa, asiaankuuluva tulos kuuluu institutionaaliseen asiakirja-aineistoon.

AI tekee vanhoista selityksistä erityisen hauraita

Tuotetut selitykset aiheuttavat erityisen riskin, koska ne ovat niin sujuvia, että ne piilottavat ajoituksensa. Järjestelmä voi tuottaa järkevän kuvauksen vanhasta päätöksestä käyttämällä nykyistä mallia ja käytäntöä. Kuvaus ei välttämättä sisällä yhtään ilmeisen väärää lausetta. Se voi silti olla väärä tallenteena, koska selitystä ei ollut olemassa päätöksen tekohetkellä eikä se ollut johdettu tilasta, joka tuotti päätöksen.

Turvallisin erottelu on samanaikaisen todistusaineiston ja myöhemmän tulkinnan välillä. Samanaikainen tallenne kertoo, mitä järjestelmä vastaanotti, mikä versio toimi, mikä tulos tuotettiin, mitä ihminen teki ja mikä ilmoitus lähetettiin. Myöhempi analyytikko voi lisätä rekonstruktion, kontrafaktuaalin, vertailun nykyiseen toimintaan tai arvion siitä, olisiko säännön pitänyt olla erilainen. Nämä lisäykset ovat arvokkaita, kun ne merkitään myöhemmäksi työksi. Niistä tulee vaarallisia, kun merkintä katoaa.

Luottamusluvuilla on sama ongelma. Luku ilman kalibrointiaan, populaatiotaan, kynnysarvoaan ja tarkoitustaan ei selitä itseään. Luku on voinut olla hyödyllinen huomion priorisoinnissa, eikä sitä ole koskaan valtuutettu lopulliseen toimenpiteeseen. Se on voitu näyttää arvioijalle tai piilottaa käyttöliittymän taakse. Se on voitu kalibroida uudelleen tapahtuman jälkeen. Luvun säilyttäminen mutta ehtojen menettäminen säilyttää todisteen muodon ja poistaa sen merkityksen.

Siksi versiohistorian tulisi sisältää selitysmallit ja lähdenäkymät, kun ne vaikuttavat ihmisen päätökseen. Sanamuoto ei ole pelkkä viestintäkerros, jos se kertoo arvioijalle, miksi järjestelmä suosittelee toimenpidettä. Todisteiden järjestyksellä voi olla merkitystä. Varoituksen puuttumisella voi olla merkitystä. Käytettävissä olevien painikkeiden joukolla voi olla merkitystä. Julkiseen päätökseen vaikuttaa se, mitä ihmiset voivat nähdä ja tehdä, ei vain piilotettu laskenta.

Tietojen korjaus on historian tärkein tehtävä

Jokainen hallinnollinen järjestelmä oppii lopulta, että lähdetietue voi olla väärä. Osoite korjataan, luokka luokitellaan uudelleen, maksu peruutetaan, mittaus lasketaan uudelleen tai henkilö toimittaa puuttuvia tietoja. Korjaus voi parantaa nykyistä tietuetta ilman, että se automaattisesti korjaa päätöksiä, jotka riippuivat aiemmasta arvosta. Tämä toinen tehtävä edellyttää linkkiä lähdehistoriasta vaikuttaviin päätöksiin.

Ilman tätä linkkiä laitoksella on kaksi huonoa vaihtoehtoa. Se voi käydä kaiken uudelleen läpi, mikä on kallista ja voi altistaa ihmisiä, joihin ei koskaan vaikutettu. Tai se voi olla käymättä mitään uudelleen läpi, jolloin tunnettu virhe jää voimaan kaikille, joiden päätös riippui siitä. Versioidut viittaukset mahdollistavat rajatumman kysymyksen: mitkä päätökset kuluttivat tämän tilan, minkä säännön mukaan ja millä seurauksella. Vastaus voi ohjata oikeasuhtaista tarkastelua.

Sama logiikka koskee lainsäädännön ja politiikan muutoksia. Uusi sääntö voi olla oikea uusille tapauksille tekemättä jokaista vanhaa lopputulosta vääräksi. Tuomioistuimen tulkinta voi edellyttää uutta tarkastelua päätöksille, jotka tehtiin aiemman ymmärryksen mukaan. Korjausprosessin on tiedettävä, milloin vanha sääntö oli voimassa, mihin tapauksiin se ulottui ja onko korjaustoimenpide uudelleen avaaminen, ilmoitus, korvaus, selitys vai ei mitään. Historia muuttaa moraalisen kysymyksen toiminnallisesti vastattavaksi kysymykseksi vähentämättä moraalista kysymystä kyselyksi.

Korjauksen tulisi myös jättää oma jälkensä. Organisaation tulisi tallentaa, mitä löydettiin, mitä tapauksia harkittiin, mitä toimenpiteitä tehtiin ja miksi jotkut tapaukset jäivät soveltamisalan ulkopuolelle. Tämä tallenne suojaa asianomaista henkilöä ja laitosta. Se estää saman ongelman hiljaisen uudelleenlöytämisen jokaisen uuden arvioijan toimesta. Korjaus ilman tallennetta on anteeksipyyntö, joka ei muista, ketä se auttoi.

Ihmisen tekemä tarkastelu tarvitsee myös version

Ihmisen valvontaa kuvataan usein niin, kuin ihmisen läsnäolo yksinään tekisi päätöksestä vakaan. Näin ei ole. Arvioija toimii aina kontekstissa: asiakirjojen, näytön, jonon, määräajan, roolin, toimintaohjeen, hälytyksen ja käytettävissä olevien toimintojen keskellä. Jos konteksti muuttuu, myös arvioijan hyväksynnän merkitys voi muuttua. Pelkän nimen ja aikaleiman tallentaminen ei kunnioita arvioijaa eikä päätöksen kohteena olevaa henkilöä.

Ihmisen tekemän arvioinnin versiointi ei edellytä jokaisen ajatuksen tallentamista. Se edellyttää riittävästi kontekstia, jotta teon auktoriteetti ja näyttö käyvät ilmi. Mitkä aineistot esitettiin. Mitkä jätettiin pois tai eivät olleet saatavilla. Oliko tulos ehdotus, vaatimus vai käynnistävä tekijä. Pystyikö arvioija ohittamaan sen. Oliko etenemispolku näkyvissä. Lisäsikö arvioija perustelun. Sovellettiinko toimintoa vai laadittiinko se vain. Nämä kentät luovat arviointipäätöksestä tallenteen ilman, että arviointia teeskennellään koneellisesti luettavaksi luvuksi.

Tämä erottelu suojelee työntekijöitä. Jos organisaatio odottaa arvioijien vastaavan lopputuloksesta, sen ei pitäisi myöhemmin arvioida heitä eri käyttöliittymän ja eri näytön perusteella. Se suojelee myös kansalaisia. Päätöstä riitauttavan henkilön ei pitäisi kuulla, että nimetön ihminen oli mukana prosessissa, ja sitten huomata, että tämä ihminen pystyi ainoastaan klikkaamaan hyväksy-painiketta. Valvonta on merkityksellistä silloin, kun tallenne osoittaa, mitä henkilö sai tehdä ja mitä tapahtui, kun hän oli eri mieltä.

Kulttuurinen hyöty on myös olemassa. Kun erimielisyys tallennetaan normaalina osana työnkulkua, siitä tulee oppimisen lähde eikä merkki epälojaaliudesta. Organisaatiot voivat tutkia, keskittyvätkö ohitukset tieto-ongelman, toimintatavan epäselvyyden vai käyttöliittymän aiheuttaman paineen ympärille. Ne voivat parantaa järjestelmää syyttämättä ihmisiä, jotka huomasivat järjestelmän olevan väärässä. Historia antaa erimielisyydelle muun paikan kuin käytävän.

Muisti ilman hamstrausta

Kun organisaatio ymmärtää historian tarpeen, kiusaus on säilyttää kaikki. Jokainen kehote, kuvakaappaus, ominaisuuden arvo, viesti, tallenne, vienti ja väliaikaistiedosto säilytetään ikuisesti varmuuden vuoksi. Se ei ole vastuullisuutta. Se on arkisto, joka on unohtanut miksi se on olemassa. Se lisää yksityisyyden riskejä, nostaa tietoturvakustannuksia ja vaikeuttaa olennaisen näytön löytämistä.

Säilytysajan tulisi seurata seurauksia, lainsäädännöllistä tarvetta ja oikeussuojan mahdollisuutta. Laajavaikutteinen päätös voi vaatia kattavamman näyttökokonaisuuden ja pidemmän suojeluajan. Vähäriskisestä luonnoksesta voi riittää tiivis kuittaus. Arkaluonteiseen sisältöön voidaan viitata tunnisteella ja säilyttää se rajoitetussa järjestelmässä. Johdettu esitys voi vanhentua, kun taas tieto sen olemassaolosta ja poiston syystä säilyy. Suunnittelussa tulee määritellä, mitä säilytetään, kenellä on siihen pääsy, miten sitä korjataan ja milloin se tuhotaan.

Valikoiva muisti on helpompi perustella, kun tallenne on jäsennelty. Vakaat tunnisteet voivat yhdistää päätöksen lähteeseen kopioimatta henkilötietoja jokaiseen lokiin. Voimassaolojaksot voivat estää nykyisen arvon lukemisen menneenä arvona. Syykoodit voivat tehdä korjauksesta löydettävän säilyttämättä yksityistä keskustelua. Eheystarkistus voi osoittaa, ettei tallennetta ole muutettu, paljastamatta sen sisältöä kaikille kysyjille. Hyvä tietosuoja näyttää usein hyvältä suunnittelulta, koska molemmat tieteenalat karttavat epämääräisyyttä.

Ilmauksen versiohistoria sisään ei ole kätkettynä yhtä yleispätevää säilytysaikaa. Säilytysaika riippuu tehtävästä, toimialasta, muutoksenhakutiestä, sopimusvelvoitteista ja laista. Yleispätevää tulisi olla vaatimus päättää asiasta harkiten. Jos organisaatio ei osaa sanoa, miksi jokin osa on säilytettävä, se ei ehkä ymmärrä sen roolia päätöksessä. Jos se ei osaa sanoa, miksi jokin osa voidaan poistaa, se saattaa säilyttää riskiä eikä näyttöä.

Historian suunnittelu ilman teatteria

Hyödyllinen toteutus alkaa kysymyksistä, ei kentistä. Mitä päätöstä saatetaan haastaa. Mitkä versiot voisivat muuttaa sen merkitystä. Kuka niitä tarvitsee tarkastettavaksi. Mikä on varhaisin hetki, jolloin tietue voidaan sinetöidä. Mikä on pienin todisteaineisto, jonka avulla tarkastaja voi testata asiaankuuluvan väitteen. Mitkä muutokset tulisi käynnistää uudelleen tarkastukselle. Mitkä tapahtumat on oltava ihmisen nähtävissä ja mitkä ovat toiminnallista yksityiskohtaa.

Vastaukset johtavat yleensä muutamaan kestävään malliin. Anna jokaiselle käytännölle, mallille, lähdemääritelmälle ja työnkulun julkaisulle vakaa tunniste. Kirjaa voimassaoloajat erikseen julkaisu- ja käyttöönottoajoista. Liitä päätös käytettyihin tarkkoihin tunnisteisiin sen sijaan, että liität sen siihen, mikä on voimassa silloin, kun joku avaa asian. Säilytä ihmisen luettavissa oleva kuvaus koneellisesti luettavien viitteiden rinnalla. Tee muutoksista historian liitteitä tai luo uusi muuttumaton tila. Jos korjaus korvaa aiemman arvon, säilytä näiden kahden välinen suhde.

Testaa historiaa toiminnallisena ominaisuutena. Ota tunnettu päätös ja pyydä insinööriä, käytännön omistajaa ja riippumatonta tarkastajaa rekonstruoimaan se. Päätyvätkö he samaan tilaan. Pystyvätkö he kertomaan, mikä on vahvistettua ja mikä puuttuu. Pystyvätkö he tunnistamaan, kenellä oli toimivalta. Pystyvätkö he löytämään päätökset, joihin lähdekorjaus vaikuttaa. Pystyvätkö he selittämään, miksi nykyinen toisto eroaa, syyttämättä menneisyyttä oletusarvoisesti vääräksi. Järjestelmä, joka läpäisee vain skeematestin, pitää siistiä kirjaa. Järjestelmä, joka läpäisee tarkastustestin, voi olla vastuullinen.

Harjoittele lopuksi muutosta. Korvaa sääntö testiympäristössä, päivitä lähdemääritelmä, rullaa mallipaketti, poista käyttöoikeus ja korjaa tietue. Tarkasta sitten historia. Näkyykö siitä siirtymä, sen laajuus ja sen omistaja. Voiko valtuutettu tarkastaja edelleen lukea vanhan tilan. Osoittaako alavirran päätös oikeaan versioon. Jos vastaus on ei, järjestelmä luottaa siihen, että tuleva poikkeama opettaa sille versiohallinnan. Tulevat poikkeamat ovat kalliita opettajia.

Mitä julkinen muutosloki ei voi kertoa sinulle

Julkinen muutosloki voi kertoa, että kynnysarvoa tarkistettiin, mallia päivitettiin tai työnkulkua parannettiin. Se ei voi kertoa henkilölle, koskiko muutos hänen asiaansa, ellei päätöstietue tee yhteyttä näkyväksi. Se voi kertoa, milloin julkaisu tuli saataville. Se ei voi kertoa sinulle, saiko jokin alue sen myöhemmin. Se voi kertoa, että vika korjattiin. Se ei voi kertoa, mitkä aiemmat tulokset tarkistettiin uudelleen. Muutoslokit ovat hyödyllisiä juuri siksi, että ne ovat valikoivia. Todisteet ovat hyödyllisiä, kun niiden valintasääntö on näkyvissä.

Erottelu on tärkeää myös demokraattisen valvonnan kannalta. Julkinen toimielin voi julkaista mallirekisterin ja yleisen kuvauksen tarkoituksesta. Parlamentti, tuomioistuin, tilintarkastaja tai oikeuttaan käyttävä henkilö voi silti tarvita tietoa siitä, mitä tiettynä päivänä tapahtui. Rekisteri antaa yhteiskunnalle näkymän maisemaan. Päätöshistoria antaa henkilölle reitin sen läpi. Molempia tarvitaan. Ensimmäinen on julkista tietoa. Toinen on institutionaalista muistia, joka voi vastata teosta.

Muutoslokin esittämisessä vastuullisuutena on hiljainen vaara, koska se palkitsee julkaisijan näkökulman. Julkaisija valitsee, mikä on olennaista, käyttää nykyistä sanastoa ja kuvaa aiottua vaikutusta. Järjestelmän vaikutuspiirissä oleva henkilö aloittaa muualta. Hän kysyy, mikä sääntö koski minun hakemustani, mitä todisteita harkittiin, oliko järjestelmän rooli toimivaltansa rajoissa ja mitä voin tehdä nyt. Tietueen on kyettävä vastaamaan tähän kysymykseen, vaikka vastaus olisi epämukava.

Hyvä julkinen muutosrekisteri toimii siis kahteen suuntaan. Se selittää muutokset kansalaisille selkeällä kielellä ja antaa valtuutetuille tarkastajille reitin tapauskohtaiseen näyttöön. Se kertoo, mitä muutos ei muuttanut. Se merkitsee myöhemmät korjaukset. Se linkittää politiikan, järjestelmän ja toiminnan omistajiin. Se ilmoittaa, milloin rekisteri on puutteellinen. Luottamusta ei synny teeskentelemällä, että jokainen historia on saumaton. Se syntyy, kun saumat ovat näkyvissä ja joku vastaa niistä.

Pieni panoksemme kysymykseen

Dwevessä palaamme jatkuvasti tähän erotteluun, koska oma Ledger-työmme käsittelee toimintahistoriaa tyypitettynä, toistettavana rekisterinä eikä kasana haettavia viestejä. Työmme toimintarekisterien parissa seuraa samaa kysymystä: mikä säilytetään historiana ja mikä johdetaan nykytilaksi. Nämä ovat teknisiä valintoja, eivät todiste siitä, että julkinen laitos tai toimittaja on täyttänyt velvoitteensa. Laajempi opetus kuuluu kaikille vastuullisia järjestelmiä rakentaville: pidä rekisteri lähellä tapahtumaa, pidä sen laajuus rehellisenä äläkä anna nykytilan hiljaa esiintyä menneisyytenä.

Tämä on pieni kappale paljon suuremmassa argumentissa. Argumentti ei riipu Dweven tuotteesta. Se on jo läsnä eurooppalaisessa asiakirjahallinnossa, tietosuojan vastuuvelvollisuudessa ja tekoälyasetuksen elinkaarivaatimuksissa. Olemme kiinnostuneita ongelmasta, koska ohjelmistot tekevät unohtamisesta helppoa ja julkiset päätökset tekevät unohtamisesta seurauksellista. Oikea vastaus ei ole lisätä logomme sanan läpinäkyvyys viereen. Se on tehdä historiasta tarkastettavaa, rajattua ja hyödyllistä sille, jonka on elettävä lopputuloksen kanssa.

Kansalaisen kysymys on yleensä menneessä aikamuodossa

Miksi tämä päätös tehtiin. Mitä sääntöä sovellettiin. Mitä tietoja käytit. Tarkastiko ihminen sen. Mitä muuttui sen jälkeen. Nämä ovat menneen aikamuodon kysymyksiä. Niitä esittävät kansalaiset, potilaat, työntekijät, opiskelijat, asiakkaat, toimittajat, tilintarkastajat, tuomioistuimet ja henkilökunta, joka perii järjestelmän, jota he eivät ole suunnitelleet. Nykytilan kojelauta voi osoittaa, että järjestelmä toimii. Se ei voi vastata eilisen päätöksestä, jos eilinen on ylikirjoitettu.

Vastaus ei edellytä, että laitos säilyttää kaiken ikuisesti tai julkaisee jokaisen sisäisen rekisterin. Se edellyttää, että laitos tietää, mitkä tosiasiat tekevät päätöksestä ymmärrettävän, säilyttää nämä tosiasiat tarkastettavassa muodossa ja ilmoittaa selvästi, milloin tosiasiaa ei voida palauttaa. Tämä on versiohistorian vaatimaton lupaus. Se ei tee päätöksestä oikeaa. Se tekee päätöksestä vastuullisen.

Eurooppalainen arkistokäytäntö on sanonut tämän tavallisella kielellä: tärkeällä tiedolla voi olla historiallisia versioita, ja digitaalinen tieto on tietoa riippumatta siitä, missä sitä säilytetään. Eurooppalainen tietosuojalainsäädäntö sanoo, että vastuuvelvollisuuteen kuuluu kyky osoittaa vaatimustenmukaisuus. Tekoälyasetus sisällyttää teknisen dokumentaation ja elinkaarilokituksen velvoitteisiin tietyille korkean riskin järjestelmille. Oikeusasiamiehen kysymykset julkisen sektorin tekoälystä osoittavat samaan suuntaan. Laitoksia arvioidaan paitsi sen perusteella, mitä ne ottavat käyttöön, myös sen perusteella, mitä ne voivat osoittaa valinnastaan.

Joten pidä muutosloki. Kirjoita julkaisutiedote. Julkaise rekisteri. Rakenna sitten vähemmän loistokas rekisteri sen alle: sellainen, joka tietää, mikä lähde, sääntö, järjestelmä, työnkulku ja toimivalta olivat voimassa, kun henkilön asia siirtyi mahdollisuudesta päätökseksi. Jos organisaatio voi osoittaa, mikä muuttui, se voi osoittaa myös, mikä ei muuttunut, mitä opittiin ja mitä voidaan vielä korjata. Tämä ei ole arkistonomantaa. Se on vähimmäismuisti, jota julkinen valta tarvitsee pysyäkseen vastuullisena.

Lähteet