Cloudflare ir pievienojis AI Gateway vadīklu, kas ļauj operatoriem pieprasīt pakalpojumu sniedzēja akreditācijas datus trešās puses modeļu pieprasījumos. Izmaiņas saskarnes ziņā ir nelielas, taču tās risina praktisku pārvaldības problēmu komandām, kas maršrutē AI trafiku caur vārteju: kam vajadzētu notikt, ja klients, projekts vai nomnieks nav piegādājis derīgu nodrošinātāja atslēgu?
Pirms šī atjaunināšanas Cloudflare AI Gateway varēja izmantot savu vienoto norēķinu iestatījumu kā rezerves ceļu atbalstītajiem trešo pušu pakalpojumu sniedzējiem. Tas var būt ērti, ja pieprasījums citādi neizdotos, taču tas var arī izjaukt izmaksu attiecinājuma un atbilstības robežas. Jaunais tikai BYOK iestatījums ļauj vārtejas īpašniekiem novērst šo atkāpšanos un pieprasīt, lai pieprasījumos tiktu izmantoti tieši nodrošināti akreditācijas dati, lai to vietā izmantotu savu atslēgu.
Cloudflare saka, ka iestatījumu var iespējot informācijas panelī vai izmantojot API, izmantojot byok_only=true. Tā arī pievienoja pieprasījuma galveni cf-aig-no-wholesale gadījumiem, kad komandas vēlas bloķēt vairumtirdzniecību vai Cloudflare pārvaldītu akreditācijas datu izmantošanu atsevišķiem zvaniem.
Kas mainījās
14. septembra AI Gateway izmaiņu žurnālā ir ieviesta trešās daļas akreditācijas datu nodrošinātāja prasība. Ja tas ir iespējots, vārteja klusi neatgriezīsies uz Cloudflare pārvaldītajiem vienotā norēķinu akreditācijas datiem, ja zvanītājs nav norādījis pieņemamus pakalpojumu sniedzēja akreditācijas datus.
Šai atšķirībai ir nozīme, jo AI vārtejas arvien vairāk atrodas starp daudzām iekšējām lietojumprogrammām, ārējiem klientiem un vairākiem modeļu nodrošinātājiem. Trūkst atslēga nav tikai tehniskas kļūmes režīms. Tā var izlemt, kurai juridiskajai personai tiek iekasēts rēķins, kura konta nodrošinātāja kvota tiek patērēta un vai lietojums tiek parādīts pareizajā izmaksu centrā.
Jaunā vadīkla platformu komandām nodrošina stingrāku darbības režīmu. Tā vietā, lai trūkstošos klienta akreditācijas datus uzskatītu par maršrutēšanas neērtībām, vārteja tos var uzskatīt par politikas pārkāpumu. Tas jo īpaši attiecas uz tālākpārdevēju iestatījumiem, klientu īpašumā esošo atslēgu izvietošanu un uzņēmuma vidēm, kur pakalpojumu sniedzēja attiecībām ir jāpaliek tieši saistītai ar uzņēmuma vienību vai nomnieku.
Kāpēc tas ir svarīgi AI vārtejas operatoriem
AI vārtejas dizains bieži ir vērsts uz maršrutēšanu, latentumu, kešatmiņu, abstrakciju un modeli. Norēķinu uzvedība ir pelnījusi tādu pašu uzmanību. Ja vārteja automātiski maina akreditācijas datu režīmu, kad viens ceļš nav pieejams, pakārtotā ziņošana var kļūt maldinoša. Pieprasījums var izskatīties kā parasta lietojumprogrammas datplūsma, kamēr rēķins tiek nosūtīts kaut kur citur.
Uzņēmumiem, kuri izmanto centrālo AI API izmaksu kontroles slāni, kas rada darbības risku. Finanšu komandas var zaudēt tīrus atmaksas datus. Drošības komandas var nezināt, kuri akreditācijas dati faktiski tika izmantoti. Produktu komandām var rasties grūtības izskaidrot, kāpēc viena nomnieka lietojums tika iekasēts, izmantojot platformas kontu, nevis paša nomnieka pakalpojumu sniedzēja kontu.
Tikai BYOK režīms palīdz arī izpildīt klientu saistības. Daži pircēji pieprasa, lai modeļu zvanus regulētu viņu pakalpojumu sniedzēja līgumi, datu apstrādes noteikumi vai reģionālie iestatījumi. Ja vārteja var atgriezties pie pārvaldītiem norēķinu akreditācijas datiem, šīs saistības kļūst grūtāk izpildīt, ja vien politika nav atspējota atkāpšanās iespēja.
Pieprasījuma galvenē tiek pievienota detalizētāka opcija. Platforma var nodrošināt plašāku vienoto norēķinu darbību pieejamu dažām darba slodzēm, vienlaikus novēršot to pieprasījumiem, kuriem ir stingrākas atbilstības, tālākpārdevēja vai attiecinājuma prasības. Tas sniedz izstrādātājiem migrācijas ceļu, nepiespiežot katru lietojumprogrammu uzreiz izmantot stingrāko režīmu.
Kas tiek ietekmēts
Tiešā mērķauditorija ir jebkura komanda, kas izmanto Cloudflare AI Gateway, lai nosūtītu starpniekservera pieprasījumus trešo pušu AI pakalpojumu sniedzējiem. Izmaiņas ir visatbilstošākās, ja vairākas komandas, nomnieki vai klienti koplieto vārteju un kur paredzams, ka pakalpojumu sniedzēja akreditācijas dati pieder ārpus centrālās platformas konta.
Uzņēmuma AI platformas komandām ir jāpārskata, vai vārtejas darbība atbilst iekšējai politikai. Ja projektā ir paredzēts izmantot savu OpenAI, Anthropic, Google, Mistral vai cita pakalpojumu sniedzēja kontu, vārtejai šī atkarība jāpadara redzama un izpildāma. Atkāpšanās, kas palīdz demonstrācijai gūt panākumus, var kļūt par problēmu ražošanā, ja tā slēpj bojātu akreditācijas datu iestatīšanu.
Tālākpārdevējiem un partneru platformām ir precīzāka vienas un tās pašas problēmas versija. Ja klienti atnes savas nodrošinātāja atslēgas, platformas operatoriem ir nepieciešama pārliecība, ka trafika nejauši netiek pārvērsta platformas apmaksātā lietošanā. Pretējā gadījumā var tikt ietekmētas peļņas normas, rēķini, audita ieraksti un klientu uzticēšanās.
Tiek ietekmēti arī izstrādātāji, lai gan galvenokārt ar skaidrākiem kļūdu režīmiem. Izmantojot tikai BYOK izpildi, pieprasījumam, kuram nav atbilstošu akreditācijas datu, vajadzētu neizdoties, nevis novirzīt alternatīvu norēķinu ceļu.Tam var būt nepieciešamas labākas iekļaušanas pārbaudes, skaidrāka kļūdu apstrāde un izvietošanas testi, kas pārbauda nodrošinātāja atslēgas pirms datplūsmas sākšanas.
Praktiskās sekas
Pirmais praktiskais solis ir politikas inventarizācija. Komandām jāizlemj, kurām darba slodzēm ir atļauts izmantot Cloudflare pārvaldītos vienotos norēķinus un kurām jāizmanto klienta vai projekta nodrošinātāja akreditācijas dati. Šim lēmumam ir jābūt skaidram, nevis pēc noklusējuma vārtejas darbības.
Otrais solis ir novērojamība. Žurnāliem un lietojuma analīzē ir jāreģistrē, kurš akreditācijas datu režīms tika izmantots, vai pieprasījums tika bloķēts, jo bija iespējots tikai BYOK, un kurš nomnieks vai projekts piegādāja atslēgu. Bez šīs redzamības stingrāka kontrole var samazināt norēķinu neskaidrības, taču operatoriem joprojām ir slikti problēmu novēršanas dati.
Trešais solis ir izstrādātāja darbplūsma. Lietojumprogrammām, kas ir atkarīgas no AI vārtejas, vajadzētu agri nedarboties, ja trūkst akreditācijas datu. Startēšanas pārbaude, izvietošanas validācija vai administratora konsoles brīdinājums ir labāks par problēmas atklāšanu pēc ražošanas pieprasījuma noraidīšanas.
Atlikušā nenoteiktība ir mazāka par pašu līdzekli un vairāk par pieņemšanas modeļiem. Cloudflare ir dokumentējis jauno kontroli, taču katram operatoram vēl ir jāizlemj, kur to lietot. Dažas komandas iekšējiem eksperimentiem dos priekšroku rezerves norēķinu elastīgumam. Citi padarīs tikai BYOK par noklusējumu produkcijas nomnieku datplūsmai. Svarīgas izmaiņas ir tādas, ka tagad tā ir pārvaldības izvēle, nevis netieša rīcība, kas paslēpta maršrutēšanas slānī.