16 июня 2026 года Банк России выпустил методические рекомендации № 3-МР о защите информации при разработке и применении искусственного интеллекта (ИИ) финансовыми организациями. Они охватывают информационную безопасность и операционную надёжность. Например, у банка есть процесс, в котором ИИ-модель внешнего поставщика (большая языковая модель, LLM) раскладывает обращения клиентов по темам. Поставщик выпускает новую версию, обращения начинают раскладываться иначе, а в банке об этом никто не знает. Мы прочитали рекомендации целиком, чтобы выяснить, что они предлагают банку в таком случае. Рекомендации описывают проверку безопасности поставщика и советуют следить за поведением ИИ-модели. Как заметить обновление ИИ-модели у сервиса поставщика, в них не поясняется. Мы считаем, что способ заметить такое обновление банку придётся выбирать самому, а начинать стоит с контрольного набора. Контрольный набор - это реальные обращения или документы банка с заранее известными правильными ответами, по которым регулярно проверяется ИИ-модель.
Поводом стала статья «Коммерсанта» от 12 июля. По её сообщению, на форуме о данных и ИИ Data Day в Москве заместитель директора юридического департамента Банка России Екатерина Дёмкина заявила, что использование множеством российских банков одних и тех же глобальных платформ ИИ создаёт значимый риск для стабильности финансовой системы. Какие платформы имеются в виду, в статье не сказано. В той же статье Тимур Аитов, председатель комиссии по финансовой безопасности совета Торгово-промышленной палаты России, описал сценарий, при котором сбой у поставщика или «незаметное изменение параметров на стороне поставщика» приводит к тому, что участники рынка сокращают лимиты (какие именно лимиты и чьи, статья не уточняет). Потери кредитного портфеля при таком сценарии в отдельных сегментах, по его оценке, могут достигать 3-5% за квартал (метод расчёта и базу оценки статья не приводит). К примеру выше ближе всего слова Аитова о незаметном изменении параметров на стороне поставщика (мы толкуем их как обновление ИИ-модели). Если у многих банков поставщик один и тот же, обновление его ИИ-модели меняет поведение сразу многих банков (это наше рассуждение). Генеральный директор компании Morizo (разработчика цифровых сервисов для финансов и электронной коммерции) Денис Царев ожидает в той же статье, что регулирование ИИ в банках «вероятно, коснется» среди прочего «контроля дрейфа модели» (изменения поведения ИИ-модели со временем) и «возможности смены поставщика».
С выхода статьи прошло около трёх месяцев. На 4 октября 2026 года, когда мы проверяли тексты документов, новых рекомендаций Банка России об обновлении ИИ-модели у поставщика в найденных нами материалах нет.
Что рекомендации Банка России № 3-МР говорят о внешних поставщиках ИИ и о поведении ИИ-модели
О внешних поставщиках ИИ рекомендации говорят в главе 5 (п. 5.1-5.7). Рядом стоят положения о поведении самой ИИ-модели. В таблице собраны положения о внешних поставщиках ИИ и о поведении ИИ-модели и показано, что в каждом сказано об обновлении ИИ-модели у поставщика.
| Положение рекомендаций | Что рекомендовано | Что сказано об обновлении ИИ-модели у поставщика |
|---|---|---|
| Пункт 5.1 | Руководствоваться при использовании сервисов ИИ поставщиков стандартом Банка России об аутсорсинге СТО БР ИББС-1.4-2018 | Не сказано. В стандарте об ИИ нет ни слова |
| Пункты 5.2-5.4 (и п. 17 приложения 5) | Разработать собственную методику оценки доверия в отношении информационной безопасности к данным и ИИ-моделям поставщиков. Среди факторов участие ИИ-модели в программе поиска уязвимостей Bug Bounty и регулярные отчёты поставщика об аудитах | Не сказано |
| Пункт 5.5 | Контролировать целостность данных и ИИ-моделей поставщиков по всей цепочке поставки средствами, прошедшими оценку соответствия в системе сертификации Федеральной службы по техническому и экспортному контролю (ФСТЭК России) | Не сказано. По нашему толкованию, контроль защищает от подмены файла ИИ-модели, а у сервиса, к которому банк обращается через интерфейс (API), банк файла не получает |
| Пункт 5.7 | Включить в договор ответственность поставщика за нарушения информационной безопасности и обязанность «по своевременному информированию о выявленных уязвимостях и инцидентах информационной безопасности» | Не сказано. Информирование рекомендовано об уязвимостях и инцидентах |
| Пункт 2.1.3 | Учитывать риски нарушения функционирования ИИ-модели, в том числе «иные варианты деградации модели ИИ» (рядом названы «галлюцинации ИИ» и «дрейф данных») | Не названо. Риски связаны с реализацией угроз безопасности технологий ИИ |
| Мера 21 приложения 4 (перечня мер защиты) | Определить показатели штатного функционирования ИИ-модели («производительность, смещение распределения входных и выходных данных, качество данных, поведение модели») и мониторить их. Показатели «дополнять самостоятельно». В п. 4 приложения 5 среди факторов безопасной разработки назван мониторинг результатов ИИ на этапе эксплуатации | Прямо не сказано. Ближайшая к этому случаю рекомендация, потому что требует мониторить «поведение модели». Как мониторить сервис поставщика, не поясняется |
| Мера 16 приложения 4 | При каждом дообучении (дополнительном обучении ИИ-модели на новых данных) фиксировать версию и для каждой версии использовать механизмы контроля целостности и проверки подлинности | Не сказано. О версиях, которые выпускает поставщик, мера не говорит |
| Пункт 16 приложения 5 (основных положений политики информационной безопасности для ИИ) | Закрепить в политике необходимость разработки плана восстановления операционной надёжности и порядка действий работников при нештатных ситуациях, включая аварийную остановку системы ИИ | Не названо. Замена ИИ-модели в плане не упомянута |
Положения главы 5 отвечают на вопрос, безопасен ли поставщик и его сервис. Вопрос о том, как банку заметить обновление ИИ-модели у поставщика, прямо в них не поставлен. В главе 5 нет рекомендации договориться с поставщиком, чтобы версия ИИ-модели не менялась без согласия банка. Определён «дрейф данных» (изменение характеристик данных со временем), а дрейфа самой ИИ-модели в определениях рекомендаций нет (проверено поиском по полному тексту на 4 октября 2026 года).
Что стандарт Банка России об аутсорсинге говорит об отказе поставщика выполнять обязательства и о концентрации операционного риска
Пункт 5.1 отсылает банк к стандарту об аутсорсинге при использовании сервисов ИИ поставщиков. В стандарте сказано, что «наличие и использование ограниченного числа поставщиков услуг, предоставляющих услуги аутсорсинга многим организациям БС РФ, реализует концентрацию операционного риска, что является системной угрозой для БС РФ в целом» (БС РФ - это банковская система Российской Федерации). К задачам руководства банка стандарт относит «обеспечение наличия плана действий организации БС РФ в случае отказа поставщика услуг от выполнения своих обязательств» и называет такой план стратегией «выхода». При аутсорсинге существенных функций (бизнес-функций, при выполнении которых обрабатывается защищаемая информация или невыполнение которых поставщиком создаёт условия для инцидентов безопасности) стандарт рекомендует ежегодную оценку «возможности реализовать стратегию "выхода" в случае отказа поставщика услуг от выполнения своих обязательств», самостоятельную или с привлечением аудиторской либо консалтинговой организации (таблица в п. 11.2).
Рекомендации Банка России № 4-МР о непрерывности деятельности банков от 29 июня 2026 года советуют диверсифицировать риски при выборе внешних подрядчиков. Об ИИ нет ни слова ни в них, ни в стандарте. Стандарт применим к поставщикам ИИ по п. 5.1 рекомендаций № 3-МР, и мы считаем, что план действий на случай отказа поставщика нужен и для ИИ-модели, от которой зависит работа банка.
Как за три месяца 2023 года изменились ответы GPT-4 на одни и те же вопросы (исследование двух американских университетов)
Что поставщик может обновить ИИ-модель так, что ответы изменятся, показало исследование Стэнфордского университета и Калифорнийского университета в Беркли (работа в открытом архиве научных статей arXiv). Исследователи сравнили мартовскую и июньскую 2023 года версии GPT-4 и GPT-3.5, двух LLM компании OpenAI. LLM просили определить, простое число или составное, и рассуждать по шагам (в наборе было 500 простых и 500 составных чисел). В марте просьба рассуждать по шагам подняла долю верных ответов GPT-4 с 59,6% до 84,0%, а в июне та же просьба почти ничего не изменила (данные в таблице). На таком наборе 50% даёт случайное угадывание (этот расчёт наш). Авторы объясняют результат частично тем, что июньская GPT-4 хуже следует инструкции рассуждать по шагам. У GPT-3.5 с той же просьбой доля верных ответов выросла с 49,6% в марте до 76,2% в июне, то есть изменение может быть и в лучшую сторону. Авторы пишут, что поведение «той же» LLM может заметно измениться за сравнительно короткое время, а когда и как LLM обновляются, непрозрачно, и рекомендуют постоянно мониторить поведение LLM.
Доля верных ответов GPT-4 и GPT-3.5 на 1000 вопросов о простых и составных числах приведена по таблице 1 исследования Стэнфордского университета и Калифорнийского университета в Беркли.
| Версия LLM | Без просьбы рассуждать по шагам | С просьбой рассуждать по шагам |
|---|---|---|
| GPT-4, март 2023 | 59,6% | 84,0% |
| GPT-4, июнь 2023 | 51,0% | 51,1% |
| GPT-3.5, март 2023 | 50,5% | 49,6% |
| GPT-3.5, июнь 2023 | 60,4% | 76,2% |
Для банка здесь важно, что запрос к ИИ-модели (например, просьба рассуждать по шагам), составленный для одной версии, может перестать работать на следующей. Авторы оговаривают, что набор задач охватывает поведение этих LLM лишь частично. В первой версии работы (июль 2023 года) набор состоял только из простых чисел и результаты были другие, здесь взяты результаты версии 3. Исследование касается зарубежных LLM 2023 года. Замеров по LLM российских поставщиков среди использованных нами материалов нет, и банк может провести такой замер сам.
Четыре проверки, которые банк может ввести, чтобы заметить обновление ИИ-модели у поставщика и подготовиться к нему
Мы считаем, что начинать стоит с первой проверки. Она не требует согласия поставщика, работает на собственных данных банка и показывает изменение ответов ИИ-модели независимо от того, кто и когда её обновил. Опыта применения этих проверок в банках в этой статье нет, они выведены из документов Банка России и исследования.
| Проверка | Нужно ли участие поставщика | Что показывает проверка |
|---|---|---|
| 1. Контрольный набор | Не нужно | Изменение доли верных ответов ИИ-модели на заготовленных случаях |
| 2. Перечень процессов и версий ИИ-моделей | Нужен ответ поставщика, а отказ отвечать тоже входит в оценку риска | Какая версия ИИ-модели в каком процессе работает и, по ответу поставщика, может ли она измениться без согласия банка |
| 3. Условие в договоре с поставщиком | Нужно согласие поставщика на условие | Предупреждение об обновлении заранее, если поставщик принял условие |
| 4. Пробная замена ИИ-модели | Участие поставщика не требуется. Требуется запасная ИИ-модель от другого разработчика | Срок замены ИИ-модели и падение доли верных ответов |
- Контрольный набор. Нужны реальные обращения или документы банка, по которым правильный ответ уже известен. Пока поставщик о смене версии не предупреждает, набор отправляется в ИИ-модель по расписанию, а кроме того при каждой смене версии, о которой стало известно. Доля верных ответов каждый раз сравнивается с результатом предыдущей отправки. Ответы LLM при повторе могут отличаться, поэтому набор стоит отправлять с одними и теми же настройками. На 100 случаях одна ошибка равна 1 проценту, поэтому размер набора определяет, какое падение доли верных ответов он заметит. Периодичность и порог тревожного падения банк выбирает сам. Доля верных ответов подходит для задач с проверяемым ответом (например, выбор темы обращения), для свободного текста нужен другой способ оценки. Мониторинг распределения ответов (доли обращений по каждой теме) показывает сдвиг в ответах. Контрольный набор дополняет его и показывает, стали ли ответы менее верными, но замечает это только на тех случаях, которые в него вошли. Контрольный набор - один из способов исполнить меру 21, которая рекомендует мониторить «поведение модели» (по нашему толкованию). Мысль о наборе своих документов с эталонными ответами «для замера до и после любой смены» уже была в нашей статье о выборе развёртывания LLM.
- Перечень процессов и версий ИИ-моделей. Для каждого процесса, где ИИ-модель влияет на решение банка (например, на выбор темы обращения клиента) или на действие с деньгами клиента, записывается, какая ИИ-модель какой версии работает и кто её поставщик. У поставщика нужно выяснить, может ли версия измениться без согласия банка и можно ли её закрепить. Ответ поставщика (или отказ отвечать) входит в оценку риска этого процесса.
- Условие в договоре с поставщиком. Стандарт об аутсорсинге в перечне условий соглашения называет «обязанность поставщика услуг информировать организацию БС РФ обо всех факторах, связанных с возникновением риска нарушения ИБ при аутсорсинге существенных функций, включая тип событий и обстоятельства их реализации». Пункт 5.7 рекомендаций № 3-МР рекомендует закрепить в договоре обязанность информировать об уязвимостях и инцидентах. По образцу этих условий можно запросить обязанность заранее сообщать об изменении версии или параметров ИИ-модели. Если поставщик типовые условия не меняет, остаётся записать отсутствие такого условия в оценку риска и учесть его при выборе поставщика.
- Пробная замена ИИ-модели. Стандарт рекомендует ежегодно оценивать возможность реализовать стратегию «выхода» при аутсорсинге существенных функций. Для ИИ-модели такую оценку можно провести так. Один процесс на тестовой копии (копии процесса, не связанной с реальными клиентами и деньгами) переключается на запасную ИИ-модель, а на контрольном наборе замеряется, за сколько дней это удалось и насколько упала доля верных ответов по сравнению с основной ИИ-моделью. Запасная ИИ-модель защищает от ошибок основной только тогда, когда это другая ИИ-модель другого разработчика, потому что у одной и той же ИИ-модели ошибки с большой вероятностью совпадут (это наше рассуждение).
Отменяет ли размещение ИИ-модели на серверах банка четыре проверки и открывает ли оно обучающие данные
По пересказу «Коммерсанта», Денис Царев считает, что отечественные ИИ-модели позволяют разворачивать ИИ-модель внутри контура банка (на серверах, которыми управляет банк). Мы считаем, что такое размещение четыре проверки не отменяет. Обновления ИИ-модели внутри контура банка ставит поставщик программно-аппаратного комплекса (сервера с предустановленной ИИ-моделью) или сам банк, если у него ИИ-модель с открытыми весами (файл ИИ-модели можно скачать и запустить у себя). Закон 243-ФЗ обязывает разработчиков суверенных и национальных LLM определять правила вывода LLM из эксплуатации (об этом написано в нашей статье о выборе развёртывания LLM). Последствия обновления видны по результатам на контрольном наборе и в этом случае. Если банк сам ставит обновления ИИ-модели с открытыми весами, о каждом обновлении он знает заранее, и условие в договоре с поставщиком (проверка 3) для такой ИИ-модели не нужно. Обучающие данные размещение внутри банка тоже не открывает, если разработчик LLM их не раскрывает. По пересказу «Коммерсанта», проверить данные, на которых обучены глобальные платформы ИИ, невозможно.
Как возможность заменить LLM в нашей ИИ-платформе Svaya связана с контрольным набором
В нашей ИИ-платформе Svaya в описании прикладной задачи указан класс LLM, а какая именно LLM за ним стоит, задаётся в настройках установки платформы, поэтому LLM можно заменить, не переделывая задачу. В этой статье мы описываем устройство платформы и не заявляем о заменах LLM на живых установках. Контрольный набор нужен и при такой возможности замены, потому что именно набор показывает, когда LLM пора менять.
