Что произошло
7 октября 2026 года на форуме «ФинТех х10» старший вице-президент «Сбера» Кирилл Меньшов озвучил тезис о переходе финансового сектора от модели mobile-first к agentic-first. В новой парадигме ИИ-агенты становятся не просто консультантами, а активными исполнителями клиентских и операционных задач, самостоятельно формируя последовательность действий для достижения цели. Это заявление знаменует собой смену фокусировки с интерфейсных улучшений на перестройку внутренних операционных процессов под возможности автономных систем.
Этот тренд подкреплён масштабными инвестициями. По данным ComNews, только за 2025 год публично заявленные инвестиции российских корпораций в ИИ составили 220 млрд рублей, из которых 150 млрд пришлись на «Сбер» и 55 млрд на «Яндекс». Подобные вложения свидетельствуют о том, что агентные системы рассматриваются как стратегическое направление для повышения эффективности и создания новых продуктов. Однако реализация этой стратегии сталкивается с объективными ограничениями.
Представители «Сбера» и «Яндекса» накануне, 6 октября, признали технологическое отставание российской отрасли от зарубежных аналогов примерно в полгода. Главной причиной называется дефицит вычислительных мощностей, в частности современных GPU, что напрямую влияет на скорость и стоимость разработки и развёртывания мощных агентных платформ. Таким образом, стратегический импульс к внедрению agentic-first сталкивается с суровой реальностью инфраструктурных и санкционных ограничений.
Как это устроено
От автоматизации к автономии
Традиционная автоматизация, включая RPA, работает по жёстко заданному сценарию: если условие А, то выполнить действие Б. Генеративные чат-боты способны формировать текстовый ответ, но обычно не имеют прав изменять состояние систем. ИИ-агент принципиально отличается наличием цели, доступа к инструментам (API, БД, интерфейсам) и способности самостоятельно планировать шаги для её достижения. В типовом сценарии агент не просто отвечает на вопрос клиента, а инициирует проверку баланса, анализирует историю операций и готовит предложение по продуктам, используя несколько внутренних систем.
Архитектура контроля
По нашему опыту проектов, надёжная агентная система в финансах требует многоуровневой архитектуры безопасности. Российское «Банковское обозрение» описывает проверенный на практике подход, включающий три ключевых элемента. Первый — встроенные в агента ограничения (policy-as-code), которые не позволяют ему выйти за рамки предопределённых действий. Второй — внешний агент-аудитор, который в реальном времени проверяет соответствие действий агента внутренним политикам безопасности. Третий — централизованный оркестратор, который управляет полномочиями, распределяет задачи и ведёт единый журнал событий. Такая схема снижает риск единой точки отказа и каскадных сбоев.
Экономика и ограничения
Внедрение agentic-first — это не только стоимость языковой модели. Опрос банков, опубликованный «Российской газетой» в марте 2026 года, показывает основные барьеры. 82% респондентов указали на ограничивающие требования к использованию публичных облаков, что фактически заставляет строить инфраструктуру on-premise. 73% столкнулись с дефицитом или высокой стоимостью GPU, а 64% — с барьерами информационной безопасности. Кроме того, 55% банков отметили нехватку каталогизированных данных внутри организации, что является критическим фактором для обучения и функционирования агентов.
| Основной барьер | Доля банков, столкнувшихся с проблемой | Влияние на проект |
|---|---|---|
| Требования к публичным облакам | 82% | Вынужденное развёртывание on-premise, рост CAPEX |
| Дефицит или высокая стоимость GPU | 73% | Увеличение сроков разработки, рост OPEX |
| Барьеры информационной безопасности | 64% | Дополнительные затраты на аудит и контроль |
| Нехватка каталогизированных данных | 55% | Снижение качества агента, необходимость ETL-проектов |
Комплаенс и жизненный цикл
Регуляторные требования накладывают дополнительные ограничения на проектирование агентных систем. Банк России в методических рекомендациях № 3-МР от 16 июня 2026 года установил принцип управления рисками на всех этапах жизненного цикла ИИ-системы. Это означает, что контроль должен охватывать не только эксплуатацию, но и постановку задачи, подготовку данных, обучение, тестирование и вывод из эксплуатации. В доступных материалах не хватает данных, чтобы прямо связать конкретные нормы 243-ФЗ с ИИ-агентами, поэтому основной ориентир — рекомендации регулятора и стандартные требования к банковской тайне и персональным данным. Ключевым является требование полной воспроизводимости и аудируемости каждого решения агента.
Как это выглядит на практике
Контур управления рисками в Альфа-банке
Одним из немногих публичных примеров системного подхода к управлению агентными рисками в России является развитие в Альфа-банке отдельного контура Agent Risk Management (ARM). По данным «Коммерсанта», система создана для централизованного мониторинга и контроля действий всех ИИ-агентов, работающих в инфраструктуре банка. ARM, по-видимому, включает в себя реальный сбор метрик о поведении агентов, проверку их действий на соответствие политикам и механизм экстренной изоляции в случае обнаружения аномальной активности. Такой подход позволяет не запрещать инновации, а управлять ими в рамках приемлемого риска, создавая единый «мозг» безопасности для всей агентной экосистемы.
Агент по кредитному скорингу с человеческим контролем
В типовом сценарии обработки кредитной заявки agentic-first-подход выглядит следующим образом. Агент получает заявку, самостоятельно собирает данные из внутренних систем (кредитная история, текущие продукты), запрашивает информацию из бюро, анализирует транзакционную активность клиента и формирует предварительный скоринговый балл. Важнейший нюанс: агент не принимает окончательное решение об одобрении или отказе. Он подготавливает полный пакет данных и рекомендацию для кредитного специалиста, который финальное решение принимает самостоятельно. Таким образом, агент берёт на себя до 80% рутинной работы по сбору и анализу, а человек сохраняет контроль за решением с высокой ценой ошибки.
Что это значит для российской компании
Для российских финансовых компаний переход к agentic-first сопряжён с уникальным набором вызовов, связанных с инфраструктурой, санкциями и регуляторной неопределённостью. Дефицит GPU, о котором заявили «Сбер» и «Яндекс», напрямую увеличивает стоимость и сроки создания собственных высокопроизводительных моделей. Это делает зависимость от зарубежных API или российских облачных платформ критическим фактором планирования. При этом использование публичных облаков для 82% банков является проблемой, что толкает их к дорогостоящему строительству собственных дата-центров.
Правовая база также требует внимательного анализа. Методические рекомендации Банка России № 3-МР служат основным ориентиром, но прямого применения норм 243-ФЗ к агентным системам в открытых источниках не описано. Это создаёт серую зону, где каждому банку приходится самостоятельно вырабатывать подходы к определению ответственности за действия агента. Импортозамещение в этой сфере осложняется не только нехваткой железа, но и отставанием российских моделей по качеству и функциональности, что признано самими разработчиками.
| Вариант внедрения | Преимущества | Недостатки и риски |
|---|---|---|
| API зарубежного вендора (OpenAI, Anthropic) | Высокое качество моделей, быстрый старт | Санкционные риски, передача данных за рубеж, валютные платежи |
| Российская модель on-premise | Контроль данных, соответствие 152-ФЗ | Высокие CAPEX, зависимость от доступности GPU, возможное отставание по качеству |
| Гибридная модель (рос. ядро, заруб. API) | Снижение зависимости, использование лучших решений | Сложная архитектура, удвоение рисков безопасности и комплаенса |
Что делать: пошагово
- Провести инвентаризацию процессов. Выявите рутинные, многократно повторяющиеся операции с чётко определёнными правилами и низкой ценой ошибки для запуска первого пилота.
- Сформировать кросс-функциональную команду. Включите в неё представителей бизнеса, ИТ, информационной безопасности, комплаенса и юридического отдела для учёта всех рисков на раннем этапе.
- Определить архитектуру управления. Выберите модель контроля: встроенные ограничения, внешний аудитор или централизованный оркестратор. За основу можно взять трёхуровневую схему, описанную в отраслевых материалах.
- Разработать политики доступа и лимиты. Чётко разграничьте права на чтение данных, подготовку решения и его исполнение. Установите жёсткие лимиты на суммы операций, частоту запросов и перечень доступных систем.
- Подготовить данные. Каталогизируйте и очистите внутренние данные. По опросам, это проблема для 55% банков, и без её решения качество работы агента будет низким.
- Запустить пилотный проект в изолированном контуре. Начните с внутреннего агента, например, для помощи сотрудникам фронт-офиса, чтобы отработать технологии и процессы без риска для клиентов.
- Провести комплексное тестирование безопасности. Включите в тестирование red-team упражнения для проверки на уязвимости, такие как prompt injection или попытки выхода за пределы полномочий.
- Внедрить непрерывный мониторинг и аудит. Настройте сбор и анализ логов всех действий агента, включая запрос, использованные данные, версию модели и итоговое решение, в соответствии с рекомендациями Банка России.
Типичные ошибки
- Смешение предложения и исполнения. Ошибка, при которой агент не только предлагает действие (например, подготовить платёж), но и сразу его исполняет. Это дорого обходится, так как ошибка приводит к необратимым финансовым операциям.
- Предоставление избыточных прав. Выдача агенту широких полномочий «на вырост» в надежде на гибкость. На практике это создаёт огромную уязвимость, которую могут использовать как злоумышленники, так и сам агент при ошибке.
- Игнорирование каскадных сбоев. Проектирование агентов как изолированных систем без учёта их взаимодействия. Ошибка одного агента может запустить цепочку неверных действий в других, что приводит к масштабным инцидентам.
- Недостаточное журналирование. Ведение логов только финальных действий агента без фиксации контекста, входных данных и цепочки рассуждений. Это делает невозможным расследование инцидента и доказательство регулятору добросовестности.
- Отсутствие эскалации человеку. Попытка с самого начала автоматизировать сложные и рискованные процессы, например, полное одобрение кредита, без предусмотренного сценария передачи задачи оператору.
- Экономия на тестировании безопасности. Фокус только на функциональности и производительности агента в ущерб проверке на устойчивость к атакам и аномальным поведению. Это приводит к тому, что уязвимости выявляются уже на боевом этапе эксплуатации.
Как понять, что вы на верном пути
- Каждый агент имеет чётко ограниченную зону ответственности и набор инструментов. Нет «агентов-универсалов», которые могут делать всё.
- Все действия агента или его предложения полностью аудируемы и воспроизводимы. Вы можете в любой момент отследить, почему агент принял то или иное решение.
- Существует формализованный и протестированный механизм эскалации человеку. Оператор вмешивается не по своей инициативе, а по заранее определённым триггерам.
- Риски и лимиты агента заложены в архитектуру на этапе проектирования. Безопасность не добавляется как «надстройка» после разработки.
- Команда управления рисками ИИ является равноправным участником проекта наравне с разработчиками. Её мнение имеет право вето на технические решения.
Вопросы, которые нам задают
С какого агента лучше всего начать?
Оптимальной стартовой точкой является внутренний агент для поддержки сотрудников. Например, агент, который помогает оператору колл-центра находить информацию в базах знаний, формирует типовые ответы и создаёт заявки в другие системы. Это сценарий с низким риском, который позволяет отработать технологический стек и процессы управления, не подвергая опасности клиентские данные и средства.
Нужно ли полностью отказываться от зарубежных моделей?
Полный отказ не всегда обязателен, но требует тщательной оценки рисков. Использование API зарубежных вендоров возможно для некритических задач или на начальных этапах пилота. Для стратегически важных агентов, работающих с чувствительными данными, развёртывание российской модели в собственном контуре является более надёжным, хоть и более дорогим решением. Гибридный подход также возможен, но усложняет архитектуру.
Как определить ответственность за ошибку агента?
Юридическая ответственность за любые действия, совершённые в инфраструктуре банка, остаётся на самой финансовой организации. Ключевым фактором для регулятора и суда будет наличие доказательств должной осмотрительности: чётко задокументированные политики безопасности, полный аудит действий агента и наличие работающего механизма контроля со стороны человека. Без этих элементов доказать, что компания приняла все разумные меры для предотвращения ошибки, будет невозможно.
Источники
- ComNews — Российские корпорации инвестировали в ИИ 220 млрд рублей за 2025 год
- Business FM — «Сбер» и «Яндекс» признали отставание России от США и Китая в ИИ
- Gazeta.press — «Сбер» заявил о переходе финансового сектора к agentic-first-модели
- Deloitte — Agentic AI in banking
- Deloitte — Agentic AI risks in banking
- Российская газета» — Опрос банков об ограничениях для ИИ
- Гарант — Методические рекомендации Банка России № 3-МР
- Банк России — Заседание экспертного совета 23 июня 2026
- Банковское обозрение» — Агенты для выживания
- Коммерсантъ» — Альфа-банк развивает контур Agent Risk Management