Cloudflare добавила в AI Gateway элемент управления, который позволяет операторам запрашивать учетные данные поставщика при запросах сторонних моделей. Изменение небольшое с точки зрения интерфейса, но оно решает практическую проблему управления для команд, маршрутизирующих трафик AI через шлюз: что должно произойти, если клиент, проект или арендатор не предоставил действительный ключ поставщика?
До этого обновления Cloudflare AI Gateway мог использовать настройку единого выставления счетов в качестве резервного пути для поддерживаемых сторонних поставщиков. Это может быть удобно, если в противном случае запрос не будет выполнен, но это также может размыть границы распределения затрат и соблюдения требований. Новая настройка «только BYOK» позволяет владельцам шлюзов предотвратить этот резервный вариант и потребовать, чтобы вместо этого в запросах использовались явно предоставленные учетные данные «принеси свой собственный ключ».
Cloudflare утверждает, что эту настройку можно включить на панели управления или через API с помощью byok_only=true. Он также добавил заголовок для каждого запроса cf-aig-no-wholesale для случаев, когда команды хотят заблокировать оптовое использование учетных данных или учетных данных, управляемых Cloudflare, для отдельных вызовов.
Что изменилось
В журнале изменений AI Gateway от 14 сентября вводятся требования к учетным данным для запросов сторонних поставщиков. Если эта функция включена, шлюз не будет автоматически возвращаться к учетным данным единого биллинга, управляемым Cloudflare, если вызывающая сторона не предоставила приемлемые учетные данные поставщика.
Это различие важно, поскольку шлюзы искусственного интеллекта все чаще располагаются между многими внутренними приложениями, внешними клиентами и несколькими поставщиками моделей. Отсутствие ключа – это не просто техническая неисправность. Он может решить, какому юридическому лицу выставляться счет, какая квота поставщика учетной записи будет использована и будет ли использование использоваться в правильном центре затрат.
Новый элемент управления дает командам платформы более строгий режим работы. Вместо того, чтобы рассматривать отсутствие учетных данных клиента как неудобство маршрутизации, шлюз может рассматривать их как нарушение политики. Это особенно актуально для настроек реселлеров, развертывания ключей, принадлежащих клиенту, и корпоративных сред, где отношения с поставщиком должны оставаться напрямую привязанными к бизнес-подразделению или арендатору.
Почему это важно для операторов шлюзов ИИ
При проектировании шлюзов ИИ часто основное внимание уделяется маршрутизации, задержке, кэшированию, повторным попыткам и абстракции модели. Платежное поведение заслуживает такого же внимания. Если шлюз автоматически меняет режим учетных данных, когда один путь недоступен, отчеты нижестоящего уровня могут ввести в заблуждение. Запрос может выглядеть как обычный трафик приложения, в то время как счет-фактура поступает куда-то еще.
Для предприятий, использующих центральный уровень контроля затрат на AI API, это создает операционный риск. Финансовые отделы могут потерять достоверные данные о возвратных платежах. Службы безопасности могут не знать, какие учетные данные были фактически использованы. Командам разработчиков может быть сложно объяснить, почему счет за использование одного арендатора выставлялся через учетную запись платформы, а не через собственную учетную запись поставщика этого арендатора.
Режим «только BYOK» также помогает выполнять обязательства перед клиентами. Некоторые покупатели требуют, чтобы вызовы моделей регулировались их собственными контрактами с поставщиками, условиями обработки данных или региональными настройками. Если шлюз может вернуться к управляемым учетным данным для выставления счетов, это обязательство становится труднее обеспечить, если только откат не отключен политикой.
Заголовок каждого запроса добавляет более детализированную опцию. Платформа может обеспечить доступность более широкого режима единого выставления счетов для некоторых рабочих нагрузок, одновременно предотвращая его для запросов, которые предъявляют более строгие требования к соответствию, реселлерам или атрибуции. Это дает разработчикам путь миграции, не переводя каждое приложение одновременно в самый строгий режим.
Кого это касается
Непосредственной аудиторией является любая команда, использующая Cloudflare AI Gateway для передачи запросов сторонним поставщикам искусственного интеллекта. Это изменение наиболее актуально в тех случаях, когда несколько команд, арендаторов или клиентов используют один шлюз и где ожидается, что учетные данные поставщика будут принадлежать за пределами учетной записи центральной платформы.
Команды, работающие над корпоративной платформой искусственного интеллекта, должны проверить, соответствует ли поведение их шлюза внутренней политике. Если проект должен использовать собственную учетную запись OpenAI, Anthropic, Google, Mistral или другого провайдера, шлюз должен сделать эту зависимость видимой и осуществимой. Резервный вариант, который помогает успешной демо-версии, может стать проблемой в производстве, если он скрывает неверную настройку учетных данных.
У реселлеров и партнерских платформ есть более острая версия той же проблемы. Если клиенты приносят свои собственные ключи поставщика, операторам платформы нужна уверенность в том, что трафик не будет случайно преобразован в использование, выставляемое платформой. В противном случае это может повлиять на прибыль, счета-фактуры, аудиторские записи и доверие клиентов.
Разработчики тоже страдают, хотя в основном из-за более явных ошибок. При применении только BYOK запрос, у которого отсутствуют надлежащие учетные данные, должен завершиться ошибкой, а не маршрутизироваться по альтернативному пути выставления счетов.Это может потребовать более качественных проверок при подключении, более четкой обработки ошибок и тестов развертывания, которые проверяют ключи поставщика до того, как трафик будет запущен.
Практические последствия
Первым практическим шагом является инвентаризация политик. Команды должны решить, каким рабочим нагрузкам разрешено использовать единый биллинг, управляемый Cloudflare, а какие должны использовать учетные данные поставщика, принадлежащие клиенту или проекту. Это решение должно быть явным, а не оставлено на усмотрение шлюза по умолчанию.
Второй шаг — наблюдаемость. Журналы и аналитика использования должны фиксировать, какой режим учетных данных использовался, был ли заблокирован запрос из-за включения режима «только BYOK», а также какой клиент или проект предоставил ключ. Без такой прозрачности более строгий контроль может уменьшить двусмысленность в выставлении счетов, но по-прежнему оставит операторов скудными данными для устранения неполадок.
Третий шаг – рабочий процесс разработчика. Приложения, зависящие от AI Gateway, должны выходить из строя раньше, если учетные данные отсутствуют. Проверка запуска, проверка развертывания или предупреждение консоли администратора лучше, чем обнаружение проблемы после отклонения производственного запроса.
Оставшаяся неопределенность связана не столько с самой функцией, сколько с шаблонами внедрения. Cloudflare задокументировала новый элемент управления, но каждому оператору еще предстоит решить, где его применять. Некоторые команды предпочтут отказоустойчивость резервного выставления счетов для внутренних экспериментов. Другие сделают использование по умолчанию только BYOK для трафика рабочего клиента. Важным изменением является то, что теперь это выбор управления, а не неявное поведение, скрытое внутри уровня маршрутизации.