За насУслугиПроектиСтатии

Инженерно съответствие с Акта за изкуствения интелект на ЕС: техническа документация, регистриране, човешки надзор и управление на данните

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

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

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

Актът за изкуствения интелект (Регламент (ЕС) 2024/1689) влезе в сила през август 2024 г. и се прилага на етапи. През 2026 г. етапите бяха променени и си струва да сме точни, защото промяната пренасочи и пари, и внимание.

  • 2 февруари 2025 г.: започнаха да се прилагат забранените практики и задълженията за грамотност в областта на ИИ.
  • 2 август 2025 г.: започнаха да се прилагат задълженията за моделите на ИИ с общо предназначение.
  • 2 август 2026 г.: започнаха да се прилагат задълженията за прозрачност по член 50: оповестяване, че потребителят взаимодейства със система с ИИ, маркиране на синтетично съдържание, оповестяване на разпознаването на емоции и биометричното категоризиране, както и обозначаване на дълбинните фалшификати.
  • 2 декември 2027 г.: задълженията за самостоятелните високорискови системи, след Цифровия омнибус. Съветът и Парламентът договориха отлагането през май 2026 г., а окончателното одобрение беше дадено през юни 2026 г.
  • 2 август 2028 г.: задълженията за високорисковите системи с ИИ, вградени в регулирани продукти.

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

Какво изграждаме

Техническа документация, която се генерира

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

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

Автоматично регистриране на събития, което отговаря на член 12

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

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

Управление на данните по член 10

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

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

Човешки надзор, който е изграден, а не деклариран

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

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

Мониторинг след пускането на пазара и докладване на инциденти

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

Задължения за прозрачност по член 50

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

Подкрепа за регистрацията и оценката на съответствието

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

Какво не предлагаме

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

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

За кого е тази услуга

Доставчици на високорискови системи с ИИ по приложение III (подбор на персонал и управление на работници, кредитен скоринг, ценообразуване в застраховането, оценяване в образованието, достъп до основни услуги, биометрични системи), които вече имат срок до декември 2027 г. и много за изграждане.

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

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

Всички, които предлагат генеративни функции на потребители в ЕС, за които прозрачността по член 50 се прилага още днес, независимо от категорията риск.

Как протича работата

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

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

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

Стандарти и рамки

Регламент (ЕС) 2024/1689 и приложения III и IV към него; хармонизираните стандарти, които се разработват от CEN/CENELEC JTC 21; ISO/IEC 42001 за системите за управление на ИИ и ISO/IEC 23894 за управлението на риска при ИИ; NIST AI Risk Management Framework, когато американско дружество майка се нуждае от съгласуваност; и ОРЗД, който не изчезва и ограничава повечето решения за регистриране на събития.

Често задавани въпроси

Отложен ли е Актът за ИИ?

Отчасти. Цифровият омнибус отложи задълженията за високорисковите системи до 2 декември 2027 г. за самостоятелните системи и до 2 август 2028 г. за ИИ, вграден в регулирани продукти. Забранените практики, грамотността в областта на ИИ, задълженията за моделите на ИИ с общо предназначение и правилата за прозрачност по член 50 не бяха отложени и са в сила сега.

Използваме само системи с ИИ, изградени от други. Имаме ли задължения?

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

Системата ни не е високорискова. Има ли какво да направим?

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

Наистина ли техническата документация може да се генерира?

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

Как се съчетава Актът за ИИ с ОРЗД?

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

Ако използваме модел на трета страна, ставаме ли доставчик на този модел?

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

Да започнем

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

Свържете се с нас, за да заявите технически анализ на пропуските по Акта за ИИ.

Свързани услуги

Готови ли сте да започнете с тази услуга?

Свържете се с нас
← Обратно към всички услуги