Сигурността на ИИ е предимно системен дизайн
Срещата по безопасност след демонстрацията
Демонстрацията беше минала добре, както обикновено. Моделът прочете купчина вътрешни документи, отговори на въпрос относно политика, предложи следваща стъпка и изготви спретнато резюме за досието по случая. Присъстващите кимнаха. Някой попита дали може да бъде свързан със системата за работния процес. Друг попита колко скоро. Тогава служителят по безопасността попита какво ще стане, ако моделът греши, но е убедителен. В стаята внезапно станаха много заинтересовани от бисквитите.
Този въпрос е мястото, откъдето започва практическата безопасност на ИИ. Не в абстрактното, и не в лозунг. А във формата на системата около модел, който понякога ще греши, понякога ще е остарял, понякога прекалено самоуверен, понякога недостатъчно самоуверен, а понякога ще е прав по погрешната причина. Проблемът с безопасността не е само в поведението на модела. Той е в това какво системата позволява на това поведение да направи.
Модел, който изготвя изречение, е един риск. Модел, който актуализира решение за обезщетение, е друг. Модел, който извиква инструмент с права за запис, е трети. Модел, който насочва пациент, отхвърля иск, променя кредитен лимит или управлява оборудване, попада в съвсем различен клас на опасност. Същият основен модел може да бъде безвреден, полезен, рисков или неприемлив в зависимост от границите, състоянието, доказателствата, правомощията, наблюдението и възстановяването. Ето защо безопасността на ИИ е предимно проектиране на системи.
„Предимно“ върши работа в това изречение. Изследванията на моделите имат значение. Качеството на данните има значение. Методите за съгласуване имат значение. Науката за оценяване има значение. Но когато една организация внедрява ИИ, безопасността става оперативна. Кой има право да пита. Какво може да вижда моделът. Какво може да променя. Какво доказателство се изисква. Какво състояние се запазва. Какво се случва, когато източниците си противоречат. Кога човек трябва да одобри. Как се открива отклонение. Как се оттегля лошо издание. Това са въпроси на проектирането, преди да са етични декларации. Етичната декларация може да е искрена. Системата не изпълнява искреност.
Безопасността е проблем на контрола
Когато хората чуят „безопасност“, често си мислят за ценности, обучителни данни, политики за отказ и съгласуване на модела. Това е част от картината, но една внедрена система също се нуждае от контроли. Контрол е нещо, което променя какво може да се случи: проверка за достъп, схема, времево ограничение, праг, човешко одобрение, пясъчна среда, ограничение на скоростта, проверяващ модул, връщане към предишно състояние, авариен прекъсвач, запис, който не може да бъде редактиран от пътя на обслужване. Контролите са скучни, докато не липсват. Тогава те се превръщат в единствената тема на срещата.
Една безопасна AI система приема, че моделът може да сгреши, и проектира заобикалящата го машинерия съответно. Тя разделя предложението от действието. Тя ограничава правомощията на инструментите. Тя проверява доказателствата преди промяна на състоянието. Тя прави несигурността видима. Тя записва версията на модела и обхвата на източниците. Тя отказва, когато липсват задължителни полета. Тя дава на операторите начин да поставят автоматизацията на пауза. Тя третира изхода на модела като кандидат, а не като заповед от много красноречива електронна таблица.
Това е обичайно инженерство за безопасност с езиков модел в средата. Авиацията, медицината, железопътният транспорт, промишленият контрол и финансите са научили, че важните системи се нуждаят от многослойни контроли, защото никой компонент не е съвършен. Версията с AI изглежда нова, защото компонентът говори. Речта прави грешката социално убедителна. Грешен отговор, който звучи спокойно, може по-лесно да се промъкне покрай уморен оператор, отколкото мигаща червена грешка. Следователно дизайнът на контрола трябва да е по-упорит от прозата.
Дизайнът на контрола започва с въпроса какво на системата е позволено да засяга. Ако AI може само да изготвя чернови, безопасността се фокусира върху качеството на източниците, проверките за халюцинации, яснотата на потребителския интерфейс и прегледа. Ако може да насочва работа, безопасността добавя проследяване на състоянието, цялост на опашката, нива на обслужване и пътища за обжалване. Ако може да извиква инструменти, безопасността добавя обхвати на разрешения, валидиране на аргументи, журнали на транзакции и компенсиращи действия. Ако може да засяга права или физически системи, безопасността изисква доказателства, формален преглед, ограничена автономия и сериозно планиране на инциденти. Моделът е едната част. Обхватът на правомощията е другата.
Границата е продуктът
Най-важната линия в една AI система често не се вижда в интерфейса. Тя е границата между четене и писане, препоръчване и решаване, обобщаване и записване, подпомагане и действие. Слабите граници превръщат безобидните прототипи в опасни услуги. Модел, който започва като помощник за чернови, получава бутон за прилагане на черновата. След това получава инструмент за актуализиране на случая. После получава правило за насочване, защото екипът е зает. Шест месеца по-късно никой не може да обясни кои решения са автоматизирани и кои само подпомагани. Това не е злоба. Това е разширяване на обхвата, облечено в удобни обувки.
Добрите граници са изрични и проверими. Моделът може да чете тези източници, не онези. Може да предлага тези полета, но не и да ги записва. Може да извиква този инструмент с тези аргументи, не с произволен текст. Може да насочва случаи с нисък риск, не оспорвани случаи. Може да отговаря само когато доказателствата са актуални. Не може да използва лични бележки за публични обяснения. Не може да преминава от един клиент, регион, акаунт или правно основание в друго, само защото следващият абзац изглеждаше полезен.
Границите трябва да се прилагат и извън модела. Подкана, която казва да не се записва в базата данни на клиентите, не е граница, ако инструментът има право на запис и няма защитна врата. Системно съобщение, което казва да се цитират източници, не е граница, ако отговорите могат да се съхраняват без цитати. Параграф от политика, който казва, че се изисква одобрение от човек, не е граница, ако работният процес позволява на автоматизацията да отбележи одобрение. Инструкциите за безопасност вътре в модела са полезни, но не са достатъчни. Системата трябва да направи опасните пътища трудни или невъзможни.
Това е небляскавата работа, която всъщност защитава хората. Типизирани извиквания на инструменти. Тесни обхвати. По подразбиране само за четене. Отделни услуги за одобрение. Идемпотентни операции. Одитни журнали. Версионирани политики. Състояния на опашката. Изрични състояния на отказ. Речникът звучи сякаш бекенд инженер е прекарал тих уикенд с клипборд. Добре. Безопасността в производство обикновено изглежда така. Тя не се опитва да спечели конкурс за лозунги.
Състоянието е мястото, където безопасността става реална
Разговорите с изкуствен интелект могат да създадат впечатлението, че системите са без състояние. Потребителят пита, моделът отговаря, екранът се променя. Продукционната среда обаче не е без състояние. Казусите се движат. Билетите остаряват. Правата изтичат. Документи се коригират. Версията на модела се променя. Човек отменя препоръка. Постъпва обжалване. Потребител пита защо се е случило нещо миналия месец. Безопасността зависи от това дали системата е запазила състоянието, необходимо за отговора.
Състоянието казва на системата какво вече се е случило и какво може да се случи по-нататък. Без него моделът вижда само откъс и предполага останалото. Така се стига до повторни действия, изчезнали крайни срокове, предположени одобрения и стари доказателства, които се връщат в ново решение. Един безопасен работен процес записва изрични състояния: чернова, липсващи доказателства, блокирано от политика, изисква се преглед, одобрено, изпълнено, оспорено, коригирано, изтеглено. Тези състояния не са декоративни. Те пречат на модела да третира важен процес като чат разговор с амбиции.
Състоянието дава лост и на хората. Оператор може да провери защо даден казус е на преглед. Ръководител може да види дали автоматизацията създава задръстване. Одитор може да възпроизведе кои версии на източниците са били активни. Потребител може да оспори резултат с нещо по-осезаемо от екранна снимка. Разработчик може да измери дали нов модел увеличава отказите, ескалациите или преработката. Без състояние всеки разговор за безопасност се превръща в театър. Хората говорят за отговорност, но системата е изгубила съществителните.
За изкуствения интелект състоянието трябва да включва версия на модела и политиката, идентификатор на подканата или шаблона, набор от източници, времеви отпечатък на извличането, извиквания на инструменти, увереност или несигурност, причина за отказ, човешко действие и последица надолу по веригата. Не всичко това принадлежи в един ред от лог, нито пък трябва да е видимо за всички. Поверителността и сигурността имат значение. Но информацията трябва да съществува при контролиран достъп. В противен случай безопасността зависи от паметта, а паметта е прочуто лоша база данни с отлични извинения.
Доказателствата са парапетът на безопасността
Отговорът на модела е по-безопасен, когато е свързан с доказателства. Това звучи очевидно, докато системата не бъде подложена на напрежение. Доказателствата се пропускат, защото добавят закъснение. Цитатите се съхраняват като текст, а не като идентификатори. Резултатите от извличането не се запазват. Версиите на източниците се презаписват. Моделът пише уверено обяснение от документ, който междувременно е коригиран. По-късно всички питат защо отговорът е бил грешен. Отговорът е, че парапетът е бил декоративен.
Полезната доказателственост не е бележка под линия. Тя е верига. Заявката е влязла с идентичност и цел. Източниците са подбрани с разрешение. Извличането е открило конкретни откъси или записи. Моделът е създал резултат под конкретна версия. Проверяващ е потвърдил твърдения или прагове. Човек е приел, редактирал или отхвърлил. Действието е променило състоянието. Системата е съхранила достатъчно от веригата, за да може тя да бъде възпроизведена или оспорена. Това не е бюрокрация заради самата нея. Това е начинът, по който безопасността оцелява във времето.
Доказателствеността също така предпазва модела от искане да върши невъзможна работа. Ако системата изисква актуални източници, моделът може да откаже остарял вход. Ако системата изисква два съвпадащи записа, той може да отбележи несъответствие. Ако системата изисква идентификатори на източници, той може да спре неподкрепени твърдения. Моделът вече не трябва да превръща липсващите доказателства в плавно управление на несигурността. Той може да върне безопасно състояние. Това е по-мило към модела и много по-мило към човека, засегнат от резултата.
Има баланс. Записването на доказателства не трябва да се превръща в наблюдение. Чувствителното съдържание може да бъде хеширано, редактирано, разделено или съхранявано за ограничени периоди. Смисълът не е да се записва всичко завинаги. Смисълът е да се запазят фактите, необходими за проверка на важно поведение. Безопасността без доказателства е просто доверие с по-хубаво яке. Може да изглежда добре във фоайето. Не издържа при инцидент.
Хората се нуждаят от проектиран авторитет
Човекът в процеса често се използва като вълшебна фраза. Не е магия. Уморен проверяващ със слаби доказателства, неясна политика и опашка от двеста случая не е система за безопасност. Това е човек, поставен в края на конвейер и помолен да бъде управление. Може да проработи за кратко, особено ако човекът е опитен и упорит. Но това не е дизайн.
Човешкият авторитет трябва да бъде конкретен. Кои случаи изискват преглед. Какви доказателства вижда проверяващият. Може ли проверяващият да променя структурирани полета или само да одобрява текст. Знае ли проверяващият дали моделът е бил несигурен или дали политиката е изисквала ескалация. Връщат ли се несъгласията в оценката. Защитени ли са проверяващите от пристрастие към автоматизацията. Могат ли да поставят на пауза работен процес. Могат ли да ескалират към специалист. Могат ли да видят подобни минали случаи. Могат ли да обяснят решение на засегнатия човек. Тези подробности решават дали човешкият надзор е реален или декоративен.
Добрият надзор също така отделя преценката от чиновническата работа. Хората не трябва да губят време в търсене на липсващи идентификатори на източници, премахване на дублирани повторни опити, превеждане на моделния текст в работни потоци или в догадки кой вариант на политиката е бил приложен. Системата трябва да подготвя случая. Човекът трябва да прилага преценка там, където тя е нужна: при спорно значение, изключение, пропорционалност, контекст, съпричастност и отговорност. Ако човекът основно оправя пропуски в инфраструктурата, организацията е объркала осигуряването на персонал с безопасността.
Дизайнът трябва също така да позволява на хората да не са съгласни с автоматизацията, без триенето да се превръща в наказание. Ако отмяната на модела изисква осем кликвания, а приемането само едно, интерфейсът вече има политика. Ако ескалацията кара екипа да изглежда бавен, хората ще избягват ескалацията. Ако показателите възнаграждават само производителността, прегледите за безопасност ще се превърнат в ритуал. Дизайнът на системите включва стимули, екрани, опашки и настройки по подразбиране. Моделът може да не знае показателя, но хората със сигурност ще го знаят.
Местоположението променя риска
Къде се случва работата с ИИ има значение. Система, която изпраща всеки документ на отдалечен модел, носи различни рискове от система, която извлича данни близо до самите данни и изпраща само получено поле. Система, която съхранява следи в услугата за обслужване, носи различни рискове от система, която води независими одитни записи. Система, която разчита на един външен рутер, има различни възможности за възстановяване от система, която може да работи локално с намален капацитет. Местоположението не е национализъм с мрежова схема. То е практическият въпрос кои рискове се преместват, когато данните, изчислителната мощ, политиката и доказателствата се преместват.
Част от работата трябва да се извършва близо до чувствителни данни, защото преместването на данните създава излагане на риск. Част от работата трябва да се извършва близо до потребителите, защото забавянето влияе на безопасността. Част от работата трябва да се извършва в централна услуга, защото е необходим специализиран преглед или хардуер. Част от доказателствата трябва да се съхраняват извън пътя за обслужване на модела, защото самият път за обслужване може да е обект на разследване. Безопасният дизайн рядко е всичко локално или всичко отдалечено. Той е обмислено разположение.
Местоположението засяга също правната и организационната отговорност. Ако извикване на модел преминава през региони, кой закон урежда данните. Ако индекс е изграден извън системата източник, как се разпространяват изтриванията. Ако доставчик промени модел, как се получава известие и как се извършва тестване. Ако регистрационните файлове са в портал на доставчика, може ли организацията да ги експортира по време на инцидент. Това не са абстрактни въпроси за суверенитет. Те са въпроси за безопасност, защото определят дали организацията може да контролира и обяснява системата при стрес.
Неправилното разположение може да направи безопасното поведение скъпо. Ако всяка стъпка за проверка изисква отдалечено пътуване, екипите може да извадят проби вместо да проверяват всеки случай. Ако данните за одит са трудни за свързване, разследванията стават бавни. Ако частни данни трябва да пътуват за проста класификация, рискът се увеличава без полза. Добрият дизайн на местоположението намалява цената на безопасното действие. Това има значение, защото контролите, които са твърде скъпи, в крайна сметка ще бъдат описани като незадължителни, а така започват много лоши истории.
Оценката трябва да следва системата
Много екипи оценяват модела и забравят да оценят системата. Те проверяват дали отговорите са верни на набор от подсказки, след което внедряват в работен процес с разрешения, свежест на източниците, опашки, извиквания на инструменти, човешки преглед, повторни опити и променящи се политики. Бенчмаркът на модела може да е полезен, но вече не описва целия риск. Пропуските в безопасността често се крият в съединенията.
Оценката на системата тества поведението от край до край. Тя пита дали правилният източник се извлича за правилния потребител. Проверява дали остарелите данни се отказват. Удостоверява, че извикванията на инструменти се блокират без разрешение. Измерва дали случаите с висок риск достигат до хора. Тества връщането към предишно състояние. Тества закъснението на опашката. Тества пътищата за надграждане на модела. Тества странни, но обичайни случаи: липсваща дата, дублиран клиент, изключение за регион, обжалване след корекция, изтриване на източник, частичен отказ на услугата, претоварен рецензент. Производството има вкус към случаите, които никой не е сметнал за достатъчно драматични.
Оценката трябва да включва отрицателна способност. Системата трябва да е добра в това да не прави неща. Да не отговаря без доказателства. Да не прекрачва границите на разрешенията. Да не преминава към действие, когато е разрешено само чертане. Да не прикрива несигурността. Да не използва източник след изтриването му. Да не продължава, когато инструментът върне противоречиво състояние. Безопасността зависи също толкова от отказа и паузата, колкото и от точността. Най-важният резултат от безопасна ИИ система може да бъде недостатъчно доказателства, което е изречение, което никой демо екип никога не поставя на транспарант.
Оценката на системата също променя управлението на пускането. Промяна на подсказка, промяна на модел, възстановяване на индекс, актуализация на политика, промяна на разрешенията за инструменти или промяна на интерфейса на рецензента може да промени безопасността. Всяка от тях изисква обхват на тестване и план за връщане. Екипът трябва да знае кои поведения са се променили и кои рискове са се увеличили. Това е досадно по начина, по който предпазните колани са досадни. Става интересно само когато отсъства, което е твърде късно за утеха.
Урокът
Безопасността на ИИ е предимно проектиране на системи, защото вредата обикновено пътува през системи. Резултатът от модела става рискован, когато работният процес му се доверява твърде много, шлюзът за инструменти е твърде широк, доказателствата липсват, състоянието е неясно, прегледът е претоварен, регистрационните файлове са слаби или връщането е въображаемо. Моделът може да е видимият източник на изречението, но системата решава дали изречението се превръща в действие.
Този възглед е по-малко драматичен от много дебати за безопасността на ИИ и по-полезен за организации, които внедряват системи в момента. Той изисква от екипите да очертаят граници, да назоват отговорностите, да запазят доказателства, да проектират състояния, да разпределят работата обмислено, да оценяват от край до край и да дадат на хората реална власт. Той третира модела като мощен компонент в рамките на безопасността, а не като цялата рамка за безопасност. Това е зрялата позиция. Освен това дава на инженерите какво да изградят, освен поредния PDF с политики, което е мило към всички.
Въпросът на служителя по безопасност след демонстрацията беше точно правилен. Какво се случва, ако моделът греши, но е убедителен. Една безопасна система трябва да има отговор: тук може само да чертае, там трябва да цитира актуални източници, не може да извиква този инструмент, този случай отива за преглед, това действие оставя разписка, този работен процес може да бъде поставен на пауза, тази версия може да бъде върната назад, това решение може да бъде оспорено. Тези отговори не са усещания. Те са дизайн.
Винаги ще има несигурност в ИИ. Практическата задача е да се спре несигурността да се превърне в неограничена власт. Това се постига с интерфейси, състояния, контроли, доказателства, локалност, оценка, възстановяване и човешка преценка, която е правилно оборудвана. С други думи, системен дизайн. Не защото ценностите нямат значение, а защото ценностите трябва да бъдат изпълними, преди да могат да защитят някого.