Человек копирует фрагмент проприетарного кода, вставляет его в веб-интерфейс внешнего сервиса и получает подсказку. Никто не узнал, никто не зафиксировал, но код уже покинул защищенный периметр. По разным отраслевым оценкам 2025 года, так поступает более половины разработчиков в российских закрытых контурах: госкомпаниях, финансовом секторе, объектах критической информационной инфраструктуры (КИИ) и оборонно-промышленном комплексе.
Проблема не в желании нарушить правила. До недавнего времени современные инструменты разработки на базе ИИ были доступны преимущественно «по ту сторону» контролируемого контура. А работать без них в последние пару лет — все равно что пытаться конкурировать с командами, у которых есть мощный рычаг ускорения.
В статье Владимир Нелюб, директор по науке и ИИ, член правления ПАО «Группа Астра», управляющий партнер «Астра ИИ», д.т.н., профессор, разбирает, почему «теневой ИИ» стал системной проблемой, какие риски он несет для бизнеса и руководителей и почему простого запрета уже недостаточно. И главное — что изменилось за последнее время и почему, чтобы получить реальный эффект от новых инструментов, недостаточно просто их установить.
Почему разработчики выводят код за периметр
Внешние сервисы вроде GitHub Copilot, Cursor или Claude дают заметный прирост скорости на рутинных задачах. По данным McKinsey (2023), ускорение на генерации кода может достигать 35–45%, при документировании — 45–50%. В эксперименте Microsoft Research и GitHub изолированная задача решалась на 55,8% быстрее.
Когда в закрытом контуре такого инструмента нет, а в других компаниях или даже соседних отделах он есть, люди находят обходные пути: личные аккаунты через VPN, копирование кода в веб-версии чат-моделей, передача фрагментов архитектуры и схем данных через мессенджеры. Служба безопасности не получает ни логов, ни аудит-следа. Вся активность остается невидимой для регулятора.
Риски: от штрафов до уголовных дел
Законодательство ужесточилось. С 30 мая 2025 года действуют поправки в ФЗ № 420-ФЗ и № 421-ФЗ: за утечку персональных данных организациям грозит штраф от 3 до 5 млн рублей, за повторные нарушения — оборотные штрафы от 1 до 3% годовой выручки (но не менее 20 млн и не более 500 млн руб.).
Но есть риски серьезнее — по линии КИИ. Передача охраняемой информации за пределы периметра нарушает требования по защите значимых объектов критической инфраструктуры. Статья 274.1 УК РФ предусматривает уголовную ответственность для тех, кто обязан соблюдать правила эксплуатации и доступа, если нарушение повлекло вред КИИ. Сам по себе вынос такого кода во внешний сервис уже создает нарушение требований регулятора и почву для претензий. Доказать, что данные не были использованы третьими лицами, практически невозможно.
Операционные последствия: не только безопасность
Тот, кто легально и безопасно использует современные ИИ-инструменты, работает быстрее. Разрыв в скорости выполнения рутинных задач может составлять 1,5–2 раза. В закрытых контурах это приводит к сдвигу сроков, текучке кадров и накоплению технического долга.
Запреты в чистом виде не работают. Компании, которые пытались полностью заблокировать внешние ИИ-сервисы, через несколько месяцев возвращаются к исходному уровню обходных подключений — или даже превышают его.
Что изменилось в 2025–2026 годах
До 2025 года ИИ в разработке использовали в основном как IDE-плагины и ассистенты (GitHub Copilot и аналоги). Они работали внутри существующих процессов, давали ограниченный контекст и приносили умеренный эффект.
Затем произошел качественный сдвиг. Появились полноценные агентные системы — terminal- и CLI-агенты. Они не просто генерируют код. Они читают весь репозиторий вместе с внутренними документами компании, понимают архитектуру проекта, составляют детальный план действий для согласования с разработчиком, запускают тесты, делегируют подзадачи специализированным агентам и работают в режиме планирования перед исполнением.
Ключевой момент: максимальный эффект такие системы дают только внутри инфраструктуры с доступом к закрытому коду и данным организации. Внешние облачные сервисы или плагины без безопасного доступа к полному контексту проекта не могут раскрыть свой потенциал.
Почему просто установить ИИ-инструмент недостаточно
Согласно отчету DevOps Research and Assessment (DORA) 2025, ИИ выступает усилителем. Он многократно усиливает сильные стороны зрелых команд и усугубляет проблемы слабых.
В 2025 году в эксперименте METR опытные инженеры на знакомых им репозиториях с ИИ тратили на задачи на 19% больше времени, чем без него — при том что сами оценивали свою работу как ускорившуюся примерно на 20%. GitClear фиксирует рост дублирования и «оттока» кода при массовом использовании ассистентов. USENIX Security 2025 указывает на риск «галлюцинаций» несуществующих программных зависимостей.
Каким должен быть безопасный ИИ-инструмент для закрытого контура
Для эффективной и безопасной работы в закрытом контуре промышленный ИИ-инструмент должен:
- обеспечивать полную изоляцию модели и данных внутри периметра организации (включая поддержку режимов без выхода в Интернет);
- фиксировать каждый запрос с возможностью передачи в корпоративную систему управления информацией и событиями безопасности (SIEM);
- содержать встроенные правила блокировки опасных команд, предлагать режим планирования, когда план действий сначала показывается на согласование, а уже потом выполняется;
- обладать настоящей «агентностью» — способностью выполнять многошаговые сценарии с доступом к полному контексту проекта;
- интегрироваться с отечественным стеком.
Эти требования опираются на действующую нормативную базу, которую важно не смешивать. Защиту информации в государственных информационных системах (ГИС) регулирует Приказ ФСТЭК России от 11.04.2025 № 117, который зарегистрирован в Минюсте 16.06.2025, вступает в силу с 01.03.2026 и заменяет ряд предыдущих приказов. Защиту значимых объектов КИИ — Федеральный закон № 187-ФЗ и Приказ ФСТЭК № 239. Вопросы защиты информации при использовании ИИ затрагивает Методический документ ФСТЭК России от 12.04.2026 (раздел 3.18 «Обеспечение защиты информации при использовании искусственного интеллекта (ИИ)».
«Искусственный интеллект — это мощный усилитель. Он многократно ускоряет сильные команды и процессы, но с такой же силой усугубляет слабости и хаос. Простое добавление агентных инструментов в существующие процессы разработки почти всегда приводит к разочарованию. Настоящий эффект появляется только тогда, когда организация готова перестроить саму методологию разработки: ввести подход, ориентированный на намерения, файлы инструкций проекта, тесты-шлюзы внутри цикла агента и зрелые практики управления и контроля. Без этого мы рискуем получить больше дублирующегося кода, скрытых уязвимостей и рост технического долга. Важно не только измерять скорость, но и жестко контролировать качество на каждом этапе».
Вадим Тынченко, доктор технических наук, профессор кафедры «Технологии искусственного интеллекта» МГТУ им. Н.Э. Баумана, главный научный сотрудник НОЦ «ФНС России и МГТУ им. Н.Э. Баумана»
Ситуация, когда более половины инженеров в закрытых контурах вынуждены использовать внешние ИИ-сервисы нелегально, не может сохраняться долго. Она сопровождается юридическими рисками (вплоть до уголовной ответственности), операционными потерями и оттоком кадров. Простые запреты не решают проблему, а лишь прячут ее в тень.
Самостоятельное развертывание отчуждаемых моделей с открытым кодом и агентных фреймворков — реальный путь, дающий полный контроль над данными, но требующий собственной команды полного цикла разработки и сопровождения, включая дообучение, ИБ-сопровождение и выстраивание системы управления. Именно поэтому многие выбирают готовое проприетарное решение, сертифицированное под работу в закрытом контуре.
Единственный системный выход — внедрение промышленных агентных систем, спроектированных для работы внутри защищенного периметра с доступом к закрытому коду и данным, с полным аудитом и контролем операций. При этом важно понимать, что максимальный эффект достигается не просто при установке нового инструмента, но при соответствующей перестройке процессов разработки. Мы продолжим цикл статей по этой теме и в будущем разберем методологию такого внедрения и конкретные сценарии практического применения.