Обжалование автоматизированных решений

Ст. 16 ФЗ-152 существует с 2006 года, однако до 2024–2025 годов большинство IT-команд её игнорировали. Рост ML-систем в кредитовании, HR-скрининге, медицинской диагностике и e-commerce изменил ситуацию: Роскомнадзор включил автоматизированные решения в индикаторы риска при проверках. Для CTO это означает, что архитектурные решения в SaaS-продукте теперь напрямую влияют на правовой статус компании как оператора персональных данных.

Что такое автоматизированное решение по ст. 16 ФЗ-152 и когда оно обжалуется?

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

На практике под действие нормы попадают: автоматический отказ в кредите по скоринговой модели, блокировка аккаунта алгоритмом антифрода, HR-скрининг резюме без участия человека-рекрутёра, ценовая дискриминация на основе профиля пользователя. Ключевой признак — решение принято исключительно алгоритмом, без итоговой верификации живым сотрудником. Если хотя бы один сотрудник подтверждает результат — норма ст. 16 технически не нарушена, хотя документировать это нужно явно.

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

Как уровни защищённости УЗ-1..4 влияют на архитектуру ML-систем?

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

Для CTO практически важны три следствия. Первое: уровень защищённости определяет базовый набор мер по Приказу ФСТЭК №21 — 109 мер в 15 группах, из которых при УЗ-3 обязательны порядка 40. Второе: облачная инфраструктура (включая российские облака) должна соответствовать заявленному УЗ — оператор обязан проверить это при заключении договора поручения по ст. 6 п. 3 ФЗ-152. Третье: для SaaS с мультиарендностью каждый арендатор-оператор самостоятельно определяет УЗ своей ИСПДн; SaaS-вендор выступает обработчиком и должен обеспечить техническую возможность соответствия заявленному УЗ арендатора.

Можно ли использовать иностранные облака для хранения ПДн граждан РФ?

Ч. 5 ст. 18 ФЗ-152 обязывает операторов при сборе ПДн граждан РФ обеспечивать первичную запись, систематизацию, накопление, хранение, уточнение и извлечение этих данных с использованием баз данных, расположенных на территории РФ. Это требование локализации действует с 01.09.2015; с 01.07.2025 его применение ужесточено в части первичного сбора.

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

Российские облака (Яндекс Облако, VK Cloud, Selectel, Ростелеком) формально закрывают требование локализации, но оператор обязан проверить соответствие конкретного тарифа и региона развёртывания заявленному УЗ. Сертификат ФСТЭК на облачную платформу подтверждает соответствие требованиям, но не снимает с оператора ответственности за классификацию его ИСПДн.

Обезличивание ПДн для ML: что обязателен зафиксировать CTO

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

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

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

Кто является оператором в мультиарендной SaaS: типовые сценарии

В мультиарендной SaaS вопрос «кто оператор» не имеет единственного ответа — он зависит от того, кто определяет цели и способы обработки ПДн конкретного пользователя. Ст. 3 ФЗ-152 определяет оператора как лицо, самостоятельно или совместно с другими лицами организующее и (или) осуществляющее обработку ПДн, а также определяющее её цели и содержание.

Сценарий 1. B2B SaaS (платформа для корпоративных клиентов). Клиент-компания обрабатывает ПДн своих сотрудников или клиентов через платформу. Клиент — оператор, SaaS-вендор — обработчик по поручению (ст. 6 п. 3 ФЗ-152). Риск вендора: отсутствие типового договора поручения обработки в оферте создаёт пробел — оба субъекта формально становятся операторами без согласованной ответственности. Стратегия: включить в оферту или типовой договор поручение обработки с перечнем действий, перечнем категорий ПДн и обязанностями по безопасности.

Сценарий 2. B2C SaaS (платформа для конечных пользователей). Вендор напрямую собирает ПДн физлиц. Вендор — оператор. Это влечёт полный объём обязанностей: уведомление РКН по ст. 22 ФЗ-152, политика конфиденциальности по ст. 18.1, отдельные согласия по ст. 9 (с 01.09.2025 — в соответствии с ФЗ-156), ответы субъектам в течение 10 рабочих дней по ст. 20. Вендор не может переложить эти обязанности на пользователя-физлицо.

Сценарий 3. ML-модель, обученная на данных арендаторов. Если SaaS-вендор дообучает общую модель на ПДн из тенантов, он выходит за рамки поручения обработки и фактически становится самостоятельным оператором в части этих данных. Это требует отдельного согласия субъектов или иного правового основания по ст. 6 ФЗ-152. Без него обработка ПДн для дообучения модели нарушает ст. 5 (принцип соответствия объёма и целей обработки).

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

Кейс 1. SaaS-компания (Уральский ФО, весна 2025) предоставляла HR-платформу для автоматического ранжирования резюме. Клиенты-операторы не получали договоры поручения обработки — только оферту с общими условиями. При плановой проверке РКН установил, что вендор обрабатывает ПДн соискателей в своих аналитических целях (улучшение алгоритма). Оба субъекта получили предписания: вендор — как самостоятельный оператор без уведомления в реестре (штраф в пределах 300 тыс. ₽ по ч. 1 ст. 13.11 КоАП), клиенты — за отсутствие поручения обработки. После проверки вендор переработал оферту, разделив функции оператора и обработчика, и доработал механизм возражения против автоматизированных решений по ст. 16 ФЗ-152.

Кейс 2. Финтех-компания (Центральный ФО, осень 2025) использовала кредитный скоринг на ML-модели. Модель принимала решения об одобрении заявок автоматически, без финальной верификации сотрудником. Один из отказов обжаловал субъект через РКН. Регулятор запросил описание механизма обжалования и документацию по ст. 16 ФЗ-152 — её не оказалось. По итогам проверки компания получила предписание разработать порядок обжалования и провести оценку воздействия (DPIA) для ML-системы. Дополнительно выявлено несоответствие: скоринговая модель обучалась на необезличенных ПДн клиентов — возбуждено дело по ч. 1 ст. 13.11 КоАП.

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

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

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

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

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

2. Можно ли использовать иностранные облака для ПДн граждан РФ?

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

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

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

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

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

5. Какие средства защиты информации (СЗИ) обязательны по Приказу ФСТЭК №21?

Приказ ФСТЭК №21 определяет базовый набор мер в 15 группах (идентификация и аутентификация, управление доступом, защита машинных носителей, регистрация событий, антивирусная защита и др.). Конкретный состав обязательных мер зависит от УЗ ИСПДн: при УЗ-3 обязательны порядка 40 мер из 109. СЗИ, используемые для выполнения мер, должны иметь действующий сертификат ФСТЭК или пройти оценку соответствия в установленном порядке. Применение несертифицированных СЗИ при УЗ-1 и УЗ-2 является нарушением требований ст. 19 ФЗ-152.

Итог

Обжалование автоматизированных решений по ст. 16 ФЗ-152 — не формальность, а архитектурное требование к SaaS-продуктам, использующим ML и алгоритмическую обработку ПДн. Правовая база в 2025 году охватывает одновременно порядок обжалования, уровни защищённости по ПП РФ №1119, требования к обезличиванию для ML и разграничение ролей оператора и обработчика в мультиарендной среде.

Юристы DATUM сопровождают IT-компании и SaaS-вендоров по полному циклу: классификация ИСПДн, DPIA для ML-систем, разработка порядка обжалования автоматизированных решений, оформление договоров поручения обработки и подготовка к проверкам РКН.