Петр РЫЛЯКОВ, руководитель отдела прототипов и исследований компании «Онланта», на основе опыта проектов в банковском секторе рассказывает, почему локальные ИИ-эксперименты не всегда доходят до промышленного внедрения и как банкам перейти к управляемому использованию генеративного ИИ без потери контроля над данными, рисками и бюджетом.

Застрявшие на пилотах

Исследование «Яков и Партнеры» в 2025 году показало, что ИИ становится значимым трендом в банковской сфере и обещает значительный экономический эффект — 0,6–1 трлн руб. к 2030 году.

Крупнейшие игроки — Сбер, ВТБ, Т-Банк, Альфа-Банк — развивают ИИ уже несколько лет: имеют свои модели, центры компетенций и сквозные стратегии. Компании делятся результатами в публичных отчетах: в Сбере к 2026 годe реализовали около 900 проектов с ИИ, а в ВТБ эти технологии внедрены более чем в 300 процессов.

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

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

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

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

ИИ в структуре бюджетов: между стратегией и операционкой

В 8 из 10 крупнейших банков ИИ становится самостоятельным стратегическим направлением: так, Сбер, ВТБ и Т-Банк отразили его в стратегиях до 2027–2028 годов. У банков второго-третьего эшелона и региональных игроков ИИ-проекты часто финансируются из общего ИТ-бюджета — наряду с поддержкой существующих систем, развитием core-банкинга, ИБ и импортозамещением.

«Теневой ИИ»: невидимая угроза банковской безопасности

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

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

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

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

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

Финансовая ловушка разрозненных пилотов

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

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

Почему установки LLM недостаточно

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

·      интеграция с корпоративной системой аутентификации и единым входом;

·      ролевая модель доступа;

·      контроль подключения к внутренним базам знаний и корпоративным системам;

·      журналирование действий;

·      мониторинг нагрузки, производительности и доступности;

·      управление моделями, версиями, лимитами и правилами использования;

·      возможность масштабировать вычислительные ресурсы;

·      контроль качества ответов и правила обработки потенциально чувствительной информации.

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

Платформа против самостоятельной сборки

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

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

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

Как работает единая платформа

Платформенный подход объединяет четыре контура:
1) доступы (аутентификация, роли);
2) модели и инструменты (управление версиями);
3) данные и интеграции (API, внутренние источники знаний);
4) контроль (мониторинг, инциденты).

На примере платформы ОНЛАНТА ИИ ХАБ можно увидеть, как эти задачи сводятся в единый процесс. Это снижает зависимость от конкретной LLM. Если появляется модель, более подходящая под задачи бизнеса, ее можно подключить или заменить без перестройки пользовательских сценариев и интеграционного контура.

Банк получает возможность развивать ИИ постепенно: начинать с ограниченного пилота, проверять эффект, а затем переносить успешные практики на другие подразделения без потери контроля над безопасностью и бюджетом.

От пилота к промышленной эксплуатации

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

Для пробного сценария процесс должен быть повторяемым, иметь понятный объем ручного труда и позволять сравнить «до» и «после». Пилот в среднем занимает две недели.

Успех измеряется тремя группами показателей.

1.     Операционная эффективность: насколько сократилось время выполнения задачи (например, обработка договора — с часа до 10 минут) или сколько типовых запросов перешло на автоматическую обработку.

2.     Соблюдение политик безопасности: факт прохождения пилота без инцидентов и с полной трассировкой всех действий.

3.     Лояльность пользователей: сотрудники перестали использовать внешние модели и перешли на защищенный инструмент внутри контура.

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

Будущее рынка: от ассистентов к экосистемам

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

Регуляторная повестка становится более предметной. В июне 2026 года Банк России выпустил методические рекомендации № 3-МР по обеспечению информационной безопасности при разработке и применении ИИ на финансовом рынке. В документе детально рассмотрены риски, связанные с данными, моделями, запросами пользователей, внешними сервисами и компонентами с открытым исходным кодом.

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

В этих условиях ключевым фактором конкурентоспособности станет способность банка безопасно и экономически предсказуемо масштабировать ИИ-решения на всю организацию.