Älykkyydestä toimivaltaan

Tekoäly ei enää ainoastaan vastaa kysymyksiin ja tuota sisältöä. Tekoälyjärjestelmät pystyvät yhä useammin tulkitsemaan ohjeita, laatimaan suunnitelmia, valitsemaan työkaluja ja suorittamaan tehtäviä ilman jatkuvaa ihmisen ohjausta.

Tällä erolla on merkitystä.

Toimintaa suositteleva tekoälyjärjestelmä on eri asia kuin järjestelmä, jolla on valtuudet toteuttaa suosituksensa. Ero ei välttämättä liity älykkyyteen tai kehittyneisyyteen, vaan toimivaltaan.

Autonomiset järjestelmät eivät rajoitu edistyneimpiin suuriin kielimalleihin. Niihin kuuluvat erikoistuneet koneoppimisjärjestelmät, robotiikka, autonomiset ajoneuvot, ohjelmistoagentit sekä eri teknologioiden yhdistelmät, jotka tekevät itsenäisesti päätöksiä tai suorittavat toimia määritellyissä käyttöolosuhteissa.

Niiden mahdolliset hyödyt ovat huomattavat. Ne voivat edistää tieteellistä tutkimusta, teollisuuden toimintaa, terveydenhuoltoa, ohjelmistokehitystä ja kyberturvallisuutta. Ne voivat myös johtaa tahattomiin seurauksiin, paljastaa arkaluonteisia tietoja tai käynnistää toimia, joita niiden käyttäjät eivät tarkoittaneet.

Autonomisten järjestelmien suunnittelun turvallisuushaasteissa Mohammad Hamad ja Sebastian Steinhorst tarkastelevat autonomiseen poikkeamien hallintaan, riskien arviointiin, pääsynhallintaan, tietojen luotettavuuteen sekä autonomisten järjestelmien väliseen vuorovaikutukseen liittyviä turvallisuushaasteita. Suuri osa heidän tutkimuksestaan käsittelee kyberfyysisiä järjestelmiä, ja se osoittaa, että itsenäisesti toimivien koneiden suojaamiseen liittyvät haasteet ulottuvat nykyisiä LLM-agentteja laajemmalle.

Autonomian laajemmat seuraukset, kuten mahdolliset fyysiset vahingot, ansaitsevat vakavaa tarkastelua. Näyttöä on kuitenkin tulkittava huolellisesti. Esimerkiksi automatisoituihin ajoneuvoihin liittyviä onnettomuuksia ei voida automaattisesti katsoa samojen mekanismien aiheuttamiksi kuin autonomisten kyberturvallisuusagenttien toimintaan liittyviä tapauksia. Merkitystä on autonomian asteella, käyttöolosuhteilla, ihmisen osallistumisella ja syy-yhteyttä koskevalla näytöllä.

Samoin näyttö siitä, että autonominen tekoäly voi aiheuttaa vahinkoa, ei osoita, että hallintamallit olisivat välttämättä jäämässä jälkeen. Ei myöskään pidä olettaa, että autonomisia järjestelmiä olisi luonnostaan vaikea suojata.

Keskeinen kysymys ei ole se, pystyykö tekoäly suorittamaan monimutkaisia tehtäviä, vaan se, pystyvätkö autonomisia järjestelmiä ohjaavat arkkitehtoniset, tietoturvaan liittyvät ja organisatoriset rakenteet asettamaan delegoidulle toimivallalle asianmukaiset rajat ja tarjoamaan todennettavaa näyttöä siitä, että näitä rajoja noudatetaan.

Kyberturvallisuus tarjoaa tähän kysymykseen erityisen hyödyllisen näkökulman, sillä tietoturva-ammattilaiset ovat vuosikymmenten ajan haastaneet luottamusta, käyttöoikeuksia, pääsyä ja järjestelmien toimintaa koskevia oletuksia.

Kissa ja hiiri -peli koneen nopeudella

Kyberturvallisuutta on jo pitkään kuvattu kissa ja hiiri -peliksi.

Hyökkääjät löytävät heikkouksia, puolustajat ottavat käyttöön suojatoimia, ja molemmat mukautuvat tilanteeseen. Kierre jatkuu teknologioiden, taktiikoiden ja toimintaympäristöjen muuttuessa.

Autonominen tekoäly ei välttämättä muuta pelin perussääntöjä. Se voi kuitenkin muuttaa sitä, kuka tai mikä peliä pelaa, kuinka nopeasti toimitaan ja kuinka paljon työtä voidaan tehdä ilman ihmisen jatkuvaa osallistumista.

Autonominen hyökkäävän tietoturvan järjestelmä voisi tunnistaa avoimia palveluita, tutkia haavoittuvuuksia, kehittää mahdollisia hyökkäyspolkuja ja testata, ovatko ne hyödynnettävissä. Puolustava järjestelmä voisi hyödyntää vastaavia valmiuksia uhkien tutkimiseen, heikkouksien tunnistamiseen ja korjausten toimivuuden varmistamiseen.

Tämä kaksikäyttöisyys on keskeistä autonomisen tekoälyn turvallisuusvaikutusten ymmärtämisessä.

Anthropicin Project Glasswing on esimerkki tekoälyavusteisesta haavoittuvuuksien löytämisestä. Toukokuun 2026 tutkimuspäivityksessään Anthropic kertoi merkittävistä tuloksista haavoittuvuuksien löytämisessä ja korosti samalla niiden varmentamiseen, ilmoittamiseen ja korjaamiseen liittyviä käytännön haasteita.

Tällä erolla on merkitystä. Haavoittuvuuden löytäminen ei ole sama asia kuin sen hyödynnettävyyden varmistaminen, korjaaminen tai sen osoittaminen, että haavoittuva järjestelmä on turvallinen.

Löydösten lisääntyminen voi parantaa näkyvyyttä mutta samalla kasvattaa niiden ratkaisemisesta vastaavien ihmisten ja prosessien työmäärää.

Turvallisuuden lopputulos riippuu siitä, mitä tapahtuu seuraavaksi.

Jos hyökkääjät ja puolustajat voivat automatisoida osan työstään, olennainen kysymys ei ole vain se, kummalla osapuolella on kyvykkäin malli. Ratkaisevaa on, pystyvätkö puolustajat muuttamaan löydökset tehokkaiksi korjauksiksi ja varmistamaan tulokset riippumattomasti.

Perinteinen tunkeutumistestaus ei käy tarpeettomaksi siksi, että tekoäly pystyy suorittamaan hyökkääviä tehtäviä. Sen soveltamisalaa on laajennettava kattamaan myös järjestelmät, jotka tulkitsevat ohjeita, käyttävät työkaluja, yhdistelevät käyttöoikeuksia ja pyrkivät tavoitteisiin useassa vaiheessa.

Tavoite on edelleen tuttu: löytää heikkoudet, selvittää niiden merkitys, korjata ne ja osoittaa, että suojatoimet toimivat.

Arkkitehtuurin saumat: missä turvallisuusrajat kohtaavat

Yksi autonomisten järjestelmien hienovaraisemmista riskeistä syntyy, kun erikseen valtuutetut komponentit toimivat yhdessä tavalla, joka johtaa tahattomiin seurauksiin.

Kutsun näitä vuorovaikutuskohtia arkkitehtuurin saumakohdiksi.

Otetaan perinteinen esimerkki. Organisaatio rajoittaa tiedoston käyttöoikeuksia NTFS-oikeuksilla. Erillinen pilvipalvelu tiedostojen jakamiseen sallii valtuutetun käyttäjän jakaa tiedot ulkopuolisille.

Kumpikin järjestelmä voi toimia omien sääntöjensä mukaisesti. Niiden yhteistoiminta voi kuitenkin johtaa tietojen jakamiseen tavalla, joka rikkoo organisaation tarkoittamaa tietoturvarajaa.

Tämä esimerkki havainnollistaa mahdollisesti ristiriitaisia käytäntöjä, eikä sen tarkoituksena ole väittää, että jokin tiedostonjakotuote olisi haavoittuva.

Ongelma ei välttämättä johdu kummankaan yksittäisen hallintakeinon puutteesta. Kyse voi olla siitä, ettei tarkoitettua tietoturvakäytäntöä noudateta koko työnkulun läpi.

Autonominen tekoäly voi joutua vastaaviin tilanteisiin yhdistäessään malleja, sovelluksia, identiteettejä, työkaluja, koodivarastoja ja ulkoisia palveluja.

Agentilla voi olla oikeus lukea asiakirja, luoda koodivarasto ja ladata tiedostoja. Se ei kuitenkaan välttämättä tarkoita, että sillä olisi valtuudet yhdistää nämä toiminnot tavalla, joka paljastaa luottamuksellisia tietoja.

Tutkimus antaa käytännön syyn tarkastella näitä vuorovaikutuksia.

AgentDojo-tutkimuksessa tutkijat arvioivat työkalujen kanssa toimiviin tekoälyagentteihin kohdistuvia kehoteruiskutushyökkäyksiä 97 realistisessa tehtävässä ja 629 tietoturvatestaustapauksessa. Tulokset osoittivat, että epäluotettavien työkalutulosteiden kautta tuodut haitalliset ohjeet saattoivat vaarantaa joidenkin tietoturvaominaisuuksien toteutumisen, vaikka hyökkäykset ja agentit eivät menestyneetkään johdonmukaisesti.

Tutkimuksessa ei selvitetä, kuinka usein nämä hyökkäykset onnistuvat tuotantoympäristöissä. Se kuitenkin osoittaa, miksi pelkkien mallin vastausten arviointi ei riitä työkaluihin yhdistetyn järjestelmän toiminnan ymmärtämiseen.

Yksi tähän liittyvä riski tunnetaan joskus valtuuksien pesuna: toiminta vaikuttaa oikeutetulta, koska se tapahtuu valtuutetun työkalun tai välikäden kautta, vaikka toimintojen yhdistelmä rikkoisi tarkoitettua valtuusrajaa.

Kun useat agentit tekevät yhteistyötä, niiden välisiä suhteita varten tarvitaan selkeät säännöt osallistumisesta, tietojen vaihdosta ja sallituista toimista.

Vastuut on myös jaettava arkkitehtuurin eri osien kesken.

Mallien tarjoajat, alustojen ylläpitäjät, agenttien kehittäjät ja niitä käyttöön ottavat organisaatiot voivat hallita järjestelmän eri osia. Toimiva jaetun vastuun malli määrittää, kuka hallitsee kutakin rajaa, kuka voi hyväksyä poikkeuksia, kuka valvoo suoritusta ja kuka reagoi ongelmatilanteisiin.

Autonomia ei poista vastuuta. Se tekee entistä tärkeämmäksi tietää, kenellä vastuu on.

Hyökkäävän testaamisen tinkimättömyys: oletustemme koetteleminen

Tämä johdattaa käsitteeseen, jota kutsun hyökkäävän testaamisen tinkimättömyydeksi.

Hyökkäävän testaamisen tinkimättömyys on kurinalainen lähestymistapa vihamielisten hyökkäysten testaamiseen, kriittiseen tarkasteluun ja näyttöön perustuvaan varmennukseen, jossa tietoturvaoletukset asetetaan kyseenalaisiksi. Siinä arvioidaan järjestelmien toimintaa realistisissa olosuhteissa sen sijaan, että luotettaisiin yksinomaan arkkitehtuurisuunnitelmiin, dokumentoituihin hallintakeinoihin tai oletettuihin suojauksiin.

Taustalla olevat käytännöt ovat vakiintuneita. Tunkeutumistestauksella, uhkamallinnuksella, red team -harjoituksilla ja tietoturvan varmennuksella on jo pitkään koeteltu puolustusta koskevia oletuksia.

Hyökkäävän testaamisen tinkimättömyys kokoaa nämä käytännöt yhden keskeisen kysymyksen ympärille:

Mikä näyttö osoittaa, että aiottu tietoturvaraja pitää?

Organisaatiolla voi olla arkaluonteisten tietojen käyttöä rajoittavia käytäntöjä, kieltäytymään kielletyistä pyynnöistä määritetty malli ja rajatuin käyttöoikeuksin toimiva agentti.

Nämä ovat merkityksellisiä suojatoimia. Niiden olemassaolo ei kuitenkaan yksin osoita, että koko järjestelmä toimisi turvallisesti vihamielisissä olosuhteissa.

Malli voi torjua haitallisen ohjeen, mutta valtuutettu työkalu voi silti sallia tahattoman toiminnan. Käytäntö voi vaikuttaa asianmukaiselta, vaikka järjestelmien välinen vuorovaikutus synnyttäisi odottamattoman kiertotien.

Kutsun tätä joskus suojakaideharhaksi: suojakaiteiden olemassaolo tulkitaan virheellisesti näytöksi siitä, ettei järjestelmä voi ylittää rajaa, jonka valvomiseksi ne on tarkoitettu.

Suojakaiteista on hyötyä. Niiden tehokkuus on silti osoitettava.

Kuvitellaan autonominen agentti, jolla on valtuudet tutkia epäiltyä tietomurtoa. Se voi hakea lokitietoja, tarkastella käyttäjien toimintaa ja suositella tilanteen rajaamista.

Valtuutetun tietoturvatestin aikana hyökkääjätestaaja lisää harhaanjohtavia ohjeita tietoihin, joita agentin odotetaan käsittelevän.

Testiä ei pidä lopettaa siihen, että selvitetään, noudattiko agentti näitä ohjeita.

Testissä on selvitettävä, yrittikö agentti tehdä luvattoman toimen, estivätkö riippumattomat hallintakeinot sen toteutumisen, kirjattiinko yritys ja palautuiko järjestelmä asianmukaisesti.

Offensiivinen perusteellisuus yhdistää viisi toimintoa:

1. Määritä oletus: yksilöi tietoturvaominaisuus, jonka arkkitehtuurin odotetaan varmistavan.
2. Haasta oletus: testaa realistisia hyökkäyspolkuja, manipuloituja syötteitä ja hyväksyttyjen toimintojen yhdistelmiä.
3. Kerää näyttöä: selvitä, mitä järjestelmä yritti tehdä, mikä suoritettiin ja mitkä hallintakeinot toimivat.
4. Korjaa heikkous: puutu malliin, työnkulkuun, käyttöoikeuksiin, arkkitehtuuriin tai toimintaprosessiin, joka aiheutti virheen.
5. Varmista korjaus: testaa asiaankuuluva hyökkäyspolku uudelleen ja varmista, että tavoiteltu tietoturvaominaisuus toteutuu.

Tässä on ero sen välillä, testataanko mallin vastausta vai koko järjestelmän tietoturvaa.

Lisäksi on tarkasteltava, mitä tapahtuu ensimmäisen jalansijan saamisen jälkeen. Hyökkääjä voi yrittää kerätä tunnistetietoja, korottaa käyttöoikeuksia, varmistaa pysyvän pääsyn tai siirtyä sivusuunnassa hyödyntämällä ympäristössä jo käytettävissä olevia toimintoja.

Se, että työkalu on hyväksytty, ei tarkoita, että sen jokainen käyttötapa olisi hyväksyttävä.

Offensiivisen perusteellisuuden tarkoituksena ei ole olettaa, että autonomiset järjestelmät ovat tietoturvattomia. Tarkoituksena on selvittää testauksen avulla, missä niiden tietoturvarajat pitävät.

Ehdollinen autonomia: älykkyyden ja toimivallan erottaminen

Yksi arkkitehtuurinen ratkaisu on erottaa toisistaan se, mitä tekoälyjärjestelmä pystyy tekemään, ja se, mihin sillä on valtuudet.

Kutsun tätä lähestymistapaa ehdolliseksi autonomiaksi.

Ehdollisessa autonomiassa tunnustetaan, että sopiva itsenäisyyden aste riippuu tehtävästä, toimintaympäristöstä, mahdollisista seurauksista, epävarmuudesta ja käytettävissä olevasta näytöstä, jolla toimintaa voidaan perustella.

Julkisten tietojen yhteenvetoa laativan agentin valvonnan ei välttämättä tarvitse olla yhtä tiukkaa kuin sellaisen agentin, jolla on valtuudet poistaa tilejä käytöstä, muuttaa palomuurisääntöjä tai tehdä muutoksia tuotantoinfrastruktuuriin.

Jälkimmäinen voi edellyttää nimenomaisia toimintasääntöjä, riippumattomasti valvottuja käyttöoikeuksia, vahvempaa valtuutusta ja ihmisen hyväksyntää merkittäviä seurauksia aiheuttaville toimille.

Näiden rajojen ei pidä laajentua vain siksi, että agentti päättää laajemman pääsyn auttavan tavoitteensa saavuttamisessa.

Agentti voi harkita uudelleen, miten se toteuttaa sille valtuutetun tehtävän, hankkimatta kuitenkaan lisää toimivaltaa.

OWASP:n LLM-sovellusten 10 tärkeintä tietoturvariskiä käsittelee tätä aihetta luokassaan LLM06:2025 Liiallinen toimivalta. OWASP pitää liiallista toiminnallisuutta, liian laajoja käyttöoikeuksia ja liiallista autonomiaa riskien lähteinä ja suosittelee rajoittamaan toimintoja sekä valvomaan valtuutusta riippumattomasti.

Ehdollisessa autonomiassa näitä periaatteita sovelletaan toiminnallisten riskien mukaan.

Tietojen saanti tulee rajata tehtävän edellyttämään määrään. Työkalujen käyttöoikeudet tulee rajata hyväksyttyihin toimintoihin. Suoritusrajoitukset, käyttötiheyden rajoitukset, hyväksyntävaatimukset ja pysäytysehdot voivat rajoittaa toimintaa.

Nämä suojatoimet ovat erityisen tärkeitä autonomisessa hyökkäävässä testauksessa.

Testausagentti voi valtuutettua tavoitetta tavoitellessaan löytää tunnistetietoja tai arkaluonteisia tietoja. Tunnistetiedon löytyminen ei kuitenkaan tarkoita, että mallin tarvitsee saada sen selväkielinen arvo.

Tietoturvakehikko voi pitää arkaluonteiset tunnistetiedot erillään mallista ja välittää niiden käytön riippumattomasti valvotun valtuutuksen kautta. Tunnistetietojen välityspalvelu voi esimerkiksi toimittaa salaisuuden suoraan hyväksytylle palvelulle altistamatta sitä tarpeettomasti mallille.

Tämä noudattaa vähimpien oikeuksien ja tehtävien eriyttämisen vakiintuneita periaatteita.

Tämä herättää myös kiinnostavan kysymyksen Bring Your Own Model (BYOM)- tai Bring Your Own LLM (BYO-LLM) -arkkitehtuurista.

Jos taustalla oleva malli vaihdetaan huomenna, mitkä tietoturvatakuut säilyvät?

Tehtävien valtuutus, tunnistetietojen eristäminen, käyttöalan rajoitukset, lokitietojen kerääminen ja käytäntöjen valvonta voivat sijaita mallia ympäröivässä kehikossa sen sijaan, että ne riippuisivat täysin mallin toiminnasta.

Tämä ei tarkoita, että kehikko olisi automaattisesti tietoturvallinen tai että mallit olisivat keskenään vaihtokelpoisia. Eri mallit voivat tulkita ohjeita eri tavoin, käyttää työkaluja eri tavoin ja aiheuttaa erilaisia virhetilanteita.

Mielekkäässä arvioinnissa on testattava sekä muuttumattomina säilyviksi tarkoitettuja hallintakeinoja että toimintatapoja, jotka muuttuvat mallin vaihtuessa.

Ehkä kestävimpien tietoturvaominaisuuksien joukossa ovat ne, joiden noudattaminen voidaan varmistaa riippumattomasti älykkyyskomponentin kehittyessäkin.

Kun tekoäly toimii tekoälyn pohjalta: todentamisen haaste

Tarkastellaan hypoteettista tietoturvatoimintojen työnkulkua:

Tutki tätä tietoturvapoikkeamaa, kerää todisteet, tunnista siihen liittyvät identiteetit, ehdota torjuntatoimia, toteuta hyväksytyt toimet ja varmista lopputulos.

Tutkiva agentti analysoi telemetriatietoja. Toinen suosittelee uhkan rajaamista. Valtuutettu suoritusagentti tekee muutokset. Varmennusagentti arvioi lopputuloksen.

Tämä havainnollistaa suljetun silmukan autonomista reagointia tietoturvapoikkeamiin, ei dokumentoitua koko alaa koskevaa epäonnistumista.

Oletetaan, että ensimmäinen agentti tunnistaa virheellisesti identiteetin vaarantuneeksi. Toinen agentti hyväksyy tämän päätelmän ja poistaa tilin käytöstä. Kolmas vahvistaa, että tili on poistettu käytöstä, ja ilmoittaa onnistumisesta.

Valittu toiminto suoritettiin.

Mutta oliko alkuperäinen arvio oikea? Oliko toiminto valtuutettu? Puuttuiko uhkan rajaaminen todelliseen uhkaan? Aiheuttiko se tarpeetonta häiriötä?

Varmennus ei voi tarkoittaa pelkästään sen vahvistamista, että agentti suoritti valitsemansa toiminnon.

Myöskään varmennuksen antaminen toiselle tekoälyagentille ei automaattisesti tee tuloksesta riippumatonta.

Eri agentit saattavat nojata samoihin virheellisiin telemetriatietoihin, vaarantuneisiin tietoihin tai puutteellisiin oletuksiin. Niiden yksimielisyys ei ole riippumaton vahvistus taustalla olevista tosiasioista.

Mitä vakavampia seurauksia autonomisella toiminnolla voi olla, sitä tärkeämpää on varmentaa toiminto riippumattomasti päätöksen tekevästä järjestelmästä.

Riippumattomuus voi tarkoittaa erikseen hankittua näyttöä, deterministisiä käytäntötarkistuksia, rajoitettuja suoritusympäristöjä, ihmisen tekemää arviointia tai näiden suojatoimien yhdistelmää.

Valvontatoimien tulisi olla oikeassa suhteessa virheen mahdollisiin seurauksiin.

Vähäisiä vaikutuksia aiheuttavat ja peruttavissa olevat toiminnot voivat soveltua automaattisesti varmennettaviksi. Suurivaikutteiset tai vaikeasti peruttavat toiminnot saattavat edellyttää vahvempaa valtuutusta, riippumatonta vahvistusta ja nimenomaista ihmisen hyväksyntää.

Neljän kysymyksen avulla voidaan erottaa toisistaan olennaiset tietoturvaominaisuudet:

• Tulkitseeko järjestelmä sille annetun tehtävän oikein?
• Kuuluiko toiminto sille delegoituihin valtuuksiin?
• Pysyikö suoritus sallituissa rajoissa?
• Vastasiko lopputulos tavoiteltua tietoturvatavoitetta?

Nämä kysymykset liittyvät toisiinsa, mutta eivät ole keskenään vaihdettavissa.

Agentti voi suorittaa valtuutetun toiminnon, joka johtaa tahattomaan lopputulokseen. Se voi myös saada aikaan näennäisesti hyödyllisen tuloksen toimimalla ilman valtuutusta.

Kumpaakaan ei pidä automaattisesti pitää onnistuneena tietoturvan kannalta.

Autonomisten järjestelmien kyvykkyyden kasvaessa haasteena ei ole vain mahdollistaa niiden suorittaa monimutkaisia työnkulkuja. On myös pystyttävä osoittamaan riittävän vahvan näytön avulla, että niiden toiminta pysyy valtuutettuna, asianmukaisena ja oikeana.

Tähän kuuluu sen tunnistaminen, milloin on syytä pysähtyä, siirtää asia eteenpäin, perua toiminto tai hyväksyä rajattu ja nimenomaisesti ymmärretty riski.

Luottamuksen on perustuttava näyttöön

Autonomisen tekoälyn tietoturvavaikutukset eivät ole yksinomaan kielteisiä.

Autonomiset järjestelmät voivat auttaa puolustajia löytämään heikkouksia, tutkimaan uhkia ja tekemään varmennustyötä, joka muuten veisi huomattavasti ihmisten aikaa.

Paremmat mallit, vahvemmat ulkoiset valvontakeinot ja kypsemmät toimintatavat voivat vähentää joitakin delegoituihin valtuuksiin liittyviä riskejä.

Siksi olisi ennenaikaista päätellä, että autonominen tekoäly on luonnostaan turvatonta tai ettei hallintamalli voi pysyä sen kehityksen tahdissa.

Väitteelle, että autonominen tekoäly edellyttää perustavanlaatuisesti uusia tietoturvaperiaatteita, on myös vakavasti otettava vasta-argumentti.

Monia taustalla olevia ongelmia – liiallisia käyttöoikeuksia, epäluotettavia syötteitä, puutteellista valtuutusta, epäjohdonmukaista käytäntöjen valvontaa ja riittämätöntä varmennusta – on tutkittu vuosikymmeniä.

Vakiintuneet valvontakeinot voivat jo tarjota toimivia ratkaisuja, kun ne toteutetaan ja testataan asianmukaisesti.

Autonomia voi muuttaa niiden soveltamisen nopeutta, laajuutta ja monimutkaisuutta. Se ei kuitenkaan automaattisesti tee niitä pätemättömiksi.

Näyttö tukee hyödyllisempää kysymystä: millä edellytyksillä autonomisten järjestelmien voidaan luottaa käyttävän niille delegoituja valtuuksia, ja miten osoitamme näiden edellytysten täyttyvän?

Vastausta ei löydy pelkästään mallien kyvykkyydestä.

Se edellyttää arkkitehtonisia rajoja, selkeästi määriteltyä vastuuta, riippumattomasti valvottua valtuutusta, asianmukaista valvontaa sekä näyttöä siitä, että suojatoimet toimivat realistisissa olosuhteissa.

Se edellyttää myös johdonmukaista mutta kehittyvää näkemystä tietoturvasta ja riskeistä.

Tietoturvan perusperiaatteidemme ei tarvitse muuttua jokaisen uuden mallin myötä. Oletuksiamme siitä, miten näitä periaatteita sovelletaan, on kuitenkin arvioitava jatkuvasti uudelleen kyvykkyyksien, toimintaympäristöjen ja delegoitujen valtuuksien kehittyessä.

Tämä on Offensive Rigor -ajattelutavan tarkoitus.

Tarkoituksena ei ole osoittaa, että tekoälyjärjestelmät epäonnistuvat, vaan selvittää, missä ne voivat epäonnistua, määrittää seuraukset ja varmistaa, että näillä epäonnistumisilla on tarkoitus ehkäistä tai rajoittaa.

Ehkä kestävämpi etu ei ole pelkästään kyvykkäämmän mallin valitseminen, vaan sellaisen arkkitehtuurin rakentaminen, jossa malleja voidaan vaihtaa vaarantamatta luottamuksen, toimivallan ja todentamisen rajoja.

Kissa ja hiiri -leikki jatkuu. Yhä useammin molemmilla osapuolilla voi olla autonomisia toimijoita.

Ratkaisevaa on varmistaa, ettei kykymme löytää heikkouksia, korjata ne ja osoittaa tulokset katoa kilpailussa kaiken muun automatisoimiseksi.

Luottamuksen on perustuttava näyttöön.

Kirjoittajan huomautus: Tässä artikkelissa esitetyt näkemykset ja tulkinnat ovat omiani eivätkä välttämättä vastaa työnantajani virallisia kantoja, toimintaperiaatteita tai tuotteiden ominaisuuksia.