Мониторинг след пускане на пазара по Закона на ЕС за ИИ (чл. 72): Задължения за доставчиците на ИИ с висок риск

Съответствието не приключва при влизането на пазара. Чл. 72 изисква от доставчиците на системи за ИИ с висок риск да поддържат активна система за мониторинг след пускане на пазара, да събират данни за изпълнението и да докладват сериозни инциденти. Ето какво трябва да правите — и кога.

Какво е мониторинг след пускане на пазара?

Оценката на съответствието и CE маркировката са входният билет за пазара на ЕС за система за ИИ с висок риск — а не финалната линия. Член 72 от Закона на ЕС за ИИ налага продължаващо задължение: доставчиците трябва да установят и управляват система за мониторинг след пускане на пазара (МПП), която активно събира, анализира и действа върху данни за изпълнението в реалния свят през целия оперативен живот на системата.

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

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

Кой трябва да установи система за МПП?

Задължително за:

• Доставчиците на самостоятелни системи за ИИ с висок риск по Приложение III — системи, изброени в Приложение III, непредставляващи компоненти за безопасност на продукт (напр. ИИ, използван при решения за заетост, достъп до образование, правоприлагане, оценка на кредитоспособността, управление на критична инфраструктура)
• Доставчиците на системи за ИИ с висок риск, вградени в продукти по Приложение I — компоненти за безопасност с ИИ, интегрирани в продукти, обхванати от съществуващото законодателство на ЕС за хармонизация (медицински изделия, машини, превозни средства)

Не се изисква за:

• Доставчиците на системи за ИИ с минимален риск (няма официално задължение за МПП, макар да се прилагат добри практики)
• Доставчиците на системи за ИИ само с прозрачност (задълженията по чл. 50 не се разширяват до МПП)
• Доставчиците на GPAI модели — те са обект на отделен режим по чл. 61–62, включващ докладване на инциденти за модели с системен риск, но е структуриран по различен начин от МПП по чл. 72

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

Планът за мониторинг след пускане на пазара (Приложение IV, точка 12)

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

1. Събиране на данни — какви показатели за изпълнение се улавят (точност, степени на грешки, резултати от решения), как се събират данните (автоматична телеметрия, доклади от крайни потребители, обратна връзка от потребители) и с каква честота
2. Контури за обратна връзка — механизмът, чрез който крайните потребители могат да докладват проблеми с изпълнението, аномалии или инциденти на доставчика по структуриран и навременен начин
3. Мониторинг на точността — как изпълнението на системата се проследява спрямо валидирания еталон, използван по време на оценката на съответствието, включително методологията за установяване на дрейф
4. Мониторинг на пристрастието — за системи, при които демографските резултати са материални (набиране на персонал, кредит, правоприлагане), текущ мониторинг на статистическите разлики между защитени групи, с определена методология и прагове
5. Задействащи фактори за актуализации — конкретните количествени или качествени прагове, подтикващи коригиращи действия, включително преобучение на модела, корекция на параметрите или спиране на разгръщането
6. График за преглед — колко често самият план за МПП се преглежда и актуализира, осигурявайки неговата годност за целта с развитието на контекста на разгръщане

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

Докладване на сериозни инциденти (чл. 73)

Какво представлява сериозен инцидент?

Член 73 определя сериозен инцидент като всеки инцидент или неизправност на система за ИИ с висок риск, водещи пряко или непряко до:

• Смърт или сериозна вреда за здравето (физическа или психологическа)
• Сериозно и необратимо нарушаване на управлението или функционирането на критична инфраструктура
• Сериозно нарушение на основните права (поверителност, недискриминация, надлежен процес)
• Ситуация, при която дадено лице е едва избегнало гореизброеното

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

Срокове за докладване

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

Какво трябва да съдържа докладът за инцидент

Съответстващият доклад за инцидент до националния орган за надзор на пазара трябва да включва:

• Идентификация на системата: наименование, версия, регистрационен номер в базата данни на ЕС
• Описание на инцидента: какво се е случило, каква вреда е настъпила или е едва избегната, дата и място
• Засегнати лица: брой и категории засегнати потребители или трети лица (анонимизирани, когато се изисква от GDPR)
• Предварителен причинен анализ: текущото разбиране на доставчика за това как е възникнал инцидентът, ясно обозначено като предварително
• Предприети незабавни коригиращи или защитни мерки: всякакви стъпки, вече предприети за ограничаване на по-нататъшни вреди или риск (напр. спиране на засегнатата функционалност, уведомления за крайни потребители)
• Точка за контакт: лицето или екипът, отговорни за последващата кореспонденция с органа

Докладът трябва да е фактически и пропорционален. Предварителните доклади могат да бъдат допълвани от последващи доклади с развитието на разследването.

Задължително регистриране (чл. 12)

Член 12 изисква системите за ИИ с висок риск да бъдат проектирани и изградени с възможност за автоматично генериране на журнали на ниво на детайлност, достатъчно за:

• Мониторинг след пускане на пазара в съответствие с чл. 72
• Проследяване на събитията, водещи до сериозен инцидент
• Разследване от националните органи

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

Задължението за активиране и съхраняване на тези журнали пада върху крайния потребител. Крайните потребители не трябва да деактивират функцията за регистриране и трябва да съхраняват журналите за периода, посочен в инструкциите и техническата документация на доставчика. Когато не е определен конкретен срок за съхранение, журналите трябва да се съхраняват за период, съизмерим с оперативния жизнен цикъл на системата и всякакви приложими секторни изисквания (напр. правила за водене на документация в сферата на финансовите услуги по DORA или MiFID II).

Съществени модификации и повторна оценка

Не всяка промяна в разгърната система за ИИ задейства нова оценка на съответствието. Законът разграничава незначителни актуализации и съществени модификации.

Модификацията е съществена — и изисква нова оценка на съответствието и актуализирана техническа документация — когато:

• Променя предназначената цел на системата (дори частично)
• Включва значителна промяна на архитектурата или методологията за обучение
• Използва нови данни за обучение, материално засягащи изпълнението на системата по начини, влияещи на поведение, свързано със съответствието
• Влошава изпълнението под праговете, определени в документацията за управление на риска, по начини, засягащи безопасността или основните права

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

Практически контролен списък за прилагане

Следният контролен списък отразява минималните оперативни изисквания по чл. 72, чл. 73 и чл. 12. Той не е заместител на правен съвет, но представлява отправна точка за анализ на пропуските.

• [ ] Планът за МПП е документиран в техническото досие (Приложение IV, точка 12), специфичен за системата и нейния контекст на разгръщане
• [ ] Способност за автоматично регистриране е проектирана и вградена в системата преди пускане на пазара
• [ ] Инструкциите за крайния потребител включват ясна, писмена процедура за докладване на инциденти с контакт за ескалация
• [ ] Вътрешна точка за контакт при докладване на инциденти е установена и уведомена на съответния национален орган за надзор на пазара
• [ ] Процеси или таблa за мониторинг на пристрастие и точност са дефинирани с документирана методология и прагове
• [ ] Прагове за ескалация за коригиращи действия са документирани и свързани с системата за управление на риска
• [ ] Процедура за оценка на съществени модификации е въведена с шаблон за запис на решения за всяка актуализация
• [ ] Политика за съхранение на журнали е определена, съобщена на крайните потребители и съответства на секторните правила за съхранение

Кръстосани препратки: Техническа документация — Системи за ИИ с висок риск по Приложение III — Доставчици срещу крайни потребители