Дата публикации: 21-08-2026 06:20:13

Ключевым требованием нового документа становится разработка комплексной ИБ-политики с закреплением ответственности руководства, принципов минимальных прав доступа и обязательной валидации результатов работы ИИ человеком в критически важных процессах при высоких рисках.
Документ получил высокую оценку профессионального сообщества. А как выглядит практическая реализация данных рекомендаций с точки зрения ИБ-аудиторов? На вопросы «Б.О» о текущем состоянии рынка в целом и методиках разработки модели угроз безопасности информации ИИ-систем согласились ответить несколько ИБ-компаний.
«Бумажная» безопасность нам не нужна
Очевидно, что обсуждение необходимо начать с определения исходных позиций, на которых находится большинство финансовых организаций. Поэтому первый вопрос к экспертам: «Каков, по вашему мнению, текущий статус приведения систем ИИ в соответствие с методическими рекомендациями № 3-МР? Какие основные этапы уже завершены большинством банков, а какие вызывают наибольшие трудности при практической реализации?»
Владислав Пец, аудитор по ИБ компании «РАД КОП», полагает: «Текущий статус выполнения Методических рекомендаций Банка России № 3-МР разнится. Причина кроется в дефиците кадров в ИБ-подразделениях и огромном количестве уже внедренных ИИ-моделей. В качестве системной основы для выстраивания требуемого жизненного цикла финансовые организации могут применять международный стандарт ГОСТ Р ИСО/МЭК 42001, который задает требования к процессам планирования, разработки, развертывания, мониторинга и вывода из эксплуатации ИИ-систем на всех этапах. Поэтому статус приведения ИИ-систем в соответствие с методическими рекомендациями может отличаться от топ-5 финансовых организаций и остальных участников финансового рынка».
Таким образом, как считают многие аудиторы, на текущий момент организации финансового рынка проводят инвентаризацию ИИ-систем, их анализ и оценку рисков в соответствии с гл. 2 Методических рекомендаций, а также корректировку внутренней нормативной документации о жизненном цикле моделей ИИ.
«Хотелось бы отметить, что главной целью текущей активности финансовых организаций является уход от “бумажной” безопасности в плоскость выполнения зафиксированных процедур и процессов при работе с системами ИИ», — добавил к словам коллеги Владислав Пец.
В чем еще сходятся эксперты? Наверное, в том, что основными трудностями являются отсутствие методик по моделированию угроз безопасности для систем ИИ, а также необходимость изменения информационной инфраструктуры для митигации рисков, указанных в методических рекомендациях. Также сложности возникают при разработке методики оценки доверия в процессе использования моделей ИИ поставщиков услуг и (или) компонентов технологий ИИ с открытым исходным кодом.
Рынок в начале пути. Но у кого-то есть фора
Размышляя о проделанном пути, Петр Шаповалов, директор по развитию бизнеса компании «Дейтерий», полагает: «По моему мнению, говорить о завершенных этапах у большинства организаций пока рано, рынок — в начале пути. Публичных данных о готовности нет и быть не может: Рекомендации опубликованы в середине июня 2026 года, а один только анализ расхождений в организации среднего размера занимает в лучшем случае полтора-два месяца, полный цикл приведения в соответствие — от года».
Но уже совершенно очевидны те сложности, с которыми финансистам придется столкнуться в будущем, если сконцентрироваться на практической реализации довольно значительного количества пунктов как самих рекомендаций, так и приложений к ним. Но сначала об этапах и длине пути.
Петр Шаповалов предположил: «Дальше всего продвинется разработка политики ИБ, поскольку это документарная работа, она ложится на уже существующий комплект внутренних документов, и гл. 4 № 3-МР вместе с приложением 5 к ним дает готовую структуру из 18 положений. А вот анализ рисков, согласно п. 2.3 Рекомендаций, будет вторым — он опирается на факторы риска из Кодекса этики ИИ на финансовом рынке, выпущенного еще в июле 2025 года. Поэтому у организаций, отработавших Кодекс, есть фора в год. Наконец, моделирование угроз завершат последним, и именно оно вызовет наибольшие трудности».
От редакции. Дело в том, что методика оценки угроз ФСТЭК, на которую ссылаются Рекомендации, создавалась до массового распространения больших языковых моделей (LLM). Из-за этого специфичные для ИИ угрозы представлены в банке данных угроз фрагментарно и модель приходится собирать из методики ФСТЭК, приложений 1–3 к № 3-МР и международных каталогов. Специалистов, владеющих одновременно методологией защиты информации и технологиями машинного обучения, на рынке недостаточно — это основное ограничение.
«Скорость прохождения этих этапов определяется зрелостью процессов, и по этому признаку я делю рынок на три группы. Во-первых, крупнейшие банки с собственными платформами машинного обучения. За их плечами — многолетнее выполнение требований ИБ, локальных нормативов (ГОСТ Р 57580, положения Банка России) и международных стандартов (PCI DSS, ISO/IEC 27001) плюс практика валидации моделей. Поэтому основная работа для них сведется к сопоставлению существующих контролей со структурой № 3-МР, а фактическую готовность покажет внутренний аудит, программу которого нужно дополнить проверками в части ИИ (п. 4.3 Рекомендаций)», — считает Петр Шаповалов.
Ко второй группе в компании «Дейтерий» относят организации без собственной зрелой платформы. ИИ у них тоже есть, но в виде готовых решений поставщиков, например антифрод-сервисов, скоринговых модулей, чат-ботов. Отдельной модели угроз для ИИ или методики оценки поставщиков от них раньше никто не требовал, поэтому начинать придется с разработки этих документов, а центр тяжести работ ляжет на гл. 5 Рекомендаций — оценку доверия к сторонним сервисам.
Наконец, третья группа — небольшие участники, которым предстоит более ранний шаг: определить область применимости, то есть решить, что вообще считать системой ИИ — антифрод от вендора, чат-бот на внешней языковой модели или помощник, встроенный в офисные программы.
От редакции. Общая закономерность простая: чем меньше у организации своего ИИ (собственных нейросетей, обучения моделей на своих данных), тем с более раннего шага начинается ее путь к соответствию ИИ-комплаенсу.
«Помимо моделирования угроз выделю еще две предсказуемо трудные зоны. Первая — генеративные модели: документ написан в логике самостоятельного обучения, а организация, применяющая готовую стороннюю модель, не может ни проверить обучающую выборку, ни пересобрать модель. Поэтому меры приложения 4 к Рекомендациям требуют творческого подхода, поскольку защищать приходится не обучающие данные, которых у организации нет, а входы и выходы готовой модели. Вторая — инвентаризация неформального использования ИИ», — добавил Петр Шаповалов.
В крупных организациях с DLP-системами и жесткими ограничениями рабочих станций этот канал в основном перекрыт. Проблема концентрируется в технологических командах: у разработчиков, специалистов сопровождения и эксплуатации. Ограничения там мягче, возможностей больше, и именно там сосредоточены сторонние модели и инструменты с ИИ, использование которых и требуется отслеживать.
Зарубежный опыт подсказывает лучшие практики и оптимальную последовательность шагов: организации, внедрявшие NIST AI RMF и ISO/IEC 42001, как правило, начинали с инвентаризации и документов и лишь затем переходили к техническим мерам, тратя на это не один год. Тем не менее у отечественного финансового сектора есть преимущество позднего старта: международные каталоги угроз, методики испытаний и готовые инструменты уже существуют, и, опираясь на них, часть пути можно пройти быстрее.
Модели угроз в приоритете
Тему таксономий продолжил Евгений Царев, управляющий RTM Group: «При моделировании угроз безопасности систем ИИ в первую очередь следует ориентироваться на базовый состав угроз, предусмотренный № 3-МР. При этом данный перечень не является исчерпывающим и может быть расширен с учетом особенностей конкретной системы ИИ, используемой модели, источников и способов подготовки данных, архитектуры решения, а также сценариев его эксплуатации в финансовой организации».
От редакции. Дополнительные отраслевые методики могут использоваться как вспомогательные источники для детализации и идентификации специфических угроз, однако ключевым остается риск-ориентированный подход применительно к конкретной системе.
В частности, необходимо учитывать угрозы, возникающие на всех этапах жизненного цикла ИИ: при сборе и подготовке данных, обучении и дообучении модели, ее внедрении, эксплуатации и последующем обновлении. При оценке каждой актуальной угрозы целесообразно рассматривать наиболее неблагоприятный реалистичный сценарий ее реализации и связанные с ним последствия. Именно возможные негативные последствия должны определять требования к системе защиты и набор компенсирующих мер.
«Такой подход применим и к рискам “дрейфа данных1 и “отравления наборов данных2. Они должны рассматриваться как самостоятельные сценарии угроз, для которых определяются возможные последствия и соответствующие меры контроля: мониторинг изменений входных данных и поведения модели, контроль происхождения и целостности наборов данных, управление версиями, проверка качества данных и результатов работы модели, а также процедуры реагирования при выявлении отклонений», — утверждает представитель RTM Group.
По словам Владислава Пеца из компании «РАД КОП», в контексте конкретных финансовых организаций используемые стандарты могут различаться, но основными из них могут быть следующие, которые ответственные сотрудники могут взять себе на заметку для разработки собственных методик оценки доверия, что прямо указано в п. 5.3 № 3-МР:
Национальный стандарт РФ ГОСТ Р 72515-2026 (ИСО/МЭК 12792:2025) «Искусственный интеллект. Таксономия прозрачности систем искусственного интеллекта»;
база знаний о тактиках и техниках злоумышленников в отношении ИИ MITRE ATLAS;
NIST AI 100-2 E2023 «Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations»;
актуальная информация, полученная от ФинЦЕРТ Банка России.
Проблема «отравления данных» может решаться следующими методами еще на этапе обучения:
при помощи санитизации и профилирования данных. Необходимо обеспечить применение статистических методов для выявления аномалий в обучающем наборе до начала обучения модели. Проверка источников данных и целостности данных путем проверки контрольных сумм или электронной подписи, в случае ее использования;
с использованием алгоритмов, устойчивых к зашумленным данным и дифференциальной приватности, для обеспечения безопасности данных на этапе обучения в целях снижения влияния отдельных вредоносных файлов.
Аудитор по ИБ компании «РАД КОП» Данила Хамцов продолжил: «В части “дрейфа данных” рекомендуется встраивать в жизненный цикл моделей ИИ-агентов, которые в реальном времени будут проводить сравнение распределения входящих данных с распределением обучающей выборки. Можно использовать методы периодического дообучения модели на основе обновленных наборов данных и обеспечивать постоянный мониторинг показателей штатного функционирования (производительность, распределение данных, качество)».
От редакции. Также, по мнению экспертов компании «РАД КОП», можно определить метрики качества моделей ИИ (например, точность и полнота ответов) и пороговые значения. Регулярный мониторинг этих метрик и управление дрейфом данных — это не только лучшая практика, но и прямое требование ГОСТ Р ИСО/МЭК 42001, который обязывает организацию внедрять процессы контроля производительности ИИ-систем на протяжении всего их жизненного цикла.
При выходе за пороговое значение рекомендуется обеспечить автоматическое блокирование модели и переключение на резервный контур, в котором, возможно, не будет модели ИИ, или производить уведомление ответственных лиц. Эти методы будут актуальны для систем, обеспечивающих банковские операции или ИБ-процессы, например антифрода.
О «правильных» таксономиях
Петр Шаповалов из компании «Дейтерий» обратил внимание на распространенное заблуждение, связанное с использованием в качестве таксономии OWASP MASVS: «Это стандарт безопасности мобильных приложений, для идентификации угроз ИИ он не предназначен, и в моделях угроз систем ИИ ссылаться на него не стоит. Основной каталог — матрица MITRE ATLAS, международная база тактик и техник атак на системы машинного обучения. Она покрывает весь жизненный цикл, и приложение 1 к № 3-МР выстроено в той же логике».
По словам эксперта, для этапа обучения угрозы берутся из OWASP Machine Learning Security Top 10 и разделов ATLAS об «отравлении данных» и закладках в моделях, а для этапа эксплуатации — из OWASP Top 10 for LLM Applications: определенные в Рекомендациях понятия прямого и непрямого внедрения запроса соответствуют описанным там атакам.
Дополняют картину каталог мер OWASP AI Exchange и классификация состязательных атак NIST AI 100-2. Главное правило простое: угрозы идентифицируются по международным каталогам, где они описаны полнее, а оформляются в терминах методики ФСТЭК — так требования регулятора и реальная картина атак не расходятся. Такой подход согласуется и с ГОСТ Р 56939-2024: в примечании к требованиям по моделированию угроз (п. 5.7.3.1) стандарт рекомендует учитывать наряду с банком данных угроз ФСТЭК иные источники и указывать в модели угроз использованную методологию.
Петр Шаповалов продолжил: «Теперь о “дрейфе данных”. Модель машинного обучения усваивает закономерности из данных за прошлые периоды, а реальность продолжает меняться: появляются новые схемы мошенничества, меняются поведение клиентов и структура платежей. Модель продолжает работать по старым закономерностям, и ее точность постепенно снижается. Это не сбой и не атака, а естественное устаревание модели — его и называют дрейфом. Решается проблема наблюдением плюс дисциплиной обновлений».
Защита от «отравления обучающих наборов» строится на трех элементах: происхождении данных, целостности файлов хранилища, проверке результата. Каждый источник данных документируется, наборы версионируются и защищаются от несанкционированных изменений, обучающие и тестовые наборы хранятся раздельно. Сразу после обучения модель тестируется на независимом наборе. При выявлении признаков «отравления» данные очищаются и цикл повторяется — этот алгоритм описан в п. 14 приложения 4 к № 3-МР.
1. Дрейф данных — изменение характеристик и свойств данных со временем, которое может привести к снижению точности и эффективности моделей ИИ, основанных на таких данных, а также к некорректным выходным данным и решениям. Источник: № 3-МР от 16.06.2026.
2. «Отравленный» набор данных — умышленно модифицированный набор данных, использование которого влечет за собой нарушение функционирования модели ИИ. Источник: № 3-МР от 16.06.2026.
Вставка изображений: Актуальная тема: ИИскрыть лид: Выключитьвыбор редакции: 0Кроспостинг в сети:  Фейсбук ТвиттерКарточка для FB: Жанр сообщения: articleдобавить в rss: Добавить в RSSНе добавлять в ленту: Включить форму покупки видео: Фон: /sites/default/files/imgartical/123wqedsad1231231_5_0.jpgТемная тема статьи: ВыключитьЛевая колонка с pdf: 0

Основное содержимое страницы с новостью.

Схожие новости