Обезличивание данных перед обучением модели — не только требование информационной безопасности, но и обязательное условие соблюдения законодательства о персональных данных.
Обновлено: 21 июля 2026
16 июня 2026 г Банк России утвердилМетодические рекомендации № 3-МР«По обеспечению информационной безопасности при разработке и применении искусственного интеллекта на финансовом рынке». Документ впервые системно описывает, как организациям финансового сектора обеспечивать информационную безопасность и операционную надежность при работе с ИИ. В этой статье — полный разбор требований, рисков и практических мер защиты.
Методические рекомендации № 3-МР — это первый специализированный регуляторный документ Банка России, посвященный информационной безопасности при использовании искусственного интеллекта в финансовом секторе. Документ охватывает весь жизненный цикл ИИ-системы от подготовки данных и разработки модели до ее обучения, тестирования и промышленной эксплуатации.
Рекомендации не носят характер жёстких предписаний, однако задают четкий стандарт ожиданий регулятора. Организации, которые следуют этим рекомендациям, формируют системную защиту от рисков ИИ и демонстрируют высокий уровень зрелости информационной безопасности.
Документ структурирован по четырем ключевым направлениям:
Рекомендации адресованы организациям финансового сектора, которые разрабатывают или применяют технологии искусственного интеллекта. Это банки, страховые компании, микрофинансовые организации, брокеры и иные участники финансового рынка, находящиеся под надзором Банка России.
Документ охватывает как собственные ИИ-модели, так и готовые решения сторонних поставщиков и компоненты с открытым исходным кодом.
Методические рекомендации формулируют шесть групп рисков ИИ, связанных с нарушением информационной безопасности и операционной надежности.
Для критически важных процессов, в которых риск информационной безопасности ИИ оценен как высокий, рекомендуется валидировать результаты операций, выполненных ИИ в автоматическом режиме, человеком с возможностью изменения таких результатов.
Первая и фундаментальная группа рисков связана с качеством данных, на которых обучается ИИ-модель. Если в обучающую выборку попадают «отравленные» данные — намеренно искаженные злоумышленником — модель усваивает ошибочные паттерны и начинает принимать неверные решения. Аналогичная проблема возникает при использовании неактуальных или некорректных наборов данных.
Что такое «отравленные» данные? Это набор обучающих данных, подвергнутый умышленной модификации: добавлены вредоносные записи, модифицированы существующие данные или удалены часть корректных. Цель — нарушить функционирование модели ИИ. Для финансового сектора это означает, что ИИ-модель, обученная на «отравленных» данных, может систематически ошибаться при оценке кредитного риска, выявлении мошенничества или принятии инвестиционных решений. Причем ошибки могут быть незаметны до момента их практического проявления.
ИИ-системы в финансовом секторе работают с большими объемами чувствительной информации: персональными данными клиентов, транзакционной историей, финансовыми показателями. Нарушение конфиденциальности этих данных — как в процессе обучения модели, так и в ходе её эксплуатации — создаёт серьёзные правовые и репутационные риски для организации.
Особую опасность представляет возможность извлечения конфиденциальной информации через взаимодействие с моделью: злоумышленник может получить данные, которые модель «запомнила» в процессе обучения, просто задавая ей специально подготовленные запросы.
Эта группа рисков охватывает специфические для ИИ явления, которые приводят к деградации качества работы модели:
Галлюцинации ИИ — генерация моделью правдоподобно выглядящей, но фактически ложной,бессмысленной, некорректной информации. Для банка это может означать, что ИИ-ассистент предоставит клиенту или сотруднику недостоверные данные, которые будут восприняты как достоверные.
Дрейф данных — изменение характеристик и свойств данных со временем, из-за которого модель, хорошо работавшая при запуске, начинает давать всё менее точные результаты. Например, модель оценки кредитного риска, обученная до экономических потрясений, может некорректно оценивать заемщиков в новых условиях.
Деградация модели — общее ухудшение качества работы ИИ-системы под воздействием различных факторов: изменения входных данных, внешних атак или внутренних сбоев.
Многие современные ИИ-модели работают как «чёрный ящик»: они выдают результат, но не могут объяснить логику принятого решения. В финансовом секторе это создает принципиальную проблему: банк обязан обосновывать свои решения — перед клиентами, регулятором и в суде.
Если ИИ отказал клиенту в кредите или заблокировал транзакцию, но не может объяснить почему — это одновременно регуляторный, правовой и репутационный риск. Отсутствие предсказуемости поведения модели также затрудняет управление операционными рисками. Организация не может заранее предвидеть, как модель поведёт себя в нестандартной ситуации.
Использование сторонних поставщиков ИИ-услуг и компонентов с открытым исходным кодом переносит часть рисков за периметр организации. Уязвимость может прийти не изнутри банка, а через внешнего партнера или стороннюю библиотеку, которая встроена в ИИ-систему.
Шестая группа рисков связана с нарушением операционной надежности организации, обусловленным умышленными или неосторожными действиями в отношении системы ИИ, приводящими к прерыванию процессов основной деятельности организации.
Последствием реализации данного риска является прерывание процессов основной деятельности организации. Для финансового сектора это особенно критично: сбой ИИ-системы, интегрированной в ключевые бизнес-процессы — оценку кредитного риска, обработку платежей, выявление мошенничества — может привести к операционным потерям, нарушению обязательств перед клиентами и регуляторным последствиям.
Банк России прямо указывает на шесть категорий последствий, к которым может привести реализация рисков ИИ:
Масштаб возможных последствий показывает безопасность ИИ в финансовом секторе — это не технический вопрос ИТ-департамента, а стратегическая задача для всего руководства организации.
Банк России рекомендует всем организациям финансового сектора разрабатывать модель угроз безопасности системы ИИ. Модель угроз — это структурированный документ, который описывает кто может атаковать систему, каким образом и с какими целями. Это отправная точка для построения любой системы защиты, сначала определяем угрозы, затем выстраиваем меры противодействия.
Принципиальный момент, модель угроз для ИИ-систем должна учитывать специфические для технологий искусственного интеллекта угрозы, которые отсутствуют в традиционных информационных системах.
Банк России выделяет восемь специфических угроз, характерных именно для ИИ-систем:
| Угроза | Описание возможной угрозы |
| Нарушение функционирования ("обхода") средств, реализующих технологии ИИ | Угроза заключается в возможности выполнить состязательную атаку в отношении модели ИИ в целях получения ошибочного вывода или решения |
| Искажение («отравление») обучающих данных | Угроза заключается в возможности изменить набор обучающих и (или) тестовых данных таким образом, чтобы модель ИИ принимала ошибочные выводы или решения, соответствующие ожиданиям нарушителя Под изменением набора обучающих данных понимается:
|
| Раскрытие информации о модели ИИ | Угроза заключается в возможности раскрыть информацию о модели ИИ в результате утечки, в том числе через выходные данные, всей или отдельной информации о ней, включая сведения об архитектуре и параметрах обучения модели ИИ |
| Хищение обучающих данных | Угроза заключается в возможности получения несанкционированного доступа к обучающим и (или) тестовым данным, в том числе через выходные данные |
| Модификация модели ИИ, в том числе изменение архитектуры, последовательности взаимодействий | Угроза заключается во внесении несанкционированных изменений в модель ИИ путем использования скрытых возможностей в компонентах, которые применяются для разработки, обучения и эксплуатации модели ИИ |
| Приведения модели ИИ в состояние "отказ в обслуживании" | Угроза заключается в возможности приведения модели ИИ в состояние "отказ в обслуживании" или снижении ее производительности путем манипуляции над входными данными |
| Манипуляции поведением модели ИИ | Угроза заключается в возможности использовать вредоносные запросы таким образом, чтобы поведение модели ИИ соответствовало ожиданиям нарушителя, в том числе для выполнения нелегитимного кода моделью ИИ |
| Подмена модели ИИ | Угроза заключается в возможности нарушителя подменить модель ИИ таким образом, чтобы контролировать ее поведение или получать нежелательные результаты |
Для каждой из угроз Банк России описывает конкретные способы реализации. Понимание механики атак позволяет организациям выстраивать адресную защиту.
Злоумышленник вводит в модель большое количество случайных или специально подобранных входных данных с целью выявить уязвимости в её логике или спровоцировать отказ в обслуживании. Фаззинг широко применяется в традиционном тестировании программного обеспечения, однако для ИИ-систем он несёт дополнительную угрозу: помогает атакующему понять поведения модели.
В модель ИИ на этапе разработки или обучения внедряется скрытый механизм, который активируется при определённых входных данных и изменяет поведение модели в интересах злоумышленника. Бэкдор может оставаться незамеченным годами при стандартном тестировании.
Злоумышленник вмешивается в логику процесса обучения модели, что приводит к её модификации. В результате модель ведёт себя корректно в стандартных условиях, но даёт нужные атакующему результаты при специфических входных данных.
Нарушитель получает конфиденциальную информацию, которую модель «запомнила» в процессе обучения, путём целенаправленного взаимодействия с ней. Это особенно критично для банков: модель, обученная на персональных данных клиентов, может «выдать» их при правильно сформулированных запросах.
Злоумышленник модифицирует или обходит системные инструкции модели ИИ с использованием специально подготовленных входных данных. Атака может быть прямой — когда пользователь сам вводит вредоносный запрос — или непрямой, когда вредоносные инструкции встроены во внешний контент, который модель обрабатывает автоматически.
Почему prompt injection особенно опасен для банков? Финансовые организации всё активнее внедряют ИИ-ассистентов для обслуживания клиентов и поддержки сотрудников. Успешная атака типа prompt injection может заставить такого ассистента выдать конфиденциальные данные, выполнить несанкционированные действия или предоставить ложную информацию.
Злоумышленник формирует специальные входные данные, обработка которых требует от модели непропорционально больших вычислительных ресурсов. Цель — истощить ресурсы системы и спровоцировать деградацию производительности или полный отказ в обслуживании.
Целенаправленная модификация обучающей выборки: добавление вредоносных записей, изменение существующих данных или удаление корректных примеров. Результат — модель, которая систематически ошибается в предсказуемых для атакующего ситуациях.
Атакующий формирует входные данные, которые для человека выглядят абсолютно нормально, но вызывают у модели ИИ грубые ошибки классификации или принятия решений.
Для нейтрализации актуальных угроз Банк России рекомендует реализовать процесс «Безопасность и защита данных» в соответствии с ГОСТ Р 71539-2024 (ИСО/МЭК 5338:2023) «Искусственный интеллект. Процессы жизненного цикла системы искусственного интеллекта». Процесс разделяется на четыре подпроцесса, соответствующих этапам работы с ИИ.
н3 Безопасность при подготовке данных
Качество и защищённость данных — фундамент безопасной ИИ-системы. Меры защиты на этом этапе:
Обезличивание данных перед обучением модели — не только требование информационной безопасности, но и обязательное условие соблюдения законодательства о персональных данных.
На этапе разработки закладывается архитектурная безопасность модели. Принцип «security by design» — встраивать защиту с самого начала, а не добавлять её потом — особенно актуален для ИИ-систем. Меры защиты на этом этапе:
Этап обучения и тестирования — наиболее технически насыщенный с точки зрения мер защиты. Банк России рекомендует семь мер:
Запуск модели в промышленную эксплуатацию не означает завершения работы по обеспечению безопасности — напротив, это начало непрерывного процесса мониторинга и защиты. Банк России рекомендует пять мер защиты на этапе эксплуатации:
безопасность ИИ-системы при эксплуатации — это непрерывный процесс, а не разовое мероприятие. Модель, безопасная при запуске, может стать уязвимой через несколько месяцев работы без должного мониторинга.
В целях минимизации рисков Банк России рекомендует организациям финансового сектора разработать или дополнить существующую политику информационной безопасности специальным разделом, посвящённым разработке и применению ИИ. Политика ИБ для ИИ — это не формальный документ для галочки, а рабочий инструмент управления рисками, определяющий правила и ответственность для всей организации.
Политика должна содержать:
Политика должна закрепить пять целевых свойств, которые организация обязуется обеспечивать:
Каждый сотрудник и система должны иметь только те права доступа к ИИ-системе и данным, которые необходимы для выполнения их функций. Принцип минимальных привилегий снижает риск как внешних атак, так и инсайдерских угроз.
Для обучения и эксплуатации ИИ-модели должен использоваться минимально необходимый объём персональных данных. Это снижает риски нарушения конфиденциальности и упрощает соблюдение требований законодательства о персональных данных.
Политика должна закрепить принципы и стандарты безопасной разработки ИИ-систем, включая требования к анализу уязвимостей, тестированию и документированию на всех этапах жизненного цикла модели.
Сотрудники, работающие с ИИ-системами, должны понимать риски и угрозы, связанные с технологиями ИИ, и иметь чётко определённые полномочия и зоны ответственности. Политика должна предусматривать программу обучения и повышения осведомлённости персонала.
Политика должна закреплять необходимость обеспечения соответствия систем ИИ национальным и (или) международным стандартам, методическим документам, отражающим лучшие практики обеспечения информационной безопасности систем ИИ.
Должны быть чётко определены лица, ответственные за реализацию требований политики, и механизмы контроля их исполнения. Размытая ответственность — одна из главных причин провалов в области информационной безопасности.
Использование публичных ИИ-сервисов и моделей с открытым исходным кодом несёт специфические риски. Политика должна регламентировать: какие сервисы разрешено использовать, в каких целях и при каких условиях, какие данные запрещено передавать во внешние ИИ-системы.
Выходные данные ИИ-системы должны быть соответствующим образом маркированы, чтобы пользователи понимали, что имеют дело с результатом работы ИИ. Одновременно политика должна предусматривать меры по защите информации об архитектуре и параметрах модели от раскрытия.
Политика должна определять чёткий алгоритм действий при выявлении инцидентов информационной безопасности, связанных с ИИ-системами: кто фиксирует, кто расследует, кто принимает решения и в какие сроки.
Рекомендуется закрепить необходимость разработки плана восстановления операционной надежности и порядка действий работников организации в случае возникновения нештатных ситуаций при эксплуатации систем ИИ, в том числе действий по аварийной остановке системы ИИ, в целях оперативного реагирования на нештатные ситуации, связанные с технологиями ИИ
Любая передача данных или моделей третьим сторонам должна предваряться формализованной оценкой рисков информационной безопасности. Политика должна устанавливать требования к такой оценке и критерии допустимого уровня риска.
Технологии ИИ и связанные с ними угрозы развиваются стремительно. Политика должна предусматривать периодический пересмотр и актуализацию на регулярной основе или при существенном изменении условий работы с ИИ.
Политика информационной безопасности — это верхний уровень нормативной базы. Для её реального исполнения организации необходимо разработать дополнительные внутренние документы, регулирующие:
Использование сторонних ИИ-сервисов и компонентов с открытым исходным кодом требует от организации системного подхода к оценке доверия. Банк России рекомендует разрабатывать собственные методики оценки доверия в отношении безопасности данных, моделей ИИ поставщиков услуг и open-source компонентов.
Методика оценки доверия должна учитывать четырнадцать факторов:
Объекты информационно-коммуникационной инфраструктуры поставщика, на базе которых размещаются данные и модели ИИ, должны соответствовать требованиям безопасности, установленным законодательством Российской Федерации и нормативными актами Банка России.
Наличие у поставщика действующей программы поиска уязвимостей свидетельствует о зрелости его подхода к безопасности и готовности к внешней проверке модели независимыми исследователями.
Модель угроз поставщика должна учитывать возможности как внешнего, так и внутреннего нарушителя. Отсутствие модели угроз — серьёзный индикатор незрелости системы безопасности.
Меры защиты, заявленные в проектной и эксплуатационной документации поставщика, должны быть фактически реализованы, а не существовать только на бумаге.
Поставщик должен на регулярной основе предоставлять организации отчёты об аудите и проверках состояния информационной безопасности своей инфраструктуры и ИИ-сервисов.
Использование программных компонентов должно соответствовать лицензионным требованиям. Регулярный аудит лицензий снижает правовые риски организации.
Software Bill of Materials — полный перечень всех программных компонентов, используемых в ИИ-системе, с указанием версий и источников. SBOM позволяет быстро выявить уязвимые компоненты при появлении новых угроз.
Поставщик должен регулярно проводить анализ уязвимостей и тестирование на проникновение своих ИИ-систем и предоставлять организации соответствующие отчёты.
Поставщик должен осуществлять непрерывный мониторинг своей инфраструктуры, обеспечивать реагирование на инциденты информационной безопасности и своевременно информировать организацию о зарегистрированных инцидентах.
Разработка ИИ-систем поставщика должна вестись в соответствии с принципами безопасного жизненного цикла разработки программного обеспечения.
Наличие независимой оценки соответствия или сертификации по требованиям безопасности для процессов разработки модели ИИ является важным подтверждением зрелости поставщика.
Поставщик должен вести учёт всех используемых компонентов с открытым исходным кодом, включая агентов, плагины и интерфейсы взаимодействия, и обеспечивать соответствие их использования требованиям безопасности.
Поставщик должен документировать и предоставлять организации информацию о происхождении данных, используемых для обучения модели ИИ.
Поставщик должн проводить независимую оценку рисков информационной безопасности своего ИИ-решения.
Для обеспечения целостности данных и моделей ИИ поставщиков услуг организациям необходимо использовать средства контроля целостности, прошедшие оценку соответствия ФСТЭК России, по всей цепочке поставки.
Это требование означает: недостаточно проверить целостность данных или модели только на входе в организацию — контроль должен осуществляться на каждом звене цепочки от источника до конечного потребителя.
Почему важна оценка соответствия ФСТЭК России?
Средства контроля целостности, прошедшие оценку соответствия ФСТЭК России, подтверждают свою надёжность независимой экспертизой. Использование несертифицированных средств создаёт риск того, что сам инструмент контроля может быть скомпрометирован.
Если организация передаёт поставщику услуг собственные данные для обучения ИИ-модели, Банк России рекомендует передавать:
Это требование защищает организацию от риска утечки конфиденциальных данных клиентов через инфраструктуру поставщика и снижает правовые риски, связанные с передачей персональных данных третьим сторонам.
Договорная база — важнейший инструмент управления рисками при работе со сторонними поставщиками ИИ. Банк России прямо указывает на два обязательных элемента, которые должны быть включены в договор на предоставление сервисов ИИ:
Договор должен содержать чёткие положения об ответственности поставщика услуг за нарушения информационной безопасности предоставляемых ИИ-сервисов. Это включает как финансовую ответственность, так и обязательства по устранению последствий инцидентов.
Поставщик обязан незамедлительно уведомлять организацию о выявленных уязвимостях и инцидентах информационной безопасности. Договор должен устанавливать конкретные сроки такого уведомления и форму предоставления информации.
Методические рекомендации № 3-МР — это чёткий сигнал от Банка России: регулятор рассматривает информационную безопасность ИИ как системный приоритет для финансового сектора. Организации, которые выстраивают защиту ИИ-систем сегодня, получают несколько ключевых преимуществ:
На основании Методических рекомендаций № 3-МР Банка России организациям финансового сектора необходимо реализовать следующий комплекс мер:
Идентифицировать все ИИ-системы, используемые в организации, и провести оценку рисков информационной безопасности для каждой из них с учётом классификации, приведённой в рекомендациях ЦБ.
Создать специализированную модель угроз, учитывающую специфические угрозы ИИ и способы их реализации, описанных в рекомендациях Банка России.
Внедрить меры защиты для каждого из четырёх подпроцессов безопасности в соответствии с ГОСТ Р 71539-2024: подготовка данных, разработка модели, обучение и тестирование, эксплуатация.
Создать специализированную политику информационной безопасности при разработке и применении ИИ, включающую все обязательные элементы, определённые рекомендациями ЦБ.
Разработать методику оценки доверия к поставщикам ИИ-услуг и open-source компонентов, включая четырнадцать факторов оценки, и включить обязательные требования безопасности в договоры с поставщиками.
Для процессов с высоким уровнем риска информационной безопасности ИИ внедрить обязательную валидацию результатов работы ИИ человеком с правом изменения этих результатов.
Провести обучение сотрудников, работающих с ИИ-системами, по вопросам информационной безопасности ИИ, специфических угроз и правил работы с открытыми моделями и публичными сервисами.
Методические рекомендации Банка России носят рекомендательный, а не обязательный характер. Однако они отражают ожидания регулятора и фактически задают стандарт, которому финансовые организации должны следовать для демонстрации зрелости системы управления рисками.
Рекомендации адресованы организациям финансового сектора, находящимся под надзором Банка России, которые разрабатывают или применяют технологии искусственного интеллекта.
«Отравление» данных — это намеренное внесение злоумышленником искажений в обучающую выборку ИИ-модели. Результат — модель, которая систематически принимает неверные решения в предсказуемых для атакующего ситуациях. Для банка это может означать ошибки в оценке кредитного риска, пропуск мошеннических транзакций или некорректные инвестиционные решения.
Согласно рекомендациям ЦБ, договор должен содержать положения об ответственности поставщика за нарушения информационной безопасности и обязанность поставщика своевременно информировать организацию о выявленных уязвимостях и инцидентах.
О: Рекомендации ЦБ предписывают регулярную актуализацию политики. Конкретная периодичность документом не установлена — организация определяет её самостоятельно с учётом изменений в технологиях ИИ, угрозах и регуляторных требованиях.
С гарантиями лицензированной компании.
Кейсы
Кейсы
Кейсы
