Минцифры не будет вводить барьеры для ИИ-кода

8 минут назад

© RUБЕЖ Выступление Максута Шадаева на форуме CNews

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

Шадаев отметил, что Минцифры не планирует создавать отдельные барьеры для ПО, разработанного с применением ИИ.

«Наша задача, чтобы конечный код всё-таки контролировался, пусть и значимая часть была сгенерирована, но за конечный продукт отвечала понятная компания и могла его развивать, внедрять», — заявил министр.

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

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

Тестирование и безопасность становятся узким местом

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

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

Переход от разовых проверок к непрерывному контролю на всём жизненном цикле разработки становится для таких организаций практической необходимостью. Как ранее писал RUБЕЖ, российский рынок безопасной разработки ПО по итогам 2025 года достиг 10 млрд рублей, а к 2027 году может вырасти до 60 млрд рублей. В отрасли ожидают, что использование ИИ при написании кода потребует специализированных инструментов аудита.

Доверенное ПО: требования еще согласуются

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

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

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

Проверять нужно не только код, но и с сценарии атак

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

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

Внешние модели требуют контроля данных и доступов

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

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

При внедрении генеративных и агентных систем необходимы ролевые модели доступа, фильтрация и маскирование данных, контроль токенов, интеграция с SIEM и тестирование в изолированных контурах. Не менее важно не допустить теневого использования внешних ИИ-сервисов сотрудниками: полный запрет без управляемой альтернативы может лишь вывести работу с такими инструментами из-под контроля организации. Эти риски и подходы к их снижению RUБЕЖ разбирал в материале: «Безопасность промышленного ИИ: на ИННОПРОМ обсудили риски генеративных и агентных систем».

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

Развитие генеративной разработки совпадает с усложнением цифровых контуров банков и торговли: в них становится больше API, партнёрских интеграций, мобильных приложений и платежных сценариев. Поэтому безопасность кода и процессов его выпуска становится частью общей устойчивости сервисов. О подходах к защите интеграционного контура, API и клиентских приложений банков и торговых компаний RUБЕЖ писал в материале: «Цифровой рубль: эксперты пояснили, как банкам и ритейлу защитить новую платежную инфраструктуру».