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