ИИ в финансах и банкахТам, где ошибка стоит дорого
Модели, решения которых можно объяснить регулятору, и работа в закрытом контуре по умолчанию: клиентские данные не покидают ваш периметр.
Частые проблемы
Не «недостаточная цифровизация», а процессы, которые называют на первой же встрече.
- Скоринг устарел, но его боятся трогать
- Модель работает годами, качество медленно падает, а переобучение откладывается: непонятно, как объяснить новую логику проверяющим и как не сломать одобрения.
- Аномалии ищут правилами
- Набор пороговых условий писался годами, разрастался и теперь даёт поток ложных срабатываний. Аналитики разбирают шум, а новые схемы проходят мимо правил.
- Регламенты никто не дочитывает
- Внутренние документы, письма регулятора и методики лежат в разных местах и обновляются независимо. Сотрудник находит не то, что действует сейчас, а то, что нашлось первым.
- Клиентские документы вводят вручную
- Справки, выписки, финансовая отчётность — всё это перепечатывается людьми. Долго, дорого, и на объёме неизбежны ошибки, которые всплывают при проверке.
- На вопрос «почему отказ» нет ответа
- Если решение принимает модель, а объяснить его нечем, это проблема и для клиента, и для комплаенса. Непрозрачная модель не проходит внутреннюю приёмку, какой бы точной она ни была.
Где ИИ окупается
Сценарии, которые в этой отрасли дают измеримый эффект. Каждый ведёт на страницу направления с деталями.
Скоринг с объяснимыми решениями
Модель на градиентном бустинге с разбором вклада каждого фактора в решение. По любой заявке видно, что именно повлияло на результат, — это требование не наше, а комплаенса и регулятора.
ML-модели и аналитикаВыявление аномалий и подозрительных операций
Модель учится на истории и находит отклонения, которых нет в правилах, снижая поток ложных срабатываний. Правила при этом не выбрасываются — они остаются как жёсткий контур, модель работает поверх.
ML-модели и аналитикаПоиск по регламентам и требованиям регулятора
Ассистент отвечает по действующей редакции внутренних документов и писем регулятора со ссылкой на пункт. Мы делали такой поиск по корпоративной базе: ответ за 5–10 секунд вместо часов, точность до 90%.
RAG-системыОбработка клиентских документов
Справки, выписки и отчётность распознаются и раскладываются по полям с проверкой на непротиворечивость. Сотрудник проверяет расхождения, а не вводит цифры.
OCR и обработка документовАссистент сотрудника фронт-офиса
Подсказывает по продукту, условиям и процедуре прямо в момент разговора с клиентом, опираясь на действующие документы. Сокращает срок ввода новых сотрудников в работу.
ИИ чат-ботыПрогноз оттока и склонности к продукту
Модель на поведенческих данных выделяет клиентов с высоким риском ухода и тех, кому продукт действительно уместен. Эффект проверяется контрольной группой, а не отчётом о рассылке.
ML-модели и аналитикаРазбор обращений и жалоб
Классификация по теме и срочности, выделение повторяющихся причин, автоматическая маршрутизация. Позволяет увидеть системную проблему раньше, чем она станет предметом претензии.
Внедрение LLMЛокальная модель в закрытом контуре
Языковая модель разворачивается на вашем железе — данные не уходят наружу физически. Мы делали это в проекте с генерацией кода: своя модель в контуре вместо облачного сервиса.
Внедрение LLMОтчётность вопросом на естественном языке
Запрос на русском превращается в SQL к вашему хранилищу с ограничением прав доступа. Аналитик перестаёт быть узким местом для типовых выгрузок.
Внедрение LLMЕсть ли у нас проектв этой отрасли
Публичного кейса в банке у нас нет — в этой отрасли проекты почти всегда под NDA, и мы не будем намекать на то, чего не можем показать. Технологически ключевые задачи закрыты в других проектах: поиск по большой базе документов с цитатой источника, развёртывание собственной языковой модели в закрытом контуре без выхода наружу, прогноз на исторических рядах и потоковое распознавание документов. На диагностике покажем эти разборы целиком и обсудим, что из них применимо к вашему процессу.
Чем эта отрасль отличается
То, что меняет архитектуру решения и смету, — а не только формулировки в презентации.
Объяснимость важнее последних долей точности
Модель, которая точнее на процент, но не объясняет решений, не пройдёт приёмку. Мы сознательно выбираем архитектуры с разбором вклада факторов, даже когда есть более точные, но непрозрачные.
Данные не покидают контур
В большинстве проектов облачные модели отпадают на первом же согласовании. Планируем закрытый контур с самого начала: переезд туда на позднем этапе означает смену модели и повторные замеры.
Классы крайне несбалансированы
Мошеннических операций доли процента, дефолтов немного. Обычная точность на таких данных бесполезна: модель, всегда говорящая «нормально», будет права в 99% случаев и бессмысленна. Меряем полноту и цену ошибки каждого типа.
Поведение меняется быстро
Схемы мошенничества адаптируются, экономические условия сдвигаются. Модель, обученная год назад, тихо деградирует — мониторинг дрейфа здесь не приятное дополнение, а обязательная часть.
Модель нельзя выпускать сразу на всех
Правильный путь — теневой режим: модель считает параллельно действующему процессу, решения сравниваются, но в бой не идут. Только после этого — ограниченный контур.
Ошибка стоит по-разному в две стороны
Пропущенное мошенничество и заблокированная нормальная операция — принципиально разные потери, и вторая ещё бьёт по отношениям с клиентом. Порог настраивается по деньгам, а не по симметричной метрике.
С чего начинаем
Начинаем с задачи, где есть исторические данные и понятная цена ошибки, — обычно это скоринг или поиск по регламентам. Работаем на обезличенной выборке, за две недели показываем качество на отложенном периоде и сразу разбор факторов, влияющих на решение. Если объяснимость не устраивает комплаенс, это выяснится на прототипе, а не после внедрения.
Частые вопросы.Короткие ответы.
Да, и в финансовых проектах мы исходим из этого по умолчанию. Модель работает на вашем железе, данные наружу не уходят физически. У нас есть проект, где собственная языковая модель развёрнута в контуре заказчика именно из-за запрета на выгрузку кода и данных.
По каждому решению формируется разбор вклада факторов: что повлияло и в какую сторону. Мы сознательно выбираем архитектуры, допускающие такой разбор, и закладываем в проект выгрузку объяснений вместе с решением — она нужна и комплаенсу, и при разборе жалобы клиента.
Сначала надо измерить. Мы берём вашу текущую модель и обучаем новую на тех же данных, сравнивая обе на периоде, которого ни одна не видела. Если прирост не окупает внедрение и переприёмку, честно скажем — это нормальный исход диагностики.
Именно поэтому мы запускаем её в теневом режиме: она считает параллельно действующим правилам, решения сравниваются, но никого не блокируют. По результатам настраивается порог, где цена пропуска и цена ложной блокировки уравновешены по деньгам, а не по абстрактной метрике.
Обычно да, но подход другой. Мы не гонимся за общей точностью — она на таких данных бессмысленна, — а работаем с полнотой и приёмами для несбалансированных классов. На диагностике оценим, достаточно ли размеченных случаев для нужного уровня полноты.
Вам: и веса модели, и код, и документация по обучению. Это принципиальный момент — решение, от которого зависит кредитный процесс, не должно зависеть от того, продолжаете ли вы работать с подрядчиком.
Другие отрасли
Начнём с одного участка
Расскажите, какой процесс болит сильнее всего в финансах. Вернёмся с планом прототипа на ваших данных, сроком и вилкой — и скажем, если задача решается без ИИ.