Cloudflare добави малък, но важен контрол към AI Gateway: екипите вече могат да изискват идентификационни данни на доставчик на трета страна, преди заявката да бъде разрешена за изпълнение. Ако шлюзът не намери приложими идентификационни данни, заявката е неуспешна с HTTP 400, вместо да се върне към управлявано от Cloudflare Унифицирано таксуване.

Това променя практическото значение на донесете свой собствен ключ или BYOK. Досега липсващият ключ на доставчика можеше да бъде проблем с конфигурацията, който все още създаваше успешно моделно повикване, но по различен път за фактуриране. С новата настройка липсващите идентификационни данни се превръщат в сериозно нарушение на правилата. За организации, които отделят моделни акаунти, притежавани от клиенти, от централно таксуван трафик, това разграничение е по-важно, отколкото предполага кодът на състоянието.

Какво се промени

Актуализацията на Cloudflare от 14 септември добавя два начина за налагане на новото поведение. На ниво шлюз администраторите могат да активират настройка byok_only. По време на заявка обаждащите се могат да изпратят заглавката cf-aig-no-wholesale, за да предотвратят резервно таксуване на едро за тази заявка.

Когато контролът се прилага и идентификационните данни на доставчика не са налични, AI Gateway връща HTTP 400. Cloudflare казва, че заявките на Workers AI остават разрешени, така че политиката е специално за заявки на доставчици на трети страни, които иначе биха могли да преминат през Управлявани от Cloudflare идентификационни данни.

Функцията не е нов модел рутер или отстъпка в цената. Това е мантинела в режим на таксуване. Това го прави пряко свързано с унифицираното таксуване на AI API, тъй като един шлюз вече може да очертае по-ясна граница между централно таксувания трафик и заявките, които трябва да бъдат таксувани към собствената сметка на доставчика на клиента.

Защо резервното таксуване е рисковано

Резервният режим е удобен, когато приоритетът е времето за работа. Ако идентификационните данни на доставчика липсват, изтекли са или не са прикачени към правилния маршрут, идентификационните данни, управлявани от шлюза, могат да поддържат работата на приложението. Но същото удобство може да създаде объркана следа от фактури.

Доставчик на SaaS, агенция или вътрешен екип на платформа може да обещае, че трафикът на даден наемател работи само срещу OpenAI, Anthropic, Google или акаунт на друг доставчик на този наемател. Ако вместо това шлюзът тихо използва идентификационни данни на едро, заявката все още може да успее, но търговският смисъл се е променил. Операторът на платформата може да поеме разходите, да ги предаде неправилно или да загуби способността да съпостави използването със сметката на доставчика на клиента.

Това е особено чувствително за дистрибутори и партньорски API модели. Един клиент може да е на BYOK поради правилата за обществени поръчки. Друг може да използва кредити, таксувани от платформа. Трети може да изисква отделни акаунти на доставчик поради регулаторни причини или причини, свързани с управлението на данни. В тази среда пътят за фактуриране е част от продуктовия договор, а не детайл от изпълнението.

Новият контрол на Cloudflare дава на екипите начин да направят този договор приложим на границата на шлюза. Неуспешната заявка е оперативно досадна, но е по-лесно да се отстранят грешки, отколкото успешна заявка, която по-късно се появява в грешен разходен център.

Кой е засегнат

Непосредствената аудитория е всеки екип, използващ Cloudflare AI Gateway с комбинация от идентификационни данни, притежавани от доставчика, и таксуване, управлявано от Cloudflare. Промяната има най-голямо значение, когато множество наематели, среди или бизнес единици споделят конфигурация на шлюз.

Разработчиците ще трябва да решат дали даден маршрут трябва да предпочете наличност или стриктна изолация на таксуването. Финансовите и оперативните екипи получават по-чист механизъм за предотвратяване на случайно използване на едро. Екипите по сигурността и платформата получават още един лост за управление на API ключове, тъй като наличието или отсъствието на идентификационни данни на доставчика вече има директен резултат от прилагането.

За операторите на AI gateway в по-общ план актуализацията е сигнал. Контролът върху фактурирането се превръща в контрол на политиката. Вече не е достатъчно да се покаже, че дадена заявка е използвала конкретен модел. Шлюзовете все повече трябва да записват кой път на идентификационни данни е бил използван, кой притежава тези идентификационни данни, кой клиент или API ключ е инициирал повикването и дали е разрешен резервен вариант.

Потребителите на модел Gate се сблъскват със същия основен проблем, когато управляват екипи, API ключове, анализи на използването и достъп, насочен към партньори. Ключът с обхват на клиента не е просто токен за удостоверяване; може да включва режим на таксуване, лимит на разходите, акаунт на доставчик и набор от очаквания за одит. Ако тези значения не се прилагат последователно, таблата за управление на анализите и фактурите могат да се отклонят от това, което клиентите вярват, че са купили.

Практически последствия

Първата практическа промяна е обработката на грешки. Приложенията, които позволяват контроли само BYOK, трябва да третират HTTP 400 от шлюза като проблем с конфигурацията или идентификационните данни, а не като грешка на модела.Повторният опит за същата заявка без коригиране на идентификационните данни може само да създаде шум.

Втората промяна е включване. Екипите, които позволяват на клиентите да носят ключове на доставчик, се нуждаят от по-силна стъпка за проверка на идентификационните данни, преди да започне производствен трафик. Клиентът не трябва да открива по време на работен процес на живо, че неговият ключ на доставчик никога не е бил прикрепен към маршрута на шлюза.

Третата промяна е възможността за наблюдение. Регистрационните файлове на шлюза и отчетите за използване трябва да разкриват дали дадена заявка е използвала BYOK, таксуване на платформа или блокиран резервен път. Без това поле екипите за поддръжка може да знаят, че дадена заявка е неуспешна, но не и дали грешката е защитила граница на таксуване.

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

Какво остава неясно

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

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