Tekoälyn turvallisuus on enimmäkseen järjestelmäsuunnittelua
Demotilaisuuden jälkeinen turvallisuuspalaveri
Demo oli sujunut hyvin tavalliseen tapaan. Malli luki pinon sisäisiä asiakirjoja, vastasi politiikkaa koskevaan kysymykseen, ehdotti seuraavaa vaihetta ja tuotti siistin yhteenvedon asiakirja-aineistoon. Huone nyökytteli. Joku kysyi, voisiko sen liittää työnkulkujärjestelmään. Joku toinen kysyi, kuinka pian. Sitten turvallisuusvastaava kysyi, mitä tapahtuisi, jos malli olisi väärässä mutta vakuuttava. Huone kiinnostui yhtäkkiä kovasti kekseistä.
Tuosta kysymyksestä käytännön tekoälyturvallisuus alkaa. Ei abstraktilla tasolla eikä iskulauseissa. Vaan järjestelmän muodossa, joka ympäröi mallia, joka on joskus väärässä, joskus vanhentunut, joskus liian itsevarma, joskus liian epävarma ja joskus oikeassa väärästä syystä. Turvallisuusongelma ei ole vain mallin käyttäytyminen. Se on se, mitä järjestelmä sallii tuon käyttäytymisen tehdä.
Malli, joka luonnostelee lauseen, on yksi riski. Malli, joka päivittää etuuspäätöksen, on toinen. Malli, joka kutsuu työkalua kirjoitusoikeuksilla, on kolmas. Malli, joka ohjaa potilaan, hylkää korvaushakemuksen, muuttaa luottorajaa tai ohjaa laitteita, kuuluu aivan eri vaaraluokkaan. Sama taustalla oleva malli voi olla harmiton, hyödyllinen, riskialtis tai mahdoton hyväksyä riippuen rajoista, tilasta, todisteista, valtuuksista, seurannasta ja palautuksesta. Siksi tekoälyturvallisuus on enimmäkseen järjestelmäsuunnittelua.
Enimmäkseen tekee tuossa lauseessa työtä. Mallitutkimus on tärkeää. Datan laatu on tärkeää. Kohdistusmenetelmät ovat tärkeitä. Arviointitiede on tärkeää. Mutta kun organisaatio ottaa tekoälyn käyttöön, turvallisuudesta tulee operatiivista. Kuka saa kysyä. Mitä malli saa nähdä. Mitä se saa muuttaa. Mitä todisteita vaaditaan. Mikä tila säilytetään. Mitä tapahtuu, kun lähteet ovat ristiriidassa. Milloin ihmisen on hyväksyttävä. Miten ajautuminen havaitaan. Miten huono julkaisu perutaan. Nämä ovat suunnittelukysymyksiä ennen kuin ne ovat eettisiä julkilausumia. Eettinen julkilausuma voi olla vilpitön. Järjestelmä ei toteuta vilpittömyyttä.
Turvallisuus on hallintaongelma
Kun ihmiset kuulevat sanan turvallisuus, he ajattelevat usein arvoja, koulutusdataa, kieltäytymiskäytäntöjä ja mallin kohdistusta. Ne ovat osa kokonaiskuvaa, mutta käyttöönotettu järjestelmä tarvitsee myös hallintakeinoja. Hallintakeino on jotakin, joka muuttaa sitä, mitä voi tapahtua: pääsyn tarkistus, skeema, aikakatkaisu, kynnysarvo, ihmisen hyväksyntä, hiekkalaatikko, nopeusrajoitus, varmennin, palautus, hätäkatkaisin, tietue, jota palvelupolku ei voi muokata. Hallintakeinot ovat tylsiä, kunnes ne puuttuvat. Sitten niistä tulee koko palaverin aihe.
Turvallinen tekoälyjärjestelmä olettaa, että malli voi epäonnistua, ja suunnittelee ympäröivän mekaniikan sen mukaisesti. Se erottaa ehdotuksen toiminnasta. Se rajoittaa työkalujen valtuuksia. Se tarkistaa todisteet ennen tilamuutoksia. Se tekee epävarmuudesta näkyvää. Se tallentaa malliversion ja lähdealueen. Se kieltäytyy, kun pakolliset kentät puuttuvat. Se antaa käyttäjille keinon keskeyttää automaatio. Se kohtelee mallin tuotosta ehdokkaana, ei määräyksenä hyvin artikuloidulta laskentataulukolta.
Tämä on tavallista turvallisuustekniikkaa, jonka keskellä on kielimalli. Ilmailu, lääketiede, rautatieliikenne, teollisuuden ohjaus ja rahoitus ovat kaikki oppineet, että tärkeät järjestelmät tarvitsevat kerroksittaisia suojauksia, koska mikään osa ei ole täydellinen. Tekoälyversio tuntuu uudelta, koska osa puhuu. Puhe tekee epäonnistumisesta sosiaalisesti vakuuttavaa. Väärä vastaus, joka kuulostaa rauhalliselta, voi livahtaa väsyneen käyttäjän ohi helpommin kuin vilkkuva punainen virheilmoitus. Suojauksen suunnittelun on siis oltava itsepäisempää kuin proosan.
Suojauksen suunnittelu alkaa kysymällä, mihin järjestelmä saa vaikuttaa. Jos tekoäly voi vain luonnostella, turvallisuus keskittyy lähteiden laatuun, hallusinaatiotarkistuksiin, käyttöliittymän selkeyteen ja tarkistukseen. Jos se voi reitittää työtä, turvallisuus lisää tilan seurannan, jonojen eheyden, palvelutasot ja valituspolut. Jos se voi kutsua työkaluja, turvallisuus lisää käyttöoikeusalueet, argumenttien validoinnin, tapahtumalokit ja korjaavat toimet. Jos se voi vaikuttaa oikeuksiin tai fyysisiin järjestelmiin, turvallisuus edellyttää todisteita, muodollista tarkistusta, rajoitettua autonomiaa ja vakavaa häiriösuunnittelua. Malli on yksi osa. Valtuusalue on toinen.
Raja on tuote
Tärkein raja tekoälyjärjestelmässä ei usein näy käyttöliittymässä. Se on raja lukemisen ja kirjoittamisen, suosittelemisen ja päättämisen, tiivistämisen ja tallentamisen, avustamisen ja toimimisen välillä. Heikot rajat ovat se tapa, jolla harmittomista prototyypeistä tulee turvattomia palveluita. Malli, joka alkaa luonnostelun apuvälineenä, saa painikkeen luonnoksen soveltamiseen. Sitten se saa työkalun tapauksen päivittämiseen. Sitten se saa reitityssäännön, koska tiimillä on kiire. Kuusi kuukautta myöhemmin kukaan ei osaa selittää, mitkä päätökset ovat automatisoituja ja mitkä vain avustettuja. Tämä ei ole pahansuopuutta. Se on laajuuden kasvua mukavissa kengissä.
Hyvät rajat ovat yksiselitteisiä ja tarkastettavissa. Malli saa lukea näitä lähteitä, ei noita. Se saa ehdottaa näitä kenttiä, mutta ei vahvistaa niitä. Se saa kutsua tätä työkalua näillä argumenteilla, ei mielivaltaisella tekstillä. Se saa reitittää matalan riskin tapauksia, ei kiistanalaisia tapauksia. Se saa vastata vain, kun todisteet ovat ajantasaisia. Se ei saa käyttää yksityisiä muistiinpanoja julkisiin selityksiin. Se ei saa siirtyä vuokralaisesta, alueelta, tililtä tai oikeusperusteesta toiseen vain siksi, että seuraava kappale vaikutti hyödylliseltä.
Rajat on myös valvottava mallin ulkopuolella. Kehote, joka sanoo, että asiakastietokantaan ei saa kirjoittaa, ei ole raja, jos työkalulla on kirjoitusoikeus eikä yhdyskäytävää ole. Järjestelmäviesti, joka sanoo, että lähteet on mainittava, ei ole raja, jos vastaukset voidaan tallentaa ilman lähdeviitteitä. Käytäntökappale, joka sanoo, että ihmisen hyväksyntä vaaditaan, ei ole raja, jos työnkulku antaa automaation merkitä asian hyväksytyksi. Turvallisuusohjeet mallin sisällä ovat hyödyllisiä, mutta ne eivät riitä. Järjestelmän on tehtävä turvattomista poluista vaikeita tai mahdottomia.
Tämä on epäromanttista työtä, joka todella suojelee ihmisiä. Tyypitetyt työkalujen kutsut. Kapeat käyttöoikeusalueet. Vain luku -oletukset. Erilliset hyväksyntäpalvelut. Idempotentit toiminnot. Auditointilokit. Versioidut käytännöt. Jonojen tilat. Yksiselitteiset kieltäytymistilat. Sanasto kuulostaa siltä, kuin taustajärjestelmäinsinööri olisi viettänyt hiljaisen viikonlopun leikepöydän kanssa. Hyvä. Turvallisuus tuotannossa näyttää yleensä tältä. Se ei yritä voittaa iskulausekilpailua.
Tila on se, missä turvallisuus muuttuu todelliseksi
Keskustelut tekoälyn kanssa voivat saada järjestelmät näyttämään tilattomilta. Käyttäjä kysyy, malli vastaa, näyttö muuttuu. Tuotanto ei ole tilatonta. Tapaukset etenevät. Tiketit vanhenevat. Käyttöoikeudet päättyvät. Asiakirjoja korjataan. Mallin versio vaihtuu. Ihminen ohittaa suosituksen. Valitus saapuu. Käyttäjä kysyy, miksi jotain tapahtui viime kuussa. Turvallisuus riippuu siitä, säilyttikö järjestelmä vastaamiseen tarvittavan tilan.
Tila kertoo järjestelmälle, mitä on jo tapahtunut ja mitä voi tapahtua seuraavaksi. Ilman sitä malli näkee siivun ja arvaa loput. Näin syntyvät päällekkäiset toimet, määräajat katoavat, hyväksynnät oletetaan ja vanha näyttö päätyy uudelleen uuteen päätökseen. Turvallinen työnkulku tallentaa yksiselitteiset tilat: luonnos, näyttö puuttuu, käytäntö estää, tarkistus vaaditaan, hyväksytty, suoritettu, haastettu, korjattu, palautettu. Nämä tilat eivät ole koristeita. Ne estävät mallia käsittelemästä merkityksellistä prosessia kuin keskustelulokia, jolla on kunnianhimoa.
Tila antaa myös ihmisille vipuvoimaa. Operaattori voi tarkastaa, miksi tapaus on tarkistuksessa. Esimies voi nähdä, luoko automaatio ruuhkaa. Auditoija voi toistaa, mitkä lähdeversiot olivat käytössä. Käyttäjä voi haastaa lopputuloksen jollakin konkreettisemmalla kuin kuvakaappauksella. Kehittäjä voi mitata, lisääkö uusi malli kieltäytymisiä, eskalaatioita tai uudelleentyötä. Ilman tilaa jokaisesta turvallisuuskeskustelusta tulee teatteria. Ihmiset puhuvat vastuusta, mutta järjestelmä on hukannut substantiivit.
Tekoälyn osalta tilaan tulisi sisältyä mallin ja käytännön versio, kehotteen tai mallipohjan tunniste, lähdejoukko, hakuaikaleima, työkalujen kutsut, luottamus tai epävarmuus, kieltäytymisen syy, ihmisen toimet ja vaikutus alavirtaan. Kaikki tämä ei kuulu yhteen lokiriviin, eikä kaiken tarvitse olla kaikkien nähtävillä. Yksityisyys ja tietoturva ovat tärkeitä. Mutta tiedon on oltava olemassa valvotun pääsyn takana. Muuten turvallisuus tulee riippuvaiseksi muistista, ja muisti on tunnetusti huono tietokanta, jolla on erinomaiset selitykset.
Näyttö on turvallisuuden kaide
Mallin vastaus on turvallisempi, kun se on sidottu näyttöön. Se kuulostaa itsestäänselvyydeltä, kunnes järjestelmä on paineen alla. Näyttö jätetään väliin, koska se lisää viivettä. Viittaukset tallennetaan tekstinä tunnisteiden sijaan. Hakupisteitä ei säilytetä. Lähdeversiot korvataan. Malli kirjoittaa varman selityksen asiakirjasta, joka on sittemmin korjattu. Myöhemmin kaikki kysyvät, miksi vastaus oli väärä. Vastaus on, että kaide oli koristeellinen.
Hyödyllinen näyttö ei ole alaviite. Se on ketju. Pyyntö saapui tunnistetun henkilön ja tarkoituksen kanssa. Lähteet valittiin luvan puitteissa. Haku löysi tiettyjä osioita tai tietueita. Malli tuotti tuloksen nimetyn version alla. Tarkistaja vahvisti väitteet tai kriteerit. Ihminen hyväksyi, muokkasi tai hylkäsi. Toiminto muutti tilaa. Järjestelmä tallensi riittävästi tästä ketjusta, jotta se voidaan toistaa tai haastaa. Tämä ei ole byrokratiaa byrokratian vuoksi. Näin turvallisuus kestää ajan.
Näyttö suojaa myös mallia siltä, että siltä vaaditaan mahdotonta työtä. Jos järjestelmä edellyttää ajantasaisia lähteitä, malli voi kieltäytyä vanhentuneesta syötteestä. Jos järjestelmä edellyttää kahta toisiaan vastaavaa tietuetta, se voi huomauttaa ristiriidasta. Jos järjestelmä edellyttää lähdetunnisteita, se voi pysäyttää perusteettomat väitteet. Mallin ei enää tarvitse muuttaa puuttuvaa todistetta sujuvaksi epävarmuuden hallinnaksi. Se voi palauttaa turvallisen tilan. Tämä on ystävällisempää mallille ja paljon ystävällisempää henkilölle, johon tulos vaikuttaa.
Tasapaino on olemassa. Näytön tallentamisesta ei saa tulla valvontaa. Arkaluonteinen sisältö voidaan tiivistää, poistaa, erottaa tai säilyttää rajoitetun ajan. Tarkoitus ei ole tallentaa kaikkea ikuisesti. Tarkoitus on säilyttää tosiasiat, joita tarvitaan tärkeän käyttäytymisen tarkasteluun. Turvallisuus ilman näyttöä on vain luottamusta hienommassa takissa. Se voi näyttää hyvältä aulassa. Se ei kestä onnettomuutta.
Ihmiset tarvitsevat suunniteltua toimivaltaa
Ihminen silmukassa on usein taikasana. Se ei ole taikaa. Väsynyt tarkistaja, jolla on heikko näyttö, epäselvä toimintaperiaate ja jono, jossa on kaksisataa tapausta, ei ole turvajärjestelmä. Hän on henkilö, joka on asetettu kuljetinhihnan päähän ja jota pyydetään toimimaan hallintona. Se voi toimia hetken, varsinkin jos henkilö on kokenut ja sinnikäs. Se ei ole suunnitelma.
Ihmisen toimivallan on oltava yksityiskohtaista. Mitkä tapaukset vaativat tarkistuksen. Mitä näyttöä tarkistaja näkee. Voiko tarkistaja muuttaa jäsenneltyjä kenttiä vai vain hyväksyä tekstin. Tietääkö tarkistaja, oliko malli epävarma vai vaativatko toimintaperiaatteet korotusta. Syötetäänkö erimielisyydet takaisin arviointiin. Ovatko tarkistajat suojassa automaatioharhalta. Voivatko he keskeyttää työnkulun. Voivatko he siirtää asian asiantuntijalle. Voivatko he nähdä samankaltaisia aiempia tapauksia. Voivatko he selittää päätöksen asianomaiselle henkilölle. Nämä yksityiskohdat ratkaisevat, onko ihmisen valvonta todellista vai koristeellista.
Hyvä valvonta erottaa myös harkinnan mekaanisesta korjailusta. Ihmisten ei pitäisi käyttää aikaansa puuttuvien lähdetunnisteiden etsimiseen, uudelleenyritysten deduplikointiin, mallin tuottaman tekstin kääntämiseen työnkulkutiloiksi tai sen arvaamiseen, mikä käytäntöversio oli voimassa. Järjestelmän pitäisi paketoida tapaus. Ihmisen pitäisi käyttää harkintaa siellä, missä harkintaa tarvitaan: kiistanalaisessa merkityksessä, poikkeuksissa, suhteellisuudessa, kontekstissa, empatiassa ja vastuussa. Jos ihminen lähinnä paikkailee infrastruktuurin aukkoja, organisaatio on sekoittanut henkilöstön turvallisuuteen.
Suunnittelun on myös annettava ihmisten olla eri mieltä automaation kanssa ilman, että kitkasta tulee rangaistus. Jos mallin ohittaminen vaatii kahdeksan klikkausta ja hyväksyminen yhden, käyttöliittymässä on käytäntö. Jos eskalaatio saa tiimin näyttämään hitaalta, ihmiset välttävät eskalaatiota. Jos mittarit palkitsevat vain läpimenon, turvallisuuskatselmuksista tulee seremoniallisia. Järjestelmäsuunnitteluun kuuluvat kannustimet, näytöt, jonot ja oletusarvot. Malli ei ehkä tunne mittaria, mutta ihmiset kyllä tuntevat.
Sijainti muuttaa riskiä
Sillä, missä tekoälytyö tapahtuu, on merkitystä. Järjestelmä, joka lähettää jokaisen asiakirjan etämallille, sisältää erilaisia riskejä kuin järjestelmä, joka tekee poiminnan lähellä dataa ja lähettää vain johdetun kentän. Järjestelmä, joka tallentaa jäljet palveluun, sisältää erilaisia riskejä kuin järjestelmä, joka pitää riippumattomia auditointitietoja. Järjestelmä, joka luottaa yhteen ulkoiseen reitittimeen, tarjoaa erilaiset palautusvaihtoehdot kuin järjestelmä, joka voi toimia rajoitetusti paikallisesti. Sijainti ei ole nationalismia verkkokaavion kanssa. Se on käytännön kysymys siitä, mitkä riskit siirtyvät, kun data, laskenta, käytännöt ja todisteet siirtyvät.
Osa työstä pitäisi tehdä lähellä arkaluonteista dataa, koska datan siirtäminen lisää altistumista. Osa työstä pitäisi tehdä lähellä käyttäjiä, koska viive vaikuttaa turvallisuuteen. Osa työstä pitäisi tehdä keskitetyssä palvelussa, koska erikoistunut tarkastelu tai laitteisto on tarpeen. Osa todisteista pitäisi säilyttää erillään mallin palvelupolusta, koska palvelupolku voi olla tutkinnan kohteena. Turvallinen suunnittelu on harvoin joko kaikki paikallisesti tai kaikki etänä. Se on harkittua sijoittelua.
Sijainti vaikuttaa myös juridiseen ja organisatoriseen vastuuseen. Jos mallikutsu ylittää alueita, minkä lain alaista data on. Jos indeksi rakennetaan lähdejärjestelmän ulkopuolelle, miten poistot välitetään. Jos toimittaja vaihtaa mallia, miten ilmoitus vastaanotetaan ja testaus suoritetaan. Jos lokit ovat toimittajan portaalissa, voiko organisaatio viedä ne ulos häiriön aikana. Nämä eivät ole abstrakteja suvereniteettikysymyksiä. Ne ovat turvallisuuskysymyksiä, koska ne määrittävät, voiko organisaatio hallita ja selittää järjestelmää paineen alla.
Väärä sijoittelu voi tehdä turvallisesta käyttäytymisestä kallista. Jos jokainen varmistusvaihe vaatii etämatkan, tiimit saattavat otantaa tarkistamisen sijaan. Jos auditointidataa on vaikea yhdistää, tutkimuksista tulee hitaita. Jos yksityisen datan on matkustettava yksinkertaisen luokittelun vuoksi, riski kasvaa ilman hyötyä. Hyvä sijoitussuunnittelu vähentää turvallisen toiminnan kustannuksia. Tällä on merkitystä, koska liian kalliit kontrollit kuvataan lopulta vapaaehtoisiksi, ja niin monet huonot tarinat alkavat.
Arvioinnin on seurattava järjestelmää
Monet tiimit arvioivat mallin mutta unohtavat arvioida järjestelmän. He testaavat, ovatko vastaukset oikeita tietyssä kysymysjoukossa, ja ottavat sitten käyttöön työnkulun, jossa on käyttöoikeuksia, lähteiden tuoreutta, jonoja, työkalujen kutsuja, ihmisten tarkistuksia, uudelleenyrityksiä ja muuttuvia käytäntöjä. Mallin vertailuarvo voi yhä olla hyödyllinen, mutta se ei enää kuvaa koko riskiä. Turvallisuuspuutteet elävät usein liitoksissa.
Järjestelmäarviointi testaa päästä päähän -käyttäytymistä. Se kysyy, haetaanko oikea lähde oikealle käyttäjälle. Se tarkistaa, kieltäydytäänkö vanhentuneesta datasta. Se varmistaa, että työkalujen kutsut estetään ilman käyttöoikeutta. Se mittaa, päätyvätkö korkean riskin tapaukset ihmisille. Se testaa palautuksen. Se testaa jonon viivettä. Se testaa mallin päivityspolut. Se testaa outoja mutta tavallisia tapauksia: puuttuva päivämäärä, päällekkäinen asiakas, aluepoikkeus, valitus korjauksen jälkeen, lähteen poisto, osittainen häiriö, ylikuormittunut tarkistaja. Tuotannolla on makua tapauksiin, joita kukaan ei pitänyt tarpeeksi dramaattisina.
Arvioinnin tulisi sisältää kieltäytymiskyky. Järjestelmän on oltava hyvä olla tekemättä asioita. Ei vastaamista ilman todisteita. Ei käyttöoikeusrajojen ylittämistä. Ei siirtymistä toimintaan, kun vain luonnostelu on sallittua. Ei epävarmuuden piilottamista. Ei lähteen käyttöä poiston jälkeen. Ei jatkamista, kun työkalu palauttaa epäjohdonmukaisen tilan. Turvallisuus riippuu yhtä paljon kieltäytymisestä ja pysähtymisestä kuin tarkkuudesta. Turvallisen tekoälyjärjestelmän tärkein tuotos voi olla riittämättömät todisteet, mikä on lause, jota yksikään demotiimi ei laita banneriin.
Järjestelmäarviointi muuttaa myös julkaisunhallintaa. Kysymysten muutos, mallin muutos, indeksin uudelleenrakennus, käytäntöpäivitys, työkalujen käyttöoikeusmuutos tai tarkistajan käyttöliittymän muutos voi muuttaa turvallisuutta. Jokainen tarvitsee testauslaajuuden ja palautussuunnitelman. Tiimin tulisi tietää, mitkä käyttäytymiset muuttuivat ja mitkä riskit kasvoivat. Tämä on tylsää samalla tavalla kuin turvavyöt ovat tylsiä. Siitä tulee kiinnostavaa vasta kun se puuttuu, mikä on liian myöhäistä mukavuudelle.
Opetus
Tekoälyn turvallisuus on enimmäkseen järjestelmäsuunnittelua, koska haitta kulkee yleensä järjestelmien kautta. Mallin tuotoksesta tulee riskialtis, kun työnkulku luottaa siihen liikaa, työkaluyhdyskäytävä on liian leveä, todisteet puuttuvat, tila on epämääräinen, tarkistus on ylikuormitettu, lokit ovat heikot tai palautus on kuvitteellista. Malli voi olla lauseen näkyvä lähde, mutta järjestelmä päättää, tuleeko lauseesta toimintaa.
Tämä näkymä on vähemmän dramaattinen kuin monet tekoälyn turvallisuutta koskevat väittelyt, ja hyödyllisempi organisaatioille, jotka ottavat järjestelmiä käyttöön nyt. Se pyytää tiimejä vetämään rajat, nimeämään auktoriteetin, säilyttämään todisteet, suunnittelemaan tilat, sijoittamaan työn harkitusti, arvioimaan päästä päähän ja antamaan ihmisille todellista valtaa. Se kohtelee mallia tehokkaana osana turvallisuusperustelua, ei koko turvallisuusperusteluna. Tämä on aikuinen kanta. Se antaa myös insinööreille jotain rakennettavaa toisen politiikka-PDF:n sijaan, mikä on ystävällistä kaikille.
Turvallisuusvastaavan kysymys demon jälkeen oli aivan oikea. Mitä tapahtuu, jos malli on väärässä mutta vakuuttava. Turvallisella järjestelmällä pitäisi olla vastaus: se voi vain luonnostella täällä, sen on viitattava ajantasaisiin lähteisiin tuolla, se ei voi kutsua tuota työkalua, tämä tapaus menee tarkasteluun, tämä toimenpide jättää kuitin, tämä työnkulku voidaan keskeyttää, tämä julkaisu voidaan peruuttaa, tähän päätökseen voidaan hakea muutosta. Nämä vastaukset eivät ole tunnelmia. Ne ovat suunnittelua.
Tekoälyssä on aina epävarmuutta. Käytännön tehtävä on estää epävarmuutta muuttumasta rajoittamattomaksi auktoriteetiksi. Se tehdään rajapinnoilla, tiloilla, hallintatoimilla, todisteilla, paikallisuudella, arvioinnilla, palautuksella ja asianmukaisesti varustetulla inhimillisellä harkinnalla. Toisin sanoen järjestelmäsuunnittelulla. Ei siksi, etteivät arvot olisi tärkeitä, vaan siksi, että arvoista on tehtävä toteutettavia ennen kuin ne voivat suojella ketään.