Стандарт для ПО с искусственным интеллектом. Что банку спрашивать у поставщика уже сейчас

Стандарт для ПО с искусственным интеллектом. Что банку спрашивать у поставщика уже сейчас

До 7 сентября разработчики принимают замечания к первой редакции проекта ГОСТ Р «Защита информации. Разработка безопасного программного обеспечения, реализующего технологии искусственного интеллекта. Общие требования». Свои я отправил 19 августа, одиннадцать замечаний по форме приложения Б ГОСТ Р 1.2-2020. Документ готовят ФСТЭК России, Институт системного программирования РАН, Сбербанк и ГНИИИ ПТЗИ ФСТЭК России по плану работы Технического комитета 362 на 2026 год. Банк, который сам модели не обучает, обычно считает тему чужой. Но через год на этом языке пойдет разговор с поставщиками.

Что регулирует стандарт

Проект дополняет ГОСТ Р 56939-2024, базовый стандарт по разработке безопасного ПО. Самое полезное в нем — это рамка. Программное обеспечение с искусственным интеллектом описано как связка компонентов. Это модель с ее весами, ПО взаимодействия модели с остальной системой, среда исполнения, средства расширения функциональности вроде подключения внешних источников данных и вызова сторонних инструментов.

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

Почему это не абстракция

Август 2025 года, история под названием s1ngularity. Через уязвимый процесс сборки был украден токен публикации, и в открытый репозиторий попали зараженные версии популярных пакетов. Установочный скрипт проверял, стоят ли на машине разработчика консольные ИИ-агенты, и, если находил, поручал агенту поискать файлы с переменными окружения, ключи и криптокошельки. Агентов запускали с флагами автоподтверждения, так что человек ничего не подтверждал. Раскрылись тысячи секретов сотен организаций. Своего инструмента сбора данных атакующим не потребовалось. Сгодился легитимный агент жертвы с уже выданными правами.

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

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

Что я предложил поправить

Первое замечание про терминологию. Определения в проекте, включая базовое понятие системы искусственного интеллекта, даны по проекту федерального закона об ИИ. В Государственную Думу он не внесен, формулировки могут поменяться, а стандарт после утверждения будет жить своей жизнью. Предложил опереться на действующие ГОСТ Р 71476-2024 и ГОСТ Р 59277-2020.

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

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

Четвертое формальное, но показательное: в библиографии Национальная стратегия развития искусственного интеллекта указана как действующая до 2023 года, хотя пояснительная записка к тому же проекту говорит про 2030 год. Остальные семь замечаний редакционные: пропущенный пункт, задвоенный номер в перечислении, опечатка в определении, перепутанные обозначения таблиц и рисунка.

Где границы применимости

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

Положение Банка России 683-П уже требует, чтобы прикладное ПО, которое банк раздает клиентам, и ПО, обрабатывающее защищаемую информацию при приеме сообщений через Интернет, было сертифицировано в системе ФСТЭК России либо прошло анализ уязвимостей по четвертому уровню доверия. Отдельно то же Положение обязывает банк раз в два года проводить оценку соответствия защиты информации силами организации с лицензией ФСТЭК. Ни то, ни другое требование не касается способа написания кода. Как только внутри программы появляется модель, вопрос о том, что именно оценивали и на какой версии весов, становится содержательным.

Дальше два сигнала от регуляторов. Приказ ФСТЭК России №117 о защите информации в государственных информационных системах вступил в силу 1 марта 2026 года. В нем впервые появились положения о применении технологий искусственного интеллекта и требования к работе с подрядными организациями: подрядчик обязан соблюдать политику безопасности заказчика. С 1 апреля 2026 года введен предварительный стандарт ПНСТ 1046-2026 про искусственный интеллект в критической информационной инфраструктуре. Банку ни один из документов не адресован, но направление движения по ним видно.

Сам по себе новый ГОСТ банку ничего не предпишет. До банка он дойдет через договор с поставщиком и через отраслевые требования, которые на него сошлются.

Что спрашивать у поставщика уже сейчас

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

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

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

В каком режиме работают ИИ-агенты в сборке поставщика и разрешено ли автоподтверждение их действий. История s1ngularity выросла целиком из этого флага.

Используются ли сторонние навыки, расширения и внешние сервисы подключения инструментов, кто их проверяет и фиксируются ли версии описаний. Каталоги таких дополнений уже стали каналом поставки вредоносного кода. С февраля по май 2026 года исследователи Unit 42 нашли в одном из них пять вредоносных пакетов, два из которых устанавливали программу для кражи данных.

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

Замечания принимает разработчик, до 7 сентября. Подать их может любой специалист, право физического лица участвовать в обсуждении проекта национального стандарта подтвердил секретариат технического комитета 362 со ссылкой на пункт 5.2.2 ГОСТ Р 1.2-2020 и пункт 5 статьи 4 закона о стандартизации. Мои одиннадцать замечаний это работа на два вечера с открытым текстом проекта. Стандарт, по которому будут проверять поставщиков банковского софта, стоит прочитать сейчас, до утверждения.