Hassabis ja Brad Smith kutsuvad agentide turvet tugevdama, ühist standardit veel pole

Dublini International AI Summitil kutsusid Demis Hassabis ja Brad Smith tugevdama AI-süsteemide turvet ning järelevalvet. Reutersi 14. oktoobri kohapealne kajastus kirjeldab Hassabise hoiatust, et praegustest juhtumitest võivad süsteemide võimekuse kasvades kujuneda palju tõsisemad probleemid. See on tema tulevikuhinnang, mitte kinnitatud prognoos konkreetse intsidendi aja kohta.

Hassabis pooldas riski muutumisega kaasas käivat sertifitseerimist; Smith rõhutas seaduste ja reeglite vajadust. Ka The Irish Times kajastas kohtumise arutelu rangemate kaitsemeetmete üle. Iirimaa ametlik ürituseteade kinnitab 14. oktoobri tippkohtumise ja Hassabise osalemise, kuid tema seisukohtade allikas on ajakirjanduslik kohapealne raport.

Uut ühist standardiorganit ega jõustumistähtajaga kokkulepet nendest teadetest ei tulene. Buildrya hinnangul ei pea ettevõte siiski ootama rahvusvahelist lahendust, et enda agentide õigused ja tegevus kontrollitavaks muuta. Alustada saab sellest, kas intsidendi korral on teada ülesanne, mudeliversioon, tööriistakutsed ja tegelikud tagajärjed.

Mudeli lubaduse asemel tuleb kontrollida tegevusõigust

Vestlusvastuse ja välises süsteemis tehtud toimingu mõju on erinev. Agent võib esitada eksliku väite, kuid ta võib ka muuta andmeid, käivitada koodi või saata sõnumi. Riskihinnang peab arvestama, millised neist võimalustest on konkreetses töövoos tegelikult lubatud.

Seetõttu võiks õigused siduda ülesandega. Dokumendi kokkuvõtteks ei ole vaja andmebaasi muutmist; veaotsinguks ei pruugi olla vaja tootmiskeskkonda juurutamist. Mida selgem on lubatud ulatus, seda lihtsam on märgata selle ületamist ja tegevus peatada.

See kontroll peab rakenduma tööriistade või ligipääsu kihis. Mudelile antud tekstiline juhis on üks osa töökorraldusest, kuid ei tõenda, et keelatud tegevus oleks tehniliselt välistatud. Sertifitseerimisest rääkides tuleks samuti küsida, millist süsteemikihti tegelikult hinnatakse.

Intsidendiskeem peab säilitama põhjuse ja tagajärje

Kasulik intsidendikirje võiks alata kasutaja antud ülesandest ja agendile lubatud tegevustest. Seejärel tuleb siduda mudeliversioon, tööriistakutsed ning välises süsteemis toimunud muutused. Ainult vestluse lõpptekst ei pruugi näidata, mida agent vahepeal tegi.

Kirjes tuleks eristada agendi enda selgitust kontrollitud süsteemisündmusest. Agent võib väita, et makse ebaõnnestus või fail jäi muutmata, kuigi tegelik olek on teine. Intsidendi lahendamiseks on vaja sõltumatut kontrolli nende süsteemide logidest, kus tegevus toimus.

Andmete kogumine peab olema eesmärgipärane. Toorlogid võivad sisaldada saladusi ja isikuandmeid, mistõttu ligipääs ning säilitamine vajavad oma piire. Kontrollitav ajalugu ei tähenda, et kogu sisu peaks olema kõigile nähtav või piiramatult säilima.

Peatamine peab ulatuma pooleliolevate tööriistadeni

Vestluse sulgemine ei pruugi lõpetada juba käivitatud protsessi. Kui agent alustas välise teenuse tööd, ajastas tegevuse või andis käsu teisele süsteemile, peab katkestamise korral teadma ka nende olekut. Muidu võib kasutaja näha peatatud agenti, samal ajal kui mõju jätkub.

Praktiline peatamisrada võiks hõlmata uute kutsete keelamist, olemasolevate võtmete vajaduspõhist tühistamist ja pooleliolevate toimingute kontrolli. Tühistamatu sammu puhul tuleb teada, mida saab veel piirata ja mida hiljem parandada. Neid võimalusi tasub proovida enne päris intsidenti.

Samuti peab olema määratud inimene, kes võib töövoo uuesti käivitada. Automaatne taaskäivitus võib sama vea kordust toita, kui põhjus jäi lahendamata. Taastamise tingimus võiks põhineda kontrollitud parandusel, mitte ainult sellel, et agent enam veateadet ei näita.

Teavitamine vajab selget vastutust

Kui agendi tegevus puudutab klienti, partnerit või teist süsteemi, ei pruugi tehnilise vea parandamine olla piisav. Organisatsioon peab teadma, kes hindab mõju ja korraldab vajaliku suhtluse. Käesolev ettepanek ei määra universaalset õiguslikku teavitamistähtaega, sest see sõltub juhtumist ja kohaldatavatest nõuetest.

Sisemises skeemis võiks olla nähtav mõjutatud teenus, andmed, osapooled ja taastamise seis. See aitab vältida olukorda, kus arendustiim peab vea lahendatuks, kuid klienditoel puudub teave tehtud valede toimingute kohta. Sama kirje saab toetada hilisemat põhjuse analüüsi.

Õppimise jaoks tuleb säilitada ka juhtumid, mis peatusid enne kahju. Need võivad näidata õiguste liigset ulatust või katsetest puuduvaid olukordi. Kõiki selliseid juhtumeid ei pea nimetama samaväärseks päris välise mõjuga intsidendiga.

Riskipõhine standard vajab ulatust ja uuendamise korda

Hassabise kirjeldatud kohanduv lähenemine jätab lahtiseks praktilised küsimused: kes kontrollib, millist tõendit nõutakse ja millal tuleb hinnang uuesti teha? Agendi mudeli, tööriistade või õiguste muutmine võib muuta süsteemi riski ka siis, kui tootenimi jääb samaks.

Ettevõtte jaoks võiks hindamine seetõttu olla seotud kindla konfiguratsiooniga. Muudatuste register peaks näitama, millal lisati uus tööriist või anti suurem ligipääs. Varem tehtud test ei tõenda automaatselt uue töövoo sobivust.

Suurte tarnijate avalik toetus turvameetmetele on oluline poliitiline signaal, kuid ei asenda rakendatavat kontrolli. Järgmine sisuline areng oleks konkreetne standardi tekst, hindamise kord ja vastutuse jaotus. Seni saab organisatsioon ise muuta agentide käitumise uuritavaks ja kahjuliku tegevuse peatamise proovitud protsessiks.