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

El navegador i les aplicacions mòbils no haurien de rebre claus de l'API del proveïdor 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 porta d'enllaç API AI. 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 d'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 d'API de proveïdor estàndard.
• 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 queda 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 l'API en temps real d'OpenAI descriu interfícies en temps real de baixa latència, inclòs WebRTC. La guia 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 API estàndard en una aplicació client. Les instruccions en temps real de l'SDK d'OpenAI Agents 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 dels proveïdors de manera explícita en lloc de pretendre 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. Passerella de l'API AI: fa complir 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: finalitza WebRTC o un altre transport en temps real.
5. Llibre i anàlisis: 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 de realtime_session abans de contactar amb el proveïdor.
6. La passarel·la truca al proveïdor amb la seva credencial d'execució protegida i crea una sessió efímera en temps real 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 de 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 d'eines.
• Plantilla de veu i instruccions: fixada o limitada per una política.
• Pressupost disponible: saldo prepagat, assignació mensual reservada o límit de despesa per funció.
• Simultània: sessions de veu actives a nivell d'inquilí i d'usuari.
• Controls d'ús abusiu: 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 ofereix 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": "arrendatari_123",
  "end_user_id": "user_hash_456",
  "proveïdor": "proveïdor_a",
  "provider_session_id": nul,
  "model_profile": "estàndard de suport de veu",
  "upstream_model_or_deployment": "model-x en temps real",
  "region": "estus",
  "session_config_hash": "sha256:...",
  "allowed_modalities": ["entrada_àudio", "sortida_àudio"],
  "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": "encunyar"
}

No deseu l'àudio del micròfon en brut ni les indicacions 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 enregistrar-lo, feu-lo explícit, conscient del consentiment i basat en la política de l'inquilí.

Punt final d'encunyació de testimonis efímer

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

POST /v1/realtime/sessions
Autorització: portador 
Tipus de contingut: aplicació/json
{
  "tenant_id": "arrendatari_123",
  "end_user_id": "user_hash_456",
  "feature": "support_voice_agent",
  "origin": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "estàndard de suport de veu"
}

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

{
  "session_id": "rt_01j...",
  "proveïdor": "proveïdor_a",
  "transport": "webrtc",
  "client_secret": "secret_efímer_aquí",
  "expires_at": "2026-08-21T10:01:00Z",
  "aprovat": {
    "model_profile": "estàndard de suport de veu",
    "max_duration_seconds": 900,
    "modalitats": ["entrada_àudio", "sortida_àudio"],
    "tools": ["lookup_order_status"]
  }
}

Lliga l'emissió a l'origen, la sessió d'usuari autenticada, l'arrendatari i un nonce. É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 taxa d'intents, 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 eines 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ó.
• Durada de la sessió: caducitat curta de credencials 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 variants de perfil controlat en lloc de passar la configuració del client arbitrària 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

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

Durant la sessió

• Feu 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 finalització 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.
• Ajusteu 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ò és operativament 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 hauria 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'identificador de sessió en temps real.

Per exemple, un agent de veu d'assistència pot trucar automàticament a 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 del permís.

Visibilitat sense utilitzar proxy 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ó. Dissenyar anàlisis al voltant de múltiples 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 identificador 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 verificació de seguretat

• No envieu mai les claus estàndard de l'API del proveïdor al navegador o als clients mòbils.
• Utilitzeu secrets de client efímers de curta durada per iniciar sessió en temps real.
• Autentiqueu l'usuari final abans d'encunyar el testimoni.
• Enllaçar les decisions d'encunyació a les metadades d'inquilí, usuari, origen, nonce i 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 per l'inquilí en lloc de la configuració del client arbitrària.
• Aplica límits de concurrència, d'ús diari i de durada màxima.
• Utilitzeu llistes permeses d'eines i portes d'aprovació per als efectes secundaris.
• Minimitza la sol·licitud en brut i la retenció d'àudio de manera predeterminada.
• Mantenir una matriu de capacitats 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 el vostre adaptador de passarel·la segons les capacitats en lloc de supòsits. Una matriu senzilla pot impulsar decisions d'encaminament i polítiques:

{
  "proveïdor_a": {
    "transports": ["webrtc", "websocket"],
    "ephemeral_client_tokens": cert,
    "token_ttl_seconds": 60,
    "server_side_disconnect": cert,
    "session_update": cert,
    "usage_events": "final_i_incremental",
    "regions": ["us", "eu"],
    "tool_approval_supported": cert
  },
  "proveïdor_b": {
    "transports": ["websocket"],
    "ephemeral_client_tokens": cert,
    "token_ttl_seconds": 120,
    "server_side_disconnect": fals,
    "session_update": fals,
    "usage_events": "només_final",
    "regions": ["nosaltres"],
    "tool_approval_supported": fals
  }
}

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 ambdós. Si cap proveïdor compleix la política, no es tanca.

Camí de migració

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

1. Només per a la creació de sessions de proxy: mantén els mitjans directes, però requereixen que totes les sessions en temps real siguin encunyades pel backend o la passarel·la.
2. Afegiu plantilles de polítiques: substituïu el model i els camps d'instruccions subministrats pel client per perfils aprovats.
3. Afegiu una reserva de pressupost: reserveu un cost de sessió conservador abans de l'emissió del testimoni.
4. Afegiu anàlisis 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 un enrutament de la capacitat del proveïdor: seleccioneu els proveïdors per regió, modalitat, suport d'esdeveniments i controls de terminació.
7. Afegiu fluxos de treball d'observadors o de gravació opcionals: només quan compleixin, acceptin i aprovin els inquilins.

Conclusió accionable

Per a la IA de veu en temps real, una porta d'enllaç API AI no hauria de convertir-se 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 els 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 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 claus de l'API, al control de costos de l'API de l'IA, al govern de l'API de l'equip o a l'anàlisi de l'ús de l'IA.

Lectura relacionada

• Llibre de reserva i liquidació del pressupost