Ответственность за решения ИИ-модели

Российское регулирование персональных данных не содержит отдельного закона об ИИ, но это не означает правовой пустоты. ФЗ-152, ст. 13.11 КоАП в редакции ФЗ-420 от 30.11.2024 и ст. 272.1 УК (ФЗ-421, действует с 11.12.2024) в совокупности покрывают весь жизненный цикл ИИ-модели: сбор данных, разметку, обучение, инференс и логирование результатов. Ниже — разбор норм, практических сценариев и технических требований, которые CTO должен учитывать при проектировании ML-инфраструктуры.

Кто несёт ответственность, когда ИИ-модель обрабатывает персональные данные?

Ст. 3 ФЗ-152 определяет оператора как лицо, которое организует и (или) осуществляет обработку ПДн, а также определяет её цели и состав. Это определение не содержит исключения для автоматизированных систем. Если компания развернула ИИ-модель, которая обрабатывает ПДн клиентов — скоринг, рекомендации, распознавание лиц в СКУД, анализ медицинских снимков, — она остаётся оператором со всеми вытекающими обязанностями.

Ст. 16 ФЗ-152 прямо регулирует автоматизированные решения, принятые без участия человека. Оператор обязан уведомить субъекта о факте принятия такого решения, разъяснить его последствия и по запросу субъекта обеспечить рассмотрение вопроса о пересмотре решения. Неисполнение этой обязанности создаёт основание для штрафа по ч. 4 ст. 13.11 КоАП — 40–80 тыс. ₽ для юрлица.

Подрядчик, разрабатывающий или эксплуатирующий модель по заданию заказчика, действует в статусе лица, осуществляющего обработку по поручению (п. 3 ст. 6 ФЗ-152). Поручение должно быть оформлено письменно с перечнем допустимых действий, требованиями по защите и обязательством не передавать данные третьим лицам. Отсутствие договора поручения при передаче обучающей выборки подрядчику — прямое нарушение ст. 6 ФЗ-152 и основание для штрафа по ч. 1 ст. 13.11 (150–300 тыс. ₽).

Какие технические требования применяются к ИСПДн с ИИ-компонентами?

ПП РФ №1119 от 01.11.2012 устанавливает четыре уровня защищённости (УЗ-1...УЗ-4) в зависимости от категории данных, типа угроз и числа субъектов. Для ИИ-систем это означает следующее:

• УЗ-1 и УЗ-2 — как правило, для медицинских или биометрических данных с угрозами 1-го или 2-го типа. Требуют сертифицированных ФСТЭК средств защиты и более строгого контроля доступа.
• УЗ-3 — наиболее распространён для SaaS-продуктов с клиентскими ПДн при числе субъектов до 100 000 и угрозах 3-го типа.
• УЗ-4 — минимальный, для общедоступных ПДн или обезличенных данных при отсутствии угроз первых двух типов.

Приказ ФСТЭК №21 от 18.02.2013 определяет состав мер защиты по уровням. Для ИИ-инфраструктуры особого внимания требуют группы РСБ (регистрация событий безопасности) и АНЗ (анализ защищённости). Каждый вывод модели, затрагивающий ПДн, должен фиксироваться в журнале — с идентификатором запроса, меткой времени и результатом. Логи без указания субъекта также могут квалифицироваться как обработка ПДн, если по ним возможна идентификация личности.

Как обезличивание данных защищает ИИ-компанию от штрафов?

Обезличенные данные не признаются персональными по ст. 3 ФЗ-152 при условии, что обратная идентификация невозможна без дополнительной информации, находящейся под контролем оператора. Это ключевое условие для обучения ML-моделей: если обучающая выборка обезличена корректно, требования ФЗ-152 к её хранению и передаче существенно снижаются.

С 2025 года действуют требования ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) и подзаконный акт РКН, определяющий пять методов обезличивания: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Применение метода, не входящего в утверждённый перечень, не даёт защиты: данные будут квалифицированы как персональные, и обучение модели на них — как обработка ПДн без надлежащего правового основания.

Практическая проблема: большинство ML-команд используют псевдонимизацию (замену имени на идентификатор), которая не признаётся обезличиванием — идентификатор можно сопоставить с исходными данными через словарь. Для защиты от ч. 1 ст. 13.11 необходимо применять методы, при которых оператор технически не может восстановить связь с конкретным субъектом.

Облачная инфраструктура и SaaS: где проходит граница локализации?

Ч. 5 ст. 18 ФЗ-152 обязывает операторов обеспечивать первичную запись, систематизацию, накопление, хранение, уточнение и извлечение ПДн российских граждан в базах данных, расположенных в Российской Федерации. Это требование применяется к обучающим выборкам ML-моделей напрямую: если данные о российских пользователях собираются и хранятся для обучения в AWS, GCP или Azure за пределами РФ — это нарушение.

Штраф по ч. 8 ст. 13.11 КоАП — 1–6 млн ₽ за первичное нарушение. При повторности (ч. 9) — 6–18 млн ₽. С введением ФЗ-233 от 08.08.2024, вступившего в силу с 01.07.2025, требования к локализации стали жёстче: расширен перечень действий, при которых база данных должна находиться в РФ.

В мультиарендной SaaS (multi-tenant) вопрос усложняется. Если SaaS-платформа обрабатывает ПДн нескольких клиентов в одной инфраструктуре, каждый клиент является оператором в отношении своих субъектов, а платформа — лицом, осуществляющим обработку по поручению каждого из них. При этом SaaS-вендор также может быть признан самостоятельным оператором в части данных, которые он собирает о пользователях платформы (логи авторизации, метаданные сессий). Смешение этих ролей без разграничения в договоре и уведомлении РКН создаёт риск по ч. 1 ст. 13.11.

Уголовная ответственность CTO: что изменилось с 11 декабря 2024 года?

Ст. 272.1 УК РФ, введённая ФЗ-421 от 30.11.2024, криминализировала незаконное использование, передачу, сбор и хранение компьютерной информации, содержащей ПДн. Статья действует с 11.12.2024. Для CTO это означает персональный уголовный риск при следующих сценариях:

• Обучение модели на ПДн, переданных без надлежащего поручения обработки или согласия субъектов, — возможная квалификация как незаконный сбор.
• Экспорт обучающей выборки за рубеж без уведомления РКН о трансграничной передаче (ст. 12 ФЗ-152) — квалификация по ч. 4 ст. 272.1 (трансграничная передача незаконно полученных ПДн, до 8 лет лишения свободы).
• Утечка модели, в которой ПДн «зашиты» в веса (memorization), — возможная квалификация как хранение и последующая утечка ПДн.

Максимальная санкция по ч. 5 ст. 272.1 (тяжкие последствия) — лишение свободы до 10 лет. Состав охватывает не только внешних злоумышленников, но и должностных лиц компании, давших указание на незаконную обработку.

Практические сценарии: как это выглядит в реальности

Сценарий 1. Рекомендательная система на клиентских ПДн (Центральный ФО, осень 2025). Технический директор e-commerce платформы передал датасет с историями покупок (650 000 субъектов) ML-подрядчику для обучения рекомендательной модели. Договор поручения подписан не был; в уведомлении РКН ML-подрядчик не фигурировал. Роскомнадзор при плановой проверке выявил передачу. Компании предъявили протокол по ч. 1 ст. 13.11 (обработка без надлежащего основания) с штрафом в диапазоне 150–300 тыс. ₽. Подрядчик также получил самостоятельный протокол как лицо, осуществлявшее обработку без поручения. Ситуацию осложнило то, что датасет хранился на серверах AWS. Стратегия: при первом взаимодействии с подрядчиком оформить договор поручения по п. 3 ст. 6 ФЗ-152 и обновить уведомление в реестре РКН по ст. 22.

Сценарий 2. Кредитный скоринг на модели с биометрическим компонентом (Сибирский ФО, начало 2026). Финтех-компания интегрировала верификацию по фотографии (проверка лица по базе) в кредитный скоринг. Технический директор не разграничил: биометрическая верификация — это ст. 11 ФЗ-152 (письменное согласие) плюс требования УЗ-2 по ПП РФ №1119. Система была развёрнута по УЗ-4. РКН зафиксировал нарушение после жалобы субъекта, отказавшегося давать согласие на биометрию. Протокол — по ч. 16 ст. 13.11 (обработка биометрии с нарушением ст. 11 ФЗ-152). Стратегия: для любого компонента с биометрией — отдельный анализ УЗ, отдельное письменное согласие и пересмотр архитектуры ИСПДн до запуска в продакшн.

Сценарий 3. Утечка обучающей выборки через уязвимость MLflow (Северо-Западный ФО, лето 2025). В открытый доступ попал сервер MLflow с экспериментами, включавшими датасет из 12 000 субъектов (имена, email, поведенческие метрики). CISO зафиксировал утечку через 6 часов; уведомление РКН направлено за 20 часов — в рамках 24-часового срока по ч. 3.1 ст. 21 ФЗ-152. Через 72 часа подан отчёт по Приказу РКН №187. Штраф по ч. 12 ст. 13.11 (1 000–10 000 субъектов, 3–5 млн ₽) был снижен судом с учётом оперативности уведомления. Стратегия: MLflow, Weights & Biases и аналогичные инструменты трекинга экспериментов не должны быть публично доступны; доступ — только через VPN с аутентификацией.

Услуги DATUM по теме

• DPIA (оценка воздействия) — идентификация рисков ИИ-обработки и состав мер по требованиям РКН.
• Аудит соответствия 152-ФЗ — проверка ML-инфраструктуры по чек-листу из 38 пунктов, включая УЗ и договоры поручения.
• Комплект ОРД под ключ — договоры поручения, согласия, модель угроз, политика обработки ПДн для ИИ-продукта.

Частые вопросы

1. Какой УЗ выбрать для SaaS?

Уровень защищённости определяется по ПП РФ №1119 на пересечении трёх факторов: категория ПДн (специальные, биометрические, общедоступные или иные), тип актуальных угроз (1–3) и число субъектов (до 100 000 или свыше). Для большинства SaaS с клиентскими данными (имя, email, история покупок) при угрозах 3-го типа и числе субъектов до 100 000 применяется УЗ-3. Если система обрабатывает медицинские или биометрические данные либо если в составе ПО используются компоненты с незакрытыми НДВ — уровень повышается до УЗ-2 или УЗ-1. Определить тип угрозы помогает модель угроз, разработанная по методике ФСТЭК.

2. Можно ли использовать иностранные облака?

Иностранные облака (AWS, GCP, Azure) допустимы для хранения обезличенных данных и для сервисов, не связанных с первичным сбором ПДн российских граждан. Первичная запись, накопление и хранение ПДн граждан РФ по ч. 5 ст. 18 ФЗ-152 должны осуществляться в базах данных на территории России. Использование иностранного облака как основного места хранения обучающей выборки с ПДн российских пользователей — нарушение, штраф по ч. 8 ст. 13.11 КоАП составляет 1–6 млн ₽. Трансграничная передача данных в страну без адекватной защиты требует предварительного уведомления РКН по ст. 12 ФЗ-152.

3. Что такое обезличивание для ML?

Обезличивание — это приведение данных к форме, при которой определение их принадлежности конкретному субъекту без дополнительной информации становится невозможным (ст. 3 ФЗ-152). Для ML-задач применяются методы из подзаконного акта РКН: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение. Псевдонимизация (замена имени на ID) обезличиванием не признаётся, так как обратная идентификация возможна через словарь соответствия. Корректно обезличенные данные выводятся из-под действия большинства требований ФЗ-152 и снимают обязательство по уведомлению РКН об их обработке.

4. Кто оператор в мультиарендной SaaS?

В мультиарендной SaaS оператором ПДн конечных пользователей является клиент платформы (арендатор), который определяет цели обработки. SaaS-вендор действует как лицо, осуществляющее обработку по поручению (п. 3 ст. 6 ФЗ-152), и обязан заключить с каждым арендатором письменный договор поручения. Одновременно SaaS-вендор является самостоятельным оператором в отношении данных, которые собирает о пользователях платформы в своих целях (телеметрия, логи аутентификации, маркетинговые рассылки). Смешение ролей без договорного разграничения создаёт риск по ч. 1 ст. 13.11 КоАП.

5. Какие СЗИ обязательны?

Конкретный состав средств защиты информации определяется Приказом ФСТЭК №21 в зависимости от актуального УЗ. Для УЗ-3 обязательны меры групп ИАФ (идентификация и аутентификация), УПД (управление доступом), РСБ (регистрация событий), АВЗ (антивирус) и ЗИС (защита информационных систем). При УЗ-2 и выше добавляются требования к сертификации СЗИ по уровням доверия ФСТЭК. Применение несертифицированных средств при обязательной сертификации — нарушение, выявляемое в ходе проверки РКН.

Итог

Ответственность за решения ИИ-модели — это ответственность оператора ПДн, независимо от степени автоматизации. Ключевые точки риска для CTO: отсутствие договора поручения с ML-подрядчиком, неверно определённый УЗ, псевдонимизация вместо обезличивания и хранение обучающих выборок в иностранном облаке. С 30.05.2025 каждая из этих ошибок имеет конкретную цену в рублях по ст. 13.11 КоАП, а с 11.12.2024 — и уголовный риск по ст. 272.1 УК.

Практика DATUM охватывает полный цикл сопровождения ИИ-проектов: от определения УЗ и составления договора поручения до подготовки к проверке РКН и защиты в арбитраже при предъявлении протокола. Юристы практики сопровождают IT-компании с ML-продуктами в контексте соблюдения требований ФЗ-152 и ст. 13.11 КоАП.