— Алексей, как вы оцениваете готовность банковского сектора к внедрению ИИ?

— У нас в стране банковский сектор демонстрирует высокую готовность к внедрению ИИ и активно инвестирует в эту сферу: по данным «Форбс», в 2024 году финансовый сектор вложил в ИИ 56,8 млрд рублей (для сравнения: нефтегазовая отрасль — менее 3 млрд). По данным Банка России, уже две трети банков используют ИИ или планируют его внедрение, видя в этом источник конкурентоспособности.

Однако отрасль сталкивается с «усталостью от “пилотов”»: множество проектов с «вау-эффектом» не масштабируются и не приносят измеримых результатов. Основная причина — сложность IT-ландшафта банков, состоящего из множества legacy-систем, что не позволяет бесшовно внедрять решения на базе ИИ в сквозные производственные процессы. Возникает парадокс: высокая активность при отсутствии реального эффекта. По данным MIT и IDC, до 95% пилотных проектов не доходят до промышленной эксплуатации.

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

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

— Какова ситуация с ИИ в малых и средних банках?

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

Полноценное развертывание системы полного цикла (модели, управление RAG/MCP, среда исполнения агентов) и интеграция в IT-ландшафт для таких банков пока недоступны технически в силу отсутствия как вычислительных ресурсов, так и специалистов.

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

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

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

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

«Камунда.РФ» — это продолжение развития Camunda Platform (на банковоском рынке РФ более 70% внедрений в BPMS-сегменте приходится на Camunda Platform) консорциумом разработчиков.

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

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

Алексей Шершнев (Farzoom). Фото: Ирина Анисина / «Б.О»

— Но если ИИ встраивается в сквозные процессы, как банк сохраняет контроль и уверенность, что это все соответствует нормативным требованиям?

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

Что же касается соответствия нормативной документации, здесь, пожалуй, и находится ключевая особенность «Камунда.РФ». В банковской практике нормативная база почти никогда не совпадает на 100% с реальным процессом, по которому выдаются продукты. Различия могут быть в деталях, но они есть всегда. BPM-система должна помогать контролировать отклонения между формальными правилами и фактическую логику работы.

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

Наш подход — непрерывное улучшение процессов. В основе — быстрое внедрение автоматизации процесса без длительных техзаданий: вместо этого мы используем регуляторную базу самого клиента. В платформу «Камунда.РФ» встроена RAG-система (Retrieval Augmented Generation), которая позволяет ИИ строить детерминированные процессы непосредственно из внутренних банковских документов.

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

Таким образом, BPM-система перестает быть статичной картинкой. Она становится инструментом постоянного мониторинга и улучшения, обеспечивая актуальность и соответствие одновременно регуляторным требованиям и реальным бизнес-задачам.

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

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

Решить это могут только те, кто накопил реальный закрытый опыт: либо компании-интеграторы, которые внедряли подобные процессы в десятках банков (такие как Farzoom с десятилетним опытом автоматизации банковских процессов), либо крупные консалтинговые компании, которые провели сотни аудитов и знают, где у рынка разрывы и какие подходы работают. Именно такие игроки могут создать машиночитаемую отраслевую базу знаний и доработать на ее основе доменную LLM, которая реально понимает, как устроены банковские процессы.

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

— Что происходило далее?

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

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

В нашем кейсе внедрения кредитного конвейера МСБ было получено около 80 рекомендаций по оптимизации; примерно половина была принята банком. Это и есть первый цикл непрерывного улучшения — еще до написания единой строки кода.

После согласования рекомендаций запускается автоматическое моделирование: дообученная модель генерирует DSL-описание процесса для платформы — это промежуточное представление, из которого разворачиваются BPMN-схема, конфигурация микросервисов и пользовательские задачи. Система определяет, какие компоненты уже есть в базе знаний (и встраивает их автоматически), а где нужен новый сервис (и формирует задачу на разработку).

Итог: полный цикл — от актуализации базы знаний до перегенерации процесса и прогона автотестов — занимает около восьми часов, включая автотестирование на реальных тестовых данных банка. Вследствие этого кредитный конвейер был запущен в эксплуатацию за 30 дней. А ключевой артефакт всего процесса — база знаний с кросс-ссылками между элементами BPMN и нормативной документацией: можно проследить соответствие в обе стороны, что обеспечивает полную прозрачность и аудитопригодность.

Алексей Шершнев (Farzoom). Фото: Ирина Анисина / «Б.О»

— Хорошо, автоматизацию запустили. Но процессы меняются — появляются новые данные, новые требования, новые продукты. Как платформа поддерживает это непрерывное изменение, особенно если процесс уже работает в проде?

— Вот здесь и начинается то, что я называю концептуальным изменением в управлении и оптимизации процессами. «Камунда.РФ» реализует MCP-сервер (Model Context Protocol), который предоставляет LLM постоянный доступ к данным о прохождении живых процессов — таймингам, ветвлениям, узким местам, аномалиям.

Представьте: приходит владелец продукта и ставит задачу — сократить time to market по заявкам МСБ. Раньше это был бы проект на месяцы: аналитика, техзадание, согласования, разработка.

Теперь ИИ-агент сам анализирует фактические данные прохождения процесса, выявляет, почему, какие заявки и где «зависают», и предлагает конкретное решение — к примеру, сделать новую ветку или назначать задачи на других специалистов.

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

При этом процесс остается детерминированным: BPMN-нотация, прозрачное логирование, полный аудит. Гибкость не означает потерю управляемости — это принципиальное требование для банковской среды.

Именно это лежит в основе тренда, который мы видим на 2026–2027 годы: консолидация стека BPM/AI/RPA в единую платформу и переход от цикла «внедрение — поддержка — редкий реинжиниринг» к режиму непрерывного улучшения. «Камунда.РФ» уже объединила BPM и AI, сейчас ведется интеграция RPA.

— Получается, что переход к непрерывному улучшению процессов зависит не только от платформы «Камунда.РФ», но в первую очередь от наличия отраслевой LLM — именно она позволяет понять, как корпоративные процессы можно сделать лучше, а не просто автоматизировать то, что есть?

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

— Эта тема, судя по всему, уже звучит на уровне регулятора и отраслевых объединений?

— Да. Недавно состоялась встреча с представителями Ассоциации ФинТех и «Ростелекома», где обсуждалась инициатива по созданию отраслевой LLM для финансового сектора. Значительная часть поднятых вопросов совпала с нашей позицией: без доменной модели промышленное внедрение ИИ в банках останется историей про «пилоты». Регулятор выразил поддержку инициативы — это важный сигнал для всей отрасли.

— Что дальше, как вы видите развитие этого направления?

— Мы сейчас ведем переговоры с ведущими консалтинговыми компаниями и коллегами по рынку — теми, кто накопил реальный опыт внедрения отраслевых процессов. Цель — объединить экспертизу и совместно создать полноценную доменную LLM для финансового сектора. Первый шаг — RAG-система на базе накопленных машиночитаемых баз знаний, затем — полноценное дистилляция и дообучение модели.

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