Почему этот чек-лист не для всех
Когда команда первый раз слышит про обязанности deployer, первый рефлекс — открыть Article 26, пробежать по 12 параграфам, превратить их в 13 пунктов чек-листа и начать раскладывать всё это по процессам. В первичных аудитах готовности этот сценарий встречается регулярно, и почти всегда он заканчивается одинаково — переработанные требования, утомлённая команда, и часть из этих обязанностей вообще к ним не относится.
Дело в том, что Article 26 — это не «универсальные правила работы с AI». Это узкая статья, написанная для конкретной ситуации: вы используете AI-систему, которая попадает в категорию высокорисковых, и используете её под собственной ответственностью. Если хоть одна часть этой формулы не сходится — статья к вам не применяется. Бывают команды, которые искренне думают, что они deployer высокорисковой системы, а на самом деле они либо не deployer, либо система не высокорисковая. И тогда выполнять 13 пунктов — это не выполнение требований, это просто потеря времени.
Поэтому правильный порядок действий — сначала пройти проверку из двух вопросов, и только потом, если оба ответа «да», возвращаться к чек-листу. Эта статья построена в том же порядке. И ещё одна важная деталь — даже когда обязанности применяются, не все 13 пунктов одинаково тяжёлые. Часть из них — обычная операционная дисциплина, которая у зрелой команды уже есть. Часть — узкие частные случаи, которые касаются только государственных органов или правоохранительных. А несколько пунктов — это реальная работа на месяцы. Я ниже разложил их по группам, чтобы было видно, где сосредоточить ресурс.
Когда Article 26 вообще применяется к вам
Чтобы статья начала работать, должны одновременно выполниться два условия. Не последовательно, не «по одному из», а оба сразу.
Вы — deployer этой конкретной системы
Роли по EU AI Act привязаны не к компании, а к конкретной AI-системе и конкретному сценарию её использования. По системе от внешнего вендора — вы deployer. По системе, которую вы выпустили под своим брендом, — вы provider. Если вы перепродаёте без модификации — distributor. Если поставляете на рынок ЕС — importer.
AI-система действительно высокорисковая
Это Annex I (AI-компоненты в продуктах с гармонизированным законодательством о безопасности) или Annex III (восемь категорий: биометрия, критическая инфраструктура, образование, занятость, доступ к услугам, правоохранительные органы, миграция, правосудие). Но попадание в Annex III — ещё не автоматически высокорисковая.
Три важных оговорки по высокорисковому статусу
Главная ловушка — думать, что попадание в Annex III автоматически делает систему высокорисковой. Это не так. Article 6(3) явно допускает исключение: если AI-система из Annex III по своему характеру не создаёт значимого риска для здоровья, безопасности или основных прав людей и не влияет существенно на принятие решений в отношении них — она может не быть высокорисковой.
Первая оговорка — исключение не применяется, если ваша Annex III-система выполняет профилирование (profiling) физических лиц. Если система анализирует людей по их характеристикам, чтобы предсказать что-то о них, — она остаётся высокорисковой, даже если на первый взгляд «не сильно влияет на решение».
Вторая оговорка — снять статус высокорисковой системы должен provider, а не вы как deployer. Article 6(4) обязывает provider заранее задокументировать оценку по Article 6(3) и зарегистрировать вывод «не высокорисковая» в базе данных ЕС. Если provider утверждает, что Annex III-система к вам неприменима — попросите ссылку на эту регистрацию. Пока её нет — обращайтесь с системой как с высокорисковой.
Третья оговорка — деление между Annex I и Annex III важно для дальнейших обязанностей. Часть пунктов чек-листа применяется только к одной из этих категорий. Например, обязанность информировать физических лиц при принятии решений (Article 26(11)) — только для Annex III.
Если хотя бы одно условие не выполнено
Тогда Article 26 к вам не относится напрямую. Это не значит, что у вас вообще нет обязанностей по EU AI Act. У вас может быть Article 4 (AI-грамотность) — он применяется ко всем компаниям, которые работают с AI-системами, независимо от уровня риска. Может быть Article 50 (прозрачность для чат-ботов, генеративного AI, дипфейков). Но конкретный чек-лист из 13 пунктов — это не ваш случай.
И ещё одна важная вещь, которую часто упускают. Даже если Article 26 не применяется к вам напрямую, он может применяться к вашему клиенту, если этот клиент использует ваш AI-продукт под собственной ответственностью на рынке ЕС. Тогда клиент — deployer, и в момент закупочного due diligence он спросит у вас, как ваш продукт помогает ему выполнять Article 26: где данные для него input data, где логи под его контролем, как организован человеческий контроль на стороне клиента. Если у вас слабый или отсутствующий ответ — контракт уйдёт к более готовому конкуренту. Подробнее про эту сторону — в материале «Как ответить на запрос клиента про EU AI Act».
Article 26 не ваш случай напрямую — но Article 4, Article 50, или запрос от клиента могут быть. Если вы не уверены, какая часть EU AI Act применяется к вам или к вашему клиенту, — обсудим вашу ситуацию →
Чем deployer отличается от provider
Я часто слышу в командах фразу: «провайдерские обязанности — это не про нас, мы только используем». Иногда это правда. Иногда — нет, и команда не замечает, что у неё одновременно две роли.
Provider держит контур разработки, deployer держит контур эксплуатации.
Provider отвечает за то, как система спроектирована и как она вышла на рынок ЕС: оценка соответствия (conformity assessment), техническая документация, система управления качеством (QMS), система пострыночного мониторинга, регистрация в базе данных ЕС. Deployer отвечает за то, как система ведёт себя в реальном использовании: применяется ли она по инструкции, есть ли осмысленный человеческий контроль (human oversight), мониторится ли работа, информируются ли затронутые люди.
Граница между ролями проходит не по компании, а по системе. Одна и та же команда может быть deployer по системе, которую они купили у внешнего вендора, и одновременно provider по системе, которую они разработали и выпустили под своим брендом. Тогда применяются оба слоя обязанностей: provider по Articles 16–22 и deployer по Article 26. Это не «двойная нагрузка ради бюрократии», это два разных набора задач для двух разных функций — и игнорировать одну из них опасно.
Простой тест по Article 25 EU AI Act — три триггера, любого из которых достаточно: (1) вы выпустили AI-систему на рынок ЕС под собственным именем или брендом; (2) вы существенно модифицировали чужую систему (fine-tuning, RAG, изменение поведения через промпты и архитектуру); (3) вы изменили её назначение по сравнению с тем, для чего её выпускал оригинальный provider. Если хотя бы один триггер срабатывает — по этой системе вы не просто deployer. Вы как минимум provider, и применяются обязанности provider per Articles 16–22. И наоборот: если вы только подключаете чужую систему по её инструкциям, не меняете назначение и не выпускаете ничего своего — вы только deployer. Article 26 привязан к роли deployer, а не к тому, внутренний у вас provider или внешний.
13 обязанностей — разложенных по группам
Article 26 содержит 12 параграфов. Я разбил их в 13 операционных пунктов, потому что параграф 5 объединяет три разных действия (мониторить, эскалировать, сообщать об инциденте), и логичнее держать их отдельно. Но и 13 — это не «список равнозначных дел». Я разложил их по пяти смысловым группам, чтобы было видно, где сосредоточить ресурс.
Базовая дисциплина использования
Это фундамент. Без этих четырёх пунктов остальные не имеют смысла. Если у вас здесь дыра — закрывайте её первым делом.
Использовать систему по инструкциям provider Article 26(1)
На практике это означает три конкретных вещи. Во-первых, у команды должна быть актуальная инструкция от provider — не та, что была год назад, а та, которая сейчас. Договор с provider должен требовать уведомлять вас об изменениях, а ваша внутренняя процедура — фиксировать получение новой редакции и доводить её до затронутых сотрудников. Во-вторых, у команды должны быть внутренние процедуры, которые обеспечивают применение системы строго в рамках её назначения (intended purpose). Если provider говорит «эта система для рекомендации товаров», а вы её начали использовать для оценки кредитоспособности — вы вышли за пределы назначения. В-третьих, должен быть запрет на использование вне назначения — либо процедурно, либо технически.
Команда читает инструкцию один раз при внедрении, после этого о ней забывает. Через год provider обновил инструкцию, добавил новые ограничения, убрал какие-то функции из числа поддерживаемых, — а команда продолжает работать по старой версии и формально нарушает Article 26(1).
Назначить человеческий контроль Article 26(2)
Article 26(2) требует, чтобы вы выделили конкретных людей, ответственных за человеческий контроль (human oversight) над работой системы, и чтобы у них были компетенция, обучение, полномочия и поддержка для этой роли. Это не «галочка в табеле». Article 14 описывает, что provider должен заложить в систему и инструкции, чтобы контроль был возможен. У вас как deployer задача — сделать так, чтобы он работал на практике. Подробнее об этом — отдельная секция ниже, потому что это тема, на которой команды регулярно проваливаются.
Контролировать входные данные, где применимо Article 26(4)
Эта обязанность применяется только если вы фактически контролируете входные данные системы. Если вы используете чужую систему, в которую данные подаёт пользователь напрямую — вы не контролируете эти данные, и обязанность к вам не применяется. Если же вы сами решаете, какие данные система получает на вход (например, грузите в неё свою клиентскую базу), — вы должны убедиться, что эти данные релевантны и достаточно репрезентативны для назначения системы.
Что значит «убедиться» на практике: задокументировать источник данных, проверить соответствие назначению системы, отметить очевидные пробелы в выборке, описать процедуру обработки исключений. Это не требует научной строгости — это операционный минимум.
Хранить логи минимум 6 месяцев Article 26(6)
Если высокорисковая система автоматически генерирует логи и эти логи находятся под вашим контролем как deployer — храните их минимум шесть месяцев. Дольше можно, меньше — нельзя. Срок может быть длиннее, если этого требует право ЕС или национальное право (например, для финансовых учреждений могут быть свои правила хранения).
Тут важна формулировка «под контролем deployer». Если логи технически генерируются, но физически хранятся у provider в его инфраструктуре — это вопрос договорной архитектуры, и обязанность распадается между сторонами. Зафиксируйте в договоре, кто что хранит.
Команда настраивает retention в инфраструктуре по принципу «удалим через 90 дней, чтобы не платить за хранилище». Это короче, чем 6 месяцев, и формально нарушает Article 26(6).
Реакция на проблемы
Эта группа — про то, что делать, когда система начинает вести себя не так, как ожидалось. У зрелой команды эти процедуры уже есть как часть операционной зрелости. У молодой — как правило, нет, и Article 26(5) их фактически вынуждает построить.
Мониторить работу системы Article 26(5), Article 72
Deployer обязан мониторить операционную работу высокорисковой системы согласно инструкциям provider. Где это применимо — информировать provider о существенных наблюдениях по правилам Article 72. Это операционная функция, требующая регулярных процедур: кто-то в команде смотрит на показатели работы системы, на основные метрики, на отклонения от нормы. Не разово, а в виде установленного процесса. Для финансовых учреждений мониторинг может исполняться через правила внутреннего управления и применимое финансовое регулирование.
Эскалировать при обнаружении риска Article 26(5)
Если у вас есть основания считать, что использование системы по инструкциям может приводить к рискам, — без задержки информируйте provider или distributor и компетентный надзорный орган и приостановите использование системы. «Без задержки» — это обязательство, не пожелание. Конкретного срока в законе нет, но «через две недели» — это уже не «без задержки».
Команда видит подозрительное поведение системы, фиксирует в очередь задач, ждёт следующего планового обновления от provider. Article 26(5) требует другого — поднять флаг сразу и приостановить использование, пока не разобрались.
Уведомить о серьёзном инциденте Article 26(5), Article 73
Серьёзный инцидент (serious incident) — это термин из Article 3, и он значит больше, чем просто «что-то сломалось». Это инциденты, повлёкшие смерть, серьёзный вред здоровью, серьёзный ущерб имуществу или окружающей среде, серьёзные нарушения основных прав или существенные сбои в критической инфраструктуре. Если такое произошло — немедленно информируйте provider, затем importer/distributor и компетентные надзорные органы. Article 73 устанавливает сроки и применяется как резервный порядок, если deployer не может связаться с provider напрямую (mutatis mutandis).
Чёткая последовательность: provider — первым. У provider есть возможность быстро понять, единичный ли это инцидент или системная проблема всей модели. Команда должна заранее знать каналы связи с каждым provider — про это будет отдельная секция ниже.
Прозрачность для затронутых людей
Эти обязанности часто воспринимаются как продолжение GDPR. Это близко, но не одно и то же. Article 26 добавляет два специфичных требования к информированию, и оба ограничены конкретным контекстом.
Информировать работников и их представителей Article 26(7)
Если вы deployer высокорисковой AI-системы и используете её на рабочем месте — вы обязаны до начала использования или ввода системы в эксплуатацию проинформировать затронутых работников и их представителей. Это отдельная обязанность, не сводится к общему требованию прозрачности и не покрывается уведомлениями GDPR. Применяется ко всем deployers на рабочем месте, не только государственным органам.
Что значит «информировать» на практике: дать работникам понятное описание того, какая система используется, для чего, какие решения она принимает или поддерживает. Если есть представители работников — профсоюз, рабочий совет, — информировать их отдельно. Сделать это нужно до того, как система начала работать, не задним числом.
Информировать физических лиц при принятии решений или участии в их принятии Article 26(11)
Эта обязанность ограничена по сфере действия — она применяется только к высокорисковым системам из Annex III, и только если система принимает решения в отношении физических лиц или участвует в их принятии. К Annex I high-risk системам она не применяется автоматически. Обязанность не отменяет требования Article 50, а действует параллельно. Для правоохранительных органов действует Article 13 Directive (EU) 2016/680.
Что значит «информировать» — что человек должен знать, что в отношении него принимается решение с использованием высокорисковой AI-системы. Не каждую техническую деталь, но факт использования AI и его роль в решении.
Частные случаи
Эти три обязанности применяются не ко всем deployers высокорисковых систем. Если ваш сценарий не попадает под них — пропускайте.
Государственные органы — регистрация в базе данных ЕС Article 26(8), Article 49(3)/(5)
Государственные органы и Union institutions, bodies, offices, agencies — deployers обязаны соблюдать требования регистрации по Article 49 для высокорисковых систем из Annex III, кроме point 2 (критическая инфраструктура — она регистрируется на национальном уровне). Если deployer обнаружил, что высокорисковая система не зарегистрирована в базе данных ЕС, — её нельзя использовать, и нужно проинформировать provider или distributor. Эта обязанность применяется только к государственному сектору. Частных deployers она не касается.
Удалённая биометрическая идентификация в правоохранительных органах Article 26(10)
Это узкий частный случай для правоохранительных органов с целым набором ограничений: предварительное разрешение от судебного или независимого административного органа (или не позднее 48 часов после начала использования), строгая необходимость для расследования конкретного преступления, документирование каждого использования, остановка использования и удаление данных при отказе в разрешении, запрет на принятие неблагоприятного правового решения только на основании результата работы системы, ежегодные отчёты в орган надзора за рынком и национальный орган по защите данных. Если это не ваш сценарий — пропускайте.
Использовать информацию provider для DPIA Article 26(9), Article 13
Где применимо, deployer использует информацию, которую provider предоставил по правилам Article 13, для проведения оценки воздействия на защиту данных (DPIA) по GDPR или Directive (EU) 2016/680. Article 13 задаёт объём инструкций и информации, которые provider обязан предоставить deployer. Отдельной «обязанности предоставить готовый DPIA-пакет» закон на provider не возлагает.
Команда получает от provider минимум документации, упирается в нехватку данных и думает, что это нарушение со стороны provider. Это, скорее всего, не нарушение — это сигнал, что в договоре с provider должен быть пункт об обязательстве предоставить дополнительную информацию по обоснованному запросу для целей DPIA.
Сотрудничество с регулятором
Самая короткая обязанность по тексту закона, но первая, по которой регулятор оценивает зрелость вашей функции по соответствию требованиям.
Сотрудничать с надзорными органами Article 26(12)
Deployer обязан сотрудничать с компетентными надзорными органами в действиях по применению регулирования. На практике это операционная обязанность из трёх элементов: иметь конкретного человека, ответственного за связь с органами надзора за рынком, иметь протокол реагирования на запросы (кто получает, кто согласует ответ, в какой срок отдаём), фиксировать историю запросов и ответов. Если запрос пришёл, а у вас нет ни ответственного, ни процедуры — вы будете импровизировать, а это плохо смотрится со стороны регулятора.
Где осмысленный человеческий контроль ломается
Article 26(2) обязывает назначить человека для человеческого контроля. Я выделил эту обязанность в отдельную секцию, потому что именно на ней регулярно проваливаются команды, которые остальные двенадцать пунктов сделали хорошо. Назначение человека — это самый простой шаг. Сделать его контроль действительно осмысленным — самая сложная.
Article 14 описывает, что provider должен заложить в систему, чтобы человеческий контроль был возможен. Recital 73 явно говорит, что условия должны позволять осмысленный контроль, а не его имитацию. Академические исследования склонности доверять автоматике (automation bias) — Goddard, Roudsari & Wyatt, 2011; Laux & Ruschemeier, 2025 — показывают: «человек в контуре» сам по себе не решает проблему чрезмерного доверия к системе. Назначенный оператор может просто кликать «утвердить» по всем решениям, и формально это будет человеческий контроль.
Чтобы понять, работает ли ваш контроль или это галочка, пройдите по пяти диагностическим вопросам. Если на хотя бы один из них честный ответ «нет» — у вас формальный контроль, и регулятор это заметит при первой же серьёзной проверке.
-
Знает ли назначенный человек ограничения системы
Не «прошёл ли он обучение в начале работы», а понимает ли он, в каких ситуациях система ошибается, какие входные данные приводят к снижению точности, какие частные случаи требуют его вмешательства. Если он не может за минуту назвать три типичных сценария, в которых система склонна ошибаться, — он не понимает её ограничений.
-
Имеет ли он реальные полномочия отменить решение системы
Может ли человек технически переопределить результат работы системы? Может ли он сделать это организационно — не нарушает ли это его собственные KPI, не приведёт ли к санкциям внутри компании? Поощряется ли вмешательство в его команде, или, наоборот, простой системы ставится ему в вину? Если человек технически может отменить решение, но боится последствий — это не контроль.
-
Есть ли у него время и данные для проверки
Если человеку даётся 5 секунд на проверку каждого решения и нет доступа к контексту входных данных — это формальный контроль, не осмысленный. Recital 73 явно требует, чтобы условия позволяли осмысленный контроль. Если у вас на каждое решение системы отведено меньше 30 секунд — посчитайте, сколько вообще решений человек видит за смену. Если это 500 — это конвейер «утвердить», не контроль.
-
Видит ли он предупреждения системы и реагирует на них
Многие provider зашивают в систему индикаторы низкой уверенности или нестандартного входа. Если эти индикаторы где-то логируются, но оператор их не видит на своём интерфейсе, — он не может на них среагировать. Если он их видит, но реагирует одинаково на «уверенный ответ» и «неуверенный ответ» — это сигнал, что обучение не сработало.
-
Документируется ли вмешательство и что с ним происходит дальше
Когда оператор отменяет решение системы — это где-то фиксируется? Эти случаи кто-то анализирует? Используются ли они для обратной связи provider (по правилам Article 72)? Если вмешательства происходят, но никуда не идут — вы теряете самый ценный сигнал о работе системы и о месте её ошибок.
План реагирования на инцидент готовится до инцидента
Article 26(5) требует «без задержки» уведомить provider при обнаружении риска и «немедленно» — при серьёзном инциденте. Article 73 устанавливает сроки для самого provider и применяется как резервный порядок, если provider недоступен. Без заранее подготовленного плана реагирования исполнение этих требований превращается в импровизацию — и обычно не очень удачную, потому что инцидент случается ночью в субботу, и оператору на смене не до того, чтобы по памяти восстанавливать процедуру.
Минимальный рабочий план реагирования — семь пунктов. Этот план должен быть на одной странице.
Триггер
Что считается серьёзным инцидентом по терминам Article 3 и кто принимает решение о переходе в режим инцидента — назначенный по контролю или дежурный руководитель.
Цепочка контактов
Кому звоним первому из provider (имя, контакт, время отклика по договору), кому из надзорных органов. Короткий список с конкретными именами — набрать за 30 секунд.
Шаблон уведомления
Заранее подготовленный текст: что произошло, когда, какие меры приняты, какие данные нужны от provider. Пишется в спокойное время, не в момент инцидента.
Журнал временных меток
Когда обнаружили, уведомили provider, уведомили регулятора, приостановили использование. Каждое действие со временем и инициатором.
Решение о приостановке
Кто и в какой ситуации останавливает использование системы. Один человек с полномочиями нажать «стоп» — без консенсусного согласования.
Корректирующие меры
После острой фазы — что меняем в процессе использования, в обучении операторов, в документации. Записывается и хранится для регулятора.
Переписка с provider
Вся коммуникация с provider по инциденту — в одном месте, со всеми версиями, ответами, договорённостями.
Доказательная база — что собирать для команды и регулятора
Без доказательной базы ваше соответствие требованиям существует только на словах — а регулятор, инвестор и крупный B2B-клиент в ходе проверки поставщика спрашивают про артефакты, а не про намерения.
Доказательная база — это не коробка случайных документов. Это структурированный набор артефактов, привязанных к конкретным обязанностям, который обновляется по мере того, как меняется работа системы. Минимум артефактов на каждую базовую обязанность Article 26 — таблица ниже. Это операционный минимум, на котором строится оценка готовности.
| Обязанность | Что собирать |
|---|---|
| Использование по инструкциям 26(1) |
|
| Человеческий контроль 26(2) |
|
| Входные данные 26(4) |
|
| Мониторинг 26(5) |
|
| Серьёзный инцидент 26(5) / 73 |
|
| Логи 6 мес. 26(6) |
|
| Информирование работников 26(7) |
|
| FRIA / DPIA 27 / 26(9) |
|
| Сотрудничество с надзором 26(12) |
|
Несколько практических замечаний. Артефакты не обязаны быть в одной системе — частично это договоры, частично это операционные процедуры, частично это логи и журналы. Главное — чтобы при запросе вы могли за час собрать всё в одну папку и показать. Если это занимает неделю — у вас не доказательная база, у вас разрозненные документы. И не путайте доказательную базу с DPIA или FRIA — это отдельные регуляторные продукты. Доказательная база — это операционный слой под ними.
FRIA — отдельная история
Оценка воздействия на основные права (FRIA) по Article 27 — отдельная обязанность, которая часто путается с обязанностями по Article 26. На самом деле это два разных регуляторных трека. Article 26 — про повседневную эксплуатацию. Article 27 — про однократную оценку перед запуском системы и её обновление при изменении обстоятельств. И главное — FRIA применяется к гораздо более узкому кругу deployers, чем Article 26.
Кому действительно нужна FRIA
FRIA по Article 27 применяется только если выполняются все четыре условия одновременно. Пропустите хотя бы одно — FRIA вам не нужна.
FRIA gate — все четыре условия
Article 27(1) — все должны быть выполнены- Система из Annex III — высокорисковая по Article 6(2). Системы из Annex I (продукты с гармонизированным законодательством о безопасности) под FRIA не попадают, у них своя процедура оценки соответствия.
- Не из Annex III point 2 — критическая инфраструктура исключена явно в тексте Article 27(1). Для неё — национальный уровень регистрации.
- Вы — публичный орган власти, или частная организация, оказывающая публичные услуги, или deployer Annex III 5(b)/(c) — кредитный скоринг физических лиц или страхование жизни и здоровья. Все остальные deployers под FRIA не попадают.
- Это первое использование системы. FRIA проводится до того, как система начала работать. Обновляется при изменении обстоятельств использования.
Как делается FRIA — Article 27(1) содержит шесть юридических элементов
Закон описывает содержание FRIA через шесть обязательных элементов (Article 27(1)(a)–(f)), которые в подаче ниже сгруппированы в пять рабочих блоков для удобства. Article 27(2) уточняет: FRIA проводится до первого использования системы и обновляется при изменении обстоятельств. Article 27(4) разрешает использовать существующую оценку воздействия на защиту данных (DPIA) по GDPR как часть FRIA, если она покрывает релевантные вопросы.
Описать назначение и контекст
Зафиксировать конкретные процессы deployer'а, в которых используется система, и временной период использования. Не «общее описание системы» — описание именно вашего сценария использования.
Идентифицировать затронутых лиц
Определить категории физических лиц или их групп, которые с большей вероятностью будут затронуты использованием системы. Конкретно — не «пользователи» или «граждане».
Оценить специфические риски вреда
Оценить риски нарушения основных прав для идентифицированных категорий лиц. Привязать к конкретным правам — не «возможный bias», а «риск дискриминации по полу — ст. 21 Хартии».
Описать меры контроля
Зафиксировать меры человеческого контроля, внутреннее управление и механизмы подачи жалоб, которые применяются для снижения выявленных рисков.
Меры при материализации риска
Описать меры, которые будут приняты, если риски материализуются — включая механизмы внутреннего управления и жалоб. Article 27(1)(f) — шестой элемент закона, сгруппированный здесь с пятым для удобства работы.
После FRIA — обязательное уведомление надзорного органа
Здесь в практике регулярно ошибаются: считают, что FRIA — это внутренний документ, который остаётся у команды. Это не так. Article 27(3) обязывает deployer по завершении FRIA уведомить компетентный орган надзора за рынком о результатах оценки и подать заполненный шаблон, который разрабатывает AI Office (Article 27(5)). Из этого правила есть исключения, предусмотренные правом ЕС, но в типичной ситуации уведомление обязательно.
Это превращает FRIA из внутреннего артефакта в часть регуляторного диалога. Если шаблон AI Office к моменту вашего запуска ещё не опубликован — закон не освобождает от уведомления: опирайтесь на структуру из Article 27(1) и подавайте в свободной форме, согласованной с надзорным органом. Заранее проверьте, кто у вас формально отправляет это уведомление, и зафиксируйте это в процедуре.
Что делает FRIA содержательной, а не формальной
Article 27 задаёт минимум, но академические работы (Mantelero, 2024) и публичные методики (нидерландская FRAIA; ISO/IEC 42005:2025) показывают: сильная FRIA выходит за рамки галочек по списку. Эти источники не являются обязательными нормами, но они полезны как методическая опора.
-
Затронутые группы — конкретные
Не «пользователи», а конкретные сегменты: возрастные группы, языковые меньшинства, люди с инвалидностью. Чем точнее группа — тем точнее оценка риска.
-
Реалистичная оценка вероятности и тяжести
Не «возможен теоретический риск», а оценка с обоснованием. Если все риски оценены как «низкий» — это сигнал, что вы не смотрели на систему критически.
-
Меры контроля привязаны к рискам
Каждая мера в плане должна снижать конкретный риск. «Общие меры» без привязки — формальность, не митигация.
-
Есть план пересмотра
Article 27(2) требует обновления при изменении обстоятельств использования. Зафиксируйте, что считается «изменением» и кто отвечает за пересмотр.
-
Можно защитить перед регулятором
Если регулятор спросит «обоснуйте, почему этот риск — низкий», ответ должен быть готов сразу, с источниками. Если потребует трёх дней — слабая FRIA.
Что вы не обязаны делать как deployer и где обычно спотыкаются
В этой секции — две короткие части. Первая — список обязанностей, которые часто ошибочно приписывают deployer, но они на самом деле для provider. Вторая — типичные ошибки команд, которые искренне пытаются всё сделать правильно.
Что не обязан делать deployer
Если вы только deployer, а не одновременно provider.
- 01
Оценка соответствия (conformity assessment)
Это обязанность provider до размещения системы на рынке ЕС — Articles 16, 43. Проверить наличие CE-маркировки и декларации о соответствии — практическая мера осмотрительности, не отдельная обязанность по Article 26.
- 02
Техническая документация по Article 11
Её ведёт и поддерживает provider. Вам как deployer должна быть доступна та часть, которая нужна для безопасного использования (по Article 13), но полную техническую документацию самостоятельно поддерживать вы не обязаны.
- 03
Система управления качеством (QMS) для AI-системы
Это обязанность provider (Article 17). У вас может быть своя система управления качеством для процессов компании — но это другое, не EU AI Act требование к deployer.
- 04
Система пострыночного мониторинга
Формальная процедура пострыночного мониторинга по Article 72 — это обязанность provider. Вы обязаны мониторить свою сторону по Article 26(5) и информировать provider — но саму систему мониторинга строит он.
- 05
Регистрация в базе данных ЕС (для частных deployers)
Общая обязанность регистрации лежит на provider. Государственные органы имеют отдельную обязанность по Article 26(8) — но для частных deployers общей обязанности регистрации нет.
Где обычно спотыкаются
Пять самых частых ошибок, которые встречаются почти в каждом первичном аудите готовности к Article 26.
- 01
Применять Article 26 ко всем AI-проектам
Статья применяется только при двух условиях одновременно: роль = deployer и AI-система действительно высокорисковая. Если хотя бы одно не выполнено — большинство из 13 пунктов вас не касается.
- 02
Путать роль provider и deployer на разных системах
По одной системе вы deployer, по другой — provider. У одной команды могут быть обе роли одновременно. Не относите «свою компанию» к одной роли по умолчанию.
- 03
Считать, что Annex III = автоматически высокорисковая
Article 6(3) допускает исключение. Но снять статус может только provider — через документирование и регистрацию по Article 6(4). Запрашивайте подтверждение.
- 04
Делать человеческий контроль формальным
Назначить человека легко. Без логов вмешательств, без реальных полномочий, без времени на проверку — это не контроль, а имитация. Recital 73 явно требует условий для осмысленного контроля.
- 05
Думать, что FRIA нужна всем deployers высокорисковых систем
Реальный охват — публичные органы, частные организации с публичными услугами и deployers Annex III 5(b)/5(c). Для большинства частных deployers высокорисковых систем FRIA по Article 27 не применяется.
Что делать дальше
Если после прочтения вы понимаете, что Article 26 действительно к вам применяется и нужен системный план — следующий шаг обычно один. Не «выпустить регуляторный документ для галочки». Не «прочитать ещё одну статью». А провести рабочую сессию с командой, в которой каждая из 13 обязанностей привязывается к конкретному процессу, конкретному ответственному и конкретной дате внедрения. Без этой привязки чек-лист останется чек-листом, а не рабочей системой.
EU AI Act Readiness Assessment
За пять рабочих дней — позиционный документ по вашему продукту: применимость EU AI Act, ваша роль (provider / deployer / комбинация), классификация по риску, доказательная база, выявленные пробелы и приоритизированный план следующих шагов. Это не аудит на сто страниц — это совместный разбор на двух консультационных сессиях плюс документ, который можно показать клиенту, инвестору или совету директоров.