ИИ для риск-функции банка: шесть модулей от LLM до автономных агентов

Для банковских клиентов я много лет работал через закрытые проекты, и публично могу называть далеко не всех. Но за закрытостью проектов остался вполне открытый материал — учебная программа для риск-подразделений банков. Она собиралась не на пустом месте: в её основе — реальные задачи, с которыми ко мне приходили банки, реальные ошибки, которые мы разбирали на пилотах, и рекомендации Банка России из Кодекса этики в сфере ИИ.

В этой статье — разбор программы по модулям. Если вы работаете в риск-функции крупного банка и думаете, чему и в каком порядке учить команду, — это для вас. Я не буду пересказывать всё содержимое (оно большое), но покажу логику: почему модули идут в таком порядке, какая в каждом из них главная мысль и где ловушки, в которые команды попадают чаще всего.

Программа в её нынешнем виде разворачивается в одном из крупных российских банков с апреля 2026 года. Параллельно ядро методики используется в однодневной фасилитации AI Café для риск-команды, которую я проводил для 100+ специалистов одного международного банка за один день.

Почему шесть модулей, а не три и не двенадцать

Первый вопрос, который я всегда задаю банковскому заказчику: какой объём обучения вы можете реально выдержать? Потому что здесь главное — не «впихнуть побольше», а «не перегрузить». Три модуля — слишком мало, чтобы дать связное понимание; двенадцать — слишком много, чтобы банк успел это действительно переварить за разумный срок.

Шесть модулей — это золотая середина. Каждый модуль — это отдельная тема, которая может стоять самостоятельно, но при этом все шесть выстраиваются в последовательность: от базовых концепций через практические применения к агентам и автономии. Один модуль занимает 20–60 минут чистого обучения плюс практические задания между модулями.

Логика последовательности такая. Сначала вы должны понять, как LLM в принципе работает, — иначе все последующие темы вы будете применять вслепую. Потом вы учитесь работать с текстом — самая частотная задача, которую сразу можно перенести в ежедневную работу. Потом — работать с данными и числовыми выводами, потому что в банке половина решений опирается на цифры, и тут у LLM есть свои ловушки. Потом — документы и RAG, потому что без работы с корпоративной базой знаний LLM в банке бесполезна. И в конце — агенты и автоматизация процессов, как следующий уровень зрелости.

Теперь по порядку.

Модуль 1 — Как LLM читают запросы и формируют ответы

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

Ключевые темы модуля:

  • Токены. Модель работает не со «смыслом слов», а с последовательностью токенов. Один и тот же русский текст может быть разбит на разное число токенов в зависимости от токенизатора, и это влияет на точность. Особенно чувствительно к русскому — у английского моделей токенизация агрессивнее.
  • Контекстное окно. LLM видит только то, что помещается в текущее окно. При длинных диалогах окно сдвигается, и фрагменты вне него перестают влиять на ответ. Это важно, когда вы работаете с большими нормативными документами: если окно закрывается, модель может «забыть» важное условие из начала документа.
  • Галлюцинации и уверенность модели. Модель всегда отвечает уверенным тоном, даже когда не знает ответа. В банковской практике это особенно опасно на аббревиатурах — одна буква превращает ПДН (показатель долговой нагрузки) в ПДЛ, и модель уходит в совершенно другой контекст, выдавая связный, но неправильный текст. Я всегда показываю этот пример на первых минутах модуля: уверенный тон не означает знание.
  • Роли System, User, Assistant. Три роли определяют рамку поведения модели. System задаёт ограничения и профиль, User ставит задачу, Assistant отвечает. Системные инструкции имеют наивысший приоритет, и это нужно использовать для встраивания политики банка (например, «не отвечать на вопросы вне области финансов», «всегда добавлять дисклеймер при работе с персональными данными»).

Внутри этого же модуля идёт блок этики и ответственности. И тут появляется главный для банка документ — Кодекс этики Банка России в сфере ИИ, который задаёт пять принципов ответственного применения ИИ в финансовой организации.

Кодекс ЦБ РФ: пять принципов ответственного применения ИИ

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

  • Принцип первый — человекоцентричность. ИИ дополняет человека, а ответственность за итоговое решение сохраняется в человеческом контуре. Это ровно то, что на шкале автономности процессов я показываю как «человек в контуре» — в банке этот принцип не рекомендация, а базовое требование.
  • Принцип второй — управление рисками. Использование ИИ должно быть встроено в общую систему управления рисками банка. Нельзя пускать модель в регулируемый процесс без оценки модельного риска, без фиксации применимости, без согласования с риск-функцией.
  • Принцип третий — прозрачность и объяснимость. Каждое решение, принятое с помощью ИИ или с его участием, должно быть воспроизводимо и объяснимо — хотя бы на уровне «какие данные использовались» и «какая модель применялась». Это тот самый пункт, из-за которого классический MRM не работает для GenAI, и про который я пишу отдельно в заметке «MRM для GenAI».
  • Принцип четвёртый — защита данных. Персональные и чувствительные данные не должны передаваться внешним AI-сервисам без соответствующего правового основания. На практике это означает, что для работы с клиентскими данными нужен либо закрытый контур, либо заключённый договор обработки данных с провайдером.
  • Принцип пятый — постоянное совершенствование. ИИ-система не «запускается один раз и работает», она требует регулярного контроля, переобучения, мониторинга дрейфа. Это встраивается в операционный процесс банка, а не в одноразовый проект.

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

Модуль 2 — Работа с текстом

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

Базовые операции, которые осваиваются в этом модуле:

  • Суммаризация. Сделать короткую выжимку из длинного документа. Сложность — в длинных нормативных документах, где важно не потерять критические условия и исключения.
  • Выделение требований, рисков и ключевых выводов из документа. Я на практике показываю, как запрашивать у модели три отдельных слоя: требования (что нужно сделать), риски (что может пойти не так), выводы (что из этого следует). Это стандартный приём, который избавляет от «пересказывающих» ответов.
  • Сопоставление требований разных редакций документа. Когда банк работает с регуляторной базой, которая обновляется несколько раз в год, критически важно уметь быстро находить разницу между старой и новой редакцией. Здесь LLM даёт трассируемое сопоставление: источник, версия, формулировка, тип изменения.
  • Выявление логических противоречий и неявных допущений. Один из самых недооценённых режимов работы LLM: не «сделай вывод», а «покажи, какие фразы конфликтуют между собой и на каком скрытом допущении держится каждый спорный вывод».
  • Контроль интерпретации. Даже корректный summary может незаметно усиливать формулировки. Я учу команду просить у LLM отдельный отчёт по интерпретациям — какие места текста были пересказаны с усилением, какие — без изменений.

В конце модуля идёт важная мета-тема: управление структурой вывода через Markdown. Современные LLM «думают» на Markdown, и если вы просите структурированный ответ, используйте язык разметки напрямую. Это экономит время на постобработке и делает ответы модели пригодными для копирования в документы.

Модуль 3 — Работа с данными и числовыми выводами

Один из самых важных модулей — и самый коварный. Банковские аналитики работают с цифрами ежедневно, и первое желание — отдать эту работу LLM: «проанализируй динамику просрочки и сделай вывод». Проблема в том, что LLM не понимает бизнес-контекст за цифрами и легко делает опасные обобщения. В этом модуле я показываю пять типовых ошибок и способы их избежать.

Ошибка первая — корреляция вместо причинности. Аналитик пишет в записке для Комитета по рискам: «Рост дефолтов в сегменте МСБ вызван повышением ключевой ставки с 16% до 19%». Вывод выглядит логично, но ошибочен: между двумя наблюдениями нет доказанной причинной связи, это только временное совпадение. LLM охотно достраивает такую связку, потому что «звучит складно», — и аналитик, не проверивший вывод, попадает в ловушку.

Ошибка вторая — абсолютные и относительные показатели. Аналитик пишет: «Доля NPL выросла на 2%». Что это значит — что доля увеличилась в 2 раза или что она выросла на два процентных пункта? Если исходное значение было 3,2% и стало 5,2%, это рост на два пункта, то есть на 62,5% от исходного. Путаница между процентами и процентными пунктами — классическая ошибка LLM в черновиках отчётов. Модель не чувствует разницы, а человек, не проверивший вывод, передаёт её в Комитет.

Ошибка третья — арифметические промахи. «Банк формирует квартальный отчёт. Портфель 420 млрд, доля просрочки 3,8%. Модель выдаёт: объём просрочки 16,8 млрд руб.». Проверяем: 420 × 0,038 = 15,96 млрд. LLM ошиблась в базовых вычислениях почти на миллиард рублей. Это не уникальный случай — это известное свойство LLM: они плохо считают без явного запроса «покажи формулу расчёта шаг за шагом».

Ошибка четвёртая — неверная агрегация. Риск-аналитик просит LLM суммировать просроченную задолженность по трём сегментам: корпоративные клиенты в рублях, МСБ в рублях, розница с валютными кредитами. Модель суммирует рубли и валюту, не пересчитав по курсу, и получает бессмысленную цифру. Это тоже типовая ситуация: LLM не знает про курсы валют по состоянию на отчётную дату, если вы сами не даёте ей эту информацию в промпте.

Ошибка пятая — игнорирование базы сравнения и сезонности. «Резкий рост к прошлому месяцу» может оказаться нормальным сезонным паттерном год к году. Если LLM не знает про сезонность (а она обычно не знает), она сделает вывод про «тревожный тренд» там, где его нет.

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

💡 Нужна программа обучения для вашей риск-команды? Я провожу 90-минутную Диагностику автономности за 150 000 ₽. Разбираем ключевые процессы вашей риск-функции и определяем следующий шаг. Записаться на диагностику →

Модуль 4 — Информационная безопасность и закрытый контур

Этот модуль я часто делаю опциональным и адаптирую под конкретный банк. В одних банках он занимает 10 минут (потому что команда уже работает в закрытом контуре и знает правила), в других — полчаса (потому что нужно разбирать обезличивание данных в PCI DSS-контуре, правила работы с карточными данными, интеграцию с банковской ABS).

Главная мысль модуля: GenAI в банке живёт либо в контуре, либо нигде. Облачный API к внешним сервисам (ChatGPT, Claude, Gemini) в регулируемых банковских процессах не применим. Остаются три варианта: российские LLM-сервисы по договору (GigaChat, YandexGPT с заключённым договором обработки), on-premise развёртывание open-source моделей (Llama, Qwen в контуре организации через платформу типа panteo.ai, о которой я пишу в отдельной заметке), или гибридная архитектура, где чувствительные данные обрабатываются в контуре, а несенсивные — через внешние сервисы.

Отдельный блок модуля — теневой GenAI: ситуация, когда сотрудники уже используют ChatGPT с личных смартфонов для рабочих задач без ведома ИБ-службы. Запретить это невозможно, игнорировать опасно. Правильная стратегия — управляемое присутствие через политику разрешений и обучение. Подробнее я разбираю это в отдельной заметке про теневой GenAI.

Модуль 5 — RAG и документный интеллект

RAG (Retrieval Augmented Generation) — это когда модель сначала ищет релевантные фрагменты в корпоративной базе знаний, а потом формирует ответ с опорой на найденные источники. В банке RAG нужен везде, где работа идёт с внутренними документами: регламенты, инструкции, прошлые заключения, судебная практика, договорная библиотека.

В этом модуле команда узнаёт:

  • Векторный поиск как основа RAG — как строки превращаются в эмбеддинги и по какому принципу система находит похожие фрагменты.
  • Архитектура RAG-бота — хранилище документов, векторное хранилище, ретривер, LLM, формирование ответа. Без понимания архитектуры команда не сможет обсуждать с ИТ-интегратором, где именно в пайплайне нужны доработки.
  • Когда RAG даёт сбои — и как их предотвращать. Самая частая проблема: в хранилище лежат одновременно старая и новая редакции регламента, и поиск возвращает противоречивые фрагменты. Лечится дисциплиной ведения базы знаний, а не улучшением модели.
  • Обязательная практика запрашивать источники в ответе — каждый RAG-ответ должен сопровождаться ссылкой на документ, страницу и точную цитату. Без этого ответ нельзя валидировать, и комплаенс-аудитор не примет его.
  • Чек-лист проверки RAG-ответа: существует ли источник, совпадает ли цитата, взята ли из актуальной редакции, не вырвана ли из контекста оговорок и исключений.

В этом модуле я всегда подчёркиваю: RAG — это не одна большая модель, это пайплайн из нескольких компонентов. И качество результата определяется не силой LLM в конце пайплайна, а дисциплиной работы со всеми предыдущими этапами.

Модуль 6 — ИИ-агенты и автоматизация процессов

Последний модуль — самый продвинутый. Здесь речь о том, что отличает агента от ассистента.

Ассистент работает по запросу пользователя: один вопрос — один ответ. Агент получает цель, сам планирует последовательность шагов, вызывает инструменты и внешние системы, может перепланировать работу и возвращается с результатом через несколько минут (или часов). Это разные архитектурные режимы, и они требуют разных подходов к безопасности, мониторингу и интерпретации результатов.

В модуле разбираются три основных паттерна агентных систем:

  • ReAct — агент чередует рассуждение и действие. Каждый шаг: Reason (сформулировать следующее действие), Act (вызвать инструмент), Observe (получить результат), Think (решить, что делать дальше).
  • Plan-and-Execute — разделение планировщика и исполнителя. Отдельный планировщик раскладывает задачу на шаги, исполнитель проходит их по очереди, план может перестраиваться, если шаг не удался.
  • SGR (Schema-Guided Reasoning) — агент на каждом шаге формирует не только действие, но и структурированное состояние задачи: что уже сделано, что осталось, какие подцели закрыты. Это делает агентный процесс управляемым и воспроизводимым.

И отдельно — MCP (Model Context Protocol) как современный стандарт подключения корпоративных инструментов к агенту. Через MCP можно давать агенту доступ к банковской ABS, к кредитной истории, к реестру операций — всё в контуре безопасности, с логированием и правами.

Завершается модуль переходом к концепции Self-Driving Business — тому же понятию, которое стоит в основе моей шкалы автономности процессов. Банковская параллель — это то, что Bain называют Self-Driving Bank или Self-Driving Finance: банк, в котором частотные операционные процессы выполняются автономными агентами с контролем человека на критических точках. Это пока что цель, а не состояние, но движение в эту сторону уже идёт.

Как эта программа превращается в реальный результат

Программа на шесть модулей — это не цель сама по себе. Цель — чтобы через 6–12 месяцев после прохождения программы в риск-функции банка были:

  • Две-три реально работающих AI-инициативы в проде, с измеримой метрикой эффекта.
  • Внутренняя политика применения ИИ, написанная командой самого банка на основе Кодекса ЦБ РФ и специфики своих процессов.
  • Дорожная карта следующих инициатив на год вперёд — построенная через мою авторскую методику дорожной карты внедрения ИИ.
  • Общий язык команды — все участники говорят на языке шкалы автономности процессов и понимают, где ИИ применим, а где избыточен.

Самая короткая версия этой работы — однодневная фасилитация AI Café на 100+ участников, которую я проводил для крупного международного банка. За один день по формату шести столов-тем собиралась карта инициатив для всей риск-функции.

А первый шаг для большинства банков — 90-минутная Диагностика автономности за 150 000 ₽, в которой мы вместе с руководителем риск-функции определяем текущую зрелость трёх-пяти ключевых процессов и набрасываем первые приоритеты.

Что дальше

Если вы руководитель риск-функции в крупном банке и эта статья дала вам структуру для следующего шага — начинайте с диагностики (быстро, один разговор) или с фасилитации (интенсивно, много людей сразу, один день).

Обсудить вашу ситуацию →