- 1Документ № 3-МР от 16 июня 2026 года — методические рекомендации. Его следует отличать от обязательных требований, применимых к конкретной организации и процессу.
- 2Проверка охватывает данные, модель, инструменты, внешнего поставщика и рабочий процесс. Фильтр запросов не заменяет ограничения полномочий и управление доступом.
- 3Каждой значимой угрозе нужна проверяемая мера, ответственный и порядок реакции. Контроль должен работать после изменения модели и при сбое внешнего сервиса.
Правовые выводы проверены и актуализированы 3 октября 2026 года. Примеры условные; рекомендации по организации работы отделены от обязательных требований.
Определите статус документа и границы проекта
Банк России выпустил методические рекомендации № 3-МР от 16.06.2026 по информационной безопасности при разработке и применении ИИ на финансовом рынке. Документ описывает подходы к рискам, модели угроз, мерам защиты и внешним сервисам. Его рекомендательная форма не превращает каждый пункт в отдельную обязательную норму.
Одновременно организация должна выполнять применимые обязательные требования к своим системам, данным и операциям. Поэтому проверка начинается с границ: кто использует ИИ, в каком процессе, какие сведения обрабатываются и какие действия возможны. Для поставщика финансового сервиса важны также требования заказчика и принятые договорные обязательства.
В рабочей карте удобно различать три основания меры: обязательное требование, условие договора и рекомендация, которую организация решила принять. Тогда внутренний документ не будет ссылаться на несуществующую обязанность, а команда сможет объяснить, почему конкретная защита выбрана и как её проверять.
Проверяйте систему, а не только название модели
Одна и та же модель может помогать сотруднику с черновиком и иметь доступ к исполнению операций. Риск определяется не брендом нейросети, а данными, связями и полномочиями. Для проверки нужна схема: входной запрос, внешние и внутренние источники, обработка, вызываемые инструменты и результат, который получает человек или другая система.
Укажите доступные учётные записи, роли и ограничения. Если модель предлагает действие, выясните, какой компонент его проверяет и исполняет. Недостаточно записать в инструкции «не выполняй опасные операции», когда технический доступ позволяет их вызвать. Запрет должен подтверждаться работой контролируемого механизма.
Полезно пройти по одному реальному сценарию от входа до результата. Это часто выявляет забытое хранилище, общую учётную запись или передачу данных подрядчику. Схема, которая не отражает работающую версию продукта, создаёт видимость проверки вместо основания для решения.
Составьте модель угроз для своего сценария
Банк России рекомендует организациям подготовить собственную модель угроз и политику безопасности ИИ. В рекомендациях рассматриваются, среди прочего, манипуляция поведением модели, искажение обучающих данных, раскрытие информации и подмена компонентов. Перечень используют для оценки применительно к конкретной системе.
Условный пример: помощник читает полученный документ, в котором размещены инструкции отправить клиентские данные внешнему адресату. Проверять нужно не только распознавание такого текста моделью. Важны право выполнить отправку, допустимый получатель и отдельная проверка параметров действия. Такой сценарий помогает связать угрозу с реальными полномочиями.
Для каждой актуальной угрозы определите последствия, способ предотвращения, признаки обнаружения и действия при реализации. Не все атаки одинаково существенны для каждого продукта. Если система не имеет доступа к исполнению платежей, проверка вымышленного платёжного сценария не должна вытеснять её действительные риски утечки документов.
Участие человека должно менять результат
Пункт 2.5 рекомендаций касается автоматических операций в критически важных процессах при высокой оценке рисков безопасности. Он рекомендует проверку результатов человеком с возможностью их изменить. Поэтому участие сотрудника нельзя свести к уведомлению после события, на которое уже невозможно повлиять.
Конкретную точку проверки выбирают по процессу. Для необратимого действия полезно оценить необходимость подтверждения до исполнения; это решение должно учитывать обязательные правила операции и оценку риска. Не следует утверждать, что документ требует ручного согласования каждого действия ИИ независимо от условий.
Сотрудник должен видеть достаточно информации для содержательной проверки, иметь возможность отклонить предложение и понимать последующий маршрут. Испытание проходит не только штатное подтверждение: проверьте отказ, истечение времени, повтор запроса и недоступность ответственного. Иначе автоматизация может обойти контроль при первой нестандартной ситуации.
Оцените поставщика и изменение сервиса
Для внешнего решения установите, где обрабатываются данные, кто имеет доступ, какие компоненты привлекаются и можно ли восстановить события инцидента. Запросите сведения, необходимые для вашего сценария, а не универсальную анкету без связи с рисками. Обещание «корпоративная безопасность» следует проверять по договору и техническим условиям.
Участие поставщика в поиске уязвимостей — полезный сигнал, но не гарантия пригодности сервиса. Важнее понять, как уязвимость исправляется, кто уведомляет заказчика и какие изменения могут затронуть его работу. Отдельно проверяют использование запросов для обучения и условия привлечения других исполнителей.
После смены модели, источников данных или набора инструментов прежняя проверка может перестать описывать продукт. Определите изменения, требующие повторной оценки, и порядок безопасного возврата к предыдущей версии. Уведомление провайдера полезно, когда у организации есть ответственный и время отреагировать до изменения критичного процесса.
Подготовьте сценарий остановки и расследования
При утечке или неправильном действии нужно знать, кто отключает функцию, ограничивает доступ и сохраняет необходимые сведения. Простого сообщения «обратитесь к поставщику» недостаточно, если организация продолжает обслуживать клиентов через неисправный компонент. План должен включать доступный резервный процесс.
Проверяйте записи событий на конкретной ситуации: можно ли установить версию компонента, существенные действия и затронутые данные? Одновременно контролируйте доступ к журналам, объём и сроки хранения. Диалог с моделью может содержать защищаемую информацию, поэтому сами логи являются объектом проверки.
В учебном сценарии разделите техническое расследование, оценку последствий для клиентов и договорные действия с исполнителем. Применимые обязанности по уведомлению определяются по характеру события и нормам, а не по общему шаблону «инцидент ИИ». Нужен способ быстро собрать факты для такой оценки.
Сведите меры в проверяемый план
Результат первичной работы может быть компактным: система, значимая угроза, мера, ответственный, способ проверки и срок. К каждой мере приложите доступное подтверждение — настройку, испытание, документ или запись события. Сам факт утверждения политики не показывает, что ограничение исполняется.
Начните с наиболее критичных сценариев и внешних зависимостей. Затем проверьте согласованность работы юристов, разработки и информационной безопасности: договор обещает одно, схема показывает другое, а настройка выполняет третье. Хорошая проверка устраняет эти расхождения и даёт организации возможность объяснить, почему выбранный способ применения ИИ допустим.