Обезличивание данных перед обучением модели — не только требование информационной безопасности, но и обязательное условие соблюдения законодательства о персональных данных.
Искусственный интеллект в банковском секторе: риски, угрозы и требования информационной безопасности
Обновлено: 9 июля 2026
16 июня 2026 г Банк России утвердилМетодические рекомендации № 3-МР«По обеспечению информационной безопасности при разработке и применении искусственного интеллекта на финансовом рынке». Документ впервые системно описывает, как организациям финансового сектора обеспечивать информационную безопасность и операционную надежность при работе с ИИ. В этой статье — полный разбор требований, рисков и практических мер защиты.
Что регулирует Банк России в сфере ИИ на финансовом рынке
Методические рекомендации № 3-МР — это первый специализированный регуляторный документ Банка России, посвященный информационной безопасности при использовании искусственного интеллекта в финансовом секторе. Документ охватывает весь жизненный цикл ИИ-системы от подготовки данных и разработки модели до ее обучения, тестирования и промышленной эксплуатации.
Рекомендации не носят характер жёстких предписаний, однако задают четкий стандарт ожиданий регулятора. Организации, которые следуют этим рекомендациям, формируют системную защиту от рисков ИИ и демонстрируют высокий уровень зрелости информационной безопасности.
Документ структурирован по четырем ключевым направлениям:
- классификация рисков ИИ;
- угрозы информационной безопасности ИИ-систем и меры нейтрализации;
- требования к политике информационной безопасности;
- требования к ИИ с открытым исходным кодом и поставщикам услуг.
На кого распространяются рекомендации
Рекомендации адресованы организациям финансового сектора, которые разрабатывают или применяют технологии искусственного интеллекта. Это банки, страховые компании, микрофинансовые организации, брокеры и иные участники финансового рынка, находящиеся под надзором Банка России.
Документ охватывает как собственные ИИ-модели, так и готовые решения сторонних поставщиков и компоненты с открытым исходным кодом.
Основные риски искусственного интеллекта в банковском секторе
Методические рекомендации формулируют шесть групп рисков ИИ, связанных с нарушением информационной безопасности и операционной надежности.
Для критически важных процессов, в которых риск информационной безопасности ИИ оценен как высокий, рекомендуется валидировать результаты операций, выполненных ИИ в автоматическом режиме, человеком с возможностью изменения таких результатов.
Риски управления данными и «отравленные» наборы данных
Первая и фундаментальная группа рисков связана с качеством данных, на которых обучается ИИ-модель. Если в обучающую выборку попадают «отравленные» данные — намеренно искаженные злоумышленником — модель усваивает ошибочные паттерны и начинает принимать неверные решения. Аналогичная проблема возникает при использовании неактуальных или некорректных наборов данных.
Что такое «отравленные» данные? Это набор обучающих данных, подвергнутый умышленной модификации: добавлены вредоносные записи, модифицированы существующие данные или удалены часть корректных. Цель — нарушить функционирование модели ИИ. Для финансового сектора это означает, что ИИ-модель, обученная на «отравленных» данных, может систематически ошибаться при оценке кредитного риска, выявлении мошенничества или принятии инвестиционных решений. Причем ошибки могут быть незаметны до момента их практического проявления.
Риски нарушения конфиденциальности данных
ИИ-системы в финансовом секторе работают с большими объемами чувствительной информации: персональными данными клиентов, транзакционной историей, финансовыми показателями. Нарушение конфиденциальности этих данных — как в процессе обучения модели, так и в ходе её эксплуатации — создаёт серьёзные правовые и репутационные риски для организации.
Особую опасность представляет возможность извлечения конфиденциальной информации через взаимодействие с моделью: злоумышленник может получить данные, которые модель «запомнила» в процессе обучения, просто задавая ей специально подготовленные запросы.
Риски нарушения функционирования модели ИИ
Эта группа рисков охватывает специфические для ИИ явления, которые приводят к деградации качества работы модели:
Галлюцинации ИИ — генерация моделью правдоподобно выглядящей, но фактически ложной,бессмысленной, некорректной информации. Для банка это может означать, что ИИ-ассистент предоставит клиенту или сотруднику недостоверные данные, которые будут восприняты как достоверные.
Дрейф данных — изменение характеристик и свойств данных со временем, из-за которого модель, хорошо работавшая при запуске, начинает давать всё менее точные результаты. Например, модель оценки кредитного риска, обученная до экономических потрясений, может некорректно оценивать заемщиков в новых условиях.
Деградация модели — общее ухудшение качества работы ИИ-системы под воздействием различных факторов: изменения входных данных, внешних атак или внутренних сбоев.
Риски отсутствия объяснимости и предсказуемости ИИ
Многие современные ИИ-модели работают как «чёрный ящик»: они выдают результат, но не могут объяснить логику принятого решения. В финансовом секторе это создает принципиальную проблему: банк обязан обосновывать свои решения — перед клиентами, регулятором и в суде.
Если ИИ отказал клиенту в кредите или заблокировал транзакцию, но не может объяснить почему — это одновременно регуляторный, правовой и репутационный риск. Отсутствие предсказуемости поведения модели также затрудняет управление операционными рисками. Организация не может заранее предвидеть, как модель поведёт себя в нестандартной ситуации.
Риски цепочки поставок и open-source компонентов
Использование сторонних поставщиков ИИ-услуг и компонентов с открытым исходным кодом переносит часть рисков за периметр организации. Уязвимость может прийти не изнутри банка, а через внешнего партнера или стороннюю библиотеку, которая встроена в ИИ-систему.
Риски, связанные с нарушением операционной надёжности организации
Шестая группа рисков связана с нарушением операционной надежности организации, обусловленным умышленными или неосторожными действиями в отношении системы ИИ, приводящими к прерыванию процессов основной деятельности организации.
- Операционная надежность в контексте ИИ означает способность организации обеспечивать бесперебойное функционирование критически важных процессов даже при воздействии на ИИ-системы. Нарушение этой надежности может быть вызвано двумя категориями действий:
Умышленные действия — целенаправленные атаки на ИИ-систему с целью вывода её из строя или нарушения её нормального функционирования. К таким действиям относятся атаки типа «отказ в обслуживании», подмена модели ИИ, внедрение бэкдора и иные виды воздействия, описанные в разделе об угрозах информационной безопасности. - Неосторожные действия — непреднамеренные действия сотрудников или иных лиц, имеющих доступ к ИИ-системе, которые приводят к нарушению её функционирования. Это может включать некорректную настройку системы, ошибки при обновлении модели, несанкционированное изменение параметров или нарушение установленных процедур работы с ИИ.
Последствием реализации данного риска является прерывание процессов основной деятельности организации. Для финансового сектора это особенно критично: сбой ИИ-системы, интегрированной в ключевые бизнес-процессы — оценку кредитного риска, обработку платежей, выявление мошенничества — может привести к операционным потерям, нарушению обязательств перед клиентами и регуляторным последствиям.
Последствия реализации рисков для финансовой организации
Банк России прямо указывает на шесть категорий последствий, к которым может привести реализация рисков ИИ:
- Нарушение прав, свобод и законных интересов физических лиц — клиенты банка могут пострадать от неверных автоматических решений;
- Нарушение операционной деятельности, в том числе в результате неверного управленческого решения, принятого с использованием ИИ;
- Причинение убытков — прямые финансовые потери организации;
- Вред деловой репутации — потеря доверия клиентов и партнёров;
- Нарушение стабильности финансовой системы — системный риск для всего рынка
Масштаб возможных последствий показывает безопасность ИИ в финансовом секторе — это не технический вопрос ИТ-департамента, а стратегическая задача для всего руководства организации.
Угрозы информационной безопасности систем ИИ
Банк России рекомендует всем организациям финансового сектора разрабатывать модель угроз безопасности системы ИИ. Модель угроз — это структурированный документ, который описывает кто может атаковать систему, каким образом и с какими целями. Это отправная точка для построения любой системы защиты, сначала определяем угрозы, затем выстраиваем меры противодействия.
Принципиальный момент, модель угроз для ИИ-систем должна учитывать специфические для технологий искусственного интеллекта угрозы, которые отсутствуют в традиционных информационных системах.
Специфические угрозы информационной безопасности для технологий ИИ
Банк России выделяет восемь специфических угроз, характерных именно для ИИ-систем:
| Угроза | Описание возможной угрозы |
| Нарушение функционирования ("обхода") средств, реализующих технологии ИИ | Угроза заключается в возможности выполнить состязательную атаку в отношении модели ИИ в целях получения ошибочного вывода или решения |
| Искажение («отравление») обучающих данных | Угроза заключается в возможности изменить набор обучающих и (или) тестовых данных таким образом, чтобы модель ИИ принимала ошибочные выводы или решения, соответствующие ожиданиям нарушителя Под изменением набора обучающих данных понимается:
|
| Раскрытие информации о модели ИИ | Угроза заключается в возможности раскрыть информацию о модели ИИ в результате утечки, в том числе через выходные данные, всей или отдельной информации о ней, включая сведения об архитектуре и параметрах обучения модели ИИ |
| Хищение обучающих данных | Угроза заключается в возможности получения несанкционированного доступа к обучающим и (или) тестовым данным, в том числе через выходные данные |
| Модификация модели ИИ, в том числе изменение архитектуры, последовательности взаимодействий | Угроза заключается во внесении несанкционированных изменений в модель ИИ путем использования скрытых возможностей в компонентах, которые применяются для разработки, обучения и эксплуатации модели ИИ |
| Приведения модели ИИ в состояние "отказ в обслуживании" | Угроза заключается в возможности приведения модели ИИ в состояние "отказ в обслуживании" или снижении ее производительности путем манипуляции над входными данными |
| Манипуляции поведением модели ИИ | Угроза заключается в возможности использовать вредоносные запросы таким образом, чтобы поведение модели ИИ соответствовало ожиданиям нарушителя, в том числе для выполнения нелегитимного кода моделью ИИ |
| Подмена модели ИИ | Угроза заключается в возможности нарушителя подменить модель ИИ таким образом, чтобы контролировать ее поведение или получать нежелательные результаты |
Способы реализации атак на ИИ-системы
Для каждой из угроз Банк России описывает конкретные способы реализации. Понимание механики атак позволяет организациям выстраивать адресную защиту.
1. Атака с использованием фаззинга
Злоумышленник вводит в модель большое количество случайных или специально подобранных входных данных с целью выявить уязвимости в её логике или спровоцировать отказ в обслуживании. Фаззинг широко применяется в традиционном тестировании программного обеспечения, однако для ИИ-систем он несёт дополнительную угрозу: помогает атакующему понять поведения модели.
2. Внедрение бэкдора (закладки)
В модель ИИ на этапе разработки или обучения внедряется скрытый механизм, который активируется при определённых входных данных и изменяет поведение модели в интересах злоумышленника. Бэкдор может оставаться незамеченным годами при стандартном тестировании.
3. Модификация алгоритма обучения
Злоумышленник вмешивается в логику процесса обучения модели, что приводит к её модификации. В результате модель ведёт себя корректно в стандартных условиях, но даёт нужные атакующему результаты при специфических входных данных.
4. Извлечение данных
Нарушитель получает конфиденциальную информацию, которую модель «запомнила» в процессе обучения, путём целенаправленного взаимодействия с ней. Это особенно критично для банков: модель, обученная на персональных данных клиентов, может «выдать» их при правильно сформулированных запросах.
5. Вредоносная «инъекция» (Prompt Injection)
Злоумышленник модифицирует или обходит системные инструкции модели ИИ с использованием специально подготовленных входных данных. Атака может быть прямой — когда пользователь сам вводит вредоносный запрос — или непрямой, когда вредоносные инструкции встроены во внешний контент, который модель обрабатывает автоматически.
Почему prompt injection особенно опасен для банков? Финансовые организации всё активнее внедряют ИИ-ассистентов для обслуживания клиентов и поддержки сотрудников. Успешная атака типа prompt injection может заставить такого ассистента выдать конфиденциальные данные, выполнить несанкционированные действия или предоставить ложную информацию.
6. Атака типа «губка»
Злоумышленник формирует специальные входные данные, обработка которых требует от модели непропорционально больших вычислительных ресурсов. Цель — истощить ресурсы системы и спровоцировать деградацию производительности или полный отказ в обслуживании.
7. «Отравление» обучающих данных
Целенаправленная модификация обучающей выборки: добавление вредоносных записей, изменение существующих данных или удаление корректных примеров. Результат — модель, которая систематически ошибается в предсказуемых для атакующего ситуациях.
8. Состязательные атаки (Adversarial Attacks)
Атакующий формирует входные данные, которые для человека выглядят абсолютно нормально, но вызывают у модели ИИ грубые ошибки классификации или принятия решений.
Как нейтрализовать угрозы: меры защиты по этапам жизненного цикла ИИ
Для нейтрализации актуальных угроз Банк России рекомендует реализовать процесс «Безопасность и защита данных» в соответствии с ГОСТ Р 71539-2024 (ИСО/МЭК 5338:2023) «Искусственный интеллект. Процессы жизненного цикла системы искусственного интеллекта». Процесс разделяется на четыре подпроцесса, соответствующих этапам работы с ИИ.
н3 Безопасность при подготовке данных
Качество и защищённость данных — фундамент безопасной ИИ-системы. Меры защиты на этом этапе:
- Контроль и очистка обучающих и тестовых данных от аномалий в данных — регулярная проверка выборок на наличие статистических аномалий, которые могут свидетельствовать об «отравлении»;
- Шифрование данных, передаваемых за пределы контролируемой зоны — все данные, покидающие защищённый периметр организации, должны быть зашифрованы, чтобы исключить их перехват и несанкционированное использование;
- Контроль целостности и проверка подлинности наборов данных — подтверждение того, что данные не были изменены с момента их формирования;
- Отслеживание и документирование изменений в наборы данных — ведение полного журнала всех изменений в обучающих и тестовых выборках с указанием автора, времени и причины изменений;
- Обезличивание персональных данных и маскирование информации ограниченного доступа — перед использованием данных для обучения модели необходимо исключить из них персональные данныеклиентов и иную конфиденциальную информацию;
- Гарантированное стирание данных — безвозвратное уничтожение данных по завершении их использования, исключающее возможность восстановления.
Важно для банков
Безопасность при разработке модели ИИ
На этапе разработки закладывается архитектурная безопасность модели. Принцип «security by design» — встраивать защиту с самого начала, а не добавлять её потом — особенно актуален для ИИ-систем. Меры защиты на этом этапе:
- Анализ уязвимостей модели ИИ, программного кода и используемых компонентов — систематическая проверка всех элементов системы на наличие известных и потенциальных уязвимостей, включая сторонние библиотеки и фреймворки;
- Обеспечение целостности криптографическими методами и проверка подлинности модели и кода — использование цифровых подписей и хеш-сумм для подтверждения того, что модель и её код не были модифицированы несанкционированно;
- Отслеживание и документирование изменений в программный код и документацию — ведение системы контроля версий с полной историей изменений, что обеспечивает прозрачность разработки и возможность аудита
Безопасность при обучении и тестировании модели ИИ
Этап обучения и тестирования — наиболее технически насыщенный с точки зрения мер защиты. Банк России рекомендует семь мер:
- Методы повышения устойчивости к состязательным атакам — специальные техники обучения, которые делают модель менее восприимчивой к adversarial-примерам. Включают adversarial training — намеренное добавление атакующих примеров в обучающую выборку для выработки устойчивости.
- Протоколы конфиденциального вычисления — технологии, позволяющие
произвести вычисление, чтобы ни один участник не смог получить никакой информации о чужих тайных входных данных. Это обеспечивает конфиденциальность данных даже в процессе обучения модели. - Федеративное обучение — подход, при котором модель обучается на данных, не покидающих устройства или серверы их владельцев. Каждый участник обучает локальную копию модели, и только обновления параметров передаются на центральный сервер. Данные клиентов при этом не покидают периметр организации.
- Цифровые метки (Watermarking) — встраивание в модель скрытых идентификаторов, позволяющих доказать авторство и выявить несанкционированное копирование или модификацию модели. Это инструмент защиты интеллектуальной собственности организации.
- Тестирование на предмет «отравления» — специализированные проверки, направленные на выявление следов атак типа data poisoning в обученной модели.
- Тестирование на проникновение (пентест) — имитация реальных атак на ИИ-систему с целью выявления уязвимостей до того, как их обнаружат злоумышленники. Пентест ИИ-системы включает как стандартные техники, так и специфические для ИИ атаки.
- Периодическое дообучение модели — регулярное обновление модели на актуальных данных для противодействия дрейфу данных и поддержания качества её работы в изменяющихся условиях.
Безопасность при функционировании модели ИИ
Запуск модели в промышленную эксплуатацию не означает завершения работы по обеспечению безопасности — напротив, это начало непрерывного процесса мониторинга и защиты. Банк России рекомендует пять мер защиты на этапе эксплуатации:
- Шифрование входных и выходных данных — все данные, поступающие в модель и исходящие из неё, должны передаваться в зашифрованном виде. Это исключает перехват чувствительной информации в процессе работы системы.
- Контроль и очистка аномалий во входных и выходных данных — автоматическое обнаружение и фильтрация подозрительных входных данных, которые могут являться попыткой атаки, а также контроль выходных данных на предмет аномальных результатов.
- Регистрация и контроль событий, связанных с входными и выходными данными — ведение детального журнала всех операций модели. Логи являются основой для расследования инцидентов, аудита и выявления паттернов атак.
- Ограничение параметров потоков входных данных — установка лимитов на объём, частоту и характеристики входных запросов. Это защищает систему от атак типа «губка» и попыток вызвать отказ в обслуживании через перегрузку модели.
- Определение и мониторинг показателей штатного функционирования модели — установка базовых метрик нормальной работы модели и непрерывный контроль отклонений от них. Раннее обнаружение аномалий в поведении модели позволяет своевременно реагировать на деградацию или атаки.
Ключевой принцип:
безопасность ИИ-системы при эксплуатации — это непрерывный процесс, а не разовое мероприятие. Модель, безопасная при запуске, может стать уязвимой через несколько месяцев работы без должного мониторинга.
Политика информационной безопасности при использовании ИИ
Что должна содержать политика ИБ для ИИ
В целях минимизации рисков Банк России рекомендует организациям финансового сектора разработать или дополнить существующую политику информационной безопасности специальным разделом, посвящённым разработке и применению ИИ. Политика ИБ для ИИ — это не формальный документ для галочки, а рабочий инструмент управления рисками, определяющий правила и ответственность для всей организации.
Политика должна содержать:
1. Целевые свойства безопасности ИИ-системы
Политика должна закрепить пять целевых свойств, которые организация обязуется обеспечивать:
- Целостность — данные и модель не подверглись несанкционированным изменениям;
- Конфиденциальность — данные доступны только авторизованным лицам;
- Доступность — система функционирует в штатном режиме;
- Киберустойчивость — способность системы продолжать работу и восстанавливаться после атак;
- Объяснимость/предсказуемость — решения модели поддаются интерпретации и аудиту.
2. Минимальные права доступа
Каждый сотрудник и система должны иметь только те права доступа к ИИ-системе и данным, которые необходимы для выполнения их функций. Принцип минимальных привилегий снижает риск как внешних атак, так и инсайдерских угроз.
3. Минимальные персональные данные
Для обучения и эксплуатации ИИ-модели должен использоваться минимально необходимый объём персональных данных. Это снижает риски нарушения конфиденциальности и упрощает соблюдение требований законодательства о персональных данных.
4. Безопасная разработка
Политика должна закрепить принципы и стандарты безопасной разработки ИИ-систем, включая требования к анализу уязвимостей, тестированию и документированию на всех этапах жизненного цикла модели.
5. Осведомлённость и полномочия работников
Сотрудники, работающие с ИИ-системами, должны понимать риски и угрозы, связанные с технологиями ИИ, и иметь чётко определённые полномочия и зоны ответственности. Политика должна предусматривать программу обучения и повышения осведомлённости персонала.
6. Комплаенс
Политика должна закреплять необходимость обеспечения соответствия систем ИИ национальным и (или) международным стандартам, методическим документам, отражающим лучшие практики обеспечения информационной безопасности систем ИИ.
7. Реализация и ответственность
Должны быть чётко определены лица, ответственные за реализацию требований политики, и механизмы контроля их исполнения. Размытая ответственность — одна из главных причин провалов в области информационной безопасности.
8. Правила для работы с открытыми моделями и общедоступными сервисами ИИ
Использование публичных ИИ-сервисов и моделей с открытым исходным кодом несёт специфические риски. Политика должна регламентировать: какие сервисы разрешено использовать, в каких целях и при каких условиях, какие данные запрещено передавать во внешние ИИ-системы.
9. Маркировка выходных данных и сокрытие информации о модели
Выходные данные ИИ-системы должны быть соответствующим образом маркированы, чтобы пользователи понимали, что имеют дело с результатом работы ИИ. Одновременно политика должна предусматривать меры по защите информации об архитектуре и параметрах модели от раскрытия.
10. Порядок регистрации, анализа и реагирования на инциденты
Политика должна определять чёткий алгоритм действий при выявлении инцидентов информационной безопасности, связанных с ИИ-системами: кто фиксирует, кто расследует, кто принимает решения и в какие сроки.
11. Нештатные ситуации
Рекомендуется закрепить необходимость разработки плана восстановления операционной надежности и порядка действий работников организации в случае возникновения нештатных ситуаций при эксплуатации систем ИИ, в том числе действий по аварийной остановке системы ИИ, в целях оперативного реагирования на нештатные ситуации, связанные с технологиями ИИ
12. Оценка рисков при передаче данных или моделей внешним поставщикам
Любая передача данных или моделей третьим сторонам должна предваряться формализованной оценкой рисков информационной безопасности. Политика должна устанавливать требования к такой оценке и критерии допустимого уровня риска.
13. Регулярность актуализации политики
Технологии ИИ и связанные с ними угрозы развиваются стремительно. Политика должна предусматривать периодический пересмотр и актуализацию на регулярной основе или при существенном изменении условий работы с ИИ.
Внутренние документы и порядок контроля
Политика информационной безопасности — это верхний уровень нормативной базы. Для её реального исполнения организации необходимо разработать дополнительные внутренние документы, регулирующие:
- Порядок контроля за реализацией требований политики — конкретные процедуры проверки исполнения каждого требования, периодичность проверок и форма их документирования.
- Порядок проведения аудита — регламент внутренних и внешних проверок системы информационной безопасности ИИ, включая критерии оценки и форму отчётности.
- Порядок информирования органов управления — механизм эскалации информации о нарушениях требований политики до уровня совета директоров или правления организации.
Требования к ИИ с открытым исходным кодом и поставщикам услуг
Как оценить доверие к поставщику ИИ-решений
Использование сторонних ИИ-сервисов и компонентов с открытым исходным кодом требует от организации системного подхода к оценке доверия. Банк России рекомендует разрабатывать собственные методики оценки доверия в отношении безопасности данных, моделей ИИ поставщиков услуг и open-source компонентов.
Методика оценки доверия должна учитывать четырнадцать факторов:
1. Оценка соответствия инфраструктуры поставщика требованиям безопасности
Объекты информационно-коммуникационной инфраструктуры поставщика, на базе которых размещаются данные и модели ИИ, должны соответствовать требованиям безопасности, установленным законодательством Российской Федерации и нормативными актами Банка России.
2. Участие модели в программе Bug Bounty
Наличие у поставщика действующей программы поиска уязвимостей свидетельствует о зрелости его подхода к безопасности и готовности к внешней проверке модели независимыми исследователями.
3. Наличие модели угроз
Модель угроз поставщика должна учитывать возможности как внешнего, так и внутреннего нарушителя. Отсутствие модели угроз — серьёзный индикатор незрелости системы безопасности.
4. Реализация мер защиты согласно документации
Меры защиты, заявленные в проектной и эксплуатационной документации поставщика, должны быть фактически реализованы, а не существовать только на бумаге.
5. Регулярные отчёты об аудите безопасности инфраструктуры
Поставщик должен на регулярной основе предоставлять организации отчёты об аудите и проверках состояния информационной безопасности своей инфраструктуры и ИИ-сервисов.
6. Регулярные отчёты об аудите лицензий
Использование программных компонентов должно соответствовать лицензионным требованиям. Регулярный аудит лицензий снижает правовые риски организации.
7. Наличие спецификации программного обеспечения (SBOM)
Software Bill of Materials — полный перечень всех программных компонентов, используемых в ИИ-системе, с указанием версий и источников. SBOM позволяет быстро выявить уязвимые компоненты при появлении новых угроз.
8. Регулярные отчёты об анализе уязвимостей и пентесте
Поставщик должен регулярно проводить анализ уязвимостей и тестирование на проникновение своих ИИ-систем и предоставлять организации соответствующие отчёты.
9. Постоянный мониторинг и реагирование на инциденты
Поставщик должен осуществлять непрерывный мониторинг своей инфраструктуры, обеспечивать реагирование на инциденты информационной безопасности и своевременно информировать организацию о зарегистрированных инцидентах.
10. Подтверждение использования процессов безопасного жизненного цикла
Разработка ИИ-систем поставщика должна вестись в соответствии с принципами безопасного жизненного цикла разработки программного обеспечения.
11. Оценка соответствия или сертификация процессов безопасной разработки
Наличие независимой оценки соответствия или сертификации по требованиям безопасности для процессов разработки модели ИИ является важным подтверждением зрелости поставщика.
12. Реализация требований безопасности к open-source компонентам
Поставщик должен вести учёт всех используемых компонентов с открытым исходным кодом, включая агентов, плагины и интерфейсы взаимодействия, и обеспечивать соответствие их использования требованиям безопасности.
13. Предоставление результатов отслеживания источников данных
Поставщик должен документировать и предоставлять организации информацию о происхождении данных, используемых для обучения модели ИИ.
14. Оценка рисков информационной безопасности организацией
Поставщик должн проводить независимую оценку рисков информационной безопасности своего ИИ-решения.
Требования к целостности данных и моделей поставщиков
Для обеспечения целостности данных и моделей ИИ поставщиков услуг организациям необходимо использовать средства контроля целостности, прошедшие оценку соответствия ФСТЭК России, по всей цепочке поставки.
Это требование означает: недостаточно проверить целостность данных или модели только на входе в организацию — контроль должен осуществляться на каждом звене цепочки от источника до конечного потребителя.
Почему важна оценка соответствия ФСТЭК России?
Средства контроля целостности, прошедшие оценку соответствия ФСТЭК России, подтверждают свою надёжность независимой экспертизой. Использование несертифицированных средств создаёт риск того, что сам инструмент контроля может быть скомпрометирован.
Требования к данным, передаваемым поставщику для обучения модели
Если организация передаёт поставщику услуг собственные данные для обучения ИИ-модели, Банк России рекомендует передавать:
- «Очищенные» наборы данных — данные, прошедшие процедуру очистки от персональной и конфиденциальной информации;
- Синтетические данные — искусственно сгенерированные данные, статистически схожие с реальными, но не содержащие реальных персональных данных клиентов;
- Обезличенные данные — данные, из которых удалены все идентификаторы, позволяющие установить личность субъекта;
- Специально подготовленные данные — данные, прошедшие дополнительную обработку с учётом конкретных требований безопасности.
Это требование защищает организацию от риска утечки конфиденциальных данных клиентов через инфраструктуру поставщика и снижает правовые риски, связанные с передачей персональных данных третьим сторонам.
Что включить в договор с поставщиком сервисов ИИ
Договорная база — важнейший инструмент управления рисками при работе со сторонними поставщиками ИИ. Банк России прямо указывает на два обязательных элемента, которые должны быть включены в договор на предоставление сервисов ИИ:
1. Ответственность поставщика за нарушения информационной безопасности
Договор должен содержать чёткие положения об ответственности поставщика услуг за нарушения информационной безопасности предоставляемых ИИ-сервисов. Это включает как финансовую ответственность, так и обязательства по устранению последствий инцидентов.
2. Обязанность своевременного информирования об уязвимостях и инцидентах
Поставщик обязан незамедлительно уведомлять организацию о выявленных уязвимостях и инцидентах информационной безопасности. Договор должен устанавливать конкретные сроки такого уведомления и форму предоставления информации.
Почему финансовым организациям важно действовать уже сейчас
Методические рекомендации № 3-МР — это чёткий сигнал от Банка России: регулятор рассматривает информационную безопасность ИИ как системный приоритет для финансового сектора. Организации, которые выстраивают защиту ИИ-систем сегодня, получают несколько ключевых преимуществ:
- Соответствие ожиданиям регулятора. Следование рекомендациям ЦБ демонстрирует зрелость системы управления рисками организации и снижает вероятность регуляторных претензий при проверках.
- Защита от реальных угроз. Атаки на ИИ-системы — это не теоретическая угроза будущего, а актуальная реальность. Состязательные атаки, отравление данных и prompt injection уже применяются злоумышленниками против финансовых организаций по всему миру.
- Защита репутации и доверия клиентов. Инцидент безопасности, связанный с ИИ-системой банка, — это не только операционные потери, но и серьёзный репутационный ущерб. Клиенты, узнавшие об утечке их персональных данных через ИИ-сервис, теряют доверие к организации.
Операционная устойчивость. Выстроенная система защиты ИИ обеспечивает бесперебойность критически важных процессов даже в условиях кибератак и технических сбоев. - Конкурентное преимущество. Организации, которые могут подтвердить безопасность и объяснимость своих ИИ-решений, получают преимущество при работе с корпоративными клиентами и партнёрами, для которых вопросы безопасности данных являются приоритетными.
Выводы: что нужно сделать финансовой организации прямо сейчас
На основании Методических рекомендаций № 3-МР Банка России организациям финансового сектора необходимо реализовать следующий комплекс мер:
1. Провести оценку рисков ИИ
Идентифицировать все ИИ-системы, используемые в организации, и провести оценку рисков информационной безопасности для каждой из них с учётом классификации, приведённой в рекомендациях ЦБ.
2. Разработать модель угроз для ИИ-систем
Создать специализированную модель угроз, учитывающую специфические угрозы ИИ и способы их реализации, описанных в рекомендациях Банка России.
3. Реализовать меры защиты по этапам жизненного цикла
Внедрить меры защиты для каждого из четырёх подпроцессов безопасности в соответствии с ГОСТ Р 71539-2024: подготовка данных, разработка модели, обучение и тестирование, эксплуатация.
4. Разработать или актуализировать политику ИБ для ИИ
Создать специализированную политику информационной безопасности при разработке и применении ИИ, включающую все обязательные элементы, определённые рекомендациями ЦБ.
5. Выстроить систему контроля за поставщиками
Разработать методику оценки доверия к поставщикам ИИ-услуг и open-source компонентов, включая четырнадцать факторов оценки, и включить обязательные требования безопасности в договоры с поставщиками.
6. Обеспечить валидацию критически важных решений ИИ
Для процессов с высоким уровнем риска информационной безопасности ИИ внедрить обязательную валидацию результатов работы ИИ человеком с правом изменения этих результатов.
7. Обучить персонал
Провести обучение сотрудников, работающих с ИИ-системами, по вопросам информационной безопасности ИИ, специфических угроз и правил работы с открытыми моделями и публичными сервисами.
«Часто задаваемые вопросы» (FAQ)
Являются ли Методические рекомендации № 3-МР обязательными для исполнения?
Методические рекомендации Банка России носят рекомендательный, а не обязательный характер. Однако они отражают ожидания регулятора и фактически задают стандарт, которому финансовые организации должны следовать для демонстрации зрелости системы управления рисками.
На какие организации распространяются рекомендации?
Рекомендации адресованы организациям финансового сектора, находящимся под надзором Банка России, которые разрабатывают или применяют технологии искусственного интеллекта.
Что такое «отравление» данных и чем оно опасно для банка?
«Отравление» данных — это намеренное внесение злоумышленником искажений в обучающую выборку ИИ-модели. Результат — модель, которая систематически принимает неверные решения в предсказуемых для атакующего ситуациях. Для банка это может означать ошибки в оценке кредитного риска, пропуск мошеннических транзакций или некорректные инвестиционные решения.
Что нужно включить в договор с поставщиком ИИ-сервисов?
Согласно рекомендациям ЦБ, договор должен содержать положения об ответственности поставщика за нарушения информационной безопасности и обязанность поставщика своевременно информировать организацию о выявленных уязвимостях и инцидентах.
Как часто нужно актуализировать политику ИБ для ИИ?
О: Рекомендации ЦБ предписывают регулярную актуализацию политики. Конкретная периодичность документом не установлена — организация определяет её самостоятельно с учётом изменений в технологиях ИИ, угрозах и регуляторных требованиях.
