Cloudflare je prehodu umetne inteligence dodal majhen, a pomemben nadzor: ekipe lahko zdaj zahtevajo poverilnice ponudnika tretje osebe, preden se dovoli izvajanje zahteve. Če prehod ne najde ustreznih poverilnic, zahteva ne uspe z HTTP 400 namesto vrnitve na poenoteno obračunavanje, ki ga upravlja Cloudflare.

To spremeni praktični pomen prinesi svoj ključ ali BYOK. Do zdaj je manjkajoči ključ ponudnika lahko predstavljal konfiguracijsko težavo, ki je še vedno povzročila uspešen modelni klic, vendar na drugi poti obračunavanja. Z novo nastavitvijo manjkajoče poverilnice postanejo resna kršitev pravilnika. Za organizacije, ki ločujejo modelne račune v lasti strank od centralno zaračunanega prometa, je to razlikovanje pomembnejše, kot nakazuje statusna koda.

Kaj se je spremenilo

Posodobitev storitve Cloudflare 14. septembra dodaja dva načina za uveljavitev novega vedenja. Na ravni prehoda lahko skrbniki omogočijo nastavitev byok_only. Ob času zahteve lahko klicatelji pošljejo glavo cf-aig-no-wholesale, da preprečijo nadomestno veleprodajno zaračunavanje za to zahtevo.

Ko se uporablja nadzor in poverilnice ponudnika niso na voljo, AI Gateway vrne HTTP 400. Cloudflare pravi, da zahteve AI Workers ostajajo dovoljene, zato se pravilnik posebej nanaša na zahteve ponudnikov tretjih oseb, ki bi sicer lahko potekale prek oblaka, ki ga upravlja Cloudflare poverilnice.

Funkcija ni nov model usmerjevalnika ali popust pri ceni. Je zaščitna ograja v načinu obračunavanja. Zaradi tega je neposredno povezan z poenotenim AI API obračunavanjem, saj lahko en sam prehod zdaj potegne ostrejšo mejo med centralno zaračunanim prometom in zahtevami, ki jih je treba zaračunati strankinemu lastnemu računu ponudnika.

Zakaj je nadomestno zaračunavanje tvegano

Nadomestno delovanje je priročno, ko je prednost čas delovanja. Če poverilnica ponudnika ni, je potekla ali ni pritrjena na pravo pot, lahko poverilnica, ki jo upravlja prehod, omogoči delovanje aplikacije. Toda ta ista priročnost lahko ustvari neurejeno sled računov.

Prodajalec SaaS, agencija ali interna ekipa platforme lahko obljubi, da promet določenega najemnika teče samo z računom tega najemnika OpenAI, Anthropic, Google ali račun drugega ponudnika. Če prehod namesto tega tiho uporablja veleprodajno poverilnico, lahko zahteva še vedno uspe, vendar se je komercialni pomen spremenil. Operater platforme lahko prevzame stroške, jih posreduje nepravilno ali izgubi zmožnost usklajevanja uporabe z računom strankinega lastnega ponudnika.

To je še posebej občutljivo za modele preprodajalcev in partnerjev API. Ena stranka je lahko na BYOK zaradi pravil javnega naročanja. Drugi lahko uporabi kredite, ki jih zaračuna platforma. Tretji lahko zahteva ločene račune ponudnika zaradi regulativnih razlogov ali razlogov upravljanja podatkov. V tem okolju je obračunska pot del pogodbe o izdelku, ne podrobnost izvedbe.

Novi nadzor Cloudflare daje ekipam možnost, da to pogodbo naredijo izvršljivo na meji prehoda. Neuspela zahteva je operativno moteča, vendar jo je lažje odpraviti kot uspešno zahtevo, ki se pozneje pojavi na napačnem stroškovnem mestu.

Kdo je prizadet

Neposredna ciljna skupina je katera koli ekipa, ki uporablja Cloudflare AI Gateway z mešanico poverilnic v lasti ponudnika in zaračunavanja, ki ga upravlja Cloudflare. Sprememba je najbolj pomembna, če si več najemnikov, okolij ali poslovnih enot deli konfiguracijo prehoda.

Razvijalci se bodo morali odločiti, ali naj pot daje prednost razpoložljivosti ali strogi izolaciji zaračunavanja. Finančne in operativne ekipe dobijo čistejši mehanizem za preprečevanje nenamerne veleprodajne uporabe. Ekipe za varnost in platformo dobijo še en vzvod za API upravljanje ključev, ker ima prisotnost ali odsotnost poverilnic ponudnika zdaj neposreden izid uveljavljanja.

Za operaterje prehodov umetne inteligence širše je posodobitev signal. Kontrole obračunavanja postajajo kontrole politik. Ni več dovolj pokazati, da je zahteva uporabila določen model.Prehodi morajo vse pogosteje beležiti, katera pot poverilnice je bila uporabljena, kdo je lastnik te poverilnice, kateri najemnik ali ključ API je sprožil klic in ali je bil dovoljen nadomestni dostop.

Model Gate uporabniki se soočajo z isto osnovno težavo, ko upravljajo ekipe, ključe API, analitiko uporabe in dostop do partnerjev. Ključ v obsegu stranke ni le žeton za preverjanje pristnosti; lahko vključuje način zaračunavanja, omejitev porabe, račun ponudnika in nabor revizijskih pričakovanj. Če ti pomeni niso uveljavljeni dosledno, se lahko analitične nadzorne plošče in računi oddaljijo od tega, za kar kupci verjamejo, da so kupili.

Praktične posledice

Prva praktična sprememba je obravnava napak. Aplikacije, ki omogočajo samo kontrole BYOK, morajo HTTP 400 iz prehoda obravnavati kot težavo s konfiguracijo ali poverilnicami, ne kot napako modela. Ponovni poskus iste zahteve brez popravljanja poverilnic lahko povzroči samo šum.

Druga sprememba je vkrcanje. Ekipe, ki strankam omogočajo, da prinesejo ključe ponudnika, potrebujejo močnejši korak preverjanja poverilnic, preden se začne produkcijski promet. Najemnik med potekom dela v živo ne bi smel odkriti, da ključ njegovega ponudnika ni bil nikoli pritrjen na prehodno pot.

Tretja sprememba je opazljivost. Dnevniki prehoda in poročila o uporabi bi morali razkriti, ali je zahteva uporabila BYOK, zaračunavanje platforme ali blokirano nadomestno pot. Brez tega polja bodo skupine za podporo morda vedele, da zahteva ni uspela, ne pa tudi, ali je napaka zaščitila mejo zaračunavanja.

Končno bi morale partnerske platforme ponovno pregledati svoje privzete nastavitve. Strogo uveljavljanje BYOK ni vedno prava izbira. Nekateri izdelki se lahko namenoma vrnejo na zaračunavanje prek platforme, da ohranijo kontinuiteto storitve. Drugi morda potrebujejo trdo ločitev zaradi pogodb, zaupanja strank ali zaščite marže. Pomemben premik je, da je odločitev lahko eksplicitna namesto naključna.

Kaj ostaja nejasno

Javna sprememba opisuje mehaniko pravilnika, vendar bodo ekipe še vedno morale preizkusiti, kako se obnaša v svoji mešanici ponudnikov, strukturi poti in modelu dedovanja poverilnic. Prav tako še ni jasno, kako široko bodo okviri aplikacij in orodja za opazovanje tretjih oseb prikazali to razliko v načinu obračunavanja na svojih privzetih nadzornih ploščah.

Širša smer je dovolj jasna. Prehodi z več modeli postajajo ravni finančnega nadzora toliko kot API posredniki. Nastavitev samo BYOK za Cloudflare je ozka funkcija, vendar obravnava način resnične napake: zahtevo, ki tehnično deluje, medtem ko krši predvideni model zaračunavanja.