🤖 ИИ в банках: методические рекомендации Банка России

16 июня ЦБ утвердил Методические рекомендации № 3-МР — о защите информации при разработке и применении ИИ на финансовом рынке. Ниже разбираем главное.

Какие риски выделяет ЦБ

— "отравленные", неактуальные или некорректные обучающие данные;
— утечка конфиденциальных данных;
— сбои модели: галлюцинации, дрейф данных, деградация;
— непрозрачность и непредсказуемость решений ИИ;
— риски от подрядчиков и open-source компонентов;
— угрозы операционной надёжности.

Возможные последствия самые разные: от репутационных потерь до полноценного нарушения функционирования и стабильности. Главное, что здесь отмечают авторы — в критичных процессах с высоким риском результаты, сгенерированные ИИ автоматически, должен валидировать человек с правом изменять их.

Угрозы, специфичные для ИИ

Обход и подмена модели, кража и «отравление» обучающих данных, раскрытие и модификация модели, отказ в обслуживании, манипуляции поведением. Способы реализации — фаззинг, бэкдоры, prompt-инъекции, атаки «губка» и состязательные атаки, извлечение данных через диалог с моделью.

Как защищаться

ЦБ предлагает встроить безопасность во все этапы жизненного цикла ИИ (по ГОСТ Р 71539-2024):

— подготовка данных: очистка от аномалий, шифрование при передаче за пределы контролируемой зоны, контроль целостности и подлинности, версионирование изменений, обезличивание и маскирование, гарантированное стирание.
— разработка модели: анализ уязвимостей кода и компонентов, криптографический контроль целостности и подлинности модели/кода, документирование изменений.
— обучение и тестирование: устойчивость к состязательным атакам, конфиденциальные вычисления, федеративное обучение, цифровые метки, тесты на «отравление», пентест, периодическое дообучение.
— эксплуатация: шифрование входных/выходных данных, контроль аномалий, регистрация событий, ограничение потоков входных данных, мониторинг показателей штатной работы.

Политика ИБ

ЦБ рекомендует разработать отдельный документ (политику) по работе с ИИ, в котором будут зафиксированы: целевые свойства (целостность, конфиденциальность, доступность, киберустойчивость, объяснимость), минимальные права и ПДн, правила для открытых моделей, маркировка выходных данных, порядок реагирования на инциденты.

Также необходимо контролировать и саму политику: для этого предлагается разработать внутренние документы, где будут регламентированы процесс аудита и порядок информирования органов управления организации о допущенных нарушениях.

Open-source и подрядчики

Необходима собственная методика оценки доверия. Среди факторов: соответствие инфраструктуры требованиям ИБ и НПА ЦБ, участие модели в Bug Bounty, модель угроз (внешний и внутренний нарушитель), отчёты об аудите, анализе уязвимостей и пентестах, спецификация ПО, отслеживание источников данных, сертификация процессов безопасной разработки, учёт используемых агентов/плагинов/интерфейсов.

Контроль целостности — только средствами с оценкой ФСТЭК по всей цепочке поставки. Подрядчику передаются «очищенные» или синтетические/обезличенные данные. В договоре должна быть закреплена ответственность поставщика за ИБ и обязанность информировать об уязвимостях и инцидентах.

@finance_ciso