Методические рекомендации Банка России по безопасности ИИ на финрынке (№ 3-МР): обзор и что делать на практике

Привет, уважаемые эксперты!

На связи Альбина Аскерова, руководитель направления по взаимодействию с регуляторами Swordfish Security. В прошлом обзоре мы разбирали методику ФСТЭК к приказу № 117, а в частности требования к безопасности ИИ в государственных системах и на объектах КИИ. Сегодня рассмотрим Методические рекомендации Банка России от 16.06.2026 № 3-МР по обеспечению информационной безопасности при разработке и применении ИИ на финансовом рынке.

Статус документа — методические рекомендации. «Рекомендательный» статус — это, скорее, объявленное направление движения, чем свобода ничего не делать. Мягкая форма часто превращается в ожидаемую практику завтра, а иногда — в положение нормативного акта. Поэтому читать документ стоит уже сейчас, причём не как «что нас заставят», а как «куда идёт регулятор и на что он смотрит».

Сегодня пройдёмся по такой карте: для кого документ и как он ложится на привычную регуляторику финсектора, что в нём принципиально нового, как устроены модель угроз и меры защиты, отдельно — про цепочку поставок и open source и про политику ИБ. А в финале — самое главное: что со всем этим делать на практике, по шагам. 

Для кого это и как соотносится с «привычной» регуляторикой финсектора

3-МР адресован широкому кругу участников рынка: кредитным организациям, филиалам иностранных банков в РФ, некредитным финансовым организациям, лицам, оказывающим профессиональные услуги на финрынке, и субъектам национальной платёжной системы (далее по тексту — «организации»).

Важная привязка: документ опирается на Кодекс этики в сфере разработки и применения ИИ на финансовом рынке (информационное письмо Банка России от 09.07.2025 № ИН-016-13/91). То есть 3-МР — это уже вторая ступень: этика задала принципы, рекомендации переводят их в плоскость ИБ.

ИИ здесь не выводится в отдельную «вселенную». Документ аккуратно ложится на тот фундамент, который у финсектора уже есть, — управление рисками, операционная надёжность, аутсорсинг, защита ПДн. Безопасность ИИ не отменяет этого фундамента, а достраивается поверх него. Такой же подход и у ФСТЭК. 

Что в документе принципиально нового

Пробежимся по тому, что отличает 3-МР от того, что мы видели раньше.

1. Регулятор закрепил «ИИшную» терминологию на своём уровне.

В главе 1 появляются определения, которые раньше жили в основном в экспертной среде и стандартах: галлюцинации ИИ, дрейф данных, прямое и непрямое внедрение запроса, «отравленный» набор данных. Термины «система ИИ», «объяснимость», «предсказуемость», «надёжность», «качество» берутся из национальных стандартов (ГОСТ Р 71476–2024, ГОСТ Р 59898–2021). Когда регулятор фиксирует термины, в дальнейшем он, скорее всего, будет оперировать ими в проверках и требованиях.

2. Риски описаны через шесть категорий. Глава 2 предлагает организациям учитывать угрозы безопасности ИИ: риски управления данными («отравленные»/неактуальные датасеты), нарушение конфиденциальности данных, нарушение функционирования модели (в т. ч. галлюцинации и дрейф), недостаточная объяснимость/предсказуемость, риски привлечения поставщиков и open source, риски операционной надёжности. И, что ценно, сразу перечислены возможные последствия: от нарушения прав граждан и убытков до угрозы стабильности финансовой системы.

3. Человек в контуре для критичных автоматических процессов. Отдельно выделю пункт 2.5. Если ИИ применяется для операций в автоматическом режиме в критически важных процессах (пример регулятора — платёжные процессы, учётные системы), и риски оценены как высокие, рекомендуется реализовать валидацию результатов человеком с возможностью их изменения. Чем выше цена ошибки, тем меньше поводов отдавать финальное решение модели без присмотра.

4. То, чего не хватало методике ФСТЭК, здесь появилось. В майском обзоре я отмечала: в методике ФСТЭК и на странице БДУ качество, объяснимость и борьба с «галлюцинациями» вынесены за скобки. Банк России этот пробел частично закрывает — недостаточная объяснимость и предсказуемость прямо названы риском, а в политике ИБ (см. ниже) появляется требование механизмов интерпретации поведения модели.

Модель угроз и меры защиты: как это устроено

Глава 3 — методическое ядро документа. Логика знакомая: сначала угрозы потом меры, пропорциональные рискам.

• Разрабатывать модель угроз рекомендуется по Методике оценки угроз безопасности информации ФСТЭК России (05.02.2021), то есть финрегулятор не изобретает свой подход и опирается на уже существующий методический аппарат. Это удобно, ведь у большинства организаций методика уже отработана.

• Жизненный цикл ИИ‑системы разбит на четыре этапа: подготовка данных → разработка → обучение и тестирование → функционирование.

• Перечислены специфичные для ИИ угрозы (обход средств ИИ, «отравление» обучающих данных, раскрытие информации о модели, хищение датасетов, модификация и подмена модели, «отказ в обслуживании», манипуляция поведением) и способы их реализации — фаззинг, бэкдоры, извлечение данных, вредоносные «инъекции», атака типа «губка», состязательные атаки.

• Приложения 1–4 — это, по сути, готовый рабочий материал: тактики и техники (в логике, близкой к MITRE ATLAS), матрица «этап ЖЦ × угроза», матрица «угроза × способ реализации × мера защиты» и каталог из 21 меры защиты, разложенный по четырём подпроцессам «Безопасность и защита данных».

Ключевой принцип, который прослеживается в документе: пропорциональность (п. 3.8). Меры защиты должны соответствовать выявленным рискам и масштабу последствий. Не нужно защищать всё и одинаково — нужно защищать соразмерно.

Цепочка поставок и open source: самая «жизненная» глава

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

• Работу с поставщиками выстраивать по логике аутсорсинга (СТО БР ИББС-1.4–2018), а доверие к внешним данным и моделям обеспечивать по ГОСТ Р 59276–2020 («Способы обеспечения доверия»).

• Разработать собственную методику оценки доверия к данным, моделям и open‑source‑компонентам. Факторы оценки перечислены подробно: участие модели в Bug Bounty, наличие спецификации ПО (по сути — SBOM/MLBOM), отчёты об анализе уязвимостей и пентестах, подтверждение процессов безопасной разработки, отслеживание источников данных (provenance), собственная оценка рисков.

• Целостность внешних данных и моделей контролировать средствами, прошедшими оценку соответствия в системе сертификации ФСТЭК.

• Отдельно — про данные: если модель обучает поставщик, ему рекомендуется передавать «очищенные», синтетические или обезличенные данные. Здесь мы снова возвращаемся к фундаменту ПДн и 152-ФЗ: минимизация и обезличивание данных до передачи наружу — это база, которая никуда не делась.

• И в договор с поставщиком — положения об ответственности за нарушения ИБ и обязанность своевременно информировать об уязвимостях и инцидентах.

Политика ИБ для ИИ: на что обратить внимание заранее

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

Из 18 положений приложения 5 отмечу те, что чаще всего вызывают затруднения:

• Red team‑тестирование как часть киберустойчивости.

• Минимальные ПДн — использовать в обучении и применении только те персональные данные, на обработку которых есть согласие, и в минимально необходимом объёме.

• Маркировка выходных данных ИИ.

• Сокращение сведений о моделях в открытых источниках (репозитории, доклады, статьи) — чтобы не облегчать подготовку атак.

• План действий в нештатных ситуациях, включая аварийную остановку системы ИИ.

• Периодический пересмотр политики с учётом развития технологий и новых тактик нарушителей.

Что с этим делать: практика по этапам

Теперь то, ради чего мы здесь — практическая последовательность. Она рекомендательная, как и сам документ, но выстроена так, чтобы двигаться от «навести порядок» к «системно управлять».

Этап 0. Признать реальность и инвентаризировать

Как и в случае с ФСТЭК, начинается всё с честной инвентаризации. Заведите реестр ИИ‑компонентов и по каждому зафиксируйте:

• где используется ИИ и кто владелец сервиса;

• тип (LLM, компьютерное зрение, рекомендательные системы, агенты);

• среду (разработка/эксплуатация); какие данные обрабатываются и откуда они;

• входные и выходные модели и кто контролирует их веса;

• каналы доступа пользователей;

• и отдельным флагом — участвует ли ИИ в критичных автоматических процессах (платежи, учётные операции).

Этап 1. Оценить риски по шести категориям

Прогоните каждый ИИ‑сервис по шести категориям риска из главы 2 и спроецируйте угрозы на четыре этапа ЖЦ. На выходе — короткий список актуальных рисков для каждого конкретного внедрения, а не абстрактное «ИИ опасен».

Этап 2. Построить модель угроз

Используйте методику оценки угроз ФСТЭК и приложения 1–3 как рабочий материал. Учтите и внешнего, и внутреннего нарушителя, и характеристики инфраструктуры, на которой живёт система ИИ. Хорошая модель угроз — основа для выбора соразмерных мер.

Этап 3. Внедрять меры по подпроцессам (данные → разработка → обучение → эксплуатация)

Практики, которые дают наибольший эффект на старте:

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

• Разработка: анализ уязвимостей моделей, кода и компонентов (по внешним источникам, включая БДУ ФСТЭК); контроль целостности весов и кода; версионирование и документирование изменений.

• Обучение и тестирование: тестирование модели на предмет «отравления»; методы повышения устойчивости к состязательным атакам (состязательное обучение, ансамблевые методы); тестирование на проникновение с использованием ИИ‑специфичных сценариев; периодическое дообучение на проверенных данных с фиксацией версий.

• Эксплуатация: фильтрация и очистка аномалий во входных/выходных данных; регистрация и контроль пар «запрос‑ответ»; ограничение частоты, объёма и количества запросов к модели; мониторинг показателей штатного функционирования и детектирование дрейфа.

Этап 4. Поставить человека в контур критичных процессов

Для операций в автоматическом режиме с высоким риском (в первую очередь платёжные и учётные процессы) предусмотрите валидацию результатов человеком с возможностью их корректировки. Это прямая рекомендация регулятора и одновременно здравый смысл: чем выше цена ошибки, тем меньше автономии у модели.

Этап 5. Навести порядок в цепочке поставок

Разработайте методику оценки доверия к внешним данным, моделям и open‑source‑компонентам; фиксируйте происхождение (provenance) и ведите учёт компонентов (спецификация ПО, хеш‑суммы, лицензии); передавайте поставщикам только очищенные, обезличенные или синтетические данные; закрепите ответственность и порядок уведомления об инцидентах в договоре.

Этап 6. Оформить политику и запустить цикл пересмотра

Параллельно соберите всё перечисленное в политику ИБ для ИИ (или дополните существующую), назначьте ответственного, добавьте обучение персонала, регистрацию и реагирование на инциденты, план аварийной остановки и периодический пересмотр.

Финальные акценты

1. Статус — рекомендательный, направление — вполне определённое. Не стоит откладывать «до обязаловки»: инвентаризация, оценка рисков и модель угроз пригодятся в любом сценарии, а сделать их «задним числом» под проверку куда болезненнее.

2. Соразмерность. Документ прямо говорит о пропорциональности мер. Начните с того, что закрывает большинство рисков: изоляция и контроль данных, фильтрация ввода/вывода, человек в контуре для критичных операций.

3. ИИ‑безопасность встраивается, а не прикручивается. 3-МР логично продолжает подход Secure‑by‑Design: защита закладывается на каждом этапе ЖЦ, от подготовки данных до эксплуатации.

4. Фундамент безопасность данных. Обезличивание, минимизация, контроль передаваемых в модель данных это основа, на которой строится всё остальное.