Umělá inteligence v reálném čase bezpečná pro prohlížeč prostřednictvím brány API: pomíjivé tokeny, zásady tenantů a ovládání hlasových relací

Prohlížeč a mobilní aplikace by neměly dostávat dlouhodobé klíče API poskytovatele. U hlasové umělé inteligence v reálném čase však odesílání každého zvukového paketu přes bránu může zvýšit latenci, provozní náklady a režimy selhání. Lepším vzorem je ponechat bránu v řídicí rovině: ověřovat uživatele, vynucovat zásady pro nájemce, rezervovat rozpočet, vytěžit úzké krátkodobé pověření v reálném čase a nechat média citlivá na latenci používat přenos poskytovatele v reálném čase tam, kde je to vhodné.

Tento článek popisuje vzor implementace pro týmy vytvářející hlasové agenty, asistenty volání, mobilní lektory, kopiloty podpory nebo hlasová rozhraní v aplikaci prostřednictvím brány AI API. Cílem je bezpečnost prohlížeče bez ztráty správy tenantem.

Problém: přímá připojení v reálném čase obcházejí vaše ovládací prvky

Prostý proxy server na straně serveru je atraktivní, protože centralizuje klíče a pozorovatelnost. Pro standardní textové požadavky je to často ten správný model. Zvuk v reálném čase je jiný. Hlasová relace může zahrnovat nepřetržitý vstup mikrofonu, obousměrný zvukový výstup, přerušení, volání nástrojů a přísná očekávání latence. Proxy všech médií prostřednictvím vaší brány může změnit bránu na mediální přenos s vysokou šířkou pásma namísto služby zásad a fakturace.

Přímé připojení mezi prohlížečem a poskytovatelem řeší latenci, ale vytváří jiný problém:

• Prohlížeč nemůže bezpečně podržet standardní klíč API poskytovatele.
• Pokud se aplikace připojuje přímo, mohou být kontroly rozpočtu nájemců přeskočeny.
• Omezení modelu, oblasti, hlasu, modality a nástrojů se stávají příslibem na straně klienta.
• Uvedení zdroje bude neúplné nebo se zpozdí.
• Bezpečnostní týmy ztratí před zahájením relace kontrolovatelné rozhodnutí.

Praktický design není „proxy každý bajt“. Je to „zprostředkovatel každé relace.“

Fakta, doporučení a předpovědi

Fakta: Poskytovatelé umělé inteligence v reálném čase stále více podporují přenosy s nízkou latencí, jako jsou WebRTC, WebSocket a SIP. Veřejná dokumentace pro OpenAI Realtime API popisuje rozhraní v reálném čase s nízkou latencí, včetně WebRTC. Pokyny k Azure OpenAI WebRTC v reálném čase popisují aplikaci prohlížeče, která používá službu back-end tokenu k načtení pomíjivého tokenu před zahájením připojení WebRTC a varuje před použitím standardního klíče API v klientské aplikaci. Pokyny OpenAI Agents SDK v reálném čase také doporučují postup, kdy backend vytvoří krátkodobý pomíjivý klientský token a prohlížeč jej použije k navázání připojení WebRTC.

Doporučení: Zacházejte s bránou jako s autoritou relace. Měl by rozhodnout, zda může existovat relace v reálném čase, s jakým modelem, v jakém regionu, pro kterého nájemce, pod jakým rozpočtem as jakými nástroji. Klient by měl obdržet pouze minimální krátkodobé pověření potřebné k zahájení této schválené relace.

Předpovědi: Rozhraní API poskytovatelů v reálném čase zůstanou nějakou dobu nerovnoměrná. Životnost tokenů, pole konfigurace relace, ovládací prvky odpojení na straně serveru, události použití a podpora regionu se budou lišit. Brány by měly explicitně modelovat schopnosti poskytovatele, místo aby předstíraly, že všechna rozhraní API v reálném čase jsou dokonale přenosná.

Referenční architektura: brána jako řídicí rovina v reálném čase

Prohlížeč bezpečný tok v reálném čase má pět částí:

1. Klientská aplikace: Prohlížeč nebo mobilní aplikace vyžadující hlasovou relaci.
2. Backend aplikace: Ověřuje koncového uživatele a volá bránu nebo vkládá logiku ražení tokenů brány, pokud je brána součástí backendového zásobníku.
3. Brána AI API: Prosazuje zásady tenanta, řeší profil modelu, rezervuje rozpočet, zaznamenává relaci a razí pomíjivé tajemství klienta poskytovatele.
4. Poskytovatel v reálném čase: Ukončí WebRTC nebo jiný přenos v reálném čase.
5. Účetní kniha a analýzy: Vyrovnává využití, jakmile jsou k dispozici události poskytovatele, údaje o trvání nebo konečné zprávy o využití.

Brána nemusí předávat každý zvukový rámec, aby zůstala autoritativní. Musí vlastnit rozhodnutí o vytvoření relace a cestu sladění.

Doporučený postup požadavků

1. Uživatel otevře v klientské aplikaci hlasovou funkci.
2. Klient zavolá váš backend: POST /voice/sessions.
3. Backend ověří relaci uživatele a předá bráně požadavek mint s ID tenanta, ID uživatele, zamýšlenou funkcí, metadaty zařízení a původem.
4. Brána vyhodnocuje zásady a rozpočet.
5. Před kontaktováním poskytovatele vytvoří brána místní záznam realtime_session.
6. Brána zavolá poskytovatele pomocí svých chráněných přihlašovacích údajů za běhu a vytvoří dočasnou relaci v reálném čase s úzkým rozsahem.
7. Brána vrací do prohlížeče pouze pomíjivá klientská tajná a schválená metadata relace.
8. Prohlížeč naváže spojení WebRTC přímo s poskytovatelem.
9. Brána zpracovává události využití poskytovatele, zpětná volání, výsledky dotazování nebo konzervativní odhady založené na trvání.
10. Hlavní kniha vyrovnává rezervovaný rozpočet a zapisuje události auditu.

Předběžné kontroly zásad

Nejdůležitějším bodem vynucení je před vyražením pomíjivého tokenu. Jakmile má prohlížeč krátkodobé pověření, může být vynucení uprostřed relace omezeno, pokud poskytovatel nepodporuje ovládání aktualizace relace, odpojení, pozorovatele nebo zpětného volání.

Brána by měla kontrolovat minimálně:

• Stav nájemce: aktivní, pozastavený, zkušební, předplacený, fakturovaný nebo v karanténě.
• Nárok uživatele: zda tento uživatel smí používat hlasový chat v reálném čase, nejen textový chat.
• Povolený profil modelu: schválený model nebo nasazení v reálném čase, nikoli libovolné ID modelu poskytnuté klientem.
• Zásady oblasti a uchovávání: zda vybraný region poskytovatele a sada funkcí odpovídají datovým pravidlům tenanta.
• Maximální trvání relace: například 5, 15 nebo 30 minut podle plánu.
• Povolené způsoby: zvukový vstup, zvukový výstup, text, obrázek nebo volání nástrojů.
• Šablona hlasu a pokynů: pevná nebo ohraničená zásadami.
• Dostupný rozpočet: předplacený zůstatek, rezervovaný měsíční příspěvek nebo strop útraty pro jednotlivé funkce.
• Souběh: aktivní hlasové relace na úrovni tenanta a uživatele.
• Kontrola zneužití: příznaky rizika uživatele, reputace původu, neobvyklá rychlost volání nebo přepínač zabíjení tenanta.

Bezpečným výchozím nastavením je odmítat nejednoznačné požadavky. Pokud klient požádá o model, nástroj, hlas nebo oblast, která není v zásadách klienta v reálném čase, brána by měla namísto tichého rozšiřování přístupu vrátit jasnou chybu zásad.

Návrh záznamu relace

Před vytištěním pověření poskytovatele vytvořte záznam relace na straně brány. Získáte tak ukotvení auditu, i když vytvoření poskytovatele proběhne úspěšně, ale prohlížeč se nikdy nepřipojí.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "provider": "poskytovatel_a",
  "provider_session_id": null,
  "model_profile": "standardní hlasová podpora",
  "upstream_model_or_deployment": "realtime-model-x",
  "region": "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": "ražba"
}

Ve výchozím nastavení neukládat nezpracovaný zvuk mikrofonu ani úplné výzvy. Ukládejte konfigurační hash, ID, rozhodnutí o zásadách a minimální metadata postačující pro audit, podporu a fakturaci. Pokud je záznam vyžadován, uveďte jej explicitně, dbejte na souhlas a řiďte se zásadami nájemce.

Koncový bod ražby pomíjivých tokenů

Koncový bod směřující k bráně může vypadat takto:

POST /v1/realtime/sessions
Autorizace: Doručitel 
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-standard"
}

Odpověď by neměla odhalit váš upstream runtime klíč:

{
  "session_id": "rt_01j...",
  "provider": "poskytovatel_a",
  "transport": "webrtc",
  "client_secret": "efemérní_tajemství_zde",
  "expires_at": "2026-08-21T10:01:00Z",
  "schváleno": {
    "model_profile": "standardní hlasová podpora",
    "max_duration_seconds": 900,
    "modality": ["audio_input", "audio_output"],
    "tools": ["lookup_order_status"]
  }
}

Svázat vydání s původem, relací ověřeného uživatele, tenantem a nonce. Poskytovatel nemusí všechny tyto vazby nativně podporovat, takže na bráně vynucujte, co můžete: omezte počet pokusů o mincovnu, odmítněte neočekávané zdroje, zaznamenejte metadata zařízení a udržujte krátkou životnost tokenu.

Šablony relací: ve výchozím nastavení úzké

Šablona relace v reálném čase by měla být více omezující než obecná žádost o dokončení chatu. Hlasové relace jsou interaktivní, hůře se kontrolují v reálném čase a mohou trvat déle, než se očekávalo.

Doporučená pole šablony zahrnují:

• Pevný model nebo nasazení: volí profil modelu na straně brány.
• Pokyny: šablona výzvy řízená serverem s proměnnými schválenými tenantem.
• Hlas: vybráno ze seznamu povolených.
• Modality: deaktivujte režimy textu, obrázků nebo nástrojů, pokud je produkt nepotřebuje.
• Nastavení zvuku vstupu: detekce otočení, chování při přepisu nebo ovládání ticha, pokud je podporováno.
• Omezení výstupu: maximální délka odezvy nebo chování odezvy, pokud je podporováno.
• Seznam povolených nástrojů: pouze nástroje potřebné pro tuto funkci.
• Životnost relace: krátké vypršení platnosti pověření plus maximální délka hovoru.

Přísné šablony snižují flexibilitu, ale usnadňují náklady, shodu a podporu. Pokud produktové týmy potřebují dynamické hlasy nebo pokyny, vystavte řízené varianty profilu namísto předávání libovolné konfigurace klienta poskytovateli.

Ovládací prvky rozpočtu pro hlas v reálném čase

Použití v reálném čase může být obtížnější stanovit cenu, než dojde k využití u konečného poskytovatele. Relace může trvat pět sekund nebo dvacet minut. Může zahrnovat zvukový vstup, zvukový výstup, přepis, volání nástrojů a textové tokeny. Brána by proto měla kombinovat rezervaci, omezení a odsouhlasení.

Před ražbou

• Odhadněte nejhorší případ nebo konzervativní cenu relace z maximální doby trvání, modelu, modalit a plánu nájemce.
• Před vydáním tajného klíče klienta si rezervujte rozpočet.
• Odmítněte nové relace, pokud tenant nemá dostatečnou rovnováhu nebo dosáhl denních hlasových limitů.

Během relace

• Sledování aktivních relací a očekávané rychlosti vypalování.
• Použijte omezení souběžnosti nájemců a uživatelů.
• Používejte funkce ukončení nebo aktualizace relace podporované poskytovatelem, jsou-li k dispozici.
• Spouštět upozornění na abnormální trvání relace, opakovaná opětovné připojení nebo neobvyklé použití hlasu.

Po relaci

• Události využití poskytovatele ingest nebo zprávy o konečném využití, pokud jsou k dispozici.
• Urovnejte rezervovaný rozpočet podle skutečných nákladů.
• Pokud je přesné použití zpožděno nebo neúplné, podržte konzervativní rezervaci až do sladění.
• Použití přiřaďte tenantovi, uživateli, funkci, profilu modelu a ID relace.

Toto je méně přesné než synchronní textové účtování v okamžiku odpovědi, ale je provozně bezpečnější než vydávání přímých přihlašovacích údajů bez výhrad.

Volání nástrojů v rámci relací v reálném čase

Hlasoví agenti v reálném čase se často stávají užitečnějšími, když mohou volat nástroje: vyhledávat účet, rezervovat si schůzku, aktualizovat lístek nebo spustit pracovní postup. Spouštění nástroje zacházejte odděleně od přenosu zvuku.

Připojení k médiím v prohlížeči by nemělo znamenat povolení k provádění vedlejších efektů. Brána nebo backend by měly vynucovat:

• Registr nástrojů: každý nástroj má vlastníka, schéma, rozsahy a úroveň rizika.
• Seznamy povolených: šablony relací přesně uvádějí, které nástroje jsou k dispozici.
• Brány schvalování: akce s vedlejšími účinky vyžadují potvrzení uživatele, schválení člověkem nebo schválení zásad.
• Samostatné přihlašovací údaje: přihlašovací údaje nástroje nejsou nikdy vloženy do relace prohlížeče.
• Připojený auditní záznam: každé volání nástroje odkazuje na ID relace v reálném čase.

Například hlasovému agentovi podpory může být povoleno volat lookup_order_status automaticky, ale refund_payment může vyžadovat výslovné potvrzení a událost schválení typu back-end. Poskytovatel v reálném čase může zorganizovat konverzaci, ale hranice oprávnění by měla řídit vaše brána.

Viditelnost bez proxy každého bajtu

Přímý tok médií WebRTC snižuje latenci brány a zatížení šířky pásma, ale viditelnost se stává více závislou na událostech poskytovatele a vašich vlastních metadatech relace. Navrhněte analýzy na základě různých zdrojů důkazů:

• Záznamy o vytvoření relace z brány.
• Události životního cyklu na straně klienta, jako je připojení, odpojení, pokus o opětovné připojení, odepření mikrofonu nebo ukončení hovoru.
• ID relací poskytovatele, události použití nebo záznamy o konečném použití.
• Odhady založené na délce trvání, když je využití poskytovatelem zpožděno.
• Protokoly volání nástroje spojené pomocí ID relace.
• Záznamy rezervací a vypořádání rozpočtu.

Před spuštěním ovládacích prvků nečekejte na dokonalou telemetrii poskytovatele. Začněte s konzervativními rezervacemi a jasnou atribucí a zlepšete přesnost vypořádání s vyspělostí přehledů využití poskytovatelem.

Kontrolní seznam zabezpečení

• Nikdy neposílejte standardní klíče API poskytovatele do prohlížeče nebo mobilních klientů.
• Pro spuštění relace v reálném čase použijte krátkodobá efemérní tajemství klienta.
• Před ražením tokenu ověřte koncového uživatele.
• Pokud je to možné, svažte rozhodnutí o ražbě s metadaty tenanta, uživatele, původu, nonce a zařízení.
• Uchovávejte přihlašovací údaje poskytovatele v tajném úložišti back-endu nebo brány.
• Před ražbou poskytovatele zaznamenejte řádek auditu relace.
• Namísto libovolné konfigurace klienta použijte šablony relací schválené tenantem.
• Použijte limity souběžnosti, denního využití a maximální doby trvání.
• Pro nežádoucí účinky použijte seznamy povolených nástrojů a brány schvalování.
• Ve výchozím nastavení minimalizujte nezpracované výzvy a zachování zvuku.
• Udržujte matici schopností poskytovatele pro životnost tokenů, oblasti, nástroje, události použití a ovládací prvky ukončení.

Matice schopností poskytovatele

Protože se rozhraní API v reálném čase liší, modelujte adaptér brány podle schopností, nikoli podle předpokladů. Jednoduchá matice může řídit směrování a rozhodování o politice:

{
  "poskytovatel_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": pravda,
    "token_ttl_seconds": 60,
    "server_side_disconnect": true,
    "session_update": true,
    "usage_events": "final_and_incremental",
    "regions": ["us", "eu"],
    "tool_approval_supported": pravda
  },
  "poskytovatel_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": pravda,
    "token_ttl_seconds": 120,
    "server_side_disconnect": nepravda,
    "session_update": nepravda,
    "usage_events": "final_only",
    "regions": ["nás"],
    "tool_approval_supported": nepravda
  }
}

Pokud tenant vyžaduje rezidenci v EU a ukončení na straně serveru, měla by brána směrovat pouze k poskytovatelům a nasazením, která splňují obojí. Pokud žádný poskytovatel nesplňuje zásady, bude selhání uzavřeno.

Cesta migrace

Nemusíte vytvářet všechny ovládací prvky hned první den. Praktické zavedení je:

1. Pouze vytváření proxy relací: ponechte média přímo, ale vyžaduje, aby všechny relace v reálném čase byly raženy backendem nebo bránou.
2. Přidejte šablony zásad: nahraďte klientem dodaná pole modelu a pokynů schválenými profily.
3. Přidat rezervaci rozpočtu: rezervujte si konzervativní cenu relace před vydáním tokenu.
4. Přidejte analýzu životního cyklu: shromažďujte začátek relace, připojení, odpojení, trvání, ID relace poskytovatele a stav vypořádání.
5. Přidat správu nástrojů: vyžadovat seznamy povolených a schválení pro volání nástrojů v reálném čase.
6. Přidat směrování schopností poskytovatele: vyberte poskytovatele podle regionu, modality, podpory událostí a ovládacích prvků ukončení.
7. Přidejte volitelného pozorovatele nebo pracovní postupy nahrávání: pouze v případě, že je to v souladu, souhlas a schválení nájemcem.

Akční závěr

U hlasové umělé inteligence v reálném čase by se brána AI API neměla automaticky stát mediálním přenosem. Bezpečnější architektura s nižší latencí spočívá v tom, že brána bude mít kontrolu nad řídicí rovinou: ověřovat uživatele, vynucovat zásady pro nájemce, rezervovat rozpočet, vytvořit záznam auditu, vytěžit dočasná pověření s úzkým rozsahem a sladit použití po relaci.

Základní implementační pravidlo je jednoduché: prohlížeče mohou přijímat krátkodobá tajemství relace, nikdy ne dlouhodobé klíče poskytovatele. Vše ostatní vyplývá z této hranice: přísné šablony, ražba s ohledem na původ, omezení souběžných relací, schválení nástrojů, vypořádání využití a matice schopností poskytovatele. To poskytuje produktovým týmům hlasové zážitky v reálném čase, aniž by se vzdali správy klíčů API, řízení nákladů AI API, správy týmového rozhraní API nebo analýzy využití AI.

Související informace

• kniha rezervací rozpočtu a vypořádání