Регулирование ИИ в РФ 2026
Регулирование ИИ в РФ 2026 года — это не отдельный закон об искусственном интеллекте, а пересечение нескольких пластов: ФЗ-152 «О персональных данных», требования ФСТЭК по защите информационных систем, нормы КИИ по 187-ФЗ и уголовная ответственность по ст. 272.1 УК РФ, введённая с 11.12.2024. Для CTO это означает: каждая ML-система, работающая с данными физических лиц, — это ИСПДн со своим уровнем защищённости, набором обязательных мер и документальным оформлением. В этом материале — структура требований, практика классификации SaaS-систем и конкретные действия по приведению ИИ-инфраструктуры в соответствие.
Какие нормы регулируют ИИ-системы, обрабатывающие персональные данные?
Специального закона о регулировании ИИ в части ПДн в России нет. Действующий каркас строится на четырёх уровнях. Первый — ФЗ-152: если ML-система получает на вход данные физических лиц (имена, идентификаторы, поведенческие паттерны, биометрию), она является оператором или обработчиком персональных данных. Второй уровень — ПП РФ №1119 от 01.11.2012, устанавливающий четыре уровня защищённости ИСПДн (УЗ-1..4) в зависимости от категории данных, типа угроз и числа субъектов. Третий — Приказ ФСТЭК №21 от 18.02.2013, задающий базовый набор мер для каждого УЗ в 15 группах (ИАФ, УПД, ЗНИ, РСБ и другие — всего 109 мер). Четвёртый — уголовная ответственность по ст. 272.1 УК РФ, действующая с 11.12.2024: незаконное использование, передача, хранение компьютерной информации, содержащей ПДн, — до 10 лет лишения свободы по ч. 5 при тяжких последствиях.
Дополнительный регуляторный слой — 187-ФЗ о критической информационной инфраструктуре. Если SaaS-платформа работает в отраслях из перечня КИИ (здравоохранение, финансы, транспорт, связь), она может быть признана субъектом КИИ. Это означает отдельную категоризацию объектов и более жёсткие требования к защите. Пересечение ФЗ-152 и 187-ФЗ в одной системе — характерная ситуация для медицинских, банковских и промышленных ИИ-платформ.
Как определить уровень защищённости УЗ-1..4 для ML-системы?
Классификация ИСПДн по ПП РФ №1119 строится на трёх параметрах: категория данных, тип актуальных угроз и количество субъектов. Для ML-систем критичен второй параметр — тип угроз определяет, влечёт ли архитектура системы наличие недекларированных возможностей в системном ПО (угрозы 1-го и 2-го типов) или нет (3-й тип). Большинство коммерческих SaaS-платформ работают с угрозами 3-го типа — это позволяет получить УЗ-3 или УЗ-4 даже при обработке специальных категорий ПДн.
На практике ML-система, обучаемая на обезличенных данных, может не являться ИСПДн вовсе — если обезличивание выполнено по методам приказа РКН (введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация). Однако обезличивание должно быть необратимым: если модель позволяет восстановить связь записи с конкретным субъектом, данные по-прежнему считаются персональными. Это особенно актуально для рекомендательных систем и моделей, работающих с поведенческими данными.
Для SaaS-платформ с мультиарендностью классификация усложняется. Каждый арендатор (tenant) может обрабатывать данные разных категорий и разного объёма. Технически это означает, что единая ИСПДн вендора должна обеспечивать наивысший УЗ из всех задействованных арендаторами. Альтернативный подход — логическая или физическая изоляция сред с отдельной классификацией каждой. Второй путь дороже в инфраструктуре, но снижает совокупный уровень требований.
Не уверены, какой УЗ применим к вашей ML-системе?
Классификация ИСПДн для SaaS-платформ с ИИ — нетривиальная задача. Ошибка в определении уровня угроз или неправильная оценка категории данных означает неполный набор мер ФСТЭК и риск штрафа по ч. 1 ст. 13.11 КоАП (до 300 000 ₽) при плановой проверке. Юристы DATUM проведут аудит ИСПДн с классификацией по ПП РФ №1119 и выдадут карту мер по Приказу ФСТЭК №21.
Заказать аудит 152-ФЗОтветим за 2 часа · +7 (983) 510-38-76 · info@vitveteam.ru · Telegram
Что такое обезличивание для ML и как его правильно применять?
С 01.09.2025 обезличивание персональных данных регулируется специальным приказом РКН, устанавливающим пять обязательных методов. Для ML-пайплайна это означает: выбор метода должен быть задокументирован, применение — воспроизводимым, а результат — проверяемым на необратимость. Просто заменить имя на UUID недостаточно: если идентификатор позволяет сопоставить запись с субъектом через смежные данные (косвенная идентификация), это не обезличивание по смыслу ст. 3 ФЗ-152.
На практике для обучающих датасетов чаще применяют комбинации методов: обобщение (замена точных значений диапазонами — возраст «34» становится «30–40»), перемешивание (разрыв связей между атрибутами разных субъектов) и декомпозиция (разделение датасета на фрагменты, каждый из которых не позволяет идентифицировать субъекта). Введение псевдонимов (идентификаторов) само по себе является псевдонимизацией, а не обезличиванием — такие данные остаются персональными по ст. 3 ФЗ-152.
Что подготовить для легального ML-пайплайна
- Акт классификации ИСПДн по ПП РФ №1119 с указанием типа угроз, категории и объёма субъектов
- Документированный метод обезличивания датасета с описанием применённых приёмов и результатом проверки необратимости
- Договор поручения обработки по п. 3 ст. 6 ФЗ-152, если ML-платформа работает по модели SaaS для внешних операторов
- Политику обработки ПДн с разделом об автоматизированной обработке и возможности оспорить автоматическое решение по ст. 16 ФЗ-152
- Журнал логирования событий безопасности с удержанием согласно требованиям УЗ (минимум 1 год для УЗ-3 и выше по Приказу ФСТЭК №21)
Кто является оператором в мультиарендной SaaS-архитектуре?
Вопрос об операторе в SaaS-системах — один из наиболее спорных в практике 2026 года. ФЗ-152 разграничивает оператора (самостоятельно определяет цели и состав обработки) и лицо, осуществляющее обработку по поручению (действует в рамках задания оператора по п. 3 ст. 6). В мультиарендной архитектуре вендор SaaS, как правило, претендует на роль обработчика по поручению каждого арендатора-оператора. Это принципиально: при надлежащем оформлении поручения ответственность за содержание обработки лежит на операторе-арендаторе, а вендор отвечает лишь за технические меры защиты.
Однако поручение работает только при соблюдении условий п. 3 ст. 6 ФЗ-152: письменный договор, перечень действий, обязанность соблюдать конфиденциальность и применять меры защиты по ст. 19. Если договор с арендатором не содержит этих реквизитов или вендор самостоятельно использует агрегированные данные арендаторов (например, для дообучения общей модели), он де-факто становится оператором со всеми обязательствами: уведомление РКН, политика, согласия субъектов, локализация по ч. 5 ст. 18 ФЗ-152.
Отдельный риск — использование данных арендаторов для обучения общей модели без явного согласия субъектов и операторов-арендаторов. Это не только нарушение ст. 5 ФЗ-152 (принцип целевого использования), но и потенциальная ответственность по ст. 272.1 УК РФ при умысле на незаконное использование компьютерной информации, содержащей ПДн. С 11.12.2024 эта норма активна и уже применяется следователями.
Если CTO не оформил договор поручения с арендаторами SaaS-платформы — вендор несёт ответственность как оператор. Уведомление РКН, политика, локализация хранилища в РФ и согласия субъектов становятся его обязанностью. Юристы DATUM помогут разграничить роли и оформить документы.
Заказать аудит 152-ФЗКак регулирование ИИ применяется на практике в 2026 году?
Сценарий 1. ML-платформа без классификации ИСПДн. IT-компания (Сибирский ФО, начало 2026) разрабатывает рекомендательную систему для ритейла. Входные данные — история покупок и демографические атрибуты покупателей клиента. Договор поручения с клиентом отсутствует. При плановой проверке РКН инспектор квалифицировал платформу как оператора, обрабатывающего ПДн без уведомления и без надлежащих мер защиты. Составлен протокол по ч. 1 ст. 13.11 КоАП. Параллельно потребовано устранить нарушения в 30 дней. После заключения договора поручения, подачи уведомления в РКН и разработки политики — постановление обжаловано, штраф минимизирован.
Сценарий 2. Обучение модели на необезличенных данных. Финтех-компания (Центральный ФО, осень 2025) обучала модель кредитного скоринга на исторических данных заёмщиков. Датасет содержал ФИО, паспортные данные и финансовые показатели без обезличивания. После утечки датасета (около 15 000 записей) РКН составил протокол по ч. 12 ст. 13.11 КоАП (штраф для юрлица 3–5 млн ₽). В рамках расследования CISO компании получил проверку на предмет ст. 272.1 УК РФ. Факт применения методов обезличивания в проде (при отсутствии его в train-пайплайне) не снял ответственность за нарушение при обработке исходного датасета.
Сценарий 3. SaaS-вендор и облако за рубежом. SaaS-платформа (Северо-Западный ФО, 2025) хранила данные российских пользователей в облаке EU-региона. После ужесточения требований к локализации с 01.07.2025 (ФЗ-233) РКН провёл внеплановую проверку по жалобе субъекта. Нарушение ч. 5 ст. 18 ФЗ-152 повлекло протокол по ч. 8 ст. 13.11 КоАП с штрафом для юрлица 1–6 млн ₽. Перенос первичного хранилища в российское облако занял 4 месяца — всё это время шли административные процедуры.
Услуги DATUM по теме
- Аудит соответствия 152-ФЗ — классификация ИСПДн, проверка мер ФСТЭК, оценка рисков ML-пайплайна
- DPIA (оценка воздействия) — анализ рисков для субъектов при автоматизированной обработке и ИИ-решениях
- Комплект ОРД под ключ — договор поручения, политика, регламент обезличивания, журналы для ML-инфраструктуры
Частые вопросы
1. Какой УЗ выбрать для SaaS-платформы с ИИ?
Уровень защищённости определяется по ПП РФ №1119 на основе трёх параметров: категория обрабатываемых ПДн (специальные, биометрические, общие или иные), тип актуальных угроз (1, 2 или 3) и количество субъектов (более или менее 100 000). Для большинства коммерческих SaaS-платформ актуальны угрозы 3-го типа (отсутствие недекларированных возможностей в системном ПО). При обработке общих категорий ПДн в любом объёме с угрозами 3-го типа — УЗ-4 (минимальный базовый набор мер ФСТЭК). При специальных категориях и объёме до 100 000 субъектов — УЗ-3. Финальное решение фиксируется в акте классификации ИСПДн.
2. Можно ли использовать иностранные облака для хранения ПДн российских пользователей?
После ужесточения требований к локализации с 01.07.2025 (ФЗ-233) хранение, запись, систематизация, накопление и извлечение ПДн граждан РФ должны осуществляться только в базах данных, расположенных в России (ч. 5 ст. 18 ФЗ-152). Иностранное облако допустимо для зеркалирования или резервного копирования после первичной записи в российском хранилище — но не для первичного сбора. Нарушение влечёт штраф по ч. 8 ст. 13.11 КоАП от 1 до 6 млн ₽, при повторности (ч. 9) — от 6 до 18 млн ₽.
3. Что такое обезличивание для ML и чем оно отличается от псевдонимизации?
Обезличивание по ст. 3 ФЗ-152 — это действия, в результате которых невозможно без дополнительной информации определить принадлежность ПДн конкретному субъекту. Псевдонимизация (замена идентификаторов на псевдонимы при сохранении таблицы соответствия) — это не обезличивание: данные остаются персональными. Для ML-датасетов РКН с 01.09.2025 установил пять методов: введение идентификаторов, изменение состава и семантики, декомпозиция, перемешивание, обобщение и агрегация. Применение метода должно быть задокументировано, а результат — проверен на невозможность обратной идентификации.
4. Кто является оператором в мультиарендной SaaS — вендор или арендатор?
По умолчанию — тот, кто самостоятельно определяет цели и состав обработки. Если арендатор самостоятельно загружает данные своих клиентов в платформу вендора для своих целей — арендатор является оператором, вендор может выступать обработчиком по поручению (п. 3 ст. 6 ФЗ-152). Поручение оформляется письменным договором с перечнем действий и обязанностями по защите. Если такого договора нет или вендор использует данные арендаторов в собственных целях (например, для общего дообучения модели), вендор приобретает статус самостоятельного оператора со всеми вытекающими обязанностями: уведомление РКН, локализация, согласия субъектов.
5. Какие СЗИ обязательны для ИСПДн по Приказу ФСТЭК №21?
Приказ ФСТЭК №21 устанавливает 109 мер в 15 группах, из которых базовый набор определяется уровнем защищённости. Для УЗ-4 обязательны меры идентификации и аутентификации (ИАФ), управления доступом (УПД), регистрации событий (РСБ), антивирусной защиты (АВЗ) и обеспечения целостности (ОЦЛ). Для УЗ-3 добавляются меры по защите носителей (ЗНИ), сетевой безопасности (ЗИС) и обнаружению вторжений (СОВ). Конкретный перечень применяемых мер фиксируется в техническом задании на систему защиты и в эксплуатационной документации. Использование несертифицированных СЗИ при обязательной сертификации — нарушение технических требований ФСТЭК.
Итог
Регулирование ИИ в РФ 2026 года строится на пересечении ФЗ-152, Приказа ФСТЭК №21, ПП РФ №1119 и уголовной нормы ст. 272.1 УК РФ. Для CTO это означает обязательную классификацию каждой ML-системы как ИСПДн, документированное обезличивание датасетов, разграничение ролей оператора и обработчика в SaaS-договорах и локализацию первичного хранилища в России.
Юристы DATUM сопровождают IT-компании и SaaS-вендоров в вопросах классификации ИСПДн, разработки договоров поручения, DPIA для ИИ-систем и подготовки комплекта ОРД по требованиям 152-ФЗ и ФСТЭК.
19 февраля 2027 года