ИИ в банковской аналитике: что он реально делает и где его нужно остановить

Где ИИ даёт пользу аналитику в банке

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

• Разбор обращений и жалоб: классификация по темам, выделение продукта, причины и тональности, поиск повторяющихся проблем в потоке, который никто не успевает прочитать целиком.
• Отчётность: черновик текстового комментария к цифрам, которые уже посчитаны в хранилище данных, сверка формулировок между версиями отчёта.
• Работа с документами: извлечение реквизитов и условий из договоров и заявлений в структурированную таблицу с обязательной выборочной проверкой.
• Поиск по внутренним регламентам и инструкциям: ответ сотруднику со ссылкой на конкретный пункт документа.
• Помощь в коде: черновики SQL-запросов и скриптов, объяснение чужого запроса, генерация тестов к расчётам.

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

Пример: комментарий к ежемесячному отчёту

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

Защита здесь простая и автоматизируемая: каждое число в тексте комментария программно сверяется с таблицей, а любое расхождение возвращает черновик на исправление. Отдельно человек проверяет смысловые выводы — например, что рост показателя объяснён правильно и не приписан причине, которой в данных нет. Модель экономит время на написании, но ответственность за текст остаётся у аналитика.

Скоринг — классическая задача, а не задача для чат-бота

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

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

Как выбрать подход: правило, классическая модель или языковая модель

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

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

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

Ограничения, о которых нужно знать заранее

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

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

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

Объяснимость и след решений

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

Банковская тайна и персональные данные

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

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

• Запрет на загрузку клиентских данных в личные аккаунты ИИ-сервисов, зафиксированный в регламенте.
• Обезличивание перед обработкой и обратная подстановка только внутри защищённого контура.
• Разграничение доступа: модель и её пользователи видят только то, что положено их роли.
• Журнал запросов и ответов для аудита.
• Согласование с комплаенсом и информационной безопасностью до пилота, а не после.

Пример: как обезличить обращение

Возьмём условное обращение: клиент пишет, что с его карты списали деньги за покупку, которую он не совершал, указывает имя, номер телефона и последние цифры карты. Для классификации модели не нужно ничего из этого. До обработки имя заменяется меткой «КЛИЕНТ», телефон — меткой «ТЕЛЕФОН», номер карты — меткой «КАРТА», суммы и даты при необходимости обобщаются. Модель получает текст «КЛИЕНТ сообщает о списании с КАРТА за операцию, которую не совершал» и уверенно относит его к спорным операциям. Связь метки с реальным клиентом хранится только во внутренней системе.

Вопросы к поставщику ИИ-сервиса

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

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

Пошаговый пилот: разбор обращений клиентов

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

1. 01Вместе с владельцем процесса утвердите список категорий обращений с понятными определениями и примерами для каждой. Если люди сами путают категории, модель будет путать их тоже.
2. 02Соберите выборку реальных обращений за период, в котором представлены все категории, и обезличьте её до передачи кому-либо.
3. 03Попросите двух сотрудников независимо разметить выборку и разберите расхождения: так вы получите эталон и уточнённые правила.
4. 04Опишите задачу для модели: категории, определения, формат ответа, право ответить «не могу определить».
5. 05Прогоните эталонную выборку, посчитайте качество по каждой категории отдельно, а не только в среднем.
6. 06Настройте маршрутизацию: уверенно классифицированные обращения идут в очередь нужного отдела, сомнительные и чувствительные — на ручной разбор.
7. 07Запустите пилот параллельно с текущим процессом и сравнивайте результаты, прежде чем отключать ручную разметку.
8. 08После запуска регулярно берите случайную выборку и проверяйте её вручную, чтобы заметить дрейф.

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

Как проверять результаты модели

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

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

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

Какие показатели качества отслеживать

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

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

Типичные ошибки внедрения и как их поймать

• Модель тестировали на нескольких удачных примерах — нет эталонной выборки. Признак: качество «на глаз» отличное, а пользователи жалуются. Лечение: размеченный набор и замер по категориям.
• Клиентские данные попали в публичный сервис через личный аккаунт сотрудника. Признак: в регламенте нет перечня разрешённых инструментов. Лечение: корпоративный контур, запрет и обучение.
• Модель «посчитала» итоговую сумму в тексте отчёта. Признак: числа в комментарии не совпадают с таблицей. Лечение: модель не порождает числа, автоматическая сверка.
• Сменили версию модели или промпт и не перепроверили качество. Признак: изменились распределения категорий без изменений в потоке обращений. Лечение: повторный прогон эталона после любого изменения.
• Текст клиента изменил поведение модели. Признак: необычные ответы на обращения с инструкциями внутри. Лечение: обработка текста как данных, ограничение действий модели, тестовые примеры с такими вставками.
• Обрезанный ответ сохранён как полный. Признак: пустые поля или оборванные записи в результатах. Лечение: проверка признака завершения и схемы ответа.

Чек-лист перед пилотом ИИ в аналитике

1. 01Задача сформулирована так, что модель готовит материал, а не принимает финансовое решение.
2. 02Комплаенс и информационная безопасность согласовали состав данных и контур обработки.
3. 03Персональные данные и реквизиты обезличены до попадания в модель.
4. 04Все числа берутся из учётной системы, модель их не порождает.
5. 05Собран эталонный набор примеров, качество измерено до запуска.
6. 06Определена цена каждой ошибки и настроены пороги.
7. 07Есть журнал запросов, ответов и решений человека.
8. 08Назначен владелец, который отслеживает качество после запуска и решает, когда модель пересматривать.
9. 09Чувствительные категории всегда уходят на ручной разбор.
10. 10Пилот идёт параллельно с текущим процессом, пока качество не подтверждено.
11. 11Любая смена модели, промпта или источника данных сопровождается повторным прогоном эталона.

Короткий словарь терминов

• Скоринг — оценка заявки или клиента числом, отражающим вероятность события, например невозврата кредита.
• Антифрод — системы и процессы выявления мошеннических операций.
• Обезличивание — замена или удаление сведений, по которым можно установить человека, до обработки данных.
• Эталонная выборка — набор реальных примеров с проверенными людьми правильными ответами, на котором измеряют качество модели.
• Валидация модели — независимая проверка качества, устойчивости и применимости модели до и после внедрения.
• Дрейф данных — изменение входных данных со временем, из-за которого модель начинает ошибаться чаще.
• Промпт-инъекция — попытка изменить поведение модели инструкцией, спрятанной во входном тексте.
• Поиск с генерацией ответа — схема, в которой модель сначала находит фрагменты документов, а затем отвечает с опорой на них.

Итог

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