Bezpečnosť AI je hlavne návrh systémov
Bezpečnostné stretnutie po demo
Demo prebehlo dobre, ako zvyčajne. Model prečítal stoh interných dokumentov, odpovedal na otázku o politike, navrhol ďalší krok a vytvoril prehľadné zhrnutie do spisu. Miestnosť prikyvovala. Niekto sa spýtal, či by sa dal pripojiť k systému pracovných postupov. Niekto iný sa spýtal, ako skoro. Potom sa bezpečnostný referent spýtal, čo by sa stalo, keby sa model mýlil, ale bol presvedčivý. Miestnosť sa zrazu veľmi zaujímala o sušienky.
Táto otázka je miestom, kde začína praktická bezpečnosť umelej inteligencie. Nie v abstrakcii a nie v slogane. V tvare systému okolo modelu, ktorý sa niekedy mýli, niekedy je zastaraný, niekedy príliš sebavedomý, niekedy málo sebavedomý a niekedy má pravdu z nesprávneho dôvodu. Bezpečnostný problém nie je len správanie modelu. Je to to, čo systém tomuto správaniu dovolí urobiť.
Model, ktorý navrhne vetu, je jedno riziko. Model, ktorý aktualizuje rozhodnutie o dávke, je iné. Model, ktorý volá nástroj s právom zápisu, je ďalšie. Model, ktorý smeruje pacienta, zamieta reklamáciu, mení úverový limit alebo riadi zariadenie, patrí do úplne inej triedy nebezpečenstva. Ten istý model môže byť neškodný, užitočný, rizikový alebo neprijateľný v závislosti od hraníc, stavu, dôkazov, oprávnení, monitorovania a obnovy. Preto je bezpečnosť umelej inteligencie z väčšej časti návrh systémov.
Slovné spojenie „z väčšej časti“ v tejto vete nesie význam. Výskum modelov je dôležitý. Kvalita údajov je dôležitá. Metódy zosúladenia sú dôležité. Veda o hodnotení je dôležitá. Ale keď organizácia nasadí umelú inteligenciu, bezpečnosť sa stáva prevádzkovou záležitosťou. Kto sa môže pýtať. Čo model smie vidieť. Čo smie zmeniť. Aký dôkaz sa vyžaduje. Aký stav sa zachováva. Čo sa stane, keď si zdroje protirečia. Kedy musí človek schváliť. Ako sa zisťuje odchýlka. Ako sa stiahne chybná verzia. Toto sú otázky návrhu skôr, než sú vyhláseniami o etike. Vyhlásenie o etike môže byť úprimné. Systém úprimnosť nevykonáva.
Bezpečnosť je problém riadenia
Keď ľudia počujú slovo bezpečnosť, často si predstavia hodnoty, tréningové údaje, politiky odmietania a zosúladenie modelu. Toto všetko je súčasťou obrazu, ale nasadený systém potrebuje aj riadenie. Riadenie je niečo, čo mení to, čo sa môže stať: kontrola prístupu, schéma, časový limit, prah, schválenie človekom, sandbox, limit rýchlosti, overovač, vrátenie zmien, núdzové vypnutie, záznam, ktorý nemožno upraviť cez servisnú cestu. Riadenie je nudné, kým nechýba. Potom sa stane celou náplňou stretnutia.
Bezpečný systém umelej inteligencie predpokladá, že model môže zlyhať, a podľa toho navrhuje okolité mechanizmy. Oddeľuje návrh od konania. Obmedzuje oprávnenia nástrojov. Pred zmenou stavu kontroluje dôkazy. Zviditeľňuje neistotu. Zaznamenáva verziu modelu a rozsah zdrojov. Odmieta pracovať, keď chýbajú povinné polia. Operátorom dáva možnosť pozastaviť automatizáciu. Výstup modelu považuje za návrh, nie za príkaz z veľmi výrečnej tabuľky.
Toto je bežné bezpečnostné inžinierstvo s jazykovým modelom v strede. Letectvo, medicína, železnice, priemyselné riadenie aj financie sa naučili, že dôležité systémy potrebujú viacúrovňové kontroly, pretože žiadny komponent nie je dokonalý. Verzia s umelou inteligenciou pôsobí novátorsky, pretože komponent rozpráva. Reč robí zlyhanie spoločensky presvedčivým. Nesprávna odpoveď, ktorá znie pokojne, môže unaveného operátora obísť ľahšie ako blikajúca červená chyba. Návrh kontroly preto musí byť tvrdohlavejší než próza.
Návrh kontroly začína otázkou, čo systém smie ovplyvniť. Ak AI môže len navrhovať, bezpečnosť sa zameriava na kvalitu zdrojov, kontroly halucinácií, jasnosť rozhrania a recenzie. Ak môže smerovať prácu, bezpečnosť pridáva sledovanie stavu, integritu frontu, úrovne služieb a odvolacie cesty. Ak môže volať nástroje, bezpečnosť pridáva rozsahy oprávnení, validáciu argumentov, transakčné protokoly a kompenzačné opatrenia. Ak môže ovplyvniť práva alebo fyzické systémy, bezpečnosť vyžaduje dôkazy, formálne preskúmanie, obmedzenú autonómiu a seriózne plánovanie incidentov. Model je jedna časť. Envelope oprávnení je druhá.
Hranica je produkt
Najdôležitejšia čiara v systéme AI často nie je viditeľná v rozhraní. Je to hranica medzi čítaním a písaním, odporúčaním a rozhodovaním, sumarizáciou a zaznamenávaním, asistovaním a konaním. Slabé hranice sú dôvodom, prečo sa neškodné prototypy stávajú nebezpečnými službami. Model, ktorý začne ako pomôcka na návrhy, dostane tlačidlo na použitie návrhu. Potom dostane nástroj na aktualizáciu prípadu. Potom dostane pravidlo smerovania, pretože tím je zaneprázdnený. O šesť mesiacov nikto nevie vysvetliť, ktoré rozhodnutia sú automatizované a ktoré len asistované. Toto nie je zlý úmysel. Je to rozširovanie rozsahu v pohodlných topánkach.
Dobré hranice sú explicitné a kontrolovateľné. Model môže čítať tieto zdroje, nie tamtie. Môže navrhovať tieto polia, ale nie ich potvrdzovať. Môže volať tento nástroj s týmito argumentmi, nie s ľubovoľným textom. Môže smerovať prípady s nízkym rizikom, nie sporné prípady. Môže odpovedať len vtedy, keď sú dôkazy aktuálne. Nesmie použiť súkromné poznámky na verejné vysvetlenia. Nesmie prejsť z jedného nájomcu, regiónu, účtu alebo právneho základu do druhého len preto, že ďalší odsek vyzeral užitočne.
Hranice je tiež potrebné presadzovať mimo modelu. Výzva, ktorá hovorí, aby sa nepísalo do databázy zákazníkov, nie je hranica, ak má nástroj právo zápisu a žiadnu bránu. Systémová správa, ktorá hovorí o citovaní zdrojov, nie je hranica, ak sa odpovede môžu ukladať bez citácií. Odsek politiky, ktorý hovorí, že sa vyžaduje schválenie človekom, nie je hranica, ak pracovný postup umožňuje automatizácii označiť schválenie. Bezpečnostné pokyny v modeli sú užitočné, ale nestačia. Systém musí urobiť nebezpečné cesty ťažkými alebo nemožnými.
Toto je neromantická práca, ktorá skutočne chráni ľudí. Typované volania nástrojov. Úzke rozsahy. Predvolené režimy len na čítanie. Samostatné služby schvaľovania. Idempotentné operácie. Audítorské protokoly. Verzované politiky. Stavy frontov. Explicitné stavy odmietnutia. Slovná zásoba znie, ako keby backendový inžinier mal tichý víkend s tabuľou. Dobre. Bezpečnosť vo výrobe zvyčajne takto vyzerá. Nesnaží sa vyhrať súťaž o slogan.
Stav je miesto, kde sa bezpečnosť stáva skutočnou
Konverzácie s AI môžu vyvolať dojem, že systémy sú bezstavové. Používateľ sa opýta, model odpovie, obrazovka sa zmení. Produkcia bezstavová nie je. Prípady sa posúvajú. Tikety starnú. Oprávnenia expirujú. Dokumenty sa opravujú. Zmení sa verzia modelu. Človek prehlasuje odporúčanie. Príde odvolanie. Používateľ sa pýta, prečo sa niečo stalo minulý mesiac. Bezpečnosť závisí od toho, či si systém zachoval stav potrebný na odpoveď.
Stav systému hovorí, čo sa už stalo a čo sa môže stať ďalej. Bez neho model vidí výsek a zvyšok si domýšľa. Takto vznikajú duplicitné akcie, zanikajú termíny, predpokladajú sa schválenia a staré dôkazy sa vracajú do nového rozhodnutia. Bezpečný pracovný postup zaznamenáva explicitné stavy: koncept, chýbajúci dôkaz, blokované pravidlami, vyžaduje sa kontrola, schválené, vykonané, napadnuté, opravené, stiahnuté. Tieto stavy nie sú dekoratívne. Zabránia modelu, aby s dôležitým procesom zaobchádzal ako s chatovým prepisom s ambíciami.
Stav dáva ľuďom aj páku. Operátor môže zistiť, prečo je prípad v kontrole. Manažér vidí, či automatizácia nevytvára backlog. Audítor môže prehrať, ktoré verzie zdrojov boli aktívne. Používateľ môže napadnúť výsledok niečím pevnejším ako snímka obrazovky. Vývojár môže zmerať, či nový model zvyšuje odmietania, eskalácie alebo prepracovanie. Bez stavu sa každá konverzácia o bezpečnosti stáva divadlom. Ľudia hovoria o zodpovednosti, ale systém stratil podstatné mená.
Pre AI by stav mal zahŕňať verziu modelu a pravidiel, identifikátor promptu alebo šablóny, množinu zdrojov, čas získania údajov, volania nástrojov, mieru istoty alebo neistoty, dôvod odmietnutia, ľudskú akciu a následný vplyv. Nie všetko patrí do jedného riadku logu a nie všetko by malo byť viditeľné pre každého. Súkromie a bezpečnosť sú dôležité. Ale informácie musia existovať pod kontrolovaným prístupom. Inak sa bezpečnosť stáva závislou od pamäte a pamäť je známe zlá databáza s výbornými výhovorkami.
Dôkazy sú bezpečnostné zábradlie
Odpoveď modelu je bezpečnejšia, keď je prepojená s dôkazmi. Znie to samozrejme, až kým systém nie je pod tlakom. Dôkazy sa vynechávajú, pretože pridávajú latenciu. Citácie sa ukladajú ako text, nie ako identifikátory. Skóre vyhľadávania sa nezachováva. Verzie zdrojov sa prepisujú. Model napíše sebavedomé vysvetlenie z dokumentu, ktorý bol medzitým opravený. Neskôr sa všetci pýtajú, prečo bola odpoveď nesprávna. Odpoveď je, že zábradlie bolo dekoratívne.
Užitočné dôkazy nie sú poznámka pod čiarou. Sú reťazou. Žiadosť vstúpila s identitou a účelom. Zdroje boli vybrané na základe povolenia. Vyhľadávanie našlo konkrétne časti alebo záznamy. Model vytvoril výstup pod pomenovanou verziou. Overovateľ skontroloval tvrdenia alebo prahy. Človek prijal, upravil alebo zamietol. Akcia zmenila stav. Systém uložil dostatok tejto reťaze na to, aby ju mohol prehrať alebo spochybniť. Toto nie je byrokracia sama pre seba. Takto bezpečnosť prežíva čas.
Dôkazy tiež chránia model pred tým, aby bol požiadaný o nemožnú prácu. Ak systém vyžaduje aktuálne zdroje, model môže odmietnuť zastaraný vstup. Ak systém vyžaduje dva zodpovedajúce záznamy, môže označiť nezrovnalosť. Ak systém vyžaduje identifikátory zdrojov, môže zastaviť nepodložené tvrdenia. Model už nemusí meniť chýbajúce dôkazy na plynulé riadenie neistoty. Môže vrátiť bezpečný stav. Toto je láskavejšie k modelu a oveľa láskavejšie k človeku, ktorého sa výstup týka.
Existuje rovnováha. Zachytávanie dôkazov by sa nemalo stať sledovaním. Citlivý obsah môže byť hašovaný, redigovaný, oddelený alebo uchovávaný po obmedzenú dobu. Nejde o to zaznamenať všetko navždy. Ide o to zachovať fakty potrebné na preskúmanie dôležitého správania. Bezpečnosť bez dôkazov je len dôvera v krajšom kabáte. V lobby môže vyzerať dobre. Pri incidente neobstojí.
Ľudia potrebujú navrhnutú autoritu
Človek v slučke sa často používa ako magická fráza. Nie je to mágia. Unavený recenzent so slabými dôkazmi, nejasnou politikou a radom dvesto prípadov nie je bezpečnostný systém. To je človek umiestnený na koniec dopravného pásu a požiadaný, aby bol riadením. Môže to fungovať krátko, najmä ak je ten človek skúsený a húževnatý. Nie je to dizajn.
Ľudská autorita musí byť konkrétna. Ktoré prípady vyžadujú preskúmanie. Aké dôkazy recenzent vidí. Môže recenzent meniť štruktúrované polia alebo len schvaľovať prózu. Vie recenzent, či bol model neistý alebo či politika vyžadovala eskaláciu. Sú nezrovnalosti vrátené do hodnotenia. Sú recenzenti chránení pred zaujatosťou automatizácie. Môžu pozastaviť pracovný postup. Môžu eskalovať špecialistovi. Môžu vidieť podobné minulé prípady. Môžu vysvetliť rozhodnutie dotknutej osobe. Tieto detaily rozhodujú o tom, či je ľudský dohľad skutočný alebo ozdobný.
Dobrý dohľad tiež oddeľuje úsudok od administratívneho upratovania. Ľudia by nemali tráviť čas hľadaním chýbajúcich identifikátorov zdrojov, odstraňovaním duplicitných pokusov, prekladaním výstupov modelu do stavov pracovných postupov alebo hádaním, ktorá verzia politiky sa použila. Systém by mal zabaliť prípad. Človek by mal uplatniť úsudok tam, kde je úsudok potrebný: sporný význam, výnimka, proporcionalita, kontext, empatia a zodpovednosť. Ak človek väčšinou upratuje medzery v infraštruktúre, organizácia si pomýlila personálne obsadenie s bezpečnosťou.
Návrh musí tiež umožniť ľuďom nesúhlasiť s automatizáciou bez toho, aby sa trenie stalo trestom. Ak prepísanie modelu vyžaduje osem kliknutí a prijatie jedno, rozhranie má politiku. Ak eskalácia spôsobí, že tím vyzerá pomaly, ľudia sa eskalácii vyhnú. Ak metriky odmeňujú iba priepustnosť, bezpečnostné kontroly sa stanú ceremoniálnymi. Návrh systémov zahŕňa stimuly, obrazovky, fronty a predvolené hodnoty. Model možno metriku nepozná, ale ľudia ju určite poznajú.
Lokalita mení riziko
Kde sa práca umelej inteligencie vykonáva, je dôležité. Systém, ktorý posiela každý dokument vzdialenému modelu, má iné riziká ako systém, ktorý vykonáva extrakciu v blízkosti údajov a posiela iba odvodené pole. Systém, ktorý ukladá záznamy v službe obsluhy, má iné riziká ako systém, ktorý vedie nezávislé audítorské záznamy. Systém, ktorý sa spolieha na jediný externý smerovač, má iné možnosti obnovy ako systém, ktorý sa môže lokálne degradovať. Lokalita nie je nacionalizmus s diagramom siete. Je to praktická otázka, ktoré riziká sa presúvajú, keď sa presúvajú údaje, výpočtový výkon, politika a dôkazy.
Niektorá práca by sa mala vykonávať v blízkosti citlivých údajov, pretože presun údajov vytvára expozíciu. Niektorá práca by sa mala vykonávať v blízkosti používateľov, pretože latencia ovplyvňuje bezpečnosť. Niektorá práca by sa mala vykonávať v centrálnej službe, pretože je potrebná špecializovaná kontrola alebo hardvér. Niektoré dôkazy by sa mali ukladať mimo cesty obsluhy modelu, pretože cesta obsluhy môže byť predmetom vyšetrovania. Bezpečný návrh je zriedka všetko lokálne alebo všetko vzdialené. Je to zámerné umiestnenie.
Lokalita tiež ovplyvňuje právnu a organizačnú zodpovednosť. Ak volanie modelu prekračuje regióny, ktorý zákon sa vzťahuje na údaje. Ak je index vytvorený mimo zdrojového systému, ako sa šíria výmazy. Ak dodávateľ zmení model, ako sa prijíma oznámenie a vykonáva testovanie. Ak sú denníky v portáli dodávateľa, môže ich organizácia exportovať počas incidentu. Toto nie sú abstraktné otázky suverenity. Sú to bezpečnostné otázky, pretože určujú, či organizácia môže kontrolovať a vysvetliť systém v záťaži.
Nesprávne umiestnenie môže predražiť bezpečné správanie. Ak každý overovací krok vyžaduje vzdialenú cestu tam a späť, tímy môžu vzorkovať namiesto kontroly každého prípadu. Ak je ťažké spájať audítorské údaje, vyšetrovania sa spomaľujú. Ak súkromné údaje musia cestovať kvôli jednoduchej klasifikácii, riziko sa zvyšuje bez prínosu. Dobrý návrh lokality znižuje náklady na bezpečné konanie. Toto je dôležité, pretože kontroly, ktoré sú príliš drahé, budú nakoniec opísané ako voliteľné, a tak sa začína veľa zlých príbehov.
Hodnotenie musí sledovať systém
Mnohé tímy hodnotia model a zabúdajú hodnotiť systém. Testujú, či sú odpovede správne na sade promptov, a potom nasadia do pracovného toku s oprávneniami, čerstvosťou zdrojov, frontami, volaniami nástrojov, ľudskou kontrolou, opakovanými pokusmi a meniacimi sa politikami. Benchmark modelu môže byť stále užitočný, ale už neopisuje celé riziko. Bezpečnostné zlyhania často žijú v spojeniach.
Hodnotenie systému testuje správanie od začiatku do konca. Pýta sa, či sa pre správneho používateľa získa správny zdroj. Kontroluje, či sa odmietnu zastarané dáta. Overuje, či sú volania nástrojov blokované bez oprávnenia. Meria, či sa vysoko rizikové prípady dostanú k ľuďom. Testuje vrátenie zmien. Testuje oneskorenie fronty. Testuje cesty inovácie modelu. Testuje zvláštne, ale bežné prípady: chýbajúci dátum, duplicitný zákazník, výnimka pre región, odvolanie po oprave, vymazanie zdroja, čiastočný výpadok, preťažený recenzent. Produkcia má chuť na prípady, o ktorých si nikto nemyslel, že sú dosť dramatické.
Hodnotenie by malo zahŕňať negatívnu schopnosť. Systém musí byť dobrý v nerobení vecí. Neodpovedať bez dôkazov. Neprekračovať hranice oprávnení. Neeskalovať na akciu, keď je povolené len navrhovanie. Neskrývať neistotu. Nepoužívať zdroj po vymazaní. Nepokračovať, keď nástroj vráti nekonzistentný stav. Bezpečnosť závisí rovnako od odmietnutia a pozastavenia ako od presnosti. Najdôležitejším výstupom bezpečného systému umelej inteligencie môže byť nedostatok dôkazov, čo je veta, ktorú si žiadny demonštračný tím nedá na banner.
Hodnotenie systému tiež mení riadenie vydaní. Zmena promptu, zmena modelu, prestavba indexu, aktualizácia politiky, zmena oprávnení nástrojov alebo zmena rozhrania recenzenta môžu zmeniť bezpečnosť. Každá z nich potrebuje rozsah testov a plán vrátenia zmien. Tím by mal vedieť, ktoré správania sa zmenili a ktoré riziká vzrástli. Toto je nudné tak, ako sú nudné bezpečnostné pásy. Zaujímavé sa to stane až vtedy, keď chýbajú, čo je na pohodlie príliš neskoro.
Ponaučenie
Bezpečnosť umelej inteligencie je väčšinou návrh systémov, pretože škoda zvyčajne putuje cez systémy. Výstup modelu sa stane rizikovým, keď mu pracovný tok príliš dôveruje, brána nástrojov je príliš široká, dôkazy chýbajú, stav je nejasný, kontrola je preťažená, protokoly sú slabé alebo vrátenie zmien je imaginárne. Model môže byť viditeľným zdrojom vety, ale systém rozhoduje, či sa veta stane akciou.
Tento pohľad je menej dramatický ako mnohé debaty o bezpečnosti umelej inteligencie a pre organizácie, ktoré systémy nasadzujú už teraz, je užitočnejší. Od tímov žiada, aby vytyčili hranice, pomenovali právomoci, uchovávali dôkazy, navrhovali stavy, rozmiestňovali prácu zámerne, vyhodnocovali celý proces a dali ľuďom skutočnú moc. S modelom pracuje ako s výkonným komponentom v rámci bezpečnostného prípadu, nie ako s celým bezpečnostným prípadom. Toto je dospelý postoj. Inžinierom tiež dáva čo stavať okrem ďalšieho PDF s politikou, čo je láskavé voči všetkým.
Otázka bezpečnostného pracovníka po ukážke bola úplne správna. Čo sa stane, ak sa model mýli, ale je presvedčivý. Bezpečný systém by mal mať odpoveď: tu môže len navrhovať, tam musí citovať aktuálne zdroje, tento nástroj nesmie použiť, tento prípad ide na posúdenie, táto akcia zanechá potvrdenie, tento pracovný postup sa dá pozastaviť, toto vydanie sa dá vrátiť späť, toto rozhodnutie sa dá napadnúť. Tieto odpovede nie sú dojmy. Sú to návrh.
Neistota v umelej inteligencii tu bude vždy. Praktickou úlohou je zabrániť tomu, aby sa neistota zmenila na neobmedzenú právomoc. Dosahuje sa to rozhraniami, stavmi, ovládacími prvkami, dôkazmi, lokalitou, vyhodnocovaním, obnovou a ľudským úsudkom, ktorý je riadne vybavený. Inými slovami, návrhom systémov. Nie preto, že hodnoty nezáležia, ale preto, že hodnoty musia byť vykonateľné skôr, než môžu kohokoľvek chrániť.