Bezpečnost AI je hlavně návrh systémů
Bezpečnostní porada po demu
Demo proběhlo dobře, jako obvykle. Model přečetl hromadu interních dokumentů, odpověděl na otázku ohledně politiky, navrhl další krok a vytvořil úhledné shrnutí do spisu. V místnosti se přikyvovalo. Někdo se zeptal, jestli by se to dalo propojit se systémem pracovních postupů. Někdo jiný se zeptal, jak brzy. Pak se bezpečnostní referent zeptal, co by se stalo, kdyby se model mýlil, ale byl přesvědčivý. Místnost najednou projevila velký zájem o sušenky.
Tato otázka je místem, kde začíná praktická bezpečnost umělé inteligence. Ne v abstraktní rovině a ne ve sloganu. Ale v podobě systému kolem modelu, který se někdy mýlí, někdy pracuje se zastaralými daty, někdy je přehnaně sebejistý, někdy naopak příliš opatrný a někdy má pravdu z nesprávného důvodu. Bezpečnostní problém není jen chování modelu. Je to to, co systém tomuto chování dovolí udělat.
Model, který navrhne větu, je jedno riziko. Model, který aktualizuje rozhodnutí o dávce, je jiné. Model, který zavolá nástroj s právem zápisu, je další. Model, který směruje pacienta, zamítá pojistnou událost, mění úvěrový limit nebo ovládá zařízení, spadá do úplně jiné třídy nebezpečí. Tentýž základní model může být neškodný, užitečný, riskantní nebo nepřijatelný v závislosti na hranicích, stavu, důkazech, oprávnění, monitorování a obnově. Proto je bezpečnost umělé inteligence většinou návrhem systémů.
Slovo „většinou“ v té větě nese váhu. Výzkum modelů je důležitý. Kvalita dat je důležitá. Metody alignmentu jsou důležité. Věda o hodnocení je důležitá. Ale když organizace nasadí umělou inteligenci, bezpečnost se stává provozní záležitostí. Kdo se smí ptát. Co model smí vidět. Co smí změnit. Jaký důkaz se vyžaduje. Jaký stav se uchovává. Co se stane, když si zdroje odporují. Kdy musí schválit člověk. Jak se zjistí odchylka. Jak se špatné vydání vrátí zpět. Toto jsou otázky návrhu dříve, než jsou etickými prohlášeními. Etické prohlášení může být upřímné. Systém upřímnost nevykonává.
Bezpečnost je problém řízení
Když lidé slyší slovo bezpečnost, často si představí hodnoty, trénovací data, pravidla odmítání a alignment modelu. To vše je součástí obrazu, ale nasazený systém také potřebuje řídicí prvky. Řídicí prvek je něco, co mění, co se může stát: kontrola přístupu, schéma, časový limit, práh, schválení člověkem, sandbox, omezení rychlosti, ověřovač, vrácení změn, nouzové vypnutí, záznam, který nelze upravit cestou obsluhy. Řídicí prvky jsou nudné, dokud nechybí. Pak se stanou celou poradou.
Bezpečný systém umělé inteligence počítá s tím, že model může selhat, a okolní mechanismy navrhuje s tímto vědomím. Odděluje návrh od provedení. Omezuje oprávnění nástrojů. Před změnou stavu ověřuje důkazy. Zviditelňuje nejistotu. Zaznamenává verzi modelu a rozsah zdrojů. Odmítne pracovat, pokud chybí povinná pole. Dává operátorům možnost pozastavit automatizaci. S výstupem modelu zachází jako s kandidátem, ne jako s rozsudkem z velmi výřečné tabulky.
Toto je běžné bezpečnostní inženýrství s jazykovým modelem uprostřed. Letectví, medicína, železnice, průmyslové řízení i finance se naučily, že důležité systémy potřebují vrstvené kontroly, protože žádná součást není dokonalá. Verze s umělou inteligencí působí nově, protože součást mluví. Řeč činí selhání společensky přesvědčivým. Špatná odpověď, která zní klidně, proklouzne kolem unaveného operátora snáze než blikající červená chyba. Návrh řízení proto musí být tvrdohlavější než samotný text.
Návrh řízení začíná otázkou, co smí systém ovlivnit. Pokud umělá inteligence pouze navrhuje text, bezpečnost se soustředí na kvalitu zdrojů, kontrolu halucinací, srozumitelnost rozhraní a revizi. Pokud může směrovat práci, bezpečnost přidává sledování stavu, integritu front, úrovně služeb a odvolací cesty. Pokud může volat nástroje, bezpečnost přidává rozsahy oprávnění, validaci argumentů, transakční protokoly a kompenzační opatření. Pokud může ovlivnit práva nebo fyzické systémy, bezpečnost vyžaduje důkazy, formální revizi, omezenou autonomii a seriózní plánování incidentů. Model je jedna část. Hranice oprávnění je druhá.
Hranice je produkt
Nejdůležitější linie v systému umělé inteligence často není v rozhraní vidět. Je to hranice mezi čtením a zápisem, doporučením a rozhodnutím, shrnutím a záznamem, asistencí a jednáním. Slabé hranice jsou důvodem, proč se neškodné prototypy mění v nebezpečné služby. Model, který začne jako pomůcka pro návrh, dostane tlačítko pro použití návrhu. Pak dostane nástroj pro aktualizaci případu. Pak dostane pravidlo směrování, protože tým je zaneprázdněný. O šest měsíců později nikdo nedokáže vysvětlit, která rozhodnutí jsou automatizovaná a která pouze asistovaná. Toto není zlý úmysl. Je to plíživé rozšiřování rozsahu v pohodlných botách.
Dobré hranice jsou explicitní a kontrolovatelné. Model smí číst tyto zdroje, ne jiné. Smí navrhovat tato pole, ale nesmí je ukládat. Smí volat tento nástroj s těmito argumenty, ne s libovolným textem. Smí směrovat případy s nízkým rizikem, ne sporné případy. Smí odpovídat pouze tehdy, jsou-li důkazy aktuální. Nesmí používat soukromé poznámky pro veřejná vysvětlení. Nesmí přecházet z jednoho tenanta, regionu, účtu nebo právního základu do jiného jen proto, že další odstavec vypadal užitečně.
Hranice je také třeba vynucovat mimo model. Výzva, která říká nezapisovat do databáze zákazníků, není hranicí, pokud má nástroj oprávnění k zápisu a žádnou bránu. Systémová zpráva, která říká citovat zdroje, není hranicí, pokud lze odpovědi ukládat bez citací. Odstavec politiky, který říká, že je nutný souhlas člověka, není hranicí, pokud pracovní postup umožní automatizaci označit věc jako schválenou. Bezpečnostní instrukce uvnitř modelu jsou užitečné, ale nestačí. Systém musí nebezpečné cesty ztížit nebo znemožnit.
Toto je neromantická práce, která skutečně chrání lidi. Typované volání nástrojů. Úzké rozsahy. Výchozí režim pouze pro čtení. Samostatné služby schvalování. Idempotentní operace. Protokoly auditu. Verzované politiky. Stavy front. Explicitní stavy odmítnutí. Slovník zní, jako by backendový inženýr strávil klidný víkend se schránkou. Dobře. Bezpečnost v produkci tak obvykle vypadá. Nesnaží se vyhrát soutěž o slogan.
Stav je místo, kde se bezpečnost stává skutečnou
Konverzace s umělou inteligencí mohou působit dojmem, že systémy jsou bezstavové. Uživatel se zeptá, model odpoví, obrazovka se změní. Produkce bezstavová není. Případy se posouvají. Tickety stárnou. Oprávnění vyprší. Dokumenty se opravují. Změní se verze modelu. Člověk přehlasuje doporučení. Přijde odvolání. Uživatel se ptá, proč se něco stalo minulý měsíc. Bezpečnost závisí na tom, zda si systém uchoval stav potřebný k odpovědi.
Stav systému říká, co se už stalo a co může nastat dál. Bez něj model vidí jen výřez a zbytek si domýšlí. Tak vznikají duplicitní akce, mizející termíny, předpokládaná schválení a staré důkazy vstupující do nového rozhodnutí. Bezpečný pracovní postup zaznamenává explicitní stavy: návrh, chybějící důkazy, blokováno pravidly, nutná revize, schváleno, provedeno, napadeno, opraveno, odvoláno. Tyto stavy nejsou dekorativní. Brání modelu, aby důležitý proces bral jako chatový přepis s ambicemi.
Stav dává páku i lidem. Operátor může zjistit, proč je případ v revizi. Manažer vidí, zda automatizace nevytváří backlog. Auditor může přehrát, které verze zdrojů byly aktivní. Uživatel může napadnout výsledek něčím pevnějším než snímkem obrazovky. Vývojář může změřit, zda nový model zvyšuje odmítání, eskalace nebo přepracování. Bez stavu se každá debata o bezpečnosti stává divadlem. Lidé mluví o odpovědnosti, ale systém ztratil podstatná jména.
Pro umělou inteligenci by stav měl zahrnovat verzi modelu a politik, identifikátor promptu nebo šablony, sadu zdrojů, čas načtení, volání nástrojů, míru jistoty či nejistoty, důvod odmítnutí, lidský zásah a dopad na další kroky. Ne všechno patří do jednoho řádku logu a ne všechno má být vidět pro každého. Soukromí a bezpečnost jsou důležité. Informace ale musí existovat pod řízeným přístupem. Jinak se bezpečnost stane závislou na paměti a paměť je pověstně špatná databáze s výbornými výmluvami.
Důkazy jsou bezpečnostní zábradlí
Odpověď modelu je bezpečnější, když je napojená na důkazy. Zní to samozřejmě, dokud není systém pod tlakem. Důkazy se vynechávají, protože přidávají latenci. Citace se ukládají jako text místo identifikátorů. Skóre vyhledávání se neuchovává. Verze zdrojů se přepisují. Model napíše sebejisté vysvětlení z dokumentu, který byl od té doby opraven. Později se všichni ptají, proč byla odpověď špatně. Odpověď je, že zábradlí bylo jen dekorativní.
Užitečné důkazy nejsou poznámka pod čarou. Jsou řetězcem. Požadavek vstoupil s identitou a účelem. Zdroje byly vybrány na základě oprávnění. Vyhledávání našlo konkrétní části nebo záznamy. Model vytvořil výstup pod pojmenovanou verzí. Ověřovatel zkontroloval tvrzení nebo prahové hodnoty. Člověk přijal, upravil nebo odmítl. Akce změnila stav. Systém uložil dostatek tohoto řetězce, aby jej mohl přehrát nebo zpochybnit. Toto není byrokracie sama pro sebe. Takto bezpečnost přežije čas.
Důkazy také chrání model před tím, aby byl žádán o nemožnou práci. Pokud systém vyžaduje aktuální zdroje, model může odmítnout zastaralý vstup. Pokud systém vyžaduje dva odpovídající záznamy, může označit nesoulad. Pokud systém vyžaduje identifikátory zdrojů, může zastavit nepodložená tvrzení. Model už nemusí měnit chybějící důkazy v plynulé řízení nejistoty. Může vrátit bezpečný stav. To je laskavější k modelu a mnohem laskavější k člověku, kterého se výstup týká.
Existuje rovnováha. Zaznamenávání důkazů by se nemělo stát sledováním. Citlivý obsah může být hashován, redigován, oddělen nebo uchováván po omezenou dobu. Smyslem není zaznamenat vše navždy. Smyslem je zachovat fakta potřebná k prozkoumání důležitého chování. Bezpečnost bez důkazů je jen důvěra v hezčím kabátě. V hale může vypadat dobře. Při incidentu neobstojí.
Lidé potřebují navrženou autoritu
Člověk ve smyčce se často používá jako kouzelné slovo. Není to kouzlo. Unavený recenzent se slabými důkazy, nejasnou politikou a frontou dvou set případů není bezpečnostní systém. To je člověk umístěný na konec dopravního pásu a požádaný, aby byl řízením. Může to krátce fungovat, zvláště pokud je člověk zkušený a houževnatý. Není to návrh.
Lidská autorita musí být konkrétní. Které případy vyžadují přezkum. Jaké důkazy recenzent vidí. Může recenzent měnit strukturovaná pole, nebo pouze schvalovat text. Ví recenzent, zda byl model nejistý, nebo zda politika vyžadovala eskalaci. Jsou neshody předávány zpět do hodnocení. Jsou recenzenti chráněni před automatizačním zkreslením. Mohou pozastavit pracovní postup. Mohou eskalovat specialistovi. Mohou vidět podobné minulé případy. Mohou vysvětlit rozhodnutí dotčené osobě. Tyto detaily rozhodují o tom, zda je lidský dohled skutečný, nebo okrasný.
Dobrý dohled také odděluje úsudek od administrativní záchrany. Lidé by neměli trávit čas hledáním chybějících identifikátorů zdrojů, odstraňováním duplicitních opakování, překládáním výstupů modelu do stavů pracovních postupů nebo hádáním, která verze politiky byla použita. Systém by měl případ zabalit. Člověk by měl uplatnit úsudek tam, kde je úsudek potřeba: sporný význam, výjimka, proporcionalita, kontext, empatie a odpovědnost. Pokud člověk většinou uklízí mezery v infrastruktuře, organizace si spletla personální zajištění s bezpečností.
Návrh musí také umožnit lidem nesouhlasit s automatizací, aniž by se tření změnilo v trest. Pokud přepsání modelu vyžaduje osm kliknutí a přijetí jedno, rozhraní má politiku. Pokud eskalace působí, že tým je pomalý, lidé se eskalaci vyhnou. Pokud metriky odměňují pouze propustnost, bezpečnostní přezkumy se stanou ceremoniálními. Návrh systémů zahrnuje pobídky, obrazovky, fronty a výchozí hodnoty. Model možná metriku nezná, ale lidé ji určitě znát budou.
Lokalita mění riziko
Na tom, kde se práce s umělou inteligencí odehrává, záleží. Systém, který posílá každý dokument vzdálenému modelu, má jiná rizika než systém, který provádí extrakci poblíž dat a posílá pouze odvozené pole. Systém, který ukládá záznamy o průběhu ve službě, která je obsluhuje, má jiná rizika než systém, který vede nezávislé auditorské záznamy. Systém, který se spoléhá na jediný externí směrovač, má jiné možnosti obnovy než systém, který se může degradovat lokálně. Lokalita není nacionalismus s diagramem sítě. Je to praktická otázka, která rizika se přesouvají, když se přesouvají data, výpočetní výkon, politika a důkazy.
Některá práce by měla probíhat blízko citlivých dat, protože přesun dat vytváří expozici. Některá práce by měla probíhat blízko uživatelů, protože latence ovlivňuje bezpečnost. Některá práce by měla probíhat v centrální službě, protože je potřeba specializovaný přezkum nebo hardware. Některé důkazy by měly být uloženy mimo cestu obsluhy modelu, protože cesta obsluhy může být právě tím, co je vyšetřováno. Bezpečný návrh je zřídka vše lokální nebo vše vzdálené. Je to záměrné umístění.
Lokalita také ovlivňuje právní a organizační odpovědnost. Pokud volání modelu překročí regiony, které právo se na data vztahuje. Pokud je index vytvořen mimo zdrojový systém, jak se šíří výmazy. Pokud dodavatel změní model, jak je přijato oznámení a provedeno testování. Pokud protokoly leží na portálu dodavatele, může je organizace během incidentu exportovat. To nejsou abstraktní otázky suverenity. Jsou to bezpečnostní otázky, protože určují, zda organizace může systém pod tlakem ovládat a vysvětlit.
Špatné umístění může učinit bezpečné chování nákladným. Pokud každý ověřovací krok vyžaduje vzdálenou cestu tam a zpět, týmy mohou vzorkovat místo kontroly každého případu. Pokud je obtížné spojit auditorská data, vyšetřování se zpomalí. Pokud musí soukromá data cestovat kvůli jednoduché klasifikaci, riziko se zvyšuje bez zisku. Dobrý návrh lokality snižuje náklady na bezpečné chování. To je důležité, protože kontroly, které jsou příliš nákladné, budou nakonec popsány jako volitelné, a tak začíná mnoho špatných příběhů.
Vyhodnocení musí sledovat systém
Mnoho týmů vyhodnocuje model a zapomíná vyhodnotit systém. Testují, zda jsou odpovědi na sadě promptů správné, a pak nasadí do pracovního postupu s oprávněními, čerstvostí zdrojů, frontami, voláními nástrojů, lidskou kontrolou, opakováními a měnícími se pravidly. Benchmark modelu může být stále užitečný, ale už nepopsuje celé riziko. Selhání bezpečnosti často žijí ve spojích.
Vyhodnocení systému testuje chování od konce do konce. Ptá se, zda je pro správného uživatele načten správný zdroj. Kontroluje, zda jsou zastaralá data odmítnuta. Ověřuje, že volání nástrojů jsou bez oprávnění blokována. Měří, zda se vysoce rizikové případy dostanou k lidem. Testuje vrácení změn. Testuje zpoždění front. Testuje cesty upgrade modelu. Testuje podivné, ale běžné případy: chybějící datum, duplicitní zákazník, regionální výjimku, odvolání po opravě, smazání zdroje, částečný výpadek, přetíženého recenzenta. Produkce má chuť na případy, o kterých si nikdo nemyslel, že jsou dost dramatické.
Vyhodnocení by mělo zahrnovat negativní schopnost. Systém musí být dobrý v tom, co nedělá. Neodpovídat bez důkazů. Nepřekračovat hranice oprávnění. Neeskalovat k akci, když je povoleno pouze navrhování. Neskrývat nejistotu. Nepoužívat zdroj po smazání. Nepokračovat, když nástroj vrátí nekonzistentní stav. Bezpečnost závisí stejně na odmítnutí a pauze jako na přesnosti. Nejdůležitějším výstupem bezpečného systému umělé inteligence může být nedostatek důkazů, což je věta, kterou žádný demo tým nikdy nedá na banner.
Vyhodnocení systému také mění řízení vydání. Změna promptu, změna modelu, přebudování indexu, aktualizace pravidel, změna oprávnění nástrojů nebo změna rozhraní recenzenta může změnit bezpečnost. Každá potřebuje rozsah testů a plán vrácení. Tým by měl vědět, která chování se změnila a která rizika vzrostla. To je nudné tak, jak jsou nudné bezpečnostní pásy. Zajímavé se to stane, až když chybí, což je příliš pozdě na klid.
Ponaučení
Bezpečnost umělé inteligence je většinou návrh systémů, protože škoda obvykle cestuje systémy. Výstup modelu se stane rizikovým, když mu pracovní postup příliš důvěřuje, brána nástrojů je příliš široká, důkazy chybí, stav je vágní, recenze je přetížená, protokoly jsou slabé nebo vrácení změn je imaginární. Model může být viditelným zdrojem věty, ale systém rozhoduje, zda se věta stane akcí.
Tento pohled je méně dramatický než mnohé debaty o bezpečnosti umělé inteligence, a pro organizace, které systémy nasazují už dnes, je užitečnější. Vyzývá týmy, aby vytyčily hranice, pojmenovaly odpovědnost, uchovávaly důkazy, navrhovaly stavy, umisťovaly práci záměrně, hodnotily od začátku do konce a daly lidem skutečnou moc. Na model pohlíží jako na výkonnou součást bezpečnostního případu, ne jako na celý bezpečnostní případ. To je dospělý postoj. Inženýrům to také dává něco, co mohou postavit, místo dalšího PDF s politikou, což je ohleduplné ke všem.
Otázka bezpečnostního pracovníka po demu byla naprosto správná. Co se stane, když se model mýlí, ale je přesvědčivý. Bezpečný systém by měl mít odpověď: tady může pouze navrhovat, tam musí citovat aktuální zdroje, na ten nástroj volat nemůže, tento případ jde k přezkumu, tato akce zanechá potvrzení, tento pracovní postup lze pozastavit, toto vydání lze vrátit zpět, toto rozhodnutí lze napadnout. Tyto odpovědi nejsou dojmy. Jsou to návrh.
V AI bude vždy existovat nejistota. Praktickým úkolem je zabránit tomu, aby se z nejistoty stala neomezená autorita. Toho se dosahuje rozhraními, stavy, ovládacími prvky, důkazy, lokalitou, hodnocením, zotavením a lidským úsudkem, který je řádně vybaven. Jinými slovy, návrhem systémů. Ne proto, že by na hodnotách nezáleželo, ale proto, že hodnoty musí být proveditelné, než mohou kohokoli chránit.