Закон об ИИ в России 2026: что изменилось и как подготовить компанию

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

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

Главная практическая мысль: законопроект, судя по описанию, движется не в сторону немедленного запрета инструментов, а в сторону более избирательного регулирования. Значит, бизнесу полезнее не останавливать внедрения, а научиться документировать ИИ-процессы так, чтобы их можно было объяснить юристам, службе безопасности, клиентам и регулятору.

Что именно изменилось в логике регулирования

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

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

Во-вторых, по сообщению, отказались от требования обучать модели только на российских данных. Это тоже существенная деталь. Современные модели часто обучаются на смешанных корпусах, дообучаются на специализированных наборах данных и работают в сложных цепочках с внешними инструментами. Жесткое требование по происхождению данных могло бы создать трудноисполнимую норму, особенно для разработчиков, которые используют открытые модели, международные датасеты или комбинированные архитектуры.

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

Для бизнеса это означает: пока рано считать, что «ничего регулировать не будут». Но можно предположить, что регулирование будет менее механическим и больше ориентированным на риск.

Почему фокус на крупных ИИ-системах важен для бизнеса

В сообщении отдельно сказано, что закон сосредоточен на крупных ИИ-системах. Это ключевая формулировка, хотя без текста законопроекта ее нельзя трактовать юридически точно.

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

Для компании это повод разделить ИИ-использование на несколько уровней:

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

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

Что не стоит делать после такого сигнала

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

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

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

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

Правильная реакция более спокойная: не замораживать внедрения, но переводить их из режима экспериментов в управляемый контур.

Рабочий метод: как подготовиться к регулированию ИИ

Для большинства компаний полезен не большой «ИИ-комитет ради комитета», а короткий операционный контур. Его задача — не запрещать, а знать, где ИИ используется и какие риски возникают.

Начать стоит с инвентаризации. Нужно собрать список инструментов и сценариев: публичные чат-боты, корпоративные ассистенты, генераторы кода, системы аналитики, распознавание документов, автоматизация поддержки, рекомендательные механики, скоринговые или классификационные модели. Важно фиксировать не только название инструмента, но и бизнес-процесс.

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

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

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

Отдельно стоит описать поставщиков. Какие инструменты используются, где хранятся данные, есть ли корпоративный договор, можно ли отключить обучение на пользовательских данных, есть ли журналирование, поддерживается ли администрирование пользователей. Даже если закон не запретит иностранные модели, вопросы поставщика останутся важными для безопасности и комплаенса.

Короткий чеклист для руководителя

Перед тем как расширять использование ИИ в компании, задайте команде один рабочий запрос:

Подготовьте за две недели карту текущего использования ИИ: инструменты, процессы, данные, владельцы, поставщики, риски и меры контроля. Отдельно отметьте сценарии, которые влияют на клиентов, юридически значимые решения или массовые операции.

Минимальный чеклист:

• [ ] Есть список ИИ-инструментов, которые реально используют сотрудники.
• [ ] Для каждого инструмента указан бизнес-процесс, а не только название сервиса.
• [ ] Понятно, какие данные загружаются в модель и какие загружать запрещено.
• [ ] Назначен владелец каждого значимого сценария.
• [ ] Описано, где результат ИИ проверяет человек.
• [ ] Зафиксированы поставщики, условия использования и настройки приватности.
• [ ] Отдельно выделены клиентские, массовые и потенциально критичные сценарии.
• [ ] Есть порядок согласования новых ИИ-инструментов.
• [ ] Сотрудники получили короткую инструкцию: что можно, что нельзя, куда обращаться.
• [ ] Юристы и безопасность понимают, какие процессы нужно пересмотреть после публикации финального текста закона.

Такой чеклист не требует ждать осени 2026 года. Он полезен уже сейчас, потому что снижает хаос в использовании ИИ и помогает быстро адаптироваться, когда появится точный текст норм.

Что отслеживать до вступления норм в силу

Если сроки из сообщения подтвердятся, у бизнеса есть время до осени 2026 года. Но это время лучше использовать не для ожидания, а для постепенной подготовки.

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

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

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

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

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

Практический вывод простой: новая версия законопроекта, по доступному описанию, выглядит менее запретительной и более отраслевой. Но зрелая компания не делает ставку на отсутствие запретов. Она строит понятный контур применения ИИ, чтобы использовать инструменты быстрее, безопаснее и с меньшими затратами на будущую адаптацию.

Источники

• Telegram-сигнал ONFF Journal