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