Николай Лобанов

Предмет у 243-ФЗ узкий: разработка, внедрение и применение больших фундаментальных моделей. По статье 3 этого закона, «большая фундаментальная модель» – это программа не менее чем с 1 млрд параметров, применяемая для большого количества различных задач и служащая основой для создания и доработки других видов программного обеспечения. Дообученная отраслевая модель, классификатор документов или скоринговая модель под это определение не попадают.

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

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

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

Чего в законе не появилось

Мартовский проект Минцифры, который обсуждался на regulation.gov.ru весной, был устроен иначе: доверенные модели с сертификацией и реестром, привязка требований к объектам критической информационной инфраструктуры и государственным системам, информирование гражданина о применении ИИ при принятии решения, распределение ответственности между разработчиком модели, оператором системы и пользователем. Его обсуждение закончилось 15 апреля.

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

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

Сроки стоит отметить отдельно, они не очевидны из пересказов. Сам закон действует с 1 сентября 2026 года. Названные полномочия правительства, конструкция статусов моделей, обязанности разработчиков, маркировка и правила по результатам интеллектуальной деятельности вступают в силу с 1 марта 2027 года. И есть длинная переходная норма: до 1 сентября 2032 года требование применять исключительно суверенные и национальные модели не распространяется на информационные системы, где такие модели созданы или эксплуатируются на день вступления этой нормы в силу, то есть на 1 марта 2027 года, при условии, что данные обрабатываются и хранятся в России. Система, запущенная до этой даты, живет по прежним правилам еще пять с половиной лет.

Где на самом деле пишутся требования к агентам

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

Сразу оговоримся о его статусе. Это первая редакция проекта, документ не утвержден и не применяется, а предварительный национальный стандарт по своей природе добровольный. Но добровольность работает своеобразно: такие документы становятся обязательными через договор с крупным заказчиком и через требования при закупке. Вопрос «Соответствует ли ваш агент?» появится в тендерной документации раньше, чем в проверке регулятора.

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

Мандат вместо доступа

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

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

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

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

Реестр агентов и описание возможностей

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

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

Для ИТ-директора это знакомая задача на новом объекте: агент – такой же объект учета, как сервер или сервисная запись, и без реестра остальные требования не выполнить.

Необратимые действия и конфликт инструкций

Два требования проекта отвечают на то, что беспокоит бизнес больше всего.

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

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

Это защита от инъекций в промпт, изложенная языком стандарта: инструкция, пришедшая агенту в тексте документа, письма или тикета, проверяется против мандата, а не исполняется потому, что сформулирована убедительно.

Аудит и сквозная трассировка

Требования к журналированию – детальные. Каждое взаимодействие сопровождается записью минимум из восьми атрибутов: идентификатор агента-инициатора и его оператора, идентификатор агента-исполнителя и его оператора, тип операции, идентификатор мандата, временные метки и результат. Записи защищаются от изменения и удаления.

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

Что закладывать в архитектуру уже сейчас

Ни один пункт ниже не требует ждать вступления норм в силу, и все они превратятся в готовое соответствие, когда требования появятся.

• Реестр агентов и моделей. Какая модель, чья, где работает, кто владелец процесса, кто может ее подменить. Без этого остальное невыполнимо.
• Мандат вместо учетной записи. Агент получает ограниченный набор операций и ресурсов со сроком действия и возможностью немедленного отзыва. Пароли и долгоживущие ключи агенту не выдаются.
• Классификатор необратимых действий, утвержденный бизнесом. Платеж, удаление, изменение прав, отправка данных наружу. Для этих классов операций разрешение выдается отдельно и осознанно, а не выписывается агенту вместе со всеми остальными правами.
• Журналы с привязкой к принципалу и сквозная трассировка цепочки вызовов.
• Проверка входящих инструкций против мандата и безопасный отказ при неоднозначности.
• Учет состава компонентов агента, включая сторонние библиотеки и внешние инструменты.
• Сценарии «агента обманули» и «модель недоступна» в киберучениях. Второй важнее, чем кажется: если процесс завязан на модель, ее недоступность останавливает процесс.

Что записать в договор с поставщиком

Самый недооцененный риск при работе с внешней моделью – не атака, а смена версии на стороне поставщика. Решения в бою меняются, ваш код при этом не менялся, а объясняться придется вам.

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

Сроки, к которым стоит готовиться

Ключевая дата – 1 марта 2027 года. К этому числу вступают в силу отложенные нормы закона, включая полномочия правительства устанавливать отраслевые требования. К той же дате ФСТЭК планирует ввести изменения в требования к защите информации в государственных системах в части ИИ, обсуждение которых закончилось 8 сентября. Параллельно в техническом комитете 362 идет проект стандарта по безопасной разработке ПО с технологиями ИИ.

Следить стоит за подзаконными актами: порядок присвоения статусов моделей, перечень случаев обязательного применения суверенных моделей, отраслевые требования по предотвращению рисков. Все они пройдут публичное обсуждение на regulation.gov.ru, и на этом этапе на них еще можно влиять. Как показывает практика, конкретная текстовая поправка с формулировкой «изложить в следующей редакции» имеет заметно больше шансов, чем общая позиция о том, что проект неудачен.

Компании, которая внедряет ИИ-агентов сегодня, можно посоветовать исходить из простого предположения: требования уже сформулированы и лежат в проектах стандартов. Удостоверение с ограниченным сроком, минимальные права, запрет расширять полномочия по цепочке, подтверждение необратимых действий, журнал с привязкой к тому, от чьего имени действовал агент – это управление доступом, перенесенное на субъект, который действует сам и быстро. Кто выстроит это в 2026 году, к моменту вступления требований покажет работающий процесс. Кто не выстроит, будет искать по своей инфраструктуре агентов, о существовании которых не знает, в срок, назначенный не им.

Автор – Николай Лобанов, независимый эксперт по информационной безопасности и защите критической информационной инфраструктуры, магистрант ИПНБ РАНХиГС