Как выбрать LLM-шлюз для банка или прямые контракты

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

Это не выбор между «серьезным контрактом» и удобным API. В обоих вариантах нужны юридическая проверка, оценка безопасности и понятный владелец риска. Разница в том, повторяет ли банк этот контур для каждого провайдера или проверяет один слой, который затем сам отвечает за связи с поставщиками. Я видел проекты, где пилот за неделю превращался в полугодовой спор между закупками, безопасностью и разработкой, потому что этот вопрос решили после написания кода.

Какой объект банк на самом деле выбирает

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

Здесь часто смешивают три разных понятия. «Локальная модель» означает, что веса и вычисления находятся в контролируемой инфраструктуре. «Локальный шлюз» означает, что точка приема, журналы и правила маршрутизации находятся в нужной юрисдикции, хотя часть запросов может уйти во внешний API. «Агрегатор моделей» может дать общий каталог, но не обязан обеспечивать банковские журналы, разграничение ключей или местное хранение. Если закупка пишет эти слова как синонимы, поставщики ответят на три разных вопроса, а комиссия будет сравнивать несопоставимые предложения.

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

Проверка поставщика умножается на число договоров

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

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

Срок проверки определяет не скорость юристов, а самый медленный открытый вопрос. Обычно им становится место обработки, право аудита, содержание журналов или порядок удаления. Поэтому сравнивать варианты по обещанию «подключение за несколько дней» нельзя. Попросите обе стороны заполнить один реестр доказательств: документ, владелец, срок действия, применимый сервис, исключения. Шлюз выигрывает, если этот реестр закрывает несколько моделей одним контролем. Прямые договоры выигрывают, если провайдер дает уникальное доказательство или обязательство, которое посредник не может передать банку.

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

Один договор не создает одну ответственность

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

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

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

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

Централизованный доступ уменьшает поверхность ошибки

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

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

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

{
  "client": "contact-center-prod",
  "data_class": "internal-masked",
  "allowed_models": ["model-a-stable", "model-b-stable"],
  "tools": [],
  "requests_per_minute": 120,
  "monthly_budget_kzt": 900000,
  "expires_at": "2026-12-31"
}

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

Место хранения не равно месту обработки

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

Официальная документация OpenAI хорошо показывает, почему одного флажка региона мало. Она разделяет customer content и system data, описывает стандартные журналы контроля злоупотреблений и указывает, что отдельные функции создают состояние приложения. Anthropic в материалах о Zero Data Retention тоже оговаривает, что режим относится к API и что некоторые функции хранения могут иметь отдельные правила. Google для Vertex AI перечисляет сценарии удержания данных и настройки, нужные для нулевого хранения. Я бы не принимал фразу «zero retention» без таблицы по каждому endpoint и включенной функции.

Локальный шлюз способен принять запрос внутри Казахстана, замаскировать PII, записать локальный аудит и отправить наружу только разрешенную часть. Но он не делает внешний вызов локальной обработкой. Если после фильтрации текст все еще содержит персональные данные, банковскую тайну или данные, по которым можно восстановить клиента, трансграничный риск остается. Маскирование тоже надо тестировать на реальных форматах: ФИО, ИИН, номера договоров, свободный текст операторов и вложения ведут себя по-разному.

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

Отказоустойчивость начинается с семантики ответа

Автоматическое переключение между провайдерами полезно лишь для задач, где другая модель может дать приемлемый результат. HTTP 200 от резервной модели не означает восстановление услуги. У нее могут отличаться формат структурированного ответа, длина контекста, политика безопасности, использование инструментов и качество на банковской терминологии.

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

Перед запуском проведите один воспроизводимый тест отказа:

1. Зафиксируйте десять эталонных запросов, допустимые ответы и запрещенные действия.
2. Искусственно верните тайм-аут основного провайдера после отправки запроса.
3. Проверьте, какой маршрут выбрал слой доступа и сколько попыток он сделал.
4. Сравните структуру и качество резервного ответа с заданными порогами.
5. Убедитесь, что журнал связывает обе попытки одним идентификатором и называет источник сбоя.

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

Цена токена скрывает большую часть стоимости

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

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

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

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

Шлюз добавляет собственный риск концентрации

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

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

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

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

Матрица решения должна приводить к владельцу риска

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

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

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

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

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

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

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

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

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

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

После заполнения у каждой спорной ячейки появляется человек, который принимает остаточный риск. Если никто не готов подписаться под внешним хранением, маршрут нельзя открывать. Если бизнес принимает остановку при сбое, не нужно оплачивать сложный fallback. Матрица полезна тем, что превращает абстрактное «безопаснее» в проверяемое решение и не дает коллективному обсуждению растворить ответственность.

NIST AI Risk Management Framework делит работу на govern, map, measure и manage и прямо предупреждает, что действия не образуют универсальный чек-лист. Для закупки это здравый ориентир: договор относится к govern, карта потока к map, тесты качества и отказа к measure, а переключение и разбор инцидента к manage. Покупка API закрывает только часть первой функции. Полная матрица показывает, кто продолжает работу после подписания договора, потому что риск модели меняется вместе со сценарием, данными и версией.

Гибридная схема обычно честнее бинарного выбора

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

У AI Router один OpenAI-совместимый endpoint может маршрутизировать запросы к внешним и локально размещенным open-weight моделям, применять маскирование PII, аудит-логи и лимиты на уровне ключа. Для банка это кандидат на единый контрольный слой, а не основание пропустить собственную оценку цепочки, режима данных и восстановления.

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

Решение готово к закупке, когда банк способен объяснить судьбу одного запроса без презентации поставщика: кто имел право его отправить, какие данные удалили, где его обработали, почему выбрали эту модель, что записали в журнал и кто действует при ошибке. Если на любой вопрос отвечают разные команды и ответы расходятся, спор о прямом контракте пока преждевременен. Сначала определите границу управления, которую банк действительно сможет эксплуатировать.