Cloudflare přidal do AI Gateway ovládací prvek, který operátorům umožňuje vyžadovat přihlašovací údaje poskytovatele u požadavků na modely třetích stran. Změna je z hlediska rozhraní malá, ale řeší praktický problém se správou pro týmy směrující provoz AI přes bránu: co by se mělo stát, když zákazník, projekt nebo tenant nedodal platný klíč poskytovatele?
Před touto aktualizací mohl Cloudflare AI Gateway používat nastavení Unified Billing jako záložní cestu pro podporované poskytovatele třetích stran. To může být výhodné, když by požadavek jinak selhal, ale také to může rozmazat hranice připisování nákladů a dodržování předpisů. Nové nastavení BYOK-only umožňuje vlastníkům bran zabránit této nouzové situaci a vyžadovat, aby požadavky místo toho používaly explicitně zadané přihlašovací údaje přinesené vlastním klíčem.
Cloudflare říká, že toto nastavení lze povolit na řídicím panelu nebo prostřednictvím rozhraní API pomocí byok_only=true. Přidala také hlavičku pro každý požadavek, cf-aig-no-wholesale, pro případy, kdy týmy chtějí blokovat velkoobchodní nebo cloudflare spravované používání pověření u jednotlivých hovorů.
Co se změnilo
Změnový protokol AI Gateway ze 14. září zavádí požadavek na pověření pro požadavky poskytovatelů třetích stran. Když je tato povolena, brána se tiše nevrátí k přihlašovacím údajům sjednocené fakturace spravovaným Cloudflare, pokud volající neposkytne přijatelné přihlašovací údaje poskytovatele.
Na tomto rozdílu záleží, protože brány umělé inteligence se stále více nacházejí mezi mnoha interními aplikacemi, externími zákazníky a několika modelovými poskytovateli. Chybějící klíč není jen režim technické poruchy. Může rozhodnout, které právnické osobě se bude fakturovat, u kterého účtu bude spotřebována kvóta poskytovatele a zda se využití objeví ve správném nákladovém středisku.
Nové ovládání poskytuje týmům platformy přísnější provozní režim. Místo toho, aby považovala chybějící přihlašovací údaje zákazníka za nepříjemnost při směrování, může je brána považovat za porušení zásad. To je zvláště důležité pro nastavení prodejce, nasazení klíčů vlastněných zákazníkem a podniková prostředí, kde vztah poskytovatele musí zůstat přímo svázán s obchodní jednotkou nebo tenantem.
Proč je to důležité pro operátory bran AI
Návrh brány AI se často soustředil na směrování, latenci, ukládání do mezipaměti, opakování a abstrakci modelu. Stejnou pozornost si zaslouží fakturační chování. Pokud brána automaticky změní režim pověření, když jedna cesta není k dispozici, může být následné hlášení zavádějící. Požadavek může vypadat jako běžný provoz aplikace, zatímco faktura dorazí někde jinde.
Pro firmy provozující vrstvu centrální řízení nákladů AI API vytváří provozní riziko. Finanční týmy mohou ztratit čistá data zpětného zúčtování. Bezpečnostní týmy nemusí vědět, které přihlašovací údaje byly skutečně použity. Produktové týmy mohou mít potíže s vysvětlením, proč bylo použití jednoho tenanta účtováno prostřednictvím účtu platformy namísto účtu vlastního poskytovatele tohoto tenanta.
Režim pouze BYOK také pomáhá se závazky zákazníků. Někteří kupující požadují, aby se modelová volání řídily smlouvami s jejich vlastním poskytovatelem, podmínkami zpracování dat nebo regionálním nastavením. Pokud se brána může vrátit k pověření pro spravovanou fakturaci, bude tento závazek obtížnější vynutit, pokud není záložní opatření zakázáno zásadami.
Záhlaví pro každý požadavek přidává podrobnější možnost. Platforma může u některých úloh ponechat k dispozici širší chování sjednocené fakturace a zároveň tomu zabránit u požadavků, které mají přísnější požadavky na shodu, prodejce nebo atribuci. To vývojářům poskytuje cestu migrace, aniž by každou aplikaci nutili do nejpřísnějšího režimu najednou.
Koho se to týká
Bezprostředním publikem je jakýkoli tým využívající Cloudflare AI Gateway k proxy žádostem poskytovatelům AI třetích stran. Tato změna je nejrelevantnější tam, kde několik týmů, nájemců nebo zákazníků sdílí bránu a kde se očekává, že pověření poskytovatele bude vlastnit mimo účet centrální platformy.
Týmy podnikové platformy AI by měly zkontrolovat, zda jejich chování brány odpovídá interním zásadám. Pokud má projekt používat svůj vlastní účet OpenAI, Anthropic, Google, Mistral nebo jiného poskytovatele, brána by měla tuto závislost zviditelnit a vynutit. Záložní řešení, které pomáhá demu uspět, se může stát problémem v produkci, pokud skryje nefunkční nastavení pověření.
Resellery a partnerské platformy mají ostřejší verzi stejného problému. Pokud si zákazníci přinesou své vlastní klíče poskytovatele, operátoři platformy potřebují jistotu, že provoz není náhodně převeden na použití účtované platformou. V opačném případě mohou být ovlivněny marže, faktury, auditní záznamy a důvěra zákazníků.
Týká se to i vývojářů, i když většinou prostřednictvím jasnějších režimů selhání. Při vynucení pouze BYOK by měl požadavek, který postrádá správná pověření, selhat, místo aby byl směrován přes alternativní fakturační cestu.To může vyžadovat lepší vstupní kontroly, jasnější zpracování chyb a testy nasazení, které ověřují klíče poskytovatele před spuštěním provozu.
Praktické důsledky
Prvním praktickým krokem je inventarizace zásad. Týmy by se měly rozhodnout, které úlohy mohou používat sjednocenou fakturaci spravovanou Cloudflare a které musí používat přihlašovací údaje poskytovatele vlastněné zákazníkem nebo projektem. Toto rozhodnutí by mělo být explicitní a nemělo by být ponecháno na chování výchozí brány.
Druhým krokem je pozorovatelnost. Protokoly a analýzy využití by měly zaznamenávat, který režim pověření byl použit, zda byl požadavek zablokován, protože bylo povoleno pouze BYOK, a který tenant nebo projekt dodal klíč. Bez této viditelnosti může přísnější kontrola snížit nejednoznačnost účtování, ale operátorům stále ponechává špatná data pro řešení problémů.
Třetím krokem je pracovní postup vývojářů. Aplikace, které jsou závislé na AI Gateway, by měly selhat brzy, když chybí přihlašovací údaje. Kontrola spouštění, ověření nasazení nebo varování administrátorské konzole je lepší než zjišťování problému po zamítnutí produkčního požadavku.
Zbývající nejistota se týká méně samotné funkce, ale spíše vzorců přijetí. Cloudflare zdokumentoval nové ovládání, ale každý provozovatel se ještě musí rozhodnout, kde jej uplatní. Některé týmy budou u interních experimentů preferovat odolnost záložní fakturace. Jiné nastaví pouze BYOK jako výchozí pro provoz produkčního tenanta. Důležitou změnou je, že se nyní jedná spíše o volbu řízení než o implicitní chování skryté ve vrstvě směrování.