Безопасность систем искусственного интеллекта для финтех-организаций
Статья создана
Обновлена 16 сентября 2026 г.
Приложение содержит справочную матрицу соответствия требований настоящего Стандарта внешним рекомендациям по обеспечению информационной безопасности систем искусственного интеллекта.
Источник внешних рекомендаций
Методические рекомендации Банка России по обеспечению информационной безопасности при разработке и применении искусственного интеллекта на финансовом рынке №3-МР от 16.06.2026.
Статус приложения
Приложение является справочным и не вводит самостоятельных нормативных требований. Действия в графе «Действия пользователя» являются рекомендуемыми мерами закрытия дефицита; их обязательность возникает только после утверждения во внутреннем нормативном документе организации. Матрица соответствия не заменяет требования настоящего Стандарта.
Приложение применяется при проектировании, разработке, внедрении и эксплуатации ИИ-решений, включая:
- приложения с использованием внешних и внутренних AI API;
- RAG-системы, базы знаний, векторные хранилища и процессы приема данных;
- ИИ-агентов, MCP-серверы, MCP Gateway и подключаемые инструменты;
- ML-модели, датасеты, процессы обучения, тестирования, дообучения и развертывания;
- облачную инфраструктуру, используемую для ИИ-решения.
Статусы соответствия
| Статус | Значение |
|---|---|
| Учтено | Требование полностью покрыто обязательными положениями Стандарта; достаточно выполнить связанные требования AI-* и сохранить их свидетельства. |
| Частично | В Стандарте предусмотрены связанные меры, но для полного соответствия внешней рекомендации их недостаточно; дополнительные действия из строки являются рекомендуемой компенсирующей мерой, которую организация утверждает своим внутренним документом. |
| Не учтено | В Стандарте отсутствует равнозначное требование; указанная мера рекомендуется к реализации через документацию проекта, внутренний нормативный документ или план мероприятий до ввода решения в эксплуатацию. |
| Неприменимо | Требование не относится к конкретному ИИ-решению; решение о неприменимости рекомендуется документировать владельцем ИИ-решения и согласовывать с функцией ИБ. |
Распределение ответственности
В матрице используются следующие роли:
| Роль | Ответственность |
|---|---|
| Пользователь | Организация, использующая сервисы Yandex Cloud и эксплуатирующая ИИ-решение; отвечает за архитектуру решения, настройки сервисов, данные, доступы, процессы и выполнение требований настоящего Стандарта. |
| Yandex Cloud | Поставщик облачной инфраструктуры и управляемых сервисов; отвечает за безопасность облачной платформы в пределах модели разделения ответственности и условий предоставления соответствующего сервиса. |
| Совместная ответственность | Требование выполняется Yandex Cloud на уровне платформы, а пользователь — через корректную настройку сервиса, ограничение доступа, включение журналирования, применение криптографических ключей и иные предусмотренные сервисом меры. |
Если в графе «Действия пользователя» указано, что требование выполняет Yandex Cloud, это относится только к защите платформенной части соответствующего управляемого сервиса. Пользователь сохраняет ответственность за конфигурацию сервиса, учетные записи, права доступа, данные, интеграции, прикладной код и соблюдение требований к своему ИИ-решению.
Матрица соответствия
Управление ИИ-рисками
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Учитывать ИБ-риски ИИ при выборе сценария, технологии, архитектуры и мер защиты | Частично | Стандарт устанавливает технические меры для AI API, RAG, MCP, данных и облачной инфраструктуры, но единый процесс оценки допустимости сценариев и ИБ-рисков ИИ-решения требует формализации | AI-SDLC1 |
До начала разработки зарегистрировать сценарий в реестре ИИ-решений; провести оценку ИБ-рисков, критичности процесса, допустимого уровня автоматизации и необходимости human-in-the-loop; утвердить результаты владельцем бизнеса и ИБ | Пользователь |
| Оценивать последствия для прав субъектов, операций, убытков, репутации, цепочки поставок и устойчивости организации | Не учтено | В Стандарте предусмотрены контроли конфиденциальности и соответствия требованиям, но нет формализованной оценки последствий по указанным категориям | AI-SDLC1, AI-COMPLY1 |
Выполнить и задокументировать оценку последствий до ввода ИИ-решения в эксплуатацию; определить недопустимые сценарии, ограничения на автоматизацию и условия эскалации человеку | Пользователь |
| Применять human-in-the-loop для высокорисковых автоматических операций | Частично | Стандарт предусматривает подтверждение отдельных действий через MCP Gateway, но не устанавливает общее правило ручной валидации результатов ИИ в критичных процессах | AI-AGENT-HITL1 |
Определить перечень критичных операций; запретить автономное выполнение таких операций; обеспечить возможность проверки, отклонения и изменения результата человеком; фиксировать решение и ответственного в журнале | Пользователь |
| Разрабатывать модель угроз ИИ-системы | Частично | Стандарт описывает границы контуров Ingress, Identity, Application, Model, Data/RAG, Egress и Logging/Monitoring, однако обязанность разработки модели угроз и ее актуализации должна быть закреплена явно | AI-SDLC1 |
Разработать модель угроз для каждого ИИ-решения; включить активы, интерфейсы, внешнего и внутреннего нарушителя, ИИ-специфичные угрозы, сценарии атак и связанные контроли; пересматривать модель угроз при существенных изменениях | Пользователь |
| Обеспечивать пропорциональность мер уровню риска и последствиям | Не учтено | В Стандарте перечислены меры защиты, но правило выбора и обоснования достаточности мер в зависимости от риска не определено | AI-SDLC1 |
Для каждого ИИ-решения установить уровень риска; выбрать минимальный набор обязательных контролей в зависимости от уровня риска; документировать обоснование исключений и компенсирующих мер | Пользователь |
Данные и приватность
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Контролировать происхождение, качество, структуру, формат, согласованность и метки обучающих и тестовых данных | Частично | Стандарт предусматривает контролируемый прием данных в RAG, DSPM, классификацию и защиту данных; контрольные точки качества для обучающих и тестовых наборов данных ML раскрыты недостаточно явно | AI-DATA1, AI-DATA5, AI-DATA-CHECK1 |
Вести паспорт каждого датасета; фиксировать источник, владельца, правовое основание обработки, версию, формат, классификацию, качество и результаты проверок; не использовать датасеты, не прошедшие утвержденные проверки | Пользователь |
| Очищать аномалии в обучающих и тестовых данных и повторно проверять данные после очистки | Частично | Имеются контроли входных данных и RAG-источников, но отдельный обязательный процесс для обучающих и тестовых наборов данных отсутствует | AI-DATA-CHECK1, AI-DATA3 |
Утвердить процедуру выявления, очистки и повторной проверки аномалий; сохранять результаты проверок и решение о пригодности датасета к использованию | Пользователь |
| Шифровать данные при передаче и вне контролируемой зоны | Учтено | Стандарт предусматривает TLS, VPC, KMS и иные механизмы защиты данных в облачном контуре | AI-CRYPT1, AI-NET2 |
Использовать TLS для всех внешних и внутренних соединений; использовать сетевую сегментацию и частную конечную точку там, где она официально документирована для выбранного сервиса; включить шифрование и управление ключами для поддерживаемых сервисов | Совместная ответственность: Yandex Cloud обеспечивает платформенные механизмы защиты сервиса; пользователь обязан корректно включить и настроить доступные механизмы |
| Обеспечивать целостность и аутентичность наборов данных | Частично | Object Lock, контроль доступа, аудит и журналирование снижают риск несанкционированной модификации, но обязательная проверка целостности каждого датасета не определена | AI-DATA6 |
Применять контрольные суммы, цифровые подписи либо иной утвержденный механизм контроля целостности; ограничить изменение датасетов; проверять целостность перед обучением, тестированием и загрузкой в RAG | Пользователь |
| Обеспечивать версионирование и трассировку изменений датасетов | Частично | Стандарт предусматривает инвентаризацию и элементы цепочки происхождения, но не устанавливает полное воспроизводимое версионирование | AI-DATA6, AI-REL1 |
Вести версии датасетов и журнал изменений; обеспечить связь «источник — версия датасета — версия модели — результаты тестирования — версия развертывания» | Пользователь |
| Обезличивать ПДн и маскировать информацию ограниченного доступа | Учтено | Стандарт предусматривает обнаружение и защитное преобразование ПДн до границы доверия, контроль преобразования и аудит; DSPM только обнаруживает данные, а KMS и Lockbox защищают ключи и таблицы соответствия, но сами по себе не выполняют маскирование | AI-COMPLY-PII1, AI-COMPLY-PII3, AI-COMPLY-PII4, AI-DATA4 |
Классифицировать данные до передачи в ИИ-систему; удалить, обезличить или замаскировать ПДн и иную чувствительную информацию, если их обработка не требуется и не разрешена; контролировать RAG-источники и промпты | Пользователь |
| Гарантированно уничтожать данные по завершении обработки или срока хранения | Частично | Стандарт регулирует жизненный цикл данных и облачных ресурсов, но прямое требование безопасного уничтожения данных требует уточнения | AI-DECOM1 |
Установить сроки хранения; реализовать удаление данных, резервных копий, индексов и временных артефактов; вести подтверждения выполнения удаления | Совместная ответственность: Yandex Cloud выполняет удаление данных на уровне платформы в соответствии с характеристиками сервиса; пользователь обязан инициировать удаление ресурсов и данных, установить сроки хранения и проверить отсутствие прикладных копий |
| Передавать внешнему поставщику только очищенные, синтетические, обезличенные или специально подготовленные данные | Частично | Стандарт содержит маскирование персональных данных и ограничения передачи, но не устанавливает явного правила для внешнего обучения или внешних AI API | AI-COMPLY3, AI-DATA4, AI-NET3 |
До передачи данных внешнему поставщику провести оценку допустимости; по умолчанию использовать синтетические, обезличенные или очищенные данные; запретить передачу секретов, ПДн и иной чувствительной информации без документированного основания и согласования | Пользователь |
Модель, разработка и поставка
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Анализировать уязвимости модели, кода и компонентов на всем жизненном цикле | Частично | Стандарт предусматривает SBOM, Container Registry и меры защиты цепочки поставок, но периодичность и минимальный охват проверок требуют явного закрепления | AI-SUPPLY4, AI-SUPPLY5 |
Включить SAST, DAST, SCA и проверку уязвимостей образов в CI/CD; вести SBOM; определить источники сведений об уязвимостях, сроки устранения и критерии блокировки релиза | Пользователь |
| Проверять криптографическую целостность и подлинность модели, кода и контейнеров | Частично | Используются дайджест, реестр и KMS, но прямое требование подтверждать доверенную версию перед применением отсутствует | AI-MODEL1, AI-SUPPLY2, AI-SUPPLY3 |
Подписывать или иным образом подтверждать доверенные версии артефактов; разрешать развертывание только из доверенного реестра; проверять дайджест, подпись или иной идентификатор целостности перед развертыванием | Совместная ответственность: Yandex Cloud предоставляет механизмы реестра, IAM, KMS и журналирования; пользователь обязан организовать доверенную цепочку сборки и проверки |
| Отслеживать изменения кода, модели и документации | Частично | В Стандарте предусмотрены развертывания и откаты, Audit Trails и инвентаризация, но полная воспроизводимая трассировка изменений должна быть усилена | AI-REL1, AI-CORE5, AI-AUDIT1 |
Вести неизменяемый журнал изменений кода, конфигураций, промптов, датасетов и документации модели; связать изменение с автором, согласованием, тестами и версией развертывания | Пользователь |
| Применять безопасный жизненный цикл разработки ИИ | Частично | Стандарт опирается на ML-DevSecOps, но полный безопасный SDLC для ИИ-модели должен быть формализован | AI-SDLC1, AI-REL1, AI-REL2 |
Внедрить AI-SDLC: требования, оценка рисков, модель угроз, подготовка данных, разработка, тестирование, согласование, развертывание, мониторинг, переобучение, вывод из эксплуатации | Пользователь |
| Защищать от подмены модели | Частично | Реестр, дайджест, аудит и контролируемое развертывание уменьшают риск, но отдельный контроль подмены модели не выделен | AI-MODEL1, AI-REL2 |
Разрешать использование только утвержденных версий модели; ограничить права на публикацию и развертывание; проверять происхождение и идентификатор модели перед запуском; обеспечить откат на предыдущую доверенную версию | Пользователь |
| Применять цифровые метки моделей, данных или выходов, когда это требуется риском или регулированием | Не учтено | Явное требование о «водяных знаках» или аналогичных цифровых метках отсутствует | — | Оценить необходимость цифровых меток для защиты авторства, трассировки происхождения и выявления подмены; при необходимости выбрать технологию, определить область применения и порядок проверки | Пользователь |
Тестирование и устойчивость
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Тестировать модель на отравление после обучения | Не учтено | Контроли приема данных в RAG и защиты данных предусмотрены, но тест на отравление после обучения отсутствует | AI-DATA-CHECK1 |
Включить тестирование на отравление в программу приемки и периодической проверки модели; определить сценарии, критерии приемки и порядок реагирования при выявлении признаков отравления | Пользователь |
| Разделять обучающие и тестовые наборы, их хранение и доступ | Частично | IAM, VPC, ACL, KMS и секреты создают основу для сегрегации, однако независимость тестового набора от обучающего набора должна быть закреплена | AI-DATA3, AI-DATA5, AI-TRAIN1 |
Использовать отдельные наборы, учетные записи или хранилища для обучающих и тестовых данных; запретить несанкционированное изменение тестового набора; предоставлять доступ по принципу минимальных привилегий | Пользователь |
| Проверять устойчивость к состязательным атакам | Не учтено | Стандарт рассматривает промпт-инъекцию и фильтрацию входа, но не устанавливает методы устойчивости ML-модели к состязательным атакам | — | Для применимых моделей проводить состязательное тестирование; при необходимости применять состязательное обучение, защитную дистилляцию, ансамблевые методы или иные меры; фиксировать результаты и ограничения модели | Пользователь |
| Проводить тестирование модели на проникновение по сценариям, специфичным для ИИ | Частично | В Стандарте есть защита API, WAF, Guardrails, RAG и MCP, но регулярный тест самой модели не формализован | AI-APP-WAF1, AI-APP-INJECT1, AI-CONTENT2 |
Проводить приемочное и периодическое тестирование, включающее обход ограничений, промпт-инъекцию, косвенную промпт-инъекцию через RAG, фаззинг, извлечение, инверсию, отравление, DoS и истощение ресурсов; устранять выявленные критичные недостатки до промышленной эксплуатации | Пользователь |
| Контролировать дрейф данных и модели, а также деградацию модели | Частично | В Стандарте предусмотрены журналирование и мониторинг, но ИИ-специфичные SLI/SLO, пороги и процесс управляемого переобучения должны быть определены | AI-MON-ANOMALY2, AI-DATA5 |
Определить метрики качества, безопасности и дрейфа данных и выходных данных; установить пороги, владельцев и порядок реагирования; переобучать и повторно валидировать модель только на проверенных данных | Пользователь |
Эксплуатация и мониторинг
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Контролировать и очищать аномалии во входных и выходных данных | Учтено | Стандарт предусматривает Guardrails, контент-фильтрацию, защиту от инъекций, проверки API и меры защиты RAG-контура | AI-CONTENT1, AI-CONTENT2, AI-APP-WAF1 |
Настроить и включить применимые Guardrails, фильтры контента и проверки входа/выхода; определить правила блокировки, маскирования, эскалации и регистрации срабатываний | Совместная ответственность: Yandex Cloud предоставляет поддерживаемые сервисные механизмы; пользователь обязан включить их, настроить политики и обработку срабатываний |
| Защищаться от прямых и непрямых промпт-инъекций | Учтено | Стандарт содержит требования AI-APP-INJECT1, контентные ограничения, Guardrails, контролируемые RAG-источники и защиту API/MCP | AI-APP-INJECT1, AI-APP-INJECT2 |
Реализовать фильтрацию и валидацию входных данных; ограничить инструменты и полномочия агентов; использовать список разрешенных RAG-источников; проводить тесты на прямую и косвенную промпт-инъекцию | Пользователь |
| Регистрировать события работы модели, пользователей и запросов | Учтено | Стандарт предусматривает Cloud Logging, Audit Trails и журналирование операций AI Studio, API, MCP Gateway, Kubernetes и связанных сервисов; платформенные журналы не образуют полной сквозной трассировки — прикладная трассировка модельного запроса реализуется отдельно | AI-AUDIT1, AI-MON-TRACE1 |
Включить журналирование для используемых сервисов; реализовать прикладную сквозную трассировку запроса; передавать журналы в Yandex SIEM при наличии требования; обеспечить хранение журналов в соответствии с политикой хранения и защиту от несанкционированного изменения | Совместная ответственность: Yandex Cloud обеспечивает сервисные журналы в объеме возможностей сервиса; пользователь обязан включить журналирование, настроить экспорт, хранение и мониторинг |
| Ограничивать число, частоту, размер и параметры запросов | Частично | WAF, API Gateway и Smart Web Security поддерживают ограничение частоты, но лимиты для токенов, сложности и потребления ресурсов ИИ должны быть определены отдельно | AI-NET7, AI-APP-WAF1, AI-AGENT2 |
Установить квоты и лимиты, максимальный размер запроса, лимиты токенов, таймауты и бюджет ресурсов; применять ограничения на уровне API Gateway, WAF, приложения и модели | Совместная ответственность: Yandex Cloud предоставляет механизмы ограничения трафика для поддерживаемых сервисов; пользователь обязан задать значения лимитов и контролировать их достаточность |
| Контролировать штатную работу, качество и поведение модели | Частично | Наблюдаемость и журналы предусмотрены, но набор ИИ-специфичных SLI/SLO и пороги деградации не определены | AI-MON-ANOMALY2 |
Установить SLI/SLO для доступности, задержек, ошибок, качества, безопасности, стоимости, дрейфа данных и выходных данных; настроить уведомления, эскалацию и регулярный анализ отклонений | Пользователь |
| Предотвращать отказ в обслуживании и истощение ресурсов | Частично | API Gateway, WAF и сетевые ограничения покрывают базовый DoS-контур, но специализированные меры против исчерпания ресурсов необходимо детализировать | AI-NET7, AI-AGENT2 |
Настроить квоты и лимиты, лимиты токенов, ограничения параллельной обработки запросов, таймауты и защиту от аномально дорогих запросов; тестировать сценарии исчерпания ресурсов до ввода в эксплуатацию | Совместная ответственность |
| Иметь план восстановления и аварийной остановки ИИ | Частично | Стандарт предусматривает откат и управляемую инфраструктуру, но механизм аварийной остановки ИИ-системы, роли и сценарии восстановления должны быть закреплены | AI-REL2, AI-AGENT2 |
Разработать план реагирования на ИИ-инциденты; определить критерии срабатывания механизма аварийной остановки ИИ-системы, роли, порядок изоляции модели или RAG-источника, отката, сохранения артефактов, уведомления и восстановления | Пользователь |
Управление поставщиками и Open Source Software (OSS)
| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Утвердить внутреннюю политику ИБ при разработке и применении ИИ | Частично | Стандарт содержит технические и организационные нормы, но не заменяет внутреннюю политику организации | AI-SDLC1 |
Утвердить политику ИБ ИИ с областью действия, ролями, классификацией сценариев, порядком исключений, контролем исполнения и ответственностью за нарушения | Пользователь |
| Назначить руководителя, ответственного за ИБ ИИ | Не учтено | Технические роли и IAM описаны, но владелец политики ИБ ИИ не определен | — | Назначить ответственное должностное лицо; закрепить полномочия по утверждению политики, контролю рисков, эскалации существенных инцидентов и отчетности руководству | Пользователь |
| Проводить аудит исполнения политики и информировать руководство о нарушениях | Частично | Audit Trails, Cloud Logging и Yandex SIEM поддерживают сбор доказательств, но аудит и отчетность должны быть определены процессно | AI-AUDIT1 |
Установить периодичность внутреннего аудита; формировать отчеты о соответствии, исключениях, инцидентах и рисках; направлять результаты руководству в установленном порядке | Пользователь |
| Обучать работников безопасной разработке и применению ИИ | Не учтено | Отдельное требование к обучению разработчиков, MLOps, ИБ, владельцев продукта и пользователей отсутствует | — | Внедрить программу обучения по угрозам ИИ, работе с чувствительными данными, промпт-инъекциями, RAG, MCP, безопасной разработке и процедурам реагирования | Пользователь |
| Предоставлять минимально необходимые права доступа | Учтено | Стандарт подробно описывает IAM, RBAC, сервисные аккаунты, роли AI Studio, Kubernetes RBAC и CIEM | AI-IAM-LEASTPRIV1, AI-IAM5 |
Использовать отдельные сервисные аккаунты; выдавать права по принципу минимальных привилегий; проводить регулярный пересмотр доступов; запрещать совместное использование учетных записей | Совместная ответственность: Yandex Cloud предоставляет IAM и сервисные роли; пользователь назначает права, организует пересмотр и отключает неактуальные доступы |
| Устанавливать правила безопасного использования публичных ИИ-сервисов | Частично | Для внешних AI API и SaaS предусмотрены список разрешенных получателей, TLS и аспекты соответствия требованиям, но единая пользовательская политика должна быть утверждена отдельно; закрытый сетевой путь к внешнему поставщику заявляется только при наличии его официальной документации | AI-NET3, AI-COMPLY3, AI-COMPLY4 |
Утвердить перечень разрешенных публичных ИИ-сервисов; определить классы данных, которые запрещено передавать; установить порядок согласования исключений и контроля использования | Пользователь |
| Учитывать риски моделей с открытым исходным кодом, компонентов, агентов, плагинов и инструментов | Частично | SBOM, Container Registry и контроли цепочек поставок предусмотрены, но реестр OSS-компонентов и оценка их рисков должны быть формализованы | AI-SUPPLY1, AI-SUPPLY4, AI-SUPPLY5 |
Вести реестр OSS-моделей, библиотек, агентов, плагинов, MCP-серверов и инструментов; поддерживать SBOM; проводить оценку лицензий, происхождения, уязвимостей и уровня доверия до использования | Пользователь |
| Оценивать доверие к поставщику, его данным, модели и компонентам | Частично | Технические меры для облачной среды подробно описаны, но собственная методика оценки поставщика отсутствует | AI-SUPPLY6 |
До заключения договора и периодически далее оценивать поставщика: модель угроз, практики безопасного жизненного цикла разработки, аудит, лицензии, SBOM, раскрытие уязвимостей, результаты тестирования на проникновение, SLA и условия обработки данных | Пользователь |
| Получать отчеты поставщика об ИБ-аудитах, лицензиях, уязвимостях и тестированиях на проникновение | Не учтено | Контрактное и процессное требование отсутствует | AI-SUPPLY6 |
Включить в договор или процедуру закупок обязательство поставщика предоставлять предусмотренные доказательства безопасности и уведомления об изменениях, уязвимостях и инцидентах | Пользователь |
| Закреплять договорную ответственность поставщика за ИБ и уведомление об инцидентах | Не учтено | Стандарт не заменяет договорные условия и не содержит обязательства включать их в договор | AI-SUPPLY6 |
Включить в договор требования к ИБ, сроки уведомления об уязвимостях и инцидентах, порядок взаимодействия при расследовании, требования к возврату или удалению данных и ответственность сторон | Пользователь |