Cloudflare a adăugat un control la AI Gateway care le permite operatorilor să solicite acreditări ale furnizorului la solicitările de modele de la terți. Schimbarea este mică în termeni de interfață, dar abordează o problemă practică de guvernare pentru echipele care direcționează traficul AI printr-un gateway: ce ar trebui să se întâmple atunci când un client, un proiect sau un chiriaș nu a furnizat o cheie de furnizor validă?
Înainte de această actualizare, Cloudflare AI Gateway ar putea folosi configurația de facturare unificată ca o cale de rezervă pentru furnizorii terți acceptați. Acest lucru poate fi convenabil atunci când o solicitare ar eșua altfel, dar poate, de asemenea, estompa atribuirea costurilor și limitele de conformitate. Noua setare numai BYOK le permite proprietarilor de gateway să prevină această alternativă și să solicite ca cererile să utilizeze în schimb acreditările de aducere-cheie furnizate în mod explicit.
Cloudflare spune că setarea poate fi activată în tabloul de bord sau prin API cu byok_only=true. De asemenea, a adăugat un antet per solicitare, cf-aig-no-wholesale, pentru cazurile în care echipele doresc să blocheze utilizarea acreditărilor angro sau gestionate de Cloudflare la apelurile individuale.
Ce s-a schimbat
Jurnalul de modificări AI Gateway din 14 septembrie introduce o cerință de acreditări pentru solicitările furnizorilor terți. Când este activat, gateway-ul nu va reveni în mod silențios la acreditările de facturare unificată gestionate de Cloudflare dacă apelantul nu a furnizat acreditări acceptabile ale furnizorului.
Această distincție contează, deoarece gateway-urile AI se află din ce în ce mai mult între multe aplicații interne, clienți externi și mai mulți furnizori de modele. O cheie lipsă nu este doar un mod de defecțiune tehnică. Acesta poate decide ce entitate juridică este facturată, cota de furnizor a contului este consumată și dacă utilizarea apare în centrul de cost potrivit.
Noul control oferă echipelor platformei un mod de operare mai strict. În loc să trateze acreditările clienților lipsă ca pe un inconvenient de rutare, gateway-ul le poate trata ca pe o încălcare a politicii. Acest lucru este relevant în special pentru setările de reseller, implementările de chei deținute de clienți și mediile de întreprindere în care relația cu furnizorul trebuie să rămână direct legată de o unitate de afaceri sau de chiriaș.
De ce este important pentru operatorii de gateway AI
Designul de gateway AI s-a concentrat adesea pe rutare, latență, cache, reîncercări și abstracție a modelului. Comportamentul de facturare merită aceeași atenție. Dacă un gateway schimbă automat modul de autentificare atunci când o cale nu este disponibilă, raportarea în aval poate deveni înșelătoare. O solicitare poate arăta ca un trafic de aplicații obișnuit, în timp ce factura ajunge în altă parte.
Pentru companiile care operează un nivel de control central al costurilor API AI, care creează risc operațional. Echipele financiare pot pierde date curate de rambursare. Este posibil ca echipele de securitate să nu știe care acreditări a fost folosită de fapt. Echipele de produse ar putea avea dificultăți să explice de ce utilizarea unui chiriaș a fost facturată printr-un cont de platformă în loc de contul propriu de furnizor al locatarului respectiv.
Modul doar BYOK ajută, de asemenea, la angajamentele clienților. Unii cumpărători solicită ca propriile lor contracte cu furnizorii, termenii de prelucrare a datelor sau setările regionale să guverneze apelurile model. Dacă un gateway poate reveni la o acreditări de facturare gestionată, acel angajament devine mai greu de aplicat, cu excepția cazului în care alternativa este dezactivată de politică.
Antetul per solicitare adaugă o opțiune mai granulară. O platformă poate menține un comportament mai larg de facturare unificată disponibil pentru anumite sarcini de lucru, împiedicându-l în același timp pentru solicitări care implică cerințe mai stricte de conformitate, revânzător sau atribuire. Acest lucru oferă dezvoltatorilor o cale de migrare fără a forța fiecare aplicație în modul cel mai strict simultan.
Cine este afectat
Publicul imediat este orice echipă care utilizează Cloudflare AI Gateway pentru a trimite cererile către furnizorii terți de AI. Schimbarea este cea mai relevantă acolo unde mai multe echipe, chiriași sau clienți partajează un gateway și unde se așteaptă ca acreditările furnizorului să fie deținute în afara contului platformei centrale.
Echipele platformei Enterprise AI ar trebui să verifice dacă comportamentul lor de gateway se potrivește cu politica internă. Dacă un proiect ar trebui să folosească propriul său cont OpenAI, Anthropic, Google, Mistral sau alt furnizor, gateway-ul ar trebui să facă acea dependență vizibilă și aplicabilă. O alternativă care ajută o demonstrație să reușească poate deveni o problemă în producție dacă ascunde configurarea acreditărilor rupte.
Revânzătorii și platformele partenere au o versiune mai clară a aceleiași probleme. Dacă clienții își aduc propriile chei de furnizor, operatorii platformei au nevoie de încredere că traficul nu este transformat accidental în utilizare facturată pe platformă. În caz contrar, marjele, facturile, înregistrările de audit și încrederea clienților pot fi toate afectate.
Dezvoltatorii sunt și ei afectați, deși mai ales prin moduri de eșec mai clare. Cu aplicarea doar BYOK, o solicitare care nu are acreditările adecvate ar trebui să eșueze, mai degrabă decât să fie direcționată printr-o cale alternativă de facturare.Acest lucru poate necesita verificări mai bune de integrare, o gestionare mai clară a erorilor și teste de implementare care verifică cheile furnizorului înainte de a începe traficul.
Consecințe practice
Primul pas practic este inventarul politicilor. Echipele ar trebui să decidă care încărcături de lucru au permisiunea de a utiliza facturarea unificată gestionată de Cloudflare și care trebuie să utilizeze acreditările deținute de client sau de furnizor deținut de proiect. Această decizie ar trebui să fie explicită, nu lăsată la comportamentul implicit al gateway-ului.
Al doilea pas este observabilitatea. Jurnalele și analiza utilizării ar trebui să înregistreze ce mod de autentificare a fost utilizat, dacă o solicitare a fost blocată deoarece a fost activată numai BYOK și care chiriaș sau proiect a furnizat cheia. Fără această vizibilitate, un control mai strict poate reduce ambiguitatea de facturare, dar totuși poate lăsa operatorii cu date slabe de depanare.
Al treilea pas este fluxul de lucru pentru dezvoltatori. Aplicațiile care depind de AI Gateway ar trebui să eșueze mai devreme atunci când acreditările lipsesc. O verificare a pornirii, validarea implementării sau avertismentul din consola de administrare este mai bună decât descoperirea problemei după ce o solicitare de producție este respinsă.
Incertitudinea rămasă este mai puțin legată de caracteristică în sine și mai mult despre modelele de adoptare. Cloudflare a documentat noul control, dar fiecare operator trebuie încă să decidă unde să-l aplice. Unele echipe vor prefera rezistența facturării alternative pentru experimentele interne. Alții vor face doar BYOK-ul implicit pentru traficul chiriașilor de producție. Schimbarea importantă este că aceasta este acum o alegere de guvernare, mai degrabă decât un comportament implicit ascuns în stratul de rutare.