Аудит ИИ-системы на этичность

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

Какие нормы регулируют обработку ПДн в ИИ-системах?

ФЗ-152 не содержит отдельной статьи об ИИ. Нормы применяются те же, что для любой информационной системы персональных данных (ИСПДн). Ключевые обязательства формируют несколько уровней.

Первый уровень — принципы обработки. Ст. 5 ФЗ-152 требует, чтобы цели обработки были конкретными и заранее определёнными. Обучение модели на данных, собранных для другой цели (например, для ведения договора), нарушает п. 2 ст. 5. Объём данных должен соответствовать цели: если для классификатора достаточно агрегированных признаков — обрабатывать полные профили нельзя.

Второй уровень — правовое основание. Ст. 6 ФЗ-152 перечисляет 11 оснований обработки. Согласие субъекта (п. 1) используется чаще всего, но требует отдельного документа с 01.09.2025 по ФЗ-156: нельзя «зашить» согласие в условия использования сервиса. Если ИИ-система принимает автоматизированные решения, влияющие на права субъектов, действует ст. 16 ФЗ-152: субъект вправе потребовать пересмотра решения с участием человека.

Третий уровень — уголовная ответственность по ст. 272.1 УК РФ (в силе с 11.12.2024). Незаконный сбор или использование компьютерной информации с ПДн для обучения ИИ-модели подпадает под ч. 1–2 статьи. Если утечка обученной модели или эмбеддингов повлекла тяжкие последствия — ч. 5 предусматривает до 10 лет лишения свободы. Ответственность персональная: под действие статьи могут попасть конкретные инженеры и руководитель разработки.

Как выбрать уровень защищённости УЗ для ИИ-системы?

ПП РФ №1119 устанавливает четыре уровня защищённости ИСПДн (УЗ-1 — наивысший, УЗ-4 — базовый). Уровень определяется тремя параметрами: категория ПДн, тип угроз (1–3) и количество субъектов относительно порога 100 000.

Для большинства коммерческих ИИ-систем базовая конфигурация выглядит так.

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

Ошибка выбора уровня — одна из наиболее частых в ИИ-проектах. Команда нередко занижает тип угроз, считая, что «внутренняя система» защищена от внешних атак. Между тем ПП №1119 под угрозами 2-го типа понимает наличие недекларированных возможностей в системном ПО, а не только внешнего злоумышленника. Если ИИ-система работает на стороннем облачном сервисе — тип угроз автоматически повышается.

Что проверяет Приказ ФСТЭК №21 применительно к ML-инфраструктуре?

Приказ ФСТЭК №21 содержит 109 мер защиты в 15 группах. Для ИИ-системы критичны пять из них.

• ИАФ (идентификация и аутентификация) — контроль доступа к обучающей выборке, модели и API. Каждый запрос к инференс-серверу должен идентифицировать пользователя или сервис.
• РСБ (регистрация событий безопасности) — логирование всех обращений к ПДн, включая запросы через модель. Если ответ модели содержит фрагменты ПДн из обучающей выборки — это обращение к ПДн по смыслу ФЗ-152 и должно фиксироваться.
• ОПС (ограничение программной среды) — только авторизованное ПО в цепочке обучения. Open-source-библиотеки с известными уязвимостями создают риск не только ИБ, но и нарушения требований ФСТЭК.
• ЗИС (защита информационной системы) — сегментация сети, изоляция ML-кластера от общедоступных сервисов.
• АНЗ (анализ защищённости) — периодическое тестирование на наличие атак типа membership inference, model inversion и data poisoning. Эти атаки специфичны для ML, и регулятор уже задаёт вопросы по ним в ходе проверок.

Отдельный вопрос — логирование как ПДн. Если журналы событий содержат идентификаторы пользователей, IP-адреса или тексты запросов с упоминанием персон — сами журналы становятся ИСПДн. Хранить их нужно с теми же мерами защиты, что и основную базу.

Как обезличивание данных влияет на риски при обучении ML-модели?

Обезличенные ПДн по ст. 13.1 ФЗ-152 (введена ФЗ-233 от 08.08.2024) выведены из-под основного регуляторного режима: на них не распространяются требования о согласии и уведомлении РКН. Это создаёт стимул для обезличивания обучающей выборки до передачи в ML-пайплайн.

Приказ РКН о методах обезличивания (2025) закрепил 5 методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Для ML-задач наиболее применимы обобщение (замена точных значений диапазонами) и введение идентификаторов (замена ФИО и контактов псевдонимами с сохранением аналитической ценности).

Критическая точка — реидентификация. Если модель обучена на псевдонимизированных данных, но по её выводу можно восстановить личность субъекта (атака model inversion или membership inference), такие данные не считаются обезличенными по смыслу ФЗ-152. Регулятор оценивает именно практическую возможность реидентификации, а не формальное применение метода.

На практике это означает: обезличивание должно быть задокументировано (метод, параметры, дата), проверено на устойчивость к реидентификации и отражено в политике обработки ПДн. Документация — часть пакета ОРД, который проверяет РКН.

Кто несёт ответственность: оператор, SaaS-провайдер или разработчик модели?

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

Типовая схема для SaaS: клиент (арендатор) — оператор своих пользователей, SaaS-провайдер — обработчик по поручению. Это требует письменного договора поручения с обязательными условиями: перечень ПДн, цели, перечень действий, обязанность обеспечить конфиденциальность и технические меры. Если договора нет или он не содержит обязательных условий — провайдер автоматически становится самостоятельным оператором со всеми вытекающими обязательствами.

Для разработчика модели дополнительный риск возникает при использовании данных арендаторов для дообучения общей модели. Такое действие без явного согласия каждого арендатора и его пользователей нарушает принцип целевого использования (ст. 5 ФЗ-152) и условия поручения.

Отдельно стоит тема КИИ. Если ИИ-система обрабатывает данные объекта критической информационной инфраструктуры (187-ФЗ), требования по защите накладываются поверх 152-ФЗ и Приказа ФСТЭК №21. Совмещение двух режимов существенно увеличивает объём технической документации.

Типовые сценарии нарушений при аудите ИИ-систем

Сценарий 1. Модель обучена на продакшн-данных без согласия. Команда скопировала боевую базу ПДн в ML-среду для экспериментов. Основание — «внутренние нужды». Цель, указанная в уведомлении РКН, — «исполнение договора». Обработка для обучения модели в уведомлении не указана. При проверке РКН это квалифицируется по ч. 1 ст. 13.11 КоАП: обработка, не соответствующая заявленным целям. Штраф — 150–300 тыс. ₽. Параллельно возможна проверка по ст. 272.1 УК, если данные получены с нарушением условий поручения. Стратегия: зафиксировать цель «разработка и улучшение ML-моделей» в уведомлении, получить отдельные согласия или применить обезличивание до начала экспериментов.

Сценарий 2. Облако в иностранной юрисдикции, первичный сбор за рубежом. SaaS работает на AWS EU или GCP US. С 01.07.2025 (ФЗ-233) запрещена не только хранение, но и первичная запись, систематизация и накопление ПДн граждан РФ в базах за рубежом (ч. 5 ст. 18 ФЗ-152). Штраф за нарушение локализации — 1–6 млн ₽ по ч. 8 ст. 13.11, при повторности — 6–18 млн ₽ по ч. 9. Стратегия: перевод primary storage в российский облачный регион (Яндекс.Облако, SberCloud, CloudMTS), зарубежный ЦОД — только для реплики без ПДн граждан РФ.

Сценарий 3. Утечка эмбеддингов из векторной базы данных. Векторная база (Pinecone, Weaviate self-hosted) содержит эмбеддинги, полученные из ПДн. Технически — это ПДн, если по ним возможна реидентификация. Утечка более 10 000 записей при отсутствии мер защиты квалифицируется по ч. 13 ст. 13.11 КоАП (штраф 5–10 млн ₽). Первичное уведомление РКН — 24 часа (ч. 3.1 ст. 21 ФЗ-152), отчёт — 72 часа (Приказ РКН №187). Стратегия: оценить устойчивость эмбеддингов к реидентификации до продакшна, применить дифференциальную приватность, включить векторную базу в перечень ИСПДн.

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

Кейс 1. IT-компания из Северо-Западного федерального округа (осень 2025) использовала продакшн-базу пользователей e-commerce-платформы для обучения рекомендательной модели. Договор поручения с ML-подрядчиком отсутствовал. РКН в ходе плановой проверки установил нарушение ст. 6 п. 3 и ст. 5 ФЗ-152. Составлен протокол по ч. 1 ст. 13.11. До вынесения постановления компания подписала договор поручения, провела обезличивание и подала уточнённое уведомление в реестр. Суд назначил штраф в размере ниже среднего диапазона, применив смягчающие обстоятельства по ст. 4.2 КоАП.

Кейс 2. Технический директор SaaS-платформы (Центральный ФО, начало 2026) обратился в DATUM после получения запроса РКН о разграничении ролей оператора и обработчика в мультиарендной архитектуре. Аудит выявил: 11 арендаторов без договоров поручения, хранение логов с ПДн в иностранном облаке, отсутствие модели угроз. По итогам аудита оформлены типовые договоры поручения, логи перенесены в российский ЦОД, определён УЗ-3. РКН получил полный ответ в установленный срок; проверка завершена без штрафов.

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

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

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

1. Какой УЗ выбрать для SaaS с данными пользователей?

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

2. Можно ли использовать иностранные облака для ML-инфраструктуры?

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

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

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

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

По умолчанию — каждый арендатор (клиент SaaS) является оператором своих пользователей и несёт ответственность за правовое основание обработки. SaaS-провайдер — обработчик по поручению по п. 3 ст. 6 ФЗ-152. Это разграничение работает только при наличии письменного договора поручения с обязательными условиями. Без договора провайдер автоматически признаётся самостоятельным оператором с полным набором обязательств по 152-ФЗ и рисками по ст. 13.11 КоАП.

5. Какие СЗИ обязательны для ИИ-системы с ПДн?

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

Итог

Аудит ИИ-системы на этичность в правовом смысле — это проверка соответствия 152-ФЗ, ПП РФ №1119, Приказу ФСТЭК №21 и новым нормам об обезличивании и локализации. Правильно определённый УЗ, договор поручения с каждым облачным провайдером и задокументированное обезличивание обучающей выборки закрывают большинство рисков до первой проверки РКН. Игнорирование этих требований с 30.05.2025 создаёт оборотные риски до 500 млн ₽ и персональную уголовную ответственность по ст. 272.1 УК.

DATUM сопровождает IT-компании и SaaS-платформы по всему циклу: от определения УЗ и разработки модели угроз до оформления договоров поручения и подготовки к проверкам РКН. Практика охватывает ML-инфраструктуру, мультиарендные архитектуры и системы КИИ.