Правовая база ИИ: ЭКГ, КГ, кодексы

Российское регулирование искусственного интеллекта в 2025–2026 годах формируется на трёх платформах: Федеральный закон об экспериментальных правовых режимах (ЭПР), Кодекс этики в сфере ИИ (КЭ) и отраслевые кодексы управления данными (КГ — кодексы поведения). Ни одна из этих платформ не снимает с CTO обязательств по 152-ФЗ. Напротив, они их уточняют. В этом материале — анализ того, как каждый из трёх регуляторных инструментов влияет на техническую архитектуру ИСПДн, выбор уровня защищённости и порядок обезличивания данных для ML-систем.

Что такое ЭПР для ИИ и какие обязательства он создаёт для CTO?

Экспериментальный правовой режим в сфере ИИ — это механизм, при котором участник проекта получает право временно отступить от отдельных требований отраслевого законодательства, но не от требований 152-ФЗ. Это ключевое разграничение, которое часто игнорируют в технических командах.

ЭПР действует в Москве с 2020 года (ФЗ-258 «Об экспериментальных правовых режимах в сфере цифровых инноваций в Российской Федерации»). Участники ЭПР могут тестировать алгоритмы в медицине, транспорте, образовании. Однако программа ЭПР обязывает участника разработать порядок обработки персональных данных, совместимый с 152-ФЗ, как условие входа в режим. Роскомнадзор включён в межведомственное согласование каждой программы ЭПР.

Для CTO это означает: ЭПР не освобождает от выбора уровня защищённости ИСПДн. Если ML-система обрабатывает медицинские данные пациентов (специальная категория по ст. 10 ФЗ-152) в рамках ЭПР — УЗ определяется по ПП РФ №1119, а состав технических мер — по Приказу ФСТЭК №21. Исключений для «экспериментальных» систем нет.

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

Как Кодекс этики ИИ и кодексы управления данными соотносятся с 152-ФЗ?

Кодекс этики в сфере ИИ (принят в 2021 году при координации РСПП и АНО «Цифровая экономика») — добровольный инструмент. Подписанты принимают на себя обязательства по прозрачности алгоритмов, недискриминации и объяснимости решений. Юридически обязательной силы кодекс не имеет, но его несоблюдение в сочетании с жалобой субъекта создаёт репутационный риск и может стать основанием для внеплановой проверки РКН.

Кодексы поведения (КГ) в отдельных отраслях — медицине, финансах, транспорте — носят иной характер. В ряде случаев они разработаны при участии отраслевых регуляторов (ЦБ РФ, Минздрав) и фактически имплементируют нормы секторального законодательства. Для CTO в медтехе или финтехе КГ означает дополнительный слой требований поверх 152-ФЗ: особые требования к согласию на автоматизированное принятие решений (ст. 16 ФЗ-152), обязательный аудит алгоритмов, журналирование решений модели.

Статья 16 ФЗ-152 прямо запрещает принимать решения, порождающие юридические последствия для субъекта, исключительно на основании автоматизированной обработки его ПДн без согласия субъекта. Это норма, которую большинство ML-команд не реализуют технически: нет механизма отзыва согласия на автоматизированное решение, нет журнала решений, нет процедуры оспаривания.

С точки зрения SaaS-архитектуры это требует: отдельного поля согласия на автоматизированное решение (не совмещать с пользовательским соглашением — ФЗ-156 от 24.06.2025 запрещает объединять согласие с иными документами с 01.09.2025), механизма отзыва, хранения истории решений с привязкой к идентификатору субъекта.

Какие требования ФСТЭК и ПП РФ №1119 применяются к ML-системам?

Приказ ФСТЭК №21 от 18.02.2013 содержит 109 мер в 15 функциональных группах. Базовый набор мер определяется уровнем защищённости по ПП РФ №1119. Для ML-систем критичны три группы.

Первая — управление доступом (УПД). ML-пайплайн часто строится на принципе минимума прав: инженер данных имеет доступ к обезличенному датасету, но не к исходным ПДн. Приказ №21 требует реализовать ролевую модель, журналировать каждое обращение к ПДн и исключить избыточный доступ. Типовая ошибка: data-scientist с доступом к production-базе ПДн для дебаггинга модели.

Вторая — регистрация событий (РСБ). Журналирование доступа к ПДн — не только требование Приказа №21, но и доказательная база при инциденте. Если журналы хранятся менее 3 лет или не охватывают все операции с ПДн в ML-пайплайне (извлечение, трансформация, загрузка в обучающую выборку) — при проверке это трактуется как отсутствие организационной меры защиты.

Третья — защита носителей информации (ЗНИ). Обучающие датасеты на локальных машинах инженеров без шифрования — прямое нарушение ЗНИ для УЗ-3 и выше. Это распространённая ситуация в командах, которые переносят датасеты на ноутбуки для работы вне офиса.

Мультиарендная SaaS и поручение обработки: где граница ответственности?

В мультиарендной SaaS-архитектуре роли оператора и лица, осуществляющего обработку по поручению, распределены нетривиально. Ст. 3 ФЗ-152 определяет оператора как лицо, которое самостоятельно или совместно с другими определяет цели и способы обработки. В типовой B2B SaaS-модели: клиент (арендатор) — оператор, SaaS-вендор — обработчик по поручению.

Однако если SaaS-вендор использует агрегированные данные всех арендаторов для обучения shared ML-модели — он становится самостоятельным оператором в отношении этой обработки. Это меняет всё: требуется собственное уведомление в реестре РКН по ст. 22 ФЗ-152, отдельное правовое основание по ст. 6, отдельное согласие субъектов (или иное основание) на такую обработку.

Договор поручения обработки по ч. 3 ст. 6 ФЗ-152 должен содержать: перечень действий с ПДн, цели обработки, обязанность обеспечить конфиденциальность, требования к защите, перечень категорий ПДн. Если в договоре с cloud-провайдером или ML-платформой этих условий нет — оператор несёт ответственность за действия подрядчика как за собственные (принцип ВС РФ по ответственности оператора за подрядчика). Штраф по ч. 1 ст. 13.11 КоАП — до 300 000 ₽ при первичном нарушении, до 500 000 ₽ при повторном.

Как работает обезличивание ПДн для ML и когда оно недостаточно?

Приказ РКН об обязательных методах обезличивания (действует с 01.09.2025) установил пять методов. Каждый применяется в зависимости от задачи. Для ML-систем наиболее релевантны обобщение (замена точных значений диапазонами — возраст «32» → «30–35») и декомпозиция (разделение датасета так, чтобы ни одна его часть не позволяла идентифицировать субъекта). Введение псевдонимов (замена прямых идентификаторов суррогатными ключами) — метод псевдонимизации, который РКН формально не признаёт полноценным обезличиванием без дополнительных мер.

Критерий достаточности обезличивания по позиции РКН: данные признаются обезличенными, если идентификация субъекта невозможна без привлечения дополнительной информации, которой оператор не располагает. Для ML это означает: если модель можно атаковать методом membership inference attack и с вероятностью выше случайного угадать, входил ли конкретный субъект в обучающую выборку, — обезличивание недостаточно.

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

Как это применяется на практике

Кейс 1. IT-компания (Сибирский ФО, осень 2025) разрабатывала медицинскую ML-платформу в рамках ЭПР. Технический директор исходил из того, что статус участника ЭПР снижает требования к защите. При аудите выяснилось: ИСПДн обрабатывает специальные категории ПДн более 100 000 пациентов при угрозах 2-го типа — это УЗ-1, а не УЗ-3, как было задокументировано. Отсутствовали сертифицированные СКЗИ класса КС2, не велись журналы по группе РСБ Приказа №21. DATUM провёл аудит, подготовил пересмотренную модель угроз, организовал замену СЗИ до плановой проверки РКН. Штраф по ч. 1 ст. 13.11 предотвращён.

Кейс 2. SaaS-вендор (Центральный ФО, начало 2026) предоставлял B2B-платформу для HR-автоматизации. ML-модуль ранжирования кандидатов обучался на агрегированных данных всех клиентов. Договоры с арендаторами определяли вендора исключительно как обработчика. При юридическом анализе установлено: вендор самостоятельно определял цели и способы обработки агрегированного датасета — статус оператора. Отсутствовало уведомление РКН по ст. 22, не было правового основания по ст. 6, ст. 16 ФЗ-152 нарушена (автоматизированные кадровые решения без согласия субъектов). DATUM подготовил пакет ОРД, отдельные согласия субъектов, направил уведомление в РКН. Штраф по ч. 10 ст. 13.11 (100–300 тыс. ₽ за неуведомление) был предотвращён до возбуждения дела.

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

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

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

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

Уровень защищённости определяется по ПП РФ №1119 и зависит от трёх параметров: категория обрабатываемых ПДн (общие, специальные, биометрические), тип актуальных угроз (1, 2 или 3) и число субъектов (порог 100 000). Для типового B2B SaaS с общими ПДн сотрудников клиентов при угрозах 3-го типа и числе субъектов менее 100 000 — это УЗ-4 (минимальный базовый набор мер). Если среди клиентов есть медицинские или финансовые организации и SaaS обрабатывает их специальные категории — УЗ повышается до 3 или 2. Определить корректный УЗ без модели угроз невозможно: начните с неё.

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

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

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

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

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

В B2B SaaS клиент (арендатор) является оператором ПДн своих пользователей, а вендор — обработчиком по поручению согласно ч. 3 ст. 6 ФЗ-152. Однако если вендор использует агрегированные данные нескольких арендаторов для обучения shared-модели или иных собственных целей, он самостоятельно определяет цели и способы обработки — и в этой части становится оператором. Это требует отдельного уведомления РКН по ст. 22 ФЗ-152, собственного правового основания по ст. 6 и раскрытия субъектам. Граница определяется контролем над целями обработки агрегированного датасета.

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

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

Итог

Правовая база ИИ в России не создаёт отдельного регуляторного пространства поверх 152-ФЗ — она уточняет и усложняет его применение. ЭПР не освобождает от УЗ и ФСТЭК. Кодексы этики не заменяют ст. 16 ФЗ-152 по автоматизированным решениям. Обезличивание для ML требует применения методов, утверждённых РКН, а не технической псевдонимизации. Для CTO это означает три документа, которых, как правило, нет: корректная модель угроз с правильным УЗ, договор поручения с каждым cloud- и ML-сервисом, порядок обезличивания, совместимый с Приказом РКН.

DATUM сопровождает IT-компании и SaaS-вендоров по всему спектру вопросов 152-ФЗ: от выбора уровня защищённости и подготовки пакета ОРД до представления интересов при проверке РКН и проведения DPIA для высокорисковых ML-систем.

14 января 2029 года