Umelá inteligencia v reálnom čase bezpečná pre prehliadač prostredníctvom brány API: efemérne tokeny, zásady nájomníkov a ovládacie prvky hlasovej relácie

Prehliadač a mobilné aplikácie by nemali dostávať dlhodobé kľúče API poskytovateľa. V prípade hlasovej AI v reálnom čase však odosielanie každého zvukového paketu cez bránu môže zvýšiť latenciu, prevádzkové náklady a režimy zlyhania. Lepším vzorom je ponechať bránu v riadiacej rovine: autentifikovať používateľa, presadzovať politiku nájomníka, rezervovať rozpočet, raziť úzke krátkodobé poverenia v reálnom čase a nechať médiá citlivé na latenciu používať prenos poskytovateľa v reálnom čase tam, kde je to vhodné.

Tento článok popisuje vzor implementácie pre tímy vytvárajúce hlasových agentov, asistentov hovorov, mobilných lektorov, podporných kopilotov alebo hlasové rozhrania v aplikácii prostredníctvom brány AI API. Cieľom je bezpečnosť prehliadača bez straty správy nájomníka.

Problém: priame pripojenia v reálnom čase obchádzajú vaše ovládacie prvky

Obyčajný proxy server na strane servera je atraktívny, pretože centralizuje kľúče a pozorovateľnosť. Pre štandardné textové požiadavky je to často ten správny model. Zvuk v reálnom čase je iný. Hlasová relácia môže zahŕňať nepretržitý vstup mikrofónu, obojsmerný zvukový výstup, prerušenia, volania nástrojov a prísne očakávania latencie. Proxy všetkých médií cez vašu bránu môže zmeniť bránu na mediálny prenos s vysokou šírkou pásma namiesto služby politiky a fakturácie.

Priame pripojenia medzi prehliadačom a poskytovateľom riešia latenciu, ale vytvárajú iný problém:

• Prehliadač nemôže bezpečne držať štandardný kľúč API poskytovateľa.
• Ak sa aplikácia pripája priamo, kontroly rozpočtu nájomníkov môžu byť preskočené.
• Obmedzenia modelu, regiónu, hlasu, modality a nástrojov sa stávajú prísľubmi na strane klienta.
• Pripisovanie používania bude neúplné alebo oneskorené.
• Bezpečnostné tímy stratia kontrolovateľný bod rozhodnutia pred začiatkom relácie.

Praktický dizajn nie je „proxy každý bajt“. Je to „sprostredkovateľ každej relácie.“

Fakty, odporúčania a predpovede

Fakty: Poskytovatelia umelej inteligencie v reálnom čase čoraz viac podporujú prenosy s nízkou latenciou, ako sú WebRTC, WebSocket a SIP. Verejná dokumentácia pre Realtime API OpenAI popisuje rozhrania v reálnom čase s nízkou latenciou, vrátane WebRTC. Usmernenie k Azure OpenAI WebRTC v reálnom čase popisuje aplikáciu prehliadača, ktorá používa službu koncových tokenov na získanie dočasného tokenu pred spustením pripojenia WebRTC a varuje pred použitím štandardného kľúča API v klientskej aplikácii. Pokyny OpenAI Agents SDK v reálnom čase tiež odporúčajú postup, pri ktorom backend vytvorí krátkodobý efemérny klientsky token a prehliadač ho použije na vytvorenie pripojenia WebRTC.

Odporúčania: S bránou zaobchádzajte ako s autoritou relácie. Mal by rozhodnúť, či môže existovať relácia v reálnom čase, s akým modelom, v ktorom regióne, pre ktorého nájomcu, v rámci akého rozpočtu a s akými nástrojmi. Klient by mal dostať len minimálne krátkodobé poverenia potrebné na začatie schválenej relácie.

Predpovede: Rozhrania API poskytovateľa v reálnom čase budú chvíľu nerovnomerné. Životnosť tokenov, polia konfigurácie relácie, ovládacie prvky odpojenia na strane servera, udalosti používania a podpora regiónu sa budú líšiť. Brány by mali explicitne modelovať možnosti poskytovateľa namiesto toho, aby predstierali, že všetky rozhrania API v reálnom čase sú dokonale prenosné.

Referenčná architektúra: brána ako riadiaca rovina v reálnom čase

Tok v reálnom čase bezpečný pre prehliadač má päť častí:

1. Klientská aplikácia: Prehliadač alebo mobilná aplikácia vyžadujúca hlasovú reláciu.
2. Backend aplikácie: Overí koncového používateľa a zavolá bránu alebo vloží logiku ražby tokenov brány, ak je brána súčasťou servera.
3. Brána AI API: Presadzuje politiku nájomníka, rieši profil modelu, rezervuje rozpočet, zaznamenáva reláciu a razí pominuteľné tajomstvo klienta poskytovateľa.
4. Poskytovateľ v reálnom čase: Ukončí WebRTC alebo iný prenos v reálnom čase.
5. Účtovná kniha a analýzy: Vyrovná používanie, keď sú k dispozícii udalosti poskytovateľa, údaje o trvaní alebo konečné správy o používaní.

Brána nemusí prenášať každý zvukový rámec, aby zostala autoritatívna. Musí vlastniť rozhodnutie o vytvorení relácie a cestu vyrovnania.

Odporúčaný postup žiadostí

1. Používateľ otvorí hlasovú funkciu v klientskej aplikácii.
2. Klient zavolá váš backend: POST /voice/sessions.
3. Backend overí reláciu používateľa a odošle bráne požiadavku mint s ID nájomníka, ID používateľa, zamýšľanou funkciou, metadátami zariadenia a pôvodom.
4. Brána vyhodnocuje politiku a rozpočet.
5. Brána pred kontaktovaním poskytovateľa vytvorí miestny záznam realtime_session.
6. Brána zavolá poskytovateľa s jeho chránenými povereniami v režime runtime a vytvorí dočasnú reláciu v reálnom čase s obmedzeným rozsahom.
7. Brána vracia prehliadaču iba dočasné tajné klientske tajomstvo a metadáta schválenej relácie.
8. Prehliadač vytvorí spojenie WebRTC priamo s poskytovateľom.
9. Brána prijíma udalosti používania poskytovateľa, spätné volania, výsledky prieskumov alebo konzervatívne odhady na základe trvania.
10. Hlavná kniha vyrovná rezervovaný rozpočet a zapíše udalosti auditu.

Predbežné kontroly pravidiel

Najdôležitejším bodom presadzovania je pred razením efemérneho tokenu. Keď má prehliadač krátkodobé poverenie, vynútenie v polovici relácie môže byť obmedzené, pokiaľ poskytovateľ nepodporuje ovládanie aktualizácie relácie, odpojenia, pozorovateľa alebo spätného volania.

Brána by mala kontrolovať minimálne:

• Stav nájomníka: aktívny, pozastavený, skúšobný, predplatený, fakturovaný alebo v karanténe.
• Nárok používateľa: či tento používateľ môže používať hlasový rozhovor v reálnom čase, nielen textový rozhovor.
• Povolený profil modelu: schválený model alebo nasadenie v reálnom čase, nie ľubovoľné ID modelu poskytnuté klientom.
• Región a pravidlá uchovávania: či sa vybraný región poskytovateľa a skupina funkcií zhodujú s pravidlami pre údaje nájomníka.
• Maximálne trvanie relácie: napríklad 5, 15 alebo 30 minút podľa plánu.
• Povolené spôsoby: zvukový vstup, zvukový výstup, text, obrázok alebo volanie nástrojov.
• Šablóna hlasu a pokynov: pevná alebo ohraničená zásadami.
• Dostupný rozpočet: predplatený zostatok, rezervovaný mesačný príspevok alebo strop výdavkov na jednotlivé funkcie.
• Súbežnosť: aktívne hlasové relácie na úrovni nájomníka a používateľa.
• Kontrola zneužitia: príznaky rizika používateľa, reputácia pôvodu, nezvyčajná rýchlosť hovoru alebo prepínač zabíjania nájomníka.

Bezpečným predvoleným nastavením je odmietnutie nejednoznačných žiadostí. Ak klient požiada o model, nástroj, hlas alebo región, ktorý nie je v politike nájomníka v reálnom čase, brána by mala namiesto tichého rozširovania prístupu vrátiť jasnú chybu pravidiel.

Návrh záznamu relácie

Pred vytlačením poverení poskytovateľa vytvorte záznam relácie na strane brány. Získate tak ukotvenie auditu, aj keď je vytvorenie poskytovateľa úspešné, ale prehliadač sa nikdy nepripojí.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "provider": "poskytovateľ_a",
  "provider_session_id": null,
  "model_profile": "hlasová podpora-štandard",
  "upstream_model_or_deployment": "realtime-model-x",
  "región": "eastus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["audio_input", "audio_output"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "approve_side_effects",
  "budget_reservation_id": "resv_789",
  "max_duration_seconds": 900,
  "issued_at": "2026-08-21T10:00:00Z",
  "expires_at": "2026-08-21T10:01:00Z",
  "client_origin": "https://app.example.com",
  "device_id_hash": "sha256:...",
  "status": "razba"
}

Predvolene neukladajte nespracovaný zvuk mikrofónu ani úplné výzvy. Uchovávajte konfiguračné hash, ID, rozhodnutia o politike a minimálne metadáta dostatočné na audit, podporu a fakturáciu. Ak sa vyžaduje záznam, uveďte ho explicitne, dbajte na súhlas a riadite sa pravidlami nájomcu.

Koncový bod razenia efemérnych tokenov

Koncový bod smerujúci k bráne môže vyzerať takto:

POST /v1/realtime/sessions
Autorizácia: Nositeľ 
Content-Type: application/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  "origin": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "hlasová podpora-štandard"
}

Odpoveď by nemala odhaliť váš upstreamový kľúč runtime:

{
  "session_id": "rt_01j...",
  "provider": "poskytovateľ_a",
  "transport": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  "schválené": {
    "model_profile": "hlasová podpora-štandard",
    "max_duration_seconds": 900,
    "modality": ["audio_input", "audio_output"],
    "tools": ["lookup_order_status"]
  }
}

Zviazať vydanie na pôvod, reláciu overeného používateľa, nájomníka a nonce. Poskytovateľ nemusí natívne podporovať všetky tieto väzby, preto na bráne vynucujte, čo môžete: obmedzte počet pokusov o mincovňu, odmietnite neočakávané zdroje, zaznamenávajte metadáta zariadenia a udržujte krátku životnosť tokenu.

Šablóny relácií: predvolene úzke

Šablóna relácie v reálnom čase by mala byť prísnejšia ako všeobecná žiadosť o dokončenie rozhovoru. Hlasové relácie sú interaktívne, ťažšie sa kontrolujú v reálnom čase a môžu trvať dlhšie, než sa očakávalo.

Odporúčané polia šablón zahŕňajú:

• Pevný model alebo nasadenie: zvolený profilom modelu na strane brány.
• Pokyny: šablóna výzvy riadená serverom s premennými schválenými nájomníkom.
• Hlas: vybratý zo zoznamu povolených.
• Modality: deaktivujte režimy textu, obrázkov alebo nástrojov, pokiaľ ich produkt nepotrebuje.
• Nastavenia zvuku vstupu: rozpoznávanie otočenia, správanie pri prepise alebo ovládanie stíšenia, ak sú podporované.
• Obmedzenia výstupu: maximálna dĺžka odozvy alebo správanie odozvy, ak je podporované.
• Zoznam povolených nástrojov: iba nástroje potrebné pre túto funkciu.
• Životnosť relácie: krátke uplynutie platnosti poverení plus maximálne trvanie hovoru.

Prísne šablóny znižujú flexibilitu, ale uľahčujú náklady, dodržiavanie predpisov a podporu. Ak produktové tímy potrebujú dynamické hlasy alebo pokyny, odhaľte riadené varianty profilu namiesto odovzdávania ľubovoľnej konfigurácie klienta poskytovateľovi.

Ovládacie prvky rozpočtu pre hlas v reálnom čase

Používanie v reálnom čase môže byť ťažšie určiť pred použitím konečného poskytovateľa. Relácia môže trvať päť sekúnd alebo dvadsať minút. Môže zahŕňať zvukový vstup, zvukový výstup, prepis, volania nástrojov a textové tokeny. Brána by preto mala kombinovať rezerváciu, limity a zmierenie.

Pred razbou

• Odhadnite najhoršiu alebo konzervatívnu cenu relácie na základe maximálneho trvania, modelu, modalít a plánu nájomníka.
• Pred vydaním tajného kľúča klienta si rezervujte rozpočet.
• Odmietnite nové relácie, ak nájomník nemá dostatočnú rovnováhu alebo dosiahol denné hlasové limity.

Počas relácie

• Sledujte aktívne relácie a očakávanú rýchlosť spaľovania.
• Použite limity súbežnosti nájomníkov a používateľov.
• Použite funkcie ukončenia alebo aktualizácie relácie podporované poskytovateľom, ak sú k dispozícii.
• Spúšťať upozornenia na abnormálne trvanie relácie, opakované opätovné pripojenia alebo nezvyčajné používanie hlasu.

Po relácii

• Udalosti používania poskytovateľa príjmu alebo správy o konečnom použití, ak sú k dispozícii.
• Vyrovnajte rezervovaný rozpočet podľa skutočných nákladov.
• Ak je presné použitie oneskorené alebo neúplné, podržte konzervatívnu rezerváciu až do vyrovnania.
• Použitie priraďte nájomníkovi, používateľovi, funkcii, profilu modelu a ID relácie.

Je to menej presné ako synchrónna textová fakturácia v momente odpovede, ale je prevádzkovo bezpečnejšia ako vydávanie priamych poverení bez výhrad.

Volania nástrojov v rámci relácií v reálnom čase

Hlasoví agenti v reálnom čase sú často užitočnejší, keď môžu volať nástroje: vyhľadať účet, rezervovať si stretnutie, aktualizovať lístok alebo spustiť pracovný postup. Spustenie nástroja zaobchádzajte oddelene od prenosu zvuku.

Pripojenie k médiám prehliadača by nemalo znamenať povolenie na vykonávanie vedľajších účinkov. Brána alebo backend by mali vynucovať:

• Register nástrojov: každý nástroj má vlastníka, schému, rozsahy a úroveň rizika.
• Zoznamy povolených: šablóny relácií presne uvádzajú, ktoré nástroje sú k dispozícii.
• Brány schvaľovania: akcie s vedľajšími účinkami vyžadujú potvrdenie používateľom, schválenie človekom alebo schválenie zásad.
• Samostatné poverenia: poverenia nástroja nie sú nikdy vložené do relácie prehliadača.
• Pripojený audit trail: každé volanie nástroja odkazuje na ID relácie v reálnom čase.

Napríklad podporný hlasový agent môže mať povolené volať lookup_order_status automaticky, ale refund_payment môže vyžadovať výslovné potvrdenie a udalosť schválenia na strane servera. Poskytovateľ v reálnom čase môže organizovať konverzáciu, ale hranicu povolení by mala riadiť vaša brána.

Viditeľnosť bez proxy každého bajtu

Priamy tok médií WebRTC znižuje latenciu brány a zaťaženie šírky pásma, ale viditeľnosť sa stáva viac závislou od udalostí poskytovateľa a vašich vlastných metadát relácie. Navrhnite analýzy týkajúce sa viacerých zdrojov dôkazov:

• Záznamy o vytvorení relácie z brány.
• Udalosti životného cyklu na strane klienta, ako je pripojenie, odpojenie, pokus o opätovné pripojenie, odmietnutie mikrofónu alebo ukončenie hovoru.
• ID relácie poskytovateľa, udalosti používania alebo záznamy o konečnom použití.
• Odhady na základe trvania, keď sa používanie poskytovateľa oneskorí.
• Protokoly hovorov nástroja spojené pomocou ID relácie.
• Záznamy o rezerváciách rozpočtu a vysporiadaní.

Pred spustením ovládacích prvkov nečakajte na dokonalú telemetriu poskytovateľa. Začnite s konzervatívnymi rezerváciami a jasným pripisovaním a s vyspelosťou prehľadov používania poskytovateľa zlepšite presnosť vyrovnania.

Kontrolný zoznam zabezpečenia

• Nikdy neposielajte štandardné kľúče API poskytovateľa do prehliadača alebo mobilných klientov.
• Na spustenie relácie v reálnom čase použite krátkodobé efemérne tajomstvá klienta.
• Pred razením tokenov overte koncového používateľa.
• Ak je to možné, zviažte rozhodnutia o razbe s nájomníkom, používateľom, pôvodom, nonce a metadátami zariadenia.
• Uchovajte poverenia poskytovateľa v tajnom úložisku servera alebo brány.
• Pred razením poskytovateľa zaznamenajte riadok auditu relácie.
• Namiesto ľubovoľnej konfigurácie klienta používajte šablóny relácií schválené nájomníkom.
• Použite limity súbežnosti, denného používania a maximálneho trvania.
• Na vedľajšie účinky použite zoznamy povolených nástrojov a brány schvaľovania.
• V predvolenom nastavení minimalizujte nespracované výzvy a uchovávanie zvuku.
• Udržiavajte maticu schopností poskytovateľa pre životnosť tokenov, oblasti, nástroje, udalosti používania a ovládacie prvky ukončenia.

Matrika schopností poskytovateľa

Keďže sa rozhrania API v reálnom čase líšia, modelujte svoj adaptér brány podľa schopností a nie podľa predpokladov. Jednoduchá matica môže riadiť rozhodnutia o smerovaní a politike:

{
  "poskytovateľ_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": pravda,
    "token_ttl_seconds": 60,
    "server_side_disconnect": pravda,
    "session_update": true,
    "usage_events": "final_and_incremental",
    "regióny": ["nás", "eu"],
    "tool_approval_supported": pravda
  },
  "poskytovateľ_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": pravda,
    "token_ttl_seconds": 120,
    "server_side_disconnect": nepravda,
    "session_update": nepravda,
    "usage_events": "final_only",
    "regióny": ["nás"],
    "tool_approval_supported": nepravda
  }
}

Ak nájomník vyžaduje trvalý pobyt v EÚ a ukončenie na strane servera, brána by mala smerovať iba k poskytovateľom a nasadeniam, ktoré spĺňajú oboje. Ak pravidlá nespĺňa žiadny poskytovateľ, zlyhanie zatvorte.

Cesta migrácie

Nemusíte vytvárať všetky ovládacie prvky v prvý deň. Praktické zavedenie je:

1. Iba vytváranie proxy relácií: ponechajte médiá priamo, ale vyžaduje, aby boli všetky relácie v reálnom čase vytlačené na serveri alebo bráne.
2. Pridajte šablóny pravidiel: nahraďte klientom dodané polia modelu a pokynov schválenými profilmi.
3. Pridať rezerváciu rozpočtu: rezervujte si konzervatívnu cenu relácie pred vydaním tokenu.
4. Pridanie analýzy životného cyklu: zbierajte začiatok relácie, pripojenie, odpojenie, trvanie, ID relácie poskytovateľa a stav vyrovnania.
5. Pridať správu nástrojov: vyžadujú zoznamy povolených a schválení pre volania nástrojov v reálnom čase.
6. Pridať smerovanie schopnosti poskytovateľa: vyberte poskytovateľov podľa regiónu, spôsobu, podpory udalostí a ovládacích prvkov ukončenia.
7. Pridajte voliteľného pozorovateľa alebo pracovné postupy zaznamenávania: iba ak je to v súlade, súhlas a schválenie nájomcom.

Uplatniteľný záver

V prípade hlasovej AI v reálnom čase by sa brána AI API nemala automaticky stať mediálnym prenosom. Bezpečnejšou architektúrou a nižšou latenciou je ponechať bránu na starosti riadiacej rovine: autentifikovať používateľov, presadzovať politiku nájomníka, rezervovať rozpočet, vytvárať záznam auditu, raziť dočasnú poverenie v úzkom rozsahu a zosúladiť používanie po relácii.

Základné implementačné pravidlo je jednoduché: prehliadače môžu dostávať krátkodobé tajomstvá relácie, nikdy nie dlhodobé kľúče poskytovateľa. Všetko ostatné vyplýva z tejto hranice: prísne šablóny, ražba s ohľadom na pôvod, limity súbežných relácií, schválenia nástrojov, vyrovnanie používania a matice schopností poskytovateľa. To poskytuje produktovým tímom hlasové skúsenosti v reálnom čase bez toho, aby sa vzdali správy kľúčov API, riadenia nákladov AI API, správy tímového rozhrania API alebo analýzy používania AI.

Súvisiace čítanie

• kniha rezervácií rozpočtu a zúčtovania