Тихата работа на ЕU AI Act: записи, не лозунги

Трудната част от Закона за ИИ на ЕС не е да повтаряш принципите му. А е да превърнеш риска, документацията, регистрирането, човешкия надзор и корекциите в...

Тихата работа на ЕU AI Act: записи, не лозунги

Записът, който пристига след решението

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

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

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

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

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

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

Защо тихата работа има значение

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

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

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

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

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

Четете акта като последователност, а не като лозунг

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

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

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

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

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

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

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

Три неща, които един запис може да прави

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

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

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

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

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

Пълнотата не е брой байтове. Тя е способността да се отговори на въпросите, породени от предназначението и последиците на системата.

Какво не може да направи един запис

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

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

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

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

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

Дневниците са доказателство, а не морално алиби

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

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

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

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

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

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

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

Документацията е живо описание

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

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

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

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

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

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

Човешкият надзор се нуждае от доказателства около себе си

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

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

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

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

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

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

Системата за качество зад документите

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

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

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

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

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

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

Съхранението е въпрос на дизайн

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

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

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

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

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

Когато доказателства липсват

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

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

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

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

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

Службата за ИИ и работата по тълкуването

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

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

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

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

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

От правния език към ежедневната практика

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

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

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

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

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

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

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

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

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

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

Записите са част от институцията

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

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

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

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

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

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

Източници