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