IA en tiempo real segura para el navegador a través de una puerta de enlace API: tokens efímeros, política de inquilinos y controles de sesión de voz

El navegador y las aplicaciones móviles no deberían recibir claves API de proveedor de larga duración. Sin embargo, para la IA de voz en tiempo real, enviar cada paquete de audio a través de una puerta de enlace puede agregar latencia, costo operativo y modos de falla. El mejor patrón es mantener la puerta de enlace en el plano de control: autenticar al usuario, hacer cumplir la política de inquilinos, reservar presupuesto, crear una credencial en tiempo real limitada y de corta duración y permitir que los medios sensibles a la latencia utilicen el transporte en tiempo real del proveedor cuando corresponda.

Este artículo describe un patrón de implementación para equipos que crean agentes de voz, asistentes de llamadas, tutores móviles, copilotos de soporte o interfaces de voz en aplicaciones a través de una puerta de enlace API de IA. El objetivo es la seguridad del navegador sin perder la gobernanza de los inquilinos.

El problema: las conexiones directas en tiempo real pasan por alto tus controles

Un proxy simple del lado del servidor es atractivo porque centraliza las claves y la observabilidad. Para solicitudes de texto estándar, este suele ser el modelo correcto. El audio en tiempo real es diferente. Una sesión de voz puede implicar entrada continua de micrófono, salida de audio bidireccional, interrupciones, llamadas de herramientas y expectativas estrictas de latencia. Proxy todos los medios a través de su puerta de enlace puede convertir la puerta de enlace en una retransmisión de medios con mucho ancho de banda en lugar de un servicio de políticas y facturación.

Las conexiones directas del navegador al proveedor resuelven la latencia, pero crean un problema diferente:

• El navegador no puede contener de forma segura una clave API de proveedor estándar.
• Es posible que se omitan las comprobaciones del presupuesto del inquilino si la aplicación se conecta directamente.
• Las restricciones de modelo, región, voz, modalidad y herramientas se convierten en promesas del lado del cliente.
• La atribución de uso queda incompleta o se retrasa.
• Los equipos de seguridad pierden un punto de decisión auditable antes de que comience una sesión.

El diseño práctico no es "proxy cada byte". Es "intermediario en cada sesión".

Hechos, recomendaciones y predicciones

Datos: Los proveedores de IA en tiempo real admiten cada vez más transportes de baja latencia como WebRTC, WebSocket y SIP. La documentación pública de la API en tiempo real de OpenAI describe interfaces en tiempo real de baja latencia, incluido WebRTC. La guía WebRTC en tiempo real de Azure OpenAI describe una aplicación de explorador que utiliza un servicio de token de backend para recuperar un token efímero antes de iniciar la conexión WebRTC y advierte contra el uso de una clave API estándar en una aplicación cliente. La guía en tiempo real del SDK de agentes OpenAI también recomienda un flujo en el que un backend crea un token de cliente efímero de corta duración y el navegador lo utiliza para establecer una conexión WebRTC.

Recomendaciones: Trate la puerta de enlace como la autoridad de sesión. Debe decidir si puede existir una sesión en tiempo real, con qué modelo, en qué región, para qué inquilino, con qué presupuesto y con qué herramientas. El cliente debe recibir solo la credencial mínima de corta duración necesaria para iniciar esa sesión aprobada.

Predicciones: Las API de los proveedores en tiempo real seguirán siendo desiguales durante un tiempo. La duración de los tokens, los campos de configuración de la sesión, los controles de desconexión del lado del servidor, los eventos de uso y el soporte regional serán diferentes. Las puertas de enlace deben modelar explícitamente las capacidades del proveedor en lugar de pretender que todas las API en tiempo real son perfectamente portátiles.

Arquitectura de referencia: gateway como plano de control en tiempo real

Un flujo en tiempo real seguro para el navegador consta de cinco partes:

1. Aplicación cliente: navegador o aplicación móvil que solicita una sesión de voz.
2. Backend de la aplicación: autentica al usuario final y llama a la puerta de enlace, o incorpora la lógica de acuñación de tokens de la puerta de enlace si la puerta de enlace forma parte de la pila del backend.
3. Puerta de enlace AI API: aplica la política de inquilinos, resuelve el perfil del modelo, reserva el presupuesto, registra la sesión y crea un secreto de cliente de proveedor efímero.
4. Proveedor de tiempo real: finaliza WebRTC u otro transporte en tiempo real.
5. Libro mayor y análisis: liquida el uso una vez que los eventos del proveedor, los datos de duración o los informes de uso final están disponibles.

La puerta de enlace no necesita transmitir cada cuadro de audio para seguir teniendo autoridad. Debe ser propietario de la decisión de creación de la sesión y de la ruta de reconciliación.

Flujo de solicitudes recomendado

1. El usuario abre una función de voz en la aplicación del cliente.
2. El cliente llama a su servidor: POST /voice/sessions.
3. El backend verifica la sesión del usuario y reenvía una solicitud mint a la puerta de enlace con el ID del inquilino, el ID del usuario, la función deseada, los metadatos del dispositivo y el origen.
4. El portal evalúa la política y el presupuesto.
5. La puerta de enlace crea un registro realtime_session local antes de ponerse en contacto con el proveedor.
6. La puerta de enlace llama al proveedor con su credencial de tiempo de ejecución protegida y crea una sesión efímera en tiempo real de alcance limitado.
7. La puerta de enlace devuelve al navegador solo el secreto efímero del cliente y los metadatos de la sesión aprobada.
8. El navegador establece la conexión WebRTC directamente con el proveedor.
9. La puerta de enlace incorpora eventos de uso del proveedor, devoluciones de llamadas, resultados de encuestas o estimaciones conservadoras basadas en la duración.
10. El libro mayor liquida el presupuesto reservado y escribe los eventos de auditoría.

Comprobaciones de políticas previas a la acuñación

El punto de aplicación más importante es antes de que se acuñe el token efímero. Una vez que el navegador tiene una credencial de corta duración, la aplicación a mitad de sesión puede ser limitada a menos que el proveedor admita controles de actualización, desconexión, observador o devolución de llamada de la sesión.

Como mínimo, la puerta de enlace debe comprobar:

• Estado del inquilino: activo, suspendido, de prueba, prepago, facturado o en cuarentena.
• Derecho del usuario: si este usuario puede utilizar voz en tiempo real, no solo chat de texto.
• Perfil de modelo permitido: modelo o implementación aprobados en tiempo real, no ID de modelo arbitrarios proporcionados por el cliente.
• Región y política de retención: si la región del proveedor seleccionado y el conjunto de características coinciden con las reglas de datos del inquilino.
• Duración máxima de la sesión: por ejemplo, 5, 15 o 30 minutos según el plan.
• Modalidades permitidas: entrada de audio, salida de audio, texto, imagen o llamadas a herramientas.
• Plantilla de voz e instrucciones: fija o limitada por política.
• Presupuesto disponible: saldo prepago, asignación mensual reservada o límite de gasto por función.
• Simultaneidad: sesiones de voz activas a nivel de inquilino y a nivel de usuario.
• Controles de abuso: indicadores de riesgo del usuario, reputación del origen, velocidad de llamada inusual o desconexión automática del inquilino.

Un valor predeterminado seguro es rechazar solicitudes ambiguas. Si el cliente solicita un modelo, herramienta, voz o región que no está en la política en tiempo real del inquilino, la puerta de enlace debería devolver un error de política claro en lugar de ampliar el acceso silenciosamente.

Diseño de registro de sesión

Cree un registro de sesión del lado de la puerta de enlace antes de acuñar la credencial del proveedor. Esto le proporciona un anclaje de auditoría incluso si la creación del proveedor se realiza correctamente pero el navegador nunca se conecta.

{
  "session_id": "rt_01j...",
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "proveedor": "proveedor_a",
  "provider_session_id": nulo,
  "model_profile": "estándar de soporte de voz",
  "upstream_model_or_deployment": "realtime-model-x",
  "región": "este",
  "session_config_hash": "sha256:...",
  "modalidades_permitidas": ["entrada_audio", "salida_audio"],
  "allowed_tools": ["lookup_order_status"],
  "tool_approval_policy": "aprobar_side_effects",
  "budget_reservation_id": "resv_789",
  "max_duration_segundos": 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:...",
  "estado": "acuñación"
}

No almacene el audio del micrófono sin formato ni las indicaciones completas de forma predeterminada. Almacene hashes de configuración, ID, decisiones de políticas y metadatos mínimos suficientes para auditoría, soporte y facturación. Si es necesario realizar una grabación, hágala explícita, tenga en cuenta el consentimiento y esté basada en la política del inquilino.

Punto final de acuñación de tokens efímeros

Un punto final orientado a la puerta de enlace podría verse así:

POST /v1/tiempo real/sesiones
Autorización: Portador 
Tipo de contenido: aplicación/json
{
  "tenant_id": "tenant_123",
  "end_user_id": "user_hash_456",
  "característica": "support_voice_agent",
  "origen": "https://app.example.com",
  "device_nonce": "8f3b...",
  "requested_profile": "estándar de soporte de voz"
}

La respuesta no debería exponer su clave de tiempo de ejecución ascendente:

{
  "session_id": "rt_01j...",
  "proveedor": "proveedor_a",
  "transporte": "webrtc",
  "client_secret": "efímero_secreto_aquí",
  "expires_at": "2026-08-21T10:01:00Z",
  "aprobado": {
    "model_profile": "estándar de soporte de voz",
    "max_duration_segundos": 900,
    "modalidades": ["audio_input", "audio_output"],
    "herramientas": ["lookup_order_status"]
  }
}

Vincular la emisión al origen, la sesión de usuario autenticado, el inquilino y un nonce. Es posible que el proveedor no admita todos esos enlaces de forma nativa, así que aplique lo que pueda en la puerta de enlace: limitar la velocidad de los intentos de acuñación, rechazar orígenes inesperados, registrar metadatos del dispositivo y mantener corta la vida útil del token.

Plantillas de sesión: estrechas por defecto

Una plantilla de sesión en tiempo real debería ser más restrictiva que una solicitud general de finalización de chat. Las sesiones de voz son interactivas, más difíciles de inspeccionar en tiempo real y pueden durar más de lo esperado.

Los campos de plantilla recomendados incluyen:

• Modelo fijo o implementación: elegido por un perfil de modelo del lado de la puerta de enlace.
• Instrucciones: una plantilla de aviso controlada por el servidor con variables aprobadas por el inquilino.
• Voz: seleccionada de una lista de permitidos.
• Modalidades: deshabilite los modos de texto, imagen o herramienta a menos que el producto los necesite.
• Configuración de audio de entrada: detección de giros, comportamiento de transcripción o manejo de silencio cuando sea compatible.
• Restricciones de salida: longitud máxima de la respuesta o comportamiento de la respuesta cuando sea compatible.
• Lista de herramientas permitidas: solo las herramientas necesarias para la función.
• Duración de la sesión: caducidad breve de la credencial más duración máxima de la llamada.

Las plantillas estrictas reducen la flexibilidad, pero facilitan los costos, el cumplimiento y el soporte. Si los equipos de producto necesitan voces o instrucciones dinámicas, exponga variantes de perfil controladas en lugar de pasar la configuración arbitraria del cliente al proveedor.

Controles de presupuesto para voz en tiempo real

Puede ser más difícil fijar el precio del uso en tiempo real antes de que llegue el uso final del proveedor. Una sesión puede durar cinco segundos o veinte minutos. Puede incluir entrada de audio, salida de audio, transcripción, llamadas a herramientas y tokens de texto. Por lo tanto, la pasarela debería combinar reservas, límites y conciliación.

Antes de acuñar

• Estime el costo de una sesión conservadora o en el peor de los casos a partir de la duración máxima, el modelo, las modalidades y el plan del inquilino.
• Reserve el presupuesto antes de emitir el secreto del cliente.
• Rechace nuevas sesiones si el inquilino no tiene saldo suficiente o ha alcanzado los límites de voz diarios.

Durante la sesión

• Seguimiento de sesiones activas y tasa de consumo esperada.
• Aplicar límites de simultaneidad de inquilinos y usuarios.
• Utilice las funciones de finalización de sesión o actualización de sesión admitidas por el proveedor, si están disponibles.
• Activar alertas en caso de duración anormal de la sesión, reconexiones repetidas o uso inusual de la voz.

Después de la sesión

• Ingerir eventos de uso del proveedor o informes de uso final cuando estén disponibles.
• Establecer el presupuesto reservado al costo real.
• Si el uso exacto se retrasa o está incompleto, mantenga una reserva conservadora hasta la conciliación.
• Atribuya el uso al inquilino, usuario, característica, perfil de modelo e ID de sesión.

Esto es menos exacto que la facturación sincrónica por mensaje de texto en el momento de la respuesta, pero operativamente es más seguro que emitir credenciales directas sin reservas.

Llamadas a herramientas dentro de sesiones en tiempo real

Los agentes de voz en tiempo real suelen resultar más útiles cuando pueden llamar a herramientas: buscar una cuenta, reservar una cita, actualizar un ticket o activar un flujo de trabajo. Trate la ejecución de herramientas por separado del transporte de audio.

La conexión multimedia del navegador no debe implicar permiso para realizar efectos secundarios. La puerta de enlace o el backend deben aplicar:

• Registro de herramientas: cada herramienta tiene un propietario, esquema, alcances y nivel de riesgo.
• Listas permitidas: las plantillas de sesión enumeran exactamente qué herramientas están disponibles.
• Puertas de aprobación: las acciones con efectos secundarios requieren la confirmación del usuario, la aprobación humana o la aprobación de la política.
• Credenciales independientes: las credenciales de la herramienta nunca se integran en la sesión del navegador.
• Pista de auditoría unida: cada llamada a la herramienta hace referencia al ID de la sesión en tiempo real.

Por ejemplo, a un agente de voz de soporte se le puede permitir llamar a lookup_order_status automáticamente, pero refund_paid puede requerir una confirmación explícita y un evento de aprobación de backend. El proveedor en tiempo real puede organizar la conversación, pero su puerta de enlace debe controlar el límite de permisos.

Visibilidad sin proxy de cada byte

El flujo de medios directo WebRTC reduce la latencia de la puerta de enlace y la carga de ancho de banda, pero la visibilidad se vuelve más dependiente de los eventos del proveedor y de los metadatos de su propia sesión. Diseñe análisis en torno a múltiples fuentes de evidencia:

• Registros de creación de sesiones desde la puerta de enlace.
• Eventos del ciclo de vida del lado del cliente, como conexión, desconexión, intento de reconexión, micrófono denegado o llamada finalizada.
• ID de sesión del proveedor, eventos de uso o registros de uso final.
• Estimaciones basadas en la duración cuando el uso del proveedor se retrasa.
• Registros de llamadas de herramientas unidos por ID de sesión.
• Registros de reservas y liquidaciones presupuestarias.

No espere a que la telemetría del proveedor sea perfecta antes de iniciar los controles. Comience con reservas conservadoras y una atribución clara, luego mejore la precisión de la liquidación a medida que maduren los informes de uso del proveedor.

Lista de control de seguridad

• Nunca envíe claves API de proveedores estándar al navegador o a clientes móviles.
• Utilice secretos de cliente efímeros y de corta duración para iniciar sesiones en tiempo real.
• Autenticar al usuario final antes de acuñar el token.
• Vincular las decisiones de acuñación a los metadatos del inquilino, usuario, origen, nonce y dispositivo siempre que sea posible.
• Mantenga las credenciales de tiempo de ejecución del proveedor en una bóveda de backend o en un almacén secreto de puerta de enlace.
• Registrar una fila de auditoría de sesión antes de la acuñación del proveedor.
• Utilice plantillas de sesión aprobadas por los inquilinos en lugar de configuraciones de cliente arbitrarias.
• Aplicar límites de simultaneidad, uso diario y duración máxima.
• Utilice listas de herramientas permitidas y puertas de aprobación para efectos secundarios.
• Minimice la retención de audio y mensajes sin formato de forma predeterminada.
• Mantener una matriz de capacidades del proveedor para la duración de los tokens, regiones, herramientas, eventos de uso y controles de terminación.

Matriz de capacidades del proveedor

Dado que las API en tiempo real difieren, modele su adaptador de puerta de enlace en función de capacidades en lugar de suposiciones. Una matriz simple puede impulsar decisiones de enrutamiento y políticas:

{
  "proveedor_a": {
    "transporta": ["webrtc", "websocket"],
    "ephemeral_client_tokens": verdadero,
    "token_ttl_segundos": 60,
    "server_side_disconnect": verdadero,
    "session_update": verdadero,
    "usage_events": "final_and_incremental",
    "regiones": ["nosotros", "ue"],
    "tool_approval_supported": verdadero
  },
  "proveedor_b": {
    "transporta": ["websocket"],
    "ephemeral_client_tokens": verdadero,
    "token_ttl_segundos": 120,
    "server_side_disconnect": falso,
    "session_update": falso,
    "usage_events": "final_only",
    "regiones": ["nosotros"],
    "tool_approval_supported": falso
  }
}

Si un inquilino requiere residencia en la UE y terminación del lado del servidor, la puerta de enlace debe enrutarse solo a proveedores e implementaciones que satisfagan ambas. Si ningún proveedor cumple la política, no se cerrará.

Ruta de migración

No es necesario crear todos los controles desde el primer día. Una implementación práctica es:

1. Solo creación de sesiones de proxy: mantenga los medios directos, pero requiera que todas las sesiones en tiempo real sean creadas por el backend o la puerta de enlace.
2. Agregar plantillas de políticas: reemplace el modelo proporcionado por el cliente y los campos de instrucción con perfiles aprobados.
3. Agregar reserva de presupuesto: reserve el costo de sesión conservador antes de la emisión del token.
4. Agregue análisis del ciclo de vida: recopile el inicio de la sesión, la conexión, la desconexión, la duración, el ID de la sesión del proveedor y el estado de la liquidación.
5. Agregar control de herramientas: requerir listas permitidas y aprobaciones para llamadas de herramientas en tiempo real.
6. Agregar enrutamiento de capacidad de proveedor: seleccione proveedores por región, modalidad, soporte de eventos y controles de terminación.
7. Agregue flujos de trabajo de observación o grabación opcionales: solo cuando cumpla con las normas, esté consentido y esté aprobado por el inquilino.

Conclusión procesable

Para la IA de voz en tiempo real, una puerta de enlace API de IA no debería convertirse automáticamente en una retransmisión de medios. La arquitectura más segura y de menor latencia es mantener la puerta de enlace a cargo del plano de control: autenticar usuarios, hacer cumplir la política de inquilinos, reservar presupuesto, crear un registro de auditoría, crear una credencial efímera de alcance limitado y conciliar el uso después de la sesión.

La regla principal de implementación es simple: los navegadores pueden recibir secretos de sesión de corta duración, nunca claves de proveedor de larga duración. Todo lo demás se deriva de ese límite: plantillas estrictas, acuñación con reconocimiento del origen, límites de sesiones simultáneas, aprobaciones de herramientas, liquidación de uso y matrices de capacidades de proveedores. Esto brinda a los equipos de productos experiencias de voz en tiempo real sin renunciar a la administración de claves de API, el control de costos de API de AI, la gobernanza de API del equipo o el análisis de uso de AI.

Lectura relacionada

• bóveda de credenciales de proveedor para tiempo de ejecución claves
• libro mayor de liquidación y reserva de presupuesto