Цлоудфларе је додао малу, али важну контролу за АИ Гатеваи: тимови сада могу да захтевају акредитиве добављача треће стране пре него што захтев буде дозвољен за покретање. Ако мрежни пролаз не пронађе применљиве акредитиве, захтев не успе са HTTP 400 уместо да се врати на обједињену наплату којом управља Цлоудфларе.
То мења практично значење речи „донесите свој кључ“ или БИОК. До сада је недостајући кључ провајдера могао бити проблем конфигурације који је и даље произвео успешан позив модела, али под другом путањом за обрачун. Са новом поставком, недостајући акредитиви постају тешко кршење смерница. За организације које одвајају налоге модела у власништву клијената од саобраћаја који се наплаћује на централном нивоу, та разлика је важнија него што сугерише статусни код.
Шта се променило
Ажурирање Цлоудфларе-а од 14. септембра додаје два начина за спровођење новог понашања. На нивоу мрежног пролаза, администратори могу да омогуће подешавање byok_only. У тренутку захтева, позиваоци могу да пошаљу заглавље cf-aig-no-wholesale како би спречили резервни наплату на велико за тај захтев.
Када се примењује контрола и акредитиви добављача нису доступни, АИ Гатеваи враћа HTTP 400. Цлоудфларе каже да захтеви за вештачку интелигенцију радника остају дозвољени, тако да су смернице посебно о захтевима треће стране који би иначе могли да обезбеде руту Цлоуд-а. акредитиви.
Ова функција није нови модел рутера или попуст на цене. То је заштитна ограда за начин наплате. То га чини директно релевантним за обједињену вештачку интелигенцију API наплату, јер један мрежни пролаз сада може да повуче оштрију линију између централно наплаћеног саобраћаја и захтева који морају да се наплаћују налогу сопственог добављача клијента.
Зашто је резервни начин обрачуна ризичан
Време је згодно када је приоритет Фалл. Ако је акредитив провајдера одсутан, истекао или није повезан са правом рутом, акредитив којим управља мрежни пролаз може да одржи апликацију да ради. Али та иста погодност може да створи неуредан траг фактура.
СааС добављач, агенција или тим интерне платформе могу обећати да ће се саобраћај датог закупца одвијати само на налогу тог закупца OpenAI, Anthropic, Google или другог провајдера. Ако мрежни пролаз нечујно користи велепродајни акредитив, захтев може и даље успети, али се комерцијално значење променило. Оператер платформе може да апсорбује трошкове, да их погрешно пренесе или да изгуби могућност да усклади коришћење са рачуном сопственог добављача клијента.
Ово је посебно осетљиво за моделе препродаваца и партнера API. Један купац може бити на БИОК-у због правила набавке. Други може да користи кредите наплаћене платформом. Трећи може захтевати посебне налоге добављача из регулаторних разлога или разлога за управљање подацима. У том окружењу, путања за обрачун је део уговора о производу, а не детаљ имплементације.
Нова контрола Цлоудфларе-а даје тимовима начин да тај уговор учине применљивим на граници пролаза. Неуспели захтев је оперативно досадан, али је лакше отклонити грешке него успешан захтев који се касније појави у погрешном центру трошкова.
Ко је погођен
Непосредна публика је сваки тим који користи Цлоудфларе АИ Гатеваи са мешавином акредитива у власништву провајдера и биллингфларе-управљања. Промена је најважнија тамо где више закупаца, окружења или пословних јединица деле конфигурацију мрежног пролаза.
Програмери ће морати да одлуче да ли рута преферира доступност или строгу изолацију обрачуна. Финансијски и оперативни тимови добијају чистији механизам за спречавање случајне употребе на велико. Тимови за безбедност и платформу добијају још једну полугу за API управљање кључевима, јер присуство или одсуство акредитива провајдера сада има директан исход примене.
За оператере АИ гатеваи-а шире, ажурирање је сигнал. Контроле обрачуна постају контроле смерница. Више није довољно показати да је захтев користио одређени модел.Гатеваи-и све више морају да забележе која је путања акредитива коришћена, ко је поседовао тај акредитив, који закупац или кључ API је покренуо позив и да ли је резервни био дозвољен.
Model Gate корисници се суочавају са истим основним проблемом када управљају тимовима, API кључевима, аналитиком коришћења и приступом окренутим према партнеру. Кључ на нивоу корисника није само токен за аутентификацију; може да подразумева начин обрачуна, ограничење потрошње, налог добављача и скуп очекивања ревизије. Ако се та значења не примењују доследно, аналитичке контролне табле и фактуре могу да одступе од онога што клијенти верују да су купили.
Практичне последице
Прва практична промена је руковање грешкама. Апликације које омогућавају контроле само за БИОК треба да третирају HTTP 400 са мрежног пролаза као проблем конфигурације или акредитива, а не као грешку модела. Поновни покушај са истим захтевом без поправљања акредитива може само да створи буку.
Друга промена је укључивање. Тимовима који омогућавају клијентима да донесу кључеве добављача је потребан јачи корак провере акредитива пре него што производни саобраћај почне. Закупац не би требало да открије током радног тока уживо да његов кључ добављача никада није био везан за руту мрежног пролаза.
Трећа промена је видљивост. Евиденције мрежног пролаза и извештаји о коришћењу треба да открију да ли је захтев користио БИОК, наплату платформе или блокирану резервну путању. Без тог поља, тимови за подршку могу да знају да захтев није успео, али не и да ли је грешка заштитила границу обрачуна.
Коначно, партнерске платформе би требало да поново погледају своје подразумеване вредности. Строга примена БИОК-а није увек прави избор. Неки производи се могу намерно вратити на наплату платформе да би се сачувао континуитет услуге. Другима ће можда бити потребно тешко одвајање због уговора, поверења купаца или заштите марже. Важна промена је у томе што одлука може бити експлицитна уместо случајна.
Оно што остаје нејасно
Јавна промена описује механику смерница, али тимови ће и даље морати да тестирају како се она понаша у оквиру сопствене мешавине добављача, структуре руте и модела наслеђивања акредитива. Такође још увек није јасно колико ће широко оквири апликација и алати за посматрање трећих страна приказати ову разлику у начину обрачуна на својим подразумеваним контролним таблама.
Велики правац је довољно јасан. Гатеваи-и са више модела постају равни финансијске контроле као и API проксији. Цлоудфларе-ова поставка само за БИОК је уска карактеристика, али се бави стварном неуспјехом: захтјевом који ради технички док крши предвиђени модел наплате.