Кой има право да спре модел, когато греши?

Човешкият надзор не е човек, който стои до модела. Той е властта, доказателствата и безопасното състояние, които позволяват на някого да откаже резултат, да...

Кой има право да спре модел, когато греши?

Законът на Европейския съюз за изкуствения интелект използва изненадващо физическа дума за едно цифрово задължение. Член 14 гласи, че хората, натоварени да наблюдават високорискова система с ИИ, трябва да могат да се намесват или да прекъсват системата чрез бутон за спиране или подобна процедура, която ѝ позволява да спре в безопасно състояние. Изречението се отнася до софтуер. То звучи така, сякаш някой разумно е запомнил, че машините могат да бъдат изключвани.

Този спомен е по-важен, отколкото звучи. В много организации човешкият надзор се третира като присъствието на човек някъде около системата. Проверяващ получава препоръка. Оператор може да отвори табло. Мениджър е посочен в политика. Съществува адрес за поддръжка за оплаквания. Схемата след това се описва като човек в контура, сякаш човешко същество е било поставено в контура и контурът в резултат е станал мъдър.

Истинският въпрос е по-труден и по-полезен: когато моделът греши, несигурен е, извън одобреното си предназначение или се държи по начин, който доказателствата не могат да подкрепят, кой има правото да спре работата? Кой може да постави на пауза нови действия, без да чака доставчик? Кой може да попречи на вече генерирани резултати да се превърнат в решения? Кой може да запази състоянието, което трябва да бъде разследвано? Кой може да отвори отново пътя и въз основа на какви доказателства? Човек, който може да забележи проблем, но не може да промени системата, е свидетел. Човек, който може да кликне върху бутон, но не знае какво спира бутонът, управлява реквизит.

Ето защо правото на спиране трябва да бъде проектирано преди внедряването. То изисква определена роля, обхват, безопасно състояние, следа от доказателства, път за ескалация и начин за връщане в експлоатация, който не въвежда тихо същия отказ. То изисква достатъчно технически детайли, за да работи, когато системата е натоварена, доставчикът е недостъпен и човекът, създал първоначалния работен процес, е преминал към друг проект. То изисква също така достатъчно институционална яснота, за да може човек да използва правото, без да бъде обвинен, че е прекъснал иновациите.

Спирането е способност, а не учтивост

Спирането често се описва като крайна мярка, което му придава злополучно церемониално качество. Организацията обещава, че някой може да спре системата, ако обстоятелствата станат достатъчно сериозни. Обстоятелствата настъпват. Човекът търси правото. Правото се оказва параграф в документ, разрешение, притежавано от друг екип, или адрес за ескалация, който се наблюдава в работно време. Системата продължава, много учтиво.

Спирането не е настроение. То е способност с интерфейс и договор. Интерфейсът може да бъде бутон, команда, политическа врата, отменен токен, деактивиран път, задържане на опашка или контролирано изключване. Договорът определя какво прави действието, какво не прави, коя работа е предотвратена, на коя работа е позволено да приключи, какво състояние се запазва, кой се уведомява и как организацията знае, че спирането е влязло в сила. Ако тези отговори липсват, думата спиране означава само, че всички са съгласни, че спирането би било хубаво.

Съществува полезна разлика между спирането на модел и спирането на последствие. Модел може да работи, докато резултатите му се задържат за преглед. Услуга може да остане достъпна за чернови с ниско въздействие, докато пътят за препоръки е затворен. Инструмент може да връща информация само за четене, докато достъпът за запис е отнет. Работен процес може да приема нови случаи, но да отказва да ги придвижи към външно решение. Това са различни контролни повърхности. Отнасянето към тях като към един голям червен ключ или спира твърде малко, или унищожава повече работа, отколкото е необходимо.

Пропорционалността има значение, но пропорционалността не е разрешение за размиване на границите на спирането. Асистент с нисък риск може да се нуждае от локален отказ и път към човек. Система, използвана в област с високо въздействие, може да се нуждае от твърда бариера, преди даден резултат да засегне правата на човек или достъпа му до услуга. Автономен инструмент, който може да промени външен запис, може да се нуждае от отделен път за намеса, различен от този на модел, който само изготвя чернова. Рискът, степента на автономия и контекстът на употреба определят силата на контрола. Те не премахват нуждата от контрола.

Езикът на AI Act е полезен именно защото свързва човешкия надзор с реална цел, свързана с риска. Надзорът има за цел да предотвратява или свежда до минимум рисковете за здравето, безопасността и основните права. Той не е там, за да украсява системата с човешки силует. Ако определеният човек не може да разпознае аномалия, да интерпретира резултат, да го отмени или да спре операцията безопасно, договореността не е изпълнила практическата цел на надзора, независимо колко подписа има в проектния файл.

Четете член 14 като инженерна спецификация

Член 14 се прилага за високорискови AI системи, а не за всякакъв софтуер, който е получил етикет за AI. Първото му изискване е системата да бъде проектирана и разработена така, че физическите лица да могат да я наблюдават ефективно, докато е в употреба. Фразата „докато е в употреба“ има значение. Преглед по време на възлагане на поръчката не е надзор на действаща система. Обучителен курс, проведен преди пускането, не е надзор на променен модел. Обяснение след инцидент не е заместител на контрол, който е можел да предотврати действието.

Второто изискване дава цел на надзора. Той трябва да предотвратява или свежда до минимум рисковете, които възникват, когато системата се използва по предназначение или при разумно предвидима злоупотреба. Тази формулировка се противопоставя на удобен трик, при който организацията третира всяка вредна употреба като непредвидима изненада. Хората ще използват системи под напрежение, с непълна информация, чрез преводи, в необичайни комбинации и на ръба на инструкциите. Сериозният дизайн задава въпроса коя злоупотреба е разумно предвидима и дава на проверяващия начин да реагира, преди резултатът да придобие институционална тежест.

Третото изискване прави надзора съизмерим с риска, автономията и контекста. Доставчикът може да вгради мерки в системата и може също така да определи мерки, които внедряващата страна трябва да приложи. Това е разделение на работата, а не разделение на отговорността. Доставчикът не може да предаде система без работещ начин за прекъсването ѝ и да сочи към внедряващата страна. Внедряващата страна не може да пренебрегне предоставените ограничения и да твърди, че доставчикът е обещал безопасност в абстрактен план. Контролът трябва да оцелее на границата между доставеното нещо и начина, по който то се използва.

Четвъртата алинея е мястото, където правният език се превръща в практически контролен списък. Хората, определени за надзор, трябва да могат да разбират съответните възможности и ограничения на системата. Те трябва да могат да я наблюдават, включително за аномалии, неизправности и неочаквано представяне. Те трябва да са наясно с пристрастието към автоматизацията, склонността да се разчита или прекалено да се разчита на машинен резултат. Те трябва да могат да интерпретират резултата. Те трябва да могат да решат да не го използват, да го пренебрегнат, да го отменят или да го обърнат. Накрая, те трябва да могат да се намесят или да прекъснат операцията чрез бутон за спиране или подобна процедура, която я привежда в безопасно състояние.

Всяка дума за действие създава различно задължение за дизайна. Разбирането изисква полезна информация за обхвата и ограниченията. Наблюдението изисква сигнали, време и път, по който да бъдат проверени. Осъзнаването на пристрастието към автоматизацията изисква обучение и интерфейс, който не превръща препоръката в присъда по подразбиране. Тълкуването изисква доказателства и контекст. Отмяната изисква правомощие и запис на несъгласието. Прекъсването изисква преход на състоянието, който е по-безопасен от продължаването. Единствено голямо зелено табло не може да удовлетвори пет различни думи за действие само с размера си.

Актът включва и по-конкретно правило за определени системи за биометрична идентификация с висок риск. В случаите, обхванати от разпоредбата, решение не може да бъде взето въз основа на резултата от идентификацията, освен ако той не е бил отделно проверен и потвърден от най-малко две компетентни, обучени и упълномощени физически лица, при спазване на посочените законови изключения. Това е конкретен европейски пример за надзор, изразен като независимо правомощие, а не като самотен проверяващ, който кликва през препоръка. Той също така показва защо дизайнът трябва да посочи вида на решението и доказателствата, необходими за него.

Член 14 не предписва единен универсален модел за персонала. Той задава граница. Лицето трябва да има достатъчно компетентност, обучение и правомощие, за да изпълнява ролята. Доставчикът и внедряващият трябва да направят контрола пропорционален на системата. Организацията все пак трябва да реши кои роли изпълняват кои действия, кога спирането е задължително, как се обработва задържан случай и какво представлява безопасно възобновяване. Законът може да изисква вратата. Той не може да избере човека, който държи ключа във всяка сграда.

Спирането не е краят на управлението. То е преходът, който прави възможни разследването, коригирането и защитимото възобновяване.

Петте правомощия, скрити в думата надзор

Полезно е петте практически правомощия от член 14 да бъдат разгледани едно по едно. Първото е разбирането. Ролята за надзор не може да работи въз основа на лозунг като моделът обикновено е точен. Ролята изисква предвиденото предназначение, известните ограничения, входните условия, съответните доказателства за ефективност, режимите на отказ, политиката за актуализиране и значението на резултата в реалния работен процес. Разбирането не е същото като четенето на карта на модела. То е способността да се разпознае кога даден случай в реално време попада извън условията, при които системата е била оценена.

Второто е мониторингът. Мониторингът често се свежда до наличност, латентност и моделен резултат. Тези показатели имат значение, но една услуга може да е налична и в същото време да е грешна. Един модел може да запази общата си производителност, докато дадена колекция от източници остарее, разпределението на езиците се промени, краен срок по политика бъде пропуснат или екип надолу по веригата започне да използва препоръка като автоматично решение. Оперативният мониторинг следи последствията. Той търси неочаквана производителност, промени във входните данни, промени в маршрута, необичайни модели на замяна, блокирани случаи, оплаквания и признаци, че системата е помолена да върши работа, за която не е създадена.

Третото е интерпретацията. Човек не може да упражнява надзор, ако резултатът пристига без своите условия. Интерпретацията може да изисква съответния източник, информация за увереността, версия на политиката, сигнал за качеството на входните данни, метод за обяснение или сравнение с безопасна базова линия. Тя не изисква мистичен поглед върху всеки параметър. Изисква достатъчно контекст, за да се отговори на въпроса, за който човекът носи отговорност: какво означава този резултат тук, какво не означава и какво трябва да се случи, ако доказателствата са недостатъчни?

Четвъртото е отказът и отмяната. Член 14 изрично дава на надзорната роля възможността да реши да не използва системата, да пренебрегне нейния резултат, да го замени или да го отмени. Това е по-силно от това да се помоли човек да добави коментар, след като приеме резултата. Означава, че работният процес трябва да позволи на различно решение да оцелее. Алтернативата не трябва да се третира като изключение, което изчезва в следващата автоматизирана стъпка. Ако човек може да не е съгласен, но системата въпреки това ще изпълни първоначалната препоръка, човекът е бил поканен да изрази мнение, а не му е даден надзор.

Петото е прекъсването. Прекъсването действа върху самата операция. То може да спре извикване на инструмент преди външна промяна, да постави случай на пауза, да попречи на нова работа да влезе в маршрут, да отнеме разрешение или да превключи услугата към ограничен резервен вариант. Техническият метод варира. Свойството за безопасност не варира: операцията трябва да достигне до определено състояние, в което следващото важно действие не може да се случи само по инерция.

Тези правомощия са свързани, но не и взаимозаменяеми. Човек може да разбира системата, но да няма правата да я спре. Човек може да има бутон за спиране, но без полезен сигнал, който да му каже кога да го натисне. Човек може да замени един резултат, докато пакетен процес продължава да произвежда същия резултат за всички останали. Човек може да спре приема на нови случаи, докато съществуващите задачи продължават да записват във външна система. Дизайнът на надзора трябва да свърже правомощията през целия действителен жизнен цикъл на работата.

Тази връзка е и мястото, където човешката роля става достойна. Проверяващият не е там, за да поеме несигурността на системата с подпис. Проверяващият е там, за да упражнява ограничена власт, която организацията съзнателно е направила възможна. Работата може да остане трудна. Може да изисква експертни познания, преценка и смелост да се оспори популярна система. Но трудността не е причина да се скрие контролът. Тя е причина да се уточни той.

Кой получава ключа?

Няма един-единствен човек в процеса. Обикновено има няколко власти, всяка с различна причина да се намеси. Доставчикът контролира части от дизайна и пускането. Разгръщащият контролира целта, конфигурацията и оперативната употреба. Човекът, назначен за надзор, контролира конкретно решение или намеса по време на изпълнение. Собственикът на домейна контролира дали даден резултат е приемлив в професионален контекст. Роля за сигурност или поверителност може да контролира достъпа до доказателства или данни. Засегнато лице може да има право да оспори резултат. Компетентен орган може да изисква информация, коригиращо действие или изтегляне. Третирането на всички тези като една роля прави системата да звучи проста, а отчетността невъзможна.

Отговорността на доставчика започва, преди системата да достигне до потребителя. Доставчикът решава кои контроли са вградени, кои ограничения са документирани, какви журнали могат да се генерират и кои промени се третират като съществени. Доставчик, който твърди, че разгръщащият може просто да наблюдава системата, трябва да покаже как разгръщащият може да направи това с предоставения интерфейс и информация. Ако спирането зависи от недокументирана вътрешна команда или от билет за поддръжка с несигурен отговор, спирането не е възможност на разгръщащия. То е надежда, че доставчикът ще остане на линия.

Разгръщащият има различни правомощия. Разгръщащият решава къде се използва системата, за каква цел, с кои данни, по какъв работен процес и с кои хора, отговорни за надзора. Разгръщащият може да превърне консултативен резултат в решение де факто чрез дизайна на интерфейса, стимули или натиск, дори когато доставчикът е описал системата внимателно. Затова разгръщащият трябва да начертае местния път, а не просто да повтори предвиденото от доставчика предназначение. Един и същ компонент може да има различен рисков профил, когато е свързан с различно действие.

Ролята за надзор по време на работа изисква по-тясно и по-ясно делегиране. На това лице може да бъде позволено да задържи случай, да отхвърли препоръка, да поиска допълнителни доказателства, да ескалира до собственик на домейн или да активира безопасно спиране. На него може да не бъде позволено да променя модела, да изтрива доказателства, да взема правно решение или да възобновява спрян маршрут. Тези граници не са обида към ролята. Те предотвратяват възможността човекът, който може да спре процес, също да може да заличи причината за спирането му.

Правомощията трябва да следват последствията. Преглеждащ, който може да постави чернова на пауза, не е задължително да може да спира всеки маршрут в организацията. Човек, който може да спре действие, свързано с безопасността, може да се нуждае от достъп до по-широк екип за инциденти и от ясно задължение да уведомява. Специалист в даден домейн може да е единственият човек, на когото е позволено да отмени резултат при регулирано решение. Специалист по сигурността може да може да изолира услуга, докато друг орган решава дали използването трябва да се възобнови. Важното не е да се създаде голяма йерархия. Важното е предаванията да бъдат изрични.

Ескалацията не трябва да се бърка с прехвърляне на отговорност. Ако първият преглеждащ препраща всеки труден случай към комитет, системата не е придобила надзор. Тя е придобила по-бавна опашка. Маршрутът за ескалация трябва да посочва кой въпрос се ескалира, каква работа се задържа, докато отговорът чака, кой трябва да отговори, какви доказателства придружават случая и какво се случва, ако маршрутът е недостъпен. Първият човек остава отговорен за запазването на случая и за използването на безопасната опция по подразбиране. От него не се изисква сам да измисли окончателния отговор.

Правомощията също се нуждаят от път за връщане. Спиране без начин за предаване на контрола обратно се превръща или в постоянен престой, или в тихо заобикаляне. Пътят за връщане трябва да посочва кой може да възобнови, кои условия трябва да бъдат изпълнени, дали уловеното състояние остава валидно, коя чакаща работа изисква повторна оценка и как потребителите се уведомяват, че маршрутът е променен. Възобновяването е друго решение. То заслужава същата сериозност като прекъсването, макар че рядко получава същия привлекателен бутон.

Спирането трябва да е безопасно

Изразът безопасно състояние от Закона за ИИ заслужава повече внимание, отколкото хардуерният образ на бутона за спиране. Система може да спре да изпраща нови заявки и въпреки това да остави опасна работа в движение. Тя може да прекрати процес по средата на транзакция. Може да изостави резултат, без да уведоми човека, който е чакал решение. Може да деактивира видимия интерфейс, докато планирана задача продължава във фонов режим. Може да спре модела и да остави кеширана препоръка достъпна за следващата услуга. Спирането е безопасно само по отношение на действителните ефекти на системата.

Определете състоянията, преди да изберете контрола. Един активен маршрут може да приема, оценява, препоръчва и действа. Един задържан маршрут може да не приема нищо ново, но да запазва вече получения материал. Един спрян маршрут може да отхвърля цялата съществена работа, като същевременно позволява оторизирана проверка. Един деградирал маршрут може да предоставя ограничена услуга само за четене или само от хора. Един оттеглен маршрут може да изисква ново одобрение, преди да се върне. Това са проектни решения, а не универсални имена. Те стават полезни, когато хората могат да видят в кое състояние се намират и какво позволява всяко състояние.

Текущата работа се нуждае от собствено правило. Някои операции са обратими и могат да завършат безопасно. Някои вече са преминали външна граница и се нуждаят от компенсиращо действие. Някои трябва да бъдат изхвърлени и генерирани наново, защото доказателствата вече не са надеждни. Някои са с ниско въздействие и могат да останат като чернови. Системата не трябва да кара оператора да гадае само от един етикет за състояние. Тя трябва да разкрива набора от работа, неговата точка на преход и действието, което ще се случи, ако не се направи нищо друго.

Безопасното състояние също защитава доказателствата. Спирането на система чрез изтриване на временните ѝ файлове може да премахне точно контекста, необходим за разбиране на повредата. Спирането ѝ чрез оставяне на тайни в широк диагностичен експорт може да създаде втори инцидент. Контролът се нуждае от път за запазване на доказателства с граници на достъп, правила за задържане и посочен отговорник. Безопасността и поверителността не са съперници тук. И двете изискват обмислено боравене, а не познатата аварийна практика да се копира всичко в папка, наречена спешно.

Тестването на спирането е част от внедряването на системата. Бутон, който е бил кликван само в демонстрация, доказва, че бутонът може да бъде кликнат. Той не доказва, че приемът спира, действията се успокояват, записите остават съгласувани, известията достигат до правилните хора или че рестартирането не повтаря работата два пъти. Тестът трябва да упражнява реалния маршрут, включително частична повреда и оператор, който има предвидения орган, но не и личните знания на разработчика. Ако спирането не може да бъде репетирано без специално изпълнение, то все още не е оперативен контрол.

Опашката е част от решението

Спирането на AI система често се представя като спиране на модела. На практика опашката около модела е част от решението. Работата може да чака да влезе, да чака резултат от модела, да чака човешка проверка, да чака инструмент надолу по веригата или да чака известие. Всяка позиция носи различен риск. Стоп, който защитава само модела, може да позволи на околната опашка да продължи да третира стари резултати като валидни.

Чакащата работа се нуждае от политика. Получава ли нова заявка ясен отказ, известие за закъснение или човешки маршрут? Остава ли използваем резултат, произведен преди спирането? Отбелязани ли са случаи, които все още не са прегледани, като изискващи нова оценка? Разграничава ли системата работа, поставена на пауза от човек, от работа, която технически се е провалила? Може ли потребител да оттегли заявка, докато тя е задържана? Подробностите зависят от услугата, но решението не може да бъде оставено на поведението по подразбиране на опашката за повторен опит.

Повторните опити са особено показателни. Техническата опашка често предполага, че операция, която не е завършила, трябва да бъде опитана отново. Управленската опашка не може да предполага, че същата препоръка трябва да бъде произведена отново, след като причината за спирането е несигурност, обхват или потенциална вреда. Повторният опит може да е безопасен за идемпотентно четене и опасен за външно действие. Политиката за спиране трябва следователно да носи причина и разрешена следваща стъпка, а не просто червен статус.

Съществуващите резултати се нуждаят от класификация. Някои са чернови, на които никое лице не се е доверило. Някои са били показани на работник. Някои са били копирани в протокол за решение. Някои са задействали известие или са променили система извън ИИ маршрута. Една организация не може да реши какво да прави с тях, докато не знае коя граница е преминал всеки резултат. Ето защо проследимостта не е канцеларска украса. Тя е картата на последиците, които една спирка трябва да ограничи.

Опашката също променя натоварването на хората. Една спирка може да защити хората от небезопасно автоматизирано действие, като същевременно създаде голямо количество работа по преглед. Тази работа трябва да бъде призната, приоритизирана и обезпечена с ресурси. В противен случай организацията в крайна сметка ще отвори отново маршрута, защото задържаните случаи са станали неудобни, а не защото доказателствата са се подобрили. Пауза, която просто премества вредата в изтощена ръчна опашка, е отлагане с добри намерения.

Няма срам в това опашката да стане по-бавна, когато алтернативата е непроверена последица. Има дизайнерски проблем, когато опашката няма модел на капацитета, правило за триаж и начин да се каже на засегнатите хора какво се случва. Човешкият надзор не е безплатно внимание. Той е оперативна услуга с ограничения, които трябва да са известни, преди машината да бъде пусната да работи в мащаб.

След спирката, памет

Спирката е събитие, което променя това, което организацията знае, и това, което е длъжна да направи. Записът трябва да съдържа задействането, времето, маршрута, състоянието преди намесата, използваното правомощие, обхвата на задържането, засегнатата работа, събраните доказателства, направените известия и условията за преглед. Той трябва да разграничава наблюдението от заключението. Оператор може да запише, че даден резултат е бил несъвместим с предоставените доказателства, без да твърди, че инцидент е доказан. Прецизността в записа защитава както разследването, така и хората, които са замесени.

Актът за ИИ третира воденето на записи като техническо свойство за системите с висок риск. Член 12 изисква такива системи да позволяват автоматично записване на събития през целия им жизнен цикъл, с възможности за регистриране, които подпомагат проследимостта, идентифицирането на риска, мониторинга след пускане на пазара и мониторинга на работата. Член 19 се отнася до съхранението на автоматично генерирани регистрационни файлове под контрола на доставчика, при спазване на предвидената цел и приложимото законодателство за защита на данните. Това е полезно напомняне, че една спирка не може да зависи от екранна снимка, събрана след факта. Системата трябва да може да остави следа, докато работи.

Регистрирането не е нареждане да се събират всякакви лични данни завинаги. То е изискване да се записват събитията, свързани с целта и риска. Един добър запис за спирка може да използва препратки, хешове, идентификатори на версии, редактирано съдържание и отделни контроли за достъп. Той може да съхранява входа, необходим за повторно изпълнение, в защитено хранилище, вместо да го поставя в обикновено табло. Трябва да е възможно да се разследва, без хранилището за доказателства да се превърне във второ неконтролирано пространство за данни.

Задължението на доставчика за коригиращи действия също е от значение. Когато доставчик счита или има основание да счита, че система с висок риск не е в съответствие, Актът изисква необходими коригиращи действия, които могат да включват привеждането ѝ в съответствие, изтеглянето ѝ, деактивирането ѝ или изземването ѝ, ако е подходящо. Изборът не е маркетингово решение. Той е отговор, обвързан с доказателства, обхват и риск. Разполагащият със системата може да трябва да спре локален маршрут, преди доставчикът да може да завърши оценката. Доставчикът може да трябва да деактивира или изтегли маршрут, който разполагащият със системата е продължил да използва. Двете власти трябва да могат да комуникират, без да губят доказателствата, които обясняват промяната.

Проследяването след пускането на пазара разширява паметта отвъд едно събитие. Актът описва система, която активно и систематично събира, документира и анализира съответните данни през целия жизнен цикъл на системата с висок риск. Смисълът не е доставчикът да се взира в табло с показатели. Смисълът е да се установи дали системата продължава да отговаря на изискванията и дали контекстът около нея се е променил. Спирането може да бъде първият полезен сигнал в този процес. Поредица от малки намеси може да каже повече за годността на една система, отколкото една чиста оценка при пускането.

Сериозните инциденти имат отделен ред за докладване в Акта, включително задължение за разследване и предприемане на коригиращи действия след докладването. Членът не превръща всяко отменяне в сериозен инцидент. Това разграничение има значение. Оператор, който отхвърля препоръка, може да упражнява здравословен контрол, а не да открива събитие, подлежащо на докладване. Записът трябва да запази достатъчно информация, за да може организацията да прецени какво се е случило, вместо да принуждава всяко несъгласие или към мълчание, или към драматичен етикет.

Ескалацията е контролирано прехвърляне на въпрос, а не учтив начин отговорността да изчезне.

Ескалацията е маршрут, а не настроение

Хората често казват, че даден труден случай трябва да бъде ескалиран. Фразата звучи отговорно и не съдържа почти никаква оперативна информация. До кого да се ескалира? За какво решение? С какви доказателства? В какъв срок? Какво се задържа, докато отговорът чака? Какво става, ако никой не отговори? Маршрут, който не отговаря на нито един от тези въпроси, ще възнагради упоритостта, а не преценката. Случаят или ще бъде прехвърлян, докато крайният срок стане решението, или тихо ще бъде върнат на човека, който пръв е забелязал проблема.

Полезната ескалация започва с въпрос. Изходът извън ли е одобреното предназначение? Доказателствата непълни ли са? Променила ли се е системата след оценката? Има ли риск за основно право? Вече е настъпило ли външно действие? Проблемът технически, правен, специфичен за дадена област, свързан ли е със сигурността или е комбинация? Въпросът определя коя роля може да отговори на него. Ескалация, която изпраща един и същ недиференциран случай до всеки екип, не е задълбочена. Това е групов имейл в бъдеще време.

Ролята за местен надзор трябва да има безопасна стойност по подразбиране, докато въпросът е отворен. Това може да бъде задържане, отказ, връщане към път само с човешко участие, запазване на чернова или ограничаване на системата до информация само за четене. Стойността по подразбиране трябва да е видима за лицето и за засегнатия потребител, когато е уместно. Мълчанието не е безопасна стойност по подразбиране, когато работният процес продължава под него.

Доказателствата трябва да пътуват с ескалацията. Получаващата роля не трябва да възстановява случая от изход на модела и времеви печат. Тя трябва да получи съответната входна препратка, изход, версии на модела и политиката, изходния материал, сигнал за увереност или несигурност, статус на действието, предишни намеси и точното решение, което е необходимо. Тук също има значение дисциплината за поверителност. Изпратете достатъчно, за да се отговори на въпроса, а не целия живот на човек, защото бутонът за експорт е бил наблизо.

Ескалацията има нужда от часовник, но не всеки часовник е краен срок за одобрение. Въпрос с ниско въздействие може да изчака редовен преглед. Действие с високо въздействие може да изисква незабавно задържане и маршрут за дежурен. Правилото за времето трябва да казва какво се случва, когато прозорецът за отговор изтече. То може да удължи задържането, да прехвърли правомощия, да уведоми ръководител или да изисква ново решение. Не трябва мълчаливо да превръща липсващия отговор в разрешение.

Приключването е част от ескалацията. Записът трябва да казва какво е решено, от кого, на базата на какви доказателства, с какви ограничения и какво последващо действие. Ако отговорът е, че системата може да продължи само в по-тесен контекст, новата граница трябва да бъде приложена, а не просто възхитена. Ако отговорът е, че системата трябва да бъде изтеглена, засегнатата работа и потребителите се нуждаят от план. Ако отговорът е, че аномалията е била безвредна, доказателствата все пак трябва да информират мониторинга и обучението. Ескалация, която изчезва след среща, не се е превърнала в институционално знание.

Добрата ескалация също защитава човека, който повдига въпроса. Правомощието да спрете система е безполезно, ако използването му се третира като нелоялност. Организациите преподават истинските си приоритети чрез това, което се случва, след като човек каже „не“. Ако отговорът е любопитство, доказателства и подкрепа, хората научават, че надзорът е част от работата. Ако отговорът е обвинение, забавяне и молба да бъдете по-позитивни, системата ще получава по-малко предупреждения и предупрежденията, които получава, ще пристигат по-късно.

Човешкият надзор е натоварване

Позоваването на закона на компетентност, обучение и правомощия е лесно да се чете като изискване за човешки ресурси. То е също така изискване за капацитет. Човек не може да наблюдава ефективно система с ИИ, ако интерфейсът показва твърде много шум, опашката не оставя време за проверка, доказателствата пристигат в различен инструмент, решенията се измерват само по скорост или организацията е възложила работата на някой без предметни познания. Ролята може да съществува на хартия и въпреки това да е невъзможна за изпълнение.

Обучението трябва да включва ограниченията на системата, одобрената цел, признаците на неочаквано представяне, значението на несигурността, механизмите за отмяна и спиране, поверителността на доказателствата и маршрута след намеса. То трябва да включва случаи, в които изходът изглежда правдоподобен. Надзорът е най-необходим, когато отговорът не е достатъчно абсурден, за да бъде отхвърлен веднага. Курс, който учи хората да разпознават карикатурно грешен отговор, ги подготвя за демонстрация, а не за работеща услуга.

Пристрастието към автоматизацията заслужава практическо внимание. Една препоръка може да се превърне в отправна точка, преди проверяващият да е прочел подкрепящите доказателства. Етикетът за увереност може да бъде интерпретиран като вероятност, дори когато не е такъв. Едно изпипано обяснение може да се възприеме като независимо потвърждение, когато то е само преразказ. Редът на интерфейса има значение. Ако системата представи отговора си първо, а доказателствата по-късно, проверяващият може да прекара останалата част от процеса в защитаване или коригиране на първоначалното си впечатление. Контролът за спиране, скрит зад същия работен процес като одобрението, също отправя изявление за това кое действие организацията очаква.

Ограниченията на натоварването са мерки за безопасност. Проверяващ, който трябва да обработи голяма опашка, може да се научи да приема по подразбиране моделът като най-бързия безопасен избор. Специалист, който получава всеки нееднозначен случай, може да започне да одобрява просто за да поддържа услугата в движение. Малък екип, който отговаря за маршрута за спиране при повикване, може да не е наличен в часовете, когато системата действително работи. Това не са лични провали. Това са предвидими реакции на оперативен дизайн, който изисква от човешката преценка да компенсира неограничената автоматизация.

Измерете самата работа по надзора. Колко често се отменят резултатите? Колко често се опитва спиране? Кои сигнали водят до намеса? Колко дълго остават отворени задържанията? Кои групи или езици пораждат повече несигурност? Колко корекция е необходима, преди резултатът да може да се използва? Показателите не заместват преценката, но могат да разкрият, че обещаният контрол се превръща в чиста формалност. Целта не е да се наказва висок процент на отмяна. Тя е да се попита какво ни казва този процент за системата и работния процес.

Европейските традиции за безопасност вече знаят това

Езикът на европейската политика за надежден ИИ не започва с Акта за ИИ. През 2019 г. експертната група на високо равнище на Европейската комисия по въпросите на ИИ публикува насоки за етика за надежден ИИ. Насоките определят човешкото участие и надзора като едно от седемте изисквания и описват подходите човек в цикъла, човек върху цикъла и човек в командването. Те също така свързват надзора с техническата стабилност, плановете за отстъпление, прозрачността, проследимостта и отчетността. Важният момент не е речникът. Той е решението да се опише надеждността като набор от условия, които могат да бъдат оценени.

По-късната работа на Комисията по оценка дава на организациите начин да превърнат тези условия във въпроси. Осъзнават ли хората, че взаимодействат със система с ИИ? Могат ли да разберат възможностите и ограниченията на системата? Могат ли да се намесят и да решат да не я използват? Има ли механизми за обезщетение? Контролният списък не прави операцията безопасна. Той обаче затруднява претенцията, че човек, назначен за надзор, автоматично е човек, упълномощен да го упражнява.

Работата на ENISA по подходите за сигурност на ИИ разглежда темата през жизнения цикъл и екосистемата около модела. Нейната карта на заплахите за ИИ от 2020 г. очертава активи, участници, заплахи и етапи от изискванията до внедряването. Тази перспектива е ценна за спирането, защото нещото, което трябва да бъде изолирано, може да не е моделът. То може да бъде източник на данни, разрешение за инструмент, пакет за внедряване, път за наблюдение или компонент от доставчик. Спиране, проектирано около името на модела, може да остави реалната функционалност непокътната другаде във веригата.

Това са документирани европейски подходи, а не твърдения, че Европа е решила проблема с надзора. Насоките и Актът задават очаквания. ENISA картографира проблем със сигурността. Работата по внедряването остава локална, техническа и неизбежно ежедневна. Някой все пак трябва да реши коя роля може да задържи маршрута в три следобед, кои доказателства се появяват на екрана му и кой отговаря, когато спирането е използвано.

Обществените поръчки решават преди операторите

Много от спиранията на системи се провалят, защото решението всъщност е взето при доставката, а не при експлоатацията. Договорът може да позволява на доставчика да смени модела без надлежно предизвестие. Услугата може да не предоставя достъп до журнали или идентификатор на версията. Експортът може да пропуска незавършена работа и история на намесите. Споразумението за поддръжка може да не предлага начин за реакция при спиране по съображения за безопасност. Купувачът може да е приел общо изказване, че клиентът носи отговорност за използването, без да е получил контролите, необходими за упражняването на тази отговорност. Когато операторът поиска бутона за спиране, договорът вече е решил дали такъв бутон съществува.

Ето защо доставките трябва да задават оперативни въпроси. Коя страна може да деактивира всеки маршрут? Може ли внедряващият да спре действие със значителни последици, без да чака поддръжката на доставчика? Какво се случва с текущата и чакащата работа? Кое състояние се записва? Как се обявяват промените? Може ли клиентът да изтегли журнали и доказателства в използваем формат? Какъв е резервният вариант, когато услугата е недостъпна? Кои роли са обучени и кой финансира обучението? Как се коригира оспорен резултат? Как организацията излиза, без да загуби записите, необходими за обяснение на предишни решения?

Тези въпроси не целят да накарат всеки доставчик да се държи като публичен орган. Те са начин авторитетът да остане съобразен с употребата. Ако организацията носи отговорността да защитава хората, засегнати от дадена система, тя се нуждае от достатъчен контрол върху маршрута, за да изпълни това задължение. Договор, който оставя клиента отговорен, но оперативно безсилен, не е модел на управление. Той е прехвърляне на отговорност с лого.

Кратко съобщение от нас

В Dweve нашата работа върху отговорен изкуствен интелект, основан на състояния, прави същата скромна точка от инженерна гледна точка: един отчетлив работен процес има именувани състояния, защити, записи, отговорници и изходи. Това не е твърдение, че една диаграма може да реши управлението. Това е напомняне, че принципите се нуждаят от място, където да се приложат, когато системата работи. Дали инструментът е компонент на Dweve, услуга в публичния сектор или модел на доставчик, тестът е същият. Може ли реален човек да види проблема, да упражни власт, да спре следващата последица, да запази доказателствата и да върне работата в защитимо състояние?

Въпроси преди внедряване

Преди модел да влезе в работен процес със значителни последици, задайте въпросите за спиране в помещението, където системата действително ще работи. Не ги оставяйте за преглед на политиката, който никога не вижда опашката, портала за инструменти или човека, който ще получи предупреждението.

  • Какво точно може да бъде спряно? Посочете моделния маршрут, извикването на инструмент, опашката, известието, действието за запис и зависимата услуга. Ако отговорът е само процесът на модела, потърсете възможността, която остава, след като той бъде спрян.
  • Кой може да го спре, без да пита създателя? Посочете ролята по време на изпълнение, нейните правомощия, нейния резервен вариант и нейната граница. На лицето не трябва да му е необходимо лично познаване на реализацията, за да използва контрола.
  • Какъв сигнал му казва да действа? Определете аномалиите, липсващите доказателства, конфликта на обхвата, неприемливата несигурност, промяната на политиката, опасението за сигурността и предизвикателството от потребител чрез термини, които операторът може да наблюдава.
  • Какво се случва с работата, която вече е в ход? Разделете новия прием, чакащата работа, операциите в процес на изпълнение, резултатите, показани на хората, и вече приложените действия. Определете безопасно третиране за всяко от тях.
  • Какво е безопасното състояние? Опишете какво системата приема, отхвърля, задържа, завършва или разкрива след прекъсване. Проверете дали състоянието е реално, а не просто етикет на екрана.
  • Какви доказателства оцеляват? Запазете съответния вход, изход, версии, политика, източници, човешки действия, времеви рамки и известия с подходящи контроли за поверителност.
  • Кой получава ескалацията? Посочете въпроса за решението, прозореца за отговор, пакета от доказателства и подразбиращото се действие в очакване. Списъкът с адресати не е карта на правомощията.
  • Кой може да възобнови, стесни или оттегли маршрута? Направете решението за връщане изрично. Определете условията, повторната оценка, комуникацията с потребителя и тригера за преглед, които го съпътстват.
  • Какво ще ви покаже, че контролът се проваля? Следете моделите на заобикаляне, продължителността на задържане, повтарящите се инциденти, неравномерните ефекти, натиска в опашката, оплакванията на потребителите и отклонението в околния работен процес. Рядко използвана спирачка може да означава безопасна система или скрит контрол.

Въпросите са умишлено прости. Те не заместват оценката на риска, процеса за съответствие, плана за инциденти или правния преглед. Те са точката, в която тези дейности стават оперативни. Ако организацията не може да отговори на тях, липсващата работа не е философско несъгласие относно това дали на ИИ трябва да се вярва. Тя е липсваща част от системата.

Правомощието да спреш е правомощието да се грижиш

Моделът може да сгреши по начин, който изглежда обикновен. Източникът е стар. Входът е непълен. Маршрутът се е разширил. Праг е бил преместен. Превод е променил значението. Разрешението за инструмент е надживяло предназначението си. На рецензента се показва заключението, но не и доказателствата. Никаква аларма не звучи, защото системата все още е налична и таблото все още е зелено. Вредата започва като малко несъответствие между това, което на системата е било позволено да прави, и това, което организацията сега очаква от нея.

Човешкият надзор е отговорът на институцията на това несъответствие, но само когато е повече от присъствие. Ролята за надзор изисква знанията да разпознае проблем, времето да го разследва, правомощието да откаже или прекъсне, безопасното състояние, което прави прекъсването смислено, и записите, които позволяват на други хора да разберат какво се е случило. Тя изисква ескалация, която носи въпрос и доказателства, а не неясна молба за помощ. Тя изисква възобновяване, което е решение, а не край на прекъсването.

Европейският акт за ИИ правилно използва езика на намесата и безопасното спиране за системи с висок риск. Той дава на управлението физически ръб. Той пита хората, които проектират и внедряват системи, да направят човешкия контрол възможен по време на употреба, а не просто възхитителен по принцип. По-ранната работа на Комисията за надежден ИИ и подходът на ENISA към жизнения цикъл подсилват същата посока: надзорът принадлежи на работата на системата, нейните доказателства и нейната околна верига за доставки.

В Dweve предпочитаме не романтизираната версия на тази идея. Една сериозна система трябва да познава своите състояния, своите граници и своя собственик. Тя трябва да може да задържи работа, да покаже защо я е задържала, и честно да спре, когато доказателствата не са достатъчни. Това не е особена добродетел на една конкретна архитектура. Това е минималното уважение, дължимо на хората, които трябва да живеят с резултата.

Когато моделът греши, решаващият въпрос не е дали човек е бил технически наличен. Въпросът е дали поименен човешки орган е можел да промени това, което се случва след това, и дали организацията е можела да запомни промяната. Ако отговорът е да, надзорът си върши работата. Ако отговорът е не, системата има човек наблизо, някъде бутон и никаква спирачка.

Източници