Cloudflare pridal do AI Gateway malý, ale dôležitý ovládací prvok: tímy teraz môžu vyžadovať poverenia poskytovateľa tretích strán pred povolením spustenia žiadosti. Ak brána nenájde príslušné poverenia, žiadosť zlyhá s protokolom HTTP 400 namiesto toho, aby sa vrátila k zjednotenej fakturácii spravovanej Cloudflare.
To mení praktický význam slova „prines svoj vlastný kľúč“ alebo BYOK. Až doteraz mohol byť chýbajúci kľúč poskytovateľa problémom s konfiguráciou, ktorý stále produkoval úspešné modelové volanie, ale pod inou fakturačnou cestou. S novým nastavením sa chýbajúce poverenia stanú tvrdým porušením pravidiel. Pre organizácie, ktoré oddeľujú modelové účty vlastnené zákazníkmi od centrálne fakturovanej prevádzky, je toto rozlíšenie dôležitejšie, než naznačuje stavový kód.
Čo sa zmenilo
Aktualizácia Cloudflare zo 14. septembra pridáva dva spôsoby, ako presadiť nové správanie. Na úrovni brány môžu správcovia povoliť nastavenie byok_only. V čase vyžiadania môžu volajúci odoslať hlavičku cf-aig-no-wholesale, aby zabránili záložnej veľkoobchodnej fakturácii pre danú žiadosť.
Keď sa použije kontrola a poverenia poskytovateľa nie sú k dispozícii, AI Gateway vráti HTTP 400. Cloudflare hovorí, že požiadavky AI pracovníkov zostávajú povolené, takže pravidlá sa týkajú konkrétne smerovania cez požiadavky poskytovateľa služby Cloudflare>
Prečo je časová priorita fakturácie riskantná
Fallback. Ak poverenie poskytovateľa chýba, jeho platnosť vypršala alebo nie je pripojená k správnej ceste, poverenie spravované bránou môže udržať aplikáciu v prevádzke. Rovnaké pohodlie však môže viesť k chaotickému chodu faktúr.
Dodávateľ služby SaaS, agentúra alebo tím internej platformy môže sľúbiť, že návštevnosť daného nájomníka prebieha iba proti účtu OpenAI, Anthropic, Google alebo iného poskytovateľa daného nájomníka. Ak brána namiesto toho ticho používa veľkoobchodné poverenia, požiadavka môže byť stále úspešná, ale komerčný význam sa zmenil. Prevádzkovateľ platformy môže absorbovať náklady, nesprávne ich preniesť alebo stratiť možnosť zosúladiť používanie s vlastným účtom poskytovateľa zákazníka.
Toto je obzvlášť citlivé pre modely API pre predajcov a partnerov. Jeden zákazník môže byť na BYOK kvôli pravidlám obstarávania. Iný môže použiť kredity účtované platformou. Tretia osoba môže vyžadovať samostatné účty poskytovateľa z regulačných dôvodov alebo z dôvodov správy údajov. V tomto prostredí je fakturačná cesta súčasťou zmluvy o produkte, nie detailom implementácie.
Nové ovládanie Cloudflare poskytuje tímom spôsob, ako zabezpečiť vynútiteľnosť zmluvy na hraniciach brány. Neúspešná žiadosť je prevádzkovo nepríjemná, ale je ľahšie ladiť ako úspešná žiadosť, ktorá sa neskôr objaví v nesprávnom nákladovom stredisku.
Koho sa to týka
Bezprostredným publikom je akýkoľvek tím, ktorý používa Cloudflare AI Gateway s kombináciou poverení vlastnených poskytovateľom a fakturácie spravovanej Cloudflare. Na tejto zmene záleží najviac tam, kde viacero nájomníkov, prostredí alebo obchodných jednotiek zdieľa konfiguráciu brány.
Vývojári sa budú musieť rozhodnúť, či má trasa uprednostňovať dostupnosť alebo prísnu izoláciu fakturácie. Finančné a prevádzkové tímy získajú čistejší mechanizmus na zabránenie náhodnému veľkoobchodnému použitiu. Bezpečnostné a platformové tímy získavajú ďalšiu páku na správu kľúčov API, pretože prítomnosť alebo neprítomnosť poverení poskytovateľa má teraz priamy výsledok.
Pre prevádzkovateľov brán AI je aktualizácia signálom. Kontroly fakturácie sa stávajú kontrolami pravidiel. Už nestačí ukázať, že žiadosť používala konkrétny model. Brány čoraz viac potrebujú zaznamenávať, ktorá cesta poverení bola použitá, kto vlastnil tieto poverenia, ktorý nájomca alebo kľúč API inicioval hovor a či bola povolená núdzová pomoc.
Používatelia modelu Gate čelia rovnakému základnému problému, keď spravujú tímy, kľúče API, analýzy používania a prístup pre partnerov. Kľúč v rozsahu zákazníka nie je len autentifikačný token; môže zahŕňať režim fakturácie, limit výdavkov, účet poskytovateľa a súbor očakávaní auditu. Ak sa tieto významy nepresadzujú dôsledne, analytické panely a faktúry sa môžu odkloniť od toho, čo si zákazníci myslia, že si kúpili.
Praktické dôsledky
Prvou praktickou zmenou je riešenie chýb. Aplikácie, ktoré povoľujú iba ovládacie prvky BYOK, by mali považovať HTTP 400 z brány za problém s konfiguráciou alebo poverením, nie za zlyhanie modelu.Opakovaný pokus o tú istú žiadosť bez opravy poverení môže spôsobiť iba šum.
Druhou zmenou je registrácia. Tímy, ktoré umožňujú zákazníkom priniesť kľúče poskytovateľa, potrebujú pred spustením produkčnej prevádzky dôkladnejší krok kontroly poverení. Nájomník by počas živého pracovného postupu nemal zistiť, že kľúč jeho poskytovateľa nebol nikdy pripojený k trase brány.
Tretia zmena je pozorovateľnosť. Protokoly brány a správy o používaní by mali odhaliť, či žiadosť použila BYOK, fakturáciu platformy alebo zablokovanú záložnú cestu. Bez tohto poľa môžu tímy podpory vedieť, že žiadosť zlyhala, ale nie to, či zlyhanie chránilo hranicu fakturácie.
Nakoniec by partnerské platformy mali prehodnotiť svoje predvolené nastavenia. Prísne presadzovanie BYOK nie je vždy tou správnou voľbou. Niektoré produkty sa môžu zámerne vrátiť k fakturácii platformy, aby sa zachovala kontinuita služby. Iní môžu potrebovať tvrdé oddelenie kvôli zmluvám, dôvere zákazníkov alebo ochrane marže. Dôležitým posunom je, že rozhodnutie môže byť explicitné namiesto náhodného.
Čo zostáva nejasné
Verejná zmena popisuje mechanizmus politiky, ale tímy budú musieť aj tak otestovať, ako sa správa v rámci ich vlastného mixu poskytovateľov, štruktúry smerovania a modelu dedenia poverení. Zatiaľ tiež nie je jasné, do akej miery aplikačné rámce a nástroje na pozorovanie od tretích strán odkryjú tento rozdiel v režime fakturácie na ich predvolených paneloch.
Väčší smer je dostatočne jasný. Viacmodelové brány sa stávajú rovinami finančnej kontroly rovnako ako API proxy. Nastavenie iba BYOK v Cloudflare je úzka funkcia, ale rieši skutočný režim zlyhania: požiadavku, ktorá technicky funguje a zároveň porušuje zamýšľaný model fakturácie.