Ст. 16 152-ФЗ: автоматизированные решения

Ст. 16 ФЗ-152 — одна из наименее проработанных в практике, но наиболее актуальных для IT-команд. Любой ML-скоринг, автоматический отказ в кредите, HR-ранжирование соискателей или персонализированный прайсинг попадает под её действие. С 30.05.2025 ст. 13.11 КоАП содержит 18 частей с оборотными составами до 500 млн ₽, и регуляторный риск стал финансовым. Эта статья разбирает: когда применяется ст. 16 ФЗ-152, как строить архитектуру ИСПДн под уровни защищённости, как правильно обезличивать данные для ML и кто несёт ответственность в мультиарендной SaaS.

Что именно запрещает ст. 16 ФЗ-152 и когда она применяется?

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

На практике норма затрагивает три класса систем. Первый — кредитный скоринг: банк, МФО или финтех-сервис автоматически отказывает в займе на основе модели. Второй — HR-автоматизация: ATS-система ранжирует резюме и отсеивает кандидатов без участия рекрутера. Третий — динамическое ценообразование и персонализированные офферы, когда алгоритм определяет, что конкретному пользователю показать цену выше рыночной. Во всех трёх случаях субъект вправе потребовать разъяснения логики решения и его пересмотра живым сотрудником.

Согласие на автоматизированные решения должно быть явным и отдельным. После вступления в силу ФЗ-156 от 24.06.2025 (с 01.09.2025) согласие оформляется отдельным документом — не встраивается в договор, пользовательское соглашение или политику конфиденциальности. Это прямо касается всех продуктов, где автоматика принимает значимые решения.

Как выбрать уровень защищённости ИСПДн по ПП РФ №1119 для SaaS-архитектуры?

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

Для типового SaaS-продукта, обрабатывающего контактные и поведенческие данные пользователей без спецкатегорий, при угрозах типа 3 и числе субъектов менее 100 000 применяется УЗ-4. Если субъектов более 100 000 — УЗ-3. Если система обрабатывает данные о здоровье, финансовом положении или судимостях — минимум УЗ-3 вне зависимости от числа субъектов, а при угрозах типа 2 — УЗ-2.

Мультиарендная SaaS-платформа — отдельный случай. Если один tenant обрабатывает данные о здоровье своих клиентов, а другой — только email-адреса, общая ИСПДн оператора-платформы должна соответствовать наивысшему из требуемых уровней. Это архитектурное решение: либо физическая изоляция tenant-сред с разными уровнями защиты, либо единый УЗ для всей инфраструктуры. Второй путь проще административно, но дороже технически.

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

Является ли логирование в SaaS-системе обработкой персональных данных?

Да, если в логах фиксируются идентификаторы пользователей (user_id, IP-адреса, email, токены сессий). РКН в своих разъяснениях последовательно квалифицирует IP-адрес как ПДн при наличии возможности идентификации субъекта. Логи доступа, логи действий в системе, логи ошибок с параметрами запросов — всё это потенциально содержит ПДн.

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

Для SaaS-платформ, где логи уходят в облако — особое внимание к вопросу локализации. Ч. 5 ст. 18 ФЗ-152 требует, чтобы первичные операции записи, систематизации, накопления, хранения, уточнения и извлечения ПДн граждан РФ выполнялись в базах данных, расположенных в России. Cloudflare Logs, AWS CloudWatch, Datadog с EU-регионом — всё это потенциально нарушает требование локализации при обработке ПДн граждан РФ.

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

С 01.09.2025 в России действуют официальные методы обезличивания ПДн, установленные приказом РКН. Пять методов: введение идентификаторов (замена прямых идентификаторов на псевдонимы), изменение состава или семантики (удаление или замена атрибутов), декомпозиция (разбиение на несвязанные части), перемешивание (перестановка значений между записями), обобщение и агрегация (замена точных значений диапазонами или агрегатами).

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

На практике большинство обучающих датасетов являются псевдонимизированными, а не обезличенными. Это означает: требования ФЗ-152 к ним применяются в полном объёме, включая уровень защищённости, согласие и ограничение целей. CTO, заявляющий, что «мы обезличили данные», должен быть готов доказать необратимость — РКН при проверке запрашивает документацию о применённых методах.

Практические сценарии: когда ст. 16 152-ФЗ создаёт реальный риск

Сценарий 1. Автоматический отказ в сервисе без объяснения причин. Финтех-стартап (Центральный ФО, лето 2025) внедрил ML-скоринг для выдачи кредитных линий. Система автоматически отклоняла заявки. Субъект обратился с жалобой в РКН — система не предусматривала ни разъяснения логики отказа, ни возможности пересмотра с участием сотрудника. РКН возбудил проверку по ч. 1 ст. 13.11 КоАП. Устранение: внедрение «человека в петле» (human-in-the-loop) на этапе финального решения и отдельного согласия на автоматизированную обработку.

Сценарий 2. Логи SaaS-системы в иностранном облаке. B2B SaaS-компания (Северо-Западный ФО, начало 2026) хранила логи доступа (с IP и user_id российских клиентов) в AWS eu-west-1. При плановой проверке РКН установил факт хранения ПДн граждан РФ за пределами страны — нарушение ч. 5 ст. 18 ФЗ-152. Штраф по ч. 8 ст. 13.11 КоАП составил сумму в диапазоне 1–6 млн ₽. Устранение потребовало миграции системы логирования в российское облако и переоформления договора поручения. ⚠️ Конкретный номер дела — менеджер уточняет при публикации.

Сценарий 3. Мультиарендная SaaS и неопределённость роли оператора. Платформа автоматизации HR-процессов (Уральский ФО, осень 2025) предоставляла сервис нескольким корпоративным клиентам. При проверке РКН возник вопрос: платформа — оператор или обработчик? В реестре РКН компания числилась как оператор, но договора поручения обработки ПДн с клиентами-тенантами не было. В итоге обе стороны получили предписания. Устранение: разграничение ролей в договоре, отдельное уведомление РКН, договор поручения с каждым тенантом.

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Ст. 16 ФЗ-152 — не мёртвая буква закона, а рабочий инструмент субъекта: право потребовать пересмотра любого автоматизированного решения, затрагивающего его права. Для CTO это означает обязательный «человек в петле» в критических пайплайнах, отдельное согласие на автоматизированные решения (с 01.09.2025), документально подтверждённое обезличивание датасетов и архитектуру ИСПДн, соответствующую присвоенному УЗ по ПП РФ №1119. Логирование, мультиарендность, иностранные облака — каждый из этих элементов создаёт самостоятельный вектор риска по ст. 13.11 КоАП в редакции с 30.05.2025.

DATUM сопровождает IT-команды по техническому комплаенсу 152-ФЗ: определение УЗ, договоры поручения, проверка методов обезличивания, DPIA для ML-систем, защита при штрафах по ст. 13.11 КоАП. Опыт охватывает SaaS-платформы, финтех и медтех с различными категориями ПДн.

14 апреля 2029 года