Може ли регулатор да одитира движеща се цел?
Одитът има право да направи снимка
Подвижната цел не е извън обхвата на проверката. Тя е извън единствено този вид проверка, която задава един вечен въпрос и очаква един вечен отговор. Тази разлика има значение. Системите с изкуствен интелект се променят по няколко начина едновременно. Доставчик пуска нова версия на модел. Лицето, което внедрява системата, променя подканата или прага за вземане на решение. Базата за извличане на информация получава нов политически документ. Правило за самоличност променя кой има право да извиква даден инструмент. Инструмент получава ново поле, губи поле или започва да връща различно значение под същото име на поле. Човешки екип променя процедурата си. Светът, който доставя входните данни, се променя, без да пита отговорника по пускането на версии на никого.
Нищо от това не прави одита безполезен. То прави обекта на одита по-точен. Въпросът не е дали дадена организация може да докаже, че една система ще остане непроменена завинаги. Това би било странно обещание дори за калкулатор, свързан с база данни. Въпросът е дали организацията може да покаже каква система е работила в даден момент, какво е трябвало да прави, какви доказателства са подкрепяли тази употреба, кои условия са ограничавали доказателствата, кой е носел отговорност за решението и каква по-късна промяна би трябвало да доведе до преразглеждане на решението.
Одитът има право да направи снимка. Просто не трябва да нарича снимката пейзаж. Правилният запис идентифицира състоянието, което е било проверено, и пази пътя от това състояние до следващото. Тогава той може да каже нещо полезно: тази оценка се отнасяше до този модел, тези настройки, тази граница на данните, тези инструменти, тази политика, този работен процес и това решение за пускане. Може също да каже нещо по-малко удобно и по-ценно: заключението не се пренесе автоматично към следващото състояние.
Това е по-добра отправна точка от познатия театър с неизменни значки. Значката подсказва, че някой е приключил въпроса. Одитният запис трябва да даде възможност да се види какво е било решено, на какво основание, за каква употреба и колко дълго това основание е останало приложимо. Регулаторът не се нуждае от замразена организация. Регулаторът се нуждае от организация, която може да различи замразен запис от действаща услуга, без да третира нито едното, нито другото като мистичен обект.
Европейските правила за изкуствения интелект вече сочат в тази посока. За системите с изкуствен интелект с висок риск Законът за изкуствения интелект изисква техническа документация, преди системата да бъде пусната на пазара или въведена в експлоатация, и изисква тя да се поддържа актуална. Той също така изисква автоматично записване на съответните събития през целия жизнен цикъл на системата и документирана система за мониторинг след пускането на пазара, съобразена с технологията и риска. Това не са указания за заснемане на един церемониален екран. Това са указания за поддържане на следа от доказателства през промяната.
Подвижната цел обикновено е система
Изкушаващо е да се опише система с изкуствен интелект като модел и след това да се обсъжда версионирането, сякаш нов файл с тегла на модела е цялата история. Това е удобно за презентации и неточно за повечето оперативни въпроси. Моделът е важен компонент. Той рядко е пълният обект, чието поведение засяга даден човек, работен процес или правно задължение.
Помислете за обикновен маршрут за подпомагане на решения, описан тук като хипотетичен пример, а не като описание на реално внедряване. Потребител подава заявка. Услугата извлича документи, които ѝ е разрешено да използва. Модел изготвя препоръка. Правило проверява дали са налице необходимите доказателства. Обучен преглеждащ може да приеме, измени или отхвърли препоръката. След това работен процес записва действие. Наблюдаваният резултат зависи от повече неща от модела. Той зависи от версиите на източниците, настройките за извличане, разрешенията, формулировката на интерфейса, праговете, правилата за опашката, човешките правомощия и границата на действието.
Ако изходният корпус се промени, моделът може да получи различна фактическа основа, без да се промени нито един параметър. Ако дадена подкана се промени, моделът може да бъде помолен да направи различен вид преценка. Ако екранът на рецензента спре да показва несигурността, човешкият надзор, описан в документ за риска, може вече да не е надзорът, който хората действително упражняват. Ако дадена интеграция започне да прилага препоръките автоматично, системата е придобила нова власт, дори ако отговорът на модела е идентичен байт за байт.
Ето защо разумният одитен запис започва с предвиденото предназначение и границите на системата. Изискванията за техническа документация на Закона за ИИ в приложение IV включват описания на предвиденото предназначение, версиите, функциите за наблюдение и контрол, валидирането и тестването, управлението на риска, промените, направени по време на жизнения цикъл, и съответните показатели за ефективност. Въпросът не е, че всяка система се нуждае от катедрала от документи. Въпросът е, че рецензентът не може да оцени дадено твърдение, когато обектът, посочен в твърдението, постоянно тихо променя формата си.
Наричането на по-широкия обект система не е начин да накараш работата да звучи по-внушително. Това е начин да избегнеш категорийна грешка. Оценката на модел може да отговори на въпрос за модела. Одитът на система трябва да отговори на въпрос за системата. Първото може да установи как даден компонент се е държал при определени условия. Второто трябва да покаже как този компонент е бил свързан с хора, данни, правила, инструменти и последици. Нито едното не замества другото. Резултатът на модела не е описание на работния процес, точно както добрият тест на гума не е маршрутен план.
Какво всъщност се опитва да установи одиторът
Одитирането на променяща се система не означава да преиграваш всеки момент от живота ѝ в заседателна зала. Означава да направиш конкретни твърдения проверими. Използвана ли е системата в рамките на заявеното предназначение? Подкрепено ли е решението за пускане с доказателства, подходящи за това предназначение? Запазила ли е организацията информацията, необходима за разследване на оспорен резултат? Дали значимите промени са предизвикали повторна оценка? Направило ли е наблюдението видима разликата между безобидна актуализация и съществена промяна? Можеха ли отговорните хора да спрат, ограничат или коригират маршрута, когато доказателствата вече не се поддържаха?
Това са практически въпроси, защото всеки от тях има видим аналог. Предвиденото предназначение принадлежи на записа. Оценката има набор от тестове, конфигурация, тестова съвкупност или входни граници, метод, резултат и ограничение. Решението за пускане има собственик и условия. Промяната има идентичност, дата, причина и оценен ефект. Наблюдението има посочени сигнали, прагове или тригери за преглед. Маршрутът за спиране има орган и операция. Детайлите варират, но одитируемостта идва от превръщането на абстрактните уверения в неща, които някой друг може да провери.
Тук има важна граница. Одитът не доказва, че всеки бъдещ резултат ще бъде правилен, справедлив или безвреден. Той не може да превърне несигурния свят в детерминиран. Той може да установи дали организацията е направила твърдения, достатъчно тесни, за да бъдат разгледани, дали е събрала доказателства, способни да подкрепят тези твърдения, и дали е запазила способността да ги преразгледа. Това може да звучи скромно. Но точно тук започва отчетността.
Разликата между доказателство и език на уверение има значение. Да се каже, че модел е бил оценен, все още не е доказателство за полезна оценка. Думата се нуждае от обект. Оценен спрямо коя задача, кои критерии и кои данни? С кой модел и в какво състояние на системата? При какви работни условия? Кой провери метода? Какво остана извън обхвата? Какво би направило резултата остарял? Без тези въпроси оценката е просто успокояващо минало време.
По-ранните насоки на Европейската комисия за надежден изкуствен интелект определят възпроизводимостта с ясни думи: един експеримент с ИИ трябва да показва същото поведение, когато се повтори при същите условия. Това е полезна дефиниция, защото съдържа собственото си ограничение. Еднаквите условия вършат реална работа. Повторен експеримент може да покаже дали записаното твърдение е възпроизводимо. Той не може да покаже, че непромененото поведение ще се появи след променен източник на данни, политика или път на внедряване. Следователно възпроизводимостта не е обещание, че светът стои неподвижен. Тя е дисциплина за точното описание на това, което се е случило.
Номерът на версията е необходим, но не е достатъчен
Номерата на версиите са полезни, защото пречат на записа да се преструва, че имената са достатъчни. Но етикетът на версията може също да създаде фалшиво усещане за сигурност. Етикет като версия 4.2 може да идентифицира издание на софтуер, но не е задължително да идентифицира действителното състояние на пътя на ИИ. Стойност на конфигурацията може да се намира извън хранилището на модела. Индекс за извличане може да бъде изграден наново от променящи се документи. Флаг на функция може да избере различен път на инструмента. Механизъм за политики може да промени разрешено действие. Следователно дадена услуга може да има безупречно форматиран номер на версия и въпреки това да е трудна за възстановяване.
Важна е идентичността, подходяща за твърдението. Ако твърдението се отнася до офлайн бенчмарк на модел, артефактът на модела, кодът за извод, настройките на параметрите, версията на набора от данни, дефиницията на показателя и средата за изпълнение може да са от съществено значение. Ако твърдението се отнася до услуга за подкрепа при вземане на решения в реално време, записът може допълнително да изисква подканата или шаблона, конфигурацията за извличане, идентификаторите и свежестта на източниците, състоянието на разрешенията, схемите на инструментите, версията на политиката, интерфейса за преглед и правилото на работния процес. Одитният пакет не трябва да съдържа всеки байт от всяка система. Той трябва да съдържа или надеждно да сочи към елементите, които биха могли да променят значението на твърдението.
Ето защо манифестът често е по-полезен от архив, изхвърлен на твърд диск. Манифестът посочва кои артефакти принадлежат заедно, техните идентификатори, техните референции за цялостност, техните взаимовръзки и условията им за достъп. Той позволява на одитора да открие съответния пакет, без да предполага, че всеки източник може да бъде копиран в неограничена папка. Някои доказателства съдържат лични данни, чувствителни детайли за сигурността, лицензирани материали или търговски тайни. Одитируемостта изисква контролиран достъп и смислена проследимост, а не задължително публично разкриване на всичко, което кара системата да работи.
Приложение IV възприема подобен практичен подход. То не третира техническата документация като кратко описание на продукта. То изисква информация за системата и нейния жизнен цикъл, включително промени, направени по време на разработката и след пускането на пазара, функции за наблюдение и контрол, процедури и резултати от валидирането и тестването, мерки за управление на риска и описание на показателите за ефективност. Документът трябва да е достатъчно ясен, за да могат националните компетентни органи и нотифицираните органи да оценят съответствието. С други думи, информацията трябва да бъде организирана за проверка, а не просто събрана, защото е имало налична система за съхранение.
Зад всичко това стои малък, но решаващ въпрос на дизайна: какво би трябвало да се промени, за да може предишното доказателство вече да не подкрепя настоящото твърдение? Отговорът създава границата на версията. Ако нов източник за извличане промени фактическата основа на препоръките, той принадлежи към идентичността. Ако нов интерфейс за рецензенти скрива предупреждение, той принадлежи към идентичността. Ако козметична редакция на текста не може да повлияе на оценяваното поведение, тя вероятно принадлежи към историята на промените, но не и към оценъчния отпечатък. Доброто управление на версиите не е максимално събиране. То е обоснована значимост.
Уловете договора, а не само резултата
Резултатът е доказателство за нещо, но не винаги е доказателство за достатъчно. Екранна снимка може да покаже какво се е появило на екрана. Тя често не може да покаже кой модел я е създал, кой източник е бил извлечен, какво е върнал даден инструмент, кое правило е било приложено, кои входни данни са били пропуснати или дали изгледът е скрил предупреждение. Това е една от причините екранните снимки да се трупат в папките за съответствие с тържествеността на археологически находки и със значително по-малка обяснителна сила.
Уловеният договор е по-богат. Той свързва резултата с условията, при които системата е трябвало да действа. За оценка това може да включва точния набор от тестове, входните данни или защитена препратка към тях, очакваните твърдения, конфигурацията на модела и услугата, съответните версии на политиката и инструментите, средата за изпълнение, доколкото тя влияе на резултата, и правилото за приемане. За работеща система това може да включва идентичността на заявката, разрешения обхват, записи за източници и извличане, маршрута на модела, извикванията на инструменти, контролите, човешката намеса и произтичащата промяна на състоянието. Целта не е да се води безкраен дневник. Тя е да се запази достатъчно причинно-следствено значима информация, за да може по-късно да се зададе сериозен въпрос.
Тук има полезна разлика, която трябва да се направи. Уловената оценка демонстрира твърдение за определен тест или упражнение. Оперативният запис помага да се реконструира конкретно събитие или решение. Записът за пускане обяснява защо дадена организация е допуснала система в определен маршрут. Записът за промяна обяснява какво е било променено по-късно. Тези записи се припокриват, но не трябва да се бъркат. Отнасянето към производствен дневник като към бенчмарк или към бенчмарк като към доказателство за производствен процес е ефикасен начин всяко запис да носи повече, отколкото може да понесе.
Правилото за регистриране на дейности в Закона за ИИ за системите с висок риск също е обвързано с целта. Член 12 изисква автоматично записване на съответните събития през целия жизнен цикъл на системата, с възможности за регистриране, подходящи за предвидената цел. Регламентът се отнася до проследимостта на функционирането на системата, наблюдението на работата и наблюдението след пускането на пазара. Той не изисква безразборен навик за записване. Той изисква записи с конкретна задача.
Този израз, записи с работа, е по-добра насока от общото изискване за наблюдаемост. Идентификаторът на модела може да помогне да се различи дадена актуализация. Произходът на входните данни може да обясни изненадваща препоръка. Версията на правило може да обясни защо даден резултат е бил блокиран. Отмяната от рецензент може да обясни защо оперативното действие се различава от предложението на модела. Времевият отпечатък може да установи последователност. Един дизайн, съобразен със защитата на личните данни, все пак пита дали всяко поле е необходимо, пропорционално, запазва се за определен период и е защитено от самата система, която трябва да проверява.
Възпроизводимостта има две честни форми
Хората често влагат в думата възпроизводимост различни значения. Объркването е разбираемо. Един екип може да има предвид, че може да пусне отново фиксирана оценка и да получи същия резултат. Изследовател може да има предвид, че друг екип може да изпълни описания метод и да провери резултата. Оператор може да има предвид, че разследване може да възстанови състоянието, използвано за конкретно решение. Клиент може да има предвид, че даден работен процес осигурява последователно третиране, вместо да се променя произволно от вторник до четвъртък. Това са свързани цели. Те не са едно свойство с различни облици.
Първо, съществува възпроизводимост на записаното изпълнение. Ако артефактът, конфигурацията, входните данни, съответното състояние и условията на изпълнение се запазят фиксирани, повторението трябва да даде документирания резултат при условията, обещани от системата. Някои системи могат да направят по-силно твърдение за детерминизъм по определен път на изпълнение. Други разчитат на контролирана случайност, разпределена инфраструктура или услуги на трети страни и могат да направят само по-тясно твърдение. Отговорният език е конкретен. Той казва какво е фиксирано, какво се измерва, какво изменение остава възможно и как се извършва сравнението.
Второ, съществува възпроизводимост на аргумента за оценка. Рецензентът трябва да може да види защо наборът от тестове представя твърдението, дали показателят има посоченото значение, дали прагът за приемане е обоснован и дали доказателствата могат да бъдат пренесени в оперативния контекст. Това не се решава с контролна сума. Контролната сума може да установи, че даден файл не е променен. Тя не може да установи, че файлът е тествал правилния въпрос, че съвкупността е била подходяща или че даден резултат подкрепя решението, свързано с него.
Двете форми трябва да се срещнат. Един напълно повторим тест, който измерва грешното нещо, все още е грешен тест. Един сложен аргумент, прикрепен към неповторимо изпълнение, оставя рецензентите неспособни да различат констатация от късметлийски следобед. Полезният стандарт не е абстрактно изискване за съвършена възпроизводимост. Той е видимо съответствие между твърдението, метода, записаните условия, наблюдавания резултат и употребата, която организацията желае да разреши.
Насоките на Комисията относно задълженията за доставчиците на модели с общо предназначение също поддържат оценката свързана с документацията и риска. Те описват техническа документация за органите и отделна информация за доставчиците надолу по веригата, включително възможности, ограничения и информация за интеграция. За моделите с общо предназначение със системен риск член 55 изисква оценка с помощта на стандартизирани протоколи и съвременни инструменти, включително документирано тестване за противодействие, за да се идентифицират и смекчат системните рискове. Една оценка, която не може да каже какво е тествано, при какви условия и с какви ограничения, не става по-полезна, защото е наречена стандартизирана.
Доказателствата имат срок на годност
Доказателствата не изтичат, защото някой е решил да е труден. Те изтичат, когато условията, които са им позволявали да подкрепят дадено твърдение, са се променили достатъчно, че връзката вече не може да се приема за даденост. Това е обичайно разсъждение. Изпитването на проект за мост не покрива автоматично различен материал. Проверката за безопасност на храните не покрива нов доставчик по силата на оптимизма. Оценката на AI маршрут не трябва автоматично да покрива променен модел, променена граница на данните, променен орган за инструментите или променено последствие от решението.
Трудната работа е да се реши кои промени имат значение. Това е въпрос на техническа преценка, анализ на риска и управление, а не един процент, записан в политика. Кръпка, която променя цвета на бутон, може да няма отношение към оценката. Промяна, която прави предупреждението по-малко видимо, може да е съществена, ако аргументът за безопасност зависи от това проверяващият да го види. Повторното индексиране на изходния корпус може да е безвредно за една задача и критично за друга. Нова крайна точка на модела може да запази широка възможност, като същевременно промени латентността, поведението при отказ, езиковото покритие или моделите на използване на инструменти, които имат значение за маршрута.
Полезният контрол на промените следователно започва с въпрос за въздействието, а не с ритуал по пускане. Кое твърдение може да засегне тази промяна? Кое предположение нарушава тя? Кои доказателства са били обвързани със старото състояние? Дали ограничена проверка отговаря на въпроса, или маршрутът се нуждае от нова оценка и решение за пускане? Кой може да вземе това решение и кой може да го оспори? Отговорите трябва да бъдат записани, защото в противен случай следващият проверяващ ще трябва да ги изведе от заглавията на задачите, слуховете и леката промяна в шрифта на таблото за пускане.
Тук също мониторингът става част от доказателствата, а не отделно хоби за наблюдаемост. Член 72 изисква от доставчиците на системи с висок риск с ИИ активно и систематично да събират, документират и анализират подходящи данни за работата през целия жизнен цикъл на системата, за да могат да оценяват непрекъснатото съответствие. Планът за мониторинг след пускането на пазара е част от техническата документация. Мониторингът следователно не е просто начин да се разбере дали услугата е натоварена. Той е начин да се научи дали условията зад първоначалното твърдение продължават да са валидни.
Мониторингът не прави всеки резултат самообясним. Повишаването на несъгласието между проверяващите и системата може да има много причини. Промяна в свежестта на източника може да отразява проблем в тръбопровода за данни, а не отклонение на модела. По-висок процент на отказ може да представлява по-безопасна политика, счупена интеграция или нова група от заявки. Записът трябва да запази достатъчно контекст за човешко разследване. Показателите са сигнали. Те не са свидетели.
Съществената промяна изисква път за решение
Изразът „съществена промяна“ често се третира така, сякаш описва от само себе си очевидно свойство. Но не е така. Съществена за кое твърдение, за кой риск и за кой потребител? Отговорът трябва да е достатъчно конкретен, за да може да се използва, когато хората са уморени, закъснели и силно искат да нарекат дадена промяна незначителна. Една добра политика не обещава да класифицира предварително всяка възможна актуализация. Тя посочва факторите, които определят дали е необходима повторна оценка.
Тези фактори обикновено включват предвидената употреба, засегнатите хора, предоставените на маршрута правомощия, източниците на данни и техния контрол на качеството, архитектурата на модела или системата, обхвата на оценката, праговете за вземане на решения, сигналите за наблюдение, човешкия надзор, мерките за сигурност и пътищата за възстановяване. Промяна, която засяга някой от тези елементи, може да е съществена, но може и да не е. От значение е дали тя може да промени доказателствата, необходими за съществуващото твърдение, или риска, оставащ след прилагане на контролите.
Актът за ИИ съдържа изрична отговорност по отношение на съществената промяна. Точното му правно приложение зависи от системата и участниците, така че не бива да се свежда до лозунг. Практическият урок е по-прост и по-широк: една организация трябва да знае кога дадена промяна прехвърля или създава отговорност, когато съществуващата документация вече не е достатъчна и когато системата трябва да бъде оценена отново, преди да продължи нова употреба. Това е по-малко вълнуващо от пускането на нова функция. Но също така е по-малко вероятно да доведе до труден случай, при който всички са съгласни, че системата се е променила, но никой не носи отговорност за решението.
Пътят за вземане на решения дава посока на промяната. Един път може да позволи документирано заключение за липса на въздействие. Друг може да изисква целенасочена регресионна оценка. Трети може да изисква по-широк преглед на риска, промяна в инструкциите за употреба, преработен план за наблюдение или ново одобрение за пускане. Най-сериозният път може да изисква маршрутът да остане ограничен или спрян, докато не са налични доказателства. Смисълът не е всяка редакция да стане скъпа. Смисълът е важната редакция да не може да бъде прикрита като рутинна домакинска работа.
В това има удовлетворяваща липса на романтика. Записът за промяна може да показва предишното състояние, предложеното състояние, засегнатите твърдения, прегледаните доказателства, решението, правомощието и условията след пускането. Това е управление в работното му облекло. То никога няма да изглежда толкова вълнуващо, колкото демонстрация на модел. Но има по-полезното свойство да помага на организацията да се обясни, когато демонстрацията се е превърнала в реална услуга.
Оценката трябва да може да се провали публично или поне във файла
Оценката се превръща в представление, когато всеки резултат се приема за резултат от пускане. Една зряла програма за оценка трябва да може да заключи, че доказателствата са непълни, че даден праг не е достигнат, че известно ограничение възпрепятства предложената употреба или че дадено твърдение трябва да бъде стеснено. Това не са смущаващи изключения от процеса. Те са резултати от процеса.
Това е особено важно за адаптивни или външно свързани системи. Екипът може да открие, че даден набор от тестове вече не представлява актуалната съвкупност от входни данни. Даден инструментален договор може да стане твърде нестабилен, за да поддържа твърдение за възпроизвеждане. Актуализация на модела може да подобри една задача, но да затрудни надзора на защитен маршрут. Оперативен сигнал може да покаже, че предаването от системата към рецензента се проваля при обикновено натоварване. Правилният отговор не е непременно драматично спиране. Той може да бъде ограничение, преработен работен процес, допълнителен тест, ново условие за приемане или решение да не се прави първоначалното твърдение.
Записът трябва да позволи на проверяващия да види този отрицателен резултат. В противен случай дадена организация изгражда много ефективна машина за събиране само на доказателствата, които харесва. Изискванията за управление на качеството в член 17 са от значение тук. Те обхващат, наред с другото, техники и процедури за проектиране, разработка и контрол на качеството; преглед, изпитване и валидиране; управление на данни; управление на риска; проследяване след пускане на пазара; докладване на инциденти; и комуникация с органите. Системата за качество не е папка, която кара грешките да изчезнат. Тя е начин те да бъдат откривани, документирани и адресирани.
Същият принцип важи и за достъпа. Външен регулаторен орган, нотифициран орган или упълномощен проверяващ може да се нуждае от технически доказателства, които не могат да бъдат публикувани открито. Публично резюме може да е подходящо за други части от записа. Това са различни пътища за достъп, а не различни факти. Обществеността не трябва да получава оптимистичен разказ, докато контролираният запис описва по-тясна и по-обусловена реалност. Поверителността може да е легитимна. Противоречието е провал в управлението.
В Dweve нашият публичен Trust Centre дава малък, съзнателно ограничен пример за това разграничение. Неговата страница за оценки казва, че оценката идентифицира модела, точния пакет, конфигурацията, записаното състояние, доказателствата и решението на проверяващия. Тя също така казва, че повторно изпълнение на записан договор трябва да даде идентични байт за байт резултати на поддържаните архитектури, докато живо повторно изпълнение може да се различава, когато външните доказателства или адаптивното състояние се променят. Страницата разделя публичния метод от попълнения маркетингов резултат. Това не е доказателство за качеството на модела. Това е просто правилната форма на твърдение относно записите от оценки.
Живото наблюдение не замества решението преди пускането
Наблюдението понякога се описва като отговора на несигурността: пуснете системата, следете таблото, усъвършенствайте непрекъснато. В това изречение има полезен инстинкт. Системите се нуждаят от наблюдение след пускането, защото внедряването произвежда информация, която лабораторията не може. Но наблюдението не може със задна дата да подкрепи решение, за което доказателствата никога не са били достатъчни. То не може да каже на човек, засегнат от грешно действие с високи последици, че организацията ще се поучи от графиката следващия месец.
Оценката преди пускането и наблюдението след пускането отговарят на различни въпроси. Оценката пита дали организацията разполага с достатъчно доказателства, за да разреши определена употреба сега. Наблюдението пита дали условията зад това разрешение все още са валидни и дали се появяват нови рискове или грешки. Първото установява начална граница. Второто наблюдава границата в действие. Една надеждна система се нуждае и от двете, както и от път за данните и оперативното учене да се върнат към оценката на риска, документацията и контрола на промените.
Този цикъл превръща статичния пакет за осигуряване в жив запис. Оценката дава базово ниво. Записът за внедряване казва кое базово ниво е прието. Регистрирането и наблюдението показват съответното поведение. Промяна може да промени базовото ниво или да разкрие неговите граници. След това преглед актуализира твърдението, неговите доказателства, неговите ограничения или неговия статус. Системата се движи. Записът се движи с нея, но не пренаписва собственото си минало. Одиторът може да види както текущата позиция, така и пътя, по който е достигната.
За системите с висок риск Законът за ИИ е изричен, че проследяването след пускане на пазара трябва да събира и анализира съответните данни за ефективността през целия жизнен цикъл и да позволява оценка на непрекъснатото съответствие. Той също така изисква от внедряващите да наблюдават работата въз основа на инструкциите за употреба и да информират доставчика и съответния орган без неоправдано забавяне, когато имат основание да смятат, че употребата може да представлява риск. Тези изисквания не премахват нуждата от професионална преценка. Те дават на професионалната преценка записи, тригери и пътища.
Съществува организационно изкушение да се третира мониторингът като отговорност на оперативния екип, а оценката като отговорност на екипа за модела. Това разделение ще се провали още при първия съдържателен въпрос за действащ маршрут. Моделистът може да знае защо е избран даден тест. Операторът може да знае, че източниците са били остарели. Собственикът на политиката може да знае, че правило за вземане на решение е било променено. Проверяващият може да знае, че интерфейсът създава пристрастие към автоматизацията. Одитната пътека трябва да обедини техните доказателства, без да се преструва, че един човек вижда цялата система.
Може ли регулатор да възпроизведе дадено решение?
Понякога отговорът трябва да е „да“, в рамките на ясно определен обхват. Ако дадена организация твърди, че дадено решение или оценка може да бъде възпроизведено, тя трябва да уточни какво означава възпроизвеждане. Означава ли повторно извикване на модела със същия подкана? Означава ли изграждане наново на целия поток за извличане и инструменти? Означава ли възстановяване на записа, който проверяващият е видял? Означава ли валидиране на детерминистично изчисление от запазени входни данни? Всяко от тях е полезно. Всяко има различни технически и правни предпоставки.
Смисленото възпроизвеждане започва със запазена идентичност. Проверяващият трябва да знае коя версия на системата и коя конфигурация са били в сила, кои входни данни и версии на източници са били допустими, кои политики и разрешения са се прилагали, кои външни зависимости са отговорили и кои човешки действия са променили пътя. Някои елементи може да се наложи да бъдат съхранявани директно. Други могат да бъдат посочени чрез стабилни идентификатори и възстановени чрез контролирани системи. Недопустимо е да се нарича дадено упражнение възпроизводимо, когато то зависи от живо уеб търсене, презаписан ред в база данни и запомнена настройка от лаптопа на инженер.
Дори тогава възпроизвеждането може да възпроизведе запис, а не да повтори света. Жив източник може да бъде актуализиран или оттеглен. Услуга на трета страна може да се промени. Адаптивна услуга може да натрупа ново управлявано състояние. Човек може да вземе различно решение, когато му бъде представена същата информация. Това не са недостатъци на идеята за възпроизвеждане. Това са различия, които записът трябва да запази. Възпроизвеждането може да покаже какво е направила системата при договорените условия. То не твърди, че настоящият свят е идентичен с тези условия.
Ето защо записите за човешки решения трябва да стоят до техническите записи, когато човешкият надзор е част от аргумента за безопасност или права. Одитът може да трябва да знае, че дадено лице е прегледало препоръка, каква информация е била на разположение на това лице, какво е избрало то и какви правомощия е имало. Не е необходимо всеки проверяващ да се превръща в обект на наблюдение или да се съхранява неограничен личен материал. Необходима е достатъчно информация, за да се установи дали обещаният надзор е съществувал при разглежданото събитие.
Възпроизвеждането следователно е стълба, а не самохвалство. На едно стъпало проверяващият може да идентифицира версията. На следващото може да разгледа доказателствата. По-нагоре може да пресъздаде тест или да анализира пътя на живо решение. Организацията трябва да посочи кое стъпало поддържа, къде са границите и кои части изискват упълномощен достъп. Скромно и проверимо твърдение за възпроизвеждане е много по-силно от неясно уверение, че всичко може да бъде проследено.
Одитите се нуждаят от записи, които си противоречат
Публичният статусен запис на организацията, вътрешният запис за пускане, докладът за оценка, оперативните регистри и регистърът на инциденти не трябва да казват различни неща за едно и също основно състояние. Но те не трябва да бъдат и идентични документи. Всеки има различна аудитория и цел. Публичният запис може да посочва предназначението, статуса, известните ограничения и път към допълнителна информация. Техническият файл може да съдържа подробна архитектура, данни, тестове и контроли. Оперативният запис може да съдържа проследимост на ниво събитие. Файлът с промените може да обясни защо предишен извод е бил преразгледан.
Целостността идва от съответствието. Ако публична страница казва, че даден маршрут е ограничен до препоръка, техническите и оперативните записи не трябва да описват автоматично действие. Ако оценка казва, че се отнася до уловен набор от източници, записът за пускане не трябва мълчаливо да я прилага към по-късен такъв. Ако запис за промяна казва, че актуализацията на модела е била несъществена, оценката на въздействието трябва да посочи засегнатото твърдение и доказателствата. Ако сигнал за мониторинг повдига преглед, последващото решение трябва да може да бъде проследено. Документите може да се различават по степен на детайлност. Те не трябва да си противоречат относно реалността.
Това съответствие е полезно за регулаторите, защото намалява нуждата да се вярва на един полиран артефакт. Проверяващият може да сравнява записи. Полезно е за организациите, защото разкрива отклонения между екипите, преди външен одит да го направи. И е полезно за засегнатите хора, защото публичното обяснение може да стане реален път към отчетност, а не декоративен слой, поставен върху отделна частна система.
Архитектурата не трябва да е сложна. Малка организация може да използва контролиран регистър, версионирани документи, подписани експорти и дисциплинирани прегледи на промени. По-голяма организация може да използва структурирани манифести, логове само за добавяне, политически двигатели и автоматизирано улавяне на доказателства. Важният въпрос е дали методът може надеждно да свърже твърдение, състояние, доказателство, решение и по-късна промяна. Огромен инструментариум, който губи тази връзка, е просто по-скъп начин да бъдеш неясен.
Има особено европейска добродетел в това записът да бъде проверим, без да е театрален. Не всеки отговор принадлежи на публичен табло. Не всяка документирана несигурност се нуждае от весела икона. Но когато организация е направила съществено твърдение за адаптивна система, тя трябва да може да покаже на регулатор къде живее това твърдение, към какво състояние се отнася и как организацията би разбрала, че то е остаряло.
Въпросът за одита променя въпроса за дизайна
Попитайте рано дали регулатор би могъл да одитира системата така, както тя действително ще работи. Отговорът променя дизайнерските избори много преди формалния одит да започне. Той благоприятства стабилни идентификатори пред двусмислени етикети. Благоприятства изрични версии на политики пред правила, вградени в проза. Благоприятства договори за инструменти, които могат да бъдат записани и тествани. Благоприятства произхода на източниците и маркери за свежест. Благоприятства ясна граница между препоръка и действие. Благоприятства екрани за преглед, които запазват информацията, от която проверяващият се нуждае. Благоприятства механизми за пауза и възстановяване с посочен орган.
Това също променя доставките. Твърдението на доставчик, че моделът се подобрява редовно, не е достатъчно, когато внедряването зависи от определено оценено състояние. Купувачът трябва да знае как се съобщават промените, кои артефакти могат да бъдат идентифицирани, каква информация е налична за оценка на въздействието, дали историческите записи остават интерпретируеми и как маршрут може да бъде ограничен или поставен на пауза. Това не са екзотични изисквания. Те са практическите условия, при които организацията остава отговорна за система, съдържаща компонент от доставчик.
Същият въпрос променя дизайна на оценката. Полезният набор има идентичност и обосновка. Неговите входове или референции са контролирани. Неговите показатели и прагове са определени, преди резултатът да бъде прочетен. Неговите изключения са видими. Неговите резултати се прикрепят към действително обсъжданото състояние на системата. Неговите неуспехи имат път към решение. Неговите условия за повторно изпълнение са ясни. Оценка с тези свойства може да бъде оспорена. Това е характеристика, а не неприятен страничен ефект от това да бъдеш задълбочен.
Най-вече въпросът променя ролята на промяната. Промяната престава да бъде неудобство, което документацията се опитва да скрие. Тя се превръща в първостепенно събитие в модела на доказателствата на системата. Някои промени ще изискват малко повече от запис. Някои ще задействат тест. Някои ще отворят отново решението за пускане. Дисциплинираната организация не смесва тези категории и не ѝ е необходим бъдещ инцидент, за да открие, че те съществуват.
Така че да: регулаторният орган може да одитира движеща се цел. Одитът започва с отхвърляне на фалшивия избор между замразен моделен лист и напълно непознаваема жива услуга. Запишете състоянието. Посочете твърдението. Запазете условията. Свържете доказателствата с решението. Отбележете какво се променя. Преоценете, когато връзката вече не е валидна. Целта може да се движи. Пътеката трябва да остане четлива.
Източници
- Регламент (ЕС) 2024/1689, Законът за изкуствения интелект, Европейски парламент и Съвет, достъпен на 5 август 2026 г.
- Член 11: Техническа документация, Европейска комисия, служба за поддръжка на Закона за ИИ, достъпен на 5 август 2026 г.
- Член 72: Наблюдение след пускането на пазара от доставчиците и план за наблюдение след пускането на пазара за системи с ИИ с висок риск, Европейска комисия, служба за поддръжка на Закона за ИИ, достъпен на 5 август 2026 г.
- Член 55: Задължения на доставчиците на модели с ИИ с общо предназначение със системен риск, Европейска комисия, служба за поддръжка на Закона за ИИ, достъпен на 5 август 2026 г.
- Етични насоки за надежден ИИ, Европейска комисия, експертна група на високо равнище по ИИ, достъпни на 5 август 2026 г.
- Насоки относно задълженията на доставчиците на ИИ с общо предназначение, Европейска комисия, достъпни на 5 август 2026 г.
- Оценки на модели, Dweve Trust Centre, достъпни на 5 август 2026 г.