Тендеры и лиды
Информация
Разбираем, как выбрать задачу для ИИ в финтехе, запустить пилот, проверить пользу и снизить риски
Автор: Иван Манжетов, менеджер портфеля проектов в KODE
Внедрение ИИ в финтехе логичнее начинать не с вопроса «какую модель выбрать», а с проблемы, которую бизнес хочет решить. Нужно заранее понять, что будет считаться успехом, какие решения останутся за человеком, как фиксировать действия системы и на каком процессе сначала проверить гипотезу.
Иначе легко потратить деньги на пилот, который красиво работает на демо, но оказывается бесполезным или слишком рискованным в реальной работе.
Искусственный интеллект уже используют в финансовых компаниях: он помогает отвечать клиентам, искать подозрительные операции, оценивать заявки, разбирать большие объёмы данных. Банк России относит к основным целям применения ИИ снижение затрат, улучшение клиентского опыта, автоматизацию процессов и управление рисками. Но наличие ИИ само по себе ничего из этого не гарантирует.
Для бизнеса вопрос звучит проще: какую проблему мы хотим решить и по какой цифре поймём, что стало лучше? Если ответа нет, пилот рискует остаться просто дорогой демонстрацией технологии.
ИИ в финтехе — это программы, которые анализируют данные, ищут закономерности, готовят рекомендации или берут на себя часть действий внутри финансового продукта.
Например, система может распределять обращения в поддержку, замечать признаки мошенничества или показывать, на каком этапе клиенты чаще всего бросают заявку. Для этого не всегда нужна сложная кастомная разработка. В одном случае компании хватит помощника, подключённого к базе знаний. В другом придётся обучать отдельную модель, интегрировать её с внутренними системами и долго проверять качество работы. Поэтому сначала стоит понять, насколько сложную задачу вы вообще хотите решить. Попытка сразу автоматизировать всё обычно делает проект дороже и добавляет рисков.
На тестовых данных всё может работать отлично. Потом решение попадает в реальный процесс, где могут начаться проблемы. Причина не обязательно в модели. Часто проект ломается вокруг неё.
Например, у него нет одного владельца. Бизнес ждёт результата от IT-команды, разработчики ждут правила от юристов, сотрудники не понимают, кто должен проверять ответы системы. Формально решение готово, а взять его в работу никто не может.
Другая частая проблема: до пилота не зафиксировали исходные показатели. Команда не знает, сколько раньше занимала обработка заявки, сколько было ошибок и во сколько обходилась одна операция. После запуска сравнивать просто не с чем. Фраза «теперь вроде быстрее» для решения об инвестициях мало что даёт.
Мешают и данные. Они могут лежать в разных системах, дублироваться, конфликтовать между собой или содержать ошибки. Модель получает неполную картину, сотрудники начинают вручную исправлять её ответы, и обещанная экономия быстро исчезает.
Ещё один сценарий: компания сразу берётся за слишком большую задачу. Пилот растягивается на месяцы. За это время успевают поменяться требования, команда или сам продукт. Решение приходится переделывать ещё до первого полноценного запуска.
Для первого внедрения лучше брать процесс, в котором много повторяющихся действий, уже накоплены данные и есть понятный показатель качества.
Система может искать информацию в базе знаний, определять тему обращения, готовить черновик ответа и передавать сложные случаи специалисту. Результат здесь легко измерить: посмотреть на время ответа, долю решённых вопросов и количество повторных обращений.
Полностью отдавать диалог с клиентом модели рискованно. Человек может обратиться с нестандартной ситуацией, связанной с деньгами, блокировкой счёта или подозрением на мошенничество. Такие разговоры требуют другого уровня ответственности.
Поэтому ещё до запуска нужно решить, на какие вопросы система отвечает сама, а в какой момент подключается сотрудник.
ИИ может искать связи в данных и предлагать оценку риска. Но если от рекомендации зависит важное решение, человек должен понимать, какие данные на него повлияли, и иметь возможность всё проверить.
В феврале 2025 года Суд ЕС по делу Dun & Bradstreet указал, что при автоматической оценке человеку нужно дать понятное объяснение того, как его данные привели к результату. Сложной формулы или общего описания программы для этого недостаточно.
В Кодексе этики Банка России для ИИ на финансовом рынке названы пять принципов: внимание к интересам человека, справедливость, прозрачность, безопасность и ответственное управление рисками. Кодекс рекомендательный, но хорошо показывает, чего регулятор ждёт от таких систем.
Российские банки уже широко используют ИИ в скоринге и антифроде. В Сбербанке решения принимаются с учётом большого количества факторов и сложных моделей. Сам банк отдельно фиксирует необходимость обеспечивать «прозрачность и объяснимость (Explainable AI)» и управляемость таких систем на уровне принципов применения AI.
Т-Банк построил антифрод-систему, которая, по открытым данным, выявляет мошеннические звонки с надёжностью более 99% и позволила предотвращать финансовые потери клиентов: от миллионов рублей в отдельных случаях до сотен миллионов в масштабе сервиса.
Здесь важно, что результат даёт не одна модель. Она работает внутри системы, где связаны данные, процессы и действия сотрудников.
Система анализирует операции и отмечает те, которые выглядят подозрительно. Сотруднику уже не нужно вручную просматривать весь поток, он получает более короткий список для проверки. Здесь эффект можно считать через долю найденных случаев, число ложных тревог, предотвращённые потери и время проверки. Но количество обнаружений не единственный показатель. Если система слишком часто ошибается, сотрудники перестают доверять её сигналам. А обычные клиенты получают лишние блокировки и проверки.
То есть антифрод, который видит мошенников везде, тоже нельзя назвать хорошим.
Модель может анализировать путь клиента и находить места, где люди долго ждут, возвращаются назад или просто закрывают приложение. Это полезный сигнал, но не готовый ответ.
Если пользователи массово уходят с одного экрана, модель увидит связь. Почему они это делают, ещё предстоит выяснить. Здесь нужен человек, который знает продукт, ограничения бизнеса и требования законодательства.
Крупнейшие банки мира уже прошли стадию экспериментов и сейчас пытаются считать реальную отдачу.
JPMorgan за два месяца подключил к внутренним AI-инструментам 140 тысяч сотрудников, почти половину банка. При росте прибыли на 12% штат вырос только на 1%.
В Bank of America 90% сотрудников ежедневно работают с AI, а количество обращений в IT-поддержку сократилось вдвое.
Goldman Sachs развернул тысячи автономных AI-агентов и ожидает роста производительности в 3–4 раза.
Во всех этих случаях AI встроен в ежедневную работу, а эффект пытаются связывать с конкретными процессами и показателями. Это уже совсем другая история, чем отдельный пилот, которым несколько месяцев пользуется десять сотрудников.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Не начинайте с фразы «нам нужен ИИ». Лучше сформулировать проблему обычными словами: проверка заявки занимает 40 минут, сотрудники по сто раз отвечают на одинаковые вопросы, слишком много клиентов уходят на конкретном этапе оформления продукта.
После этого запишите текущую цифру. Если проверка действительно занимает 40 минут, после пилота появится с чем сравнивать результат. Без исходной точки любой эффект будет оцениваться на уровне ощущений.
Посмотрите, где лежат нужные данные, кто имеет к ним доступ и можно ли вообще использовать их для этой задачи. Проверьте пропуски, ошибки, дубли, разные варианты записи одного события. То, что человек легко понимает по контексту, модель может воспринять как разные сущности. Заодно уберите данные, которые для задачи не нужны. Если система может работать без части персональных сведений, лучше их ей не передавать.
Ещё до разработки ответьте на четыре вопроса:
кто отвечает за бизнес-показатель;
кто проверяет качество рекомендаций;
кто принимает окончательное решение;
кто разбирается с ошибками и жалобами клиентов.
У проекта должен быть "хозяин" внутри компании. Иначе пилот держится на личной инициативе пары сотрудников. Пока они им занимаются, всё работает. Как только меняются задачи или люди, проект останавливается.
Не нужно сразу подключать систему ко всем обращениям, заявкам или операциям. Дайте ей ограниченный объём и сравните результат с обычным процессом. Желательно в этот момент не менять всё остальное сразу: интерфейс, правила работы, команду и саму модель. Иначе потом будет сложно понять, что именно повлияло на результат. Условия остановки тоже лучше придумать заранее.
Например, если после подключения системы выросло число ошибочных блокировок или сотрудникам приходится делать больше ручной работы, эксперимент нужно остановить и разобраться, что пошло не так.
Точность модели важна, но одной её недостаточно. Посмотрите на весь процесс:
сколько времени удалось сэкономить;
как изменились расходы;
стало ли меньше ошибок;
сколько ручной работы осталось;
можно ли восстановить и объяснить отдельное решение;
сколько стоит поддержка системы;
не падает ли качество при росте нагрузки.
После пилота не обязательно должен последовать большой запуск. Вариантов три: масштабировать решение, доработать его или закрыть. Последний вариант тоже нормальный. Если компания за небольшой бюджет проверила гипотезу и поняла, что она не работает, это лучше, чем ещё год вкладываться в бесперспективное внедрение.
Часто экономику проекта пытаются свести к тому, сколько минут модель сэкономила одному сотруднику. Этого мало. Есть подготовка данных, интеграции, проверка качества, защита информации, инфраструктура, поддержка и доработки после запуска. Всё это тоже стоит денег. Упрощённо считать можно так:
Эффект = полученная экономия или дополнительный доход − все расходы на запуск и работу решения.
Представим, что AI-помощник сократил время ответа клиенту, но число сотрудников осталось прежним.
Это ещё не означает, что проект не принёс пользы. Возможно, команда стала быстрее разбирать сложные обращения или смогла обслуживать больше клиентов тем же составом. Просто такую пользу тоже нужно переводить в цифры.
PwC в 2025 году оценивала, что широкое применение ИИ в банке может улучшить показатель операционной эффективности до 15 процентных пунктов. Это оценка потенциального эффекта, а не обещание, что любой банк после внедрения автоматически получит плюс 15 пунктов. Результат зависит от процессов, данных и масштаба использования технологии.
Перед расширением пилота я бы прошёлся по короткому списку:
У проекта есть понятная задача и исходный показатель.
Команда знает, какие данные получает система.
Персональные данные защищены и не используются без необходимости.
Важное решение можно проверить и объяснить человеку.
Сотрудник может отклонить рекомендацию ИИ.
Действия системы и изменения фиксируются.
Есть правила работы с ошибками и жалобами.
Качество проверяется не только во время пилота, но и после запуска.
Посчитаны расходы на пилот и дальнейшую эксплуатацию.
Команда понимает, при каком результате эксперимент нужно остановить.
Если ответов нет сразу на несколько пунктов, с масштабированием лучше не торопиться.
Внешняя команда нужна не только для того, чтобы «прикрутить нейросеть». Она особенно полезна, когда ИИ нужно связать с действующим приложением, внутренними системами и реальным бизнес-процессом. Здесь уже мало просто показать, что модель умеет отвечать на вопросы. Подрядчик должен помочь выбрать метрику, проверить данные, разобраться с ролями и собрать систему, которую потом можно нормально поддерживать.
Перед стартом стоит попросить команду описать границы пилота, критерии успеха, основные риски и стоимость следующего этапа. Так заранее будет понятно, во что проект превратится после удачного эксперимента и сколько это будет стоить.
Хороший AI-проект начинается не с выбора модели. Сначала нужно найти один процесс, в котором есть понятная проблема, и измерить его текущее состояние. Потом решить, что можно доверить системе, где обязательно нужен человек и как команда будет разбирать ошибки. После этого можно запускать небольшой пилот и смотреть на цифры.
Если сотрудники стали обрабатывать больше задач, ошибок стало меньше, а работа системы остаётся понятной для команды, то решение можно расширять.
Если пользу нельзя доказать цифрами, а отдельное решение невозможно нормально объяснить клиенту или сотруднику, то спешить с масштабированием не стоит.
