AI Act ЕС и российские операторы

К середине 2026 года пересечение европейского регулирования ИИ и российского законодательства о персональных данных стало реальной операционной проблемой для технических директоров. AI Act ЕС формирует требования к прозрачности, надзору и управлению рисками для ML-систем. Одновременно 152-ФЗ в редакции ФЗ-420 и ФЗ-156 ужесточил режим обработки ПДн в автоматизированных системах. Для CTO это означает двойной комплаенс: технические меры защиты по российским стандартам плюс документационные требования европейского регулятора. Ниже — анализ пересечений, практических конфликтов и способов их разрешения.

Как AI Act ЕС пересекается с обработкой ПДн по 152-ФЗ?

AI Act классифицирует системы ИИ по уровням риска: недопустимый, высокий, ограниченный и минимальный. Системы высокого риска (HR-скоринг, кредитный скоринг, медицинская диагностика, биометрическая идентификация) обязаны проходить оценку воздействия перед развёртыванием и вести регистрацию в базе данных ЕС. Для российского оператора, обслуживающего европейских клиентов через SaaS, это создаёт прямое пересечение с DPIA по ст. 18.1 ФЗ-152 — оценка воздействия на права субъектов требуется в обоих юрисдикциях, но в разном формате.

Ключевое структурное совпадение: оба регулятора требуют документировать цели обработки, категории данных и меры защиты до начала обработки. Расхождение — в объёме: AI Act требует также технической документации архитектуры модели, описания обучающих данных и механизмов надзора человека. 152-ФЗ сосредоточен на правовых основаниях (ст. 6, ст. 9), техническом уровне защищённости (ПП РФ №1119) и организационных мерах (ст. 18.1).

Практический вывод для CTO: если ML-система обрабатывает ПДн граждан РФ и одновременно предоставляется европейским клиентам, единый документ DPIA, составленный по расширенному шаблону (с техническими разделами для AI Act), закрывает требования обоих регуляторов в части оценки воздействия. Это снижает дублирование работ при двойном комплаенсе.

Что требует 152-ФЗ от CTO при использовании ML-моделей?

Технический директор отвечает за три обязательных технических параметра при обработке ПДн в ML-инфраструктуре.

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

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

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

Какие риски несёт SaaS с мультиарендностью при обработке ПДн клиентов?

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

Это означает обязательное заключение договора поручения обработки с каждым клиентом-оператором. Договор должен включать перечень обрабатываемых ПДн, цели обработки, перечень действий и обязательство обеспечить конфиденциальность. При отсутствии такого договора разработчик SaaS становится самостоятельным оператором без правового основания — что автоматически создаёт нарушение по ч. 1 ст. 13.11 КоАП (150 000–300 000 ₽ для юрлица в редакции с 30.05.2025).

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

Облако в РФ: что изменилось с 01.07.2025 по требованиям локализации?

С 01.07.2025 требования локализации по ч. 5 ст. 18 ФЗ-152 (в редакции ФЗ-233) ужесточены: первичный сбор, систематизация, накопление, хранение, уточнение и извлечение ПДн граждан РФ разрешены только в базах данных, расположенных в Российской Федерации. Трансграничная передача допустима после выполнения требований локализации — данные должны сначала попасть в российскую базу, а затем могут быть переданы за рубеж.

Для CTO это означает конкретный архитектурный запрет: нельзя организовывать первичный сбор ПДн граждан РФ напрямую в зарубежное облако. Если данные поступают в AWS us-east-1 или Azure westeurope без промежуточного хранения в российской зоне — это нарушение ч. 8 ст. 13.11 КоАП (штраф 1–6 млн ₽ для юрлица). При повторном нарушении — ч. 9 ст. 13.11 (6–18 млн ₽).

Облачные провайдеры с российскими зонами доступности (Яндекс Облако, VK Cloud, SberCloud, Облако МТС) позволяют организовать первичное хранение в РФ с последующей репликацией за рубеж. Важно документально подтвердить, что российская база данных является основной для операций записи — иначе регулятор может квалифицировать репликацию как первичное хранение в зарубежной юрисдикции.

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

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

Кейс 1. IT-компания из Сибирского федерального округа (осень 2025) предоставляла HR-SaaS с ML-скорингом кандидатов. При плановой проверке РКН инспекторы запросили акт определения уровня защищённости: документа не было. Платформа обрабатывала резюме с данными о здоровье (в графе «медкнижка») — специальная категория ПДн по ст. 10 ФЗ-152, требующая УЗ-1 или УЗ-2. Фактически система соответствовала УЗ-4. Компания получила предписание об устранении нарушений и штраф по ч. 1 ст. 13.11 КоАП в редакции, действовавшей на момент проверки. После привлечения юристов компания устранила нарушения за 45 дней: разработала модель угроз, внедрила дополнительные СЗИ, обновила ОРД. Повторная проверка нарушений не выявила.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итог

Для CTO в 2026 году ML-инфраструктура с ПДн — это одновременно задача по определению УЗ по ПП РФ №1119, внедрению мер по Приказу ФСТЭК №21, документированию поручения обработки и выбору архитектуры хранения с учётом требований локализации. AI Act ЕС добавляет слой документации для систем высокого риска, но не отменяет российские требования — они применяются параллельно.

Юристы и технические эксперты DATUM сопровождают IT-компании и SaaS-разработчиков в построении комплаенса по 152-ФЗ: от определения уровня защищённости до составления пакета ОРД и договоров поручения. Опыт практики по защите ПДн в IT-секторе — с 2014 года в рамках сети «Ветров и партнёры».