Система с висок риск не е модел с висок риск

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

Система с висок риск не е модел с висок риск

Етикетът се закрепва към употреба, не към кутия

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

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

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

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

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

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

Задръжте показалеца или изберете слой. Моделът е един слой; последствието се появява едва когато слоевете се срещнат.

Европа умишлено използва две различни съществителни

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

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

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

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

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

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

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

Предназначението е отправната точка на анализа

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

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

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

Предназначението е също мястото, където даден екип открива, че е описвал амбиция, а не операция. „Ще подпомагаме служителите по преписки“ може да прикрие дузина различни договорености. Инструментът търси ли в документи, подрежда ли работа, изготвя ли отговор, препоръчва ли категория, отхвърля ли заявление, ескалира ли сигнал, задава ли приоритет или извиква ли друга услуга? Колегата използва ли го преди или след формирането на независимо мнение? Резултатът предложение в страничен панел ли е, или поле, което трябва да бъде попълнено, преди записът да продължи? Ефектът незабавен, забавен, обратим или трудно забележим ли е? Отговорът променя системата дори когато потребителският интерфейс изглежда познат.

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

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

Контекстът не е декор

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

Подходът на Акта към високия риск отразява това. Член 6 свързва класификацията като високорискова със системи, предназначени да се използват като компоненти за безопасност на определени продукти, или със системи, посочени в приложение III. Приложение III изброява области, в които системите с ИИ може да са високорискови, защото са предназначени за определени употреби, като някои биометрични употреби, критична инфраструктура, образование и професионално обучение, заетост, достъп до основни частни и публични услуги и обезщетения, правоприлагане, миграция и граничен контрол, както и правораздаване и демократични процеси. Правният детайл има значение, но и граматиката също. Не се казва, че техническият артефакт е високорисков в абстрактен смисъл. Повтаря се изразът „предназначени да се използват“.

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

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

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

Изберете начин на внедряване. Моделът остава непроменен; системната граница, правомощията и необходимите доказателства не остават.

Потребителите са част от повърхността за контрол

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

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

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

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

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

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

Засегнатите хора стоят извън конзолата

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

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

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

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

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

Интеграцията е мястото, където отговорностите преминават от едни ръце в други

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

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

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

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

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

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

Документацията трябва да описва система, която все още може да се променя

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

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

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

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

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

Как да разсъждаваме за цялата система, без да се преструваме на сигурност

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

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

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

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

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

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

Кратка бележка от нас

В Dweve нашият публичен Trust Centre третира записа за модела и низходящата интеграция като свързани, но отделни записи. Неговата страница за низходящата интеграция посочва, че екипите, които интегрират или внедряват Loom, се нуждаят от актуални възможности, ограничения, интерфейси, контекст на оценката и промени, докато публичният запис гласи, че моделът е една нишка в по-широката тъкан от компоненти и оперативни граници. Това е документационна позиция, а не твърдение, че публична страница класифицира всяко възможно внедряване или доказва съответствие за интегратора. Целта на разделението е по-скромна: записът за модела трябва да пътува заедно с интеграцията, без да се преструва, че замества собствения системен анализ на интегратора.

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

По-трудният въпрос обикновено е по-добрият

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

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

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

Източници