Cloudflare ir pievienojis nelielu, bet svarīgu AI Gateway vadīklu: tagad komandas var pieprasīt trešās puses nodrošinātāja akreditācijas datus, pirms tiek atļauts izpildīt pieprasījumu. Ja vārteja neatrod piemērotus akreditācijas datus, pieprasījums neizdodas, izmantojot HTTP 400, tā vietā, lai atgrieztos uz Cloudflare pārvaldīto vienoto norēķinu sistēmu.

Tas maina vārda atnest savu atslēgu jeb BYOK praktisko nozīmi. Līdz šim trūkstošā nodrošinātāja atslēga varēja būt konfigurācijas problēma, kas joprojām radīja veiksmīgu modeļa izsaukumu, taču tika izmantots cits norēķinu ceļš. Izmantojot jauno iestatījumu, akreditācijas datu trūkums kļūst par nopietnu politikas pārkāpumu. Organizācijām, kas atdala klientiem piederošos modeļu kontus no centralizēti maksātās trafika, šī atšķirība ir svarīgāka, nekā to norāda statusa kods.

Kas mainījās

Cloudflare 14. septembra atjauninājumā ir pievienoti divi veidi, kā ieviest jauno darbību. Vārtejas līmenī administratori var iespējot iestatījumu byok_only. Pieprasījuma brīdī zvanītāji var nosūtīt galveni cf-aig-no-wholesale, lai novērstu vairumtirdzniecības norēķinu atkāpšanos šim pieprasījumam.

Kad tiek piemērota kontrole un pakalpojumu sniedzēja akreditācijas dati nav pieejami, AI Gateway atgriež HTTP 400. Cloudflare saka, ka Workers AI pieprasījumi joprojām ir atļauti, tāpēc politika, iespējams, ir īpaši saistīta ar trešo daļu. akreditācijas dati.

Funkcija nav jauna modeļa maršrutētājs vai cenu atlaide. Tas ir norēķinu režīma aizsargmargas. Tādējādi tas ir tieši saistīts ar vienotajiem AI API norēķiniem, jo viena vārteja tagad var novilkt asāku robežu starp centralizēti apmaksātu trafiku un pieprasījumiem, kas jāiekasē no klienta paša pakalpojumu sniedzēja konta.

Kāpēc norēķinu atkāpšanās ir riskanta, kad prioritāte ir ērta

. Ja pakalpojumu sniedzēja akreditācijas datu nav, tā derīguma termiņš ir beidzies vai tas nav pievienots pareizajam maršrutam, vārtejas pārvaldīts akreditācijas dati var nodrošināt lietojumprogrammas darbību. Taču šīs pašas ērtības var radīt nekārtīgu rēķinu izsekošanu.

SaaS piegādātājs, aģentūra vai iekšējās platformas komanda var apsolīt, ka konkrētā nomnieka datplūsma tiks izmantota tikai nomnieka OpenAI, Anthropic, Google vai cita pakalpojumu sniedzēja kontā. Ja vārteja klusībā izmanto vairumtirdzniecības akreditācijas datus, pieprasījums joprojām var izdoties, taču ir mainījusies komerciālā nozīme. Platformas operators var absorbēt izmaksas, pārskaitīt tās nepareizi vai zaudēt spēju saskaņot lietojumu ar klienta paša nodrošinātāja rēķinu.

Tas ir īpaši jutīgs attiecībā uz tālākpārdevēju un partneru API modeļiem. Viens klients var būt BYOK iepirkuma noteikumu dēļ. Cits var izmantot platformas norēķinu kredītus. Trešajai pusei var būt nepieciešami atsevišķi pakalpojumu sniedzēja konti regulatīvu vai datu pārvaldības iemeslu dēļ. Šajā vidē norēķinu ceļš ir daļa no produkta līguma, nevis ieviešanas informācija.

Jaunā Cloudflare vadīkla sniedz komandām iespēju padarīt šo līgumu izpildāmu pie vārtejas robežas. Neveiksmīgs pieprasījums ir kaitinošs, taču to ir vieglāk atkļūdot nekā veiksmīgu pieprasījumu, kas vēlāk tiek parādīts nepareizajā izmaksu centrā.

Kas tiek ietekmēts

Tiešā mērķauditorija ir jebkura komanda, kas izmanto Cloudflare AI Gateway ar pakalpojumu sniedzējam piederošu akreditācijas datu un Cloudflare pārvaldīto norēķinu kombināciju. Izmaiņas ir visnozīmīgākās, ja vairākiem nomniekiem, vidēm vai biznesa vienībām ir kopīga vārtejas konfigurācija.

Izstrādātājiem būs jāizlemj, vai maršrutam vajadzētu dot priekšroku pieejamībai vai stingrai norēķinu izolācijai. Finanšu un operāciju komandas iegūst tīrāku mehānismu, lai novērstu nejaušu vairumtirdzniecības izmantošanu. Drošības un platformu komandas iegūst vēl vienu sviru API atslēgu pārvaldībai, jo nodrošinātāja akreditācijas datu esamība vai neesamība tagad ir tieši saistīta ar to izpildi.

Pilnīgāk AI vārtejas operatoriem atjauninājums ir signāls. Norēķinu vadīklas kļūst par politikas vadīklām. Vairs nepietiek tikai parādīt, ka pieprasījumā tika izmantots konkrēts modelis. Vārtejas arvien vairāk ir jāreģistrē, kurš akreditācijas datu ceļš tika izmantots, kam piederēja šie akreditācijas dati, kurš nomnieks vai API atslēga ir uzsākusi zvanu un vai bija atļauta atkāpšanās.

Modeļu vārti lietotāji saskaras ar to pašu pamata problēmu, kad viņi pārvalda komandas, API atslēgas, lietojuma analīzi un partneru piekļuvi. Klienta darbības jomas atslēga nav tikai autentifikācijas marķieris; tas var ietvert norēķinu režīmu, tēriņu ierobežojumu, pakalpojumu sniedzēja kontu un audita gaidu kopumu. Ja šīs nozīmes netiek konsekventi ieviestas, analīzes informācijas paneļi un rēķini var novirzīties no tā, ko klienti uzskata, ka viņi ir iegādājušies.

Praktiskās sekas

Pirmā praktiskā izmaiņa ir kļūdu apstrāde. Lietojumprogrammām, kas iespējo tikai BYOK vadīklas, HTTP 400 no vārtejas jāuzskata par konfigurācijas vai akreditācijas datu problēmu, nevis kā modeļa kļūmi.Atkārtoti mēģinot izpildīt to pašu pieprasījumu, nelabojot akreditācijas datus, var rasties tikai troksnis.

Otrā izmaiņa ir iekļaušana. Komandām, kas ļauj klientiem ienest pakalpojumu sniedzēja atslēgas, pirms ražošanas trafika sākšanas ir jāveic stingrāka akreditācijas datu pārbaude. Īrniekam tiešās darbplūsmas laikā nevajadzētu atklāt, ka tā nodrošinātāja atslēga nekad nav bijusi pievienota vārtejas maršrutam.

Trešā izmaiņa ir novērojamība. Vārtejas žurnālos un lietošanas pārskatos ir jāatklāj, vai pieprasījumā tika izmantots BYOK, platformas norēķini vai bloķēts rezerves ceļš. Bez šī lauka atbalsta komandas var zināt, ka pieprasījums neizdevās, bet ne to, vai kļūme aizsargāja norēķinu robežu.

Visbeidzot, partneru platformām ir jāpārskata savi noklusējuma iestatījumi. Stingra BYOK izpilde ne vienmēr ir pareizā izvēle. Lai saglabātu pakalpojuma nepārtrauktību, daži produkti var apzināti atgriezties pie platformas norēķinu sistēmas. Citiem var būt nepieciešama stingra nošķiršana līgumu, klientu uzticības vai maržas aizsardzības dēļ. Svarīgi ir tas, ka lēmums var būt nepārprotams, nevis nejaušs.

Kas paliek neskaidrs

Publiskās izmaiņas apraksta politikas mehānismus, taču komandām joprojām būs jāpārbauda, ​​kā tas darbojas atkarībā no pakalpojumu sniedzēju kombinācijas, maršruta struktūras un akreditācijas datu mantošanas modeļa. Pagaidām arī nav skaidrs, cik plaši lietojumprogrammu ietvari un trešo pušu novērošanas rīki parādīs šo norēķinu režīma atšķirību noklusējuma informācijas paneļos.

Pilnīgākais virziens ir pietiekami skaidrs. Vairāku modeļu vārtejas kļūst par finanšu kontroles plāniem tikpat lielā mērā kā API starpniekserveri. Cloudflare tikai BYOK iestatījums ir šaurs līdzeklis, taču tas attiecas uz reālu kļūmes režīmu: pieprasījumu, kas darbojas tehniski, pārkāpjot paredzēto norēķinu modeli.