
Luottamusta ei pidä maksimoida. Se on ansaittava, osoitettava näytöllä ja kalibroitava jatkuvasti.
Lähes jokainen teknologiayritys väittää rakentavansa luottamusta. Jo ilmaus ”luota meihin” paljastaa kuitenkin taustalla olevan ongelman: se pyytää luottamusta ennen kuin sille on annettu riittävät perusteet. Ohjelmistotoimittaja voi väittää, että asiakastiedot ovat turvassa. Asiakas voi uskoa väitteen ja päättää luottaa toimittajaan. Se, onko toimittaja todella luotettava, on kuitenkin eri kysymys. Vain näyttö toteutetuista tietoturvakontrolleista, niiden vaikuttavuudesta, kattavuudesta ja jatkuvasta toiminnasta voi antaa rationaalisen perustan tälle luottamukselle. Juuri tässä käsitteet kuten luottamus, luotettavuus, varmuus (assurance), nojautuminen (reliance), vaatimustenmukaisuus, digitaalinen luottamus ja Zero Trust sekoittuvat usein toisiinsa. Ne kuvaavat kuitenkin saman ongelman eri puolia.
Näiden erojen ymmärtäminen auttaa vastaamaan paljon laajempaan kysymykseen:
Mitä luottamuksen pitäisi tarkoittaa digitaalisessa maailmassa, jossa järjestelmät, organisaatiot ja riskit muuttuvat jatkuvasti?
Organisaatio- ja psykologisessa tutkimuksessa luottamus liitetään yleisesti valmiuteen hyväksyä haavoittuvuus. Rousseau ym. kuvaavat luottamusta psykologisena tilana, johon sisältyy aikomus hyväksyä haavoittuvuus toisen osapuolen aikeita tai käyttäytymistä koskevien myönteisten odotusten perusteella [1]. Mayer, Davis ja Schoorman määrittelevät luottamuksen samaan tapaan valmiudeksi olla haavoittuvainen toisen osapuolen suhteen silloinkin, kun tätä osapuolta ei voida täysin valvoa tai kontrolloida [2]. (ResearchGate) Luottamus edellyttää siis vähintään kahta ehtoa: on oltava epävarmuutta, ja jotain merkityksellistä on oltava pelissä.
Kun lopputulos on täysin varma, luottamusta ei tarvita. Kun mahdollista menetystä tai riippuvuutta ei ole, se, mikä näyttää luottamukselta, voi olla pelkkää mukavuutta. Luottamus tulee merkitykselliseksi, kun olemme riippuvaisia toisesta ihmisestä, organisaatiosta tai järjestelmästä ja tämä riippuvuus tekee meistä haavoittuvaisia. Tämä tarkoittaa myös, että luottamus ei ole koskaan pelkästään jonkin toimijan yleinen ominaisuus. Täsmällisempi muotoilu olisi:
A luottaa B:hen asian X osalta olosuhteissa Y tiettynä ajankohtana.
Yritys voi luottaa pilvipalveluntarjoajaan julkisen markkinointimateriaalin tallentamisessa, mutta se ei automaattisesti luota samaan toimittajaan erittäin arkaluonteisten terveystietojen käsittelyssä. Järjestelmä voi olla riittävän luotettava yhteen käyttötarkoitukseen ja täysin sopimaton toiseen. Luottamus on siksi suhteellista, kontekstisidonnaista ja riskistä riippuvaa.
Arkikielessä sanoja ”luotettu” ja ”luotettava” käytetään usein synonyymeinä. Käsitteellisesti ne kuitenkin kuvaavat kahta eri asiaa. Luotettu tarkoittaa, että toimijalle todella annetaan luottamusta. Luotettava tarkoittaa, että toimija ansaitsee tämän luottamuksen. Vakuuttavaan huijariin voidaan luottaa, vaikka hän ei ole luotettava. Toisaalta huolellisesti suunniteltu ja hyvin hallittu järjestelmä voi olla luotettava mutta jäädä silti vaille käyttäjien luottamusta, koska sen kyvyt, kontrollit ja rajoitukset jäävät näkymättömiin. Mayer ym. nimeävät kolme laajasti käytettyä koetun luotettavuuden ulottuvuutta: kyvykkyys, rehellisyys (integrity) ja hyväntahtoisuus [2].
Kyvykkyys tarkoittaa sitä, onko luotettu osapuoli riittävän pätevä suorittamaan kyseisen tehtävän. Rehellisyys tarkoittaa sitä, ovatko sen lausumat, periaatteet ja todellinen toiminta johdonmukaisia. Hyväntahtoisuus tarkoittaa sitä, odotetaanko sen ottavan huomioon luottavan osapuolen edut sen sijaan, että se tavoittelisi yksinomaan omaa etuaan. (JSTOR) Teknisissä järjestelmissä nämä ulottuvuudet on käännettävä uuteen muotoon. Kyvykkyydestä tulee tekninen suorituskyky, luotettava toiminta, häiriönsietokyky ja tietoturva. Rehellisyydestä tulee ennustettava käyttäytyminen, johdonmukaiset säännöt, jäljitettävä käsittely ja totuudenmukainen viestintä rajoituksista. Hyväntahtoisuutta ei voi yksinkertaisesti liittää koneeseen. Sitä voidaan kuitenkin arvioida suhteessa organisaatioon, joka kehittää ja ylläpitää järjestelmää: Suojaako organisaatio käyttäjien etuja? Viestiikö se riskeistä rehellisesti? Tarjoaako se mekanismeja vastuuvelvollisuuteen ja oikeussuojaan?
NIST lähestyy luotettavuutta järjestelmäsuunnittelun näkökulmasta. Luotettava järjestelmä ei ole pelkästään sellainen, johon ihmiset sattuvat luottamaan. Sen luotettavuuden on perustuttava näyttöön siitä, että se pystyy täyttämään sille asetetut kriittiset vaatimukset. Kontekstista riippuen näitä vaatimuksia voivat olla tietoturva, turvallisuus, toimintavarmuus, häiriönsietokyky, yksityisyys tai muut järjestelmän ominaisuudet [3]. Tämä ero on perustavanlaatuinen:
Luottamus on olemassa luottavan osapuolen mielessä. Luotettavuus on olemassa luotetun toimijan ominaisuuksissa ja käyttäytymisessä.
Nämä kaksi voivat olla linjassa, mutta ne eivät ole sitä automaattisesti.
Toinen tärkeä ero on luottamuksen ja nojautumisen välillä. Luottamus on asenne, odotus tai arvio. Nojautuminen on havaittavaa käyttäytymistä. Ihminen voi epäillä tekoälyjärjestelmää ja silti noudattaa sen suositusta, koska vaihtoehtoa ei ole, koska aikapaine on kova tai koska organisaation prosessi sitä edellyttää. Toisaalta ihminen voi yleisesti luottaa järjestelmään mutta tietoisesti jättää sen suosituksen huomiotta yksittäisessä tapauksessa. Ero on tärkeä, koska kyselyt, joissa käyttäjiltä kysytään, luottavatko he järjestelmään, eivät välttämättä ennusta, milloin nämä käyttäjät nojautuvat siihen. Tuoreessa ihmisen ja tekoälyn vuorovaikutusta koskevassa tutkimuksessa erotetaankin yhä useammin toisistaan koettu luottamus, käyttäytymisen tasolla näkyvä nojautuminen, järjestelmän suorituskyky ja tuloksena syntyvän päätöksen asianmukaisuus [8]–[10]. (ACM Digital Library)
Myöskään vaatimustenmukaisuus ei ole sama asia kuin luotettavuus. Vaatimustenmukaisuus vastaa aluksi suppeampaan kysymykseen:
Onko määritelty joukko vaatimuksia täytetty määritellyssä soveltamisalassa?
Sertifiointi, tarkastusraportti tai arviointi voi antaa tärkeän syyn luottamukselle. Se ei kuitenkaan ole rajoittamaton ja pysyvä lausunto siitä, että organisaatio on turvallinen. Tarkastus voi vahvistaa, että tietty hallintajärjestelmä on toteutettu asianmukaisesti tietyssä soveltamisalassa ja tiettynä ajanjaksona. Se ei automaattisesti todista, että jokainen nykyinen konfiguraatio on oikein, että jokainen uusi järjestelmä on katettu tai että tietoturvapoikkeamaa ei voi tapahtua. NIST varoittaakin pitämästä vaatimustenmukaisuutta varmuuden tai luotettavuuden ainoana näyttöperustana. Vaatimustenmukaisuus voi tuottaa arvokasta näyttöä, mutta pelkkään vaatimustenmukaisuuteen nojaava lähestymistapa voi luoda vaikutelman turvallisuudesta osoittamatta riittävästi taustalla olevan järjestelmän vaikuttavuutta [3]. (NIST Publikationen)
Vaatimustenmukaisuudella on merkitystä. Mutta se on yksi perustellun luottamuksen osatekijä, ei sen täydellinen korvike.
Osapuolen subjektiivisen luottamuksen ja järjestelmän todellisen luotettavuuden välissä on vielä yksi käsite: varmuus (assurance). NIST kuvaa varmuutta perusteina perustellulle luottamukselle siihen, että väite on täytetty tai tullaan täyttämään [3]. Varmuus ei siis ole tunne eikä takuu. Se on jäsennelty perustelu. Vahvan varmuusrakenteen tulisi tuoda näkyviin vähintään viisi osaa: Väitteet: Mitä tarkalleen väitetään? Argumentit: Miksi käytettävissä olevan tiedon pitäisi tukea väitettä? Näyttö: Mitkä tallenteet, havainnot, testit tai artefaktit osoittavat toteutuksen ja vaikuttavuuden?
Oletukset: Millä ehdoilla johtopäätös pysyy pätevänä? Soveltamisala: Mitkä järjestelmät, prosessit, tiedot, sijainnit ja ajanjaksot ovat mukana? NIST käyttää käsitettä varmuusperustelu (assurance case) kuvaamaan väitteiden, argumenttien, oletusten ja tukevan näytön välistä jäsenneltyä ja tarkastettavissa olevaa suhdetta [3]. Tarkastellaan seuraavaa tietoturvaväitettä:
Kaikki tuotantodata on salattu levossa.
Yrityksen salauspolitiikka osoittaa, että tavoite ja vaatimus ovat olemassa. Se ei todista, että jokainen tuotannon tallennusjärjestelmä todella toteuttaa vaatimuksen. Yhden tietokannan konfiguraatiosta otettu kuvakaappaus on näyttöä kyseisestä tietokannasta tiettynä hetkenä. Se ei välttämättä osoita täydellistä kattavuutta. Vahvempi varmuusperustelu voisi yhdistää:
Eri näyttömuodot palvelevat eri tarkoituksia. Politiikka tukee suunniteltua toteutusta. Konfiguraatio tukee teknistä toteutusta. Testi tai jatkuva telemetria tukee todellista toimintaa. Katselmointi tukee johtopäätöstä, että vastuullinen osapuoli on arvioinut ja hyväksynyt näytön. Mikään näistä osista ei välttämättä riitä yksinään. Varmuus syntyy alkuperäisen väitteen, katetun soveltamisalan, toteutuksen ja käytettävissä olevan näytön välisestä jäljitettävästä suhteesta. Kypsän varmuusjärjestelmän on myös kyettävä tuottamaan kielteisiä johtopäätöksiä. Sen pitäisi pystyä toteamaan, että:
NIST tunnustaa nimenomaisesti, että varmuusanalyysi voi tuottaa epäedullisia tuloksia, kun näyttö ei tue väitettä [3]. (NIST Publikationen) Järjestelmä, joka pystyy tuottamaan vain vihreitä valintamerkkejä, voi luoda mielenrauhaa. Se ei välttämättä luo uskottavaa varmuutta.
Ensi silmäyksellä Zero Trust näyttää olevan ristiriidassa sen tavoitteen kanssa, että luottamusta rakennetaan lisää. Näin ei ole. Zero Trust käsittelee ongelmaa eri tasolla. Se ei ole ensisijaisesti psykologinen tai kulttuurinen filosofia. Se on arkkitehtuurinen lähestymistapa pääsypäätöksiin. Zero Trust -mallissa luottamusta ei myönnetä pelkästään siksi, että käyttäjä tai laite on yrityksen verkossa, kuuluu organisaatioon tai on aiemmin tunnistettu. Pääsyä arvioidaan suhteessa tiettyyn resurssiin, identiteettiin, laitteeseen, kontekstiin ja pyyntöön. Käyttöoikeuksien tulisi olla rajattuja, niitä tulisi arvioida jatkuvasti uudelleen, ja ne tulisi myöntää olettaen, että verkko tai järjestelmä saattaa jo olla vaarantunut [4].
Perinteinen kehäpohjainen tietoturva tiivistää usein monimutkaisen luottamuspäätöksen yhdeksi laajaksi oletukseksi:
Yrityksen verkon sisällä tarkoittaa luotettavaa.
Zero Trust pilkkoo tämän oletuksen pienemmiksi päätöksiksi:
Saako tämä identiteetti tätä laitetta käyttäen näissä olosuhteissa käyttää tätä resurssia nyt?
Zero Trust ei siis ole luottamuksen loppu. Se on implisiittisen, laajan ja pysyvästi periytyvän luottamuksen loppu. Täsmällisempi tulkinta olisi:
Ei implisiittistä luottamusta. Ei ansaitsemattomia oikeuksia.
Organisaatiolla voi olla samanaikaisesti vahvan luottamuksen kulttuuri ja Zero Trust -arkkitehtuuri. Työntekijöiden ei tarvitse henkilökohtaisesti epäillä toisiaan vain siksi, että pääsypäätökset todennetaan teknisesti. Hyvin suunnitellut kontrollit voivat itse asiassa helpottaa ihmisten välistä luottamusta. Ne pienentävät todennäköisyyttä, että yksittäinen virhe, vaarantunut tili tai vihamielinen pyyntö johtaa rajattomaan vahinkoon. Zero Trust korvaa yhden suuren ja epämääräisen luottamusoletuksen monilla pienemmillä, kontekstisidonnaisilla, väliaikaisilla ja peruttavissa olevilla päätöksillä. Tämä sopii erittäin hyvin yhteen modernin luottamuskäsityksen kanssa.
Luotettavuus keskittyy usein tietyn organisaation, järjestelmän tai suhteen ominaisuuksiin. Digitaalinen luottamus laajentaa näkökulman koko digitaaliseen ekosysteemiin. Maailman talousfoorumi kuvaa digitaalista luottamusta odotukseksi siitä, että digitaaliset teknologiat ja palvelut sekä niitä tarjoavat organisaatiot suojaavat sidosryhmien etuja ja noudattavat asiaankuuluvia yhteiskunnallisia odotuksia ja arvoja. Sen viitekehys liittää digitaalisen luottamuksen ulottuvuuksiin kuten kyberturvallisuus, yksityisyys, läpinäkyvyys, tarkastettavuus, oikeudenmukaisuus, yhteentoimivuus, turvallisuus ja oikeussuojakeinot [5]. (World Economic Forum) ISACA puolestaan jäsentää digitaalisen luottamuksen luottamukseksi suhteiden, vuorovaikutusten ja transaktioiden eheyteen digitaalisessa ekosysteemissä, joka koostuu ihmisistä, organisaatioista, prosesseista, tiedosta ja teknologioista [6]. (ISACA)
Ekosysteemin näkökulma on tärkeä, koska digitaalisen tuotteen luotettavuus riippuu harvoin pelkästään tuotteesta itsestään. SaaS-toimittaja voi olla riippuvainen seuraavista:
Näkyvän tuotteen luotettavuus riippuu siis myös kontrolleista, oletuksista ja riippuvuuksista, jotka jäävät sen käyttäjiltä suurelta osin piiloon. Digitaalinen luottamus voidaan ymmärtää laajempana taloudellisena ja yhteiskunnallisena lopputuloksena. Luotettavuus kuvaa ominaisuuksia, jotka tekevät ekosysteemistä luottamuksen arvoisen. Varmuus toimii siltana näiden ominaisuuksien ja sidosryhmän luottamuspäätöksen välillä.
Tekoäly tekee koetun luottamuksen ja todellisen luotettavuuden välisen eron erityisen näkyväksi. Tekoälyjärjestelmä voi viestiä sujuvasti, itsevarmasti ja vakuuttavasti olematta johdonmukaisesti oikeassa. Käyttöliittymä voi viestiä läpinäkyvyyttä ja osaamista silloinkin, kun taustalla oleva malli ei ole riittävän luotettava aiottuun tehtävään. Selitykset, luottamuspisteet tai ihmismäinen kieli voivat vaikuttaa käyttäjien käsityksiin. Ne eivät automaattisesti ole näyttöä siitä, että vastaus on oikea. NIST ei siksi määrittele luotettavaa tekoälyä yhden ominaisuuden kautta. AI Risk Management Framework nimeää useita ominaisuuksia, kuten validiteetti ja toimintavarmuus, turvallisuus, tietoturva ja häiriönsietokyky, vastuullisuus ja läpinäkyvyys, selitettävyys ja tulkittavuus, yksityisyys sekä haitallisen vinouman hallinta. NIST korostaa myös, että nämä ominaisuudet ovat kontekstisidonnaisia ja voivat edellyttää kompromisseja [7].
Järjestelmä voi olla tarkka mutta epäoikeudenmukainen. Se voi olla läpinäkyvä mutta tietoturvaltaan heikko. Se voi suojata yksityisyyttä mutta olla silti epäluotettava aiottuun tarkoitukseensa. Se voi toimia keskimäärin hyvin mutta epäonnistua ennalta arvaamattomasti juuri niissä tapauksissa, joilla on eniten merkitystä. Nimitys ”luotettava tekoäly” ei saa hämärtää näitä eroja. Ihmisen ja tekoälyn vuorovaikutusta koskevassa tutkimuksessa puhutaankin yhä useammin asianmukaisesta luottamuksesta, kalibroidusta luottamuksesta ja asianmukaisesta nojautumisesta. Tavoitteena ei ole saada käyttäjiä luottamaan järjestelmään mahdollisimman paljon. Tavoitteena on auttaa käyttäjiä muodostamaan oikea käsitys järjestelmän kyvyistä ja rajoituksista ja nojautumaan siihen vain silloin, kun se on perusteltua.
Mehrotran ym. systemaattinen katsaus totesi, että kirjallisuudessa ei vieläkään ole yhtä, johdonmukaisesti sovellettua asianmukaisen luottamuksen määritelmää. Tutkimuksissa käytetään erilaisia konstruktioita ja mittareita luottamukselle, aikomuksille, nojautumiselle, koetulle kyvykkyydelle ja järjestelmän todelliselle suorituskyvylle [8]. (ACM Digital Library) Visser ym. erottavat samaan tapaan luottamuksen, epäluottamuksen ja asianmukaisen nojautumisen. Heidän katsauksensa mukaan selitettävän tekoälyn, käyttäjän luottamuksen ja asianmukaisen nojautumisen välinen empiirinen yhteys on edelleen ristiriitainen ja monissa yhteyksissä epäselvä [9]. (ScienceDirect) Raeesin ja Papangelisin vuoden 2026 esipainos väittää vielä suoremmin, että subjektiiviset luottamusmittaukset eivät automaattisesti kerro, nojautuvatko ihmiset asianmukaisesti tekoälyn suosituksiin. Koska työ on julkaistu esipainoksena, sen johtopäätöksiä on pidettävä ajankohtaisena tutkimuspanoksena eikä lopullisena konsensuksena [10]. (arXiv)
Epäluottamus ei myöskään välttämättä ole hyvän järjestelmän käytön vastakohta. Tietty skeptisyys voi kannustaa todentamaan ja havaitsemaan virheitä. Umpimähkäinen epäluottamus voi kuitenkin johtaa myös siihen, että käyttäjät hylkäävät oikeita suosituksia. Petersin, Biermeierin ja Scharlaun vuoden 2026 kokeellinen tutkimus selvitti, voisiko visuaalinen tarkkaavaisuus auttaa tunnistamaan ”tervettä epäluottamusta” ihmisen ja tekoälyn vuorovaikutuksessa. Tulokset eivät olleet ratkaisevia, ja ne havainnollistavat, kuinka vaikeaa on yhä mitata, onko luottamus ja epäluottamus kalibroitu asianmukaisesti [11]. (Frontiers) Toivottua suhdetta voidaan havainnollistaa seuraavasti:
| Todellinen luotettavuus | Käyttäjän vähäinen luottamus | Käyttäjän vahva luottamus |
|---|---|---|
| Matala | Perusteltu skeptisyys | Vaarallinen yliluottamus |
| Korkea | Aliluottamus tai tarpeeton käyttämättä jättäminen | Perusteltu, kalibroitu luottamus |
Tavoitteena ei ole yksinkertaisesti siirtää jokaista käyttäjää oikeaan alakulmaan luottamusta lisäämällä. Tavoitteena on saada koettu luottamus ja käyttäytymisen tasolla näkyvä nojautuminen vastaamaan mahdollisimman tarkasti järjestelmän todellista luotettavuutta, epäonnistumisen seurauksia ja käyttökontekstia. Heinäkuussa 2026 julkaistussa artikkelissa Busuioc ja Maggetti puoltavat siirtymää luottamuksen maksimoinnista kohti kalibroitua luottamusta. He varoittavat, että luottamus voi irrota todellisesta luotettavuudesta, kun organisaatiot tuottavat luottamuksen signaaleja sen sijaan, että ne puuttuisivat taustalla oleviin olosuhteisiin, jotka tekevät luottamuksesta perusteltua. Heidän analyysinsa korostaa myös haavoittuvuutta, vastuuvelvollisuutta ja epäluottamuksen rakentavaa roolia [12]. (OUP Academic)
EU:n tekoälysäädös noudattaa samansuuntaista toiminnallista logiikkaa. Asiaankuuluvien suuririskisten järjestelmien osalta se edellyttää prosesseja ja dokumentaatiota, jotka koskevat riskienhallintaa, datanhallintaa, teknistä dokumentaatiota, lokitietojen tallentamista, läpinäkyvyyttä, ihmisen suorittamaa valvontaa, tarkkuutta, vakautta ja kyberturvallisuutta [13]. Nämä vaatimukset eivät todista, että jokainen sääntelyn piiriin kuuluva tekoälyjärjestelmä on luotettava. Ne kuitenkin pyrkivät muuntamaan abstraktin luotettavuusodotuksen konkreettisiksi hallintotoimiksi ja tarkastettavissa olevaksi näytöksi. (EUR-Lex) Luotettava tekoäly ei siis ole käyttöliittymätyyli tai markkinointinimike. Se on jatkuva hallinto- ja varmuuskysymys.
Secanilla emme ymmärrä luottamusta tunteena, jota pitäisi yksinkertaisesti vahvistaa. Emme myöskään määrittele sitä ehdottomaksi varmuudeksi. Ehdotonta turvallisuutta ei ole todellisissa digitaalisissa järjestelmissä. Vahvakaan näyttö ei voi taata, ettei vikaa tai hyökkäystä koskaan tapahdu. Näyttö vähentää epävarmuutta ja tukee parempia päätöksiä, mutta se ei poista riskiä. Jos kaikki epävarmuus voitaisiin poistaa, luottamusta ei enää tarvittaisi. Siksi puhumme tietoisesti perustellusta luottamuksesta, emme varmuudesta. Määritelmämme on:
Luottamus on perusteltua, kontekstisidonnaista vakuuttuneisuutta siitä, että tietoturvaväite on totta nyt, koska väite, sen toteutus ja ajantasainen näyttö ovat todennettavasti linjassa.
Taustalla oleva ketju on:
Väite → Toteutus → Näyttö → Varmuus → Kalibroitu luottamus
Organisaatio esittää väitteen tietoturvastaan. Väite muunnetaan tietyiksi kontrolleiksi, järjestelmiksi, vastuiksi ja odotetuiksi tuloksiksi. Ajantasainen näyttö osoittaa, onko ja miten nämä kontrollit on toteutettu. Varmuusprosessi arvioi, tukeeko näyttö todella alkuperäistä väitettä. Vasta silloin syntyy rationaalinen perusta luottamukselle. Määritelmä sisältää viisi tietoista rajausta.
”Olemme turvallisia” on liian laaja, jotta sitä voitaisiin mielekkäästi todentaa. ”Kaikki tuotannon tietovarastot käyttävät hyväksyttyjä salauskonfiguraatioita” on suppeampi ja testattavissa. Mitä yleisemmäksi väite muuttuu, sitä vaikeampaa on tunnistaa sen soveltamisala, tarvittava näyttö, oletukset ja pätevyyden ehdot.
Kontrolli voi olla vaikuttava yhdessä järjestelmässä ja tehoton toisessa. Tekoälymalli voi sopia sisäisten asiakirjojen tiivistämiseen mutta olla sopimaton tietoturvapoikkeuslupien itsenäiseen hyväksymiseen. Luottamusta ei voi siirtää kontekstista toiseen arvioimatta, ovatko asiaankuuluvat olosuhteet yhä vertailukelpoisia.
Organisaatiot muuttuvat jatkuvasti. Uusia omaisuuseriä otetaan käyttöön. Konfiguraatioita muutetaan. Työntekijät vaihtavat rooleja. Toimittajat päivittävät palvelujaan. Haavoittuvuuksia löydetään. Kontrollit, jotka toimivat eilen oikein, eivät välttämättä toimi oikein enää tänään. Näytön arvo siis heikkenee ajan myötä. Luotettavan johtopäätöksen on kerrottava paitsi se, mitä todennettiin, myös se, milloin se todennettiin ja kuinka kauan johtopäätöksen pitäisi pysyä voimassa.
Näyttö tekee epävarmuuden näkyväksi ja päätökset puolustettaviksi. Se ei poista epävarmuutta kokonaan. Vahvallakin näytöllä on rajoituksensa. Se voi kattaa vain osan järjestelmästä, perustua oletuksiin, sisältää mittausvirheitä tai vanhentua. Uskottavan varmuuden on kerrottava nämä rajoitukset sen sijaan, että ne piilotetaan binäärisen tilan taakse.
Luottamuspäätöksen on voitava muuttua, kun sitä tukevat olosuhteet muuttuvat. Kun uusi näyttö on ristiriidassa aiemman tietoturvaväitteen kanssa, johtopäätös on päivitettävä. Kun näyttö vanhenee, vakuuttuneisuuden on heikennyttävä. Kun katettu soveltamisala laajenee, lisänäyttöä on vaadittava. Luottamus, jota ei voi tarkistaa, ei ole kalibroitua luottamusta. Se on todellisuudesta irronnutta uskoa.
Perinteistä digitaalista luottamusta rakennetaan usein määräajoin annettavilla signaaleilla: sertifikaateilla, kyselylomakkeilla, tarkastusraporteilla, arviointiasiakirjoilla ja tietoturvaesityksillä. Nämä mekanismit ovat edelleen tärkeitä. Ne eivät kuitenkaan yksinään riitä maailmassa, jossa digitaaliset järjestelmät voivat muuttua joka päivä. Tulevaisuuden malli kulkee toiseen suuntaan:
| Perinteinen malli | Tulevaisuuden malli |
|---|---|
| ”Luota meihin” | Todenna tietty väite |
| Laajat tietoturvalupaukset | Määritellyt väitteet ja nimenomainen soveltamisala |
| Määräajoin kerättävä näyttö | Jatkuvasti päivittyvä näyttö |
| Staattiset asiakirjat | Toisiinsa kytketty, koneluettava tieto |
| Binäärinen vaatimustenmukaisuuden tila | Konteksti, epävarmuus ja voimassaoloajat |
| Piilotetut oletukset | Nimenomaiset oletukset ja riippuvuudet |
| Vain myönteinen näyttö | Näkyvät puutteet ja ristiriitainen näyttö |
| Yksi vuosittainen johtopäätös | Jatkuvasti tarkistettavat johtopäätökset |
Jatkuva varmuus ei tarkoita, että jokaista organisaation toimintoa on valvottava pysyvästi. Sen tulee olla riskiperusteista ja oikeasuhtaista. Etuoikeutettua pääsyä, tuotantoinfrastruktuuria tai arkaluonteisia asiakastietoja koskeva kriittinen väite edellyttää ajantasaisempaa ja vahvempaa näyttöä kuin vähäisen vaikutuksen hallinnollinen väite. Tärkeä muutos on, että luottamus ei enää ole sidottu yksittäiseen asiakirjaan. Vaatimusten, toteutusten, näytön, katselmointien, havaintojen, vastuiden ja riippuvuuksien pitäisi sen sijaan muodostaa toisiinsa kytketty malli. Koneluettavilla rakenteilla voi olla tärkeä rooli tässä siirtymässä. Niiden avulla näyttöä voidaan käyttää uudelleen eri viitekehyksissä ja arvioinneissa menettämättä sen alkuperää, alkuperäistä soveltamisalaa, keräysajankohtaa, vastuullista omistajaa tai rajoituksia.
Luottamuksen tulevaisuus ei siis ole pelkästään jatkuva. Se on yksityiskohtainen, jäljitettävä, siirrettävä ja peruttavissa.
Eri käsitteet voidaan nyt yhdistää. Zero Trust ohjaa sitä, miten yksittäiset pääsypäätökset tehdään. Luotettavuus kuvaa, ansaitseeko järjestelmä tai organisaatio luottamusta. Varmuus antaa jäsennellyn perustelun tälle johtopäätökselle. Näyttö tukee toteutusta ja vaikuttavuutta koskevia väitteitä. Vaatimustenmukaisuus arvioi yhdenmukaisuutta määriteltyjen vaatimusten kanssa. Nojautuminen kuvaa, onko joku todella riippuvainen järjestelmästä tai noudattaako hän sitä. Digitaalinen luottamus on laajempi vakuuttuneisuus, joka voi syntyä koko ekosysteemissä. Zero Trust estää olettamasta luottamusta ilman riittäviä perusteita. Varmuus osoittaa, missä luottamus on perusteltua.
Vaatimustenmukaisuus tuo mukanaan jäsennellyt vaatimukset ja katselmointimekanismit. Näyttö yhdistää väitteet havaittavaan todellisuuteen. Nämä käsitteet eivät siis ole kilpailevia visioita. Ne ovat saman johdonmukaisen mallin eri osia. Tulevaisuus ei ole yleinen ”luota kaikkiin” eikä kulttuurinen ”älä luota kehenkään”. Se on todennettavaa, kalibroitua luottamusta.
”Optimize for trust” ei saa tarkoittaa luotettavuuden vaikutelman optimointia. Sen ei pitäisi tarkoittaa mahdollisimman monen vihreän valintamerkin, merkin, sertifikaatin tai laajan tietoturvaväitteen tuottamista. Sen ei pitäisi tarkoittaa ihmisten kannustamista luottamaan järjestelmään enemmän kuin sen todelliset ominaisuudet oikeuttavat. Meille se tarkoittaa:
Älä optimoi sitä, että sinuun luotetaan. Optimoi sitä, että ansaitset perustellun luottamuksen.
Rakennamme Secania yhdistämään tietoturvaväitteet, vaatimukset, toteutukset ja näytön jatkuvasti toisiinsa. Luottamuksen ei pitäisi syntyä pelkästään vakuuttavasta esityksestä tai määräajoin laadittavasta vaatimustenmukaisuusasiakirjasta. Sen pitäisi syntyä ajantasaisesta, tarkastettavissa olevasta ja jäljitettävästä perustelusta. Tämän ajatuksen tiivein ilmaus voisi olla:
Luottamus ei ole lupaus. Se on jatkuvasti perusteltu johtopäätös.
Organisaatioiden ei pitäisi vain näyttää luotettavilta. Niiden pitäisi pystyä osoittamaan, miksi ne ansaitsevat luottamuksen. Eikä ihmisiä pitäisi vain pyytää luottamaan enemmän. Heidät pitäisi tehdä kykeneviksi luottamaan paremmin.
[1] D. M. Rousseau, S. B. Sitkin, R. S. Burt, and C. Camerer, “Not So Different After All: A Cross-Discipline View of Trust,” Academy of Management Review, vol. 23, no. 3, pp. 393–404, 1998, doi: 10.5465/AMR.1998.926617. (DOI)
[2] R. C. Mayer, J. H. Davis, and F. D. Schoorman, “An Integrative Model of Organizational Trust,” Academy of Management Review, vol. 20, no. 3, pp. 709–734, 1995, doi: 10.5465/amr.1995.9508080335. (DOI)
[3] R. Ross, M. Winstead, and M. McEvilley, Engineering Trustworthy Secure Systems, NIST Special Publication 800-160, vol. 1, rev. 1, National Institute of Standards and Technology, Gaithersburg, MD, USA, Nov. 2022, doi: 10.6028/NIST.SP.800-160v1r1. (NIST Publikationen)
[4] S. Rose, O. Borchert, S. Mitchell, and S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207, National Institute of Standards and Technology, Gaithersburg, MD, USA, Aug. 2020, doi: 10.6028/NIST.SP.800-207. (NIST Computer Security Resource Center)
[5] World Economic Forum, Earning Digital Trust: Decision-Making for Trustworthy Technologies, Geneva, Switzerland, Nov. 2022. (World Economic Forum)
[6] K. B. Kelley, “The Digital Trust Imperative: Defining, Establishing and Measuring Digital Trust,” ISACA Journal, vol. 1, Jan. 2023. (ISACA)
[7] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, Jan. 2023, doi: 10.6028/NIST.AI.100-1. (NIST Publikationen)
[8] S. Mehrotra, C. Degachi, O. Vereschak, C. M. Jonker, and M. L. Tielman, “A Systematic Review on Fostering Appropriate Trust in Human-AI Interaction: Trends, Opportunities and Challenges,” ACM Journal on Responsible Computing, vol. 1, no. 4, Art. no. 26, pp. 1–45, 2024, doi: 10.1145/3696449. (ACM Digital Library)
[9] R. Visser, T. M. Peters, I. Scharlau, and B. Hammer, “Trust, distrust, and appropriate reliance in (X)AI: A conceptual clarification of user trust and survey of its empirical evaluation,” Cognitive Systems Research, vol. 91, Art. no. 101357, 2025, doi: 10.1016/j.cogsys.2025.101357. (ScienceDirect)
[10] M. Raees and K. Papangelis, “From Trust to Appropriate Reliance: Measurement Constructs in Human-AI Decision-Making,” arXiv:2604.23896, Apr. 2026, doi: 10.48550/arXiv.2604.23896. Preprint. (arXiv)
[11] T. M. Peters, K. Biermeier, and I. Scharlau, “Assessing healthy distrust in human-AI interaction: Interpreting changes in visual attention,” Frontiers in Psychology, vol. 16, Art. no. 1694367, Jan. 2026, doi: 10.3389/fpsyg.2025.1694367. (Frontiers)
[12] M. Busuioc and M. Maggetti, “Worthy of trust? AI governance and the role of (dis)trust,” Perspectives on Public Management and Governance, Art. no. gvag007, Jul. 2026, doi: 10.1093/ppmgov/gvag007. (OUP Academic)
[13] European Parliament and Council of the European Union, “Regulation (EU) 2024/1689 of 13 June 2024 laying down harmonised rules on artificial intelligence,” Official Journal of the European Union, Jul. 2024. (EUR-Lex)
Secani yhdistää rajaukset, todisteet, tehtävät ja tekoälyagentit yhteiseen työtilaan.
Lähdelinkki ei tee tekoälyn ratkaisusta luotettavaa. Vaatimuksen, näytön ja ratkaisun välisen suhteen on oltava testattavissa.
Yhdistä kriittiset palvelut palautumistavoitteisiin, riippuvuuksiin, harjoituksiin ja korjaaviin toimenpiteisiin, jotta jatkuvuussuunnitelmat vastaavat todellista kyvykkyyttä.
Rakenna uskottava liiketoimintaperuste asiakkaiden luottamuksen, vähentyneen koordinoinnin, häiriönsietokyvyn ja parempien päätösten varaan lupaamatta taattua tuottoa.