Näin suunnittelet rajatun tekoälyavustajan: työkalut, käyttöoikeudet ja kontekstirajat

Rajattu tekoälyavustaja on suoritettava palvelusopimus, ei järjestelmäkehotteeseen kirjoitettu kieltolista. Vaikka mallille sanottaisiin, ettei se saa lähettää viestiä, todellisen rajan ratkaisevat käytettävissä oleva lähetystyökalu, toimiva tunniste, kohdejärjestelmän käyttöoikeudet ja suorituksen hyväksyntä. Kun nämä ovat liian laajoja, kohtelias kielto ei estä virheellistä toimintaa. Siksi avustajaa ei pidä valtuuttaa yhtenä kokonaisuutena: tiedon hakeminen, luonnostelu, tietueen päivittäminen ja viestin lähettäminen tarvitsevat kukin oman tietokehyksensä, identiteettinsä, toimintakattonsa, testinsä ja vastuuhenkilönsä.

Mitä tekoälyavustajan saa antaa tehdä?

Aloita yhden virkkeen palvelulupauksesta ja pura se sen jälkeen täsmällisiksi kyvykkyyksiksi. Toimiva muoto on: ”Avustaja saa auttaa [kelpoisia käyttäjiä] tekemään [sallitun tehtäväperheen] käyttäen [hyväksyttyä tietorajaa] ja tuottaa [sallitun lopputuloksen], mutta se ei saa [nimenomaiset ei-tavoitteet tai vaikutukselliset päätökset].” Ennen työkalujen kytkemistä nimeä käyttäjät, käyttöympäristö, tuetut tehtävät, tiedon rajat, ihmisen valvonta ja riskin omistaja. NIST AI RMF kokoaa vastaavia dokumentointitavoitteita, mutta tässä esitetty kyvykkyysmenetelmä on käytännön toimituksellinen synteesi, ei NISTin tai OWASPin vaatima lomake.

• Korvaa ”auta asiakaspalvelua” erillisillä toimilla, kuten hae tapaus, tiivistä aineisto ja laadi vastausluonnos.
• Erota päivittäminen, lähettäminen, poistaminen ja hyväksyminen omiksi kyvykkyyksikseen, vaikka ne näkyisivät samassa keskustelussa.
• Kirjaa ei-tavoitteiksi päätökset ja ulkoiset vaikutukset, joita palvelun ei ole tarkoitus tehdä missään tilanteessa.
• Pidä aloitus suppeana: OWASP suosittelee pienintä tarvittavaa työkalutoiminnallisuutta avoimen yleiskäyttöisen työkalun sijasta.

Hyvä kyvykkyyden nimi kertoo jo, mitä onnistuminen tarkoittaa. ”Näytä työntekijälle hänen käyttöoikeuksiinsa kuuluva tukitapaus” on suunniteltavissa ja testattavissa; ”hallitse asiakassuhdetta” ei ole. Tarkkuus paljastaa myös puuttuvan omistajuuden: tietojen lukemisesta voi vastata palvelun omistaja, mutta hyvityslupaus tai asiakkaan oikeuksien muuttaminen kuuluu erikseen hallittuun päätösprosessiin. Jos sama verbi peittää sekä tiedonhaun että ulkoisen sitoumuksen, toimivalta on jo määritelty liian karkeasti.

Mitä tietoa kukin kyvykkyys saa käyttää?

Kontekstiraja on tietokehys, joka määrittää kelvollisen aineiston ja luottamusrajat; se ei ole vain mallin tekninen sanakemäärä. Kirjaa kyvykkyydelle hyväksytyt järjestelmät, tietuetyypit, tietoluokat, kohde- ja päivämääräsuodattimet, ajantasaisuusvaatimus, käyttäjän omat oikeudet sekä aina kielletty tieto. NISTin mukaan järjestelmän tietämysrajat, kohdennettu soveltamisala ja tuotosten sallittu käyttö on dokumentoitava. Suurempi konteksti-ikkuna ei kuitenkaan lisää toimivaltaa eikä tee puuttuvasta, vanhentuneesta tai ristiriitaisesta aineistosta luotettavaa.

• Erota hyväksytty lähde siitä, saako kyseinen käyttäjä nähdä juuri tämän tietueen ja sen kentät.
• Merkitse ulkoiset viestit, liitteet, asiakirjat, API-vastaukset ja haettu sisältö epäluotettavaksi dataksi, joka ei saa muuttua palveluohjeeksi.
• Määritä istuntohistorialle ja pysyvälle muistille erilliset kelpoisuus-, eristys-, vanhenemis-, koko- ja poistoehdot.
• Estä tunnusten, salaisuuksien ja muun nimenomaisesti kielletyn tiedon tallentaminen kehotteisiin tai muistiin.

Muisti tarvitsee oman elinkaarensa, koska hyödyllinen keskusteluhistoria ja pysyvä organisaatiotieto eivät ole sama asia. Ennen tallennusta sisältö validoidaan, käyttäjien ja istuntojen tiedot erotetaan, eheys suojataan ja säilytys sidotaan todelliseen käyttötarpeeseen. Jos tehtävän edellyttämä lähde ei ole käytettävissä tai sen ajantasaisuutta ei voida osoittaa, avustajan on rajattava vastaustaan tai kieltäydyttävä. Se ei saa täyttää aukkoa uskottavan kuuloisella arvauksella eikä väittää tarkistaneensa lähdettä, jota se ei tavoittanut.

Miten identiteetti, työkalut ja käyttöoikeudet pakottavat rajat voimaan?

Raja pannaan toimeen erottamalla tunnistaminen, valtuuttaminen ja hyväksyntä sekä tarkistamalla oikeudet työkaluyhdyskäytävässä ja kohdejärjestelmässä. Kysy ensin, kuka käyttäjä, asiakasohjelma tai työkuorma on tunnistettu. Kysy sitten, saako tämä identiteetti tehdä tietyn operaation tietylle resurssille. Vasta kolmas kysymys on, onko juuri esikatseltu toimenpide hyväksytty. Kielimalli voi tulkita pyynnön, mutta kehote tai luonnollisen kielen suojalause ei ole käyttöoikeustarkastus. OWASP suosittelee vähimpiä taustajärjestelmäoikeuksia ja käyttäjän valtuutuskontekstin säilyttämistä.

• Valitse tietoisesti käyttäjän delegoitu toimivalta tai rajattu työkuormaidentiteetti; älä peri ylläpitäjän laajoja oikeuksia huomaamatta.
• Tarjoa tarkkarajainen toiminto validoituine parametreineen kokonaisen postilaatikon, tietokannan, selaimen tai komentotulkin sijasta.
• Rajaa suorituksessa verbit, resurssit, objektit, kentät, kohteet, tunnuksen voimassaolo ja käyttöoikeustunnuksen kohdeyleisö.
• Sovita kutsumäärän, uusintojen, ketjusyvyyden, eräkoon, kustannusten, ajan ja katkaisijan rajat kyseiseen palveluun.

Suojatuissa MCP-integraatioissa valtuutusmäärittely erottaa asiakkaan, resurssipalvelimen ja tunnuksia myöntävän valtuutuspalvelimen. Se tukee vähimpiä oikeusalueita ja tunnuksen sitomista tarkoitettuun resurssiin, mutta MCP ei määrää kaikkien työkalujen arkkitehtuuria. Yleispätevä periaate on suppeampi: tunnusta ei pidä voida käyttää odottamattomassa kohteessa, ja kohdejärjestelmän on tarkistettava jokainen pyyntö. Mallin oma vakuutus siitä, että toimi on sallittu, ei kelpaa todisteeksi.

Keskustelu voi jatkua yhtenäisenä, mutta sen toimivalta pitää jakaa pieniin, toisistaan riippumatta valvottuihin kyvykkyyksiin.

Kuinka paljon toimintavaltaa kyvykkyydelle kannattaa antaa?

Jokaiselle kyvykkyydelle tarvitaan selvä toimintakatto, ja ulkoista tilaa muuttava toimi tarvitsee vastaamista vahvemmat riippumattomat kontrollit. Käytännöllinen toimituksellinen asteikko kulkee vastauksesta tai tiivistelmästä ehdotukseen, luonnokseen, rajattuun palautettavaan kirjoitukseen ja vaikutukselliseen ulkoiseen toimeen. Viimeisenä ovat päätökset, joita palvelu ei saa tehdä. Asteikko ei ole NISTin, NCSC:n tai OWASPin virallinen luokitus, vaan niiden vähimpiä oikeuksia, toimintarajoja ja ulkoisia varmistuksia koskevista periaatteista johdettu suunnitteluväline.

1. Vastaus tai tiivistelmä käyttää vain kelvollista, käyttäjälle sallittua aineistoa eikä muuta ulkoista tilaa.
2. Suositus tai ehdotus näyttää perustan ja epävarmuudet mutta jättää vastuullisen päätöksen ihmiselle.
3. Luonnos syntyy ei-lopulliseen työtilaan, eikä se vielä muodosta ulkoista sitoumusta.
4. Rajattu palautettava kirjoitus muuttaa vain hyväksyttyjä objekteja ja kenttiä sekä tukee idempotenssia tai palautusta.
5. Vaikutuksellinen ulkoinen toimi, kuten lähetys, julkaisu, poisto, maksu, käyttöoikeuden myöntäminen tai tuotantomuutos, tarvitsee täsmällisen esikatselun ja erillisen suorituspolitiikan.
6. Kielletty päätös pysyy poissa työkalusta ja estetään myös taustajärjestelmässä, vaikka käyttäjä pyytäisi tai hyväksyisi sen keskustelussa.

Hyväksyntä koskee yhtä tarkastettavaa toimenpidettä. Sido se toimijaan, työkaluun, kohderesurssiin, normalisoituihin parametreihin, ajankohtaan ja vanhenemiseen, ja tarkista vastaavuus juuri ennen suoritusta. Jos vastaanottaja, sisältö tai muu olennainen parametri muuttuu, tarvitaan uusi tarkastus ja hyväksyntä. Hyväksyntä ei anna puuttuvaa käyttöoikeutta, laajenna pysyvää toimivaltaa eikä tee kielletystä päätöksestä sallittua. Maksut, käyttöoikeudet, tuhoavat toimet, tuotantomuutokset, ulkoiset sitoumukset ja korkean panoksen asiantuntijaratkaisut kuuluvat pätevän ihmisen ja deterministisen politiikan hallintaan.

Mitä tapahtuu, kun avustaja kohtaa rajansa?

Kieltäytyminen, turvallinen osittainen apu, ihmiskäsittely ja turvallisuuspoikkeaman eskalointi on suunniteltava erillisiksi palvelutuloksiksi, joilla on todellinen pysäytysehto. Avustajan pitää kertoa raja ymmärrettävästi paljastamatta arkaluonteisia käytäntöjä. Se ei saa väittää työkalukutsun, lähdetarkistuksen, hyväksynnän tai kirjoituksen onnistuneen, jos tapahtuma epäonnistui tai jäi tekemättä. NISTin arviointitavoitteisiin kuuluu turvallinen epäonnistuminen tietämysrajojen ulkopuolella. Käytännössä tämä tarkoittaa sekä mallin käyttäytymisen että suorituspolun determinististen kieltojen testaamista, ei pelkän mallin itse ilmoittaman varmuuden seuraamista.

• Luokittele syy: tehtävä ei kuulu palveluun, tieto ei ole kelvollista, valtuutus puuttuu, hyväksyntä tarvitaan tai näyttö on puutteellinen.
• Erota lisäksi asiantuntijaharkinnan tarve, riippuvuuden häiriö, toimintarajan täyttyminen ja havaittu turvallisuussignaali.
• Tarjoa vain turvallinen osa, kuten luonnos, tarkistuslista tai täsmällinen pyyntö puuttuvasta tiedosta.
• Liitä siirtoon tavoite, tarpeellinen ei-arkaluonteinen konteksti, yritetty kyvykkyys, syy, saatavilla oleva näyttö, seuraava vaihe ja jäljitystunniste.

Rutiininomainen palvelusiirto, liiketoiminnan hyväksyntä ja turvallisuuspoikkeama voivat hyödyntää samaa tapahtumatietoa, mutta niillä on eri omistaja ja kiireellisyys. Epäilty oikeuksien laajentaminen, hyväksynnän ohitus, tietojen ulosvienti, muistin saastuttaminen tai hallitsematon työkaluketju kuuluu ennalta määriteltyyn poikkeamapolkuun. NCSC suosittelee reagointi-, eskalointi- ja korjausskenaarioita, koulutettuja vastuuhenkilöitä ja laadukkaita tarkastuslokeja. Odottava suoritus pysyy pysäytettynä, ja muuttunut toimenpide validoidaan uudelleen sen sijaan, että vanha hyväksyntä käynnistäisi sen automaattisesti.

Miten rajat muutetaan toimivaksi kyvykkyyssuunnitelmaksi?

Täytä yksi suunnittelurivi jokaista käyttäjälle näkyvää toimintoa kohti ja yhdistä rivi teknisiin kontrolleihin, tapahtumatietoon, testeihin, mittareihin ja nimettyyn omistajaan. Älä kirjoita riviksi ”avustaja käyttää asiakkuusjärjestelmää”, vaan esimerkiksi ”tiivistä työntekijälle näkyvä tukitapaus”. Kirjaa kelpoinen toimija ja tunnistaminen, tietokehys, istunto- ja muistiehdot, suppea työkaluoperaatio, toimiva identiteetti, resurssirajaus, toimintakatto, hyväksyntä, käyttörajat, kieltäytyminen, lokinäyttö, arviointitapaukset ja eskalointi. Tämä kyvykkyyspohja on käytännön toimituksellinen synteesi, ei minkään lähdeorganisaation sertifiointivaatimus.

• Määritä onnistuminen käyttäjän tehtävän ja todellisen palvelutuloksen kautta.
• Tee näkyväksi, toimiiko työkalu käyttäjän delegoidulla oikeudella vai erillisellä työkuormaidentiteetillä.
• Kirjaa jokaiselle kyvykkyydelle myönteiset, raja-, kielto-, hyökkäys- ja riippuvuusvikojen testit.
• Valitse mittari, joka paljastaa rajanylitykset, toistuvat kiellot, valtuutusvirheet tai odottamattomat työkaluketjut.
• Nimeä taho, joka vastaanottaa palvelusiirron, tutkii poikkeaman ja voi tarvittaessa muuttaa tai poistaa kyvykkyyden käytöstä.

Sisäisen tukipalvelun esimerkki näyttää, miksi keskustelun yhtenäisyys ei saa tarkoittaa yhteisiä oikeuksia. Tapausyhteenveto tarvitsee vain käyttäjän nykyisiin oikeuksiin sidotun luvun. Vastausluonnos tarvitsee lisäksi hyväksytyn ohjeaineiston mutta vain ei-lopullisen kirjoituskohteen. Lähettäminen on erillinen vaikutuksellinen operaatio, joka tarkistaa vastaanottajan, hyväksytyn sisältöviitteen, valtuutuksen, hyväksynnän voimassaolon ja kaksoislähetyksen eston. Näin kukin vaihe voidaan evätä, mitata ja omistaa itsenäisesti.

Millaista näyttöä julkaisu ja jatkuva käyttö edellyttävät?

Julkaisu edellyttää näyttöä siitä, että sallittu palvelu toimii ja odotetut kiellot, pysäytykset sekä eskaloinnit toteutuvat käyttöä vastaavissa olosuhteissa. Pelkkä onnistuneiden esimerkkien sarja ei osoita rajan pitävyyttä. NIST AI RMF käsittelee käyttöä vastaavaa testausta, turvallista epäonnistumista, tuotantoseurantaa ja säännöllistä turvallisuusarviointia. NCSC puolestaan suosittelee turvallisuusarviointia ennen julkaisua sekä tunnettujen rajoitusten ja vikatapojen viestimistä. Testinäytön pitää kohdistua julkaistavaan kyvykkyyteen, käytäntöversioon, työkaluihin ja todelliseen suorituspolkuun.

• Testaa sallitut tehtävät sekä toisen käyttäjän tiedot, luvaton työkalu, vanhentunut näyttö, saastutettu hakusisältö ja kielletty tietoluokka.
• Testaa hyväksynnän ohitus, hyväksynnän jälkeen muuttuneet parametrit, kaksoisuusinnat, riippuvuuden häiriö, tietojen ulosvientiyritys ja hallitsematon ketju.
• Varmista, että tapahtumista voidaan rekonstruoida pyytäjä, kyvykkyys, käytäntö, lähde- ja työkaluluokka, valtuutus, hyväksyntä, lopputulos ja käytössä olleet versiot.
• Peitä salaisuudet ja vältä rajattoman arkaluonteisen keskustelusisällön keräämistä lokiin.
• Seuraa odottamatonta työkalukäyttöä, toistuvia kieltoja, valtuutusvirheitä, hyväksyntämuutoksia, poikkeavia toimintaketjuja, viivettä, resurssikäyttöä ja palveluvikoja.

Nimeä erikseen palvelukäyttäytymisen, käyttöoikeuksien, liiketoimintasiirtojen ja turvallisuuspoikkeamien omistajat sekä anna heille valta keskeyttää, muuttaa tai poistaa kyvykkyys. Avaa asiaankuuluvat testit ja julkaisunäyttö uudelleen, kun malli, kehote, tiedonhaku, muisti, työkalu, oikeus, käytäntö, aineisto, palveluntarjoaja tai käyttöympäristö muuttuu olennaisesti. Aloita pienimmästä hyödyllisestä kyvykkyydestä ja laajenna toimivaltaa käsiteltyinä muutoksina, ei pelkkinä kehote­muokkauksina. Arkaluonteista tietoa, pysyvää muistia, etuoikeutettua pääsyä tai ulkoisia sitoumuksia koskevissa muutoksissa ota mukaan organisaation turvallisuus-, identiteetti-, tietosuoja-, tiedonhallinta-, riski- ja palveluomistajat.