Usklajevanje nadzorne ravnine za prehode AI API

Prehod AI API lahko poskrbi, da je dostop med izvajanjem videti poenoten, medtem ko nadzorne ravni ponudnika navzgor lebdijo. Ekipe pogosto centralizirajo klice sklepanja, zaračunavanje, upravljanje ključev API in analitiko uporabe na prehodu, nato pa prepustijo projektom OpenAI, delovnim prostorom Anthropic, projektom Google Cloud, ključem Gemini, računom storitev, proračunom in obsegom poročanja ročno konfiguracijo. To ustvari način tihe napake: prehod pravi, da obstaja ena politika najemnika, vendar račun ponudnika uveljavlja ali poroča nekaj drugega.

Praktični vzorec je usklajevanje nadzorne ravnine. Obravnavajte skrbniške objekte zgornjega ponudnika kot inventar. Primerjajte opazovani inventar z želeno politiko najemnika v prehodu. Izdelajte ugotovitve zanašanja, sanacijo poti z odobritvami in rezervirajte samodejno ukrepanje za očitno visoko tvegana stanja.

Ta članek ločuje dejstva, priporočila in napovedi. Dejstva so danes dokumentirana vedenja ponudnikov. Priporočila so izbire arhitekture za operaterja prehoda. Napovedi so verjetno operativni pritiski, ko dozorevajo skladi umetne inteligence več ponudnikov.

Kako izgleda drift po sprejetju prehoda

Prehodi med izvajanjem rešujejo eno plast težave: aplikacije pošiljajo zahteve skupni končni točki, najemniki dobijo ključe prehoda z omejenim obsegom in uporaba se beleži v eni knjigi. Vendar so objekti ponudnika navzgor še vedno pomembni. Odločijo se, kateri projekt ali delovni prostor ima ključ, katera poročila vključujejo porabo, katere stopnje in omejitve virov veljajo ter kateri kontrolniki v sili so na voljo.

Pogosti primeri zamaknjenja vključujejo:

• Najemnik je preslikan v projekt OpenAI v prehodu, vendar ključ izvajalnega časa še vedno pripada privzetemu projektu v skupni rabi.
• Ključ Anthropic API je bil ustvarjen v napačnem delovnem prostoru in ga ni mogoče premakniti v predvideni. ena.
• Ključ Google API je bil ustvarjen zunaj toka konzole in ostaja neomejen, ker omejitve niso bile nikoli izrecno nastavljene.
• Prag porabe ponudnika je nižji od proračuna najemnika prehoda, kar povzroča napake na strani ponudnika, preden jih prehod pričakuje.
• Prag porabe ponudnika je višji od pravilnika o prehodu, zaradi česar je račun ponudnika šibek backstop.
• Poročila o uporabi vsebujejo ničelna ali podedovana polja delovnega prostora, zato finance ne morejo natančno uskladiti stroškov ponudnika z najemniki prehoda.
• Račun storitve preživi odhod zaposlenih, ker ni povezan z modelom lastništva prehoda.

Tveganje ni le varnost. Odmik prekine dodeljevanje, odziv v sili, nadzor nad stroški in revizijo.

Dejstva, ki jih je treba ohraniti pri načrtovanju

Kontrolne ravnine ponudnika niso zamenljive. Usklajevalnik bi moral normalizirati dovolj podatkov, da lahko operaterji delujejo učinkovito, vendar bi moral ohraniti semantiko, specifično za ponudnika.

Projekti OpenAI

Dejstvo: Projekti OpenAI omogočajo organizacijam organizacijo dela, upravljanje dostopa in omejitev, zagotavljanje računov storitev in sledenje uporabi znotraj obsega projekta. Uporabo je mogoče razčleniti po projektih, omejitve porabe pa je mogoče nastaviti za vsak projekt.

Dejstvo: Računi storitve OpenAI projekta so edinstveni za projekt, v katerem so ustvarjeni. Njihov ustvarjen skrivni ključ je prikazan enkrat in če ga izgubite, je treba ustvariti nov ključ.

Dejstvo: ključi OpenAI API podpirajo ravni dovoljenj, kot so vse, omejeno in samo za branje. Dovoljenja za ključ API storitvenega računa so privzeto namenjena dostopu za branje in pisanje do vseh virov API projekta, razen če se spremenijo.

Dejstvo: dokumentacija OpenAI opisuje omejitve mesečne porabe projekta kot mehke pragove v enem članku s pomočjo, medtem ko gradivo za odpravljanje težav dokumentira tudi napake s trdimi omejitvami, kot je project_spend_limit_exceeded. Prehod ne bi smel domnevati, da se vsaka konfigurirana omejitev porabe ponudnika obnaša kot sinhrona trda omejitev v vsaki konfiguraciji računa.

Anthropic Workspaces

Dejstvo: Anthropic Workspaces organizirajo ključe API-ja, timski dostop in stroške. Dodatni delovni prostori lahko vsebujejo člane, storitvene račune, ključe API in omejitve virov.

Dejstvo: ključi API so vezani na delovni prostor, kjer so ustvarjeni, in jih ni mogoče premikati med delovnimi prostori. Anthropic pri vsaki zahtevi oceni uporabne omejitve delovnega prostora in organizacije.

Dejstvo: Privzeti delovni prostor ima posebno vedenje poročanja. Poročila o uporabi in stroških lahko prikažejo ničelni workspace_id, kar je pomembno, ko poskuša prehod preslikati poročila ponudnika nazaj v najemnike.

Dejstvo: API-ji Anthropic Admin in Analytics pokrivajo administracijo organizacije in delovnega prostora, ključe API-ja, poročila o uporabi, poročila o stroških in povezano analitiko, vendar je dostop odvisen od skrbniških ključev in upravičenosti računa ali vloge.

Ključa Google Cloud in Gemini

Dejstvo: Smernice za ključ API za Google Cloud pravijo, da neomejeni ključi API niso varni. Omejitve API-jev omejujejo, katere API-je je mogoče poklicati, omejitve aplikacij pa omejujejo, kje je mogoče uporabiti ključ.Google priporoča, da nastavite oboje, kjer je to primerno.

Dejstvo: dokumentacija Google Cloud pravi, da ključi API-ja, ustvarjeni prek konzole, zahtevajo vsaj eno omejitev API-ja, medtem ko so ključi, ustvarjeni prek gcloud ali REST, neomejeni, razen če so omejitve izrecno navedene.

Dejstvo: dokumentacija Google AI for Developers pravi, da API Gemini prehaja s standardnih ključev na avtorizacijske ključe, neomejeni standardni ključi so zavrnjeni in standardni ključe je treba preseliti na avtorizacijske ključe pred septembrom 2026, da se izognete prekinitvi storitve.

Dejstvo: proračuni Google Cloud Billing z opozorili ne omejijo samodejno porabe. Programska obvestila Pub/Sub lahko avtomatizirajo odzive za nadzor stroškov, vendar je dostava Pub/Sub vsaj enkrat in sporočila lahko prispejo nepravilno.

Referenčna arhitektura

Priporočilo: Zgradite usklajevanje kot storitev nadzorne ravnine poleg prehoda izvajalnega časa, ne znotraj vroče poti zahteve. Prebrati mora skrbniške površine ponudnika, jih primerjati s politiko najemnika prehoda in oddajati dogodke odmika.

Praktična arhitektura ima pet delov:

• Shranjevanje želenega stanja: pravilnik najemnika prehoda: najemnik, lastnik, dovoljeni ponudniki, profili modelov, politika proračuna, politika cen, dovoljeni navzgornji projekti ali delovni prostori, lastništvo ključa in nujni primeri status.
• Inventar opazovanega stanja: predmeti ponudnika, odkriti prek skrbniških API-jev, izvozov zaračunavanja, izvozov konzole ali načrtovanih pregledov.
• Vmesniki ponudnika: OpenAI, Anthropic, Google Cloud in drugi zbiralniki, specifični za ponudnika, ki ohranjajo izvorne identifikatorje in semantiko.
• Mehanizmi za premikanje: deterministične primerjave ki proizvedejo ugotovitve namesto tihega spreminjanja stanja ponudnika.
• Potek dela za sanacijo: vstopnice, odobritve, opozorila o klepetu in ozko omejena avtomatizirana dejanja za visoko tvegano odnašanje.

Prehod ostaja vir resnice o zaračunavanju najemnikov. Poročila o stroških in uporabi ponudnika postanejo vhodni podatki za poravnavo in signali nepravilnosti. Ta razlika je pomembna, ker lahko poročila ponudnika zaostajajo, uporabljajo različne dimenzije ali izpostavijo polja za poročanje, ki se ne preslikajo čisto v najemnike prehoda.

Normalizirajte inventar, ne pomena stran

Priporočilo: uporabite normalizirano tabelo inventarja, vendar vključite polja, ki izvirajo iz ponudnika. Ne pretvarjajte se, da so projekt OpenAI, delovni prostor Anthropic in projekt Google Cloud isti objekt.

Koristni model inventarja vključuje:

• ponudnik: openai, anthropic, google, azure ali drugo ime vmesnika.
• provider_account_id: organizacija, račun za obračunavanje ali račun v oblaku identifikator.
• container_type: projekt, delovni prostor, projekt v oblaku, mapa ali račun.
• container_id: izvorni identifikator projekta ali delovnega prostora ponudnika.
• container_name: človeku berljiva oznaka ponudnika.
• tenant_id: preslikan najemnik prehoda ali nič, ko nepreslikan.
• service_account_id: račun storitve ponudnika ali identiteta delovne obremenitve, kjer je na voljo.
• api_key_id: prstni odtis ključa, ID ključa ali zgoščeni identifikator ključa. Ne shranjujte neobdelanih skrivnosti ponudnika v to tabelo.
• key_scope: projekt, delovni prostor, organizacija, omejitev aplikacije, omejitev API-ja ali enakovreden obseg, specifičen za ponudnika.
• dovoljenja: izvorna raven dovoljenj, vezava vlog, seznam omejenih zmogljivosti ali stanje branja/pisanja.
• model_allowlist: modeli oz. Družine API-jev, ki jih ključ lahko doseže, kjer ponudnik izpostavi ta nadzor.
• rate_policy: opažena omejitev ponudnika in pravilnik prehoda, ki naj bi ga podpiral.
• spend_policy: opazovani prag ali proračun ponudnika in proračunska politika najemnika prehoda.
• reporting_scope: dimenzije, pričakovane v poročilih ponudnika, vključno z znano ničelno ali podedovana polja.
• last_seen_at: časovni žig iz zadnjega skeniranja.
• owner: najemnik prehoda, ekipa, lastnik storitve ali človeški lastnik.
• vir: skrbniški API, izvoz zaračunavanja, izvoz konzole, uvoz konfiguracije ali ročno potrjevanje.

Ta tabela mora biti prijazna do dodajanja. Operaterji potrebujejo zgodovino: kdaj se je ključ prvič pojavil, kdaj se je prenehal pojavljati, kdaj so se njegova dovoljenja spremenila in kateri skener je opazil spremembo.

Izrecno definirajte želeno stanje

Priporočilo: Usklajevanje deluje samo, če je želeno stanje konkretno. Politika, kot je najemnik A, ki lahko uporablja Anthropic, je preveč nejasna.Politika, kot je najemnik A, mora uporabljati delovni prostor ws_123, storitveni račun svc_billing_prod, brez izvajalnih ključev v lasti človeka, hitra podpora za profil modela in prag porabe ponudnika med 80 in 110 odstotki proračuna prehoda, je izvedljiv.

Želeno stanje mora vključevati:

• Katere vsebnike navzgor lahko uporablja posamezni najemnik.
• Ali najemnik uporablja poverilnice v lasti prehoda, poverilnice BYOK najemnika ali oboje.
• Ali morajo biti ključi izvajalnega okolja v lasti storitvenega računa.
• Kateri API-ji in modeli ponudnika so dovoljeni.
• Najvišji in najmanjši sprejemljivi pragi porabe navzgor.
• Pričakovane razsežnosti poročanja ponudnika za poravnavo.
• Zahtevana aplikacija in API omejitve za Googlove ključe.
• Vedenje onemogočitve v sili za vsakega ponudnika in najemnika.

Shranjevanje želenega stanja v tabeli pravilnika z različicami. Vsaka ugotovitev odstopanja se mora sklicevati na različico pravilnika, uporabljeno za primerjavo. To omogoča preglede in povrnitve nazaj, ko spremembe pravilnika ustvarijo veliko novih ugotovitev.

Implementirajte razrede zanašanja, po katerih lahko operaterji ukrepajo

Priporočilo: Oddajte vtipkane ugotovitve zanašanja. Izogibajte se splošnim opozorilom o neujemanju. Operaterji bi morali vedeti, kaj se je pokvarilo, zakaj je pomembno in katero dejanje je dovoljeno.

Uporabni razredi zanašanja vključujejo:

• missing_container: pravilnik najemnika pričakuje ponudnikov projekt ali delovni prostor, ki ne obstaja ali ni bil viden optičnemu bralniku.
• unmapped_container: ponudnikov projekt, delovni prostor ali projekt v oblaku obstaja, vendar nima najemnika. preslikava.
• wrong_container: ključ, ki ga uporablja promet najemnika, pripada drugemu projektu ali delovnemu prostoru, kot dovoljuje pravilnik.
• stale_key: ključ ponudnika ni bil viden v prometu prehoda določeno obdobje, vendar ostaja aktiven navzgor.
• orphaned_owner: ključ ali račun storitve je v lasti uporabnika, ki ni na krovu, ali ni preslikan identiteta.
• excessive_permission: ključ ima širša dovoljenja ponudnika, kot jih zahteva pravilnik o prehodu.
• unrestricted_google_key: Googlov ključ nima zahtevanih omejitev API-ja, omejitev aplikacij ali stanja migracije avtorizacije, združljivega z Gemini.
• limit_below_policy: omejitve ponudnika bodo verjetno blokirale prometa pred pričakovanji pravilnika prehoda.
• limit_above_policy: omejitve ponudnika so preveč permisivne, da bi služile kot varovalka.
• reporting_unreconcilable: poročil o uporabi ali stroških ponudnika ni mogoče čisto preslikati v najemnika, ključ, projekt ali delovni prostor.
• scanner_blind: zahtevani skrbniški API-ji ali vloge so manjkajo, tako da usklajevalnik ne more vložiti zahtevka.

Vsaka ugotovitev mora vključevati resnost, zaupanje, prizadetega najemnika, izvorne identifikatorje ponudnika, čas prvega opazovanja, zadnji čas opazovanja, priporočeno dejanje, dovoljena samodejna dejanja in metapodatke o povrnitvi.

Popravek: Začni na suho, ozko avtomatiziraj

Priporočilo: Privzeto na ugotovitve suhega zagona pred mutacija. Skrbniške poverilnice ponudnika so zmogljive. Slabo preslikavo lahko onemogoči produkcijske delovne obremenitve, izbriše dodeljevanje ali povzroči drag izpad.

Dvostopenjski model deluje dobro:

• Obvesti in potrdi: za nizko tveganje ali dvoumen odmik, kot so manjkajoče oznake lastnika, nepreslikana polja za poročanje ali pragovi porabe, ki so nekoliko zunaj pravilnika.
• Predhodno odobreno samodejno dejanje: za ozki primeri z visokim tveganjem, kot so razkriti ključi, ključi v lasti uporabnikov zunaj krova, neomejeni ključi, ki podpirajo Gemini, ali ključi, vezani na najemnike, ki so že onemogočeni v prehodu.

Avtomatizacija mora biti reverzibilna, kjer je to mogoče. Na primer, onemogočanje ključa prehoda je lažje razveljaviti kot brisanje ključa navzgor. Vrtenje ključa ponudnika navzgor po razponu je morda potrebno, vendar zahteva koordinacijo uvajanja na nižji stopnji. Znižanje proračuna prehoda na nič je takojšnje in ga je mogoče preveriti, medtem ko lahko opozorila o proračunu ponudnika zaostajajo ali se obnašajo asinhrono.

Runbook za zaustavitev v sili

Priporočilo: Napišite knjigo runbook za zaustavitev ponudnika v sili, preden bo potreben.Zajemati mora nadzor prehoda in nadzor ponudnika.

Praktično zaporedje je:

1. Označite prizadete ključe prehoda kot onemogočene, tako da se nove zahteve za čas izvajanja ustavijo na prehodu.
2. Nastavite proračun prehoda najemnika ali omejitev porabe rezervacije na nič.
3. Blokirajte usmerjanje najemnika k prizadetemu ponudniku ali profilu modela.
4. Prekličite, onemogočite ali zasukajte ključi ponudnika navzgor, kjer so podprti.
5. Znižajte pragove na strani ponudnika, če so na voljo in so uporabni za konfiguracijo računa.
6. Zabeležite vsako dejanje z akterjem, časovnim žigom, razlogom, predmetom ponudnika in navodilom za povrnitev.
7. Uskladite uporabo in stroške na strani ponudnika po poročanju zamud pri širjenju.
8. Odprite pregled premikanja po incidentu: kako je predmet postal neupravljano in katero preverjanje pravilnika bi ga moralo prej ujeti?

To zaporedje namerno najprej ustavi promet na prehodu. Kontrole ponudnika so še vedno pomembne, vendar se lahko razlikujejo po hitrosti, razpoložljivosti in semantiki uveljavljanja.

Kompromisi

Samodejno usklajevanje zmanjša odmik, vendar zahteva skrbniške poverilnice. Priporočilo: ločite skrbniške poverilnice od izvajalnih poverilnic, jih shranite v ločeno pot trezorja, omejite privilegije mutacije in nadzirajte vsako branje in pisanje.

En navzgornji projekt ali delovni prostor na najemnika izboljša dodeljevanje in nadzor polmera razstreljevanja. Kompromis je širjenje objektov, omejitve ponudnika, operativni stroški in zapleti za skupni predpomnilnik, omogočeno zmogljivost ali združene prepustne strategije.

Omejitve ponudnika zagotavljajo uporabno varovalko, vendar niso nadomestilo za rezervacijo proračuna na strani prehoda. Omejitve ponudnika so lahko mehke, asinhrone, odvisne od načrta ali različno ovrednotene glede na zahteve in poročila.

Pogosta skeniranja hitreje zaznajo odklon, vendar povečajo uporabo skrbniškega API-ja, pritisk na kvoto in obseg opozoril. Boljši vzorec so posodobitve na podlagi dogodkov, kjer so na voljo, in načrtovana uskladitev za popolnost.

Z normalizacijo so nadzorne plošče uporabne, vendar pretirana normalizacija skrije pomembne razlike. Naj bodo polja izvornega ponudnika vidna v ugotovitvah in poročilih.

Napovedi

Napoved: Operaterji prehodov API-ja AI bodo vedno bolj obravnavali skrbniške objekte ponudnika kot regulirano konfiguracijo, podobno kot IAM v oblaku in konfiguracija računa za obračunavanje. Samo izvajanje proxyja ne bo zadovoljilo finančnih, varnostnih ali platformnih skupin, ko bo poraba in dostop razširjena na veliko najemnikov.

Napoved: ključni modeli se bodo spreminjali. Prehod Gemini s standardnih ključev na avtorizacijske ključe je viden primer. Usklajevalni sistemi, ki shranjujejo izvorno vrsto objekta ponudnika, stanje selitve in nazadnje viden vir, bodo obravnavali te spremembe bolje kot sistemi, ki shranjujejo samo neobdelano skrivnost in ime ponudnika.

Predvidevanje: poročila ponudnika bodo ostala uporabna za poravnavo, vendar neenakomerna za uveljavljanje v realnem času. Prehodi, ki vodijo lastno knjigo zahtev, model rezervacij in dodeljevanje najemnikov, bodo bolj predvidljivi kot prehodi, ki čakajo na izvoze zaračunavanja ponudnika.

Kontrolni seznam za implementacijo

• Ustvarite tabelo pravilnika želenega stanja za preslikave med najemnikom in ponudnikom.
• Ustvarite tabelo opazovanega inventarja z izvornimi identifikatorji ponudnika in zgoščenim ključem. ID-ji.
• Najprej zgradite adapterje ponudnika samo za branje.
• Razvrstite napake optičnega bralnika kot ugotovitve, namesto da jih skrijete.
• Oddajanje vnesenih dogodkov z resnostjo in zaupanjem.
• Ugotovitve usmerjajte v prijave, opozorila ali čakalne vrste za odobritev.
• Omogočite samodejno ukrepanje samo za ozko, vnaprej odobreno visoko tveganje. razrede.
• Skrbniške poverilnice hranite ločene od poverilnic za čas izvajanja.
• Pridružite zapise glavne knjige prehoda poročilom ponudnika za poravnavo in odkrivanje nepravilnosti.
• Preizkusite zaustavitev v sili v neproizvodnem najemniku, preden se zanesete nanj.

Ukrepljiv sklep

Ne ustavite se pri usmerjanju sklepnih klicev prek skupne končne točke. Če nadzorne ravnine navzgor odtavajo, lahko prehod še vedno izgubi atribucijo, zgreši zastarele ključe, napačno razbere vedenje porabe ponudnika ali odpove v nujnem primeru.

Najmočnejši vzorec je preprost: zapišite želeno politiko najemnika v prehodu, skenirajte opazovane objekte ponudnika, ohranite pomen, specifičen za ponudnika, oddajte vtipkane ugotovitve odmika in popravite z nadzorovanim potekom dela. Zaženi samo za branje. Dokažite inventar.Nato avtomatizirajte samo dejanja, katerih tveganje je nižje od odmika, ki ga popravijo.

Sorodno branje

• ločite čas izvajanja, skrbništvo, obračunavanje in BYOK poverilnice
• glavna knjiga obračunavanja na strani prehoda in rezervacija proračuna
• pravila o lastništvu računov za izven krova in storitev