Cloudflare dodał kontrolę do AI Gateway, która pozwala operatorom wymagać poświadczeń dostawcy w przypadku żądań modeli innych firm. Zmiana jest niewielka pod względem interfejsu, ale rozwiązuje praktyczny problem zarządzania w przypadku zespołów kierujących ruch AI przez bramę: co powinno się stać, gdy klient, projekt lub najemca nie dostarczył prawidłowego klucza dostawcy?
Przed tą aktualizacją Cloudflare AI Gateway mogła używać swojej konfiguracji ujednoliconego rozliczeń jako ścieżki awaryjnej dla obsługiwanych dostawców zewnętrznych. Może to być wygodne, gdy w przeciwnym razie żądanie nie powiedzie się, ale może również zatrzeć granice alokacji kosztów i zgodności. Nowe ustawienie BYOK-only pozwala właścicielom bram zapobiegać takim awariom i wymagać, aby zamiast tego żądania korzystały z jawnie dostarczonych poświadczeń umożliwiających przyniesienie własnego klucza.
Cloudflare twierdzi, że to ustawienie można włączyć w panelu kontrolnym lub za pośrednictwem interfejsu API za pomocą parametru byok_only=true. Dodano także nagłówek żądania cf-aig-no-wholesale na wypadek, gdy zespoły chcą zablokować wykorzystanie danych uwierzytelniających zarządzanych hurtowo lub zarządzanych przez Cloudflare w przypadku indywidualnych połączeń.
Co się zmieniło
Dziennik zmian AI Gateway z 14 września wprowadza wymóg poświadczeń w przypadku żądań dostawców zewnętrznych. Po włączeniu brama nie będzie po cichu korzystać z danych uwierzytelniających Unified Billing zarządzanych przez Cloudflare, jeśli osoba dzwoniąca nie podała akceptowalnych danych uwierzytelniających dostawcy.
To rozróżnienie ma znaczenie, ponieważ bramy AI coraz częściej znajdują się pomiędzy wieloma aplikacjami wewnętrznymi, klientami zewnętrznymi i dostawcami wielu modeli. Brakujący klucz to nie tylko stan awarii technicznej. Może decydować, który podmiot prawny jest rozliczany, który limit dostawcy konta jest wykorzystywany i czy wykorzystanie pojawia się we właściwym centrum kosztów.
Nowa kontrola zapewnia zespołom ds. platform bardziej rygorystyczny tryb działania. Zamiast traktować brakujące dane uwierzytelniające klienta jako niedogodność związaną z routingiem, brama może potraktować je jako naruszenie zasad. Jest to szczególnie istotne w przypadku konfiguracji sprzedawców, wdrożeń kluczy będących własnością klientów i środowisk korporacyjnych, w których relacja z dostawcą musi pozostać bezpośrednio powiązana z jednostką biznesową lub najemcą.
Dlaczego jest to ważne dla operatorów bram AI
Projektowanie bram AI często skupiało się na routingu, opóźnieniach, buforowaniu, ponownych próbach i abstrakcji modelu. Zachowanie związane z rozliczeniami zasługuje na taką samą uwagę. Jeśli brama automatycznie zmienia tryb poświadczeń, gdy jedna ścieżka jest niedostępna, raportowanie na dalszym etapie może wprowadzać w błąd. Żądanie może wyglądać jak zwykły ruch aplikacji, podczas gdy faktura ląduje gdzie indziej.
W przypadku firm korzystających z warstwy centralnej kontroli kosztów interfejsu AI API stwarza to ryzyko operacyjne. Zespoły finansowe mogą utracić czyste dane dotyczące obciążeń zwrotnych. Zespoły ds. bezpieczeństwa mogą nie wiedzieć, które dane uwierzytelniające zostały faktycznie użyte. Zespoły ds. produktu mogą mieć trudności z wyjaśnieniem, dlaczego korzystanie z usługi przez jednego najemcę było rozliczane za pośrednictwem konta platformy, a nie własnego konta dostawcy tego najemcy.
Tryb „tylko BYOK” pomaga również w przypadku zobowiązań klientów. Niektórzy kupujący wymagają, aby połączenia modelowe regulowały ich własne umowy z dostawcami, warunki przetwarzania danych lub ustawienia regionalne. Jeśli brama może korzystać z zarządzanych danych uwierzytelniających, wyegzekwowanie tego zobowiązania staje się trudniejsze, chyba że funkcja zastępcza jest wyłączona zgodnie z zasadami.
Nagłówek żądania zapewnia bardziej szczegółową opcję. Platforma może udostępnić szersze zachowanie ujednoliconego rozliczeń w przypadku niektórych obciążeń, jednocześnie uniemożliwiając to w przypadku żądań, które mają bardziej rygorystyczne wymagania dotyczące zgodności, sprzedawcy lub atrybucji. Daje to programistom ścieżkę migracji bez konieczności jednoczesnego przełączania każdej aplikacji w najbardziej rygorystyczny tryb.
Kogo to dotyczy
Bezpośrednim odbiorcą jest dowolny zespół używający Cloudflare AI Gateway do przesyłania żądań proxy do zewnętrznych dostawców sztucznej inteligencji. Zmiana jest najbardziej istotna, gdy wiele zespołów, dzierżawców lub klientów korzysta z bramy i gdy oczekuje się, że poświadczenia dostawcy będą znajdować się poza kontem platformy centralnej.
Zespoły zajmujące się platformami korporacyjnej sztucznej inteligencji powinny sprawdzić, czy ich zachowanie bramy jest zgodne z zasadami wewnętrznymi. Jeśli projekt ma korzystać z własnego konta OpenAI, Anthropic, Google, Mistral lub innego dostawcy, brama powinna sprawić, że ta zależność będzie widoczna i możliwa do wyegzekwowania. Rozwiązanie awaryjne, które pomaga w powodzeniu wersji demonstracyjnej, może stać się problemem w środowisku produkcyjnym, jeśli ukrywa nieprawidłową konfigurację poświadczeń.
Sprzedawcy i platformy partnerskie mają ostrzejszą wersję tego samego problemu. Jeśli klienci przynoszą własne klucze dostawcy, operatorzy platform muszą mieć pewność, że ruch nie zostanie przypadkowo zamieniony na korzystanie z usług rozliczanych przez platformę. W przeciwnym razie może to mieć wpływ na marże, faktury, zapisy audytów i zaufanie klientów.
Dotyczy to również programistów, choć głównie z powodu wyraźniejszych trybów awarii. W przypadku wymuszania wyłącznie metodą BYOK żądanie pozbawione odpowiednich poświadczeń powinno zakończyć się niepowodzeniem, a nie zostać przesłane przez alternatywną ścieżkę rozliczeniową.Może to wymagać lepszych kontroli wdrożenia, wyraźniejszej obsługi błędów i testów wdrożeniowych weryfikujących klucze dostawcy przed uruchomieniem ruchu.
Praktyczne konsekwencje
Pierwszym praktycznym krokiem jest inwentaryzacja zasad. Zespoły powinny zdecydować, które obciążenia mogą korzystać z ujednoliconego rozliczeń zarządzanego przez Cloudflare, a które muszą korzystać z poświadczeń dostawcy będących własnością klienta lub projektu. Decyzja ta powinna być wyraźna, a nie pozostawiona domyślnemu zachowaniu bramy.
Drugim krokiem jest obserwowalność. Dzienniki i analizy użycia powinny rejestrować, który tryb poświadczeń był używany, czy żądanie zostało zablokowane, ponieważ włączono tryb tylko BYOK, oraz który dzierżawca lub projekt dostarczył klucz. Bez tej widoczności ściślejsza kontrola może zmniejszyć niejednoznaczność rozliczeń, ale nadal pozostawia operatorom słabe dane dotyczące rozwiązywania problemów.
Trzeci krok to przepływ pracy programisty. Aplikacje zależne od AI Gateway powinny zakończyć się wcześniej niepowodzeniem w przypadku braku poświadczeń. Sprawdzenie przy uruchamianiu, sprawdzenie wdrożenia lub ostrzeżenie w konsoli administracyjnej jest lepsze niż wykrycie problemu po odrzuceniu żądania produkcyjnego.
Pozostała niepewność dotyczy w mniejszym stopniu samej funkcji, a bardziej wzorców wdrażania. Cloudflare udokumentowało nową kontrolę, ale każdy operator musi jeszcze zdecydować, gdzie ją zastosować. Niektóre zespoły będą preferować odporność rozliczeń rezerwowych na potrzeby eksperymentów wewnętrznych. Inne ustawią opcję BYOK-only jako domyślną dla ruchu dzierżawy produkcyjnej. Ważną zmianą jest to, że jest to teraz wybór zarządzania, a nie ukryte zachowanie ukryte w warstwie routingu.