Короткий ответ. Когда в банке появляется несколько десятков AI-сценариев, проблема перестает быть выбором «лучшей нейросети». Возникает инфраструктурная задача: где выполнять модели, как распределять GPU, какие данные им разрешены, как переключаться между провайдерами, кто контролирует стоимость, как версионировать промпты и модели и что произойдет при сбое. Альфа-Банк в 2026 году сообщил о собственной GPUaaS-платформе в multi-cloud режиме, HSBC расширяет партнерство с Google Cloud на сотни AI-кейсов, а Moody’s предупреждает о растущей зависимости финансового сектора от небольшого числа технологических поставщиков. Эти три факта хорошо описывают главный конфликт: скорость внедрения против стратегического контроля.
Почему отдельные AI-проекты плохо масштабируются
Первый пилот легко собрать локально: команда берет модель, подключает документы и показывает результат. Десятый пилот начинает повторять инфраструктуру первого. Появляются разные способы авторизации, собственные векторные базы, несогласованные версии моделей, дублирование GPU и разный уровень безопасности. К двадцатому проекту банк фактически управляет зоопарком AI-систем.
Платформенный подход пытается вынести общие функции в единый слой. Бизнес-команда получает модель через gateway, данные через стандартный RAG, инструменты через каталог API, а мониторинг качества и стоимости — централизованно. Это снижает time-to-market и одновременно упрощает контроль. Но платформа быстро становится критической инфраструктурой, поэтому требования к ней ближе к core banking, чем к экспериментальной песочнице.
Что входит в промышленную AI-платформу банка
Кейс Альфа-Банка: GPU как внутренний сервис
В мае 2026 года Альфа-Банк сообщил о запуске GPUaaS в multi-cloud режиме с поддержкой высокоскоростного обмена между GPU и сетевой сегментацией в Kubernetes. По заявлению банка, платформа была создана за три месяца и объединила собственные и облачные вычислительные ресурсы. Важно не конкретное название технологий, а организационный смысл: дефицитная GPU-мощность превращается в управляемый внутренний ресурс, который можно выделять разным AI-командам по правилам.
Для крупного банка это логично. Разные задачи имеют разный профиль. Обучение или fine-tuning требуют интенсивного compute короткими периодами. Массовый inference требует стабильной доступности. Чувствительные сценарии могут быть ограничены внутренним контуром. Непредсказуемые пики удобнее отправлять в облако. Multi-cloud позволяет балансировать эти классы, хотя сам по себе не гарантирует экономию.
Почему загрузка GPU — плохая бизнес-метрика
Инфраструктурная команда естественно смотрит на utilization, стоимость часа и очередь задач. Но банк покупает не GPU-загрузку, а сокращение времени сотрудника, снижение мошенничества, рост продаж или улучшение сервиса. Дешевая модель, которая требует трех повторных вызовов и часто ошибается, может быть дороже сильной модели. Собственный GPU может казаться выгодным, пока не учтены простаивающие мощности, команда эксплуатации, электричество, сеть и обновление оборудования.
Поэтому правильная единица — cost per successful task. Для контакт-центра это стоимость корректно закрытого обращения, для coding assistant — стоимость принятого изменения, для документов — стоимость обработанного пакета с заданной точностью. Такая метрика позволяет честно сравнивать on-prem, облако и разные модели.
Model gateway становится обязательным слоем
Ни один банк не должен проектировать все AI-приложения вокруг API одной модели. Рынок меняется слишком быстро. Сегодня одна модель лучшая в коде, другая — в русском языке, третья — в длинном контексте, четвертая — дешевле для классификации. Gateway позволяет приложению запрашивать класс сервиса, а не конкретный бренд модели.
Это не означает, что переключение полностью прозрачно. Модели по-разному реагируют на промпты, имеют разные контекстные окна и форматы tool calling. Поэтому банк должен хранить набор evaluation-тестов для каждого сценария. Новая модель проходит их до допуска. Тогда multi-model стратегия становится управляемой, а не хаотичной.
HSBC показывает противоположный полюс: ставка на hyperscaler
HSBC объявил многолетнее партнерство с Google Cloud и планы развивать более 200 новых AI use cases. Банк уже использует сотни приложений в Google Cloud и рассчитывает на доступ к технологиям Google DeepMind и агентным возможностям. Такая стратегия дает скорость: вместо построения каждого слоя самостоятельно банк получает зрелую инфраструктуру, модели, инструменты и инженерную поддержку.
Но чем глубже интеграция, тем выше switching cost. Если десятки процессов используют proprietary services одного провайдера, формально «перенести модель» недостаточно. Потребуется перенос данных, IAM, observability, agent framework и десятков интеграций. Поэтому vendor strategy должна оцениваться на горизонте нескольких лет, а не только по скорости первого запуска.
Предупреждение Moody’s: технологическая концентрация становится финансовым риском
В августе 2026 года в публичной дискуссии появилось предупреждение Moody’s о том, что ускоренное внедрение AI усиливает зависимость банков от ограниченного круга технологических компаний. Это не абстрактный antitrust-вопрос. Одновременный сбой крупного облака или AI-провайдера может затронуть множество финансовых институтов. Рост цен способен повысить операционные расходы сразу по отрасли. Изменение условий доступа к модели — нарушить критичные процессы.
Для отдельного банка это означает необходимость concentration risk assessment. Нужно знать долю AI-нагрузки на каждого поставщика, список критичных процессов, доступный fallback и максимальное время восстановления. Такие показатели должны обсуждаться не только архитектурным комитетом, но и операционным риск-менеджментом.
Собственная модель не равна независимости
Иногда ответом на vendor lock-in называют open source и локальное развертывание. Это действительно дает больше контроля, но зависимость просто перемещается. Нужны GPU, библиотечный стек, специалисты, обновления безопасности, датасеты и система оценки. Если банк использует конкретную архитектуру ускорителей или один дистрибутив, новый lock-in может оказаться не меньше облачного.
Рациональная цель — не абсолютная независимость, а управляемая заменяемость. Для критичных функций должен существовать альтернативный путь с приемлемым снижением качества. Для некритичных можно сознательно принять зависимость, если экономический эффект выше риска.
Данные важнее модели
На практике основная ценность банковского AI часто находится не в LLM, а в доступе к качественным внутренним данным. Если права доступа к документам плохо описаны, RAG будет либо слишком ограничен, либо небезопасен. Если нет актуальности и владельцев знаний, модель будет цитировать старые инструкции. Если master data расходится между системами, персональный ассистент начнет давать противоречивые ответы.
Поэтому AI-platform должна включать data lineage, ACL, классификацию чувствительности и механизм удаления данных из индексов. «Мы развернули модель в своем контуре» не решает проблему, если сам контур знаний неуправляем.
Финансовая модель: capex против opex
Собственные GPU требуют капитала и прогнозирования спроса. Облако переводит расходы в opex и удобнее при неопределенности, но цена масштабируется вместе с использованием. Гибридная модель позволяет базовую стабильную нагрузку держать внутри, а пики отдавать наружу. Однако это работает только при реальной переносимости workloads и едином уровне наблюдаемости.
При расчете нужно учитывать не только compute. В стоимость входят storage, сеть, векторный поиск, лицензии, мониторинг, инженеры, безопасность, evaluation и резервные мощности. Для каждого use case следует считать TCO на завершенную задачу и сравнивать с экономическим эффектом.
Как должна выглядеть стратегия банка
Первое — единый реестр моделей и gateway. Второе — классификация данных и стандартный защищенный RAG. Третье — централизованный cost observability, чтобы бизнес видел цену своих AI-сценариев. Четвертое — evaluation framework, который позволяет менять модели без ручного «кажется, стало лучше». Пятое — vendor exit plan хотя бы для критичных функций.
Только после этого имеет смысл спорить, сколько GPU покупать. Иначе железо становится дорогим символом AI-трансформации, а не частью управляемой платформы.
Вывод
AI-инфраструктура банка в 2026 году превращается в стратегический слой. Альфа-Банк показывает путь внутренней GPU-платформы и multi-cloud, HSBC — глубокого партнерства с hyperscaler, а предупреждение Moody’s напоминает о цене концентрации. Универсального ответа нет. Правильная архитектура — та, где банк может измерить стоимость каждого сценария, контролировать доступ к данным, менять модель без переписывания приложения и продолжать критичные операции при отказе поставщика. Именно эта способность, а не число GPU, определяет технологическую устойчивость AI-банка.
Экономика инфраструктуры: модель дороже не всегда лучше
Для банка критична стоимость на завершенную бизнес-операцию, а не цена миллиона токенов. Если небольшая модель решает 80% запросов, а крупная подключается только к сложным, routing может резко снизить TCO без заметной потери качества. Кэширование, batch processing и предварительная классификация также влияют на экономику сильнее выбора одного «лучшего» LLM.
Отдельный вопрос — utilization собственных GPU. Покупка ускорителей выглядит как защита от внешней зависимости, но при низкой загрузке капитал простаивает. Multi-cloud и гибридная архитектура позволяют балансировать локальность, стоимость и доступ к новым моделям, но повышают требования к orchestration.
Vendor concentration — не абстрактный риск
Если десятки банков зависят от одного облака, model API или семейства ускорителей, локальный сбой поставщика становится отраслевым. Поэтому resilience-план должен включать fallback model, переносимость prompts/evaluations и регулярную проверку переключения, а не только пункт в договоре.
Частые вопросы
Зачем банку собственные GPU, если есть облако? — Собственные мощности дают контроль над чувствительными нагрузками и предсказуемостью, но требуют капитальных затрат и высокой утилизации. Многие банки выбирают гибридный или multi-cloud подход.
Multi-cloud устраняет vendor lock-in? — Нет. Он снижает зависимость от одного облака, но модель, API, формат данных и специализированные сервисы также могут создавать lock-in.
Главная экономическая метрика AI-инфраструктуры? — Стоимость завершенного бизнес-процесса при заданном качестве и SLA. Цена токена или загрузка GPU полезны, но недостаточны для управленческого решения.