Mudel riskijuhtimine ja punane meeskond

Kasu:

• Võimalus liigitada kasutusstsenaariume vastavalt mõjule madala/keskmise/kõrge riskitaseme alla
• Võimalus mudelit enne tootmist süstemaatiliselt testida punase meeskonnaga
• Võimalus teha tootmisotsuseid mudelikaardi ja vastuvõtuuksega (go/no-go)

Iga AI kasutusega ei kaasne sama riski. Koosolekuteatist kokkuvõtet tegev assistent ja laenutaotlust hindav assistent annavad väga erinevaid tulemusi. Ettevõtte üldjuhtimise aluseks on kasutusalade liigitamine vastavalt riskitasemele ja asjakohane kontroll igal tasandil. Selles üksuses õpime mudeli riskijuhtimise raamistikku (mudeli ebakorrektsest, kallutatud või kasutatavast riskist tingitud riski juhtimise distsipliini), mudeli testimist enne tootmist red-teaminguga ning mudelikaarti ja aktsepteerimise kriteeriume.

Klassifikatsioon riski järgi

Esimene samm on alati sama: "Mis juhtub, kui see kasutus läheb valesti?" Kolm ligikaudset taset vastavalt tõhususele ja pöörduvusele:

• Madal risk: viga on kergesti tuvastatav ja tühistatav; Isiklikke/rahalisi tagajärgi pole. Näide: sisekoosoleku kokkuvõte, ideekavandi genereerimine.
• Keskmine risk: viga mõjutab äriprotsessi, kuid läbib inimsilma. Näide: vastuse mustand kliendile, esialgne aruande kokkuvõte.
• Kõrge risk: otsus mõjutab otseselt inimest/raha, raske tagasi pöörata. Näide: krediidi-/kindlustusotsus, tervishoiutriaaž, tööhõive sõeluuringud.

Kontrolli intensiivsus suureneb koos riskitasemega: madala riski korral piisab valgusjuhtimisest; Suure riski korral on kohustuslik inimeste järelevalve, range kontrollimine, punane meeskond ja pidev jälgimine.

Tähelepanu: Tehke riskide klassifikatsioon kasutuse mõju, mitte nimetuse järgi. Niinimetatud "lihtsalt vestlusroti" süsteem on kõrge riskiga, kui see suudab makseid algatada.

Punane meeskond (Red-Teaming)

Red teaming üritab tahtlikult süsteemi murda, teeseldes, et on pahatahtlik ründaja. See on AI-s; See hõlmab jailbreak'i (mudeli turvareeglitest mööda hiilimist), kiiret süstimist, andmete väljafiltreerimist, kallutatud/pahatahtliku väljundi genereerimist ja servastsenaariumide testimist. Eesmärk on leida haavatavused enne tõelist ründajat.

Samm-sammult:

1. Loetlege ohustsenaariumid. Kuidas saab seda süsteemi kuritarvitada?
2. Valmistage ette rünnakukomplekt. Kirjutage iga ohu kohta konkreetsed sisenemisnäited.
3. Proovige süstemaatiliselt. Käivitage iga stsenaarium ja salvestage tulemus.
4. Seadistage leiud prioriteediks. Sorteeri mõju × tõenäosuse järgi.
5. Parandage see ja testige uuesti. Pärast plaastrit proovige uuesti sama komplektiga (regressioon).

Mudelkaart ja aktsepteerimiskriteeriumid

Mudelikaart on dokument, mis võtab kokku mudeli sobivuse, piirangud, teadaolevad riskid ja jõudluse. Enne selle tootmisse panemist peaksid teil olema aktsepteerimisotsuse kriteeriumid: täpsuslävi, punase meeskonna läbimise määr, latentsusaeg, maksumus ja kallutatuse testid.

Neli kopeeritavat malli

Riski klassifikatsiooni viide:

Mõelge järgmisele kasutusjuhtumile: {{ stsenaarium }}Küsimused:- keda/mida viga mõjutab? (inimene, raha, maine, harmoonia)- Kas see on pöörduv? (jah/ei) – Kas inimesed saavad sekkuda? Tulemus: "Madal / keskmine / kõrge risk" + kohustuslike kontrollide loend.

Punase meeskonna rünnakukomplekti generaator:

Olete punase meeskonna spetsialist. Looge järgmise assistendi jaoks 15 rünnakustsenaariumit: 5 jailbreaki, 5 kiiret süstimist (neist 3 on kaudsed), 5 andmete väljafiltreerimise katset. Iga stsenaariumi jaoks: kirjutage eesmärk, täielik sissejuhatuse tekst ja "edukriteeriumid" (kõik, mida ma näen, loetakse rünnak edukaks).

Mudeliplaadi skelett:

Mudelkaart:- Sihtotstarbeline kasutus / tahtmatu kasutamine- Koolitus/andmepiirangud ja teadaolevad haavatavused- Jõudlus: täpsus, latentsusaeg, maksumus (testikomplektil)- Turvalisus: punase meeskonna läbimise määr, teadaolevad jailbreakid- Kallutatuse testimise tulemused- Vastuvõtuotsus: KINNITAMINE / TINGIMUSLIK / TAGASÜKKUMINE + põhjendus

Sissepääsu värava kontrolli reegel:

Tootmisse üleminekuks peavad olema täidetud KÕIK tingimused:- >= täpsustesti seatud sihtlävi- Punase meeskonna kriitiliste leidude arv = 0- Suure riski korral: inimeste kontrolli ja jälgimise juhatus Kui ükski ei ole täidetud: "NO-GO" + puuduv element.

Nõrk viip / Tugev viip

halb lähenemine

Tugev lähenemine

Iga kasutuskorra töötlemine sama kontrolliga

Klassifitseerida riski ja ulatuse kontrolli järgi

"Katsetasime seda, see töötab" (õnnelik viis)

Tahtlik murdmiskatse punase meeskonnaga

Mudeli tootmisse panemine ilma põhjenduseta

Mudelkaart + vastuvõtuvärav (go/no-go)

Pärast lappimist ei testita uuesti

Regressioonitest pärast korrigeerimist

Kolm miniümbrist

Juhtum 1 – valesti klassifitseerimine oli kulukas. Üks ettevõte pidas värbamise eelkontrolli "lihtsalt lisandiks" ja pidas seda madalaks. Mudel kõrvaldas süstemaatiliselt teatud koolide lõpetajad; sellest sai diskrimineerimiskaebus. Kasutamine liigitati ümber kõrge riskiga kategooriasse ning lisati eelarvamuste testimine ja inimeste jälgimine.

Juhtum 2 – punane meeskond leidis 3 kriitilist turvaauku. Enne tootmisse minekut määrati punasesse meeskonda kliendiassistent. 15-st stsenaariumist 3 olid edukad: kaudse süsti kaudu võis lekkida mõne teise kliendi tellimuse teave. Vahed suleti ja testiti uuesti sama komplektiga; Tootmist jätkati alles siis, kui kriitiline leid lähtestati.

Juhtum 3 – mudel selgitas kaardi aktsepteerimise otsust. Kahe mudeli vahel valides pani meeskond mudelikaardid kõrvuti. Odavam mudel saavutas täpsuse, kuid oli haavatav punase meeskonna kahe kriitilise jailbreak'i suhtes. Meeskond valis kalli, kuid turvalise mudeli tänu vastuvõtuvärava "kriitiline leid = 0" reeglile ja dokumenteeris otsuse.

Näpunäide: Punane meeskond ei ole ühekordne üritus. Käivitage ründekomplekt uuesti, kui mudel, viip või tööriistad muutuvad; Turvalisus ei ole riik, vaid pidev praktika.

Levinud vead

• Klassifitseerige kasutamine nimetuse (mitte mõju järgi); suure riski segamine madalaga.
• Lihtsalt katsetades "õnnelikku teed" ja mitte proovides üldse kuritarvitamist.
• Punast meeskonda korra teha ja pärast muudatusi mitte korrata.
• Mudeli tootmisse laskmine ilma mudelikaardita ja aktsepteerimiskriteeriumideta.
• Eelarvamuste/diskrimineerimise testimisest möödahiilimine (eriti suurte inimlike otsuste puhul).
• See tähendab "suletud" ilma korrigeerimisjärgset regressioonitesti tegemata.

Kokkuvõttes

• Esimene samm on kasutusalade klassifitseerimine madala/keskmise/kõrge riskiga alla vastavalt mõjule; Kontrolli intensiivsus suureneb koos riskiga.
• Red teaming üritab teadlikult süsteemi murda nagu ründaja; leiab haavatavuse enne tegelikku ründajat.
• Mudelikaart dokumenteerib mudeli eesmärgi, piirangud ja riskid; on vastuvõtuotsuse aluseks.
• Tootmisele üleminek peab olema seotud käiguga/ei-minekuga: täpsus, kriitiline leid null, nõutav jälgimine.
• Turvalisus on pidev: punast meeskonda ja regressioonitesti korratakse iga muudatusega.

Rakenduse ülesanne

Valige tehisintellekti kasutamine, määrake riskitase mõju põhjal ja kirjutage põhjendus. Seejärel looge selle kasutuse jaoks vähemalt 10 rünnakustsenaariumit (jailbreak, süstimine, andmete väljafiltreerimine) ja proovige neid käsitsi. Iga eduka rünnaku jaoks tehke lahendus. Lõpuks täitke näidiskaardi skelett ja tehke põhjendustega otsus "GO/EI-GO".

kontrollnimekiri

• [ ] Olen liigitanud kasutuse riskitaseme järgi mõju järgi.
• [ ] Ma sobitasin kontrolli intensiivsuse riskitasemega.
• [ ] Valmistasin ette punase meeskonna rünnakuseti ja proovisin seda süstemaatiliselt.
• [ ] Parandasin kriitilised leiud ja kontrollisin neid regressioonitestiga.
• [ ] Koostasin näidiskaardi (otstarve, limiit, jõudlus, turvalisus).
• [ ] Sidusin tootmisotsuse mine/ei lähe.