Закон об ИИ в России: что меняется для бизнеса с 1 сентября 2027 года

Что было опубликовано весной 2026 года

В середине марта на портале regulation.gov.ru появился проект, который Минцифры презентовало как первый системный закон об ИИ в России. До него отрасль регулировалась по кускам: стратегия развития ИИ до 2030 года, ГОСТы, отраслевые методические документы, экспериментальные правовые режимы под отдельные кейсы. Системного документа не было.

В первой редакции появились несколько идей, которые потом стали предметом главных споров. Прежде всего — сама конструкция риск-ориентированного подхода: регулирование тем строже, чем серьёзнее последствия от ошибки модели. Дальше — три новые юридические категории моделей: «суверенная», «национальная» и «доверенная». Отдельной нормой шла обязательная маркировка контента, созданного нейросетью. Главное для бизнеса с КИИ — обязательное использование доверенных моделей в государственных информационных системах и на значимых объектах критической информационной инфраструктуры. Проверять такие модели должны были ФСТЭК и ФСБ.

Публичное обсуждение шло почти месяц, с 18 марта по 15 апреля. К нему подключились более 150 экспертов, представители Роснефти, Россетей, МегаФона, объединённой компании Wildberries и Russ, отраслевых ассоциаций — АПКИТ, АЦП, АЕБ, ТПП, Ассоциации больших данных. Дискуссия получилась громкой.

Что критиковал бизнес

Камнем преткновения стали критерии «суверенной» и «национальной» моделей. По первой редакции, чтобы получить такой статус, модель должна была разрабатываться исключительно гражданами РФ на территории страны, обучаться только на данных российского происхождения и использоваться только при участии российских юридических лиц. На бумаге звучит логично. На практике — почти невыполнимо.

Открытых русскоязычных датасетов в нужном объёме просто нет. Все российские LLM — и коммерческие, и опенсорсные — используют зарубежные библиотеки, веса базовых моделей и многоязычные датасеты. По оценкам ассоциаций, реализация в первоначальной редакции увеличила бы стоимость внедрения ИИ на 20–40% и замедлила вывод продуктов на рынок в полтора-два раза. Ни первая цифра, ни вторая никого не устраивают.

23 апреля точку в первой редакции поставил Совет по кодификации при Президенте: документ отклонили, указав на противоречия с Гражданским кодексом и размытость формулировок.

Что изменилось в обновлённой редакции

Через четыре дня, 27 апреля, аппарат вице-премьера Дмитрия Григоренко публично рассказал, как документ переписали. Ключевые правки:

• требование разрабатывать суверенные и национальные модели исключительно гражданами России — убрано;
• требование обучать такие модели только на данных российского происхождения — убрано;
• статус «суверенной» и «национальной» теперь нужен в первую очередь для возможности господдержки, а не как обязательное условие применения;
• зарубежные ИИ-модели не запрещаются — они могут работать в России при соблюдении российского законодательства и претендовать на статус доверенных, если пройдут проверку безопасности;
• обязательное использование доверенных моделей касается прежде всего госсектора и значимых объектов КИИ;
• для коммерческого софта подтверждение «доверенности» — добровольное.

Принципиальный сдвиг — от общей запретительной рамки к отраслевому порогу. Большая часть коммерческого ИИ остаётся в зоне мягкого регулирования. Жёсткие требования распространяются на госсектор, КИИ и всё, что прямо влияет на безопасность граждан. Для компаний с лицензиями ФСТЭК и ФСБ, которые работают с КИИ-объектами, по сути ничего не поменялось — к ним требования останутся максимальными.

Почему игнорировать законопроект нельзя

Самый понятный соблазн — сказать: «текст ещё не финальный, давайте подождём принятия и тогда уже что-то делать». Сценарий рабочий ровно до того момента, пока дата 1 сентября 2027 не окажется в трёх месяцах от текущего дня. Тогда что-то делать придётся срочно и дорого.

Логика регулирования уже видна, и она вряд ли изменится в принципиальных вещах: риск-ориентированный подход, реестр доверенных моделей, проверка ФСТЭК и ФСБ, локализация обработки данных в значимых сценариях. Эти принципы заложены не только в законопроекте, но и в сопутствующих документах по КИИ, поручениях Президента, отраслевых нормах. Может смягчиться формулировка — но не общее направление.

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

Наконец, чисто технически: переехать с публичного облачного ИИ на закрытый контур за месяц-два невозможно. На железо, документацию, регламенты, пилот и обучение людей уходит 6–12 месяцев. Кто начнёт в конце 2026-го, успеет к осени 2027 в спокойном режиме. Кто отложит до весны 2027-го — будет работать в авральном.

Идея проста: чем серьёзнее последствия от ошибки или сбоя ИИ-системы, тем строже требования к её разработке и эксплуатации. ИИ, который пишет рекламные тексты, и ИИ, который участвует в решении о допуске человека к опасным работам или о выдаче кредита, — это разные истории и разная мера ответственности.

В первом случае хватает общих правил добросовестности: предупредить пользователя, не нарушать законов о рекламе, маркировать сгенерированный контент. Во втором — нужны жёсткие требования к качеству обучающих данных, объяснимости решений, журналированию, защите от взлома и подмены. И это не каприз законодателя — это нормальная инженерная гигиена для систем, ошибка которых стоит дорого.

Подход не уникален для России. Похожая логика лежит в основе европейского AI Act, и её заимствование — правильный шаг. Но российская версия строится не вокруг прав человека (как в ЕС), а вокруг безопасности информационной инфраструктуры. Поэтому ключевые роли отданы ФСТЭК и ФСБ, а центральным понятием стал реестр доверенных моделей.

Критический

Высокий

Ограниченный

Минимальный

Кто попадает в зону повышенного внимания

В обеих редакциях законопроекта уровень контроля растёт там, где ИИ затрагивает чувствительные сферы. Если ваш сценарий хотя бы частично подходит под одно из этих описаний — готовиться придётся всерьёз:

• системы, влияющие на жизнь и здоровье — медицинская диагностика, помощь врачам в принятии решений, управление транспортом и промышленным оборудованием;
• системы, принимающие или существенно влияющие на решения о правах граждан — скоринг, отказ в услугах, подбор кандидатов на работу;
• системы, обрабатывающие данные ограниченного доступа — персональные данные, банковскую тайну, гостайну, охраняемую иную тайну, коммерческую тайну;
• системы, встроенные в критическую информационную инфраструктуру;
• системы, работающие в государственных информационных системах, особенно социально значимых.

Чем больше галочек, тем выше будет потолок требований. Точные критерии разнесения по уровням риска появятся в подзаконных актах, но общая интуиция от этого не изменится.

Почему КИИ и госсектор — первая линия

Регулирование критической информационной инфраструктуры — самая зрелая часть российского правового поля по ИБ. Здесь уже работают 187-ФЗ, приказы ФСТЭК, требования к доверенным программам и базам данных, обновлённые в 2025–2026 нормы. ИИ-системы естественно достраиваются в эту картину — как новый класс информационных систем, к которому применят знакомые принципы: категорирование, защита, контроль, аудит.

В обновлённой редакции это и закреплено: жёсткие требования распространяются прежде всего на значимые объекты КИИ и госсектор. Для остального бизнеса требования заметно мягче, а значит у большинства компаний есть пространство для маневра. Но только если они не работают с банковской тайной, медициной, энергетикой, транспортом или госзаказчиком.

Это, пожалуй, самая запутанная часть законопроекта. Три новых юридических термина похожи между собой, и даже специализированная пресса их регулярно путает. Между тем разница принципиальная: за каждой категорией стоит своя задача регулятора, и для бизнеса важно понимать, какая из них к нему применима.

Зачем три категории

Государство параллельно решает две разные задачи. Первая — поддержать развитие отечественных ИИ-моделей: льготное финансирование, преференции в госзакупках, доступ к вычислительным мощностям. Под эту задачу заточены статусы «суверенная» и «национальная». Вторая — гарантировать безопасность ИИ в чувствительных сферах. Под неё — статус «доверенная».

Перед нами две независимые шкалы. Российская модель не обязательно подходит для КИИ — она может быть отечественной, но уязвимой к prompt injection или к утечкам через выдачу. Зарубежная модель не обязательно небезопасна — в обновлённой редакции она тоже может пройти проверку и получить статус доверенной. Если, конечно, провайдер согласится открыть архитектуру и допустить регуляторов к контролю.

Суверенная

Национальная

Доверенная

Суверенная модель

В первой редакции суверенной называлась модель с полностью российским происхождением: разработка, обучение, инфраструктура, данные, кадры — всё внутри страны. Именно это и стало главным камнем преткновения: на практике обеспечить такую чистоту цепочки сегодня невозможно.

В обновлённой редакции требования смягчили. По текущей версии достаточно, чтобы модель принадлежала российскому юрлицу и соответствовала российскому законодательству. Точные критерии — про долю отечественных компонентов, локализацию обучения, состав команды — уйдут в подзаконные акты. Пока понятно одно: статус «суверенной» нужен в первую очередь для получения господдержки и преференций. Инструмент промышленной политики, а не универсальное обязательное требование.

Национальная модель

Похожа на суверенную, но с менее жёсткими требованиями. Где именно проходит граница между двумя статусами — до сих пор неясно. На это ещё в марте обращали внимание эксперты АПКИТ: разница между «суверенной» и «национальной» в первой редакции была размыта настолько, что юристы не могли уверенно отнести модель к той или иной категории. В обновлённой редакции, по доступным данным, критерии стали реалистичнее, но окончательное разграничение всё равно появится только в подзаконных актах.

Доверенная модель

Вот это — главное понятие для всех, кто работает с КИИ, госзаказчиками или чувствительными данными. Доверенная модель должна одновременно соответствовать четырём критериям:

• пройти подтверждение соответствия требованиям информационной безопасности — по линии ФСТЭК и ФСБ;
• обрабатывать данные на территории России;
• соответствовать отраслевым требованиям качества — например, требованиям ЦБ для банков или Минздрава для медицинских систем;
• быть включённой в специальный реестр доверенных моделей.

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

Конкретный порядок проверки безопасности на момент конца апреля 2026-го не утверждён. Скорее всего, методики появятся в подзаконных актах Правительства, ФСТЭК и ФСБ — уже после принятия рамочного закона. Так работает рамочное регулирование: закон задаёт принципы, методики и конкретные регламенты приходят следом.

Как это касается вашего бизнеса

Если ваши ИИ-сценарии не пересекаются с госсектором, КИИ или социально значимыми ГИС — модели из реестра можно не использовать. Достаточно соблюдать общее законодательство: 152-ФЗ о персональных данных, 149-ФЗ об информации, отраслевые нормы. Можно работать хоть на YandexGPT, хоть на Claude, хоть на опенсорсной Llama — под свою ответственность.

Если пересекаются — выбора три. Первый: использовать модель из реестра доверенных. Второй: проводить собственную проверку безопасности и добиваться включения своей модели в реестр. Третий: переходить на закрытый контур с подтверждением соответствия требованиям. На практике большинство компаний выбирают комбинацию: коробочные сценарии — на готовых доверенных моделях, специфичные — через закрытый on-premise контур, который проще аттестовать.

В марте, когда первую редакцию законопроекта только опубликовали, в деловой прессе быстро сложилась интерпретация: иностранные ИИ-сервисы запретят. Трактовка оказалась поспешной и не совсем точной — и аппарат Григоренко её прямо опроверг 27 апреля. Полного запрета в законопроекте нет ни в одной редакции.

Что есть на самом деле — это требование использовать только доверенные модели из реестра в значимых объектах КИИ и государственных информационных системах. Если зарубежная модель не вошла в реестр — её нельзя применять в этих контурах. Но речь именно об ограничении в конкретных сферах, а не о генеральном запрете.

Тонкость в том, что для большинства зарубежных облачных сервисов попасть в реестр доверенных — технически и юридически почти неподъёмно. Чтобы получить статус, нужно показать ФСТЭК и ФСБ архитектуру системы, обеспечить локализацию обработки данных, открыть цепочку поставки модели и допустить регуляторов к контролю. Ни OpenAI, ни Anthropic, ни Google такие условия выполнять не будут — это противоречит их бизнес-модели и американскому законодательству. Получается не запрет, а высокий барьер, через который большинство публичных платформ просто не пройдёт.

Для частного бизнеса, не работающего с КИИ и госзаказчиками, формальных ограничений по использованию зарубежных моделей в обновлённой редакции нет вообще. Можно продолжать работать с ChatGPT, Claude, Gemini и любыми другими — под свою ответственность и при соблюдении общего законодательства.

Публичный облачный ИИ

On-premise ИИ

Данные уходят за периметр

Данные остаются в контуре

Скрытые риски использования внешних облаков

Закон ещё не принят, но часть проблем с публичным облачным ИИ существует уже сейчас, независимо от регулирования. Зрелые компании их учитывают — и поэтому переходят на закрытый контур не дожидаясь принуждения.

• Передача персональных данных за рубеж. Когда сотрудник копирует резюме кандидата в ChatGPT для краткого пересказа — это потенциальное нарушение 152-ФЗ, если у компании нет надлежащих оснований трансграничной передачи. Подробнее о 152-ФЗ и ИИ.
• Утечка коммерческой тайны. Запросы и документы, отправленные в публичный сервис, могут попадать в логи провайдера, использоваться для дообучения модели или быть доступны его сотрудникам в рамках расследований. Юристы спокойно загружают черновики договоров, разработчики — куски кода с ключами API. Никто не считает это утечкой, пока ничего не всплыло.
• Геополитические риски. Провайдер может в любой момент отозвать доступ или ограничить использование — такие случаи уже происходили с рядом западных сервисов после 2022 года.
• Потеря контроля над данными. В корпоративный DLP внешний облачный сервис не встроишь. Журналирования действий пользователей нет. Аудит после инцидента — невозможен.
• Несовместимость с отраслевыми регуляторами. Банковская тайна, медицинская тайна, гостайна, охраняемая иная тайна — всё это плохо совмещается с публичным облачным ИИ независимо от того, что напишут в ФЗ об ИИ.

Список не исчерпывающий, и каждый пункт по отдельности кажется управляемым. Проблема в том, что они часто складываются: одно резюме в ChatGPT — ничего страшного, тысяча резюме в ChatGPT — уже подходящий повод для предписания Роскомнадзора.

Что известно про процедуру

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

Конкретные регламенты — методики, критерии, формы документов, сроки рассмотрения, состав испытаний — уйдут в подзаконные акты, которые появятся уже после принятия закона. Так работает рамочное регулирование: закон задаёт принципы, методики приходят отдельно. Минус в том, что готовиться к конкретике приходится по аналогиям с уже существующими процедурами ФСТЭК и ФСБ.

Какие документы стоит готовить уже сейчас

Финальная редакция может ещё подвинуться, но базовый комплект документов почти не будет зависеть от нюансов формулировок. Если в компании есть ИИ-сценарии в чувствительных сферах, готовить нужно следующее.

• Модель угроз ИИ-системы. Не обычная модель угроз, а специфичная для нейросетей: отравление обучающих данных, prompt injection, утечка чувствительной информации через выдачу модели, подмена компонентов цепочки поставки, инверсия модели для извлечения обучающих данных. Без неё ни одна проверка не закроется.
• Классификация обрабатываемых данных. Что именно идёт на вход и выход модели: персональные данные, коммерческая тайна, охраняемая иная тайна, банковская тайна, гостайна. Без классификации невозможно ни оценить риск, ни выбрать архитектуру.
• Архитектурная схема. Где живёт модель, где данные, как они движутся, кто имеет доступ. Картинка простая, но именно её всегда требуют первой.
• Регламенты эксплуатации. Порядок обновления модели, контроль изменений, тестирование перед каждой выкаткой. Если завтра прилетит новая версия Llama 4 и кто-то на коленке заменит ей старую модель в продакшене — это нарушение.
• Журналирование действий пользователей и модели. Запросы, ответы, решения, время хранения, защита самих журналов. Особенно важно для расследования инцидентов.
• Контроль доступа. Кто может работать с системой, как аутентифицируется, какие у него права. Простая ролевая модель закрывает 80% вопросов.
• Управление инцидентами. Что считается инцидентом ИИ (не всегда очевидно: утечка через выдачу — это инцидент или сбой?), как фиксируется, кому эскалируется, как расследуется.
• Контроль цепочки поставки. Откуда взялись веса модели, какая лицензия, чем отличается версия в проде от опенсорсной, кто и когда дообучал.

Этот пакет — фундамент любой проверки. Его готовят под уже работающие приказы ФСТЭК (включая обновлённый приказ № 117 от 2025 года). В случае ИИ его расширят с учётом специфики моделей, но основу можно собирать уже сейчас. Подробнее о сценариях ИИ в информационной безопасности.

Контроль цепочки поставки моделей

На этом пункте стоит остановиться отдельно. Supply chain ИИ-системы — тема молодая, и в корпоративных регламентах она почти никогда не прописана достаточно подробно. Между тем именно через цепочку поставки происходят самые неочевидные инциденты.

Что нужно отслеживать: источник самой модели (кто обучал, на каких данных, по какой методике), источник весов и контрольные суммы, версии библиотек и фреймворков (PyTorch, TensorFlow, vLLM, llama.cpp — у каждого регулярно выходят CVE), образы контейнеров и базовые ОС, внешние API, к которым обращается система во время инференса, и датасеты, использованные для дообучения.

Чем прозрачнее эта цепочка, тем проще пройти проверку и подтвердить «доверенность». Для on-premise решений всё это в принципе выполнимо — компания контролирует каждый компонент. Для публичных облачных моделей — фактически нет: провайдер не покажет вам внутренности своего стека.

Можно подождать финальной редакции закона. Можно ждать подзаконных актов. Можно ждать первых проверок у коллег по отрасли. У всех этих стратегий есть общая черта: чем дольше ждать, тем меньше времени на нормальную подготовку. Поэтому ниже — что имеет смысл начать делать уже сейчас. Большинство пунктов окупаются независимо от того, в какой именно редакции закон будет принят.

1. Инвентаризация ИИ-сценариев. Где в компании уже используется или планируется ИИ — генеративные модели, видеоаналитика, скоринг, RAG-поиск, ассистенты в продуктах. Список почти всегда длиннее, чем кажется ИТ-директору: половину сценариев запустили подразделения сами, без согласования. Без этой карты дальше двигаться бессмысленно.
2. Классификация данных по каждому сценарию. Что подаётся на вход, что выходит, какие категории данных проходят через систему. Персональные, коммерческая тайна, банковская, охраняемая иная, гостайна, открытые. Это основа для всех дальнейших решений.
3. Определение уровня риска. По логике риск-ориентированного подхода: что произойдёт при сбое, ошибке или утечке. Сценарии, влияющие на жизнь людей, права граждан или устойчивость КИИ — высокий риск. Внутренний помощник в почте — минимальный.
4. Аудит использования внешних ИИ-сервисов. Какие сотрудники работают с публичными моделями, что туда отправляют, есть ли политика. Часть данных при таком аудите всплывает впервые: «Иван из маркетинга три месяца загружал в ChatGPT финансовые отчёты для пересказа на планёрке».
5. Запрет загрузки чувствительных данных в публичные модели. Сделать это можно буквально завтра — регламентом, корпоративным DLP, прокси, корпоративным браузером. Большая часть рисков снимается простыми техническими мерами и инструктажем.
6. Архитектура для каждого сценария. Публичный облачный ИИ — только для нечувствительных задач. Гибрид — где это допустимо. On-premise или закрытый контур — для всего, что связано с персональными данными в чувствительных сценариях, КИИ, банковской тайной, гостайной.
7. ИБ-документация. Модели угроз, регламенты, журналирование, инциденты — всё, что обсуждалось выше. Для подготовленного ИБ-отдела — несколько недель работы. Для тех, кто такой работой раньше не занимался, счёт пойдёт на месяцы.
8. Пилот закрытого контура. Если в компании ещё нет опыта on-premise развёртывания LLM или RAG — первый пилот лучше пройти сейчас, в спокойном режиме. Через год это будет нужно делать в авральном. См. пошаговое руководство.
9. Обучение сотрудников. Без культуры безопасной работы с ИИ любые технические меры обходятся за пять минут — через копипаст в публичный сервис или личный смартфон. Одним инструктажем такое не решается — нужна системная работа с командами.
10. Подготовка к аудиту и аттестации. Понять, кто внутри компании отвечает за это направление (часто — никто), какие подрядчики могут помочь, какие лаборатории работают по линии ФСТЭК и ФСБ. Желательно заранее, потому что хороших исполнителей в 2027 году будет нехватка.

Грамотная подготовка к будущему регулированию — это не «купить сертифицированный продукт». Это значит выстроить архитектуру, которая в принципе совместима с риск-ориентированным подходом. On-premise развёртывание ИИ — один из её ключевых элементов. Не единственный, но для большинства сценариев из «высокого» и «критического» риска — безальтернативный.

Что даёт on-premise архитектура практически:

• Локальная обработка данных. Запросы, документы, ответы остаются в периметре организации. Локальная обработка снимает большую часть вопросов по 152-ФЗ, банковской тайне, охраняемой иной тайне и потенциальным требованиям локализации для доверенных моделей.
• Никакой передачи запросов во внешние облака. Главный риск публичных ИИ-сервисов — решён на уровне архитектуры. Не регламентом, не инструктажем, а тем, что физически некуда отправлять.
• LLM и RAG в закрытом контуре. Языковые модели и корпоративный поиск работают внутри инфраструктуры заказчика. Корпоративные знания не «утекают» в обучение чужой модели.
• Разграничение доступа на уровне корпоративных систем. Аутентификация через AD/LDAP, ролевые модели, ограничение видимости данных по подразделениям.
• Журналирование действий пользователей и модели. Всё, что нужно для расследования инцидентов и аттестационных процедур.
• Интеграция с корпоративными источниками знаний. RAG-архитектура подключается к 1С, СЭД, базам нормативных документов, архивам — без выноса этих данных наружу.
• DLP, SIEM, SOAR — по месту. ИИ-система становится частью корпоративного контура ИБ, а не «чёрным ящиком в облаке поставщика».
• Готовность к будущим требованиям. Когда появятся подзаконные акты с конкретными методиками проверки доверенных моделей, on-premise архитектура изначально совместима с большинством разумных требований — потому что построена по тем же принципам, что и существующие нормы по защите информации.

Для компаний, работающих с КИИ, госсектором, банковской и иной охраняемой тайной, — это не «один из вариантов», а основной путь подготовки к 2027 году. И чем раньше начать, тем спокойнее пройдёт собственно подготовка.