ФСБ предложил 12 практик управления ИИ для финансовых учреждений

15 октября 2026 года Финансовый стабильностный совет (ФСБ) опубликовал окончательный отчет "Здравые практики ответственного использования искусственного интеллекта финансовыми учреждениями", в котором предложены 12 практик для финансовых учреждений. Отчет охватывает такие аспекты, как стратегия ИИ, оценка рисков, управление данными, человеческий надзор, кибербезопасность и услуги третьих сторон, отвечая на ряд управленческих вопросов, возникших после ускоренного внедрения генеративного ИИ и ИИ-агентов в последние годы.

Управление ИИ в финансовых учреждениях связывает руководителей бизнеса, команды по рискам и внешних поставщиков.

Этот отчет был окончательно оформлен после публичного запроса мнений и предоставляет международную практическую рамку, которую учреждения могут использовать с учетом своей бизнес-модели и рисков. При реализации финансовым учреждениям необходимо учитывать конкретные законы и регуляторные требования своего региона.

Почему практики должны охватывать так много аспектов, таких как советы директоров, данные, модели и поставщики? Это можно понять на примере распространенного проекта: банк готовит ИИ для помощи в обработке кредитов для малого бизнеса. Команда бизнеса хочет сократить время проверки, команда моделей беспокоится о точности распознавания, команда по соблюдению норм обращает внимание на клиентские данные и объяснение решений, а операционная команда должна гарантировать, что кредитный бизнес продолжится даже после отключения поставщика. Проверка только производительности модели не может ответить на вопросы других сторон. Отчет ФСБ пытается объединить эти решения в едином управленческом процессе.

I. 12 практик охватывают весь цикл управления ИИ

ФСБ разделил 12 практик на две группы. Первые четыре касаются управления на уровне учреждения, а последние восемь охватывают все этапы от внедрения, разработки, развертывания до постоянного использования ИИ.

Четыре практики управления учреждением сначала помещают ответственность, документацию и постоянные корректировки в управленческую рамку.

Часть управления учреждением сначала требует от совета директоров и высшего руководства рассматривать использование ИИ в контексте бизнес-модели, риск-аппетита и общей стратегии. Когда ИИ участвует в кредитной проверке, обслуживании клиентов, мониторинге транзакций или внутренних решениях, руководство должно понимать, где он используется, какую функцию выполняет и какие последствия могут возникнуть в случае ошибки.

Вторая практика подчеркивает разделение ответственности. Учреждения должны четко определить, какие обязанности несут команды по бизнесу, технологиям, рискам, соблюдению норм и аудиту, и включить риски ИИ в существующую систему управления рисками. Третья практика продолжает эту мысль, требуя документировать способы использования ИИ, оценку рисков и соответствующие меры контроля.

Ценность документации заключается в том, что в случае возникновения проблем учреждение может восстановить, какие решения были приняты системой, какие данные использовались, кто принял решение и какие меры контроля действовали в тот момент. Четвертая практика напоминает учреждениям, что технологическая и бизнес-среда могут измениться, и структура управления также должна быть скорректирована.

Эти четыре практики определяют, кто утверждает проект ИИ, кто его поддерживает и кто имеет право его остановить. Совету директоров не нужно проверять параметры модели по отдельности, но он должен знать, в какие важные бизнес-процессы учреждение внедрило ИИ, какие ожидаемые выгоды, и какой риск готово взять на себя. Руководство затем должно перенести общие требования на одобрение продуктов и должностные обязанности. Например, руководитель кредитного бизнеса решает, на каком этапе одобрения может участвовать рекомендация ИИ; команда по рискам модели разрабатывает тесты; сотрудники по соблюдению норм проверяют права клиентов; внутренний аудит оценивает, действительно ли работают указанные меры контроля. Если между должностями существуют пробелы, необходимо назначить окончательного принимающего решения перед запуском.

Документация ФСБ не равнозначна сохранению инструкции по продукту. Один случай использования должен как минимум позволять отслеживать бизнес-цели, источники данных, версии модели, результаты тестирования, места человеческого вмешательства, зависимости от третьих сторон и записи значительных изменений. Если клиент оспаривает результаты одобрения, учреждение может восстановить процесс на основе этих материалов. То же самое касается уже приобретенного офисного программного обеспечения: если продукт, изначально не содержащий ИИ, получает функции автоматического резюме или классификации клиентов, учреждение должно заново подтвердить направление и область использования входных данных.

Последние восемь практик исходят из конкретных сценариев использования и охватывают важность и оценку рисков случаев использования ИИ, выбор моделей и систем, управление данными, объяснимость и прозрачность. Последующие практики также касаются производительности систем, человеческого надзора, рисков в области информационно-коммуникационных технологий (ИКТ) и зависимости от третьих сторон в области ИИ.

12 практик организованы по темам управления, многие требования охватывают несколько этапов использования ИИ. Учреждения могут, исходя из своего масштаба, сложности бизнеса, роли в финансовой системе и степени внедрения ИИ в ключевые бизнес-процессы, определить глубину контрольных мер.

Здесь "оценка важности" (materiality assessment) — это, простыми словами, определение того, повлияет ли конкретное применение ИИ на ключевые бизнес-процессы, права клиентов или решения по рискам. Инструмент для составления протоколов заседаний и система, участвующая в одобрении кредитов или управлении активами клиентов, требуют различной степени проверки. ФСБ предлагает настраивать уровень управления в зависимости от сценария применения и рисков, позволяя учреждениям направлять больше ресурсов на контроль более значительных применений.

Эта система управления жизненным циклом требует от учреждений совместного рассмотрения данных, моделей и бизнес-сценариев. Качество данных для обучения и работы влияет на выводы модели, обновление модели может изменить ее прежние результаты, а способы использования клиентами и сотрудниками могут привести к новым рискам. Поэтому оценка рисков должна охватывать выбор, тестирование, запуск и постоянную работу.

Пятая практика "оценка важности и рисков" подходит для завершения первого раунда на этапе проектирования, а затем должна быть повторена при изменении назначения, расширении объема данных или обновлении модели. База знаний службы поддержки клиентов, отвечающая на время работы продукта, и автоматическая рекомендация клиентам по покупке высокорисковых инвестиционных продуктов сталкиваются с различными последствиями для потребителей. Учреждения могут включить в оценку количество затронутых людей, обратимость решений, чувствительность данных, финансовые риски и возможности человеческого вмешательства, а затем определить, какие тесты и одобрения необходимы. Таким образом, ресурсы будут в первую очередь направлены на системы, которые действительно могут нанести вред клиентам или прервать обслуживание.

Шестая практика касается выбора. На рынке есть как собственные модели, так и внешние API и встроенные функции ИИ в распространенное программное обеспечение. Команды бизнеса обычно сначала смотрят на цену и функции, тогда как команда по рискам должна также задать вопросы: может ли модель стабильно работать в языковых, клиентских и рыночных условиях данного учреждения? Уведомляет ли поставщик об обновлениях? Будут ли данные использоваться для дальнейшего обучения? Если можно получить только ограниченную техническую информацию, учреждение может сначала ограничить назначение и объем данных, а затем продолжать тестирование с использованием своих образцов после запуска, а не считать демонстрацию закупки официальной проверкой.

Седьмая и восьмая практики связаны с данными и объяснениями. Если в исторических данных по кредитам отсутствует определенная категория клиентов, модель может продолжать давать неверные результаты для таких заявок; если сотрудники на переднем крае не могут объяснить результаты рекомендаций, клиентские споры будет сложнее разрешить. Поэтому управление данными охватывает целостность, точность, разрешение источников, доступ и безопасность. Требования к объяснимости также должны быть организованы в зависимости от сценария: предоставление источников для внутреннего поиска и объяснение клиенту решений, влияющих на его возможности финансирования, требуют разной степени ясности. ФСБ позволяет учреждениям устанавливать ограничения на использование, повторную проверку и дополнительные тесты для трудных для объяснения моделей, акцентируя внимание на том, чтобы ответственные за принятие решений имели достаточно информации.

Девятая и десятая практики касаются повседневной работы. Учреждения должны отслеживать, изменяется ли производительность модели в зависимости от бизнес-среды, наблюдать за уровнем ошибок, жалобами, аномальными вызовами и случаями человеческого пересмотра; контрольные показатели должны быть связаны с первоначальным назначением. Человеческий надзор также должен иметь реальные полномочия. Если аудиторы просто нажимают "согласен" на экране, не видя оснований и не имея права изменять выводы, надзор будет затруднен. Для высокорисковых процессов можно установить обязательное вторичное подтверждение, выборочное повторное обследование и автоматические пороги остановки; запись причин, по которым человек принял или отклонил рекомендации модели, может, в свою очередь, улучшить тестирование.

Последние две практики возвращают ИИ в технологическую и цепочку поставок. Интерфейсы моделей, соединители данных и инструменты агентов могут стать новыми точками атаки, и кибербезопасные учения должны охватывать инъекции подсказок, утечки ключей, неправильные вызовы инструментов и сбои внешних услуг. Риски поставщиков также включают производительность моделей, прозрачность, качество данных для обучения и работы, цепочки субподрядчиков и централизованные зависимости. Если несколько банков одновременно используют несколько облачных платформ или базовых моделей, сбой отдельного поставщика может иметь более широкие последствия для бизнеса. Учреждения должны как минимум знать, где находятся ключевые зависимости, и кто возьмет на себя ответственность в случае прерывания важного бизнеса.

II. Открытые мнения добавили детали на уровне операций в окончательный проект

ФСБ опубликовал консультационный документ в июне 2026 года и завершил сбор мнений 22 июля. В итоге было получено около 160 отзывов от банков, страховых компаний, других финансовых учреждений, отраслевых ассоциаций, поставщиков технологий, академического сообщества и государственного сектора. В целом, респонденты поддержали подход, основанный на принципах, подчеркивающий пропорциональность; в то же время они также указали на практические трудности в реализации.

Окончательный проект сохранил принципиальную направленность и технологическую нейтральность, а также добавил объяснения о том, как небольшие учреждения могут использовать существующие должности и внешние профессиональные возможности для реализации управления. В раздел примеров были добавлены практики страховых компаний, управляющих активами и платежных сервисов, что сделало эти практики применимыми для большего числа типов учреждений. ФСБ рассматривает примеры как демонстрацию практических путей, конкретные меры все еще должны быть адаптированы к конкретным условиям учреждений.

Зависимость от третьих сторон в области ИИ стала одной из наиболее обсуждаемых проблем. Когда финансовые учреждения используют внешние модели или встроенные ИИ-продукты, информация о моделях, данных и цепочках поставок часто бывает ограниченной, что усложняет независимую оценку рисков. Увеличение доли нескольких ключевых поставщиков в инфраструктуре ИИ также заставляет учреждения задуматься о том, как переключить поставщиков и восстановить бизнес в случае сбоя услуг.

Зависимость от третьих сторон и кибербезопасность также вошли в управление жизненным циклом ИИ.

Окончательный проект, таким образом, расширил обсуждение зависимости от третьих сторон в области ИИ, охватывая встроенный ИИ, субподрядные услуги и зависимости в цепочке поставок, и подчеркивая управление концентрацией, непрерывность бизнеса и планы выхода. Планы выхода для ключевых услуг, проще говоря, это то, как учреждение может переключить услуги или поддерживать работу бизнеса в случае остановки поставщика, прекращения контракта или превышения рисков, которые учреждение может вынести.

В ходе переговоров по контракту финансовые учреждения могут получить информацию по четырем вопросам: как поставщик обрабатывает входные и выходные данные, как уведомляются о значительных изменениях моделей или услуг, какие журналы могут быть предоставлены в случае инцидента и как данные возвращаются или удаляются после прекращения сотрудничества. Крупные поставщики не всегда принимают индивидуальные условия для каждого клиента, но учреждения могут снизить зависимость от единой точки, ограничив объем доступа, сохранив внутренние резервные процессы и регулярно тестируя альтернативные пути. Так называемые планы выхода должны в конечном итоге касаться людей, форматов данных и времени, необходимого для преобразования, а не оставаться на уровне "можно прекратить" в контракте.

ИИ-агенты также стали важным объектом изменений. Они отличаются от обычных инструментов генерации текста тем, что могут выполнять несколько шагов после установки цели, некоторые системы также могут вызывать внешние инструменты или получать доступ к бизнес-данным. В отзывах были предложены контрольные идеи, такие как авторизация перед выполнением, минимальные права, неизменяемые записи операций и мониторинг в режиме реального времени. Окончательный отчет добавил соответствующие соображения и указал, что эта часть практики все еще находится в стадии разработки и в будущем может потребовать более глубоких указаний.

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

III. Для финансовых учреждений ключевая работа заключается в интеграции принципов в повседневные процессы

Эти 12 практик должны быть внедрены внутри учреждения, прежде всего, необходим список использования ИИ, который может постоянно обновляться. Список должен указывать, для какого бизнеса служит система, кто за нее отвечает, на каких клиентов или ключевые процессы она повлияет, от каких внешних моделей и облачных услуг она зависит, а также как при возникновении аномалий приостановить или переключить работу. Возможности ИИ также могут быть встроены в распространенные офисные, клиентские или аналитические продукты, поэтому список должен охватывать повседневное программное обеспечение и бизнес-инструменты, помимо закупаемых проектов.

Во-вторых, оценка рисков ИИ должна начинаться с этапов закупки и тестирования. Команда бизнеса объясняет цели применения, техническая команда оценивает модели и данные, а сотрудники по рискам и соблюдению норм определяют влияние на решения клиентов, ключевые бизнес-процессы или юридические обязательства. После запуска системы учреждение должно продолжать наблюдать за производительностью и проверять, приводят ли обновления данных или моделей к новым рискам.

Когда пути принятия решений модели трудно объяснить, учреждения могут снизить риски, ограничив назначение, увеличив человеческую проверку или устанавливая дополнительные тесты. Эти "компенсационные меры" используются для смягчения рисков, связанных с недостаточной прозрачностью модели, и должны быть реализованы вместе с юридическими обязательствами по защите данных и правам потребителей.

Рабочий процесс также должен различать "эксперимент" и "производство". Экспериментальная среда может использовать анонимизированные или синтетические данные, ограничивать пользователей и количество вызовов; перед подключением реальных клиентских данных и бизнес-системы необходимо совместно подтвердить данные и права со стороны бизнеса, технологий, безопасности и юридического отдела. Одобрение запуска не должно быть конечной точкой. Учреждение может установить триггеры для изменений версий: при замене базовой модели, подключении новых внешних инструментов, расширении до новых клиентских групп или изменении уровня автоматизации автоматически запускается повторная проверка. Многие риски ИИ возникают после постепенного расширения назначения, в то время как первоначальные материалы проектирования остаются на прежнем низкорисковом уровне.

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

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

Для ИИ-агентов также необходимо четко обозначить границы авторизации: к каким данным они могут получить доступ, какие инструменты могут вызывать, какие действия должны подтверждаться сотрудниками и как при возникновении аномалий приостановить задачи. Надзорные сотрудники должны иметь реальные полномочия вмешиваться, достаточно времени и доступные записи выполнения.

Например, если учреждение разрешает агенту организовывать материалы заявок клиентов, он может получить доступ к определенной папке, создать список для проверки, но изменение кредитного лимита и отправка решений должны оставаться за сотрудниками. Если один и тот же агент должен выполнять три действия: запрос, запись и уведомление, система может выдавать краткосрочные удостоверения на разных этапах и записывать каждый вызов. Таким образом, команда по рискам видит не абстрактную метку "использовался агент", а цепочку выполнения, которую можно тестировать, проверять и приостанавливать.

На практике 12 практик можно сгруппировать в четыре категории поставляемых материалов: принципы использования ИИ, утвержденные советом директоров, постоянно обновляемый список приложений и зависимостей, оценки и записи тестирования для каждого важного случая использования, а также планы по приостановке и восстановлению в случае аномалий. Эти четыре категории материалов взаимосвязаны. Список информирует руководство о том, какие проекты существуют; оценки определяют, какие меры контроля более строгие; тесты подтверждают, эффективны ли меры контроля; записи инцидентов способствуют изменению правил. Небольшие учреждения также могут использовать существующие процессы заседаний по рискам и закупкам, главное — обеспечить отслеживаемость ответственности и доказательств.

IV. Это набор управленческих рекомендаций, реализация которых зависит от юрисдикции

ФСБ позиционирует эти 12 практик как практический инструмент, который можно адаптировать к условиям учреждения. При применении этой рамки учреждения все же должны сопоставить случаи использования ИИ с конкретными требованиями своей юрисдикции в области защиты данных, прав потребителей, управления аутсорсингом, рисков моделей или управления финансовыми учреждениями.

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

С точки зрения международной политики, подход ФСБ имеет еще одну ценность: разные юрисдикции могут рассматривать применение ИИ финансовыми учреждениями через схожие проблемы. Регуляторы могут не использовать одну и ту же таблицу, но их будет интересовать, кто несет риски, как модели работают в ключевых бизнес-процессах и как клиенты могут пострадать в случае сбоя внешних зависимостей. Если учреждения смогут подготовить вышеуказанные доказательства, им будет легче объяснить свои меры контроля в ответ на требования защиты данных, прав потребителей и надзорных норм в разных регионах.

Этот контент предоставляется исключительно в общих информационных целях и не является финансовым, инвестиционным, юридическим или налоговым советом. Любые мероприятия, вознаграждения, онлайн-акции или связанная с ними информация, упомянутые в настоящем документе, не должны рассматриваться как рекомендация, приглашение к покупке, продаже, торговле или иной сделке с какими-либо криптоактивами. Криптоактивы очень волатильны и могут привести к убыткам. Доступность услуг, продуктов WEEX и связанных с ними событий может варьироваться в зависимости от региона. Вы несете ответственность за обеспечение того, чтобы ваше участие соответствовало применимым местным законам и нормативным актам.