Intel·ligència artificial en temps real segura per al navegador mitjançant una passarel·la d'API: testimonis efímers, política d'inquilí i controls de sessió de veu

Les aplicacions del navegador i mòbils no haurien de rebre claus del proveïdor API de llarga durada. Tanmateix, per a la IA de veu en temps real, enviar cada paquet d'àudio a través d'una passarel·la pot afegir latència, cost operatiu i modes de fallada. El millor patró és mantenir la passarel·la al pla de control: autenticar l'usuari, fer complir la política d'inquilí, reservar pressupost, encunyar una credencial en temps real de curta durada i deixar que els mitjans sensibles a la latència utilitzin el transport en temps real del proveïdor quan sigui necessari.

Aquest article descriu un patró d'implementació per a equips que creen agents de veu, assistents de trucada, tutors mòbils, copilots de suport o interfícies de veu dins de l'aplicació mitjançant una passarel·la AI API. L'objectiu és la seguretat del navegador sense perdre el govern dels inquilins.

El problema: les connexions directes en temps real obvien els vostres controls

Un servidor intermediari senzill del costat del servidor és atractiu perquè centralitza les claus i l'observabilitat. Per a sol·licituds de text estàndard, aquest és sovint el model adequat. L'àudio en temps real és diferent. Una sessió de veu pot incloure entrada de micròfon contínua, sortida d'àudio bidireccional, interrupcions, trucades a eines i expectatives de latència estrictes. El proxy de tots els mitjans a través de la vostra passarel·la pot convertir la passarel·la en un relé multimèdia amb molta amplada de banda en lloc d'una política i un servei de facturació.

Les connexions directes del navegador al proveïdor solucionen la latència, però creen un problema diferent:

• El navegador no pot contenir de manera segura una clau del proveïdor estàndard API.
• Les comprovacions del pressupost dels inquilins es poden ometre si l'aplicació es connecta directament.
• Les restriccions de model, regió, veu, modalitat i eines es converteixen en promeses del client.
• L'atribució d'ús esdevé incompleta o es retarda.
• Els equips de seguretat perden un punt de decisió auditable abans que comenci una sessió.

El disseny pràctic no és "proxy cada byte". És "intermediar cada sessió".

Fets, recomanacions i prediccions

Fets: Els proveïdors d'IA en temps real admeten cada cop més transports de baixa latència com ara WebRTC, WebSocket i SIP. La documentació pública de OpenAI's Realtime API descriu interfícies en temps real de baixa latència, inclòs WebRTC. La guia de WebRTC en temps real d'Azure OpenAI descriu una aplicació de navegador que utilitza un servei de testimoni de fons per recuperar un testimoni efímer abans d'iniciar la connexió WebRTC i adverteix que no s'utilitza una clau estàndard API en una aplicació client. OpenAI La guia d'agents SDK en temps real també recomana un flux on un backend crea un testimoni de client efímer de curta durada i el navegador l'utilitza per establir una connexió WebRTC.

Recomanacions: Tracteu la passarel·la com l'autoritat de sessió. Hauria de decidir si pot existir una sessió en temps real, amb quin model, en quina regió, per a quin inquilí, amb quin pressupost i amb quines eines. El client només hauria de rebre la credencial mínima de curta durada necessària per iniciar la sessió aprovada.

Prediccions: Les API del proveïdor en temps real es mantindran desiguals durant un temps. La durada del testimoni, els camps de configuració de la sessió, els controls de desconnexió del servidor, els esdeveniments d'ús i el suport de la regió seran diferents. Les passarel·les haurien de modelar les capacitats del proveïdor de manera explícita en lloc de fingir que totes les API en temps real són perfectament portàtils.

Arquitectura de referència: passarel·la com a pla de control en temps real

Un flux en temps real segur per al navegador té cinc parts:

1. Aplicació client: Navegador o aplicació mòbil que sol·licita una sessió de veu.
2. Backend de l'aplicació: Autentica l'usuari final i truca a la passarel·la, o incorpora la lògica d'encunyació de testimonis de la passarel·la si la passarel·la forma part de la pila de fons.
3. AI API Gateway: Aplica la política d'inquilí, resol el perfil del model, reserva el pressupost, registra la sessió i encunya un secret de client de proveïdor efímer.
4. Proveïdor en temps real: Termina WebRTC o un altre transport en temps real.
5. Llibre i anàlisi: liquida l'ús un cop estiguin disponibles els esdeveniments del proveïdor, les dades de durada o els informes d'ús finals.

La passarel·la no necessita transmetre tots els fotogrames d'àudio per mantenir l'autoritat. Ha de ser propietari de la decisió de creació de la sessió i del camí de conciliació.

Flux de sol·licituds recomanat

1. L'usuari obre una funció de veu a l'aplicació client.
2. El client truca al vostre backend: POST /voice/sessions.
3. El backend verifica la sessió de l'usuari i reenvia una sol·licitud mint a la passarel·la amb l'identificador de l'inquilí, l'identificador d'usuari, la funció prevista, les metadades del dispositiu i l'origen.
4. La passarel·la avalua la política i el pressupost.
5. La passarel·la crea un registre local realtime_session abans de contactar amb el proveïdor.
6. La passarel·la truca al proveïdor amb la seva credencial de temps d'execució protegida i crea una sessió en temps real efímera d'abast restringit.
7. La passarel·la només retorna el secret del client efímer i les metadades de sessió aprovades al navegador.
8. El navegador estableix la connexió WebRTC directament amb el proveïdor.
9. La passarel·la ingereix els esdeveniments d'ús del proveïdor, les devolucions de trucada, els resultats de les enquestes o les estimacions conservadores basades en la durada.
10. El llibre major liquida el pressupost reservat i escriu els esdeveniments d'auditoria.

Comprovacions prèvies a la política

El punt d'aplicació més important és abans d'encunyar el testimoni efímer. Un cop el navegador tingui una credencial de curta durada, l'aplicació a mitja sessió pot estar limitada tret que el proveïdor admeti l'actualització de la sessió, la desconnexió, l'observador o els controls de devolució de trucada.

Com a mínim, la passarel·la hauria de comprovar:

• Estat del llogater: actiu, suspès, de prova, prepagament, facturat o en quarantena.
• Dret de l'usuari: si aquest usuari pot utilitzar la veu en temps real, no només el xat de text.
• Perfil de model permès: model o desplegament aprovat en temps real, no identificadors de model arbitraris proporcionats pel client.
• Política de regió i retenció: si la regió del proveïdor seleccionada i el conjunt de funcions coincideixen amb les regles de dades de l'inquilí.
• Durada màxima de la sessió: per exemple, 5, 15 o 30 minuts segons el pla.
• Modalitats permeses: entrada d'àudio, sortida d'àudio, text, imatge o trucades a eines.
• Plantilla de veu i instruccions: fixada o limitada per la política.
• Pressupost disponible: saldo prepagat, subsidi mensual reservat o límit de despesa per funció.
• Simultània: sessions de veu actives a nivell d'inquilí i d'usuari.
• Controls d'abús: senyals de risc de l'usuari, reputació d'origen, velocitat de trucada inusual o interruptor de mort de l'inquilí.

Una predeterminada segura és rebutjar sol·licituds ambigües. Si el client demana un model, una eina, una veu o una regió que no es troba a la política en temps real de l'inquilí, la passarel·la hauria de retornar un error de política clar en lloc d'ampliar l'accés en silenci.

Disseny de registre de sessió

Creeu un registre de sessió del costat de la passarel·la abans d'encunyar la credencial del proveïdor. Això us proporciona un àncora d'auditoria encara que la creació del proveïdor tingui èxit però el navegador mai es connecta.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "provider": "provider_a",
  "provider_session_id": null,
  "model_profile": "voice-support-standard",
  "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": "minting"
}

No deseu l'àudio del micròfon en brut ni les sol·licituds completes de manera predeterminada. Emmagatzema hash de configuració, identificadors, decisions de polítiques i metadades mínimes suficients per a l'auditoria, el suport i la facturació. Si cal l'enregistrament, feu-lo explícit, conscient del consentiment i basat en la política de l'inquilí.

Punt final d'encunyació de testimonis efímers

Un punt final orientat a la passarel·la pot semblar així:

POST /v1/realtime/sessions
Authorization: Bearer <gateway_app_token>
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": "voice-support-standard"
}

La resposta no hauria d'exposar la vostra clau d'execució amunt:

{
  "session_id": "rt_01j...",
  "provider": "provider_a",
  "transport": "webrtc",
  "client_secret": "ephemeral_secret_here",
  "expires_at": "2026-08-21T10:01:00Z",
  "approved": {
    "model_profile": "voice-support-standard",
    "max_duration_seconds": 900,
    "modalities": ["audio_input", "audio_output"],
    "tools": ["lookup_order_status"]
  }
}

Lliga l'emissió a l'origen, la sessió d'usuari autenticada, l'arrendatari i un noce. És possible que el proveïdor no admeti tots aquests enllaços de manera nativa, així que feu complir el que podeu a la passarel·la: limitar la velocitat dels intents d'execució, rebutjar orígens inesperats, registrar metadades del dispositiu i mantenir la vida útil del testimoni breu.

Plantilles de sessió: estretes per defecte

Una plantilla de sessió en temps real hauria de ser més restrictiva que una sol·licitud general de finalització del xat. Les sessions de veu són interactives, més difícils d'inspeccionar en temps real i poden durar més temps del previst.

Els camps de plantilla recomanats inclouen:

• Model o desplegament fix: triat per un perfil de model de passarel·la.
• Instruccions: una plantilla de sol·licitud controlada pel servidor amb variables aprovades per l'inquilí.
• Veu: seleccionada d'una llista permesa.
• Modalitats: desactiveu els modes de text, imatge o eina tret que el producte els necessiti.
• Configuració d'àudio d'entrada: detecció de girs, comportament de transcripció o gestió del silenci quan s'admet.
• Restriccions de sortida: longitud màxima de resposta o comportament de resposta quan s'admet.
• Llista d'eines permeses: només les eines necessàries per a la funció.
• Vida útil de la sessió: caducitat de credencials curta més durada màxima de la trucada.

Les plantilles estrictes redueixen la flexibilitat, però faciliten el cost, el compliment i l'assistència. Si els equips de producte necessiten veus o instruccions dinàmiques, exposa les variants de perfil controlat en lloc de passar la configuració arbitrària del client al proveïdor.

Controls de pressupost per a veu en temps real

L'ús en temps real pot ser més difícil de fixar el preu abans que arribi l'ús final del proveïdor. Una sessió pot durar cinc segons o vint minuts. Pot incloure entrada d'àudio, sortida d'àudio, transcripció, trucades d'eines i fitxes de text. Per tant, la passarel·la hauria de combinar reserva, límits i conciliació.

Abans d'encunyar

• Calculeu un cost de sessió en el pitjor dels casos o conservador a partir de la durada màxima, el model, les modalitats i el pla d'inquilí.
• Reserveu pressupost abans d'emetre el secret del client.
• Rebutja sessions noves si l'inquilí no té l'equilibri suficient o ha arribat als límits de veu diaris.

Durant la sessió

• Fes un seguiment de les sessions actives i la taxa de gravació esperada.
• Aplica límits de concurrència d'usuaris i inquilins.
• Utilitzeu les funcions de terminació o d'actualització de sessions compatibles amb el proveïdor, si estan disponibles.
• Activa alertes per a una durada anormal de la sessió, reconnectades repetides o ús de veu inusual.

Després de la sessió

• Ingerir esdeveniments d'ús del proveïdor o informes d'ús finals quan estiguin disponibles.
• Ajusta el pressupost reservat al cost real.
• Si l'ús exacte es retarda o està incomplet, manteniu una reserva conservadora fins a la reconciliació.
• Atribueix l'ús a l'arrendatari, l'usuari, la funció, el perfil del model i l'identificador de sessió.

Això és menys exacte que la facturació de text síncrona en el moment de la resposta, però operativament és més segur que emetre credencials directes sense reserva.

Trucades d'eines dins de sessions en temps real

Els agents de veu en temps real solen ser més útils quan poden trucar a eines: cercar un compte, reservar una cita, actualitzar un bitllet o activar un flux de treball. Tracteu l'execució de l'eina per separat del transport d'àudio.

La connexió multimèdia del navegador no ha d'implicar permís per dur a terme efectes secundaris. La passarel·la o el backend hauria d'aplicar:

• Registre d'eines: cada eina té un propietari, un esquema, un abast i un nivell de risc.
• Llistes permeses: les plantilles de sessió indiquen exactament quines eines estan disponibles.
• Portes d'aprovació: les accions amb efectes secundaris requereixen la confirmació de l'usuari, l'aprovació humana o l'aprovació de la política.
• Credencials separades: les credencials de l'eina mai s'incorporen a la sessió del navegador.
• Ruta d'auditoria unida: cada trucada d'eina fa referència a l'ID de sessió en temps real.

Per exemple, un agent de veu d'assistència pot trucar automàticament al lookup_order_status, però refund_payment pot requerir una confirmació explícita i un esdeveniment d'aprovació del backend. El proveïdor de temps real pot orquestrar la conversa, però la vostra passarel·la hauria de regir el límit dels permisos.

Visibilitat sense utilitzar cada byte

El flux de mitjans WebRTC directe redueix la latència de la passarel·la i la càrrega d'ample de banda, però la visibilitat depèn més dels esdeveniments del proveïdor i de les metadades de la vostra sessió. Dissenya analítiques a partir de diverses fonts d'evidència:

• Registres de creació de sessions des de la passarel·la.
• Esdeveniments del cicle de vida del client, com ara connectat, desconnectat, intent de reconnexió, micròfon denegat o trucada finalitzada.
• Identificadors de sessió del proveïdor, esdeveniments d'ús o registres d'ús finals.
• Estimacions basades en la durada quan es retarda l'ús del proveïdor.
• Registres de trucades d'eines units per ID de sessió.
• Registres de reserva i liquidació del pressupost.

No espereu a una telemetria perfecta del proveïdor abans d'iniciar els controls. Comenceu amb reserves conservadores i una atribució clara i, a continuació, milloreu la precisió de la liquidació a mesura que maduren els informes d'ús del proveïdor.

Llista de control de seguretat

• No envieu mai les claus del proveïdor estàndard API al navegador o als clients mòbils.
• Utilitzeu secrets de client efímers de curta durada per iniciar la sessió en temps real.
• Autentiqueu l'usuari final abans d'encunyar el testimoni.
• Enllaçar les decisions d'encunyació a les metadades de l'arrendatari, l'usuari, l'origen, el noce i el dispositiu sempre que sigui possible.
• Conserveu les credencials d'execució del proveïdor en un magatzem secret de volta o passarel·la.
• Enregistreu una fila d'auditoria de sessió abans d'encunyar el proveïdor.
• Utilitzeu plantilles de sessió aprovades pels inquilins en lloc de la configuració del client arbitrària.
• Aplica límits de concurrència, d'ús diari i de durada màxima.
• Utilitzeu les llistes permeses d'eines i les portes d'aprovació per als efectes secundaris.
• De manera predeterminada, minimitzeu les indicacions en brut i la retenció d'àudio.
• Manteniu una matriu de capacitat del proveïdor per a la vida útil del testimoni, les regions, les eines, els esdeveniments d'ús i els controls de terminació.

Matriu de capacitat del proveïdor

Com que les API en temps real són diferents, modeleu l'adaptador de passarel·la segons les capacitats en lloc de supòsits. Una matriu senzilla pot impulsar decisions d'encaminament i polítiques:

{
  "provider_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": true,
    "token_ttl_seconds": 60,
    "server_side_disconnect": true,
    "session_update": true,
    "usage_events": "final_and_incremental",
    "regions": ["us", "eu"],
    "tool_approval_supported": true
  },
  "provider_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": true,
    "token_ttl_seconds": 120,
    "server_side_disconnect": false,
    "session_update": false,
    "usage_events": "final_only",
    "regions": ["us"],
    "tool_approval_supported": false
  }
}

Si un inquilí requereix la residència a la UE i la terminació del costat del servidor, la passarel·la només hauria de dirigir-se als proveïdors i implementacions que compleixin tots dos. Si cap proveïdor compleix la política, falla tancat.

Camí de migració

No cal que construïu tots els controls el primer dia. Un llançament pràctic és:

1. Només per a la creació de sessions de proxy: mantingui els mitjans directes, però requereix que totes les sessions en temps real siguin encunyades pel backend o la passarel·la.
2. Afegiu plantilles de polítiques: substituïu els camps de model i instruccions subministrats pel client per perfils aprovats.
3. Afegiu una reserva de pressupost: reserveu el cost conservador de la sessió abans de l'emissió del testimoni.
4. Afegiu analítiques del cicle de vida: recull l'inici de la sessió, la connexió, la desconnexió, la durada, l'identificador de sessió del proveïdor i l'estat de la liquidació.
5. Afegiu govern d'eines: requereixen llistes de permís i aprovacions per a les trucades d'eines en temps real.
6. Afegiu l'encaminament de la capacitat del proveïdor: seleccioneu proveïdors per regió, modalitat, suport d'esdeveniments i controls de terminació.
7. Afegiu fluxos de treball opcionals d'observador o d'enregistrament: només quan compleixin, acceptin i aprovin l'inquilí.

Conclusió accionable

Per a la IA de veu en temps real, una passarel·la AI API no s'ha de convertir automàticament en un retransmetre multimèdia. L'arquitectura més segura i amb una latència més baixa consisteix a mantenir la passarel·la a càrrec del pla de control: autenticar usuaris, fer complir la política d'inquilí, reservar pressupost, crear un registre d'auditoria, crear una credencial efímera d'abast restringit i conciliar l'ús després de la sessió.

La regla bàsica d'implementació és senzilla: els navegadors poden rebre secrets de sessió de curta durada, mai claus de proveïdor de llarga durada. Tota la resta se segueix d'aquest límit: plantilles estrictes, encunyació conscient de l'origen, límits de sessions concurrents, aprovacions d'eines, liquidació d'ús i matrius de capacitat del proveïdor. Això ofereix als equips de productes experiències de veu en temps real sense renunciar a la gestió de API claus, al control de costos API de l'IA, al govern de l'equip API o a l'anàlisi de l'ús d'IA.

Lectura relacionada

• Volta de credencials del proveïdor per al temps d'execució claus
• Llibre de reserva i liquidació del pressupost